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