Один документ в 1С — десятки плеч доставки: ЭПД для фарм-дистрибуции

Дистрибутор медицинских товаров, развоз по десяткам точек за рейс. Учёт — в 1С:ERP с отраслевыми доработками. К 1 сентября 2026 транспортная накладная, заказ-заявка и экспедиторские документы должны оформляться в электронном виде — а процесс у клиента под типовой сценарий «одна отгрузка → одна накладная» не подходит.

Что усложняло переход:

• На одну отгрузку в учёте приходится, по сути, один документ, а внутри — поставки на десятки точек.
• Груз медицинский — в выгрузку нужно передавать соответствующий признак.
• Единиц хранения много и они разные, поэтому грузовые места, объём и вес (их передавать обязательно) считаются не по одной формуле, а по нескольким веткам под номенклатуру.
• Помимо накладной и заказа-заявки клиенту понадобилось поручение экспедитору — а это отдельная, более капризная механика.

Оформлять такой поток вручную по каждому плечу — это часы работы оператора ежедневно и разночтения в данных.

Собрали весь комплект прямо в 1С:ERP, из тех оснований, что уже ведутся в учёте, — без отдельного веб-кабинета и без переписывания конфигурации и отраслевых доработок.

• Отбор под экспедирование. Надёжного системного признака «это экспедиция» у документов нет — ни по типу, ни по контрагенту не определить однозначно. Завели флаг: оператор помечает нужные документы, и помеченные попадают в выборку на формирование, а из выборок под другие виды документов пропадают — чтобы исключить двойную обработку.
• Поручение экспедитору там, где «коробка» пасует. На момент реализации собрать несколько маршрутов в одном поручении штатно было нельзя — за проход подтягивается один маршрут, при нескольких основаниях отрабатывает только одно направление перевозки. Сделали обходной путь: система выводит оператору в сопровождающие документы и свободные поля список документов, которые нужно добавить в поручение; по этим номерам оператор находит документы и добавляет их в маршрут. А несколько настроек конвертации под разные типы позволяют закончить на этом ручную обработку и дозаполнить остальные маршруты в пару кликов.
• Разные основания — разные правила. Развели обработку по типам вложенных документов (заказ поставщику — «доставка до нас», реализация товаров и услуг — «отгрузка от нас»): от типа зависит, как строится маршрут и как считаются грузовые места под конкретную номенклатуру.
• Основной поток ЭТрН. Один документ учётной системы отражает и заказ-заявку, и ЭТрН. Из него собирается одна заказ-заявка на перевозчика (при необходимости — из нескольких документов, если они назначены на одного перевозчика), а затем она разбивается на отдельные ЭТрН — на каждый маршрут или плечо доставки.
• Автоформирование по статусу. Для точного контроля автоотправки — например, в ночное время — завязались на самописные статусы клиента, которые зависят от работы нескольких отделов. В зависимости от статуса система сама готовит документы, отправляет их на согласование и подписывает. Если заполнение корректно — уходит само; если данных не хватает — остаётся черновик, и оператор дозаполняет только его.