EDI: что это такое и как интегрировать EDI с 1С

Для поставщика торговой сети электронный обмен часто начинается не с УПД. Сначала приходит заказ, затем его нужно подтвердить, подготовить отгрузку, передать уведомление о поставке, получить результат приемки и только после этого закрыть расчёты документами.

Если все эти операции выполняются вручную, сотрудник фактически переносит одни и те же данные между учётной системой, личным кабинетом оператора и внутренними таблицами. На большом количестве заказов это превращается в постоянный источник ошибок и задержек.

EDI (Electronic Data Interchange) решает именно эту задачу: бизнес-системы автоматически обмениваются стандартизированными сообщениями. GS1 описывает EDI как автоматическую передачу согласованных бизнес-данных между торговыми партнёрами; в экосистеме GS1 используются, в частности, EANCOM, GS1 XML и UN/CEFACT XML.

Что такое EDI простыми словами

Представим обычную цепочку:

Торговая сеть
      ↓
Заказ поставщику
      ↓
Поставщик
      ↓
Подтверждение
      ↓
Отгрузка
      ↓
Приёмка
      ↓
Расчёты

В ручном процессе каждый этап может требовать участия сотрудника. В EDI эти события передаются между информационными системами в стандартизированном виде.

Торговая сеть
      ↓
   EDI
      ↓
1С / ERP поставщика
      ↓
WMS / производство
      ↓
   EDI
      ↓
Торговая сеть

GS1 отмечает среди преимуществ EDI снижение ручного ввода, ускорение обмена и уменьшение количества ошибок при повторном вводе данных. EDI также используется для управления заказами, поставками и логистическими процессами.

EDI и ЭДО — это одно и то же?

Нет. Эти технологии связаны, но решают разные задачи.

EDI	ЭДО
Автоматизация бизнес-обмена между системами	Юридически значимый электронный документооборот
Заказы, подтверждения, отгрузки, приемка, логистика	УПД, счета-фактуры и другие юридически значимые документы
Главный акцент — автоматизация цепочки поставок	Главный акцент — юридическая значимость документов
Может использоваться вместе с ЭДО	Может быть частью единого EDI/ЭДО-контура

На практике эти контуры часто объединяются. Например, заказ и уведомление об отгрузке передаются как EDI-сообщения, а УПД — как юридически значимый электронный документ. В модуле 1C:EDI предусмотрен обмен EDI-сообщениями и юридически значимыми документами с торговыми сетями из интерфейса 1С.

Как работает EDI

В упрощённом виде схема выглядит так:

Торговая сеть
      ↓
EDI-сообщение
      ↓
EDI-провайдер / канал обмена
      ↓
Интеграция
      ↓
1С / ERP
      ↓
Бизнес-действие

Ответное сообщение проходит обратный путь. При этом участники не обязаны использовать одинаковые внутренние системы. Смысл EDI как раз в том, чтобы согласовать формат и значение сообщений между разными информационными средами.

Какие сообщения используются в EDI

Набор сообщений зависит от конкретной сети, оператора и согласованного бизнес-процесса. В GS1 EDI существуют сообщения для заказа, подтверждения заказа, доставки, приемки, платежных и логистических процессов.

В российском сценарии 1C:EDI, например, официальная документация показывает последовательность:

ORDER
  ↓
Подтверждение заказа
  ↓
DESADV
  ↓
RECADV
  ↓
УПД
  ↓
Корректировка при необходимости

В инструкциях 1С отдельно описаны принятие заказа ORDER, уведомление об отгрузке DESADV, обработка результатов приемки RECADV, отправка УПД и корректировок.

ORDER — заказ

Торговая сеть формирует заказ поставщику. Вместо ручного ввода данных в 1С заказ передаётся в стандартизированном электронном сообщении.

Торговая сеть
      ↓
ORDER
      ↓
EDI
      ↓
1С
      ↓
Заказ клиента

После этого 1С может использовать полученный заказ в обычном процессе обеспечения, резервирования, производства и отгрузки.

ORDRSP — подтверждение заказа

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

Важно, что EDI позволяет автоматизировать не только передачу первоначального заказа, но и обратную коммуникацию между системами.

DESADV — уведомление об отгрузке

После подготовки поставки покупателю нужно сообщить, что именно и когда отправляется. В EDI для этого используется сообщение об отгрузке.

