Единый транспортный документ редко живёт в одной системе. В типовом ландшафте средней компании есть ERP, где ведутся продажи, склад и расчёты с контрагентами, и TMS, где планируются рейсы и маршруты. Вопрос, в какой из них формируется ЕТД и откуда берутся данные для титулов, определяет всю архитектуру интеграции. Разберём рабочие схемы, антипаттерны и то, что стоит решить до начала проекта.
Главный вопрос: где владелец документа
Начинать нужно не с форматов обмена, а с назначения системы-владельца перевозочного документа. Вариантов три, и каждый имеет свою область применимости.
Владелец — TMS
Подходит транспортным и экспедиторским компаниям, для которых перевозка является основной деятельностью. Маршрут, плечи, перевалка и транспортные средства уже описаны в TMS как объекты учёта, поэтому формирование титулов ложится на существующую модель данных естественно. ERP получает из TMS факт оказания услуги и суммы для расчётов.
Владелец — ERP
Подходит производственным и торговым компаниям, которые отгружают собственную продукцию и пользуются наёмным транспортом. Первичные данные о грузе — номенклатура, весогабаритные характеристики, маркировка — и так живут в ERP, а перевозка описывается достаточно просто. Заводить ради этого отдельную TMS избыточно.
Разделение по типу перевозки
Компромисс для компаний со смешанным профилем: простые односоставные отгрузки оформляются в ERP, мультимодальные маршруты с перевалкой — в TMS. Схема рабочая, но требует чёткого правила маршрутизации и контроля, чтобы один и тот же рейс не оформлялся дважды.
Чего делать не стоит — оставлять вопрос открытым и позволять формировать документы в обеих системах «по ситуации». Это гарантированно приводит к расхождению нумерации и дублям в государственной системе.
Мастер-данные: откуда что берётся
Состав сведений ЕТД собирается из нескольких источников, и для каждого блока нужно назначить систему-источник.
| Блок сведений | Типичный источник | На что обратить внимание |
|---|---|---|
| Контрагенты, реквизиты | ERP | Единый справочник, без параллельного ведения в TMS |
| Номенклатура, вес, габариты, маркировка | ERP | Часто не заполнено — основной объём подготовительной работы |
| Маршрут, плечи, пункты перевалки | TMS | В ERP обычно отсутствует как структура |
| Транспортные средства, водители | TMS | Нужны для титула о приёме груза и замены ТС |
| Провозная плата и её разбивка | TMS или ERP | Требуется разбивка по видам транспорта |
| Сертификаты подписи, доверенности | Система-владелец документа | Привязка к пользователю, а не к подразделению |
Правило простое: у каждого справочника один хозяин и однонаправленная репликация. Двусторонняя синхронизация справочников контрагентов и номенклатуры между ERP и TMS — источник конфликтов, который проявится ровно в момент, когда документ отклонит оператор.
Точки интеграции
Помимо справочников, между системами передаются события. Минимально необходимый набор:
- Потребность в перевозке — из ERP в TMS: заказ клиента или заказ на отгрузку порождает задание на перевозку.
- Сформированный документ — из системы-владельца к оператору ЭПД и обратно статусы обработки.
- Статусы титулов — во вторую систему, чтобы менеджер видел ход перевозки не переключаясь между интерфейсами.
- Факт оказания услуги и суммы — в ERP для закрытия периода и расчётов с перевозчиками отдельных плеч.
- Отклонения — переадресация, замена транспортного средства, изменение финансовых условий должны доходить до системы, где ведутся расчёты.
Практики, которые себя оправдывают
- Один контур обмена с оператором. Подключать к оператору ЭПД одну систему, а не обе. Даже если документы формируются в двух местах, канал должен быть один — иначе разъезжаются статусы.
- Идемпотентность обмена. Повторная отправка одного и того же события не должна порождать второй документ. Это спасает при сбоях связи, которые неизбежны.
- Сквозной идентификатор перевозки. Один ключ, по которому перевозка прослеживается от заказа клиента до закрывающего титула, — иначе разбор инцидента превращается в ручное сопоставление.
- Валидация до отправки. Проверка обязательных реквизитов на стороне системы-владельца, а не ожидание отказа от оператора.
- Журнал обмена с человекочитаемыми ошибками. Логист должен понимать причину отказа без обращения к администратору.
- Единый запрет правок. Если документ закрыт для редактирования в одной системе, он должен быть закрыт и во второй — иначе запрет обходится сменой интерфейса.
Антипаттерны
- Обмен файлами через папку. Работает до первого расхождения и не даёт контроля доставки.
- Ручной перенос данных между системами. Ровно то, ради устранения чего вводился электронный документ.
- Дублирование справочника контрагентов. Две карточки одного клиента с разными реквизитами — прямой путь к отклонённому документу.
- Интеграция без обратных статусов. Документ ушёл, а что с ним — видно только в кабинете оператора.
- Доработка вместо настройки. Значительная часть требований закрывается штатными механизмами сервиса 1С-ЭПД и отраслевых конфигураций; писать своё стоит только там, где типового решения действительно нет.
Как это выглядит на платформе 1С
Если и ERP, и TMS реализованы на 1С, задача упрощается: обмен строится штатными механизмами платформы, а работа с перевозочными документами закрывается сервисом 1С-ЭПД, поддерживающим утверждённые форматы и обмен через операторов. В связке «1С:ERP» и «1С:Управление транспортировками» распределение ролей между системами уже проработано, и проект сводится к настройке и дозаполнению данных.
Сложнее сценарий, где TMS или ERP — стороннее решение. Тогда ключевым становится выбор системы-владельца документа и проектирование одного канала обмена с оператором, а не попытка синхронизировать два независимых контура.
Что решить до старта проекта
- Какая система является владельцем перевозочного документа и по какому правилу маршрутизируются нетиповые случаи.
- Какой справочник в какой системе является главным и как устроена репликация.
- Через какую систему идёт единственный канал обмена с оператором ЭПД.
- Какие события передаются между системами и с какой периодичностью.
- Как выглядит сквозной идентификатор перевозки.
- Кто и в каком интерфейсе разбирает ошибки обмена.
Итог
Интеграция ЕТД с TMS и ERP — это в первую очередь архитектурное решение о владельце документа и мастер-данных, и только во вторую — вопрос протоколов обмена. Проекты, где этот выбор сделан явно и зафиксирован, проходят внедрение предсказуемо; проекты, где его отложили «до технического этапа», упираются в дубли документов и расхождение справочников.
Компания «Сайфилд» проектирует и настраивает интеграцию учётных систем с контуром электронных перевозочных документов — от выбора системы-владельца и схемы мастер-данных до подключения 1С-ЭПД и сквозного тестового обмена. Опишите свой ландшафт, и мы оценим объём работ.