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