Как объединить две базы 1С:ЗУП 3.1 в одну и избежать критических ошибок при расчете зарплаты?

← На главную

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

Анализ проблемы: почему стандартный РИБ ломает базу-приемник?

Выясним, почему попытка использовать встроенный план обмена РИБ (Распределенная информационная база) по организации часто оборачивается катастрофой. С первого взгляда идея кажется изящной: мы создаем пустой узел в центральной базе, подменяем его существующей базой присоединяемой организации и запускаем обмен. Однако на практике этот метод приводит к полной неработоспособности функций начисления зарплаты во всех организациях приемника.

Причина кроется в механизме идентификации данных. План обмена РИБ при загрузке данных ориентируется исключительно на уникальные идентификаторы объектов (UUID). Если объекты в базе-источнике создавались автономно, их UUID гарантированно не совпадут с аналогичными объектами в базе-приемнике (даже если это стандартные предопределенные элементы, такие как показатели расчетов, валюты или производственные календари). В результате в базе-приемнике перезаписываются системные связи, либо образуется каша из дублированных элементов, что парализует работу программных модулей, отвечающих за автоматический расчет начислений.

Почему возникает ошибка «деление на ноль» при расчете зарплаты?

Проанализируем конкретную ошибку, с которой сталкиваются разработчики после неудачного слияния баз: отказ проведения документов и ошибка деления на ноль при автозаполнении документа «Начисление зарплаты».

В ЗУП 3.1 расчет формул критически зависит от показателей расчета (таких как НормаДней, ВремяВЧасах, Оклад). При переносе документов начислений система пытается сопоставить формулы с показателями. Если в процессе слияния уникальный идентификатор показателя НормаДней в базе-приемнике заменяется идентификатором из базы-источника, либо ломается связь с графиком работы сотрудника (производственным календарем), программа не может получить числовое значение времени. Показатель нормы дней становится равен нулю, что при расчете тарифной ставки по формуле (например, Оклад / НормаДней * ВремяВДнях) неизбежно приводит к исключительной ситуации «Деление на ноль».

Более того, ломаются интервальные регистры, такие как КадроваяИсторияСотрудниковIntervaly и ПлановыеНачисленияИнтервальный. Данные регистры хранят срез информации в виде временных интервалов, и прямое некорректное вмешательство в их структуру через РИБ нарушает целостность всей кадровой истории программы.

Пошаговая инструкция по слиянию данных через обработку «Универсальный обмен данными XML»

Рассмотрим рабочий и безопасный метод слияния баз с помощью внешней обработки ВыгрузкаЗагрузкаДанныхXML (или стандартной «Универсальный обмен данными в формате XML»). Этот метод позволяет гибко управлять составом выгружаемых объектов и избегать затирания критически важных системных настроек базы-приемника.

Разберем процесс по шагам:

Подготовка баз. Перед началом любых манипуляций обязательно создаем резервные копии обеих информационных баз (источника и приемника). Убеждаемся, что релизы конфигураций ЗУП 3.1 в обеих базах абсолютно идентичны. Если это не так, обновляем обе базы до одного и того же релиза.
Настройка выгрузки в источнике. Запускаем обработку ВыгрузкаЗагрузкаДанныхXML в базе присоединяемой организации (базе-источнике). На вкладке выгрузки выбираем только необходимые справочники (организации, подразделения, физические лица, сотрудники, штатное расписание) и документы (кадровые документы, документы начислений, выплаты). Важный нюанс: устанавливаем флаг «Выгружать документы с движениями». Это позволит перенести документы вместе с их записями в регистрах накопления и расчетов, исключая необходимость их массового перепроведения в базе-приемнике.
Исключение системных констант и настроек. Снимаем флажки с системных справочников и регистров, которые могут нарушить работу приемника. К ним относятся: константы, производственные календари, показатели расчета, настройки учетной политики (если они общие для базы), а также предопределенные виды начислений и удержаний.
Загрузка в приемник. Открываем обработку в базе-приемнике и загружаем сформированный XML-файл. Обращаем внимание, что данный процесс может занять значительное время в зависимости от объема данных.

