Синхронизация данных между современными конфигурациями на управляемых формах, такими как ЗУП 3.1, и классическими решениями на обычных формах, как УТ 10.3, является нетривиальной задачей. Основная сложность заключается в разности архитектур хранения данных и зачастую в невозможности вносить изменения в одну из информационных баз. Рассмотрим подробно, как организовать перенос справочника ФизическиеЛица, сохранив конфигурацию источника на поддержке.
Самый надежный и гибкий метод — это создание правил обмена в конфигурации «Конвертация данных 2.1». Проанализируем этот процесс по шагам. Во-первых, нам необходимо выгрузить описания структур обеих баз (метаданные) с помощью обработки MD83Exp.epf. Поскольку УТ 10.3 работает на обычных формах, а ЗУП 3.1 на управляемых, убедитесь, что используете соответствующие версии обработки выгрузки метаданных.
После загрузки структур в КД 2.1 мы создаем «Правила обмена данными». В них настраивается ПКО (Правило конвертации объектов) для справочника ФизическиеЛица. Разберем важные нюансы настройки полей:
ИНН и СНИЛС. Если же базы изначально синхронизированы, можно использовать поиск по GUID (уникальному идентификатору).JSON (согласно стандартам БСП), в то время как в УТ 10.3 это могут быть табличные части или регистр сведений. Для корректного переноса в правилах конвертации (ПКС) для полей адреса придется написать обработчик «При загрузке» на стороне УТ 10.3, который будет разбирать строку JSON и распределять данные по полям Управления торговлей.Для выполнения обмена используем обработку УниверсальныйОбменДаннымиXML.epf. На стороне ЗУП 3.1 она запускается в режиме управляемого приложения, а на стороне УТ 10.3 — как обычная внешняя обработка.
Если ЗУП 3.1 изменять нельзя, но требуется регулярный (например, ежедневный) обмен, воспользуемся механизмом Дополнительных отчетов и обработок. Посмотрим, как это реализовать программно. Мы можем создать внешнюю обработку, которая будет содержать внутри себя макет с правилами обмена и программный код для вызова универсального механизма выгрузки.
Пример кода для программного запуска выгрузки внутри внешней обработки:
// Инициализация обработки универсального обмена
ОбработкаОбмена = Обработки.УниверсальныйОбменДаннымиВФорматеXML.Создать();
ОбработкаОбмена.ИмяФайлаПравил = "C:\Exchange\Rules.xml";
ОбработкаОбмена.ИмяФайлаВыгрузки = "C:\Exchange\Data.xml";
ОбработкаОбмена.РежимОбмена = "Выгрузка";
// Загрузка правил из файла или макета
ОбработкаОбмена.ЗагрузитьПравилаОбмена();
// Выполнение выгрузки
ОбработкаОбмена.ВыполнитьВыгрузку();
Эту обработку мы регистрируем в справочнике Дополнительные отчеты и обработки в ЗУП 3.1. БСП (Библиотека стандартных подсистем) позволяет назначить расписание для таких обработок. Таким образом, конфигурация остается типовой, а выгрузка происходит в автоматическом режиме по расписанию сервера 1С.
Если мы хотим, чтобы УТ 10.3 сама «забирала» данные из ЗУП 3.1, можно воспользоваться механизмом COM-соединения. В типовой обработке универсального обмена в УТ 10.3 есть вкладка «Подключение и выгрузка данных на узле-приемнике». Проанализируем ситуацию: в этом режиме УТ 10.3 выступает инициатором, подключается к базе ЗУП 3.1 через COMConnector, вызывает там правила и считывает данные напрямую в свою память.
Важный технический момент: При использовании COM-соединения часто возникает проблема разрядности. Если сервер 1С 64-битный, а клиент УТ 10.3 32-битный, необходимо настроить Component Services (Службы компонентов) в Windows для регистрации 32-битного comcntcfg.xml. Это позволит избежать ошибки «Класс не зарегистрирован».
Рассмотрим более современный вариант, который не требует изменения ЗУП 3.1. В ЗУП 3.1 можно включить стандартный OData интерфейс. Это позволит базе УТ 10.3 обращаться к справочнику ФизическиеЛица через обычные HTTP-запросы.
Алгоритм действий будет следующим:
OData.HTTPСоединение получает список физических лиц в формате JSON или XML.Пример фрагмента кода в УТ 10.3 для получения данных через OData:
Соединение = Новый HTTPСоединение("server_address", , "user", "password");
Запрос = Новый HTTPЗапрос("/zup_base/odata/standard.odata/Catalog_ФизическиеЛица?$format=json");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
// Разбор JSON и создание объектов
// Используем ЧтениеJSON или парсинг строки
КонецЕсли;
Перед тем как запустить автоматический обмен, проанализируем текущее состояние баз. Если в обеих программах уже заведены физические лица вручную, неизбежно возникнут дубли. Чтобы этого избежать, выполните предварительное сопоставление (мэппинг):
ИНН.ИНН не заполнен, используйте связку ФИО + Дата рождения.GUID из ЗУП 3.1 в какой-нибудь дополнительный реквизит, чтобы при первом обмене правила КД 2.1 точно «увидели» существующий объект.Резюмируем: Для разовых переносов лучше всего подходят правила КД 2.1 с ручным запуском. Для постоянной автоматизации без изменения ЗУП 3.1 оптимально использовать внешнюю обработку в ЗУП, запускаемую по расписанию БСП, которая будет выгружать файл, а УТ 10.3 своим регламентным заданием будет этот файл загружать. Это гарантирует стабильность работы и независимость от обновлений конфигураций.