Примерно три года назад я впервые столкнулась с задачей интегрировать две системы: ERP‑систему с 1С. На тот момент у меня не было ни опыта, ни документации, ни ментора, который сказал бы: «делай вот так». Были только задача и желание разобраться. Эта статья про мой опыт, совершенные ошибки и принятые решения. Надеюсь, она будет вам полезна и сэкономит вам время и нервы.
Архитектура интеграции
Как мы решили строить обмен
Задача звучала просто: нужно было организовать двусторонний автоматизированный обмен данными между ERP‑системой и 1С в разных конфигурациях: Бухгалтерия, Управление торговлей, Комплексная автоматизация, Розница.
Мы выбрали микросервисную архитектуру. Микросервис принимает запросы, трансформирует данные, обрабатывает файл загрузки из 1С и формирует файл выгрузки. Это позволило нам не трогать ядро ERP‑системы, чтобы при изменениях в интеграции — любая доработка касалась только микросервиса.
Почему два протокола — это нормально
Одно из первых решений, которое мы приняли — это использовать разные протоколы для выгрузки и загрузки данных.
Так как при выгрузке документов необходимо выгружать справочники, на которые ссылается выгружаемый документ, то для выгрузки из ERP в 1С мы выбрали GraphQL:
Гибкость в построении запросов: позволяет получать большие массивы данных одним запросом, а в интеграции с 1С для выгрузки одного документа необходимо запрашивать данные из нескольких таблиц
Позволяет использовать узлы для выгрузки связанных документов и справочников (например, документ заказ покупателя содержит товары, контрагента и организацию, данные о которых необходимо выгружать в связке с заказом покупателя)
Позволяет запрашивать только нужные поля (иногда для выгрузки справочника достаточно выгрузить только обязательные поля)
Для загрузки данных из 1С в ERP мы выбрали REST API:
REST поддерживает создание, изменение и удаление данных (в отличие от GraphQL, который работает только на чтение)
Вывод: не нужно выбирать один инструмент на все случаи. Используйте сильные стороны каждого. Существуют интеграции, в которых используются и GraphQL, и REST API для выгрузки данных (например, один справочник запрашивается с помощью GraphQL, а другой — REST API). Все зависит от особенностей интеграции и реализуемых бизнес‑процессов.
Маппинг данных — одна из самых сложных частей
Маппинг данных — это когда ты пытаешься объяснить системе: «Вот это поле в ERP соответствует вот этому полю в 1С». И если у тебя 50 полей, а у 1С — 50 других полей с другой логикой, эта задача становится нетривиальной.
Я столкнулась с тем, что разные конфигурации 1С живут своей жизнью. То, что работает в «Бухгалтерии», может не работать в «Управлении торговлей». Один документ может по‑разному выгружаться в разные конфигурации 1С.
Подход к задаче маппинга
Сначала я составила таблицу соответствия документов и справочников для каждой конфигурации отдельно. Затем составила аналогичную таблицу соответствия полей. Потом нашла общий знаменатель — минимальный набор документов и справочников, который есть во всех конфигурациях и выгружается одинаково. Аналогично с полями в документах. Для специфичных справочников/документов сделала отдельную обработку, но таких, как правило, было не так много.
Главный урок: если ты не продумаешь маппинг на этапе анализа, ты будешь переписывать его на этапе тестирования. А это дорого и больно.
EnterpriseData — что это и как с ним работать
EnterpriseData — это универсальный XML‑формат для обмена бизнес‑данными, разработанный фирмой 1С.
Главная идея: формат описывает бизнес‑сущности (документы, справочники) в виде, понятном и ERP, и 1С.
Ключевая особенность: формат не зависит от структуры конкретной информационной базы. Этот формат является универсальным и позволяет обмениваться данными между разными системами и конфигурациями 1С, не перестраивая их архитектуру.
Информация для справки: Сейчас формат EnterpriseData имеет более 10 версий. Как правило, глобальные изменения в формате наблюдаются редко. В основном это изменения добавочного характера, то есть появляется поддержка нового необязательного поля в одном или нескольких документах, реже: какое‑либо поле в новых версиях начинает описывается в виде отдельного справочника.
Как работает обмен через EnterpriseData
Схема обмена через формат EnterpriseData:
Стороннее приложение формирует XML‑файл в формате EnterpriseData
В заголовке файла указывается служебная информация (кто отправил, порядковые номера получаемого и отправляемого файлов, время отправки, GUID интеграции, список документов, участвующих в обмене)
Файл передаётся в 1С одним из следующих способов:
файловый каталог
FTP (Микросервис кладет файл на FTP, 1С обращается к FTP, обрабатывает файл и загружает ответный файл с данными)
веб‑сервис
1С обрабатывает файл и формирует файл‑ответ о с сообщением о том, что данные приняты или не приняты. Также если в 1С есть измененные или новые документы/справочники, то 1С отправляет данные о них в этом же файле‑ответе
Важные нюансы:
Если вам нужна только односторонняя передача (например, из интернет‑магазина в «1С: Бухгалтерию»), можно использовать упрощённый вариант: реализовать выгрузку XML‑файла из ERP, далее загружать его вручную
Важно учитывать при выборе конфигурации для клиента: Фреш‑версии 1С поддерживают только ручную загрузку файла, то есть идея реализации автоматизированной выгрузки и обмена в обе стороны отпадает
Практический пример: структура EnterpriseData
Документ в формате EnterpriseData описывается через XML‑схему. Вот упрощённая структура для справочника Номенклатура
<Справочник.Номенклатура>
<КлючевыеСвойства>
<Ссылка>0c8913dd-ea5e-11e0-a0cd-e1cb4ed5f6e4</Ссылка>
<НаименованиеПолное>Обычный товар</НаименованиеПолное>
<КодВПрограмме>00-089100</КодВПрограмме>
<Артикул>000321</Артикул>
<Наименование>Обычный товар</Наименование>
<Группа>
<Ссылка>0c8813d8-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка>
<Наименование>Товары</Наименование>
<КодВПрограмме>00-891</КодВПрограмме>
<Группа>
<Ссылка>fad620c2-c719-11e4-9ec3-bcaec56cc100</Ссылка>
<Наименование>Торговая деятельность</Наименование>
<КодВПрограмме>00-89</КодВПрограмме>
</Группа>
</Группа>
</КлючевыеСвойства>
<ТипНоменклатуры>Товар</ТипНоменклатуры>
<ЕдиницаИзмерения>
<Ссылка>2609357a-c180-90e4-a7a9-123d884fd00d</Ссылка>
<ДанныеКлассификатора>
<Код>01</Код>
<Наименование>Штука</Наименование>
</ДанныеКлассификатора>
</ЕдиницаИзмерения>
<СтавкаНДС>НДС22</СтавкаНДС>
<ДанныеАлкогольнойПродукции>
<АлкогольнаяПродукция>false</АлкогольнаяПродукция>
<ВидАлкогольнойПродукции xsi:nil="true" />
<ИмпортнаяАлкогольнаяПродукция>false</ИмпортнаяАлкогольнаяПродукция>
<ОбъемДАЛ xsi:nil="true" />
<ПроизводительИмпортер xsi:nil="true" />
<Крепость xsi:nil="true" />
</ДанныеАлкогольнойПродукции>
<КодТРУ xsi:nil="true" />
<ЦеноваяГруппа>
<Ссылка>0ae4894e-ef12-11e4-92f1-0000008b35ac</Ссылка>
<Наименование>Обычные товары</Наименование>
</ЦеноваяГруппа>
<ВидНоменклатуры>
<Ссылка>0c6013c6-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка>
<Наименование>Товары обычные</Наименование>
<ТипНоменклатуры>Товар</ТипНоменклатуры>
<ИспользоватьСерии>true</ИспользоватьСерии>
<ИспользоватьСрокГодностиСерии>false</ИспользоватьСрокГодностиСерии>
<ИспользоватьХарактеристики>false</ИспользоватьХарактеристики>
</ВидНоменклатуры>
<ПризнакПредметаРасчета>Товар</ПризнакПредметаРасчета>
<Весовой>false</Весовой>
<Маркируемый>false</Маркируемый>
<ПодакцизныйТовар>false</ПодакцизныйТовар>
<ПрослеживаемыйТовар>false</ПрослеживаемыйТовар>
<ОбщиеСвойстваОбъектовФормата>
<ДополнительныеРеквизиты>
<Строка>
<ЗначениеСвойства>
<ЗначениеДополнительногоРеквизитаСсылка>
<Наименование>5</Наименование>
<Ссылка>0c6013cc-ea5e-98e0-a7cd-e0cb4ed5f6e4</Ссылка>
<Владелец>
<Наименование>Число элементов</Наименование>
<Ссылка>0c0000c7-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка>
<ЭтоДополнительноеСведение>false</ЭтоДополнительноеСведение>
</Владелец>
</ЗначениеДополнительногоРеквизитаСсылка>
</ЗначениеСвойства>
<Свойство>
<Наименование>Число элементов</Наименование>
<Ссылка>0c0000c7-ea5e-11e0-a7cd-e0cb4ed5f6e4</Ссылка>
<ЭтоДополнительноеСведение>false</ЭтоДополнительноеСведение>
</Свойство>
</Строка>
</ДополнительныеРеквизиты>
</ОбщиеСвойстваОбъектовФормата>
</Справочник.Номенклатура>Каждый объект (любой документ или справочник) содержит тег <КлючевыеСвойства>, который содержит в себе основные параметры объекта. Кроме того, этот тег содержит тег <Ссылка>, в котором хранится guid — идентификатор объекта, по которому система идентифицирует объект. Если объект уже выгружался ранее, то далее необходимо выгружать этот объект с тем же guid, чтобы избежать дублирования.
Грабли, на которые мы наступали
№ 1 Разные конфигурации 1С — разные правила
Каждая конфигурация имеет свою логику документооборота. Например, в 1С‑Бухгалтерия нет документа Заказ клиента, но он есть в 1С‑Управление Торговлей (УТ). Если взять один и тот же документ и выгрузить его в формате EnterpriseData как <Документ.ЗаказКлиента>, то в 1С‑Бухгалтерию этот документ выгрузится как Счет покупателю, а в 1С‑УТ — Заказ клиента.
Решение: Указывать в какую конфигурацию 1С выгружаются данные, чтобы система понимала как описать ей тот или иной документ.
№ 2 Версии формата EnterpriseData
Клиент обновил 1С, вместе с которой и обновился формат обмена EnterpriseData до 1.15 версии, а ERP продолжала обмениваться в 1.11 версии.
Решение: Формат постоянно обновляется. Необходимо не обновлять формат, именно добавлять поддержку новых форматов для поддержки интеграции у всех пользователей.
№ 3 Избыточная синхронизация
В типовом обмене 1С отправляет на загрузку все документы, в том числе и те, которые не участвуют в бизнес‑процессе.
Решение: Микросервис обрабатывает только нужные документы, игнорируя остальные. Но данное решение не совсем оптимально, так как 1С тратит время и ресурсы на выгрузку всех данных. Поэтому в настройках интеграции на стороне 1С в настройках интеграции можно выбрать список типов документов, которые будут выгружаться из 1С.
Заключение
Интеграция с 1С — это всегда про большие данные. Файлы обмена могут быть огромными. Документов — тысячи. Справочников — десятки тысяч записей. Всё это одновременно загружает систему, и если не продумать архитектуру, она просто встанет.
Микросервисная архитектура в этом случае является оптимальным вариантом. Выделенный сервис‑посредник берёт на себя всю нагрузку по обработке файлов: он получает данные из ERP, преобразовывает их в формат EnterpriseData XML‑файл, считывает файл‑ответ от 1С и обновляет данные в ERP. Ядро ERP при этом не тормозит, не перегружается и продолжает работать стабильно. Любые доработки касаются только микросервиса — это снижает риски для всей системы.
Формат EnterpriseData — отдельная история. Он сложный для восприятия. В нём много тегов, вложенных элементов, правил. Но у него есть два важных преимущества. Во‑первых, он универсален — подходит для любых конфигураций 1С. Во‑вторых, его не нужно переписывать каждый раз. Поддерживать EnterpriseData несложно: достаточно отслеживать новые версии и добавлять поддержку новых полей. Это понятная, предсказуемая работа.
Если коротко: выбирайте микросервисы, чтобы выдержать нагрузку. Используйте EnterpriseData, чтобы не переписывать интеграцию с нуля под каждую конфигурацию.