Как перенести документ из одной базы 1С в другую с помощью JSON и XDTO?

← На главную

При организации обмена данными между информационными базами 1С часто возникает задача не просто передать ссылку на объект, а полностью перенести документ со всеми его реквизитами и табличными частями. Использование формата JSON в сочетании с механизмами XDTO является одним из самых производительных и современных способов решения этой задачи. В этой статье мы разберем, как правильно реализовать такой перенос, на что обратить внимание при работе с разными конфигурациями и как избежать типичных ошибок, таких как «битые ссылки» или дублирование документов.

Различие между сериализацией ссылки и объекта

Разберем типичную ситуацию: когда мы используем метод СериализаторXDTO.ЗаписатьJSON(ЗаписьJSON, Ссылка), в результирующий файл попадает только уникальный идентификатор (UUID) и текстовое представление ссылки. Этого достаточно, если объект уже существует в базе-приемнике. Однако, если нам нужно создать новый документ, необходимо сериализовать не ДокументСсылка, а ДокументОбъект. Рассмотрим, как это выглядит в коде:


// На стороне отправителя
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();

// Получаем объект документа, а не ссылку
ДокументОбъект = СсылкаНаДокумент.ПолучитьОбъект();

// Сериализуем именно объект
СериализаторXDTO.ЗаписатьJSON(ЗаписьJSON, ДокументОбъект, НазначениеТипаXML.Явное);

СтрокаJSON = ЗаписьJSON.Закрыть();
// Теперь СтрокаJSON содержит все данные документа (реквизиты, ТЧ)

Проанализируем этот подход: при сериализации объекта 1С автоматически включает в JSON все данные, которые необходимы для воссоздания документа в другой базе. Это избавляет нас от ручного перебора всех реквизитов.

Восстановление документа в базе-приемнике

На стороне приемника (например, внутри метода веб-сервиса) нам необходимо выполнить обратную операцию. Мы получаем строку JSON и должны превратить ее обратно в объект 1С. Посмотрим на пример реализации:


// На стороне приемника
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(ПолученнаяСтрокаJSON);

// Десериализуем данные обратно в объект документа
НовыйОбъект = СериализаторXDTO.ПрочитатьJSON(ЧтениеJSON, Тип("ДокументОбъект.РеализацияТоваровУслуг"));

// Теперь НовыйОбъект — это незаписанный ДокументОбъект со всеми заполненными данными
НовыйОбъект.Записать(РежимЗаписиДокумента.Запись);

Важно помнить: если конфигурации базы-отправителя и базы-приемника идентичны, этот способ работает идеально «из коробки». Если же структуры метаданных отличаются, СериализаторXDTO может выдать ошибку при несовпадении состава реквизитов.

Работа с уникальными идентификаторами (UUID)

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

Рассмотрим алгоритм действий:

Извлечь UUID из JSON-сообщения (обычно передается отдельным полем или извлекается из свойств ссылки).
Проверить наличие документа в базе по этому UUID.
Если документ найден — получить его и заполнить данными.
Если не найден — создать новый и принудительно назначить ему полученный UUID.


// Пример установки ссылки для нового объекта
СсылкаНаОбъект = Документы.РеализацияТоваровУслуг.ПолучитьСсылку(Новый УникальныйИдентификатор(ЗначениеUUIDИзJSON));
НовыйОбъект.УстановитьСсылкуНового(СсылкаНаОбъект);
НовыйОбъект.Записать();

Проблема «Битых ссылок» и предварительная подготовка

Посмотрим на ситуацию, когда документ содержит ссылки на справочники (например, «Контрагенты» или «Номенклатура»), которых еще нет в базе-приемнике. В этом случае СериализаторXDTO создаст объект, но в реквизитах будет отображаться надпись «Объект не найден».

Чтобы этого избежать, мы рекомендуем два пути:

Предварительная выгрузка: Сначала передавать все связанные справочники, а затем сам документ.
Создание «заглушек»: Если справочник не найден в приемнике, программно создавать пустой элемент с нужным UUID, который будет заполнен данными позже.

Использование Enterprise Data для разных конфигураций

Если конфигурации баз сильно различаются (например, обмен между Бухгалтерия предприятия и ERP Управление предприятием), стандартная сериализация прикладных типов может оказаться слишком жесткой. В таких случаях правильно будет использовать формат Enterprise Data.

Рассмотрим преимущества этого метода:

Стандартизация: Данные передаются в виде универсальных объектов, описанных в XDTO-пакете ExchangeMessage.
Независимость: Базе-отправителю не нужно знать внутреннюю структуру базы-приемника.
Встроенные механизмы: В большинстве современных конфигураций 1С уже есть менеджеры обмена, которые умеют преобразовывать объекты в этот формат.

Использование REST API и OData

Разберем еще один альтернативный способ, который позволяет избежать написания кода на стороне приемника. Если включить в базе-приемнике стандартный интерфейс OData, то создание документа можно выполнить простым HTTP-запросом (POST) из базы-отправителя.

В этом случае база-отправитель формирует JSON-структуру, соответствующую требованиям OData, и отправляет ее. Платформа 1С на стороне приемника самостоятельно распознает типы, сопоставит реквизиты и создаст объект. Это значительно упрощает архитектуру, так как не требует разработки собственных веб-сервисов.

Настройка процесса сериализации

Для тонкой настройки процесса обмена мы можем использовать объект НастройкиСериализацииJSON. Это позволяет управлять форматом дат, обработкой спецсимволов и другими параметрами. Например, перевод дат в стандарт ISO 8601 гарантирует, что данные будут корректно прочитаны даже если в будущем вы решите передавать JSON во внешнюю систему (не на 1С).

Подведем итог: перенос документа через JSON — это мощный инструмент, требующий внимания к деталям. Мы проанализировали основные подходы от простой сериализации через СериализаторXDTO до использования Enterprise Data и OData. Выбор конкретного метода зависит от идентичности ваших баз и требований к надежности обмена.