Контроль остатков при неоперативном проведении #215278

При неоперативном проведении УТ не проверяет остатки. Вижу множество аргументов ПРОТИВ этого. Но есть ли аргументы ЗА?

При неоперативном проведении УТ не проверяет остатки. Вижу множество аргументов ПРОТИВ этого. Но есть ли аргументы ЗА?

При неоперативном проведении УТ не проверяет остатки. Вижу множество аргументов ПРОТИВ этого. Но есть ли аргументы ЗА?

вопрос по V8!

Да есть такие дело. Супер не правда ли ))

Думаю стоит ждать новую редакцию УТ либо писать. Франчи тоже возмущены очень.

Есть. Один. Повышение быстродействия.

Я считаю версию, что документы формируют всегда оперативно и никогда не правят потом идиалестическим бредом... Закоментарить строки Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда     НаборДвижений.КонтрольОстатков(Это.... .... конечно не сложно, просто думала, что в них есть некий глубинный смысл...

Для полного быстродействия тогда стоит вообще отменить перепроведение Раз провелось - все, больше кривыми ручками не лазить!

Закомментарить условие про оперативность, конечно, не сложно. Чуть сложнее (точнее муторнее) во всех запросах прописать моменты времени в параметрах.

в правах запретить проводить неоперативно

упс... А я не в теме! Остатки берутся не на момент времени? Ща буду смотреть...

это просто невозможно. Некоторые расходные документы формируют днем позже.

И что ты этим хочешь добиться?

там надо править модули регистров. Я в свое время так попался, просто закоментировав строки :))

а смысл что-то контролировать при неоперативном проведении? последущие расходы могут свести на нет весь твой контроль и все равно заминусовать остатки. бардак, однозначно... Видел кучу контор, которые пищали, что они жить не могут без формирования документов завтрашним числом и в результате этого имели постоянный геморрой с отрицательными остатками. Лечилось нормальной постановкой документооборота.

Уже вижу, что не так все просто! Спасибо, что предупредили.

не бардак, а условия проведения отчетов о розничных продажах с пос-терминалов. А отрицательные остатки легче выявлять при проведении документов, чем потом отлавливать документы без себестоимости!

а при чем здесь "неоперативное проведение"? вы в pos-ах закрываете смены через день?

не без себестоимости, а дающие отрицательный остаток

они смену с терминала на след. день привозят.

по правильному, нужно перепроводить сразу же всё, после нарушения последовательности. как уже сказали - это будет полнейший тормоз, иногда, просто невозможный (документ двухгодичной давности, типа). Посему - это необходимое зло. по другому, просто невозможно при существующей идеологии УТ. В аксапте - сторнирование для этого. Только что делать с итогами за прошедшии отчётные периоды?

Идеология такая - проведение задним числом - это уже свершившийся акт и смысла в проверке остатков нету. При оперативном проведении остатки актуальные и запрос по остаткам идет мгновенно. Если это изменить и проверять остатки на конкретный момент - в запросе будет замедление за счет расчета итогов, что как следствие приведет к невозможности работы при многопользовательской интенсивной работе, т.к. часто будут возникать ошибки транзакции. При оперативном проведении остатки нерасчитываются - они уже есть готовые.

"При этом контроль остатков остаётся на усмотрении "и тэдэ и тэпэ  - с саппорта 1С. я не стал трогать. оставил как есть. по причинам: 1. нех лазить в закрытый период. Только с разрешения шефа. 2. зачем туда лазить? делать сторно? если в "+", То необходимо только перепроведение документов. 3. если лишнего наприходовали.. (а ситуация с "-" может возникнуть по поему только в это случае) спрашивается что тогда переместили/продали.. воздух что ли?

Самое грамотное решение приняла 1С - не контролировать ничего при неоперативном проведении. Залезая назад, для нормальной работы надо контролировать не только прошлые, но и будущие документы. Это ужас просто! Так что грамотнее просто отключить контроль.

ОК. Я согласна, что это возможно, когда все документы выписываются в системе в режиме on-line. Но такой возможности нет: 1) Отчеты о продажах с посов принимают на следующий день; 2) Приходные документы исправляют за вчерашний день; 3) После каждого нарушения последовательности восстанавливать - хаха нереально конечно, в базе одновременно работают 40-60 пользователей; Пока есть только такая идея: Проверять остатки в модуле формы перед записью, чтоб проверка не происходила при перепроведении.

