Итак, механизм, который прогнозирует (или контролирует) возникновение отрицательных остатков при изменении движений по любому остаточному регистру.
В составе:
-
Справочник настроек контроля (итНастройкиПрогнозированияОтрицательныхОстатков);
-
Регистр сведений для указания актуальной настройки контроля (итРегистрыДляПрогнозированияОтрицательныхОстатков);
-
Общий модуль с двумя процедурами (эти процедуры можно включить в любой другой модуль, и подписку тоже свою использовать).
Как настраивать:
- В настройке контроля указывается регистр, перечисляются измерения и ресурсы, по которым контролировать (там флажки есть). Бантиков пока мало, имя регистра вписывается руками. Измерения и ресурсы можно заполнять.
Флажки там не просто так:- - по ресурсам понятно - не все их нужно контролировать онлайн
- - по измерениям - на всякий случай, при работе онлайн бывает, что не требуется полное закрытие в ноль. Например, для заказов поставщикам - измерение цена, можно закрыть потом, все разом.
-
Там же, в настройке, после п. 2 надо нажать кнопку "Сформировать тексты запросов" - они там же и появятся, в форме. Их можно корректировать (пока).
-
В регистре сведений нужно еще раз написать имя регистра, указать настройку и поставить флаг.
-
Не включил в конфигурацию подписку на событие, чтобы к метаданным не привязываться. Подойдет любая подписка для регистра накопления, событие - перед записью. Нужно настроить, чтобы она смотрела на процедуру итПередЗаписьюРегистраПрогнозированиеОтрицательныхОстатковПередЗаписью из общего модуля. Само действие выделено в отдельную процедуру, чтобы замер производительности по процедуре делать.
По настройке - все. Контроль начинает действовать.
Как работает:
-
Перед записью набора в регистр сравниваются его старый и новый вариант. Сравнение делается одним запросом, который сформировался в настройке контроля (см п.2 настройки, "Текст запроса уменьшения по ресурсам");
-
Если уменьшения нет, на этом все прекращается. Уменьшение - это когда уменьшается или распроводится приход, либо увеличивается расход.
-
Если есть уменьшение, то идем дальше. Выполняется второй запрос, который использует временные таблицы первого запроса - осуществляется проверка остатков по регистраторам от даты документа до текущей даты.
В текущем варианте проверяются как остатки до изменения, так и остатки после изменения, т.к. в результат попадут и отрицательные остатки, в которых мы не виноваты. Это сделано намеренно, задел на будущее. Можно убрать, удалив условие из запроса "Текст запроса выборки регистраторов" в настройке. -
На выходе получается таблица с регистраторами и всеми контролируемыми измерениями, а также с остатками до и после изменения. Сейчас пока все, это последняя строка процедуры.
Дальше уже начинаются вариации, как интерпретировать полученную информацию. Думаю добавить регистр с настройками по пользователям, кому можно кому нельзя создавать отрицательные остатки.
Также есть планы добавить функционал:
-
Отбор, чтобы все подряд контролировать;
-
Возможность задавать параметры действий в случае обнаружения отрицательных остатков. Хотя бы текст сообщения задать, или вопрос какой-то спросить.
-
Сделать форму (или обработку), которая будет открываться толковому пользователю, чтобы он увидел всю цепочку и мог, например, на время отключить контроль остатков для себя и привести эту цепочку к требуемому виду.
Также есть мысль расширить поиск отрицательных остатков и на сам проводимый документ, т.е. вместо обычного в таких случаях запроса на наличие остатков делать один запрос текущее + прогнозируемое.
На всякий случай прикладываю cf, вдруг кому интресно. Платформа 8.2.13.219, тестировалось на УПП 1.3.12.1.
P.S. Проводил замер производительности: включил контроль по регистру ТоварыНаСкладах, перепровел складские документы за месяц - получилось 1.5 % времени уходило на весь контроль. Не знаю, много это или мало. Также буду признателен, если кто-нибудь разбирающийся в оптимальности запросов, глянет мои запросы и подскажет, где там есть неоптимальность.
