← На главную

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

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

Выясняем причину: почему заказ «исчезает» из списка распоряжений на доставку

Рассмотрим подробнее архитектурные особенности подсистемы доставки версии 2.0, которая использовалась в УТ до версии 11.4 и КА до версии 2.4. В этой схеме основным распоряжением на доставку выступает непосредственно сам документ Заказ клиента.

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

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

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

Ниже мы подробно разберем четыре практических метода обхода этого ограничения.

Способ 1. Управление составом товаров и флагами в «Задании на перевозку» (Рекомендованный ручной метод)

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

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

Способ 2. Переход на схему планирования по «Реализациям товаров и услуг»

Если ручной контроль состава документов логистом приводит к частым ошибкам, мы рекомендуем изменить бизнес-процесс и планировать доставку не по заказам, а по документам отгрузки. Это самый надежный стандартный вариант для конфигураций на архитектуре доставки 2.0.

Проанализируем, как перенастроить систему на эту схему:

1. В настройках подсистемы склада и доставки укажем, что распоряжениями на доставку являются документы Реализация товаров и услуг.
2. Менеджер по продажам оформляет Заказ клиента на весь объем сделки.
3. Для первой партии товара, готовой к отправке в первый день, менеджер устанавливает статус строк «Отгрузить» и создает документ Реализация товаров и услуг только на эту часть номенклатуры.
4. Эта первая накладная сразу же появляется в рабочем месте логиста как самостоятельное распоряжение на доставку. Логист без труда включает её в рейс.
5. Во второй день менеджер создает вторую Реализацию товаров и услуг на оставшиеся позиции заказа. Данный документ появляется в доставке как новое независимое распоряжение и уезжает в следующий запланированный день.

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

Способ 3. Построчная детализация дат доставки в заказе

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

Чтобы воспользоваться этим механизмом, выполним следующие действия:

1. В документе Заказ клиента включим режим отображения дат отгрузки в табличной части (кнопка «Обеспечение» — «Заполнить обеспечение» или через настройки формы).
2. Для первой группы товаров установим желаемую дату отгрузки (например, сегодня) и статус «Отгрузить».
3. Для второй группы товаров укажем будущую дату отгрузки и статус «Резервировать к дате» или «К обеспечению».
4. При формировании доставки на текущую дату система считает распоряжением только ту часть заказа, которая подлежит отгрузке сегодня. При правильной работе алгоритмов это позволяет частично закрывать потребность в доставке, оставляя неактуальные на сегодня строки для будущих рейсов.

Способ 4. Современное решение — переход на «Доставку 2.5» (релизы УТ 11.5 / КА 2.5 и новее)

Если вы работаете на современных версиях программных продуктов 1С (начиная с релизов 11.5.7 / 2.5.7), разработчики полностью устранили данную архитектурную проблему, внедрив новую подсистему «Доставка 2.5».

Рассмотрим ключевые преимущества и логику новой подсистемы:

• Документ «Заказ на доставку»: теперь Заказ клиента больше не отправляется напрямую логисту. Вместо этого в системе появился промежуточный сущностный документ — Заказ на доставку.
• Деление без ограничений: на основании одного большого Заказа клиента менеджер может создать сколько угодно отдельных документов Заказ на доставку на разные даты, разные адреса и даже на разные транспортные средства.
• Независимое планирование: каждый Заказ на доставку поступает в АРМ логиста как отдельная неделимая единица. Логисту больше не нужно вручную вычеркивать позиции из заданий на перевозку — он работает с уже подготовленными менеджером частями отправлений.

Если ваша компания регулярно сталкивается с необходимостью частичной доставки крупных заказов, обновление конфигурации до версии 11.5/2.5 и переход на новую подсистему доставки будет наиболее стратегически правильным и удобным решением.

Влияние ордерного склада на процесс частичной доставки

Необходимо отдельно проанализировать ситуацию, когда в компании используется ордерная схема документооборота на складе. В этом случае крайне важна настройка склада «Порядок сборки товаров».

Выделим два основных сценария работы:

Сценарий А. Доставка и сборка планируются независимо

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

Сценарий Б. Сборка осуществляется после планирования доставки

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

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