Заказ
  ↓
Сборка
  ↓
Отгрузка
  ↓
DESADV
  ↓
Торговая сеть

На этом этапе особенно важна связка EDI с WMS и складским учётом: фактический состав отгрузки должен соответствовать тому, что ушло покупателю.

RECADV — результат приемки

После доставки торговая сеть сообщает результат приемки. Это позволяет автоматически сопоставить ожидаемую и фактическую поставку.

DESADV
   ↓
Доставка
   ↓
Приёмка
   ↓
RECADV
   ↓
1С / ERP
   ↓
Сверка

Если количество или состав поставки отличается, система может передать результат в процесс обработки расхождений.

Какие данные должны быть синхронизированы

EDI-интеграция редко ограничивается одним документом. До обмена сообщениями нужно обеспечить сопоставление основных справочных данных.

Данные	Зачем нужны
Контрагент	Определение торговой сети и участника обмена
Номенклатура	Сопоставление товара поставщика и товара покупателя
GTIN	Идентификация товарных позиций в соответствующих EDI-сценариях
GLN	Идентификация участников и мест в цепочке поставок
Единицы измерения	Корректная передача количества
Склады	Определение места отгрузки или доставки
Договоры	Привязка бизнес-операции к условиям поставки

GS1 EANCOM, например, использует GTIN, SSCC и GLN в соответствующих EDI-сообщениях, связывая идентификацию товаров, логистических единиц и торговых партнёров с электронным обменом.

EDI и 1С: как выглядит интеграция

Самая простая архитектура:

Торговая сеть
      ↓
EDI-провайдер
      ↓
1С:EDI
      ↓
1С

Для типового сценария этого может быть достаточно. 1С уже предоставляет модуль 1C:EDI, предназначенный для обмена EDI-сообщениями и юридически значимыми документами с торговыми сетями.

Но на крупных проектах появляется другой вопрос: что делать, если кроме 1С есть WMS, CRM, собственный портал, производство или несколько информационных систем?

Enterprise-архитектура EDI

                 ┌───────────────┐
                 │ Торговая сеть │
                 └───────┬───────┘
                         │
                    EDI messages
                         │
                 ┌───────▼───────┐
                 │ EDI Provider  │
                 └───────┬───────┘
                         │
                 ┌───────▼──────────┐
                 │ Integration Layer│
                 │ mapping           │
                 │ validation        │
                 │ idempotency       │
                 └───────┬──────────┘
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
             1С         WMS        CRM
              │
              ▼
          Production

В таком варианте EDI-провайдер отвечает за транспорт и взаимодействие с внешним контуром, а Integration Layer — за внутреннюю бизнес-интеграцию.

Зачем нужен Integration Layer

Если подключить EDI напрямую к нескольким системам, логика быстро начинает дублироваться:

EDI → 1С
EDI → WMS
EDI → CRM
EDI → сайт
EDI → производство

При добавлении нового партнёра или изменении формата приходится менять несколько интеграций.

Лучше:

                 EDI
                  ↓
         Integration Layer
                  ↓
      ┌───────────┼───────────┐
      ↓           ↓           ↓
     1С          WMS         CRM

Внутри слоя можно централизовать mapping, валидацию, маршрутизацию, журналирование, retry и контроль идемпотентности.

Mapping: EDI и 1С говорят на разных языках

Один из самых сложных элементов EDI-интеграции — сопоставление данных. Внешний партнёр может использовать свои коды товаров, единицы измерения и идентификаторы, а 1С — собственные.

EDI
GTIN: 04601234567890
SKU: RET-001
Qty: 120
      ↓
Mapping
      ↓
1С
Номенклатура: 00000123
Количество: 120
Ед.: шт

Поэтому mapping нельзя делать набором случайных условий в обработчиках. Лучше иметь отдельную модель соответствий.

edi_product_mapping
-------------------
partner_id
external_code
gtin
internal_product_id
unit_mapping
created_at
updated_at

Что происходит, если товар не найден

Реальная интеграция должна уметь работать с исключениями. Например, торговая сеть прислала товар, которого нет в 1С.

Нельзя просто молча создать новый элемент справочника.

Лучше:

EDI ORDER
   ↓
Mapping
   ↓
