Рано или поздно перед крупными компаниями или холдингами встает задача консолидации учета. Когда руководство принимает решение объединить несколько разрозненных баз «1С:Зарплата и Управление Персоналом» разных юридических лиц в одну единую базу, перед техническим специалистом возникает серьезный вызов. Кажется, что задача тривиальна — конфигурации одинаковые, структуры данных идентичные. Но «легким движением руки» выполнить слияние не удастся.
В этой статье мы подробно рассмотрим, почему стандартный перенос «в лоб» может разрушить учет, какие технические инструменты лучше всего использовать, и как пошагово решить сопутствующие проблемы с дублированием данных, перерасчетами и бизнес-логикой.
Перед тем как приступить к технической реализации, проанализируем две принципиально разные стратегии переноса данных. Выбор стратегии определяет объем трудозатрат и количество потенциальных ошибок в новой базе.
Давайте подробнее разберем технический арсенал инструментов, которые помогут нам справиться с этой задачей при любом выборе стратегии.
Выясним, с помощью какого программного инструментария мы можем выполнить перенос объектов между идентичными конфигурациями 1С:ЗУП. При консолидации учёта применяется перенос данных между базами 1С:ЗУП 3, включающий выгрузку сотрудников, кадровых документов и расчётных сведений.
Во-первых, рассмотрим стандартную универсальную обработку ВыгрузкаЗагрузкаДанныхXML.epf (она входит в состав состава дистрибутива «Технологическая платформа»). Этот инструмент предназначен для обмена данными между абсолютно идентичными конфигурациями (где совпадают имена объектов, типы реквизитов и структура метаданных). Обработка работает напрямую с UUID (уникальными идентификаторами объектов). Если объект с определенным UUID уже существует в базе-приемнике, он будет перезаписан данными из источника. Это самый быстрый способ, но он таит в себе колоссальные риски дублирования предопределенных элементов и затирания настроек.
Во-вторых, проанализируем использование конфигурации «Конвертация данных 2.1» (КД 2.1). Это наиболее гибкий и безопасный метод. С помощью КД 2.1 мы можем создать правила обмена, где сопоставление ключевых справочников (например, физических лиц) будет происходить не по скрытому идентификатору UUID, а по бизнес-полям (таким как ИНН, СНИЛС, Код или Наименование). Это гарантирует, что один и тот же человек, работавший в разных базах, корректно «склеится» в единую карточку физического лица в базе-приемнике.
В-третьих, при объединении большого количества баз (например, более 5–10 филиалов) имеет смысл использовать механизмы планов обмена. Мы можем настроить временную синхронизацию, перенести основной массив данных на копиях баз в фоновом режиме, а перед запуском пользователей в единую базу быстро довыгрузить только измененные документы (дельту).
Рассмотрим по шагам ключевые технические проблемы, с которыми сталкиваются программисты при слиянии баз 1С:ЗУП 3.1, и разберем методы их локализации.
Если мы просто запустим обработку ВыгрузкаЗагрузкаДанныхXML, то в базе-приемнике неизбежно задвоятся или даже затроятся предопределенные элементы справочников. Это касается таких объектов, как виды расчетов (начисления, удержания), производственные календари, настройки отчетов и т.д. В базах-источниках они имеют разные внутренние UUID, хотя визуально называются одинаково.
Для решения этой проблемы в «Конвертации данных 2.1» для всех ключевых справочников необходимо настроить правило поиска по наименованию или коду, отключив поиск по UUID. Также рекомендуется предварительно очистить или исключить из выгрузки служебные справочники настроек пользователей и вариантов отчетов, настроив их заново в объединенной базе.
Один и тот же сотрудник мог работать по совместительству или переходить из одного юрлица в другое. Соответственно, в разных базах-источниках у него будут созданы разные карточки физических лиц. Нам необходимо объединить их в одно физлицо, но при этом сохранить уникальные карточки сотрудников для каждого юридического лица.
Для сопоставления физлиц настроим поиск по полям СтраховойНомерПФР (СНИЛС) и ИНН. Посмотрим на пример программного алгоритма поиска физлица при загрузке в базу-приемник:
// Пример поиска существующего Физического лица по СНИЛС
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ФизическиеЛица.Ссылка КАК Ссылка
|ИЗ
| Справочник.ФизическиеЛица КАК ФизическиеЛица
|ГДЕ
| ФизическиеЛица.СтраховойНомерПФР = &СНИЛС
| И НЕ ФизическиеЛица.ПометкаУдаления";
Запрос.УстановитьПараметр("СНИЛС", СодержимоеСНИЛС);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
СсылкаНаФизлицо = Выборка.Ссылка; // Используем найденную ссылку
КонецЕсли;
Для справочника Сотрудники сопоставление должно идти по связке: ФизическоеЛицо + Организация + ГоловнаяОрганизация. Чтобы избежать конфликта табельных номеров, на этапе выгрузки необходимо добавить префиксы организаций к кодам сотрудников.
Пользователи в разных базах могли создавать индивидуальные виды начислений с одинаковыми наименованиями, но абсолютно разной логикой расчета (разными формулами). При бездумном слиянии настройки одного начисления перезапишут настройки другого.
Чтобы избежать этой коллизии, проанализируем список начислений в базах-источниках. Уникальные пользовательские начисления перед переносом следует переименовать или добавить к ним префиксы баз-источников. Перенос планов видов расчета Начисления и Удержания должен производиться под строгим контролем методолога расчета заработной платы.
Стандартные механизмы обмена записывают документы в режиме ОбменДанными.Загрузка = Истина. При этом в 1С:ЗУП отключаются все проверки, не выполняются процедуры расчета средних величин и заполнения связанных регистров. Если перенесенные документы просто оставить в базе «как есть», отчетность по налогам и взносам (например, ЕФС-1, РСВ, 6-НДФЛ) соберется некорректно.
Поэтому после загрузки документов необходимо программно запустить их проведение. Разберем пример кода для группового перепроведения загруженных документов определенного типа:
// Перепроведение загруженных документов для корректного формирования регистров
ВыборкаДокументов = Документы.ПриемНаРаботу.Выбрать();
Пока ВыборкаДокументов.Следующий() Цикл
ДокументОбъект = ВыборкаДокументов.ПолучитьОбъект();
Если ДокументОбъект.Проведен Тогда
ДокументОбъект.ОбменДанными.Загрузка = Ложь;
Попытка
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
ЗаписьЖурналаРегистрации("ПереносДанных", УровеньЖурналаРегистрации.Ошибка, , ,
"Не удалось провести документ: " + ДокументОбъект.Ссылка + " Описание: " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
КонецЦикла;
При записи старых документов в базу-приемник система 1С:ЗУП 3.1 автоматически регистрирует необходимость перерасчетов зарплаты за прошлые периоды в регистре сведений ОчередьРасчетаЗарплаты (или связанных таблицах перерасчетов). Это может привести к тому, что при очередном расчете текущего месяца программа начнет массово доначислять или сторнировать суммы за прошлые годы.
Выясним, как с этим бороться. Сразу после успешного переноса и проведения документов необходимо полностью очистить все зарегистрированные записи перерасчетов. Для этого можно воспользоваться типовой обработкой «Перерасчеты» в интерфейсе программы (раздел Зарплата - Сервис - Перерасчеты) или очистить их программным кодом:
// Очистка зарегистрированных перерасчетов после миграции данных
НаборЗаписей = РегистрыСведений.ПерерасчетЗарплаты.СоздатьНаборЗаписей();
// Если требуется очистить перерасчеты по конкретной организации
НаборЗаписей.Отбор.Организация.Установить(СсылкаНаОрганизацию);
НаборЗаписей.Записать(); // Записываем пустой набор для очистки таблицы
Для успешного завершения проекта консолидации рекомендуем придерживаться следующего структурированного плана работы:
ФизическиеЛица по ИНН/СНИЛС, а Организации — по ОГРН/ИНН.Подводя итог, можно утверждать: стандартного софта, который «легким движением руки» сольет разные базы 1С:ЗУП в одну без участия квалифицированного программиста, не существует. Но, вооружившись правильной методологией переноса (срезами на дату), инструментом «Конвертация данных 2.1» и четким планом по сопоставлению НСИ, мы сможем провести этот процесс максимально безболезненно для кадровой службы и бухгалтерии.