gifts2017

Механизм прогнозирования отрицательных остатков по произвольному регистру

Опубликовал Иван Белокаменцев (1c-intelligence) в раздел Администрирование - Системное

Подключаемый механизм, позволяющий прогнозировать возникновение отрицательных остатков по любому остаточному регистру в любой конфигурации на платформе 1С 8.2

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

 

В составе:

  1. Справочник настроек контроля (итНастройкиПрогнозированияОтрицательныхОстатков);

  2. Регистр сведений для указания актуальной настройки контроля (итРегистрыДляПрогнозированияОтрицательныхОстатков);

  3. Общий модуль с двумя процедурами (эти процедуры можно включить в любой другой модуль, и подписку тоже свою использовать).

Как настраивать:

  1. В настройке контроля указывается регистр, перечисляются измерения и ресурсы, по которым контролировать (там флажки есть). Бантиков пока мало, имя регистра вписывается руками. Измерения и ресурсы можно заполнять.
    Флажки там не просто так:
    • - по ресурсам понятно - не все их нужно контролировать онлайн
    • - по измерениям - на всякий случай, при работе онлайн бывает, что не требуется полное закрытие в ноль. Например, для заказов поставщикам - измерение цена, можно закрыть потом, все разом.
  2. Там же, в настройке, после п. 2 надо нажать кнопку "Сформировать тексты запросов" - они там же и появятся, в форме. Их можно корректировать (пока).

  3. В регистре сведений нужно еще раз написать имя регистра, указать настройку и поставить флаг.

  4. Не включил в конфигурацию подписку на событие, чтобы к метаданным не привязываться. Подойдет любая подписка для регистра накопления, событие - перед записью. Нужно настроить, чтобы она смотрела на процедуру итПередЗаписьюРегистраПрогнозированиеОтрицательныхОстатковПередЗаписью из общего модуля. Само действие выделено в отдельную процедуру, чтобы замер производительности по процедуре делать.

По настройке - все. Контроль начинает действовать.

Как работает:

  1. Перед записью набора в регистр сравниваются его старый и новый вариант. Сравнение делается одним запросом, который сформировался в настойке контроля (см п.2 настройки, "Текст запроса уменьшения по ресурсам");

  2. Если уменьшения нет, на этом все прекращается. Уменьшение - это когда уменьшается или распроводится приход, либо увеличивается расход.

  3. Если есть уменьшение, то идем дальше. Выполняется второй запрос, который использует временные таблицы первого запроса - осуществляется проверка остатков по регистраторам от даты документа до текущей даты.
    В текущем варианте проверяются как остатки до изменения, так и остатки после изменения, т.к. в результат попадут и отрицательные остатки, в которых мы не виноваты. Это сделано намеренно, задел на будущее. Можно убрать, удалив условие из запроса "Текст запроса выборки регистраторов" в настройке.

  4. На выходе получается таблица с регистраторами и всеми контролируемыми измерениями, а также с остатками до и после изменения. Сейчас пока все, это последняя строка процедуры.

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

Также есть планы добавить функционал:

  1. Отбор, чтобы все подряд контролировать;

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

  3. Сделать форму (или обработку), которая будет открываться толковому пользователю, чтобы он увидел всю цепочку и мог, например, на время отключить контроль остатков для себя и привести эту цепочку к требуемому виду.

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

На всякий случай прикладываю cf, вдруг кому интресно. Платформа 8.2.13.219, тестировалось на УПП 1.3.12.1.

P.S. Проводил замер производительности: включил контроль по регистру ТоварыНаСкладах, перепровел складские документы за месяц - получилось 1.5 % времени уходило на весь контроль. Не знаю, много это или мало. Также буду признателен, если кто-нибудь разбирающийся в оптимальности запросов, глянет мои запросы и подскажет, где там есть неоптимальность.

Скачать файлы

Наименование Файл Версия Размер
Конфигурация 76
.cf 19,44Kb
26.08.14
76
.cf 19,44Kb Скачать

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение
Комментарии
1. Misha ⁠ (Magister) 04.10.11 15:57
Однозначно плюс за подробное описание и реализацию.
Нужно попробовать внедрить себе :)
1c-intelligence; +1 Ответить
2. Артур Аюханов (artbear) 04.10.11 16:13
Интересная идея, нужно обдумать плюсы и минусы.
1c-intelligence; +1 Ответить
3. Антон Чарушкин (hulio) 05.10.11 07:35
artbear пишет:
плюсы и минусы

