Как организовать надежный обмен данными между доработанной и типовыми базами 1С?

← На главную

При сопровождении нескольких информационных баз 1С часто возникает задача: передавать документы и справочники из центральной доработанной базы в типовые базы по конкретным организациям. Попытки использовать простую обработку ВыгрузкаЗагрузкаДанныхXML в таких сценариях регулярно приводят к ошибкам при загрузке, а стандартный РИБ (распределенная информационная база) не подходит из-за различий в структуре метаданных. Разберем, почему возникают сбои и какие архитектурные решения позволяют настроить стабильный односторонний или двусторонний обмен, не требующий ручной корректировки при каждом обновлении конфигураций.

Почему обработка «ВыгрузкаЗагрузкаДанныхXML» дает сбои на неидентичных базах?

Обработка ВыгрузкаЗагрузкаДанныхXML использует механизм жесткой XDTO-сериализации платформы с помощью методов ЗаписатьXML() и ПрочитатьXML(). Этот инструмент предназначен исключительно для переноса данных между базами с полностью совпадающей структурой метаданных. Проанализируем основные причины сбоев:

Несоответствие состава реквизитов: Если в центральной базе в типовой документ (например, ДокументСсылка.ПлатежноеПоручение) добавлены новые реквизиты, табличные части или изменен состав типов, сериализатор выгружает их в XML. База-приемник при чтении файла не находит этих объектов в своей схеме метаданных и аварийно завершает операцию.
Отсутствие сопоставления по полям поиска: Обработка переносит объекты строго по внутренним идентификаторам (GUID). При отсутствии гибкой логики поиска и сопоставления ссылочных типов возникают дубли или битые ссылки.
Невозможность частичной загрузки: Механизм не позволяет пропустить отсутствующие в приемнике поля — объект либо загружается целиком по строгой схеме, либо вызывает исключение.

Роль плана обмена в организации синхронизации

Важно понимать разделение зон ответственности в платформе 1С: сам по себе объект метаданных ПланОбмена не выполняет передачу данных. Его назначение — фиксация изменений (служба регистрации изменений). Механизм регистрирует факт изменения объектов с помощью таблиц изменений, а выборка выполняется методом ПланыОбмена.ВыбратьИзменения().

Формирование пакета данных, маршрутизация, трансформация структуры и транспорт (файлы, веб-сервисы, COM, прямые HTTP-запросы) реализуются прикладным кодом или библиотеками, такими как БСП (Библиотека стандартных подсистем).

Решение 1. Синхронизация через универсальный формат EnterpriseData (КД 3.0)

Использование универсального формата обмена (EnterpriseData) — наиболее масштабируемый и устойчивый к обновлениям подход для современных конфигураций на базе БСП.

Формат EnterpriseData опирается на фиксированную XDTO-схему бизнес-сущностей, а не на метаданные конкретной конфигурации. Если в центральной базе добавлены нетиповые реквизиты, типовой менеджер выгрузки просто не включит их в стандартные XML/JSON-сообщения, благодаря чему база-приемник гарантированно примет пакет.

Пошаговый порядок настройки:

В центральной и типовых базах используется типовой план обмена «Синхронизация данных через универсальный формат».
В правилах регистрации данных настраивается фильтрация по нужным организациям, чтобы документы распределялись только в соответствующие базы-приемники.
Если требуется передать специфические доработанные данные, обработчики формата переопределяются в модуле МенеджерОбменаЧерезУниверсальныйФорматПереопределяемый с помощью расширения конфигурации (аннотации &Вместо, &После). Основная конфигурация при этом остается на полной поддержке.

Решение 2. Использование правил обмена «Конвертации данных 2.0»

Если конфигурации сильно различаются или требуется переносить документы с движениями регистров, оптимальным вариантом остается разработка правил в конфигурации «1С:Конвертация данных 2.1» и использование обработки УниверсальныйОбменДаннымиXML.

Преимущества данного способа:

Устойчивость к изменениям: Правила сопоставляют только явно указанные реквизиты. Новые поля, добавленные в ходе обновлений или доработок, игнорируются и не ломают процесс обмена.
Гибкая синхронизация: Возможность сопоставления объектов по полям поиска (ИНН, КПП, артикул, код) без жесткой привязки к GUID.
Автоматизация по расписанию: Правила обмена можно загрузить в типовой план обмена или вызывать обработку УниверсальныйОбменДаннымиXML регламентным заданием в фоновом режиме.

Посмотрим на пример программного вызова выгрузки по правилам КД 2.0:


ОбработкаОбмена = Обработки.УниверсальныйОбменДаннымиXML.Создать();
ОбработкаОбмена.ИмяФайлаПравил = "C:\Exchange\Rules.xml";
ОбработкаОбмена.ИмяФайлаДанных = "C:\Exchange\Message.xml";
ОбработкаОбмена.РежимОбмена = "Выгрузка";
ОбработкаОбмена.ЗагрузитьПравилаОбмена();
ОбработкаОбмена.ВыполнитьВыгрузку();

Решение 3. Прямая интеграция через COM-соединение или HTTP-сервисы

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

Через COM-соединение (V83.COMConnector): Центральная база регистрирует изменения в собственном плане обмена, подключается к базам-приемникам по COM и напрямую создает или обновляет типовые документы. В базе-приемнике не создаются узлы планов обмена, а процесс выполняется незаметно в фоновом режиме.
Через HTTP-сервисы (REST API): В базах-приемниках публикуется типовой или кастомный HTTP-сервис. Центральная база формирует JSON-пакеты и отправляет их методом POST. Это устраняет зависимость от разрядности платформы и версий COM-компонентов.

Архитектурная рекомендация: вынос доработок в расширение

Для долговременной стабильности центральной базы рекомендуется вынести все добавленные реквизиты, документы и справочники в расширение конфигурации (.cfe). В этом случае основная конфигурация центральной базы возвращается к полностью типовому состоянию (идентичному базам-приемникам). Это устраняет конфликты метаданных при типовых обменах и существенно упрощает установку регулярных обновлений от поставщика.