"Проверять остатки в модуле формы перед записью" - ну да, ну да. Если одновременно несколько пользователей зафигачат списание по одной и той-же позиции, то минусы полезут всеравно. Лучше ночь восстанавливать последовательность.

На ИТС :"как правило проведение задним числом опперация редкая и осмысленная "

Но когда поставщик ждет от покупателя того что он все сам пересчитает в приходе ,отправит расхождения поставщику, тот выпишет норамальную накладную и тд. и тр. :)

Но время то идеть. Не стоит на месте.

Вот нашелся человек, который меня понимает!

Себестомиость в регламент. Однозначно.

Раз в месяц  :)

ПередЗаписью - хорошее решение, мне нравится. По сравнению с проверкой в ОбработкеПроведения это позволит избежать долгих блокировок регистров, по которым делаются движения. И вообще-то ПередЗаписью необязательно в форме, для универсальности лучше в модуле дока. Главное, что процедура ПередЗаписью может выполняться сколь угодно долго, т.к. ничего не блокирует. А минусы - это вещь специфичная - у кого-то есть, а у кого-то нету - все зависит от того, как распределена работа.

Я вот тоже такую тему поднимал: Включил неоперативный контроль, на следующий же день попросили отключить, вот так-то...

Себестоимость в регламент - неплохое предложение. Но. Если есть доки делающие минусы - никакой себестоимости не получится. Как предотвратить в общей массе эти минусы - вот концептуальный вопрос! Идеи типовой УТ не прокатывают.

Ну например, запретить проведение задним числом

Как предотвратить в общей массе эти минусы - вот концептуальный вопрос! Концептуальный вопрос - это то , что для продажи чего либо материального необходимо сначала купить что либо маериальное. Это вид деятельности диктует все сложности.Проще конечно продавать не материальное. Т.е. то чего в имущественном выражении нет.

" Идеология такая - проведение задним числом - это уже свершившийся акт и смысла в проверке остатков нету." Смысл есть... например, на тот момент просто не было товара на складе.... "Залезая назад, для нормальной работы надо контролировать не только прошлые, но и будущие документы. Это ужас просто! Так что грамотнее просто отключить контроль." Это - безграмотнее. НО ПРОЩЕ.... Ибо свою головную боль запихиваем в задницу пользователя и пусть он типа трахается...    А документы действительно надо проверять.... Если ты сообразишь, как это делать быстро (пересчет) - тогда взлетишь.... Купи идею... Продам недорого, баксов за 500...

" Идеология такая - проведение задним числом - это уже свершившийся акт и смысла в проверке остатков нету." Смысл есть... например, на тот момент просто не было товара на складе.... "Залезая назад, для нормальной работы надо контролировать не только прошлые, но и будущие документы. Это ужас просто! Так что грамотнее просто отключить контроль." Это - безграмотнее. НО ПРОЩЕ.... Ибо свою головную боль запихиваем в задницу пользователя и пусть он типа трахается...    А документы действительно надо проверять.... Если ты сообразишь, как это делать быстро (пересчет) - тогда взлетишь.... Купи идею по предотвращению минусов.. Продам недорого, баксов за 500...

Объясняла уже, что нельзя запретить проведение задним числом. Незачет.

| " Идеология такая - проведение задним числом - это уже свершившийся акт и | смысла в проверке остатков нету." Да просто взяли и нормальные, неодаренные анализом своих действий, пользователи перенесли вчерашнюю приходную на конец дня. А другие пользователи хотят списание товара провести вчерашним днем. И пусть программа выдаст им сообщение, что проблема! И пусть разбираются с этой проблемой когда делают документ и когда свежи воспоминания, а не раз в месяц перед расчетом себестоимости.

Так ты же написала про контроль ПриЗаписи - это неустраивает?

ошибка - ПередЗаписью, конечно.

Контроль ПередЗаписью - это обсуждаемый вариант. Я не писала, что не устраивает, есть недостатки, что несколько пользователей могут списать одни остатки. Но! Процент документов ушедших в минус уменьшится на порядки!

