Прогнозирование работает при любом изменении регистра — проведении/отмене проведения документа, изменении проведенного документа.
Итак, механизм, который прогнозирует (или контролирует) возникновение отрицательных остатков при изменении движений по любому остаточному регистру.
В составе:
-
Справочник настроек контроля (итНастройкиПрогнозированияОтрицательныхОстатков);
-
Регистр сведений для указания актуальной настройки контроля (итРегистрыДляПрогнозированияОтрицательныхОстатков);
-
Общий модуль с двумя процедурами (эти процедуры можно включить в любой другой модуль, и подписку тоже свою использовать).
Как настраивать:
- В настройке контроля указывается регистр, перечисляются измерения и ресурсы, по которым контролировать (там флажки есть). Бантиков пока мало, имя регистра вписывается руками. Измерения и ресурсы можно заполнять.
Флажки там не просто так:- — по ресурсам понятно — не все их нужно контролировать онлайн
- — по измерениям — на всякий случай, при работе онлайн бывает, что не требуется полное закрытие в ноль. Например, для заказов поставщикам — измерение цена, можно закрыть потом, все разом.
-
Там же, в настройке, после п. 2 надо нажать кнопку «Сформировать тексты запросов» — они там же и появятся, в форме. Их можно корректировать (пока).
-
В регистре сведений нужно еще раз написать имя регистра, указать настройку и поставить флаг.
-
Не включил в конфигурацию подписку на событие, чтобы к метаданным не привязываться. Подойдет любая подписка для регистра накопления, событие — перед записью. Нужно настроить, чтобы она смотрела на процедуру итПередЗаписьюРегистраПрогнозированиеОтрицательныхОстатковПередЗаписью из общего модуля. Само действие выделено в отдельную процедуру, чтобы замер производительности по процедуре делать.
По настройке — все. Контроль начинает действовать.
Как работает:
-
Перед записью набора в регистр сравниваются его старый и новый вариант. Сравнение делается одним запросом, который сформировался в настройке контроля (см п.2 настройки, «Текст запроса уменьшения по ресурсам»);
-
Если уменьшения нет, на этом все прекращается. Уменьшение — это когда уменьшается или распроводится приход, либо увеличивается расход.
-
Если есть уменьшение, то идем дальше. Выполняется второй запрос, который использует временные таблицы первого запроса — осуществляется проверка остатков по регистраторам от даты документа до текущей даты.
В текущем варианте проверяются как остатки до изменения, так и остатки после изменения, т.к. в результат попадут и отрицательные остатки, в которых мы не виноваты. Это сделано намеренно, задел на будущее. Можно убрать, удалив условие из запроса «Текст запроса выборки регистраторов» в настройке. -
На выходе получается таблица с регистраторами и всеми контролируемыми измерениями, а также с остатками до и после изменения. Сейчас пока все, это последняя строка процедуры.
Дальше уже начинаются вариации, как интерпретировать полученную информацию. Думаю добавить регистр с настройками по пользователям, кому можно кому нельзя создавать отрицательные остатки.
Также есть планы добавить функционал:
-
Отбор, чтобы все подряд контролировать;
-
Возможность задавать параметры действий в случае обнаружения отрицательных остатков. Хотя бы текст сообщения задать, или вопрос какой-то спросить.
-
Сделать форму (или обработку), которая будет открываться толковому пользователю, чтобы он увидел всю цепочку и мог, например, на время отключить контроль остатков для себя и привести эту цепочку к требуемому виду.
Также есть мысль расширить поиск отрицательных остатков и на сам проводимый документ, т.е. вместо обычного в таких случаях запроса на наличие остатков делать один запрос текущее + прогнозируемое.
На всякий случай прикладываю cf, вдруг кому интресно. Платформа 8.2.13.219, тестировалось на УПП 1.3.12.1.
P.S. Проводил замер производительности: включил контроль по регистру ТоварыНаСкладах, перепровел складские документы за месяц — получилось 1.5 % времени уходило на весь контроль. Не знаю, много это или мало. Также буду признателен, если кто-нибудь разбирающийся в оптимальности запросов, глянет мои запросы и подскажет, где там есть неоптимальность.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Однозначно плюс за подробное описание и реализацию.
Нужно попробовать внедрить себе 🙂
Интересная идея, нужно обдумать плюсы и минусы.
плюсы и минусы
Да простит меня автор, но минус могу сходу подсказать 🙂
На примере 10-й торговли: проводим документ «Резервирование товаров», по логике автора уменьшения нет (ну правильно, мы ведь увеличили количество в резерве), а по логике программы — на свободном остатке может образоваться «минус» — если количество в резерве превысит количество на складе.
Справедливости ради, стоит заметить, что в новых конфигурациях есть отдельный регистр — «Свободные остатки». ПО нему такой контроль вполне сработает 🙂
(3) hulio,
Это скорее минус УТ 10.
Есть также обходной вариант — если смотрели настройку прогнозирования, то там можно корректировать созданный программно запрос. В данном случае нужно усложнить запрос, скучковав все 4 регистра товаров, как это делается в УТ 10 (товары на складах минус в резерве минус к передаче плюс к получению).
Что скажете?
не уловила смысла этого творения, хоть и достаточно внушительного. Зачем заниматься прогнозом отрицательных остатков, если можно их просто не допускать?
(5) pt_olga, в этом и смысл — спрогнозировать возникновение отрицательных остатков и не допустить его. Согласитесь, чтобы не допустить, надо сначала спрогнозировать.
(0) Идея не нова — в свое время она не раз поднималась в конференции разработчиков 1с (partners.v8.1c.ru). Автор молодец, что попытался ее реализовать. Но как обычно в жизни бывает — есть большое НО.
Подскажите, как решается проблема с перепроведением например документа ПТиУ? Именно с «перепроведением», т.к. именно в этом случае предложенный способ контроля не сработает (для просто «проведения» или «отмены проведения» сработает), или убедите меня в обратном.
Поясню.
Не для кого не секрет, что в случае перезаписи набора записей регистра (например, в случае перепроведения документа) происходит не одна, а две итерации записи. Первая — очищает (удаляет) текущие записи (производится запись пустого набора), вторая записывает новый набор записей в регистр. Я посмотрел код этой разработки. В процедуре «ПередЗаписью» модуля набора записей регистра производится сравнение записываемого набора с текущими записями регистра. Тут-то и произойдет ошибка на первой итерации. Ведь записываемый набор записей придет пустой, что фактически для данного контроля будет означать, что уменьшили приход и соответственно могут быть отрицательные остатки в будущих расходных накладных.
pt_olga, в этом и смысл — спрогнозировать возникновение отрицательных остатков и не допустить его. Согласитесь, чтобы не допустить, надо сначала спрогнозировать.
если «прогноз» заменить на «проверку» возможности списания, то соглашусь.
Дело в том,что специфика моей работы подразумевает постоянную работу по отгрузке дефицитных товаров,
т.е. отделы продаж на перегонки резервируют появившийся на складе товар.
Как таковой прогноз нам не нужен, тут к гадалке не ходи, что через час разметут.))
Оперируем механизмами по недопущению вылета в минус.
(7) Вот именно что основная фишка этого метода в том чтобы он корректно работал при проведении, отмене проведения и перепроведении.
Особенно учитывая то что в типовых конфигурациях при перепроведении регистры товарных остатков очищаются чтобы обеспечить корректность контроля остатков.
А при применении этого метода штатный контроль остатка уже не нужен, т.е. и очистку существующих движений можно убрать. Таким образом достигается оптимизация записи регистров при перепроведении о которой 1С так много писали, но по факту она в типовых так и не реализована (точнее реализована но не используется). Но при убирании очистки появляются проблемы наличия движений у непроведенных документов (при неудачной попытке проведения и последующей просто записью).
А плюс ко всему этому заказчик для некоторых документов захотел разрешить возникновение минусов и соответственно пришлось разрешить даже если минус есть но это приход и минус ним уменьшается, а если расход и минус увеличивается то запретить. Вот такая вот у меня эпопея с этим методом была.
То что тут у автора к сожалению не смотрел — сейчас мне не актуально.
Спасибо!