На что влияет желаемая дата отгрузки в заказе клиента и почему заказы становятся просроченными в 1С:УТ 11?

← На главную

При работе с документами Заказ клиента в конфигурации «1С:Управление торговлей 11» (а также в «1С:КА 2» и «1С:ERP») пользователи и разработчики нередко сталкиваются с ситуацией, когда вчера созданные заказы сразу же подсвечиваются красным как просроченные. При этом реквизит Желаемая дата отгрузки часто остается незаполненным либо его изменение визуально не сдвигает колонку Срок выполнения в списке заказов. Разберем подробно, за что отвечает этот реквизит, как система вычисляет дату просрочки и как правильно автоматизировать закрытие неактуальных заказов клиентов.

Назначение реквизита «Желаемая дата отгрузки»

Реквизит шапки ЖелаемаяДатаОтгрузки фиксирует исходное пожелание покупателя: к какому числу он ожидает поставку товаров или оказание услуг. Этот реквизит носит ориентировочно-плановый характер и напрямую не является жестким дедлайном исполнения заказа. Проанализируем, где и как он задействован в типовых механизмах конфигурации:

Обработка «Состояние обеспечения» и расчет дат отгрузки. При анализе потребности рабочего места обеспечения или при вызове команды «Обеспечение → Заполнить обеспечение» система сопоставляет желаемую дату с возможностями поставки. Дата готовности к отгрузке в строках рассчитывается по правилу: максимальная дата между желаемой датой отгрузки и фактической датой поступления/резерва. Если товар есть на складе в свободном остатке, дата отгрузки строки будет зафиксирована именно на желаемую покупателем дату.
Планирование складских операций. Желаемая дата позволяет логистической и складской службам заранее планировать график сборки и упаковки товаров, оценивать пиковые нагрузки на зоны отгрузки и распределять рабочую силу склада во избежание простоев и авралов.
Формирование заказов поставщикам. При расчете потребностей под обеспечение заказов система ориентируется на срок потребности, базирующийся на желаемой дате, чтобы вовремя инициировать закупку у поставщика.

Как рассчитывается колонка «Срок выполнения» и почему заказ становится просроченным

Выясним причину, по которой вчерашний заказ сразу отображается просроченным. Колонка Срок выполнения в списке заказов не берется напрямую из реквизитов шапки Дата или ЖелаемаяДатаОтгрузки. Она вычисляется и хранится в ресурсе ДатаСобытия непериодического независимого регистра сведений СостоянияЗаказовКлиентов.

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

Этап ожидания оплаты (аванс или предоплата). Если заказ ожидает оплаты, ДатаСобытия заполняется из даты платежа строки предоплаты в табличной части ЭтапыГрафикаОплаты. Если график оплаты не заполнен детально (например, отсрочка равна 0 дней от даты заказа), программа выставляет плановую дату оплаты равной дате создания документа. На следующий календарный день срок платежа считается нарушенным, и весь заказ подсвечивается как просроченный.
Этап согласования. В состоянии Ожидается согласование контролируется дата согласования, которая по умолчанию также приравнивается к дате создания заказа.
Этап обеспечения и отгрузки. В состояниях Готов к отгрузке или В процессе отгрузки значение ДатаСобытия определяется реквизитом ДатаОтгрузки строк табличной части Товары (берется минимальная плановая дата неотгруженных строк). Если строки не были распределены по датам или дата отгрузки строк совпадает с датой документа, отгрузка признается просроченной сразу после наступления следующего дня.

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

Типовые способы управления сроками выполнения

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

Настройка этапов графиков оплаты. В типовых или индивидуальных соглашениях с клиентами (либо в самом заказе по гиперссылке расчетов) необходимо задавать правила оплаты со смещением. Например, «Аванс (до обеспечения): отсрочка 3 дня» или «Кредит (после отгрузки): 5 дней». Тогда строки этапов оплаты автоматически получат корректную дату платежа в будущем, отодвигая ДатаСобытия на соответствующий срок.
Использование функциональной опции дат отгрузки. В настройках продаж можно включить признак указания дат отгрузки (в шапке и в табличной части). При заполнении согласованной даты отгрузки система синхронизирует строки табличной части, что предотвратит переход заказа в статус просроченного до наступления этой плановой даты.

Разработка регламентной обработки по закрытию просроченных заказов

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

Разберем по шагам правильный алгоритм регламентной отмены и закрытия:

Выбираем заказы, у которых дата документа с учетом допустимого интервала ожидания меньше текущей даты, при этом отсутствуют фактические движения по оплате и отгрузке.
Для снятия зарезервированного товара недостаточно просто установить статус Закрыт в шапке документа. При проведении сработает контроль, требующий завершения процессов отгрузки.
Необходимо программно обойти строки табличной части Товары, установить в неотгруженных строках флаг Отменено = Истина и заполнить реквизит ПричинаОтмены ссылкой на элемент соответствующего справочника.
После отмены строк переводим статус заказа в значение Закрыт и проводим документ в режиме РежимПроведенияДокумента.Неоперативный. Это снимет все резервы и корректно обновит состояние в регистре сведений.

Посмотрим на пример процедуры закрытия неактуального заказа клиента:


Процедура ЗакрытьНеактуальныйЗаказ(СсылкаНаЗаказ, ПричинаОтмены) Экспорт

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

КонецПроцедуры

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