При работе в программе 1С:Зарплата и Управление Персоналом (редакция 3.1) бухгалтеры и расчетчики часто сталкиваются с неприятной ситуацией: сотруднику начислена премия за месяц, однако при расчете Районного коэффициента (РК) или Северной надбавки (СН) эта премия полностью или частично «выпадает» из базы. Проблема проявляется именно тогда, когда в середине месяца был оформлен документ Кадровый перевод. Рассмотрим подробнее, почему так происходит, и разберем способы решения этой проблемы.
Для начала проанализируем, как система 1С:ЗУП 3.1 видит месяц, в котором произошел кадровый перевод. В отличие от старых версий (например, 2.5), «тройка» строит расчеты в жесткой привязке к записям в регистре Кадровая история. Когда мы регистрируем Кадровый перевод, например, со 2-го апреля, система «разрезает» месяц на два независимых интервала:
Когда программа начинает рассчитывать Районный коэффициент, она делает это отдельно для каждого из этих интервалов. При поиске расчетной базы (в нашем случае — премии) система пытается сопоставить даты периода, за который начислена премия, с датами кадровых интервалов. Если премия начислена одной строкой за весь месяц (с 1 по 30 число), а кадровая история изменилась со 2-го числа, возникает конфликт распределения. Система часто не может корректно «привязать» общую сумму премии к разорванному периоду кадровых условий, из-за чего база РК оказывается пустой.
Выясним самый простой способ избежать проблемы. Если фактическое изменение условий (например, повышение оклада) произошло в начале месяца или на первый рабочий день (допустим, 1 апреля был выходным, а перевод сделан со 2-го апреля), наиболее корректным с точки зрения логики программы будет оформление перевода именно с 1-го числа.
Разберем, почему это помогает: когда перевод зафиксирован с 1-го числа, «разреза» кадровой истории внутри месяца не происходит. Сотрудник весь расчетный период числится на одних условиях. В этом случае документ Премия, введенный за полный месяц, без труда сопоставляется с единственным кадровым периодом, и Районный коэффициент рассчитывается верно.
Если перевод невозможно перенести на 1-е число (например, сотрудник действительно сменил должность в середине месяца), нам придется помочь программе распределить базу вручную. Рассмотрим, как это сделать в документе Премия:
Премия, которым было начислено вознаграждение.Еще — Изменить форму.В некоторых случаях (если премия должна облагаться РК за весь месяц) более правильным методом будет разбиение строки премии на две части:
Таким образом, каждая часть премии «ляжет» на свой участок кадровой истории, и Районный коэффициент подхватит обе части.
Проанализируем ситуацию, описанную в сообщениях форума: часто проблема усугубляется, если в Кадровом переводе меняется не только оклад, но и Должность. Смена должности в 1С:ЗУП 3.1 является критическим изменением, которое создает новую строку в механизме формирования записей о начислениях.
Если перевод вызван только изменением денежного содержания (повышением оклада), рекомендуется использовать документ Изменение оплаты труда вместо полноценного Кадрового перевода. Этот документ создает меньше «побочных» движений в кадровых регистрах, что иногда позволяет избежать ошибок при сборе расчетной базы зависимых начислений.
Посмотрим на настройки самих начислений. Для того чтобы система понимала связь между премией и районным коэффициентом, необходимо проверить следующее:
Районный коэффициент на вкладке Расчет базы должна быть указана ваша премия.Премии на вкладке Зависимости должны быть указаны Районный коэффициент и Северная надбавка.Для программной проверки можно обратиться к регистру сведений ДанныеОВремениДляРасчетаСреднегоЗаработка или ПараметрыПериодовСтажа, но чаще всего проблема кроется именно в виртуальных таблицах РасчетнаяБаза, которые формируются «на лету» при заполнении документа Начисление зарплаты и взносов.
Стоит отметить, что в релизах линейки 3.1.5 и 3.1.6 была зарегистрирована официальная ошибка (например, №10191632), связанная именно с потерей базы для РК и СН при наличии кадровых изменений внутри месяца. Разработчики 1С признали, что механизм распределения «межрасчетных» начислений (таких как премии) по периодам кадровой истории в этих версиях работал нестабильно.
Если вы столкнулись с подобным поведением системы, рекомендуется:
Подводя итог: основная причина кроется в неспособности программы автоматически распределить базу начисления, введенного «за месяц», по разным записям кадровой истории. Выравнивание дат или явное указание периодов в документе начисления позволяют обойти эту особенность платформы.