Задача консолидации данных из нескольких разрозненных баз 1С:Зарплата и Управление Персоналом (ЗУП) в одну общую базу является классической для крупных холдингов и компаний с филиальной структурой. Основная сложность заключается не столько в разовом переносе данных, сколько в организации регулярного, автоматического и безошибочного обмена новыми сведениями. Рассмотрим подробно, как решить эту задачу, обходя стандартные ограничения платформы и типовых конфигураций.
Стандартный механизм Распределенных Информационных Баз (РИБ) удобен тем, что он «из коробки» умеет регистрировать изменения и передавать их между узлами. Однако главной преградой здесь становится требование системы создать начальный образ. Если базы уже существуют и в них есть данные, создание образа — лишний и часто невозможный этап. Разберем, как «обмануть» систему и связать уже существующие базы в топологию РИБ.
Проанализируем пошаговый алгоритм настройки такой связки:
ПоОрганизациям или Полный). Каждому узлу присваиваем уникальный код, соответствующий одной из периферийных баз.
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаУзелВЦентральнойБазе);
Важно: Перед этим необходимо создать в периферийной базе элемент того же плана обмена, который будет представлять центральный узел, и найти его ссылку.
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
// Выполнение операций
ПланыОбмена.УстановитьГлавныйУзел(НужнаяСсылка);
Если РИБ кажется слишком жестким инструментом, рассмотрим вариант с использованием механизма «Замеры изменений» и типовой обработки УниверсальныйОбменДаннымиXML. Многие отказываются от этого способа, считая, что он пригоден только для ручной выгрузки всех данных. Это не так.
Выясним, как автоматизировать этот процесс:
Мы можем создать в конфигурации (или расширении) свой собственный ПланОбмена. Его единственная задача — фиксировать изменения объектов (документов, справочников, регистров). В составе плана обмена мы указываем все нужные нам типы данных.
Далее, мы настраиваем регламентное задание, которое будет запускать обработку выгрузки по расписанию. При выгрузке через УниверсальныйОбменДаннымиXML в параметрах можно указать использование узла плана обмена. В этом случае система выгрузит не все данные, а только те, что зарегистрированы на данном узле. После успешной выгрузки регистрация изменений очищается. Это превращает обычную обработку в полноценный движок одностороннего обмена.
Проанализируем ситуацию, когда программист пытается расширить стандартный обмен через Универсальный формат в ЗУП. Часто добавленные в расширение объекты не появляются в составе передаваемых данных. Почему так происходит?
Разберем основные причины:
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанные() или через специализированные инструменты разработчика для обновления кэша БСП.МенеджерОбменаЧерезУниверсальныйФормат. Править этот модуль в расширении крайне трудозатратно, так как придется переписывать огромные пласты логики формирования JSON/XML.При слиянии данных из нескольких баз ЗУП в одну мы неизбежно столкнемся с проблемой дублей. Рассмотрим подробнее, на что обратить внимание:
Физические лица: Это самый критичный справочник. Один и тот же сотрудник может работать в разных организациях (разные базы), но в консолидированной базе он должен быть представлен одной записью ФизическиеЛица. Если использовать стандартный обмен по GUID, вы гарантированно получите дубли.
Решение: В правилах обмена (КД 2.0) необходимо настроить поиск не по внутреннему идентификатору, а по комбинации СНИЛС + ФИО или ИНН. Это позволит системе сопоставить записи и «склеить» их в центральной базе.
Справочники настроек: Подразделения, Должности, Графики работы. В каждой базе они могут иметь свои GUID. Если выгружать их «как есть», справочники в центральной базе раздуются от одинаковых по названию, но разных по идентификаторам записей. Здесь также поможет настройка поиска по наименованию или коду в рамках владельца (Организации).
На основе практического опыта экспертов (как упоминалось в сообщении 5 форума), наиболее стабильной схемой для консолидации является разделение ответственности:
Такой подход позволяет избежать «мусора» в центральной базе и дает полный контроль над тем, какие данные и как мигрируют между узлами системы. Помните, что консолидация ЗУП требует особого внимания к регистрам расчета и кадровым сведениям — они должны переноситься в строгом соответствии с хронологией, чтобы не нарушить целостность учета в центральной базе.