При работе с современными конфигурациями на платформе 1С:Предприятие 8.3, такими как Зарплата и управление персоналом 3.1 и ERP Управление предприятием 2, разработчики часто сталкиваются с вопросом: куда исчезли привычные правила обмена? Если раньше мы привыкли искать XML-файлы в макетах конфигурации или планах обмена, то теперь архитектура взаимодействия изменилась. Давайте разберем, как устроена современная синхронизация через универсальный формат и как мы можем на нее повлиять.
Для начала проанализируем фундаментальное отличие. В старых решениях использовалась технология Конвертация данных 2.0. Правила (ПКО, ПКС) хранились в виде громоздких XML-структур. Современный обмен базируется на технологии EnterpriseData и Конвертации данных 3.0. Главная особенность здесь в том, что вся логика трансформации данных из объектной модели информационной базы в формат обмена (и обратно) теперь описывается программным кодом.
Рассмотрим, где именно в конфигурации «спрятаны» эти правила. Основная логика сосредоточена в специализированных модулях менеджеров. Посмотрим на список ключевых объектов:
МенеджерОбменаЧерезУниверсальныйФормат.Именно в этих модулях объявлены все правила выгрузки и загрузки для каждого документа или справочника. Вместо визуального редактора правил мы видим процедуры и функции, которые программно заполняют поля XDTO-пакетов.
Выясним причину, по которой прямая правка этих модулей является плохой идеей. Как справедливо отмечено в обсуждении, конфигурации ERP и ЗУП обновляются часто. При каждом обновлении (например, при переходе с версии 2.5.7 на 2.5.8) типовой модуль МенеджерОбменаЧерезУниверсальныйФормат будет полностью перезаписан. Чтобы наши доработки сохранились, мы должны использовать механизм расширений.
Разберем по шагам, как перехватить логику обмена в расширении. Нам необходимо использовать программные события, которые предоставляет платформа для модификации данных в момент синхронизации. Чаще всего используются следующие обработчики:
ПриОтправкеДанных — позволяет модифицировать данные перед их упаковкой в XML.ПриПолученииДанных — используется для дополнительной обработки объекта после его загрузки в базу-приемник.ПриВыгрузке_Документ_ВедомостьНаВыплатуЗарплаты.Рассмотрим пример кода, который можно разместить в расширении для изменения логики заполнения данных при выгрузке:
&После("ПРиВыгрузке_Документ_ВедомостьНаВыплатуЗарплаты")
Процедура Расш1_ПРиВыгрузке_Документ_ВедомостьНаВыплатуЗарплаты(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
// Добавляем свою логику заполнения реквизита
Если ДанныеИБ.Организация.Код = "00001" Тогда
ДанныеXDTO.ДополнительнаяИнформация = "Спецвыплата для филиала";
КонецЕсли;
КонецПроцедуры
Несмотря на то, что правила теперь — это код, нам все еще нужен инструмент для проектирования этих правил. Для этого разработана конфигурация «Конвертация данных, редакция 3.0». Проанализируем алгоритм работы с ней:
ВыгрузкаМетаданных.epf.МенеджерОбменаЧерезУниверсальныйФормат.Этот подход позволяет избежать ошибок ручного написания кода при сопоставлении сложных структур XDTO-пакетов.
Если данные уходят из ЗУП, но не появляются в ERP (или загружаются некорректно), нам необходимо выяснить причину. Посмотрим на основные способы отладки:
1. Анализ регистраций. Используем обработку Регистрация изменений для обмена данными. Она покажет, какие объекты «стоят в очереди». Если объект зарегистрирован, но не уходит, возможно, в правилах стоит фильтр или возникает ошибка при выгрузке.
2. Проверка XML-сообщений. В настройках синхронизации данных можно включить режим сохранения файлов обмена в локальную папку. Проанализируем содержимое сформированного файла. Это поможет понять, на какой стороне проблема: если в XML данные верные — ищем ошибку в приемнике, если неверные — в источнике.
3. Журнал регистрации. При ошибках обмена через универсальный формат в журнале регистрации фиксируются детальные ошибки XDTO. Часто это связано с тем, что в правилах ожидается обязательное поле, которое в базе не заполнено. Ищите записи с типом Событие: Данные.СинхронизацияДанных.
Важно помнить, что EnterpriseData сильно завязана на уникальные идентификаторы (GUID) и ключевые поля. Рассмотрим ситуацию: если вы создали сотрудника «Иванов» вручную в обеих базах, механизм обмена может создать дубль. Чтобы этого избежать, убедитесь, что настроены правила сопоставления по уникальным полям:
Организации: ИНН + КПП.ФизическихЛиц: СНИЛС или ФИО + Дата рождения.Контрагентов: ИНН + КПП.Если типовых полей поиска недостаточно, вы можете переопределить их в коде менеджера обмена, добавив свои условия поиска существующих объектов в базе-приемнике.
При настройке обмена между ЗУП и ERP всегда обращайте внимание на версию формата EnterpriseData (например, 1.13 или 1.15). Если вы обновили ERP до версии, которая поддерживает формат 1.15, а ЗУП остался на старой версии, поддерживающей только 1.10, обмен может завершиться ошибкой из-за несовместимости схем. Всегда старайтесь поддерживать актуальные релизы обеих конфигураций, чтобы избежать конфликтов в структуре передаваемых XML-пакетов.
Таким образом, мы выяснили, что современный обмен — это гибкий программный инструмент. Хотя он требует более глубоких знаний программирования, чем старая «Конвертация 2.0», он обеспечивает гораздо более высокую скорость работы и стабильность при масштабных внедрениях 1С:ERP.