Как бороться с дублями предопределенных объектов и видов расчетов?

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

Поиск и удаление дублей. Используем встроенную в ЗУП 3.1 обработку «Поиск и удаление дублей» (раздел Администрирование — Обслуживание — Корректировка данных).
Производственные календари. Если перенеслись дубли производственных календарей (например, два календаря «Российская Федерация»), необходимо объединить их, выбрав в качестве правильного элемента тот календарь, который изначально был в базе-приемнике.
Плановые начисления и удержания. При переносе документов начисления в базу могли попасть дубли видов расчетов (например, два вида расчета «Оклад»). Чтобы исправить это, с помощью обработки поиска дублей заменяем дублирующие виды начислений на оригинальные начисления приемника. Обращаем внимание: если формулы или настройки начислений в присоединяемой организации отличались, возможно, потребуется создать уникальное начисление (например, «Оклад (Дельфин)»), но делать это нужно осознанно, не допуская бесконтрольного размножения предопределенных элементов.

Перенос независимых регистров сведений — критически важный шаг

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

ГражданствоФизическихЛиц — хранит сведения о гражданстве сотрудников, необходимые для корректного расчета страховых взносов.
ВоинскийУчет — содержит данные для воинского учета.
ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам — информация о номерах карт и банковских счетах для выплаты зарплаты.
СтандартыРаскрытияИнформацияОСтраховомСтаже — регистры по учету стажа сотрудников.

При переносе данных регистров через XML важно следить за тем, чтобы записи по физическим лицам корректно связались с их новыми карточками в базе-приемнике (сопоставление должно происходить по СНИЛС и ИНН).

Альтернативный метод: Слияние через «Конвертацию данных 2.1» (КД)

Если объем баз велик, а ручная чистка дублей после XML-переноса пугает своей трудоемкостью, лучшим решением будет написание индивидуальных правил обмена в конфигурации «Конвертация данных 2.1». Это позволит настроить точные правила сопоставления объектов «на лету» в момент загрузки.

Рассмотрим ключевые правила настройки ПКО (Правил конвертации объектов):

Физические лица. В ПКО для справочника ФизическиеЛица настраиваем поиск по полям СтраховойНомерПФР (СНИЛС) и ИНН. Это гарантирует, что если один и тот же человек работал в обеих организациях, в базе-приемнике не создастся дубль физического лица, а данные объединятся.
Сотрудники. Поиск настраиваем по полям Код (если коды уникализированы) или по связке Наименование + ГоловнаяОрганизация.
Подразделения. Настраиваем поиск по полям Наименование + Владелец (где владельцем выступает конкретная Организация). Это исключит склеивание одноименных подразделений (например, «Бухгалтерия») разных юридических лиц.

Чтобы документы при переносе не вызывали ошибок проведения из-за отсутствия каких-то промежуточных данных в регистре, в обработчике «После загрузки» для всех документов прописываем отключение транзакционных проверок платформы. Посмотрим на пример кода:


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

Этот код гарантирует, что движения документов запишутся в базу-приемник в том виде, в каком они существовали в источнике, без инициации тяжелых и часто сбойных алгоритмов проведения ЗУП.

Метод перехода через облачные технологии (выгрузка для сервиса)

Упомянем еще один альтернативный инструмент, встроенный в современные типовые конфигурации 1С. Это механизм выгрузки данных для перехода в облачный сервис (формат EnterpriseData). Проанализируем его работу: в базе-источнике мы запускаем мастер выгрузки данных в сервис (раздел Администрирование — Переход в сервис). Система формирует zip-архив, содержащий данные в универсальном формате. При загрузке этого архива в базу-приемник платформа задействует встроенные правила интеграции, которые автоматически сопоставляют ключевые справочники (по ИНН, КПП, СНИЛС) и воссоздают кадровые и расчетные данные. Этот метод более бережно относится к бизнес-логике, чем простой XML-перенос таблиц БД, однако он также требует финального контроля и удаления возможных дублей вспомогательных справочников.