Как правильно организовать переход с 1С 7.7 на 1С 8.3 и решить технические проблемы переноса данных из ЗиК в ЗУП 3.1

Перевод информационных систем со старой, но проверенной временем платформы 1С:Предприятие 7.7 на современную 1С:Предприятие 8.3 — это всегда серьезный вызов для программиста и организации. Ситуация усложняется, когда предстоит перенести сразу три ключевых контура учета: бухгалтерский (БУ 7.7), расчет зарплаты (ЗиК 7.7) и торговый складской учет (ТиС 7.7). Разберем по шагам, как правильно спланировать этот процесс, минимизировать риски саботажа пользователей и решить конкретные технические проблемы, возникающие при переносе данных из программы 1С:Зарплата и Кадры 7.7 в 1С:Зарплата и Управление Персоналом 3.1.

Методология и стратегия успешного перехода

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

1. ЗиК 7.7 на ЗУП 3.1. Это наиболее критичный участок. Поддержка конфигурации 1С:ЗиК 7.7 давно прекращена, изменения в законодательстве делают расчет в ней невозможным. Переход на ЗУП 3.1 рекомендуется выполнять строго на начало нового календарного года (на 1 января). Это обусловлено тем, что расчеты по НДФЛ и страховым взносам ведутся нарастающим итогом с начала года, и перенос в середине расчетного периода потребует колоссального объема ручной сверки.
2. БУ 7.7 на БП 3.0. Перенос бухгалтерского учета можно выполнять параллельно или сразу после запуска зарплатного контура. Нам потребуется выгрузить остатки на начало года и сверить оборотно-сальдовую ведомость (ОСВ) по всем счетам. Особое внимание уделим взаиморасчетам с контрагентами (счета 60, 62) в разрезе субконто (договоры, документы расчетов).
3. ТиС 7.7 на УТ 11 (или УНФ). Торговый контур обычно вызывает больше всего сложностей из-за обилия уникальных доработок под бизнес-процессы заказчика. Этот этап можно отложить и выполнять постепенно, настроив на время переходного периода обмен данными между старой торговой базой на 7.7 и новой БП 3.0.

Важнейшим залогом успеха является работа с персоналом. Саботаж со стороны пользователей — естественная реакция на изменение привычного интерфейса. Проанализируем ключевые организационные требования:

• Обучение пользователей за счет заказчика. Программист не должен брать на себя роль персонального учителя для каждого бухгалтера. Настаивайте на прохождении сотрудниками профильных курсов по работе в программах 1С 8.3.
• Поддержка руководства. Все спорные вопросы, связанные со сменой методологии учета (когда пользователи требуют «сделайте мне точно так же, как было в семерке»), должны решаться через руководителя проекта или директора. Попытки воссоздать интерфейс и механизмы 7.7 в управляемых формах 8.3 приводят к созданию нежизнеспособных «костылей» и лишают систему возможности типового обновления.

Технические проблемы при переносе ЗиК 7.7 в ЗУП 3.1 и их решение

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

Проблема 1. Дублирование сотрудников и разделение понятий в ЗУП 3.1

При анализе перенесенных данных разработчики часто обнаруживают дубли сотрудников в списке. Выясним причину этого явления. В отличие от платформы 7.7, где карточка сотрудника совмещала в себе и персональные данные, и параметры трудового договора, в 1С:ЗУП 3.1 реализовано жесткое разделение объектов:

• Справочник ФизическиеЛица — содержит персональные данные человека (ФИО, СНИЛС, ИНН, паспорт, адреса). Каждое физлицо в системе должно быть строго в единственном экземпляре.
• Справочник Сотрудники — отражает конкретное рабочее место и трудовой договор.

Если один и тот же человек в течение своей трудовой деятельности увольнялся и принимался заново, либо работал по внутреннему совместительству, в ЗУП 3.1 у него будет одно физическое лицо, но несколько элементов в справочнике Сотрудники (по каждому трудовому договору отдельно).

Важное правило: Ни в коем случае нельзя использовать стандартные обработки поиска и замены дублей для объединения таких сотрудников в одного! Это полностью разрушит кадровую историю, приведет к искажению расчета среднего заработка для отпусков и больничных, а также сделает невозможным корректное заполнение регламентированной отчетности по НДФЛ и РСВ. Вместо этого в справочнике сотрудников следует просто скрыть неактивные договоры, установив флаг «Скрывать архивных сотрудников».

Проблема 2. Невозможно выбрать перенесенного сотрудника в документах

Рассмотрим ситуацию: сотрудник успешно перенесен из ЗиК 7.7, отображается в кадровых списках, однако при попытке добавить его в документ ввода остатков (например, в документ НачальнаяЗадолженность) система не находит его в списке выбора.

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

Чтобы решить эту проблему, выполним следующие шаги по обновлению регистра сведений:

1. Откроем базу в режиме «1С:Предприятие» под правами администратора.
2. Перейдем в меню Администрирование — Обслуживание — Корректировка данных (или воспользуемся групповой обработкой данных).
3. Если у вас есть возможность запустить произвольный код на встроенном языке (например, через внешнюю обработку или консоль кода), выполним принудительное обновление регистра сведений. Запустим следующий метод глобального модуля:

