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

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

При интеграции разнородных конфигураций 1С — в частности, нетиповой или отраслевой базы («Автосервис») на платформе 8.2 с обычными формами и современной конфигурации «Бухгалтерия предприятия 3.0» на управляемых формах — разработчики сталкиваются с серией прикладных вопросов: какую технологию обмена использовать, как не допустить появления задвоенных элементов и как поведет себя система при массовой регистрации изменений. Рассмотрим подробно архитектуру построения такого обмена данными и разберем по шагам ключевые этапы настройки.

Выбор инструмента: «Конвертация данных 2.1» против «Конвертации данных 3.0»

Выясним причину, почему в данной связке не всегда применим современный универсальный формат (EnterpriseData) и конфигурация «Конвертация данных 3.0» (КД 3.0). Универсальный формат жестко привязан к наличию современных версий «Библиотеки стандартных подсистем» (БСП версии 2.2 и выше) и XDTO-пакетов в обеих базах. В старых решениях на платформе 8.2 эти механизмы отсутствуют, а их внедрение вручную требует огромных трудозатрат.

Именно поэтому оптимальным и стабильным решением остается «Конвертация данных 2.1» (КД 2.1), формирующая правила конвертации в формате XML. Она позволяет гибко описывать логику выгрузки и загрузки объектов между любыми структурами метаданных независимо от версии конфигурации и платформы.

Способ взаимодействия информационных баз

Рассмотрим, как физически передавать пакеты данных между базой на 8.2 и базой на 8.3:

  1. Файловый обмен (каталог, FTP): Классический и наиболее надежный способ. База-источник формирует XML-файл выгрузки по правилам КД 2.1, а база-приемник считывает его по расписанию через регламентное задание. Исключает конфликты версий библиотек.
  2. Сетевые сервисы (HTTP/SOAP): Поскольку платформа 8.2 не позволяет поднимать собственные HTTP-сервисы, но умеет отправлять запросы объектом HTTPСоединение, мы можем настроить приём пакетов в «Бухгалтерии 3.0» через HTTP-сервис. База 8.2 выгружает XML-сообщение и отправляет его POST-запросом в базу 8.3.
  3. Ограничения COM-соединения: Использование V83.COMConnector напрямую между 8.2 и 8.3 крайне не рекомендуется из-за конфликтов регистрации библиотек comcntr.dll разных версий и разрядностей в операционной системе.

Синхронизация без дублирования: сопоставление объектов

Один из главных страхов при внедрении обмена в работающую базу бухгалтерии — появление дублей справочников («Контрагенты», «Номенклатура», «Договоры контрагентов»). Разберем, обязательно ли создавать чистую базу бухгалтерии и переносить остатки с нуля.

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

  1. Первичный поиск по внутреннему идентификатору (GUID): Если элемент ранее уже выгружался и сопоставлялся, он моментально находится по ссылке.
  2. Поиск по ключевым реквизитам: Если по GUID объект не найден, система ищет совпадение по реквизитам. Для контрагентов это сочетание ИНН и КПП, для номенклатуры — Артикул или связка Наименование + родительская группа.
  3. Использование регистра соответствий: В типовой конфигурации «Бухгалтерия предприятия 3.0» предусмотрен регистр сведений СоответствияОбъектовИнформационныхБаз. Если ранее обмен велся через внешний файл (например, DBF с сопоставлением GUID), достаточно написать разовую обработку, которая заполнит этот регистр связками «УникальныйИдентификаторИсточника — СсылкаПриемника». При последующих загрузках КД будет использовать эти связи, гарантируя отсутствие дублей.

Управление планом обмена и защита от лавинообразной нагрузки

Проанализируем работу механизма регистрации изменений. По умолчанию включенное свойство Авторегистрация в планах обмена фиксирует объект при абсолютно любой его перезаписи. Если бухгалтер перепроведет документы за прошлый месяц, в очередь регистрации попадут тысячи записей. Приемник способен переварить огромные объемы данных (десятки тысяч документов), однако синхронная обработка такого пакета заблокирует работу пользователей.

Для предотвращения подобных ситуаций реализуем избирательную регистрацию через подписки на события:

  1. В свойствах плана обмена для нужных объектов устанавливаем Авторегистрация = Запретить.
  2. Создаем подписку на событие ПриЗаписи для регистрируемых документов.
  3. В обработчике проверяем, изменились ли значимые для бухгалтерского учета реквизиты, и обязательно исключаем зацикливание при загрузке:

Если Источник.ОбменДанными.Загрузка Тогда
    Возврат;
КонецЕсли;

// Проверяем, изменились ли ключевые данные документа
Если НеобходимаРегистрацияВОбмене(Источник) Тогда
    ПланОбменаСсылка = ПланыОбмена.ОбменСБухгалтерией.НайтиПоКоду("БП");
    Если ЗначениеЗаполнено(ПланОбменаСсылка) Тогда
        ПланыОбмена.ЗарегистрироватьИзменения(ПланОбменаСсылка, Источник);
    КонецЕсли;
КонецЕсли;

Посмотрим на важные правила при обработке больших очередей на стороне «Бухгалтерии предприятия 3.0»:

  1. Асинхронность выгрузки: Не выполняйте выгрузку пакета интерактивно прямо в момент нажатия кнопки «Провести и закрыть». Фиксируйте изменения через план обмена, а саму передачу доверьте регламентному заданию, запускаемому по расписанию каждые несколько минут.
  2. Разделение записи и проведения: При масштабном импорте документов безопаснее загружать их с установкой режима Только запись (свойство РежимЗаписи = РежимЗаписиДокумента.Запись в правилах КД), проводя их отложенно регламентным заданием в фоне. Это исключит взаимные блокировки таблиц и ошибки, связанные с блокировкой закрытых периодов («Дата запрета изменения данных»).
← На главную