При организации обмена между несколькими базами 1С:Бухгалтерия 3.0 часто возникает задача регулярной синхронизации по расписанию. Типовой механизм обмена через универсальный формат (EnterpriseData) позволяет связать конфигурации, но на практике пользователи сталкиваются с тем, что часть важных документов (например, ТребованиеНакладная или складские акты) не переносятся автоматически из одной базы в другую.
Разберем подробно, почему возникает такая ситуация, как устроена синхронизация через универсальный формат и что необходимо сделать для добавления недостающих документов в обмен.
Механизм обмена на базе универсального формата предназначен для взаимодействия различных информационных баз. В отличие от старых механизмов обмена, здесь сопоставление объектов выполняется не через регистр сведений СоответствияОбъектовИнформационныхБаз, а с использованием регистра ПубличныеИдентификаторыОбъектов. Это обеспечивают устойчивость обмена при обновлениях конфигурации.
Однако при типовой настройке обмена «Другая программа» в правилах выгрузки могут отсутствовать определенные типы документов. Направление передачи объектов строго регламентировано:
Проанализируем типовые правила обмена 1С:Бухгалтерия 3.0. По умолчанию в формате EnterpriseData для конфигурации БП 3.0 обработка документа ТребованиеНакладная может быть реализована только на стороне *приема*. Это означает, что конфигурация умеет читать и проводить incoming XML-структуру документа, но в план обмена на *выгрузку* этот документ не включен. Аналогичная ситуация встречается и с другими первичными документами (передача материалов в эксплуатацию, ведомости в банк и т.д.).
Если необходимо настроить регулярную отправку документа из базы-источника в базу-приемник, выполним следующие шаги:
Выясним, входит ли нужный документ в состав плана обмена. Для обмена через универсальный формат используется план обмена СинхронизацияДанныхЧерезУниверсальныйФормат.
СинхронизацияДанныхЧерезУниверсальныйФормат.ДокументСсылка.ТребованиеНакладная).Чтобы система понимала, в какой момент документ должен попадать в очередь на отправку, проверим подписки на события:
ЗарегистрироватьИзмененияДокумента...).После того как документ научился регистрироваться к выгрузке, необходимо описать, как именно объект 1С превращается в формат XDTO и наоборот:
КД3 (Конвертация данных 3.0) или редактора правил формируем изменения для модуля МенеджерОбменаЧерезУниверсальныйФормат.AdditionalInfo (Дополнительная Информация), которое поддерживается большинством типов XDTO-пакета EnterpriseData. Это позволит передать дополнительные данные без изменения XDTO-схем.Чтобы сохранить возможность беспрепятственного автоматического обновления конфигураций, все изменения рекомендуется вносить через расширение конфигурации (файл .cfe):
СинхронизацияДанныхЧерезУниверсальныйФормат и нужный документ.&Вместо или &После переопределяются методы модуля МенеджерОбменаЧерезУниверсальныйФормат.Если обе базы имеют одинаковый релиз 1С:Бухгалтерии 3.0, использование универсального формата EnterpriseData не всегда является единственным и самым быстрым решением. Рассмотрим альтернативные варианты:
Штатный механизм РИБ идеально подходит для однородных конфигураций одинакового релиза. Он позволяет настроить автоматический обмен по расписанию без потери специфических бухгалтерских данных и без написания правил конвертации. Фильтрация данных по конкретным организациям настраивается прямо в узлах РИБ.
Создание собственного HTTP-сервиса на стороне базы-приемника и регламентного задания в базе-источнике позволяет передавать документы в формате JSON или XML (через СериализаторXDTO). Этот способ обеспечивает высокую скорость работы, отсутствием лишних служебных записей и точный контроль над процессом проведения документов.
Поскольку метаданные баз идентичны, объекты можно сериализовать напрямую с помощью системного объекта СериализаторXDTO без трансформации в промежуточные форматы конвертации.