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