Почему при переносе из ЗУП 2.5 в ЗУП 3.1 задвоился зарплатный проект и как восстановить лицевые счета сотрудников?

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

Причины разделения проектов и «исчезновения» счетов

Выясним причину такого поведения типовых правил переноса данных:

1. Различия в структуре метаданных: В ранних версиях ЗУП 2.5 лицевые счета сотрудников могли фиксироваться в регистре сведений с прямой привязкой к справочнику Банки, а поле зарплатного проекта оставалось пустым. При переносе алгоритм проверяет: если проект указан — данные переносятся в него, а если поле пустое, но указан банк — автоматически создается новый элемент справочника ЗарплатныеПроекты с наименованием банка.
2. Связь лицевых счетов и мест выплат в ЗУП 3.1: В новой редакции информация о счетах хранится в регистре сведений ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам с жестким разрезом по измерениям ФизическоеЛицо, Организация и ЗарплатныйПроект. Если в кадровых данных или настройках организации местом выплаты назначен один проект, а счет перенесен в другой, программа не видит номер счета при автоматическом заполнении документов.
3. Рассинхронизация регистров: При переносе данных запись о выбранном зарплатном проекте в регистре МестаВыплатыЗарплатыСотрудников может не совпадать с проектом, к которому привязан лицевой счет в регистре ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам.

Способ 1. Объединение дублей зарплатных проектов штатными средствами ЗУП 3.1

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

1. Перейдем в раздел Администрирование → Обслуживание → Корректировка данных → Поиск и удаление дублей.
2. В поле выбора объекта укажем справочник Зарплатные проекты.
3. Нажмем кнопку Найти дубли. Выберем оба проекта, указав корректный элемент в качестве оригинального, а лишний — в качестве дубля.
4. Нажмем кнопку Объединить.

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

Способ 2. Программная синхронизация регистров выплат и лицевых счетов

Если проекты должны остаться разделенными, но в регистре мест выплаты сотрудникам указан не тот зарплатный проект, к которому привязан действующий счет, исправим данные с помощью программной обработки. Напишем код, который выбирает актуальный зарплатный проект из регистра лицевых счетов и перезаписывает его в регистр мест выплаты.

Посмотрим на пример кода внешней обработки:

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|	МестаВыплаты.Сотрудник.ГоловнаяОрганизация КАК СотрудникГоловнаяОрганизация,
|	МестаВыплаты.Сотрудник КАК Сотрудник,
|	МестаВыплаты.МестоВыплаты КАК МестоВыплаты,
|	ЛицевыеСчета.ЗарплатныйПроект КАК ЗарплатныйПроект
|ИЗ
|	РегистрСведений.МестаВыплатыЗарплатыСотрудников КАК МестаВыплаты
|	ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЛицевыеСчетаСотрудниковПоЗарплатнымПроектам.СрезПоследних КАК ЛицевыеСчета
|		ПО МестаВыплаты.ФизическоеЛицо = ЛицевыеСчета.ФизическоеЛицо
|		И МестаВыплаты.Сотрудник.ГоловнаяОрганизация = ЛицевыеСчета.Организация
|ГДЕ
|	МестаВыплаты.МестоВыплаты <> ЛицевыеСчета.ЗарплатныйПроект
|	И МестаВыплаты.Сотрудник.ГоловнаяОрганизация = &Организация
|УПОРЯДОЧИТЬ ПО
|	МестаВыплаты.Сотрудник.Наименование";

Запрос.УстановитьПараметр("Организация", ВыбраннаяОрганизация);

НачатьТранзакцию();
Выборка = Запрос.Выполнить().Выбрать();

Пока Выборка.Следующий() Цикл
	НаборЗаписей = РегистрыСведений.МестаВыплатыЗарплатыСотрудников.СоздатьНаборЗаписей();
	НаборЗаписей.ОбменДанными.Загрузка = Истина;
	НаборЗаписей.Отбор.Сотрудник.Установить(Выборка.Сотрудник);
	НаборЗаписей.Прочитать();
	
	Для Каждого Запись Из НаборЗаписей Цикл
		Запись.МестоВыплаты = Выборка.ЗарплатныйПроект;
	КонецЦикла;
	
	НаборЗаписей.Записать();
КонецЦикла;

ЗафиксироватьТранзакцию();

Проанализируем работу этого алгоритма: использование свойства ОбменДанными.Загрузка = Истина позволяет отключить избыточные платформенные проверки и безопасно актуализировать измерения набора записей в рамках одной транзакции.

Способ 3. Подготовка данных в исходной базе ЗУП 2.5 (перед повторным переносом)

Если перенос выполняется в тестовом режиме и планируется его повторение, целесообразно устранить первопричину непосредственно в базе-источнике:

1. Откроем регистр сведений Лицевые счета работников организации в ЗУП 2.5.
2. Проверим заполнение реквизита Зарплатный проект по всем физическим лицам. В записях не должно быть пустых значений зарплатного проекта при указанном банке.
3. Устраним дубли в справочниках Банки и Контрагенты, привязанных к зарплатным проектам.
4. Пометить на удаление или очистить устаревшие неактуальные записи закрытых счетов, чтобы они не создавали фантомных ссылок при выгрузке.

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