Как перенести справочник Сотрудники при обмене через EnterpriseData между ЗУП 3 и УАТ 2?

← На главную

При переходе с устаревших систем (например, «УАТ 1») на современные конфигурации («УАТ 2» и «ЗУП 3») разработчики часто сталкиваются с неожиданным поведением типовой синхронизации. Одной из самых частых проблем является отсутствие справочника Сотрудники в списке переносимых объектов. В то время как ФизическиеЛица синхронизируются успешно, отсутствие сотрудников блокирует работу кадрового учета и заполнение путевых листов в транспортных системах. Разберем подробно, почему так происходит и как решить эту задачу в рамках технологий КД3 (EnterpriseData) и КД2.

Анализируем причину отсутствия справочника в EnterpriseData

Прежде чем приступать к разработке, давайте выясним причину, по которой фирма «1С» исключила Сотрудники из стандартного состава EnterpriseData. Согласно методологии, формат EnterpriseData ориентирован на передачу бизнес-сущностей, общих для всех систем. ФизическоеЛицо — это человек, который существует вне контекста конкретной базы. Сотрудник же — это служебная сущность, описывающая отношение этого лица к конкретной организации (трудовой договор, табельный номер, условия работы).

Предполагается, что в системе-приемнике (например, «1С:Бухгалтерия» или «1С:УАТ») справочник Сотрудники либо не нужен в полном объеме, либо должен создаваться автоматически на основании данных о физлице. Однако в «УАТ 2» справочник Сотрудники является ключевым для работы с водителями, экипажами и графиками. Рассмотрим, как мы можем восстановить этот поток данных.

Решение 1: Доработка обмена через расширения КД3

Это наиболее правильный путь с точки зрения сохранения типовой конфигурации на поддержке. Механизм EnterpriseData позволяет расширять состав передаваемых данных без изменения кода основной конфигурации. Проанализируем шаги, необходимые для реализации этого метода:

Создание расширения XDTO-пакета. Нам необходимо создать расширение в обеих базах (ЗУП и УАТ). В расширении мы создаем свой тип данных, который будет описывать структуру справочника Сотрудники.
Регистрация изменений в правилах отправки. Используем обработчики в модуле менеджера обмена. Нам понадобится процедура ПриОтправкеДанных, где мы опишем логику выгрузки сотрудника вместе с его физлицом.
Обработка загрузки в приемнике. В УАТ 2 создаем обработчик, который при получении данных о физлице будет проверять наличие соответствующего сотрудника и, при необходимости, создавать или обновлять его.

Рассмотрим пример кода, который может использоваться для регистрации изменений при выгрузке объектов в КД3:


Процедура ПередВыгрузкойОбъекта(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена) Экспорт
    Если ТипЗнч(ДанныеИБ) = Тип("СправочникСсылка.Сотрудники") Тогда
        // Описываем логику заполнения свойств XDTO из реквизитов справочника
        ДанныеXDTO.ТабельныйНомер = ДанныеИБ.Код;
        ДанныеXDTO.Наименование = ДанныеИБ.Наименование;
    КонецЕсли;
КонецПроцедуры

Решение 2: Перенос данных через дополнительные свойства Физических лиц

Если задача стоит в минимальной доработке и нужно передать только базовую информацию (например, Табельный номер), можно воспользоваться механизмом дополнительных свойств EnterpriseData. Посмотрим, как это работает:

В формате EnterpriseData у многих объектов есть коллекция ДополнительныеРеквизиты. Мы можем программно добавить в эту коллекцию данные о сотруднике (его ссылку или код) при выгрузке ФизическогоЛица из ЗУП. На стороне УАТ в обработчике ПослеЗагрузки мы считываем эти свойства и программно создаем элемент в справочнике Сотрудники, устанавливая связь с загруженным физлицом.

Преимущества этого метода:

Не нужно изменять XDTO-пакеты.
Минимальный риск сломать типовой обмен при обновлении конфигураций.
Легко реализовать для простых сценариев «один человек — один сотрудник».

Решение 3: Использование «Универсального обмена» КД 2.1

Иногда требования бизнеса таковы, что штатный обмен через ED не покрывает всех потребностей, а разработка в КД3 кажется слишком трудоемкой. В этом случае можно прибегнуть к старому доброму способу — правилам конвертации данных 2.1. Рассмотрим, как интегрировать этот механизм в современную среду:

Хотя в «УАТ 2» и «ЗУП 3» основным является EnterpriseData, техническая возможность загрузки через XML по правилам КД 2.1 сохраняется. Для этого используется обработка УниверсальныйОбменДаннымиXML. Для подготовки правил обмена можно использовать модифицированную конфигурацию Конвертация Данных 2.1.

Проанализируем алгоритм настройки такого обмена:

Создаем правила конвертации в конфигурации «Конвертация данных 2.1».
В качестве источника выбираем ЗУП 3, в качестве приемника — УАТ 2.
Настраиваем синхронизацию справочника Сотрудники, используя поиск по уникальному идентификатору или комбинации «Физлицо + Организация».
Для автоматизации процесса создаем регламентное задание, которое будет запускать внешнюю обработку выгрузки/загрузки по расписанию.

Важный момент: При использовании КД 2.1 в базах на управляемых формах следует использовать версию обработки, адаптированную под них, чтобы избежать ошибок инициализации COM-соединения или работы с файловой системой.

Выводы и выбор стратегии

Проанализировав ситуацию, мы видим три пути:

1. Типовой путь (EnterpriseData): Подходит, если вы готовы к созданию расширений и работе с XDTO. Это наиболее перспективный метод, который сохранит целостность системы в будущем. 2. Гибридный путь (Доп. реквизиты): Лучший вариант для быстрой передачи небольшого количества кадровых данных без серьезного вмешательства в структуру обмена. 3. Альтернативный путь (КД 2.1): Рекомендуется, если у вас уже есть готовые наработки из старых версий (УАТ 1) и вам нужно быстро запустить процесс, не вникая в архитектуру КД3.

Помните, что справочник Сотрудники в 1С 8.3 тесно связан с периодами действия договоров и организационной структурой. При любом способе переноса следите за тем, чтобы ФизическоеЛицо всегда загружалось раньше или одновременно с Сотрудником, чтобы избежать появления «битых» ссылок в базе приемнике.