можно вообще предотвращать...

Как?...

Какие проблемы - проверяй в ОбработкеПроведения. Тогда минусов не будет. Но могут быть блокировки с ошибками транзакци.

имхо надо заниматься не последствиями а причинами. т.е. трудность перепроведения задним числом лишь следствие .. как переделать существующее не знаю.. пит вон чего то разоряется по этому поводу но конструктива как всигда ноль.

Попробуй понять. Я даже не могу поднимать разговор о изменении документооборота и регламентов. Над этим работали топ-менеджеры. Программист нужет для автоматизации разработанных бизнесс-процессов. И мое заявление "Вы тут все не так делаете" не прокатит. Есть реальная задача: контролировать остатки при изменении в документах при проведении задним числом. В ходе обсуждения выяснено, что есть варианты: 1) Контролировать в проведении. Недостатки: блокировки и переписывание кода. 2) Контролировать перед записью в форме. Недостаток: остатки можно одновременно списать нескольким пользователям.

Так двух зайцев нельзя убить одним патроном.

+ Нужно выбрать меньшее, чем стОит пожертвовать.

Ок. Будем их душить.

Для данного учета меньшее зло - это контроль остатков в форме перед записью.

при списании партий если их нет выдает ошибку, можно там попробывать поставить отмену проведения

Расчет партий в регламент! :) При проведении не делать, мы договорились.

а вот как ... отследить что хочет сделать пользователь например - есть док на приход 10 штук на 01/01/06 соответсвенно по этому товару есть и расход 10 штук 10/01/06 оператор находит ошибку - надо было оприхоовать не 10, а 20 шт его действия ... меняет в ТЧ количество на 20 наши действия ? Проведение и где мне ставить проверку ?

т.е. есть отмена проведения документа, а вот что будет после ... как узнать будет ли после отмены документ снова проведен или нет ?

При вводе строки дока можно проверять остатки, но могут быть тормоза...

Есть мысль: Отчет по документам, которые "уходят в минус". Выполнять его перед восстановлением последовательности и расчетом себестоимости, чтобы исключить нераспределенные партии. Ваше мнение, господа!

Резонно! Еще один большой минус варианту размещать проверку остатков в форме документа.

я думаю над такой заморочкой прикрутить ко всему этому делу бизнес процессы при отмене проведения дока (хоть прихода, хоть расхода) отменять проведение всех документов по номенклатуре - и кидать их в задачи на проведение

... Если я тебя правильно поняла, ты хочешь перепровести все пооследующие документы по товарам из исправленной накладной??? не катит.

уже столкнулся с ошибками оператора: изменили дату прихода на более позднюю увеличили количество в приходе (уменьшили цену)- соответсвенно минусы в суммовом учете почему ?

(партии у нас списываются документами)

Лучше правильно настроить последовательность документов Если это не критично, то отказаться от движений партий по документам, проводить в конце месяца перед расчетом себестомости.

Как правильно настроить? Проблема в том, что в базе велика вероятность минусов. При восстановлениии последовательности партии не распределятся. Возможные решения: 1) запретить минусы => тормоза и блокировки 2) ежедневно контролировать документы, из-за которых лезут минусы и исправлять ошибки

Есть еще решение: подождать выхода 8.1 - если там тормозов и блокировок небудет, то вы можете спокойно проверять остатки в ОбработкеПроведения.

1) Интересно когда будет выход? 2) Для отсутствия блокировок код придется дописывать?

Да, там есть управляемые блокировки. Выход-то намечают, но это приблизительно. Я думаю, что ноябрь-декабрь.

Ну что. Голосуем за контроль остатков в модуле проведения?

протифф

Это единственный нормальный выход. Остатки нужно контролировать, если есть изменения задним числом - факт. Другой вопрос что их нужно контролировать не только на момент времени, но и на текущую дату. Тут без перепроведения последовательностей не обойтись. А это уже великие тормоза .

Каждый сам для себя голосует. Я не знаю вашу фирму и ваши процессы. У меня есть фирма - контроль остатков в форме, а есть фирма - контроль остатков при проведении.

