Как перенести изменения (дельту) при переходе с 1С:ЗУП 2.5 на ЗУП 3.1?

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом IT и автоматизация бизнеса
← На главную

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

Довольно распространен сценарий, когда в процессе опытной эксплуатации часть сотрудников продолжает вести расчеты и кадры в старой программе ЗУП 2.5, в то время как в ЗУП 3.1 уже начинается подготовка или частичный ввод данных. В этот момент возникает закономерный технический вопрос: как переносить только измененные или новые данные (так называемую «дельту») за определенный период (день, час, неделю) из старой базы в новую?

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

---

1. Встроенный стандартный механизм переноса документов за период

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

Проанализируем подробнее специальный режим, который называется «Выгрузить документы, введенные после начала работы в новой программе»:

  1. Назначение режима: Он создан специально для того, чтобы переносить кадровые и расчетные документы, созданные в старой базе в период, когда в новой базе уже вовсю идет работа.
  2. Какие данные переносятся: В состав выгрузки попадают только первичные кадровые приказы (Прием на работу, Кадровый перевод, Увольнение), а также базовые расчетные документы (Больничный лист, Отпуск, Командировка, Оплата по среднему заработку).
  3. Статус загружаемых документов: При загрузке в ЗУП 3.1 все эти документы записываются в статусе непроведенных («черновиков»). Это критически важное архитектурное решение. Оно гарантирует, что загруженные документы не изменят автоматически рассчитанные налоги, взносы и взаиморасчеты в новой базе без ведома расчетчика. Пользователь должен самостоятельно открыть перенесенные документы, проверить их корректность и провести вручную.
  4. Защита от затирания изменений: Если выгрузка запускается повторно за тот же период, система сверяет объекты. Если документ в ЗУП 3.1 уже был проверен и проведен пользователем, повторная загрузка не перезапишет его данные, предотвращая затирание ручных правок.

Однако у этого механизма есть существенное ограничение: он корректно переносит только новые первичные документы. Любые документы-исправления, корректировки прошлых периодов или сложные сторнирования этот механизм обработать в автоматическом режиме не сможет. Их придется переносить или дублировать в новой базе вручную.

---

2. Архитектурный барьер для бесшовного обмена «дельтой»

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

---

3. Опасности повторных запусков полного переноса

Когда пользователи понимают, что перенос «дельты» кадровых документов работает с ограничениями, у них возникает соблазн просто заново запускать стандартный Помощник перехода поверх уже существующей базы ЗУП 3.1. Сделаем важное предупреждение: помощник перехода рассчитан исключительно на однократный запуск!

Рассмотрим, какие проблемы возникают при регулярном повторном использовании стандартного помощника:

---

4. Технические варианты решения проблемы для разработчиков

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

Вариант А. Создание кастомного плана обмена и правил в «Конвертации данных»

Для реализации этого подхода нам потребуется использовать конфигурацию «1С:Конвертация данных 2.1». Разберем этот процесс по шагам:

Шаг 1. Создание плана обмена в ЗУП 2.5
В конфигураторе старой базы создаем новый план обмена (например, _ДемоПереносВЗУП3). В состав этого плана обмена включаем только те объекты, изменения которых нам необходимо отслеживать (например, справочники Сотрудники, ФизическиеЛица и определенный перечень кадровых документов).

Шаг 2. Разработка правил конвертации объектов (ПКО)
В Конвертации данных настраиваем правила сопоставления объектов. Особое внимание нужно уделить поиску. Настроим поиск физлиц по СНИЛС, а при его отсутствии — по уникальному идентификатору (GUID), если базы изначально были синхронизированы.

Шаг 3. Регистрация изменений и выгрузка
При изменении или создании документа в ЗУП 2.5 он автоматически регистрируется на узле нашего плана обмена. Напишем пример процедуры для регистрации изменений программным путем:


// Пример регистрации изменений документа для обмена
Процедура ЗарегистрироватьИзменениеДокумента(СсылкаНаДокумент) Экспорт
    
    УзелОбмена = ПланыОбмена._ДемоПереносВЗУП3.НайтиПоКоду("ЗУП3");
    
    Если ЗначениеЗаполнено(УзелОбмена) Тогда
        // Проверяем тип документа, чтобы не регистрировать лишнее
        ТипДокумента = ТипЗнч(СсылкаНаДокумент);
        Если ТипДокумента = Тип("ДокументСсылка.ПриемНаРаботуВОрганизацию") 
            Или ТипДокумента = Type("ДокументСсылка.КадровоеПеремещениеОрганизаций") Тогда
            
            ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, СсылкаНаДокумент);
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Шаг 4. Написание скрипта выгрузки
Используя обработку УниверсальныйОбменДаннымиXML, настраиваем регламентное задание, которое будет раз в сутки (или с другой периодичностью) выгружать зарегистрированные изменения по созданным правилам, а затем очищать регистрацию на узле плана обмена.

Вариант Б. Доработка типовой обработки выгрузки

Как отмечают практикующие специалисты, в обработке выгрузки данных из ЗУП 2.5 логика запросов крайне сложная. Пытаться внедрить туда фильтрацию по измененным объектам «на лету» — очень трудоемкий процесс. Однако можно пойти по пути упрощения:

---

5. Итоги и рекомендации

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

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

  1. Избегайте затяжного параллельного учета. Лучшая методология перехода — это единовременный перенос данных на начало отчетного периода с полным запретом редактирования в старой базе. Оптимально делать это на 1 января.
  2. Используйте типовой перенос документов за период только как резервный вариант. Если параллельный учет неизбежен, переносите кадровые документы стандартным механизмом за период, но будьте готовы к ручному проведению и верификации каждого документа в ЗУП 3.1.
  3. Не запускайте стандартный перенос повторно поверх рабочей базы. Это практически со 100% вероятностью приведет к затиранию ручных правок расчетчиков, дублированию элементов кадровой истории и сбою в расчетах среднего заработка и НДФЛ. Если данные в старой базе сильно изменились — проще очистить базу ЗУП 3.1 и запустить перенос с нуля.
  4. Привлекайте профильного специалиста. Учитывая кардинальную разницу в архитектуре подсистем расчета зарплаты и налогов, практически ни один реальный переход крупного предприятия не проходит без точечной доработки правил обмена или написания кастомных обработок выверки данных.
← На главную