Как правильно осуществить переход с доработанной ЗГУ 1.0 на ЗГУ 3.0?

Переход с устаревшей редакции «Зарплата и кадры государственного учреждения 1.0» (или «Зарплата и кадры бюджетного учреждения 1.0») на современную редакцию 3.0 является крупным проектом, особенно когда исходная база содержит множество доработок. Архитектура ЗГУ 3.0 коренным образом отличается от редакции 1.0: изменились принципы расчета зарплаты, подсистемы учета НДФЛ, страховых взносов, штатного расписания и статей финансирования. Разберем по шагам, как выстроить стратегию перехода, какие инструменты использовать для переноса данных и как перенести доработанный функционал без ущерба для типового обновления.

Стратегия работы с доработками: почему нельзя переносить код напрямую

Распространенная ошибка при переходе — попытка механически перенести программные доработки и новые объекты метаданных из конфигурации 1.0 в 3.0. Рассмотрим, почему этого делать не следует:

1. Устаревание логики: Значительная часть доработок, сделанных годами ранее, часто теряет актуальность в связи с изменением законодательства или сменой бизнес-процессов учреждения.
2. Типовые возможности ЗГУ 3.0: Многие механизмы, требовавшие доработки в версии 1.0 (например, гибкие формулы расчета начислений, учет квалификационных категорий, ПКГ/КУ, специфика госслужбы и расширенная тарификация), уже реализованы в типовом функционале третьей редакции.
3. Смена архитектурных подходов: В ЗГУ 3.0 код пишется под управляемые формы и клиент-серверное взаимодействие. Прямой перенос процедур из обычных форм редакции 1.0 приведет к неработоспособности системы.

Главное правило: Переносятся только данные. Программный код и доработки анализируются с нуля и реализуются в ЗГУ 3.0 исключительно через механизм расширений (cfe), дополнительных отчетов и обработок, сохраняя конфигурацию на полной типовой поддержке.

Подготовка исходной информационной базы

Качество переноса напрямую зависит от чистоты данных в исходной базе ЗГУ 1.0. Перед началом выгрузки выполним обязательный комплекс подготовительных работ:

1. Аудит физических лиц: В ЗГУ 3.0 действует строгая привязка трудовых договоров к справочнику ФизическиеЛица. Проверим и устраним дубли физлиц, корректность заполнения СНИЛС и ИНН.
2. Проверка бюджетной аналитики: В редакции 3.0 структура учета финансирования разделена на «Статьи финансирования» и «Статьи расходов» с привязкой к кодам КОСГУ/КЭК. Устраним пересортицу по источникам финансирования и закроем зависшие остатки взаиморасчетов прошлых периодов.
3. Закрытие расчетных периодов: Проверим проведение всех документов начисления зарплаты, страховых взносов и межрасчетных выплат за последний закрываемый расчетный месяц.
4. Тестирование и исправление: Выполним стандартную процедуру «Тестирование и исправление информационной базы» в конфигураторе ЗГУ 1.0 с пересчетом итогов и удалением помеченных объектов.

Методика и варианты переноса данных

Существует два основных сценария переноса данных при наличии доработок в структуре регистров и документов.

Вариант 1. Модификация типовых правил в «Конвертации данных 2.1»

Если в исходной базе были добавлены новые реквизиты или регистры, данные которых критически важно сохранить в ЗГУ 3.0, используем конфигурацию Конвертация данных 2.1:

1. Из поставки обновления ЗГУ 3.0 извлекаем типовые правила конвертации данных (XML-файл правил обмена).
2. Загружаем метаданные ЗГУ 1.0 (с учетом доработок) и типовые метаданные ЗГУ 3.0 в «Конвертацию данных 2.1».
3. Загружаем типовые правила и дорабатываем Правила конвертации объектов (ПКО) и Правила конвертации свойств (ПКС) под кастомные поля.
4. Выгружаем обновленные правила и выполняем перенос с помощью универсальной обработки ВыгрузкаЗагрузкаДанныхXML или типового помощника.

Вариант 2. Приведение к типовой конфигурации и двухэтапный перенос

Если структура стандартных учетных регистров (взаиморасчеты, НДФЛ, расчет среднего заработка) не нарушена, а доработки изолированы:

1. Создаем копию рабочей базы ЗГУ 1.0.
2. Приводим конфигурацию копии к полностью типовому релизу ЗГУ 1.0, обновляя ее файлом cf от типовой конфигурации соответствующей версии.
3. Выполняем перенос данных на выбранную дату среза с помощью типового помощника перехода.
4. Специфические данные, хранившиеся в нестандартных регистрах или справочниках, переносим отдельной внешней обработкой прямого чтения через COM-соединение или обмен через файлы JSON/XML.

Краткий перенос против полного

Рекомендуется выбирать краткий перенос данных (на расчетный период/дату среза), а не перенос всей истории за предыдущие годы. При кратком переносе в ЗГУ 3.0 переносятся:

1. Справочная информация (структура подразделений, должности, сотрудники, физлица, начисления).
2. Актуальная кадровая расстановка на дату переноса (документы НачальнаяШтатнаяРасстановка).
3. Остатки взаиморасчетов и сальдо на начало года.
4. Данные для расчета среднего заработка для отпусков, командировок и пособий за предыдущие 2–3 года (вспомогательные документы ПереносДанных).

Попытка полного переноса первичных документов за все годы в 95% случаев приводит к критическим расхождениям из-за различий в алгоритмах движений по регистрам накопления между редакциями.

Сверка и контроль корректности перенесенных данных

После завершения загрузки данных в ЗГУ 3.0 выполним контрольную выверку перед стартом промышленной эксплуатации:

1. Сверка кадрового состава: Сопоставим отчеты «Штатная расстановка» и «Списочный состав сотрудников» в обеих базах на дату среза.
2. Сверка сальдо взаиморасчетов: Сформируем отчеты «Расчетная ведомость Т-51» и «Свод начисленной зарплаты» с детализацией по статьям финансирования и статьям расходов.
3. Тестирование расчета среднего заработка: Проведем тестовые документы «Отпуск» и «Больничный лист» по нескольким сотрудникам из разных подразделений, сверив рассчитанную среднедневную ставку с расчетом в редакции 1.0.
4. Параллельный расчет: В течение как минимум одного расчетного месяца ведем параллельный расчет зарплаты и налогов в обеих программах для исключения скрытых ошибок.