Как реализовать сложные цепочки перемещений и обособленное обеспечение в 1С:УТ 11 при переходе с 7.7?

Переход с платформы 1С:Предприятие 7.7 на современную конфигурацию 1С:Управление торговлей 11 (УТ 11) часто сопровождается трудностями в понимании механизмов резервирования и логистики. В старых системах пользователи привыкли к прямой связке «товар-заказ», которая поддерживалась доработками. В УТ 11 реализована мощная, но более абстрактная система обеспечения потребностей. Разберем подробно, как настроить систему для работы с равнозначными региональными складами, транзитными перемещениями и обособленными заказами.

Анализ проблемы динамической логистики

Рассмотрим типовую ситуацию: клиент заказывает товар на Складе 1. Однако части этого заказа разбросаны по разным точкам: что-то есть на Складе 2, что-то на Складе 3, а что-то только ожидается от поставщика. При этом логистическая цепочка может быть сложной, например: Склад 3 -> Склад 2 -> Склад 1. Основная сложность заключается в том, что схемы движения не статичны — любой склад может стать транзитным или пунктом выдачи в зависимости от текущей ситуации.

Механизм обособленного обеспечения (Назначение)

В УТ 11 решение задачи «связки товара и заказа» строится на понятии Назначение. Проанализируем, как это работает. Когда мы создаем Заказ клиента и устанавливаем вариант обеспечения «Обеспечивать обособлено», система создает уникальный идентификатор потребности. Этот идентификатор будет «сопровождать» товар на всем пути его следования.

При использовании обособления важно понимать следующее:

1. Наследование назначения: Если на основании Заказа клиента создается Заказ на перемещение, назначение автоматически копируется в табличную часть документа перемещения.
2. Жесткий резерв: Товар, поступивший на склад с указанным назначением, нельзя отгрузить под другой заказ. Система блокирует его для всех, кроме владельца назначения.
3. Прослеживаемость: В отчетах (например, «Остатки и доступность товаров») такой остаток отображается в колонке «В резерве», но с детализацией по конкретному заказу.

Настройка многоступенчатых схем обеспечения

Для автоматизации цепочек перемещения (например, через транзитный склад) в УТ 11 используются Схемы обеспечения. Рассмотрим алгоритм их настройки:

1. Определяем способы обеспечения: Создадим несколько записей в справочнике Способы обеспечения потребностей. Для каждого плеча логистики (например, «Перемещение со Склада 2 на Склад 1») создается отдельный способ с типом «Перемещение».

2. Настраиваем транспортные связи: В схеме обеспечения для каждого склада-получателя указываем источник пополнения. Выясним, как построить цепочку:

• Для Склада 1 источником указываем Склад 2.
• Для Склада 2 источником указываем Склад 3.

3. Формирование заказов: При запуске обработки Формирование заказов по потребностям система увидит дефицит на Складе 1 и предложит создать Заказ на перемещение со Склада 2. После создания этого документа возникнет дефицит на Складе 2, и система следующим шагом предложит создать заказ со Склада 3. Таким образом, формируется полная логистическая цепочка.

Использование транзитных складов и ордерной схемы

Проанализируем ситуацию, когда товар должен физически пройти через Склад 2, не задерживаясь на нем. Для контроля таких движений рекомендуем использовать статусы документов и двухфазную отгрузку:

В настройках склада или в параметрах перемещения можно задействовать статусы: «К отгрузке», «Отгружено», «Принято». Рассмотрим этапы:

1. При установке статуса «Отгружено» на Складе 3, товар списывается с остатков этого склада, но еще не появляется на Складе 2. Он переходит в состояние Товары в пути.
2. Логист всегда может увидеть объем товара, находящегося «в пути», с помощью специализированных отчетов.
3. На промежуточном Складе 2 кладовщик подтверждает приемку (статус «Принято»), и товар на мгновение становится доступным для дальнейшей отгрузки по следующему заказу на перемещение (на Склад 1).

Вариант автоматизации (Custom Solution)

Если типовые механизмы кажутся пользователям слишком сложными, можно реализовать автоматизированное рабочее место (АРМ) логиста, как это часто делалось в версии 7.7. Рассмотрим пример логики такой доработки:

1. Карта складов: Создадим вспомогательный объект (например, регистр сведений), где для каждого склада пропишем приоритетные склады-доноры.

2. Автомат обработки: Напишем обработку, которая анализирует Заказы клиента в статусе «К выполнению». Для строк с нехваткой товара она должна выполнять следующий алгоритм:

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

3. Связывание документов: В созданных документах Заказ на перемещение обязательно заполняется поле Назначение, чтобы резерв «перетекал» вместе с товаром.

Инструменты контроля для логиста

Выясним, какие типовые инструменты УТ 11 позволяют заменить привычные отчеты из 7.7:

• Рабочее место «Состояние обеспечения заказов»: Позволяет в реальном времени видеть, какие позиции зарезервированы, какие ожидаются, а по каким еще не созданы заказы на перемещение или закупку.
• Отчет «Распределение запасов»: Самый детальный инструмент, показывающий остатки в разрезе назначений, ожидаемых поступлений и планируемых отгрузок. Он заменяет старую связку «товар-заказ».
• Корректировка назначения товаров: Если логистика внезапно изменилась (например, товар пришел на таможню в Москву вместо Питера), этот документ позволяет оперативно перебросить резерв с одного ожидаемого поступления на другое без перепроведения заказов.

Таким образом, система обеспечения в УТ 11 значительно мощнее старых решений. Главное — правильно использовать механизмы Назначений и Способов обеспечения, что позволит автоматизировать даже самые сложные и динамичные схемы движения товаров без существенного изменения программного кода.