В процессе работы торгового предприятия часто возникает ситуация, когда финансовый отдел (менеджеры) и склад работают в разных темпах. Менеджер может изменить клиента или состав товаров в документе Реализация товаров и услуг, в то время как склад уже распечатал документы и начал сборку по Расходному ордеру на товары. Это приводит к пересортице, ошибкам в первичной документации и логистическим сбоям.
В этой статье мы подробно разберем, почему в типовых конфигурациях (УТ 11, ERP, КА) такая возможность оставлена открытой, какие стандартные механизмы контроля все же существуют и как реализовать жесткую блокировку изменений с помощью расширения.
Для начала проанализируем логику системы. В конфигурациях на базе 1С:УТ 11 связь между складскими и финансовыми документами реализована через распоряжения. Часто основным распоряжением выступает Заказ клиента. С точки зрения системы, Реализация товаров и услуг фиксирует переход права собственности, а Расходный ордер на товары — физическое движение со склада.
Разработчики 1С закладывают определенную гибкость: если менеджер допустил опечатку в номере договора, система не должна полностью блокировать работу склада. Однако в реальности бесконтрольное изменение реквизитов «Партнер» или «Номенклатура» в Реализации, когда ордер уже в работе, недопустимо. Выясним, какими методами мы можем это ограничить.
Прежде чем приступать к программированию, проверим наличие встроенных инструментов. В типовых решениях существует механизм, который следит за тем, чтобы данные в ордерах не расходились с распоряжениями на отгрузку.
Разберем по шагам, как его активировать:
Как это работает: теперь при попытке изменить количество или состав номенклатуры в Реализации товаров и услуг, если по ней уже выписан Расходный ордер на товары, система выдаст ошибку. Она сообщит, что данные финансового документа не соответствуют складскому факту. Однако стоит учесть, что этот механизм «слабо» реагирует на изменение текстовых реквизитов или аналитики, не влияющей на остатки (например, смена подразделения или комментария).
Проанализируем жизненный цикл документа Расходный ордер на товары. Он имеет несколько статусов: Подготовлено, К отбору, В работе, Отобран, К отгрузке, Отгружен.
Логика работы должна быть следующей: если склад перевел ордер в статус «К отгрузке», это означает, что товар упакован, документы ТОРГ-12/УПД распечатаны и лежат в коробке. В этот момент любые изменения в «голове» (Реализации) должны быть запрещены регламентом.
Рассмотрим, как усилить этот контроль через Версионирование объектов:
Реализация товаров и услуг (Администрирование — Общие настройки).Это не запретит изменение напрямую, но позволит администратору или руководителю отдела продаж мгновенно выявить виновного в расхождении данных. Как показывает практика, наличие прозрачного «цифрового следа» дисциплинирует сотрудников не хуже программных запретов.
Если бизнес-процесс требует жесткого запрета («нельзя чихнуть, если склад начал работу»), оптимальным решением будет создание небольшого расширения. Рассмотрим пример кода, который можно внедрить в процедуру ПередЗаписью документа РеализацияТоваровУслуг.
Нам необходимо проверить наличие связанных ордеров в статусах, отличных от «Подготовлено». Разберем пример реализации:
&После("ПередЗаписью")
Процедура ИТ_ПередЗаписьюПроверкаОрдеров(Отказ, РежимЗаписи, РежимПроведения)
// Проверяем, что документ не новый и записывается из формы (или программно с контролем)
Если ОбменДанными.Загрузка ИЛИ ЭтоНовый() Тогда
Возврат;
КонецЕсли;
// Запрос для поиска связанных расходных ордеров
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РасходныйОрдерНаТовары.Ссылка КАК Ордер,
| РасходныйОрдерНаТовары.Статус КАК Статус
|ИЗ
| Документ.РасходныйОрдерНаТовары КАК РасходныйОрдерНаТовары
|ГДЕ
| РасходныйОрдерНаТовары.Распоряжение = &Ссылка
| И РасходныйОрдерНаТовары.Проведен
| И РасходныйОрдерНаТовары.Статус <> ЗНАЧЕНИЕ(Перечисление.СтатусыРасходныхОрдеров.Подготовлено)";
Запрос.УстановитьПараметр("Ссылка", ЭтотОбъект.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
Если НЕ РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Изменение запрещено! По данной реализации создан ордер " + Выборка.Ордер + " в статусе " + Выборка.Статус;
Сообщение.Сообщить();
КонецЦикла;
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Разберем, что делает этот код:
&После), что позволяет не снимать основную конфигурацию с поддержки.Документ.РасходныйОрдерНаТовары, фильтруя их по текущей Реализации (поле Распоряжение).Отказ = Истина, блокируя сохранение изменений в Реализации.Важно понимать, что иногда изменения действительно необходимы (как в примере из темы форума, когда клиент меняет юрлицо в последний момент). Посмотрим, как должен выглядеть правильный бизнес-процесс в системе, если мы ввели запрет:
Реализации.Расходный ордер на товары в статус «Подготовлено» или снимает его с проведения.Реализации снимается, менеджер вносит правки.Такой подход гарантирует, что данные в учетной системе всегда соответствуют тому, что реально происходит на пандусе отгрузки. Мы исключаем ситуацию, когда в программе один контрагент, а в напечатанной накладной у водителя — другой.
Мы выяснили, что стандартная логика 1С:УТ 11 достаточно либеральна к изменениям. Для обеспечения строгого контроля рекомендуется комбинировать стандартную настройку «Контроль соответствия документов распоряжений» с административными мерами (версионирование) или технической блокировкой через расширение. Выбор метода зависит от масштабов вашего предприятия и дисциплины сотрудников.
Помните, что автоматизация — это не только упрощение действий, но и создание «защиты от дурака», которая предотвращает дорогостоящие ошибки в логистике и учете.