В процессе автоматизации розничной или оптовой торговли часто возникает классическая задача: обеспечить магазин товаром наиболее эффективным способом. Идеальная логика выглядит так: если товар есть на Центральном складе (ЦС), мы должны сначала переместить его оттуда, и только если запасов на ЦС недостаточно, формировать заказ внешнему поставщику. Рассмотрим подробнее, как эта логика реализована в 1С:Управление торговлей 11, и почему стандартная обработка формирования заказов иногда ведет себя не так, как мы ожидаем.
Для начала проанализируем ситуацию, с которой сталкиваются пользователи УТ 11.3 и более новых версий. Основным инструментом управления запасами является обработка «Формирование заказов по потребностям». Она опирается на настройки Схемы обеспечения и Способа обеспечения.
Проблема заключается в том, что в карточке номенклатуры для конкретного склада можно указать только одну Схему обеспечения, в которой зафиксирован один основной Способ обеспечения. Система не позволяет в рамках одного склада сказать: «Сначала попробуй переместить, а если не выйдет — купи».
Более того, если мы используем заказы на группу складов, система 1С имеет жестко зашитый в программный код приоритет типов обеспечения. Проанализируем этот список от самого высокого приоритета к самому низкому:
Как мы видим, Покупка имеет более высокий приоритет, чем Перемещение. Это означает, что если система видит возможность и купить товар, и переместить его, типовой алгоритм выберет закупку. Выясним причину: разработчики 1С предполагают, что перемещение — это внутренний логистический процесс, который должен быть запланирован заранее, в то время как закупка — основной источник внешнего ресурса.
Рассмотрим самый «чистый» с точки зрения типовой конфигурации вариант. Мы можем выстроить цепочку поставок, где магазины вообще не «знают» о внешних поставщиках напрямую. Разберем по шагам:
Способ обеспечения с типом «Перемещение». В качестве склада-источника указываем Центральный склад.Способ обеспечения с типом «Покупка» у внешнего поставщика.Схеме обеспечения указываем для склада магазина наш способ перемещения, а для центрального склада — способ покупки.Как это работает в системе: при запуске обработки «Формирование заказов по потребностям» система увидит потребность магазина и предложит создать Заказ на перемещение с ЦС. Если на ЦС товара нет, возникнет потребность уже на самом ЦС. При следующем шаге (или повторном запуске) система предложит Заказ поставщику для пополнения ЦС.
Минус этого метода: товар физически всегда должен пройти через ЦС. Если вы хотите, чтобы в случае отсутствия товара на ЦС поставщик вез товар напрямую в магазин, эта схема не сработает автоматически.
Если нам нужно сохранить возможность прямых поставок в магазины, но при этом максимально использовать остатки ЦС, проанализируем ситуацию с точки зрения бизнес-процесса. Мы можем выполнять формирование заказов в два этапа.
Шаг 1: Обеспечение перемещениями.
Временно или постоянно настраиваем в схеме обеспечения магазина приоритет на Перемещение. Запускаем обработку формирования заказов. На этапе выбора способов обеспечения мы выбираем только перемещения. Система проанализирует свободные остатки на ЦС и создаст документы Заказ на перемещение только на то количество, которое физически есть в наличии на источнике.
Шаг 2: Обеспечение закупками.
После того как заказы на перемещение созданы, остаток потребности в магазине все еще остается (на то количество, которое не покрыл ЦС). Мы повторно запускаем обработку, но теперь выбираем способ обеспечения Покупка. Система увидит неудовлетворенный остаток и сформирует Заказы поставщику напрямую на магазин.
Для удобства в современных версиях (начиная с 11.4) в самой обработке формирования заказов можно гибко отмечать галочками нужные потребности и способы, не меняя настройки в карточках Схем обеспечения постоянно.
Посмотрим на пример использования функционала «Группы складов». Если в настройках системы (НСИ и администрирование — Склады и магазины) разрешено использование групп складов, мы можем объединить магазин и ЦС в одну группу.
В этом случае в документе (например, в Заказе клиента или при анализе остатков) можно указать не конкретный склад, а группу складов. Система будет пытаться зарезервировать товар на складах группы согласно их приоритетам. Однако стоит помнить о правиле из сообщения (11) форума: внутри группы складов приоритет типа обеспечения Покупка все равно будет выше Перемещения. Этот метод эффективен только для распределения уже имеющихся остатков, но не для планирования новых закупок.
Если типовые методы не подходят из-за большого количества складов (например, 50 магазинов, как у автора темы), проанализируем возможность доработки. Основная логика формирования заказов сосредоточена в обработке ФормированиеЗаказовПоПотребностям и связанных с ней запросах к регистрам сведений ВариантыОбеспеченияТоварами.
Для автоматизации можно создать внешнюю обработку, которая будет выполнять следующие действия:
// Пример алгоритма для внешней обработки:
// 1. Получаем общую потребность по всем магазинам (регистр "ЗапасыИПотребности")
// 2. Получаем свободные остатки на Центральном складе
// 3. Распределяем остатки ЦС между магазинами по приоритету (или пропорционально)
// 4. Программное создание Заказов на перемещение:
НовыйЗаказ = Документы.ЗаказНаПеремещение.СоздатьДокумент();
НовыйЗаказ.СкладОтправитель = ЦентральныйСклад;
НовыйЗаказ.СкладПолучатель = Магазин;
// Заполнение табличной части Товары...
НовыйЗаказ.Записать(РежимЗаписиДокумента.Проведение);
// 5. Оставшуюся потребность передаем в стандартный механизм Заказа поставщику
Такой подход позволит избежать ручного переключения способов обеспечения и обеспечит максимально быструю обработку данных для всей розничной сети.
Подводя итог, можно сказать, что «из коробки» 1С:УТ 11.3 не умеет автоматически выбирать между перемещением и покупкой на основе наличия товара на складе-источнике в рамках одного шага.
Наилучшие стратегии без программирования:
Выбор конкретного метода зависит от объемов вашей номенклатуры и готовности персонала к выполнению регламентных операций в системе.