Как реализовать механизм изменения заказов только через корректировки

← На главную

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

Вариант 1. Использование штатного механизма корректировок (логика УТ 10.3 и УПП)

В конфигурациях «старой школы» (например, «Управление торговлей 10.3») существовал отдельный документ КорректировкаЗаказаПокупателя. Разберем принцип его работы, так как это идеальная модель для тех, кто хочет видеть «дельту» изменений. Проанализируем, как это устроено:

Запрет редактирования: При проведении основного заказа или смене его статуса на «Принят», документ блокируется для изменения.
Ввод корректировки: На основании заказа создается документ КорректировкаЗаказаПокупателя. В нем указывается, какие позиции добавляются, а какие удаляются или уменьшаются.
Движения по регистрам: Корректировка не переписывает движения заказа, а делает дополнительные записи в регистры накопления (например, ЗаказыПокупателей). Если мы уменьшаем количество товара на 2 штуки, документ делает движение «-2».

Такой подход позволяет в любой момент сформировать отчет и увидеть: «Первоначальный заказ: 10 шт., Корректировка №1: -2 шт., Корректировка №2: +5 шт. Итого к отгрузке: 13 шт.».

Вариант 2. Программная блокировка редактирования формы

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

В модуле формы документа ЗаказКлиента в процедуре ПриЧтенииНаСервере или ПриОткрытии пропишем проверку статуса:


&НаСервере
Процедура ЗаблокироватьФормуЕслиНужно()
    
    // Проверяем, что документ проведен и находится в статусе, запрещающем правку
    Если Объект.Проведен И (Объект.Статус = Перечисления.СтатусыЗаказовКлиентов.КОтгрузке 
        Или Объект.Статус = Перечисления.СтатусыЗаказовКлиентов.Закрыт) Тогда
        
        // Устанавливаем только чтение для всей формы
        ТолькоПросмотр = Истина;
        
        // Или блокируем только табличную часть
        Элементы.Товары.ТолькоПросмотр = Истина;
        
    КонецЕсли;
    
КонецПроцедуры

Однако просто «закрыть» документ мало. Проанализируем ситуацию: что делать, если склад еще не собрал товар, а клиент позвонил и попросил изменить заказ? В этом случае мы можем разрешить редактирование только через специальную кнопку «Создать корректировку», которая будет программно менять статус заказа назад или открывать помощник внесения изменений.

Вариант 3. Современный подход: Причины отмены и Версионирование

В современных конфигурациях на платформе «1С:Предприятие 8.3» (УТ 11, ERP 2.5) вместо создания кучи документов-корректировок рекомендуется использовать механизм Версионирования и Причин отмены строк. Рассмотрим этот алгоритм по шагам:

Включение версионирования: Перейдем в раздел «НСИ и администрирование» — «Общие настройки» — «История изменений». Установим для документа Заказ клиента режим «Версионировать при проведении».
Отказ от позиций: Вместо удаления строки из заказа, менеджер должен установить флаг «Отменено» и выбрать причину (например, «Инициатива клиента»). Это сохраняет строку в базе, и мы всегда видим, что клиент изначально хотел эту позицию.
Сравнение версий: В любой момент руководитель может нажать кнопку «История изменений» и увидеть сравнение текущего заказа с версией часовой давности. Система подсветит измененные реквизиты и строки ТЧ.

Вариант 4. Реализация через расширение (для Управляемых форм)

Если бизнес-процесс требует именно отдельный документ-корректировку, рассмотрим создание расширения. Нам потребуется новый документ ИзменениеЗаказа, который будет содержать две табличные части: «Старые данные» и «Новые данные». Посмотрим на пример кода, который будет переносить данные из корректировки в основной заказ после согласования:


&НаСервере
Процедура ПрименитьКорректировкуКЗаказу(ДокументКорректировка)
    
    ЗаказОбъект = ДокументКорректировка.ДокументОснование.ПолучитьОбъект();
    
    // Блокируем объект заказа для записи
    ЗаказОбъект.Заблокировать();
    
    // Очищаем товары и загружаем новые данные из корректировки
    ЗаказОбъект.Товары.Очистить();
    Для Каждого СтрокаНовыхДанных Из ДокументКорректировка.ТоварыЦикл
        ЗаполнитьЗначенияСвойств(ЗаказОбъект.Товары.Добавить(), СтрокаНовыхДанных);
    КонецЦикла;
    
    // Записываем заказ, обходя проверки (если нужно)
    ЗаказОбъект.Записать(РежимЗаписиДокумента.Проведение);
    
КонецПроцедуры

Важный момент: При таком подходе необходимо обеспечить транзакционность. Если заказ уже начал отгружаться (созданы связанные документы РасходныйОрдерНаТовары или РеализацияТоваровУслуг), система должна выдать ошибку. Проанализируем связи документов через критерий отбора СвязанныеДокументы.

Организационный «Момент отсечки»

Как отмечалось в обсуждении на форуме, никакая автоматизация не поможет, если не определен «момент отсечки». Рассмотрим типовую схему:

Статус «Согласован»: Менеджер может править заказ.
Статус «К отгрузке» (Передан на склад): Документ блокируется. Любое изменение требует «отката» статуса.
Создано «Задание на сборку»: Полный запрет изменений. Если нужно что-то поменять — склад должен сначала «расформировать» сборку в системе, и только потом заказ станет доступен для корректировки.

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

Резюме

Для реализации контроля изменений заказов рекомендуем следующее:

Использовать штатное версионирование для хранения истории правок (кто, когда и что изменил).
Настроить запрет редактирования через механизм «Даты запрета изменений» или через проверку статусов в модуле формы.
Внедрить механизм причин отмены строк вместо физического удаления позиций из табличной части документа.
Синхронизировать статусы заказа с процессами склада. Изменение заказа не должно быть возможно, если по нему уже открыта складская операция.

Выяснив причину частых корректировок (будь то нерасторопность менеджеров или неопределенность клиентов), вы сможете выбрать наиболее подходящий технический инструмент: от жестких запретов в коде до мягкого логирования изменений через версионирование.