Товар найден?
 ┌─┴──────────┐
Да            Нет
↓              ↓
Создать        Error / Review
заказ          Queue
               ↓
          Ответственный

Особенно важно не создавать автоматически финансово или юридически значимые данные без предусмотренного бизнес-правила.

EDI и WMS

Связка EDI + WMS особенно важна для компаний, поставляющих товары в крупные торговые сети.

ORDER
  ↓
1С
  ↓
WMS
  ↓
Сборка
  ↓
Отгрузка
  ↓
DESADV
  ↓
Торговая сеть
  ↓
RECADV
  ↓
1С / WMS

При этом WMS должна передавать фактические данные отгрузки, а не просто копировать плановый заказ. Иначе уведомление DESADV может расходиться с реальным составом паллет или коробов.

EDI и производство

Для производителя EDI-заказ может стать входом в производственный контур.

EDI ORDER
    ↓
1С
    ↓
Проверка остатков
    ↓
Проверка мощности
    ↓
План производства
    ↓
Сменные задания
    ↓
Выпуск
    ↓
WMS
    ↓
DESADV
    ↓
Торговая сеть

Здесь EDI перестаёт быть отдельной «системой обмена заказами» и становится частью сквозного процесса Order-to-Cash.

Для производственного предприятия особенно важно связать этот контур с планированием мощностей и bottleneck-анализом: входящий EDI-заказ должен учитываться не только в продажах, но и в реальной производственной способности предприятия.

Очереди и асинхронная обработка

Нельзя предполагать, что внешний EDI-провайдер, 1С и все внутренние системы доступны одновременно.

Поэтому надёжная интеграция строится асинхронно:

EDI
 ↓
Message received
 ↓
Queue
 ↓
Validation
 ↓
Mapping
 ↓
Business processing
 ↓
1С / WMS
 ↓
Result

Если 1С временно недоступна, сообщение не должно теряться. Оно остаётся в очереди и обрабатывается после восстановления сервиса.

Retry и Dead Letter Queue

Не каждая ошибка означает, что сообщение неправильное. Сетевой timeout, временная недоступность 1С или перегрузка внешнего сервиса могут пройти после повторной попытки.

EDI Message
     ↓
Queue
     ↓
Processing
 ┌────┼────────────┐
 ↓    ↓            ↓
OK  Temporary    Permanent
    Error          Error
     ↓              ↓
   Retry            DLQ

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

Идемпотентность в EDI

Внешняя система может повторно доставить сообщение. Интеграция должна уметь понять, что оно уже обработано.

edi_message
-----------
partner_id
message_id
message_type
received_at
processed_at
status

Перед созданием бизнес-объекта проверяем:

message_id уже обработан?
        ↓
   ┌────┴────┐
   Да        Нет
   ↓          ↓
 Skip       Process
              ↓
            Save ID

Это особенно важно для заказов, отгрузок и других сообщений, которые при повторной обработке могут создать дубликаты.

EDI и юридически значимые документы

В российском контуре EDI может идти рядом с юридически значимым ЭДО. Поэтому архитектура должна различать как минимум:

• операционные EDI-сообщения;
• юридически значимые электронные документы;
• статусы документооборота;
• подписанные документы и результаты обработки.

1C:EDI как раз объединяет EDI-обмен с торговыми сетями и обмен юридически значимыми документами в едином контуре 1С.

EDI через интернет и Web EDI

EDI не обязательно означает старую модель закрытой сети. GS1 отдельно описывает Internet EDI: те же стандартизированные EANCOM или GS1 XML могут передаваться через интернет вместо традиционной VAN-инфраструктуры.

Существует и Web EDI — модель, при которой небольшому участнику предоставляется веб-интерфейс для работы с EDI-сообщениями, а платформа преобразует данные в необходимый стандартный формат. GS1 описывает Web EDI как способ подключать к EDI небольших партнёров, которым не нужна полноценная собственная EDI-инфраструктура.

EDI, XML и EDIFACT

EDI — это концепция электронного обмена структурированными бизнес-сообщениями, а конкретный формат может быть разным.

В международном EDI используются, например, UN/EDIFACT, GS1 EANCOM и GS1 XML. GS1 EANCOM является подмножеством UN/EDIFACT, адаптированным для GS1-сценариев.

