Как настроить и доработать синхронизацию данных через универсальный формат в 1С:Бухгалтерия 3.0?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса
← На главную

При организации обмена между несколькими базами 1С:Бухгалтерия 3.0 часто возникает задача регулярной синхронизации по расписанию. Типовой механизм обмена через универсальный формат (EnterpriseData) позволяет связать конфигурации, но на практике пользователи сталкиваются с тем, что часть важных документов (например, ТребованиеНакладная или складские акты) не переносятся автоматически из одной базы в другую.

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

Особенности синхронизации через универсальный формат (EnterpriseData)

Механизм обмена на базе универсального формата предназначен для взаимодействия различных информационных баз. В отличие от старых механизмов обмена, здесь сопоставление объектов выполняется не через регистр сведений СоответствияОбъектовИнформационныхБаз, а с использованием регистра ПубличныеИдентификаторыОбъектов. Это обеспечивают устойчивость обмена при обновлениях конфигурации.

Однако при типовой настройке обмена «Другая программа» в правилах выгрузки могут отсутствовать определенные типы документов. Направление передачи объектов строго регламентировано:

  1. Загрузка (получение) документа: Чтобы целевая база могла принять и создать документ, достаточно наличия логики обработки данного документа в алгоритмах менеджера обмена целевой базы. Доработка состава конфигурации-приемника обычно не требуется.
  2. Выгрузка (отправка) документа: Чтобы база-источник отправила документ в поток данных, объект обязан входить в состав состава соответствующего плана обмена и регистрироваться при изменениях.

Почему не переносятся складские и другие документы?

Проанализируем типовые правила обмена 1С:Бухгалтерия 3.0. По умолчанию в формате EnterpriseData для конфигурации БП 3.0 обработка документа ТребованиеНакладная может быть реализована только на стороне *приема*. Это означает, что конфигурация умеет читать и проводить incoming XML-структуру документа, но в план обмена на *выгрузку* этот документ не включен. Аналогичная ситуация встречается и с другими первичными документами (передача материалов в эксплуатацию, ведомости в банк и т.д.).

Пошаговый алгоритм добавления документа в синхронизацию

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

Шаг 1. Проверка и изменение состава плана обмена

Выясним, входит ли нужный документ в состав плана обмена. Для обмена через универсальный формат используется план обмена СинхронизацияДанныхЧерезУниверсальныйФормат.

  1. Найдем в дереве метаданных план обмена СинхронизацияДанныхЧерезУниверсальныйФормат.
  2. Перейдем в состав плана обмена и проверим наличие нужного документа (например, ДокументСсылка.ТребованиеНакладная).
  3. Если документ отсутствует, включаем его в состав данного плана обмена с авторегистрацией Запретить (или Наследовать, в зависимости от логики правил регистрации).

Шаг 2. Настройка подписок на события и правил регистрации объектов (ПРО)

Чтобы система понимала, в какой момент документ должен попадать в очередь на отправку, проверим подписки на события:

  1. Добавим необходимый документ в типы источника для подписок на события, отвечающих за регистрацию изменений для универсального формата (например, подписки типа ЗарегистрироватьИзмененияДокумента...).
  2. Откорректируем правила регистрации объектов (ПРО) через Конвертацию Данных, чтобы отключить ненужную регистрацию изменений для узлов других организаций или несоответствующих условий. Это предотвратит неограниченный рост таблицы регистратора.

Шаг 3. Доработка менеджера обмена и правил конвертации (ПОО/ПКО)

После того как документ научился регистрироваться к выгрузке, необходимо описать, как именно объект 1С превращается в формат XDTO и наоборот:

  1. С помощью обработки КД3 (Конвертация данных 3.0) или редактора правил формируем изменения для модуля МенеджерОбменаЧерезУниверсальныйФормат.
  2. Определяем правила конвертации объекта (ПКО) и правила обработки объектов (ПОО) для нужного документа.
  3. Если необходимо передать специфичные реквизиты, отсутствующие в базовой схеме XDTO, задействуем стандартное поле AdditionalInfo (Дополнительная Информация), которое поддерживается большинством типов XDTO-пакета EnterpriseData. Это позволит передать дополнительные данные без изменения XDTO-схем.

Доработка без снятия конфигурации с поддержки

Чтобы сохранить возможность беспрепятственного автоматического обновления конфигураций, все изменения рекомендуется вносить через расширение конфигурации (файл .cfe):

  1. В расширение добавляется план обмена СинхронизацияДанныхЧерезУниверсальныйФормат и нужный документ.
  2. В расширении создаются или перехватываются подписки на события для регистрации изменений.
  3. С помощью аннотаций &Вместо или &После переопределяются методы модуля МенеджерОбменаЧерезУниверсальныйФормат.

Альтернативные способы синхронизации однородных баз

Если обе базы имеют одинаковый релиз 1С:Бухгалтерии 3.0, использование универсального формата EnterpriseData не всегда является единственным и самым быстрым решением. Рассмотрим альтернативные варианты:

  1. Распределенная информационная база (РИБ) с отбором по организациям:

    Штатный механизм РИБ идеально подходит для однородных конфигураций одинакового релиза. Он позволяет настроить автоматический обмен по расписанию без потери специфических бухгалтерских данных и без написания правил конвертации. Фильтрация данных по конкретным организациям настраивается прямо в узлах РИБ.

  2. HTTP-сервисы и REST API в расширении:

    Создание собственного HTTP-сервиса на стороне базы-приемника и регламентного задания в базе-источнике позволяет передавать документы в формате JSON или XML (через СериализаторXDTO). Этот способ обеспечивает высокую скорость работы, отсутствием лишних служебных записей и точный контроль над процессом проведения документов.

  3. Прямая XDTO-сериализация:

    Поскольку метаданные баз идентичны, объекты можно сериализовать напрямую с помощью системного объекта СериализаторXDTO без трансформации в промежуточные форматы конвертации.

← На главную