← На главную

При адаптации механизмов контроля остатков из современных конфигураций (например, УТ 11 или ERP) в конфигурацию 1С:Управление производственным предприятием 1.3 разработчики часто сталкиваются с техническими сложностями. Типовая логика проведения документов в УПП устроена иначе: при проведении документа регистр партий может перезаписываться несколько раз за одну транзакцию.

Рассмотрим типовую цепочку записи регистра ПартииТоваровНаСкладах при проведении документа ПоступлениеТоваровУслуг:

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

Если мы попытаемся встроить контроль отрицательных остатков в модуль набора записей регистра (события ПередЗаписью или ПриЗаписи), алгоритм выдаст ошибку уже на первом шаге очистки или на промежуточных итерациях, когда итоговая картина движений еще не сформирована. Разберем по шагам, как корректно и с минимальными трудозатратами обойти данное поведение платформы.

Архитектурная проблема проверки в модуле набора записей

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

Для решения этой задачи существует два архитектурных пути:

1. Перенос контроля в обработку проведения документа через подписку на события (рекомендуемый и наименее трудозатратный способ).
2. Использование дополнительных свойств набора записей для подавления промежуточных проверок.

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

Наиболее надежный подход заключается в переносе контрольного алгоритма из модуля набора записей регистра в подписки на события документа: ОбработкаПроведения (или ПриПроведении) и ОбработкаУдаленияПроведения.

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

Разберем по шагам реализацию данного механизма:

1. Создаем подписку на событие для документов поступления/списания на событие ОбработкаПроведения (источник — проверяемые документы).
2. Создаем аналогичную подписку на событие ОбработкаУдаленияПроведения, чтобы предотвратить появление минусов при распроведении приходных накладных задним числом.
3. В обработчике подписки считываем сформированные движения документа по регистру ПартииТоваровНаСкладах.
4. Проверяем, не приводят ли эти движения к отрицательному остатку. Если остаток падает ниже нуля, устанавливаем параметр Отказ = Истина. Вся транзакция проведения или отмены проведения документа целиком откатывается платформой.

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

Важная методическая деталь: расчет остатка задним числом

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

Рассмотрим, как правильно организовать контрольный запрос при проведении или отмене документа задним числом:

1. Необходимо наложить управляемую блокировку данных (БлокировкаДанных) по проверяемым позициям (номенклатура, склад), чтобы исключить параллельное списание другими транзакциями.
2. Запросом анализируется не текущая дата, а временной интервал от даты документа до момента актуальности. Если накопленный итог на каком-либо промежуточном документе становится меньше нуля, проведение должно быть отклонено.

Способ 2. Использование свойства ДополнительныеСвойства набора записей

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

Проанализируем алгоритм с использованием свойств объекта:

1. У набора записей регистра доступна коллекция ДополнительныеСвойства.
2. В типовом коде проведения документа перед промежуточными вызовами метода Записать() устанавливается признак: НаборЗаписей.ДополнительныеСвойства.Вставить("ПромежуточнаяЗапись", Истина);
3. В модуле набора записей в процедуре ПередЗаписью или ПриЗаписи выполняется анализ этого флага:
   Скопировать код

   
   Если НаборЗаписей.ДополнительныеСвойства.Свойство("ПромежуточнаяЗапись") 
      И НаборЗаписей.ДополнительныеСвойства.ПромежуточнаяЗапись Тогда
       Возврат; // Пропускаем проверку, так как данные еще не окончательные
   КонецЕсли;
   
   // Выполняем полноценный контроль остатков
   

Однако данный метод требует вмешательства в типовые общие модули проведения конфигурации УПП 1.3, поэтому использование подписок на события документа остается более предпочтительным и сопровождаемым решением.

Штатная альтернатива: восстановление последовательности партионного учета

Стоит помнить о базовой концепции партионного учета в УПП 1.3. Разработчики конфигурации изначально не закладывали жесткий оперативный запрет на проведение документов задним числом. Архитектура типового решения рассчитана на то, что:

1. При проведении расходных документов списывается доступное количество партий, а на недостающее количество выдается предупреждение.
2. При отмене или изменении поступлений граница последовательности «Партионный учет» автоматически сдвигается назад.
3. Корректность остатков и списания себестоимости восстанавливается пакетно с помощью регламентной обработки «Проведение по партиям», которая останавливается при обнаружении фактической нехватки партий и указывает на проблемный документ.

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