При переходе на новую учетную систему, например, при переносе данных из КА 2.5 или ERP 2.5 в ЗУП 3.1, или при плановой свертке базы данных в 1С:Зарплата и Управление Персоналом (ЗУП 3.1), мы часто сталкиваемся с необходимостью ввода исторических данных для расчета среднего заработка (для отпусков и больничных). Стандартный механизм — использование документа Перенос данных, хотя в ряде случаев пользователями применяется и загрузка данных из Excel непосредственно в расчетные документы.
Однако, даже если общая сумма заработка перенесена верно, при попытке рассчитать отпуск в новой базе мы можем обнаружить неприятную ошибку: в печатной форме расчета среднего заработка и в самой форме ввода данных суммы Районного Коэффициента (РК) и Северной Надбавки (СН) не выделены в отдельные колонки, а "схлопнуты" с основной суммой заработка (или отсутствуют в разбивке). Разберем подробно причины этого поведения и способы решения проблемы.
Прежде чем приступать к исправлению, давайте разберемся, как программа хранит информацию. В отличие от простых систем, в ЗУП 3.1 данные для среднего заработка разделены на несколько уровней (регистров накопления). Нас интересуют два основных регистра:
В этом регистре хранится "итоговая" информация: общая сумма заработка, учитываемая при расчете, и данные об отработанном времени. Именно этот регистр используется программой для определения числителя в формуле расчета отпускных. Если вы заполнили только его, сумма отпускных может посчитаться верно арифметически, но детализации вы не увидите.
Этот регистр часто упускают из виду при ручном переносе. Он служит для детализации сумм. Именно здесь хранится информация о том, из каких конкретно видов начислений (Оклад, Премия, РК, СН) сложилась общая сумма. Этот регистр критически важен для корректного отображения структуры заработка и применения индексации.
Если данные есть в первом регистре, но отсутствуют во втором, программа видит общую сумму как "монолит", не имея возможности выделить из нее районный коэффициент или северную надбавку.
Это самая неочевидная и сложная для диагностики проблема, которая обсуждалась специалистами. Даже если вы добросовестно заполнили оба регистра (и общий, и детализирующий), разбивка может не появиться.
Давайте проанализируем, как работает программный код получения данных для среднего заработка. В общих модулях, например в функции УчетСреднегоЗаработка.ДанныеОНачисленияхСреднегоЗаработка(), система строит запрос к базе данных.
Ключевой момент заключается в том, что соединение таблиц двух регистров (общего и по начислениям) часто происходит по полю Регистратор. Это означает, что записи в обоих регистрах должны быть сделаны одним и тем же документом.
Рассмотрим ситуацию, приводящую к ошибке:
Перенос данных №1 и заполнили в нем регистр Данные о начислениях для расчета среднего заработка (общий).Перенос данных №2 и заполнили в нем регистр Данные для расчета среднего заработка по начислениям.В этом случае при попытке собрать данные в единую таблицу для расчета отпуска система не сможет сопоставить строки, так как регистраторы разные. Для системы это разрозненные, не связанные между собой данные.
Решение:
Необходимо убедиться, что записи по одному сотруднику за один и тот же период (месяц начисления) находятся в рамках одного документа Перенос данных. Откройте документ, перейдите к настройке состава регистров и включите оба указанных выше регистра накопления. Заполните их синхронно.
Вторая распространенная причина связана с тем, какие именно виды расчета мы указываем при переносе данных (поможет перенос данных из ERP и КА 2.5 в ЗУП 3.1).
При миграции из старых программ (полезен перенос данных из ЗУП 2.5 в ЗУП 3.1) часто создаются "дубликаты" начислений. В справочнике начислений появляется элемент, например, "067. Районный коэффициент". С точки зрения пользователя название верное. Но с точки зрения конфигурации ЗУП 3.1 — это просто произвольная надбавка.
В ЗУП 3.1 есть предопределенные логикой программы виды расчета для РК и СН. Программа "узнает" их по определенным идентификаторам или назначениям начислений. Если в регистр детализации вы запишете сумму с пользовательским видом расчета, программа не поймет, что ее нужно поместить в колонку "Районный коэффициент".
Решение:
В документе переноса данных, в регистре детализации, в колонке "Вид расчета" необходимо выбирать типовое начисление текущей конфигурации, у которого в настройках указано назначение "Районный коэффициент".
Чтобы не действовать вслепую, давайте используем мощный инструмент диагностики — Универсальный отчет (для миграции пригодятся правила переноса из УПП/КА в ЗУП 3.1). Также для проверки итоговых цифр полезно использовать автоматизированный отчет по среднему заработку, который наглядно показывает, как программа интерпретирует данные регистров.
Для самостоятельной диагностики через Универсальный отчет выполните шаги:
Проанализируем результат: если отчет пуст, детализирующий регистр не заполнен. Если регистраторы в разных регистрах отличаются — это и есть причина "схлопывания" сумм.
Если ваша задача связана с реорганизацией и вы выполняете перенос среднего заработка между организациями, или просто исправляете ошибки ручного ввода, придерживайтесь следующего алгоритма:
Данные для расчета среднего заработка по начислениям.В случае правильного выполнения этих действий суммы из переноса данных корректно распределятся по колонкам РК и СН.
Стоит также упомянуть нюанс: если расчет среднего производится исходя из МРОТ, программа берет коэффициент, действующий на момент расчета, и исторические данные из регистров играют второстепенную роль.
Кроме того, при масштабных переносах данных не забудьте, что правильный расчет среднего — это лишь часть дела. Часто требуется также корректировка остатков по невыплаченной зарплате, чтобы входящие сальдо и взаиморасчеты с сотрудниками в новой базе полностью соответствовали действительности.