В практике автоматизации кадрового учета и расчета зарплаты часто возникает задача синхронизации данных между идентичными конфигурациями 1С:Зарплата и Управление Персоналом 3 (ЗУП). Наиболее частный случай, который мы разберем в этой статье, — это необходимость выделить данные по одной конкретной организации из общей базы в отдельную, либо настроить постоянный поток данных из одной базы в другую.
Рассмотрим, какие инструменты предоставляет платформа и конфигурация, проанализируем их плюсы и минусы, и выберем оптимальную стратегию в зависимости от конечной цели.
В процессе обсуждения мы выделили четыре основных подхода к решению задачи. Давайте подробно проанализируем каждый из них.
Многие разработчики первым делом обращают внимание на формат EnterpriseData. Это современный стандарт обмена от 1С. Однако при попытке применить его для задачи "ЗУП — ЗУП" мы сталкиваемся с серьезными ограничениями.
Проблема: Формат EnterpriseData изначально проектировался для обмена между разными конфигурациями (например, ЗУП и Бухгалтерия, или ЗУП и ERP). Его цель — передать финансово значимую информацию для бухгалтерского или управленческого учета.
Если мы посмотрим на типовые правила регистрации, то увидим, что:
Таким образом, использовать EnterpriseData для создания полной копии данных или для полноценного разделения баз — не рекомендуется. Вы рискуете потерять часть кадровой истории.
Использование протокола OData или написание собственных HTTP-сервисов для передачи данных в формате JSON кажется заманчивым вариантом для программистов, привыкших к веб-технологиям. Однако, давайте разберем подводные камни этого метода применительно к сложной конфигурации ЗУП.
Сложность реализации:
При использовании OData нам придется самостоятельно программировать логику создания объектов. ЗУП 3 — это конфигурация с огромным количеством связей.
Разберем пример создания сотрудника. Это не просто запись в справочнике Сотрудники. Это цепочка взаимосвязанных объектов:
ФизическиеЛица (персональные данные).Сотрудники (ссылка на физлицо, вид занятости).Если мы будем передавать объекты через JSON, нам придется решать проблему сопоставления ссылок (GUID). Если передавать данные без сохранения оригинальных GUID, то при повторной синхронизации возникнут дубли. Сопоставление по полям поиска (например, по ФИО или СНИЛС) работает ненадежно при наличии однофамильцев или опечаток.
Проблема регистров расчета: Главная сложность ЗУП — это не справочники, и даже не документы, а записи регистров расчета. Если мы перенесем документ "Начисление зарплаты" через JSON и попытаемся его провести в новой базе, результат расчета может отличаться от оригинала. Это происходит из-за различий в настройках, версиях программы или отсутствия исторических данных для расчета среднего заработка.
Вывод: написание своего обмена — это путь постоянного "допиливания" и отладки, требующий огромных трудозатрат.
Если задача стоит в регулярном обмене данными между базами, то стандартный механизм РИБ (План обмена Полный или ОбменВРаспределеннойИнформационнойБазе) — это наиболее надежное решение.
Преимущества РИБ:
Если необходимо выгружать данные только по одной организации, можно использовать РИБ с фильтром. В настройках узла плана обмена можно указать отбор по организации. Тогда в периферийную базу уйдут данные только по выбранному юрлицу.
Однако РИБ требует дисциплины: нельзя обновлять конфигурацию периферийной базы отдельно от центральной. Обновление всегда приходит из центра.
В ходе обсуждения мы выяснили, что конечная цель — это разовое отделение данных (принцип "одна база — одна организация"). Для этой задачи лучше всего подходит метод создания полной копии с последующей очисткой.
Давайте разберем алгоритм действий, который гарантирует корректность данных:
Шаг 1. Создание полной копии
Мы берем рабочую базу и копируем её. Это гарантирует, что все настройки программы, учетная политика, штатное расписание и, главное, движения регистров расчета перенесутся "как есть". Цифры начисленной зарплаты и налогов останутся неизменными.
Шаг 2. Маркировка объектов к удалению
В копии базы нам необходимо удалить данные по "лишним" организациям. Для этого можно воспользоваться стандартной обработкой УдалениеПомеченныхОбъектов, но сначала нужно пометить на удаление огромный массив документов.
Лучше всего написать простую обработку или воспользоваться готовыми решениями с Инфостарта, которые помечают на удаление документы по отбору. Примерная логика кода для пометки документов:
// Примерный алгоритм пометки документов по лишней организации
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Ссылка
|ИЗ
| Документ.НачислениеЗарплаты
|ГДЕ
| Организация <> &НужнаяОрганизация";
Запрос.УстановитьПараметр("НужнаяОрганизация", СсылкаНаОставляемуюОрганизацию);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектДок = Выборка.Ссылка.ПолучитьОбъект();
ОбъектДок.УстановитьПометкуУдаления(Истина);
КонецЦикла;
Эту операцию нужно проделать для всех видов документов, где есть реквизит Организация.
Шаг 3. Удаление данных
После пометки запускаем стандартную процедуру удаления. Платформа проверит ссылочную целостность. Если какой-то справочник (например, Сотрудники) используется только в удаляемых документах, он тоже может быть удален (если настроить каскадное удаление или пометить его вручную).
Шаг 4. Отключение от главного узла (если использовался РИБ)
Если вы создавали периферийную базу через РИБ для переноса данных, и теперь хотите сделать её самостоятельной, необходимо "отвязать" её от главного узла. Это делается следующим образом:
// Сброс признака РИБ и главного узла
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Подведем итоги. Выбор метода зависит от цели:
1. Идентификаторы объектов (GUID)
При любом способе обмена (кроме ручного ввода) критически важно синхронизировать объекты по УникальныйИдентификатор. Если вы будете искать сотрудников по ФИО, вы неизбежно получите дубли (однофамильцы) или ошибки (смена фамилии при замужестве).
2. Настройки расчета зарплаты
При переносе данных через XML или JSON убедитесь, что настройки начислений и удержаний в базе-приемнике идентичны базе-источнику. Если в базе-приемнике формула расчета оклада отличается, то при перепроведении документа сумма изменится.
3. Регистры накопления и расчета
Помните, что отчеты в ЗУП строятся не по документам, а по регистрам. Обработка ВыгрузкаЗагрузкаДанныхXML позволяет переносить записи регистров напрямую, без перепроведения документов. Это мощный инструмент для исправления ситуаций, когда документ проведен, но движения нужно перенести "как в старой базе".