Сорри, может не в тему, но если так поставить вопрос - неправильно забитый документ дал неверный остаток. А что если взять да и провести Инвентаризацию? Она как раз и предназначена для исправления таких ситуаций? Сильно не пинайте, работаю с бухгалтерией преимущественно 77.

У нас более 10 лет работает система (не 1с), в которой для изменения задним числом необходимо "отменить" все документы, связанные с партиями изменяемого документа. Причём, ручками (система подсказывает какие). Если день назад - это ещё реально, два дня - никому и в голову не придёт распутывать этот клубок. Если бы такая система была в 1с УТ (а это вполне реально и не сложно реализовать) - те, кто разрабатывал/утверждал бизнес-процесы вашего предприятия вероятно изменили бы своё решение.

о) у тебя система для пользователей или ползователи для системы?))

No comments! Если б я в своей компании к директору пришла и сказала - "воть, теперь у нас будет так!" - меня бы вышибли и денех не дали! :)

технологии складского учёта разработали не ваши топ-менеджеры и даже не 1с, им несколько сотен (тысяч) лет. вы что, в амбарной книге будете подчищать записи и вырывать листы? Если вы (ваше руководство) согласны на это, то должны и фальшивые остатки/себестоимость кушать в соответствии с правилами ихнего "уникального" бизнеса или "конкурентного преимущества". - система для учёта, прежде всего; пользователи - материал переменный, правила учёта - постоянные. Не нужно по принципиальным вопросам идти на поводу у пользователей/заказчиков/руководителей. У вас, в конце концов, есть ит-директор, если нет - то сами доказывайте, что нехорошо вчерашний день корректировать. вы же потом и будете ночами/выходными перепроводками заниматься и минусы куда-нибудь пристраивать. Разрешите творить гадости вашим пользователям в течении дня, потом препроводите этот день. Всё остальное - сторнированием. Уверяю, и вы и ваше начальство со временем с этим смирится - не враги же они своему бизнесу. И не нужно изобретать ИТ-велосипеды в сфере учёта, всё уже давно изобретено.

"Остатки нужно контролировать, если есть изменения задним числом - факт. Другой вопрос что их нужно контролировать не только на момент времени, но и на текущую дату. Тут без перепроведения последовательностей не обойтись. А это уже великие тормоза ." Бред. Есть методики без тормозов... Просто все методики "а ля 1С" - ориентированы на ГП и перепроведение. Так проще разработчику... Это пример решения проблемы. Не самый хороший, тормозной - но решения. Опять таки через перепроведение. Такое решение предусмотрено идеологией 8-ки... где можно отслеживать такое.... Есть еще решение: подождать выхода 8.1 - если там тормозов и блокировок небудет, то вы можете спокойно проверять остатки в ОбработкеПроведения. Бред сивого мерина в ясную лунную ночь Ты фантастические романы не пишешь? Будь проще - и люди к тебе потянутся.... Не бизнес работает на ИТ, а ИТ работает на бизнес... И бизнес платит деньги... Если ты не можешь решить проблемы - бизнес не платит.    А заднее число возникает не только из-за ошибок - иногда оформление сделки задним числом дает возможность вполне законно сэкономить... А ты запрещаешь это оформление...

Нормального решения в ветке никто не предложил Только "в стиле 1С" - с трахом... P.S. изучайте другие системы, даже поганые - там есть изюминки... В частности, есть решения проблемы ...

Будь проще - и люди к тебе потянутся.... Не бизнес работает на ИТ, а ИТ работает на бизнес... И бизнес платит деньги... Если ты не можешь решить проблемы - бизнес не платит. А заднее число возникает не только из-за ошибок - иногда оформление сделки задним числом дает возможность вполне законно сэкономить... А ты запрещаешь это оформление... -------- Я не вендор, я работник/участник в этом самом бизнесе. Посему, у вас может быть другой взгляд на эти процессы. Моё ит-подразделение работает совместно с бизнесом бок о бок. Собственно, я - тоже часть "топ-менеджеров". Посему, вопрос стоит так: вам (бизнесу) нужны реальные данные? 1. да - не допускайте решений, противоречащих идеологии информационной системы и здравого смысла. 2. нет, не важны/мы готовы терпеть “липовые” цифры - готовьтесь сводить месяц в течение следующего месяца. При любом из этих вариантов основной бизнес несёт потери. Но потери в первом варианте можно свести к минимуму налаживанием нормальных бизнес - процессов, повышением квалификации пользователей. Во втором потери неуправляемы и непредсказуемы. 1С УТ предлагает как раз этот выбор. А уж то, что вы выбираете – вопрос вашей корпоративной религии. А вот выполнять любые пожелания руководства – это к хотабычу, а не ит-отделу. Ps.: Конечно же, всё это только если ваш наниматель не относится к криминалу или около. Там свои правила. Но там совсем и не до учёта.