EDI
 │
 ├── UN/EDIFACT
 │      └── GS1 EANCOM
 │
 └── GS1 XML

Поэтому при разработке интеграции нельзя начинать с вопроса «какой XML нам прислали». Сначала нужно определить бизнес-сообщение и соглашение с конкретным партнёром, а уже затем — технический формат и mapping.

Symfony + EDI

Если требуется собственный integration gateway, Symfony хорошо подходит для построения отдельного слоя между EDI-провайдером и корпоративными системами.

EDI Provider
      ↓
Symfony API / Adapter
      ↓
Message Bus
      ↓
Mapping / Validation
      ↓
PostgreSQL
      ↓
1С / WMS / CRM

Внутри можно разделить ответственность:

EdiTransport
EdiMessageParser
EdiMapper
EdiValidator
EdiRouter
EdiProcessor
EdiStateRepository

Это позволяет не смешивать транспорт EDI с бизнес-логикой конкретной 1С-конфигурации.

Go + EDI

Для высоконагруженного gateway аналогичный контур можно реализовать на Go:

EDI
 ↓
Go Gateway
 ↓
RabbitMQ / Queue
 ↓
Workers
 ↓
1С / WMS / CRM
 ↓
PostgreSQL

Особенно полезно это становится, когда через один шлюз нужно обслуживать нескольких торговых партнёров и несколько протоколов обмена.

Что хранить в собственной базе

Для надёжной интеграции полезно хранить не только бизнес-документ, но и техническое состояние обмена.

edi_message
-----------
id
partner_id
external_message_id
message_type
direction
received_at
processed_at
status

edi_document
------------
message_id
source_system
source_document_id
internal_document_id
status

edi_mapping
-----------
partner_id
external_code
internal_code

edi_operation
-------------
operation_id
message_id
attempts
last_error
next_retry_at

Это позволяет восстановить цепочку обработки и понять, где именно находится проблема: у партнёра, в EDI-провайдере, mapping, 1С или WMS.

Типичные ошибки при внедрении EDI

Ошибка	Последствие
Считать EDI просто обменом XML	Не учитывается бизнес-семантика сообщений
Не сделать mapping товаров	Заказы не сопоставляются с номенклатурой 1С
Обрабатывать всё синхронно	Временная недоступность одной системы блокирует цепочку
Не хранить внешний ID сообщения	Невозможно защититься от дублей
Не разделять EDI и ЭДО	Смешиваются операционные и юридически значимые процессы
Зашить mapping в код	Любое изменение партнёра требует изменения приложения
Подключить EDI напрямую к нескольким системам	Появляется множество точечных интеграций
Не связать EDI с WMS	DESADV может расходиться с фактической отгрузкой

Когда достаточно 1C:EDI

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

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

Когда нужен собственный EDI Integration Layer

Отдельный слой имеет смысл, если:

• есть несколько учётных систем;
• нужно подключать несколько EDI-провайдеров или партнёров;
• есть собственная WMS;
• EDI связан с производством;
• нужно централизованное журналирование;
• требуется сложный mapping;
• есть очереди и большой объём сообщений;
• нужен единый API для нескольких внутренних систем.

Минимальный MVP EDI-интеграции

Для первого проекта необязательно автоматизировать весь Order-to-Cash. Можно взять один торговый канал и один сценарий.

Итог

EDI — это механизм автоматизированного обмена стандартизированными бизнес-сообщениями между торговыми партнёрами. Он позволяет убрать ручной перенос данных между системами и связать заказ, поставку, приемку и дальнейший документооборот в единый цифровой процесс.

Для компании на 1С путь может быть простым:

Торговая сеть
      ↓
EDI Provider
      ↓
1C:EDI
      ↓
1С

Но если в контуре есть WMS, CRM, производство, сайт или собственные сервисы, лучше строить отдельный Integration Layer:

Торговые сети
      ↓
EDI Provider
      ↓
Integration Layer
      ↓
┌─────┼─────┬────────┐
↓     ↓     ↓        ↓
1С   WMS   CRM   Production
      ↓
  PostgreSQL
      ↓
Analytics / AI

В результате EDI становится не отдельным кабинетом, а частью сквозного процесса: заказ → обеспечение → производство/склад → отгрузка → приемка → ЭДО → аналитика.