← На главную

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

Шаг 1. Подготовка и выравнивание баз

Прежде чем приступать к объединению, проанализируем состояние исходных информационных баз. Критически важно, чтобы обе базы (база-источник и база-приемник) имели абсолютно идентичный релиз конфигурации. Даже минимальное различие в версии может привести к тому, что при загрузке данных через XML-формат часть реквизитов или движений по регистрам будет потеряна из-за несовпадения структуры объектов.

Выполним следующие подготовительные действия:

1. Обновим все базы до актуального и одинакового релиза.
2. Проведем процедуру «Тестирование и исправление» (ТиИ) в обеих базах. Это позволит исключить логические ошибки в данных и битые ссылки до того, как они попадут в общую систему.
3. Сделаем полные архивные копии всех баз. Это обязательное правило перед любыми массовыми манипуляциями с данными.
4. Проверим настройки расчета зарплаты (раздел Настройка). Состав используемых начислений, удержаний и настройки кадрового учета должны быть максимально синхронизированы. Например, если в одной базе включена опция использования нескольких тарифных ставок, а в другой — нет, документы кадрового перевода могут загрузиться некорректно.

Шаг 2. Выбор метода переноса данных

Разберем основные инструменты, которые мы можем использовать для слияния баз.

Метод 1. Обработка «Выгрузка и загрузка данных XML»

Это наиболее популярный и доступный метод для идентичных конфигураций. Данная обработка (обычно доступная на диске ИТС или в составе «Инструментов разработчика») позволяет выгрузить все объекты (справочники, документы, константы, регистры) из одной базы и загрузить их в другую. При этом сохраняются внутренние идентификаторы (GUID) объектов, если они уникальны.

Метод 2. Конвертация данных (КД)

Если базы существенно различаются или требуется сложная логика сопоставления объектов (например, «если СНИЛС совпадает, то не создавать новое физлицо, а подцепить существующее»), лучше использовать «1С:Конвертация данных». Это более надежный, но и более трудозатратный метод, требующий написания правил обмена.

Метод 3. Обработка «Выгрузка в идентичную конфигурацию»

На диске ИТС также встречается специализированная обработка для переноса данных между одинаковыми конфигурациями, которая по сути является надстройкой над XML-выгрузкой, упрощающей отбор объектов.

Шаг 3. Процесс загрузки и проблема GUID

Рассмотрим ситуацию, когда мы выбрали метод XML. Мы выгружаем данные из меньшей базы и загружаем их в основную (большую) базу. Сразу после загрузки мы столкнемся с основной проблемой — дублированием справочников.

Поскольку в 1С данные сопоставляются по уникальным идентификаторам (GUID), то физическое лицо «Иванов Иван Иванович», созданное в базе №1 и в базе №2 вручную, будет иметь разные GUID. После объединения в базе окажется два «Иванова», каждый из которых привязан к своим документам. Это же касается графиков работы, подразделений и должностей.

Проанализируем порядок действий по устранению дублей:

1. Физические лица: Это приоритет №1. Используем типовую обработку «Поиск и замена дублей». Склеивать физлиц нужно по полям СНИЛС и ИНН. После объединения физлиц все ссылки в кадровых приказах и регистрах расчетов автоматически перейдут на одного «правильного» человека.
2. Справочники кадровой структуры: Подразделения и должности часто дублируются. Здесь нужно быть осторожным: если подразделения в разных юрлицах называются одинаково, но по факту это разные структуры, их, возможно, стоит оставить как есть, предварительно переименовав.
3. Планы видов расчета (ПВР): Самый сложный этап. Начисления (оклады, премии) и удержания могут задвоиться. Простая замена дублей в ПВР часто не срабатывает из-за настроек вытеснения.

Шаг 4. Решение проблем с начислениями (ПВР)

При объединении баз ЗУП часто возникают дубли в планах видов расчета Начисления и Удержания. Если просто удалить один из видов расчета, система может выдать ошибку, так как он используется в «ведущих» или «вытесняющих» начислениях других объектов.

Разберем алгоритм исправления:

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

Шаг 5. Тонкости расчета налогов (НДФЛ и Взносы)

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

НДФЛ 15% и Предельная база взносов: Когда мы объединяем базы, система начинает видеть общие доходы человека по всем пяти юрлицам. Если один и тот же человек работал по совместительству в разных фирмах, которые раньше были в разных базах, то после слияния:

• Программа увидит суммарный доход и может применить ставку 15% НДФЛ раньше, чем это было в раздельных базах (если доход превысит 5 млн руб.).
• Предельная величина базы для страховых взносов также будет рассчитываться кумулятивно по всем организациям, что может привести к пересчету взносов «задним числом».

Стандартные вычеты: Необходимо проверить, чтобы после объединения вычеты на детей не начали применяться дважды. В одной базе право на вычет для физлица фиксируется общим документом Заявление на вычеты по НДФЛ.

Шаг 6. Расчет среднего заработка

Посмотрим на ситуацию с расчетом отпусков и больничных. Данные для среднего заработка хранятся в специальных регистрах накопления, таких как Данные о начислениях для расчета среднего заработка (общий). При переносе документов XML эти регистры заполняются данными из первичных документов. Однако после замены дублей физических лиц ссылки в этих регистрах могут требовать обновления.

Рекомендуем после объединения выполнить пересчет данных для среднего заработка или воспользоваться обработкой «Обновить данные для расчета среднего заработка» (если она предусмотрена в текущем релизе или расширениях).

Шаг 7. Завершающие операции

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

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

Важный совет: Лучше всего творить слияние баз с начала нового календарного года, сразу после закрытия декабря и сдачи годовой отчетности. Это избавит вас от 90% проблем с пересчетом предельных баз налогов и среднего заработка в текущем периоде.

Таким образом, мы проанализировали процесс объединения баз ЗУП. Помните, что основной объем работы заключается не в самой выгрузке, а в последующем аудите и «склейке» данных, чтобы система продолжала корректно считать зарплату и налоги для всех сотрудников пяти организаций.