"У лю 427: P.S. изучайте другие системы, даже поганые - там есть изюминки..." - ну и дай наводку, чего из пустого в порожнее переливашь?

"Посему, вопрос стоит так: вам (бизнесу) нужны реальные данные? 1. да - не допускайте решений, противоречащих идеологии информационной системы и здравого смысла. 2. нет, не важны/мы готовы терпеть “липовые” цифры - готовьтесь сводить месяц в течение следующего месяца. При любом из этих вариантов основной бизнес несёт потери. Но потери в первом варианте можно свести к минимуму налаживанием нормальных бизнес - процессов, повышением квалификации пользователей. Во втором потери неуправляемы и непредсказуемы." "1.  да - не допускайте решений, противоречащих идеологии информационной системы и здравого смысла. " Неверные акценты... Сначала должен быть здравый смысл, потом идеология информационной системы... Если идеология ИС ущербна - не надо натягивать бизнес на нее, ИС... Идеология 1С только частично соответствует здравому смыслу - она сделана ради наличия самой системы... и весьма оторвана от бизнеса. Хотя и есть определенное соответствие жизни...   Если выкинуть ошибки юзеров, то заднее число все равно требуется - либо ради оптимизации налогов, либо для согласования дейсвий продавца/покупателя. Западные системы решают это через простое сторно и повторный ввод правильной инфы (плюсы - аудиторский след). 1С решает через перепроведение... Другие разработчики - решают другими методами... "2. нет, не важны/мы готовы терпеть “липовые” цифры - готовьтесь сводить месяц в течение следующего месяца." Вообще говоря, неверно... говоря другими словами - -либо мы жестко регламентируем работу и в случае исключений неимоверно трахаемся (вариант с запретом заднего числа и перепроведение), -либо мы занимаемся разгильдяйством в отчетном периоде и только по окончанию выправляем результаты... На самом деле есть третий путь -  можно весьма значительно ослабить жесткость за контролем действий пользователя (допустив определенное размиздяйство)  и СРАЗУ иметь корректные результаты...   для этого нужно много думать. Чтобы создать дуракоустойчивую и размиздяйствоустойчивую ИС. Идеи такой ИС давно известны - хороших реализаций очень мало... Причины этого тоже известны... хочет и рыбку съесть и чешую продать да еще и заработать... Флаг в руки - но пока успехов не видно... P.S. кстати, идеология с перепроведением для восстановления ГП (и партионного учета) несет в себе свинью - при вставке/правке дока задним числом не факт, что распределение по партиям пройдет успешно (и вообще возможно) - поплывут партии.  Если рентабельность сделок считалась от себестоимости партий в наличии - можно пролететь...  Для исправления последнего недостатка в рамках модели от 1С надо разделять учет по количеству и партиям. В случае же третьего критерия (неизменности уже отданных пользователю характеристик товаров) - нужен еще один учет (по сериям). Такая проблема имеется при учете по серийным номерам или акцизным маркам.  В результате этого усложняется проведение - система становится критичной ко времени проведения... Однако можно соединить все требования в одно и ... упростить систему, облегчив проведение...

пошел в сад... Тебе надо - либо ты ищешь сам, либо нанимаешь человека и он ищет... Нахаляву - мы все мастера...

Вообще то это коммерческая информация и неслабо стоит... Целые конторы неплохо живут на грамотных сравнительных обзорах...

Жмот

