← На главную

Переход с устаревшей конфигурации «Зарплата и кадры бюджетного учреждения» редакции 1.0 на современную «Зарплата и кадры государственного учреждения» (редакции 3.0 или 3.1) — одна из наиболее ответственных задач. На практике специалисты часто сталкиваются со сбоями прямого переноса, аварийным закрытием программы, непониманием принципов переноса кадровой истории и вопросом, почему за прошлые периоды в новой базе не формируются расчетные листки и своды. Разберем по шагам все нюансы этой процедуры, выясним причины ошибок и определим методику проверки перенесенных данных.

Анализ причин сбоев при переносе и выбор релизов

Проанализируем типовую ситуацию: запускается мастер переноса данных, выбирается информационная база-источник, запускается процесс выгрузки, но ближе к завершению платформа выдает системную или программную ошибку. Выделим основные технические факторы, вызывающие такие сбои:

1. Несоответствие релизов источника и приемника. Правила конвертации данных жестко зашиты в конфигурацию. Если релиз приемника устарел (например, ранняя редакция 3.0.19.x), встроенные правила не смогут корректно обработать структуры данных обновленного источника (1.0.101.x). Более того, развитие ветки 3.0 прекращено, и переходить необходимо непосредственно на актуальную редакцию 3.1. Официальные ошибки механизмов переноса (например, зарегистрированная ошибка 50008317) исправляются разработчиками только в актуальных релизах ветки 3.1.
2. Ограничения COM-соединения и нехватка оперативной памяти. При прямом подключении конфигурации-приемника к источнику через COM-соединение 32-разрядный клиент 1С аварийно завершает работу с ошибкой нехватки памяти при обработке больших массивов накопленных данных (регистров расчета и среднего заработка). Кроме того, конфликт разрядности (запуск 64-битного клиента при зарегистрированном в системе 32-битном COM-коннекторе) приводит к падению процесса в самом начале.
3. Ошибки ссылочной целостности и особенности видов расчетов. Некорректно заполненные виды расчетов в источнике (например, специфические чернобыльские отпуска или нестандартные начисления в натуральной форме) могут приводить к сбоям встроенных алгоритмов сопоставления. Перед переносом в исходной базе рекомендуется выполнить «Тестирование и исправление» и устранить дублирующиеся элементы справочников.

Пошаговый алгоритм выполнения переноса данных

Рассмотрим правильную последовательность действий, обеспечивающую успешную миграцию данных в новую информационную базу:

1. Обновление конфигураций до совместимых релизов. Обновим исходную базу ЗБУ 1.0 до актуального релиза и развернем чистую базу ЗКГУ редакции 3.1. Переход сразу на ветку 3.1 исключает ошибки, оставшиеся в не поддерживаемой редакции 3.0.
2. Использование альтернативного варианта через XML-файл. Чтобы избежать нестабильности прямого COM-соединения и ошибок переполнения памяти, воспользуемся выгрузкой через внешний файл. В каталоге шаблона конфигурации-приемника поставляется специализированная внешняя обработка выгрузки для редакции 1.0. Запустим ее в исходной базе, сформируем XML-файл с выгруженными данными, после чего загрузим его в чистую базу ЗКГУ через стандартный помощник начальной настройки. Этот метод полностью изолирует базы друг от друга.
3. Корректный выбор даты начала эксплуатации. В мастере переноса ключевое значение имеет параметр даты начала работы в новой программе (например, 1 октября). Все кадровые состояния и остатки взаиморасчетов переносятся как срез на указанную дату. Если указать дату в прошлом (например, 1 января), программа не перенесет кадровые приказы (приемы, увольнения, перемещения), произошедшие позже этой даты внутри года, так как ожидает, что текущий учет с этой даты пользователи будут вести вручную непосредственно в ЗКГУ.

Особенности механизмов загрузки: почему расчетная ведомость пустая

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

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

Аналогично обстоит ситуация и с кадровыми данными: документы прошлых лет («Прием на работу», «Кадровое перемещение») не создаются заново. Вся кадровая история работающих сотрудников на дату переноса сворачивается в документ Начальная штатная расстановка. Поэтому построить кадровые отчеты по движениям за закрытые периоды в новой базе невозможно — это штатное архитектурное поведение типового перехода.

Опасность повторной загрузки данных в рабочую базу

Проанализируем важный технический аспект: что происходит, если повторно запустить мастер переноса в ту же самую базу, например, решив сдвинуть дату перехода с января на октябрь?

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

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

1. Либо полностью развернуть перенос заново в чистую пустую базу данных.
2. Либо перед повторным запуском найти через поиск ссылок, пометить на удаление и полностью физически удалить из базы-приемника все созданные ранее документы переноса (Начальная штатная расстановка, Начальная задолженность по зарплате и документы Перенос данных).

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

Поскольку стандартные сводные отчеты за прошлые периоды не формируются, контроль качества переноса выполняем по специализированной методике:

1. Сверка актуального кадрового состава. Формируем в новой базе отчет Штатные сотрудники на дату начала эксплуатации. Сверяем полученный список со списком фактически работающих сотрудников в ЗБУ 1.0, обращая особое внимание на количество занимаемых ставок, корректность подразделений, должностей и назначенных плановых начислений в документе Начальная штатная расстановка.
2. Сверка начального сальдо взаиморасчетов. Формируем отчет Задолженность по зарплате (или документ Ведомость на выплату) на дату среза и сопоставляем входящее сальдо с расчетной ведомостью из исходной базы 1.0. Суммы задолженностей организации и сотрудников должны совпасть до копейки.
3. Тестирование расчета среднего заработка. Создаем в новой базе тестовые документы Отпуск и Больничный лист по сотрудникам с различными графиками работы. Проверяем вкладку расчета среднего заработка: данные о начислениях за предшествующие 12 или 24 месяца, а также отработанные дни и часы должны автоматически заполниться из регистров, сформированных документами переноса данных.