При переходе со старых конфигураций на новые (например, при постепенной замене 1С:Управление производственным предприятием (УПП 1.3) на 1С:ERP Управление предприятием) часто возникает дилемма: какую технологию обмена данными выбрать? Заказчики и руководители проектов, наслушавшись маркетинговых материалов об «универсальном формате обмена», часто требуют использовать современный формат EnterpriseData (ED) и инструмент Конвертация данных 3.0 (КД 3). Но насколько это технически реализуемо, если одна из баз (УПП) работает на старой платформе 1С:Предприятие 8.2? Рассмотрим этот вопрос подробно, проанализируем все технические риски и подготовим железные аргументы для обоснования правильного архитектурного выбора.
Если коротко ответить на вопрос «Взлетит ли EnterpriseData на 8.2?», то ответ будет следующим: взлетит, но только после долгой работы «напильником», огромных финансовых затрат и с высокими рисками постоянных сбоев при эксплуатации.
Давайте разберем по шагам ключевые технические проблемы, с которыми столкнется разработчик при попытке запустить обмен через EnterpriseData на платформе 8.2 в конфигурации УПП:
Чтобы понять, почему для обмена между двумя конкретными базами (УПП и ERP) использование EnterpriseData часто является архитектурной ошибкой, давайте проанализируем разницу между КД 2 и КД 3 на простом жизненном примере.
Представим себе контейнер с товаром, который приехал на склад:
Вывод: В КД 2.0 правила (инструкция) передаются вместе с данными. В КД 3.0 (EnterpriseData) правила жестко прописаны внутри баз (источника и приемника). Любое изменение формата требует доработки кода и в источнике, и в приемнике.
Многие ошибочно считают EnterpriseData «универсальным» форматом в значении «могу передать все что угодно». Это не так. Он универсален только потому, что он стандартизирован фирмой 1С под типовые операции.
Если в вашем обмене между УПП и ERP есть специфические бизнес-данные, уникальные регистры сведений, кастомные реквизиты документов, которых нет в стандартной ERP, то передать их через ED напрямую будет невозможно. Вам придется:
AdditionalInfo (ДополнительныеСведения) в формате JSON, а на стороне ERP писать сложный парсер «напильником», что полностью убивает всю идею «красивого универсального формата».Если заказчик (или руководство) настаивает на использовании EnterpriseData, аргументируя это тем, что «это современно, и в будущем УПП все равно заменят на ERP, поэтому давайте сразу делать на ED», предоставьте ему следующие прагматичные аргументы:
1. Экономический аргумент (ROI и TCO)
Внедрение поддержки EnterpriseData в УПП 1.3 потребует сотен часов дорогостоящей разработки (адаптация модулей БСП, переписывание функций платформы 8.3 под 8.2, ручное создание правил КД3). Поскольку УПП в обозримом будущем подлежит выводу из эксплуатации, эти огромные инвестиции никогда не окупятся. Они будут списаны в ноль в момент отключения УПП. Использование классической КД 2.0 для временного обмена обойдется в разы дешевле и быстрее.
2. Технологические риски
Платформа 8.2 физически не оптимизирована под объемы сериализации XDTO, используемые в EnterpriseData. Мы рискуем получить постоянные падения службы сервера 1С при выгрузке больших пакетов данных. Кроме того, внедрение модулей новой БСП в УПП создаст «конфликт версий» внутри конфигурации, что приведет к неявным ошибкам в других подсистемах.
3. Усложнение поддержки целевой ERP
Для того чтобы ERP могла принимать нестандартные данные из УПП через EnterpriseData, нам придется дорабатывать модуль МенеджерОбменаЧерезУниверсальныйФормат на стороне ERP (создавать расширения, переопределять логику БСП). В результате конфигурация ERP потеряет свою типовую чистоту, а последующие обновления ERP станут значительно сложнее и дороже. При использовании КД 2.0 вся специфика обмена хранится во внешнем XML-файле правил обмена и никак не затрагивает конфигурацию ERP.
Если решение принято авторитарно и вам все же приходится реализовывать EnterpriseData на УПП под платформой 8.2, не пытайтесь переносить туда всю БСП. Используйте обходные технологические решения:
Разберем алгоритм адаптации:
Пример схемы ручного формирования простейшего заголовка файла EnterpriseData на платформе 8.2:
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.ОткрытьФайл(ПутьКФайлу, "UTF-8");
ЗаписьXML.ЗаписатьОбъявлениеXML();
// Записываем корневой элемент с пространствами имен EnterpriseData
ЗаписьXML.ЗаписатьНачалоЭлемента("Message", "http://v8.1c.ru/EDI/Exchange/EnterpriseData/1.8");
ЗаписьXML.ЗаписатьСоответствиеПространстваИмен("xsi", "http://www.w3.org/2001/XMLSchema-instance");
ЗаписьXML.ЗаписатьСоответствиеПространстваИмен("xs", "http://www.w3.org/2001/XMLSchema");
// Запись заголовка сообщения
ЗаписьXML.ЗаписатьНачалоЭлемента("Header");
ЗаписьXML.ЗаписатьНачалоЭлемента("FormatVersion");
ЗаписьXML.ЗаписатьТекст("1.8");
ЗаписьXML.ЗаписатьКонецЭлемента(); // FormatVersion
ЗаписьXML.ЗаписатьКонецЭлемента(); // Header
// Здесь идет логика выборки данных и записи тела сообщения...
ЗаписьXML.ЗаписатьКонецЭлемента(); // Message
ЗаписьXML.Закрыть();
Для обмена «УПП (8.2) — ERP (8.3)» самым разумным, стабильным и экономически оправданным решением является использование Конвертации данных 2.0. Для перехода с УПП на ERP у фирмы 1С и сообщества уже есть готовые, отлаженные годами правила обмена на КД 2.0.
Пытаться внедрить EnterpriseData на платформе 8.2 — это неоправданный технологический риск, который увеличит бюджет проекта в разы, не принеся при этом никаких практических дивидендов заказчику.