Какие могут быть варианты решения: 1. Вести учет исключительно оперативно, не вносить документы в предыдущих датах. Если нужны какие либо корретировки, то вносить их тоже оперативно. 2. Если допустить внесения движений "задним числом", то тогда нужен пересчет (перепроведение) последующих движений. Если реализовать это "с умом", то можно минимизировать кол-во проведений и перепрведений. Операция восстановления последовательности можно осуществлять во время наименьшей загруженности системы. 3. Разрешить внесение данных неоперативно, но при записи движений проверять все последующие списания. Это самый затратый по производительности способ. Например, собираемся списать с какой либо партии некое кол-во, проверям все списания от документа до текущей даты. Если залазим по этой партии в минус, то выбираем следующую партию для списания. 4. В случе партионного учета, то отказаться от партий и вести учет по средневзвешанной. Сбестоимость считать в конце месяца, по результатам дейятельности за месяц. Что забыл?

почему жмот? Если я потратил на изучение месяц, затратив время и деньги - почему ты это должен получить бесплатно? не совсем так... Нереально. Иногда ошибки всплывают через неделю - две.. "2. Если допустить внесения движений "задним числом", то тогда нужен пересчет (перепроведение) последующих движений. Если реализовать это "с умом", то можно минимизировать кол-во проведений и перепрведений. Операция восстановления последовательности можно осуществлять во время наименьшей загруженности системы." Это подход 1С. При арифметическом прогрессии возрастании количества "задних" чисел геморой растет растет в геометрической. В некоторый момент геморой стопорит систему.. на восстановление ГП уходит больше времени и сил, чем на основную работу "3. Разрешить внесение данных неоперативно, но при записи движений проверять все последующие списания. Это самый затратый по производительности способ. Например, собираемся списать с какой либо партии некое кол-во, проверям все списания от документа до текущей даты. Если залазим по этой партии в минус, то выбираем следующую партию для списания." Если сумеешь "просчитать" движения быстро - тогда метод полетит. Работоспособный метод. Может применяться как для себестоимости, так и при некоторой модификации для учета по серийникам. 4. В случе партионного учета, то отказаться от партий и вести учет по средневзвешанной. Сбестоимость считать в конце месяца, по результатам дейятельности за месяц.   точная себестоимость за месяц будет известна в конце месяца... В течении месяца, если делать отчет от начала месяца до последнего дока за этот месяц - будет некая "текущая" средневзвешенная оперативно. Которая в условиях равномерной инфляции будет достаточно точной...   Метод не работает в условиях кризиса (по образцу 1998 года), когда цены закупки менялись очень быстро. В этом случае нужно вести учет либо в стабильной валюте, либо постоянно переоценивать хранимые запасы...

Имхо это америкозная/еврейская философия. Очень простой (буквально несколько строчек кода) контроль остатков делается через события (штатный механизм 7.7/8.0). Пример на 7.7

(+87) При этом массовое перепроведение не натыкается на ошибки, и никоим образом не замедляется.

все не читал, но правильней всего править не задним числом , а текущими документами ИМХО.

+Соответственно с этим запрещать неоперативное проведение, а все исправления вносить текщим числом.

эта методика известна, ее использует зарубежное ПО. имеет достоинства и недостатки P.S. но иногда "заднее" число - это не исправление, а новые документы... Тут эта методика прокалывается...

Да то главная проблема в этой методике :(

как вариант, достаточно трудоёмкий (для меня, в крайнем случае): снимать изменения регистров и заносить эту инфу в особые, корректировочные регистры количеств/стоимости текущей датой (типа, авто-сторно). в таком варианте получить точную информацию на любой момент нельзя, но можно на момент "неправильного" документа и на текущий, что более важно. в большинстве случаев этого достаточно. безусловно, вся система утяжелится. помоему, это единственно возможный вариант.

В семерке работа задним числом с расчетом остатков и контролем их на текущий момент делается как два пальца об асфальт. Тоже самое можно сделать и в восьмерке. Некер было тока систему раздувать.

оказывается v8 еще поганее чем v77, а франчи гады еще агитируют с 77 на 8 перейти. побольше денег хотят срубить. Вообще не надо было нам на 1С переходить работали бы без проблем на старой программе как раньше.. под ДОС.

попал... в ЖПО пальцем... думать надо... и все получится...

она не лучше и не хуже... Она такая же - принципы те же...