При интеграции разнородных конфигураций 1С — в частности, нетиповой или отраслевой базы («Автосервис») на платформе 8.2 с обычными формами и современной конфигурации «Бухгалтерия предприятия 3.0» на управляемых формах — разработчики сталкиваются с серией прикладных вопросов: какую технологию обмена использовать, как не допустить появления задвоенных элементов и как поведет себя система при массовой регистрации изменений. Рассмотрим подробно архитектуру построения такого обмена данными и разберем по шагам ключевые этапы настройки.
Выясним причину, почему в данной связке не всегда применим современный универсальный формат (EnterpriseData) и конфигурация «Конвертация данных 3.0» (КД 3.0). Универсальный формат жестко привязан к наличию современных версий «Библиотеки стандартных подсистем» (БСП версии 2.2 и выше) и XDTO-пакетов в обеих базах. В старых решениях на платформе 8.2 эти механизмы отсутствуют, а их внедрение вручную требует огромных трудозатрат.
Именно поэтому оптимальным и стабильным решением остается «Конвертация данных 2.1» (КД 2.1), формирующая правила конвертации в формате XML. Она позволяет гибко описывать логику выгрузки и загрузки объектов между любыми структурами метаданных независимо от версии конфигурации и платформы.
Рассмотрим, как физически передавать пакеты данных между базой на 8.2 и базой на 8.3:
HTTPСоединение, мы можем настроить приём пакетов в «Бухгалтерии 3.0» через HTTP-сервис. База 8.2 выгружает XML-сообщение и отправляет его POST-запросом в базу 8.3.V83.COMConnector напрямую между 8.2 и 8.3 крайне не рекомендуется из-за конфликтов регистрации библиотек comcntr.dll разных версий и разрядностей в операционной системе.Один из главных страхов при внедрении обмена в работающую базу бухгалтерии — появление дублей справочников («Контрагенты», «Номенклатура», «Договоры контрагентов»). Разберем, обязательно ли создавать чистую базу бухгалтерии и переносить остатки с нуля.
Начинать базу с нуля не требуется. В правилах КД 2.1 в правилах конвертации объектов (ПКО) можно настроить каскадный алгоритм сопоставления с помощью обработчика «Поля поиска»:
ИНН и КПП, для номенклатуры — Артикул или связка Наименование + родительская группа.СоответствияОбъектовИнформационныхБаз. Если ранее обмен велся через внешний файл (например, DBF с сопоставлением GUID), достаточно написать разовую обработку, которая заполнит этот регистр связками «УникальныйИдентификаторИсточника — СсылкаПриемника». При последующих загрузках КД будет использовать эти связи, гарантируя отсутствие дублей.Проанализируем работу механизма регистрации изменений. По умолчанию включенное свойство Авторегистрация в планах обмена фиксирует объект при абсолютно любой его перезаписи. Если бухгалтер перепроведет документы за прошлый месяц, в очередь регистрации попадут тысячи записей. Приемник способен переварить огромные объемы данных (десятки тысяч документов), однако синхронная обработка такого пакета заблокирует работу пользователей.
Для предотвращения подобных ситуаций реализуем избирательную регистрацию через подписки на события:
Авторегистрация = Запретить.ПриЗаписи для регистрируемых документов.
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Проверяем, изменились ли ключевые данные документа
Если НеобходимаРегистрацияВОбмене(Источник) Тогда
ПланОбменаСсылка = ПланыОбмена.ОбменСБухгалтерией.НайтиПоКоду("БП");
Если ЗначениеЗаполнено(ПланОбменаСсылка) Тогда
ПланыОбмена.ЗарегистрироватьИзменения(ПланОбменаСсылка, Источник);
КонецЕсли;
КонецЕсли;
Посмотрим на важные правила при обработке больших очередей на стороне «Бухгалтерии предприятия 3.0»:
Только запись (свойство РежимЗаписи = РежимЗаписиДокумента.Запись в правилах КД), проводя их отложенно регламентным заданием в фоне. Это исключит взаимные блокировки таблиц и ошибки, связанные с блокировкой закрытых периодов («Дата запрета изменения данных»).