При работе с заказами клиентов в конфигурации 1С:Управление торговлей (в частности, в редакции УТ для Украины 3.1) пользователи часто сталкиваются с ситуацией, когда после выбора действия К обеспечению для отсутствующих на складе товаров состояние всего документа автоматически меняется на «Готов к отгрузке» вместо логичного «Готов к обеспечению». В результате менеджерам приходится вручную заходить в каждый заказ и проверять строки табличной части, чтобы выяснить, действительно ли товар есть в наличии или его требуется заказать у поставщика.
В этой статье мы подробно проанализируем, почему возникает такое поведение системы, чем отличаются ручные статусы от динамических состояний, какова алгоритмическая причина данной проблемы и как правильно организовать работу с обеспечением заказов.
Для правильного понимания механики работы 1С:Управление торговлей разделим два понятия, которые часто путают пользователи:
На согласовании, К выполнению, Закрыт). Он определяет текущий этап жизненного цикла заказа.Расчет состояния зависит от совокупности следующих факторов:
- Установленных действий в строках табличной части (Не обеспечивать, К обеспечению, Резервировать по мере поступления, Резервировать на складе, Отгрузить);
- Условий оплаты (варианты: предоплата, аванс до обеспечения, кредит / оплата после отгрузки);
- Фактического поступления денежных средств по документу;
- Фактического наличия свободных остатков на складе и выписанных документов отгрузки (Реализация товаров и услуг, Расходный ордер).
Рассмотрим стандартную логику, заложенную разработчиками 1С. Предположим, по условиям договора с клиентом выбрана схема «Оплата после отгрузки». Это означает, что с финансовой точки зрения никаких блокеров для работы с документом нет.
В этом случае система должна вести себя следующим образом:
1. Если в табличной части заказа для позиций установлено действие К обеспечению (товара нет на складе, его нужно заказать у поставщика или переместить с другого склада), заказ должен принимать состояние «Готов к обеспечению» (или «Ожидается обеспечение»). Это сигнальный флаг для отдела закупок и логистики о необходимости формирования заказов поставщикам.
2. В состояние «Готов к отгрузке» заказ должен переходить только тогда, когда для товаров установлено действие Отгрузить, позиция физически зарезервирована на складе, а условия предоплаты (если они предусмотрены) полностью выполнены.
Проанализируем ситуацию, описанную пользователями. Почему же в конфигурации УТ для Украины 3.1 статус «Готов к обеспечению» проскакивал, и заказ сразу получал состояние «Готов к отгрузке»?
Причиной является программная ошибка в алгоритме общего модуля УправлениеЗаказамиКлиентов (функция СформироватьСостояниеЗаказа). При вычислении итогового состояния цепочка проверок выполнялась с неверным приоритетом:
1. Программа сначала проверяла финансовые ограничения. Поскольку в заказе было указано «Оплата после отгрузки», финансовая проверка возвращала флаг ОтгрузкаРазрешена = Истина.
2. Далее алгоритм не делал вторичную детальную проверку наличия необеспеченных строк со статусом К обеспечению и сразу присваивал документу итоговое состояние «Готов к отгрузке».
Пример упрощенной схемы логики, содержавшей уязвимость:
// Упрощенный пример ошибочного алгоритма
Если ГрафикОплатыВыполнен И ОтгрузкаРазрешена Тогда
// Ошибка: состояние присваивалось без учета товарного дефицита в строках
РезультатСостояние = Перечисления.СостоянияЗаказовКлиентов.ГотовКОтгрузке;
ИначеЕсли ТребуетсяОбеспечение Тогда
РезультатСостояние = Перечисления.СостоянияЗаказовКлиентов.ГотовКОбеспечению;
КонецЕсли;
В конфигурации УТ 11.3 (для РФ) этот модуль был обновлен ранее, и проверка табличной части на дефицит выполнялась корректно до принятия решения о готовности к отгрузке:
// Исправленная логика расчета состояния
Если ЕстьСтрокиКОбеспечению И НЕ ТоварЗарезервирован(Строка) Тогда
РезультатСостояние = Перечисления.СостоянияЗаказовКлиентов.ГотовКОбеспечению;
ИначеЕсли ГрафикОплатыВыполнен И ТоварГотовКОтгрузке Тогда
РезультатСостояние = Перечисления.СостоянияЗаказовКлиентов.ГотовКОтгрузке;
КонецЕсли;
Данная ошибка была официально зарегистрирована и отправлена разработчикам 1С, после чего ее исправили в последующих обновлениях и релизах линейки BAS (BAS UT / BAS ERP).
Разберем по шагам, как решить эту проблему на практике и организовать эффективный контроль обеспечения заказов.
1. Обновление конфигурации
Самый надежный способ устранения ошибки — обновление конфигурации до актуального релиза. В свежих релизах алгоритм расчета состояний в модуле УправлениеЗаказамиКлиентов Сервер работает корректно.
2. Использование специализированного рабочего места «Состояние обеспечения заказов»
Чтобы менеджерам и логистам не приходилось открывать каждый заказ вручную, рекомендуется использовать штатное рабочее место «Состояние обеспечения заказов» (раздел Продажи или Закупки -> Состояние обеспечения).
Это рабочее место анализирует реальные остатки на складах и потребности по каждой позиции, независимо от текста состояния в журнале документов. В нем четко видно:
- Какое количество товара зарезервировано на складе;
- Какое количество находится в пути (по заказам поставщикам);
- Какой чистый дефицит требуется обеспечить.
3. Проверка этапов оплаты и соглашений
Если обновление конфигурации пока не выполнено, проверьте настройки графика оплаты в заказе. Если вместо «Оплата после отгрузки» явно указать этап Аванс (до обеспечения) с нулевым процентом, алгоритм корректно переведет заказ в состояние ожидания обеспечения.