Ручное создание накладных в личных кабинетах перевозчиков — источник ошибок и потерянного времени менеджеров. Гораздо надёжнее, когда 1С-Битрикс сам оформляет отправление и подтягивает трек-номер по событию заказа. Разбираем, как выстроить автосоздание накладных для нескольких служб доставки.
Зачем автоматизировать накладные
Пока накладные создаются вручную, магазин платит за это скоростью и качеством. Автоматизация решает сразу несколько проблем.
- Ошибки ввода. Адреса и габариты, скопированные руками, дают возвраты и пересчёты.
- Скорость отгрузки. При потоке заказов ручное оформление становится узким местом.
- Единая картина. Трек-номер и статус видны в заказе, а не в стороннем кабинете.
- Мультислужбы. Один процесс на все службы вместо переключения между кабинетами.
Триггеры создания накладной
Создание отправления привязывают к событию заказа. В 1С-Битрикс для этого есть обработчики событий модуля sale.
OnSaleOrderSaved— реагируем на сохранение заказа.OnSaleStatusOrderChange/OnSaleOrderStatusChange— создаём накладную при переходе в нужный статус (например, «Оплачен» или «Готов к отгрузке»).
Самый предсказуемый вариант — привязать создание к смене статуса. Тогда логика такая: заказ оплачен и укомплектован → статус меняется → обработчик формирует отправление в службе доставки → сохраняет трек-номер.
Идемпотентность и защита от дублей
Главный риск автоматизации — создать два отправления на один заказ. Событие может сработать повторно, менеджер — дважды сменить статус, API — ответить таймаутом при успешном создании. Защита строится на нескольких уровнях.
- Перед созданием проверяем свойство заказа с трек-номером: если оно заполнено — выходим.
- Ставим блокировку/флаг «идёт создание», чтобы параллельные вызовы не пересеклись.
- Где перевозчик поддерживает — передаём ключ идемпотентности или свой номер заказа, чтобы повтор не создавал дубль на его стороне.
- Логируем каждую попытку с ответом API.
Такой подход делает операцию безопасной: повторный вызов не плодит отправления, а возвращает уже существующий трек.
Хранение трек-номера и печать этикеток
Трек-номер и идентификатор отправления сохраняются в свойствах заказа — например, TRACK_NUMBER и DELIVERY_ORDER_ID. Отсюда их показывают клиенту в личном кабинете и передают в 1С.
Печать этикеток — отдельный шаг: большинство служб отдают наклейку в PDF по идентификатору отправления. Удобно сделать в списке заказов действие «печать этикеток» для выделенных заказов, чтобы собирать пачку к отгрузке.
| Что сохраняем | Свойство заказа | Зачем |
|---|---|---|
| Трек-номер | TRACK_NUMBER | Трекинг, показ клиенту |
| ID отправления | DELIVERY_ORDER_ID | Печать, отмена, статусы |
| Статус доставки | DELIVERY_STATE | Синхронизация воронки |
Мультислужбы под единым интерфейсом
Магазины редко работают с одним перевозчиком. Чтобы не плодить разрозненный код, логику создания накладных удобно свести к общему контракту, а различия спрятать в адаптеры под каждую службу.
- Единый метод
createShipment(order)на уровне магазина. - Отдельные адаптеры СДЭК, Boxberry, Почты, DPD со своей реализацией.
- Выбор адаптера по коду службы доставки заказа.
- Общий формат хранения трека и статуса независимо от перевозчика.
Тогда добавление новой службы — это ещё один адаптер, а не переписывание всей логики отгрузки.
Синхронизация статусов
Создание накладной — половина дела. Дальше нужно поддерживать актуальный статус. Одни службы шлют вебхуки, другие требуют опроса.
- Вебхуки (СДЭК и др.) — обработчик принимает событие и меняет статус заказа сразу.
- Опрос агентом (Boxberry, Почта) — периодический запрос статусов активных отправлений.
- Выборка событий (DPD) — получение изменений по всем заказам разом.
Итог
Автосоздание накладных и трек-номеров в 1С-Битрикс держится на трёх опорах: правильный триггер по смене статуса, идемпотентность против дублей и единый контракт с адаптерами под каждую службу. Дополняют картину печать этикеток пачкой и синхронизация статусов вебхуками или агентом.
Мы в B2Bsite выстраиваем автоматическое оформление отправлений для всех подключённых служб доставки: накладные и трек-номера создаются по событию заказа, этикетки печатаются из списка заказов, статусы синхронизируются с сайтом, 1С и CRM. Менеджер работает в одном окне, а не в десятке личных кабинетов.
Частые вопросы
К какому событию привязывать создание накладной?
Надёжнее всего к смене статуса заказа, например на «Готов к отгрузке» или «Оплачен», через обработчики OnSaleStatusOrderChange. Привязка к каждому сохранению заказа опасна: одно редактирование породит дубль отправления.
Как избежать создания двух накладных на один заказ?
Проверять свойство с трек-номером перед созданием, ставить флаг «идёт создание» от параллельных вызовов и, где возможно, передавать перевозчику ключ идемпотентности или свой номер заказа. Все попытки логируются.
Где хранится трек-номер?
В свойствах заказа, например TRACK_NUMBER и идентификатор отправления DELIVERY_ORDER_ID. Оттуда трек показывается клиенту в личном кабинете, используется для печати этикеток и передаётся в 1С.
Можно ли печатать этикетки пачкой?
Да. Большинство служб отдают наклейку в PDF по идентификатору отправления. В списке заказов делают действие «печать этикеток» для выделенных заказов, чтобы собрать пачку к отгрузке.
Как автоматизировать сразу несколько служб?
Логику сводят к единому методу создания отправления, а различия прячут в адаптеры под каждую службу. Адаптер выбирается по коду службы доставки заказа, а трек и статус хранятся в общем формате.
Как обновлять статусы после создания накладной?
Зависит от службы: одни шлют вебхуки и статус меняется сразу, другие опрашиваются агентом по расписанию, третьи отдают выборку событий по всем заказам. Статусы сопоставляют с воронкой заказа.
Нужен ли обмен с 1С для автосоздания накладных?
Не обязательно, но полезно. Если магазин обменивается с 1С, трек-номер и статус доставки прокидывают в учётную систему, чтобы менеджеры видели движение отправлений без входа в кабинеты перевозчиков.
Поможем с настройкой и поддержкой Интеграции и связки систем
Поможем с настройкой, доработкой и поддержкой Интеграции и связки систем.