← На главную

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

Причина №1: Разная логика формирования отчетов

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

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

Совет: Чтобы корректно сравнить сальдо при переносе, попробуйте в копии базы ЗУП 2.5 временно изменить даты выплат последнего месяца на последнее число этого же месяца. Если после этого сальдо в 2.5 совпало с 3.1 — значит, проблема была лишь в визуальном отображении, а сами данные перенесены верно.

Причина №2: Учет в разрезе подразделений

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

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

Анализ проблемы через Универсальный отчет

Для выявления «фантомных» долгов стандартного «Свода» недостаточно. Нам необходимо проанализировать регистры накопления. Выясним причину через Универсальный отчет (раздел Администрирование — Печатные формы, отчеты и обработки):

1. Выберем тип объекта Регистр накопления, имя объекта — Зарплата к выплате.
2. Установим тип данных — Остатки и обороты.
3. В настройках на вкладке «Группировка» добавим поля: Сотрудник, Период взаиморасчетов, Подразделение, Статья финансирования.

Проанализируем результат: если мы видим строки, где по одному подразделению висит «приход», а по другому «расход» за один и тот же месяц — это и есть причина появления лишних сумм в ведомостях.

Способ 1: Техническое «обнуление» остатков ведомостью

Если сотрудников много (более 300, как в рассматриваемом случае), ручная правка каждого документа переноса займет слишком много времени. Рассмотрим метод «схлопывания» остатков через техническую ведомость:

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

После проведения такой ведомости регистр Зарплата к выплате очистится, и в следующие документы эти суммы попадать не будут.

Способ 2: Редактирование документов «Перенос данных»

Все данные, пришедшие из ЗУП 2.5, хранятся в документах Перенос данных (раздел Администрирование — См. также — Перенос данных). За взаиморасчеты отвечают документы с кодами:

• ЗП_ВР — регистр накопления Взаиморасчеты с сотрудниками.
• ЗП_ЗВ — регистр накопления Зарплата к выплате.

Рассмотрим порядок действий:

1. Найдем документ за месяц, предшествующий началу работы в новой базе (например, если работаем с января 2019, ищем за декабрь 2018).
2. Проанализируем записи по проблемному сотруднику. Мы можем вручную добавить или изменить строки так, чтобы закрыть остатки по ненужным подразделениям или периодам.
3. Важно: записи в ЗП_ВР и ЗП_ЗВ должны быть идентичны, иначе возникнет разрыв между отчетами и ведомостями.

Способ 3: Использование документа «Начальная задолженность»

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

1. В документах Перенос данных (коды ЗП_ВР и ЗП_ЗВ) полностью удалим или очистим движения по регистрам взаиморасчетов на дату переноса.
2. Воспользуемся специальным документом Начальная задолженность (раздел Выплаты).
3. В этом документе введем только реальные остатки долгов на дату начала учета в разрезе сотрудников. Это «чистый» способ, который позволит не тащить историю ошибок из версии 2.5.

Особенности учета НДФЛ при корректировке сальдо

Нужно помнить, что в ЗУП 3.1 учет НДФЛ неразрывно связан с выплатой зарплаты. Если мы используем «Способ 1» (техническую ведомость), необходимо проверить, не подтянулся ли в документ налог. В окне расшифровки суммы «К выплате» колонки, связанные с НДФЛ, должны быть пустыми. Если там появятся суммы налога, это приведет к искажению отчетов 6-НДФЛ и справок 2-НДФЛ за текущий период.

Резюме

Для исправления сальдо после перехода выполним следующие шаги:

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

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