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