Переход с устаревшей конфигурации 1С:Зарплата и управление персоналом 2.5 (или 1С:УПП 1.3) на современную версию 3.1 часто наталкивается на жесткое требование бизнеса: «Перенести всё». Под этим подразумевается не только сальдо и кадровый состав, но и все документы начислений, выплат и кадровые приказы за десятилетнюю историю. В этой статье мы разберем, почему типовой перенос этого не делает «из коробки», какие существуют технические лазейки и как модифицировать типовые механизмы для решения этой задачи.
Прежде всего, нам необходимо понять, что ЗиУП 2.5 и 3.1 — это принципиально разные программы. В версии 2.5 кадровый учет и расчет зарплаты были разделены. Существовал отдельный документ ПриказОПриемеНаРаботу и отдельный расчетный механизм. В версии 3.1 реализована концепция единого документа. Например, документ Отпуск одновременно делает записи и по кадровому учету, и по начислениям, и по НДФЛ, и по выплатам.
При попытке перенести документы именно как «объекты», мы сталкиваемся с тем, что в новой базе нет прямых аналогов для связок старых документов. Типовой перенос от фирмы 1С решает эту проблему через технические документы ПереносДанных. Они просто записывают нужные цифры в регистры, минуя сложную логику проведения расчетных документов. Если же мы хотим видеть в базе именно документы НачислениеЗарплаты за 2015 год, нам придется программно воссоздавать всю цепочку зависимостей, что крайне трудозатратно.
В типовом помощнике перехода существует режим «Полного переноса» (иногда его называют нерекомендуемым). Проанализируем, что он делает:
ПереносДанных.Для многих организаций этого недостаточно. Рассмотрим, как снять ограничение по глубине периода и перенести данные за 5, 10 или более лет.
Для переноса данных используется внешняя обработка ВыгрузкаДанныхДляПереходаНаЗУП3.epf. Чтобы расширить период переноса, нам необходимо проанализировать код этой обработки. Разберем по шагам, что нужно сделать:
1. Откроем обработку в конфигураторе и найдем код, отвечающий за установку периода. В типовом решении часто жестко прописано ограничение ДобавитьМесяц(ДатаНачалаЭксплуатации, -36). Нам нужно изменить это значение или вывести его в настройки формы.
2. Рассмотрим пример функции, которую часто приходится модифицировать для корректной выгрузки данных по НДФЛ. Типовой механизм может не подхватывать данные прошлого года, если дата начала эксплуатации — январь текущего года. Нам нужно убедиться, что алгоритм захватывает весь налоговый период.
3. Проанализируем ситуацию с отборами. Если в базе много организаций, типовая выгрузка может «падать» по памяти. Рекомендуется внедрить в обработку жесткий отбор по конкретной организации, чтобы переносить данные порциями.
// Пример модификации фильтра в обработке выгрузки
ПараметрыВыгрузки.Вставить("ГлубинаПереноса", 120); // Устанавливаем 10 лет вместо 36 месяцев
ДатаНачалаВыгрузкиОборотов = ДобавитьМесяц(ПараметрыВыгрузки.ДатаНачалаЭксплуатации, -ПараметрыВыгрузки.ГлубинаПереноса);
Это самый сложный блок. В ЗиУП 2.5 НДФЛ учитывался преимущественно «по месяцу начисления», а в ЗиУП 3.1 действует строгий учет «по дате выплаты». Разберем, к чему это приводит:
ПереносДанных приходится вручную или программно корректировать даты получения дохода, чтобы они соответствовали ведомостям на выплату.Важный совет: убедите заказчика, что отчетность за прошлые периоды должна храниться и подаваться из старой базы (архива). В новую базу данные должны заходить только как база для расчета среднего заработка и остатки по взаиморасчетам.
Если ваша задача — перенос из УПП, помните, что структура зарплатного блока там практически идентична ЗиУП 2.5. Вы можете использовать ту же самую обработку выгрузки. Однако, как отмечают эксперты, необходимо предварительно «покрутить» её в отладчике, чтобы обойти проверку версии конфигурации. Программа может выдать ошибку «Конфигурация не поддерживается», которую легко устранить в коде обработки, закомментировав соответствующее условие в процедуре ПроверитьВозможностьВыгрузки().
Рассмотрим ситуацию: вы перенесли все документы начислений за 5 лет. Бухгалтер в новой базе решает пересчитать отпуск за 2018 год. Выясним причину, почему это плохая идея:
Решение: переносить исторические данные только в виде записей регистров (документы ПереносДанных). Это позволит системе видеть «базу» для среднего заработка, но защитит старые периоды от случайного перепроведения и искажения.
Если руководство настаивает на «максимальном» переносе, рекомендуем следующий алгоритм:
ВыгрузкаДанныхДляПереходаНаЗУП3.epf с увеличенным периодом для выгрузки данных о начислениях.РегистрНакопления.ДанныеОНачисленияхДляРасчетаСреднегоЗаработкаОбщий.ПереносДанных с кодами ЗП (Зарплата) и НДФЛ. Убедитесь, что суммы соответствуют расчетным листкам из старой базы.Полный перенос всех оборотов — это задача, требующая высокой квалификации программиста 1С и готовности бухгалтерии к тому, что старые данные в новой программе будут выглядеть иначе. Мы проанализировали основные риски и выяснили, что наиболее стабильный вариант — это использование штатных механизмов с расширением периода выгрузки через модификацию кода обработки. Помните: переносить нужно не «документы», а «данные». Это обеспечит работоспособность системы и корректный расчет среднего заработка без необходимости перепроведения документов десятилетней давности.