При настройке обмена данными между современными конфигурациями 1С, такими как Зарплата и управление персоналом 3.1 и Бухгалтерия предприятия 3.0, разработчики часто сталкиваются с ситуацией, когда правила конвертации (КД 2.1) ведут себя непредсказуемо. Распространенный сценарий: при использовании обработки «Универсальный обмен данными в формате XML» данные выгружаются полностью, но стоит запустить тот же обмен через План обмена или типовую подсистему обмена данными, как в файл попадают только ссылки (наименование и код), а остальные реквизиты (дата рождения, ИНН, СНИЛС) игнорируются.
В этой статье мы подробно разберем, почему это происходит, проанализируем механизмы кэширования правил в БСП (Библиотеке стандартных подсистем) и выясним, какие шаги необходимо предпринять, чтобы заставить систему выгружать все необходимые свойства объекта.
Рассмотрим ситуацию на примере справочника ФизическиеЛица. В правилах конвертации объектов (ПКО) прописаны все необходимые правила конвертации свойств (ПКС). При выгрузке через универсальную обработку движок КД 2.1 последовательно обходит каждое ПКС и записывает данные в XML. Однако при работе через механизм планов обмена в игру вступает подсистема обмена данными БСП, которая использует обработку КонвертацияОбъектовИнформационныхБаз.
Выясним основную причину: современные конфигурации не читают файл правил xml напрямую с диска в момент выполнения обмена. Они хранят эти правила внутри информационной базы в специальном кэше. Если вы внесли изменения в правила в конфигурации «Конвертация данных», сохранили их в файл, но не обновили их в самой базе-источнике, система продолжит использовать старую версию правил, где нужные ПКС могли быть отключены или отсутствовать.
Это самый важный шаг при работе с типовыми конфигурациями на базе БСП. Рассмотрим алгоритм действий для принудительного обновления кэша правил:
ПравилаДляОбменаДанными (через функции для технического специалиста или через настройки синхронизации данных).Проанализируем, что происходит в этот момент: система считывает XML-файл, разбирает его структуру и сохраняет в виде скомпилированных данных. Если этого не сделать, даже физическое удаление старого файла правил с диска не поможет, так как обмен будет работать на «памяти» регистра.
Многие разработчики считают, что если обмен односторонний (например, только из ЗУП в БП), то правила для принимающей стороны (корреспондента) не нужны. Это заблуждение при использовании механизмов БСП.
Система обмена данными БСП требует наличия правил и для «той стороны» (корреспондента), чтобы корректно сопоставить метаданные. Если правила корреспондента отсутствуют или не актуальны, движок обмена может переключиться в защищенный режим выгрузки только базовых реквизитов (ссылок), так как он «не знает», сможет ли приемник принять дополнительные поля.
Для решения этой проблемы необходимо:
Посмотрим на пример кода, который часто используется в типовых правилах для физических лиц. В обработчике ПоследовательностьПолейПоиска может быть заложена логика, которая влияет на состав выгружаемых полей, если они используются для идентификации.
ПоляПоискаМассив = Новый Массив;
Если ЗначениеЗаполнено(СвойстваПоиска["СтраховойНомерПФР"]) Тогда
ПоляПоискаМассив.Добавить("СтраховойНомерПФР");
КонецЕсли;
Если ЗначениеЗаполнено(СвойстваПоиска["ИНН"]) Тогда
ПоляПоискаМассив.Добавить("ИНН");
КонецЕсли;
Если ЗначениеЗаполнено(СвойстваПоиска["ДатаРождения"]) Тогда
ПоляПоискаМассив.Добавить("Наименование,ДатаРождения");
КонецЕсли;
Если НомерВариантаПоиска <= ПоляПоискаМассив.Количество() Тогда
СтрокаИменСвойствПоиска = ПоляПоискаМассив[НомерВариантаПоиска-1];
Иначе
ПрекратитьПоиск = Истина;
КонецЕсли;
Рассмотрим также обработчик ПослеВыгрузкиВФайл. В типовых правилах ЗУП 3.1 часто используется вызов алгоритмов для сбора контактной информации или паспортных данных, которые не хранятся напрямую в реквизитах справочника:
// Пример вызова алгоритма для сбора дополнительных сведений
Выполнить(Алгоритмы.ВыгрузитьСведенияФизическогоЛица);
Если вы «вычищали» правила и случайно удалили вызов этого алгоритма, то такие данные, как ФИО (как периодический реквизит) или паспортные данные, перестанут попадать в файл выгрузки, даже если в ПКС они настроены. Это связано с тем, что в ЗУП 3.1 многие реквизиты являются «виртуальными» и заполняются запросом к регистрам сведений именно в этих обработчиках.
Еще одна причина, по которой свойства могут не выгружаться — это режим работы плана обмена. Рассмотрим ситуацию: объект был изменен, но в плане обмена зарегистрировалась только сама ссылка на объект, а не изменение его конкретных реквизитов (если используется механизм выборочной регистрации).
Проанализируем шаги для проверки:
В некоторых случаях БСП оптимизирует выгрузку: если система считает, что объект уже был выгружен ранее и в нем ничего не менялось, она может отправить только ссылку для синхронизации, игнорируя заполнение всех ПКС. Обновление правил в регистре (как описано в Решении 1) обычно сбрасывает этот механизм и заставляет систему выполнить полную выгрузку свойств согласно новым правилам.
Подведем итог. Если вы столкнулись с «пустой» выгрузкой ПКС в КД 2.1 при использовании планов обмена, придерживайтесь следующего плана действий:
ПриВыгрузке и ПослеВыгрузки, если не уверены, что данные хранятся в обычных реквизитах справочника, а не в регистрах сведений.Следуя этим правилам, вы обеспечите стабильную и полную передачу данных между конфигурациями 1С любой сложности.