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