В современных конфигурациях 1С, таких как ERP Управление предприятием, Комплексная автоматизация 2 или Управление торговлей 11, часто возникает ситуация, когда фактическое поступление товаров превышает количество, указанное в заказе. Попытка просто увеличить количество в документе поступления часто приводит к тому, что статус заказа в системе не меняется на «Закрыт», оставаясь в состоянии «Ожидается поступление».
Разберем детально, почему так происходит, как работают внутренние механизмы 1С и какими способами можно выполнить сверку заказа поставщику и его поступлений для решения этой задачи, сохранив логическую целостность системы.
Проанализируем ситуацию, описанную пользователем. При использовании расширения была отключена стандартная проверка, запрещающая приходовать больше, чем заказано. Однако статус заказа в регистре сведений СтатусыЗаказовПоставщикам остался прежним. Чтобы понять причину, нам нужно заглянуть «под капот» системы.
В 1С статус заказа — это не просто значение реквизита в документе. Это расчетная величина, которая зависит от остатков в регистре накопления «Заказы поставщикам». Рассмотрим по шагам, как это работает:
Заказ поставщику создается запись в регистре накопления (приход), фиксирующая нашу потребность в товаре.Приобретение товаров и услуг создается запись в этом же регистре (расход), которая должна «закрыть» потребность.Выясним причину ошибки автора темы: когда количество в поступлении было увеличено вручную (через расширение), типовой программный механизм проведения не «понял», что излишек должен закрывать остатки заказа. В итоге в регистре либо завис остаток, либо возникла «краснота», которую система не интерпретирует как корректное закрытие заказа.
Прежде чем приступать к написанию кода, рассмотрим самый правильный и «чистый» способ решения проблемы, предусмотренный разработчиками 1С. В системе существует штатный механизм работы с отклонениями.
Выполним следующие действия в интерфейсе программы:
Заказ поставщику или в соглашении с поставщиком появится возможность указать процент допустимого отклонения.Преимущества этого метода: система автоматически понимает, что поступление чуть большего количества — это норма. Она корректно сформирует движения по всем регистрам накопления, и статус заказа перейдет в состояние «Закрыт» без какого-либо вмешательства программиста.
Если бизнес-процесс требует именно того поведения, которое описал автор (правка количества в основной строке без деления на «сверх заказа»), нам придется доработать логику формирования движений. Рассмотрим, как это сделать правильно через расширение.
Проблема в том, что при заполнении движений документа ПриобретениеТоваровУслуг, система сопоставляет строки поступления со строками заказа. Если в строке поступления стоит количество 120, а в заказе было 100, то без специальной обработки система спишет из регистра только 100.
Нам необходимо перехватить процедуру сбора данных для движений. Обычно это методы в менеджере документа или специализированных модулях проведения (например, ИнициализироватьДанныеДокумента). Нам нужно добиться того, чтобы при расчете остатков по заказу учитывалось все фактическое количество поступления.
Пример логики для модификации (схематично):
&После("ИнициализироватьДанныеДокумента")
Процедура Расш_ИнициализироватьДанныеДокумента(ТаблицыДокумента, ПараметрыПроведения)
// Находим таблицу, отвечающую за движения по заказам поставщикам
ТаблицаЗаказы = ТаблицыДокумента.ТаблицаЗаказыПоставщикам;
Для Каждого СтрокаТЗ Из ТаблицаЗаказы Цикл
// Если наше фактическое количество больше, чем требуется по заказу,
// принудительно устанавливаем списание в размере всего остатка по заказу
Если СтрокаТЗ.Количество > СтрокаТЗ.ОстатокПоЗаказу Тогда
// Логика корректировки ресурса регистра, чтобы остаток стал 0
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Важно помнить: просто «убрать ругань» недостаточно. Нужно гарантировать, что регистр ЗаказыПоставщикам обнулится.
Рассмотрим еще один вариант, предложенный в обсуждении: автоматическое изменение самого Заказа поставщику при проведении поступления. Несмотря на кажущуюся простоту, этот метод таит в себе серьезные риски, которые мы обязаны проанализировать:
Если вы все же решили идти этим путем, делайте это не в момент проведения, а в подписке на событие ПриЗаписи документа поступления, проверяя режим записи Проведение.
Выясним еще один важный момент: почему в консоли запросов статус в реквизитах документа «Закрыт», а в регистре сведений — нет? В ERP-системах обновление регистра СтатусыЗаказовПоставщикам часто происходит не мгновенно, а с помощью фонового задания.
Проанализируем работу фонового задания «Обновление статусов заказов». Если движения по регистрам накопления после вашего вмешательства стали некорректными (например, появился отрицательный остаток), это фоновое задание может просто «зависать» или игнорировать такие заказы, не переводя их в финальный статус.
Совет: Всегда проверяйте состояние регистров накопления через «Отчеты по остаткам» или универсальный отчет. Если вы видите «хвосты» с минусом или плюсом по вашему заказу — статус никогда не станет «Закрыт» корректно.
Подведем итог. Чтобы успешно реализовать задачу и не сломать систему учета, придерживайтесь следующего алгоритма:
Заказы поставщикам. Остаток по заказу после проведения поступления должен быть строго равен нулю.Помните, что 1С — это сложный механизм взаимосвязанных регистров, и простое отключение проверок («лампочки низкого уровня масла») не решает проблему отсутствия «масла» (корректных данных в базе).