Переход с устаревшей редакции 1С:Зарплата и управление персоналом 2.5 на современную 3.1 — это сложный процесс, который часто сопровождается техническими сбоями. Одной из наиболее распространенных проблем является ошибка в программном коде на этапе сопоставления планов видов расчета. Рассмотрим подробнее, почему это происходит и как успешно завершить миграцию данных.
Проанализируем ситуацию, когда при попытке прямого переноса или загрузки данных через файл система выдает ошибку в модуле. Типичный фрагмент кода, на котором происходит прерывание процесса, выглядит следующим образом:
// Корректируем список ведущих по базовым и вытесняющим начислениям.
Для Каждого КлючИЗначение Из ПакетВидовРасчета Цикл
ВидРасчета = КлючИЗначение.Значение;
ВедущиеНачисления = Новый Массив;
// Собираем уже имеющиеся ведущие начисления.
Для Каждого Строка Из ВидРасчета.ВедущиеВидыРасчета Цикл
ВедущиеНачисления.Добавить(Строка.ВидРасчета);
КонецЦикла;
// Если расчетная база определяется за текущий период,
// то базовые виды расчета являются также ведущими.
Если ЕстьПоказательВКоллекции(ВидРасчета.Показатели, "РасчетнаяБаза") Тогда
Для Каждого Строка Из ВидРасчета.БазовыеВидыРасчета Цикл
ВедущиеНачисления.Добавить(Строка.ВидРасчета);
КонецЦикла;
КонецЕсли;
// Ведущие начисления
СвойстваНачисления = СвойстваНачислений[ВидРасчета.КатегорияНачисленияИлиНеоплаченногоВремени];
ОтборВедущих = СвойстваНачисления.ОтборВедущих;
Если ОтборВедущих <> Неопределено И НачислениеРассчитываетсяПоЧасам(ВидРасчета)
И ЗарплатаКадрыРасширенныйКлиентСервер.ЗачетОтработанногоВремени(ВидРасчета.ВидВремени) Тогда
// Начисления по условию из коллектора.
ОбщегоНазначенияКлиентСервер.ДополнитьМассив(
ВедущиеНачисления,
ПланыВидовРасчета.Начисления.ВидыРасчетаКоллектораПоОтбору(ПакетВидовРасчета, ОтборВедущих));
// ..Дополняются по условию из базы данных.
ОбщегоНазначенияКлиентСервер.ДополнитьМассив(
ВедущиеНачисления,
ПланыВидовРасчета.Начисления.НачисленияПоОтбору(ОтборВедущих), Истина);
КонецЕсли;
// Заполняем табличную часть полученными вытесняющими начислениями.
Для Каждого ВедущееНачисление Из ВедущиеНачисления Цикл
Если ВидРасчета.ВедущиеВидыРасчета.Найти(ВедущееНачисление, "ВидРасчета") = Неопределено
И КлючИЗначение.Ключ <> ВедущееНачисление Тогда
ВидРасчета.ВедущиеВидыРасчета.Добавить().ВидРасчета = ВедущееНачисление;
КонецЕсли;
КонецЦикла;
КонецЦикла;
Разберем, что именно здесь происходит. В процессе переноса ЗУП 3.1 пытается автоматически воссоздать иерархию связей между начислениями. Ошибка часто вызвана тем, что в коллекции ВедущиеНачисления оказываются битые ссылки или циклические зависимости, которые были допустимы в ЗУП 2.5, но жестко блокируются в ЗУП 3.1. Особенно это актуально для технологических релизов ветки 3.1.13.
Как показывает практика, наиболее эффективным решением при возникновении подобных ошибок является использование конкретных, проверенных временем релизов для первоначальной загрузки данных. Выясним алгоритм действий:
ЗУП 3.1.12.144. Этот релиз зарекомендовал себя как наиболее лояльный к переносу данных из 2.5, так как в нем правила выгрузки и алгоритмы формирования ведущих начислений работают максимально корректно.ЗУП 3.1 до текущего актуального релиза.Чтобы минимизировать риски, разберем необходимые подготовительные действия в исходной базе перед началом процесса:
Тестирование и исправление. Обязательно выполните процедуру "Тестирование и исправление" (ТиИ) в конфигураторе ЗУП 2.5. Обратите особое внимание на пункты "Проверка ссылочной целостности" и "Реиндексация таблиц". Если в базе есть "Объекты не найдены" в списках ведущих или базовых начислений, перенос гарантированно завершится ошибкой.
Очистка справочников. Проанализируем список начислений в 2.5. Проверьте вкладку "Прочее" у каждого вида расчета. Если вы обнаружите пустые строки в табличных частях "Базовые начисления" или "Ведущие начисления", их необходимо удалить вручную. Также рекомендуется выполнить полное удаление объектов, помеченных на удаление.
Обновление до финального релиза 2.5. Убедитесь, что ваша ЗУП 2.5 обновлена до последнего доступного релиза (например, 2.5.130.2). Это гарантирует наличие наиболее актуальных правил выгрузки со стороны источника.
Рассмотрим разницу между методами переноса, так как это может влиять на результат:
Перенос через прямое подключение: Этот метод требует наличия обеих баз на одном сервере или компьютере. Он более удобен для отладки, но чувствителен к правам доступа и версии платформы.
Перенос через файл данных: Рекомендуется использовать именно этот метод, если прямое подключение выдает ошибки связи. Сначала в ЗУП 2.5 через обработку "Выгрузка данных в ЗУП 3" формируется файл xml, который затем загружается в ЗУП 3.1. Это позволяет локализовать проблему: если ошибка возникает при выгрузке — дело в данных 2.5, если при загрузке — в релизе 3.1.
Краткий перенос: Если база 2.5 эксплуатировалась много лет и накопила много "мусора", мы настоятельно рекомендуем использовать вариант "Краткий перенос" (перенос остатков). В этом случае переносятся только актуальные данные для расчета среднего заработка и текущие кадровые данные, что значительно снижает вероятность столкнуться с ошибками в коде устаревших начислений.
Таким образом, комбинируя тщательную подготовку исходной базы и использование стабильного промежуточного релиза 3.1.12.144, вы сможете обойти программную ошибку и успешно завершить переход на новую версию программы.