Да простит меня автор, но минус могу сходу подсказать :)
На примере 10-й торговли: проводим документ "Резервирование товаров", по логике автора уменьшения нет (ну правильно, мы ведь увеличили количество в резерве), а по логике программы - на свободном остатке может образоваться "минус" - если количество в резерве превысит количество на складе.

Справедливости ради, стоит заметить, что в новых конфигурациях есть отдельный регистр - "Свободные остатки". ПО нему такой контроль вполне сработает :)
4. zaebunga (1c-intelligence) 05.10.11 07:45
(3) hulio,

Это скорее минус УТ 10.

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

Что скажете?
5. olga pt (pt_olga) 07.10.11 22:41
не уловила смысла этого творения, хоть и достаточно внушительного. Зачем заниматься прогнозом отрицательных остатков, если можно их просто не допускать?
6. zaebunga (1c-intelligence) 08.10.11 16:34
(5) pt_olga, в этом и смысл - спрогнозировать возникновение отрицательных остатков и не допустить его. Согласитесь, чтобы не допустить, надо сначала спрогнозировать.
7. Денис (1cspecialist) 09.10.11 16:32
(0) Идея не нова - в свое время она не раз поднималась в конференции разработчиков 1с (partners.v8.1c.ru). Автор молодец, что попытался ее реализовать. Но как обычно в жизни бывает - есть большое НО.
Подскажите, как решается проблема с перепроведением например документа ПТиУ? Именно с "перепроведением", т.к. именно в этом случае предложенный способ контроля не сработает (для просто "проведения" или "отмены проведения" сработает), или убедите меня в обратном.
Поясню.
Не для кого не секрет, что в случае перезаписи набора записей регистра (например, в случае перепроведения документа) происходит не одна, а две итерации записи. Первая - очищает (удаляет) текущие записи (производится запись пустого набора), вторая записывает новый набор записей в регистр. Я посмотрел код этой разработки. В процедуре "ПередЗаписью" модуля набора записей регистра производится сравнение записываемого набора с текущими записями регистра. Тут-то и произойдет ошибка на первой итерации. Ведь записываемый набор записей придет пустой, что фактически для данного контроля будет означать, что уменьшили приход и соответственно могут быть отрицательные остатки в будущих расходных накладных.
8. olga pt (pt_olga) 09.10.11 23:17
zaebunga пишет:

(5) pt_olga, в этом и смысл - спрогнозировать возникновение отрицательных остатков и не допустить его. Согласитесь, чтобы не допустить, надо сначала спрогнозировать.


если "прогноз" заменить на "проверку" возможности списания, то соглашусь.
Дело в том,что специфика моей работы подразумевает постоянную работу по отгрузке дефицитных товаров,
т.е. отделы продаж на перегонки резервируют появившийся на складе товар.
Как таковой прогноз нам не нужен, тут к гадалке не ходи, что через час разметут.))

Оперируем механизмами по недопущению вылета в минус.
9. розница.net (ZLENKO) 22.05.12 18:26
(7) Вот именно что основная фишка этого метода в том чтобы он корректно работал при проведении, отмене проведения и перепроведении.
Особенно учитывая то что в типовых конфигурациях при перепроведении регистры товарных остатков очищаются чтобы обеспечить корректность контроля остатков.
А при применении этого метода штатный контроль остатка уже не нужен, т.е. и очистку существующих движений можно убрать. Таким образом достигается оптимизация записи регистров при перепроведении о которой 1С так много писали, но по факту она в типовых так и не реализована (точнее реализована но не используется). Но при убирании очистки появляются проблемы наличия движений у непроведенных документов (при неудачной попытке проведения и последующей просто записью).
А плюс ко всему этому заказчик для некоторых документов захотел разрешить возникновение минусов и соответственно пришлось разрешить даже если минус есть но это приход и минус ним уменьшается, а если расход и минус увеличивается то запретить. Вот такая вот у меня эпопея с этим методом была.
То что тут у автора к сожалению не смотрел - сейчас мне не актуально.
10. Денис Денисов (koladen) 27.06.13 11:45