// Принудительное обновление вспомогательных данных для подбора сотрудников
ЗарплатаКадрыОбщегоНазначения.ОбновитьДанныеДляПодбораСотрудников();

Данный метод пересчитает состояния всех сотрудников, заполнит необходимые реквизиты (такие как флаг ОсновнойСотрудник, роли сотрудника, состояние занятости) и запишет их в регистр сведений ДанныеДляПодбораСотрудников. После этого сотрудники станут доступны для выбора во всех расчетных и кадровых документах.

Проблема 3. Задвоение сальдо по сотрудникам в документе «Начальная задолженность»

При тестировании результатов миграции расчетчики могут заметить, что начальное сальдо (задолженность организации перед сотрудниками или наоборот) завышено в несколько раз. Проанализируем причину сбоя.

Стандартный алгоритм переноса анализирует историю начислений и выплат. Если в ЗиК 7.7 по сотруднику были незакрытые цепочки кадровых документов (например, повторные приемы без корректного закрытия предыдущих взаиморасчетов), перенос может сформировать записи по задолженности для каждого архивного договора сотрудника отдельно. В результате суммы складываются, образуя некорректное сальдо.

Для исправления этой ситуации выполним следующие действия:

1. Откроем документ НачальнаяЗадолженность (раздел Главное — См. также — Начальная задолженность). Обратите внимание: дата документа по умолчанию может установиться равной текущей дате переноса (например, 17.01.2020). Обязательно установим дату документа на 01.01.2020 (или на дату начала ведения учета в новой базе), чтобы остатки легли строго на границу отчетных периодов.
2. Проверим табличную часть документа. Если по какому-то сотруднику выводится несколько строк с разными суммами по его архивным договорам, сопоставим их с реальной расчетной ведомостью из 7.7.
3. Оставим только одну актуальную строку по действующему трудовому договору сотрудника с корректной суммой остатка. Лишние строки по архивным договорам удалим.

Проблема 4. Некорректный автоматический перерасчет в документе «Увольнение»

Часто при регистрации увольнения сотрудника, перенесенного из ЗиК 7.7, в документе Увольнение на вкладке «Начисления и удержания» программа автоматически рассчитывает огромные суммы сторно (отрицательные перерасчеты за прошлые периоды), при этом отредактировать их вручную на форме документа не удается.

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

Для очистки ложных регистраций перерасчетов выполним следующие действия:

1. Распроведем проблемный документ Увольнение.
2. Перейдем в раздел Зарплата — Сервисы — Перерасчеты.
3. В открывшемся списке зарегистрированных перерасчетов найдем строки, относящиеся к нашему сотруднику.
4. Выделим эти строки и нажмем кнопку Отменить (или удалим их из списка зарегистрированных перерасчетов).
5. Вернемся в документ Увольнение, перевыберем сотрудника или дату увольнения для принудительного обновления расчетной части. Ложные сторно-записи исчезнут, и расчет будет произведен корректно за фактически отработанное время в текущем месяце.

Ошибки адресов при переходе с КЛАДР на ФИАС

Еще одной частой проблемой является частичное стирание адресов проживания или регистрации сотрудников после переноса при попытке их редактирования в ЗУП 3.1.

Разберем причину ситуации. В 1С 7.7 адреса хранились в текстовом формате на основе старого адресного классификатора КЛАДР. В современных конфигурациях на платформе 8.3 используется обновленный федеральный адресный реестр ФИАС (ГАР). Разница в регистрах написания названий регионов (например, Тыва Респ в 7.7 и Тыва респ в 8.3) приводит к тому, что при переносе адреса сопоставляются некорректно.

Для того чтобы избежать потери адресных данных при редактировании, до начала переноса данных необходимо загрузить актуальный адресный классификатор ФИАС непосредственно в новую чистую базу ЗУП 3.1 для нужных регионов. Это позволит обработке загрузки данных автоматически сопоставить текстовые представления адресов с уникальными идентификаторами ФИАС (GUID) и сохранит структуру адреса при его открытии пользователем.

Особенности подготовки баз 1С 7.7 перед переносом остатков

Успешность автоматического переноса напрямую зависит от чистоты ведения учета в базе-источнике. Рассмотрим обязательные регламентные операции, которые необходимо выполнить в конфигурациях 7.7 перед началом выгрузки данных:

1. Проведение тестирования и исправления (ТиИ) баз. На платформе 7.7 часто возникают нарушения логической и физической целостности таблиц базы данных. В конфигураторе 7.7 выполним операцию Администрирование — Тестирование и исправление ИБ. Обязательно выберем режим пересчета итогов, проверки ссылочной целостности и удаления битых ссылок.
2. Анализ отрицательных остатков. Наличие «минусов» на счетах бухгалтерского учета или регистрах торгового учета гарантированно приведет к тому, что в 8.3 остатки перенесутся некорректно. Документы ввода остатков в 8.3 не поддерживают проведение с отрицательным количеством или суммами по многим аналитическим разрезам. Выправим все пересортицы по номенклатуре и договорам контрагентов в базах 7.7 до выгрузки.
3. Закрытие периодов. Все регламентные документы по закрытию месяцев, расчету себестоимости и амортизации за прошлый год должны быть окончательно рассчитаны и проведены в базах 7.7. Только после фиксации итоговой финансовой картины можно приступать к переносу остатков в новые базы на платформе 8.3.

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