В практике работы с программой 1С:Зарплата и управление персоналом 3.1 часто встречается ситуация, когда при расчете заработной платы за месяц система неожиданно «разбивает» начисление на части. Наиболее странным выглядит случай, когда премия или другое плановое начисление выделяется отдельной строкой ровно за один день месяца (чаще всего за 1-е число), при этом расчетная база и итоговая сумма выглядят некорректно. Разберем детально, почему так происходит, как провести диагностику и устранить причину этой ошибки.
Когда мы видим в документе НачислениеЗарплатыИВзносов строку с периодом в один день, это верный признак того, что программа обнаружила изменение условий оплаты труда или конфликт документов именно в эту дату. В 1С:ЗУП 3.1 расчетный механизм опирается на состояние регистров на конкретные моменты времени. Если система видит, что 1-го числа закончилось действие одного основания и началось действие другого (даже если они идентичны), она будет вынуждена создать две строки, чтобы соблюсти точность учета по регистраторам.
Рассмотрим ситуацию глубже: почему это может коснуться только нескольких сотрудников из всего штата? Это исключает глобальные ошибки в настройках начислений или графиков работы. Значит, проблема кроется в индивидуальной «истории» назначений конкретных работников. Проанализируем основные методы поиска первопричины.
Первым делом нам необходимо понять, какой документ программа считает «виновным» в создании этой странной строки. Самый быстрый способ сделать это без обращения к консоли запросов — воспользоваться стандартным отчетом.
Если в расчетном листке для одной и той же премии за разные периоды (например, за 01.02 и за 02.02–28.02) указаны разные документы-регистраторы, мы нашли место «стыковки». Однако часто бывает так, что документы выглядят одинаково, или отчет не показывает явного разделения. В этом случае переходим к более глубокой диагностике.
В системе 1С:ЗУП 3.1 есть удобный инструмент для просмотра всех изменений в оплате труда сотрудника. Рассмотрим, как им воспользоваться:
В открывшемся окне мы увидим хронологический список всех документов, которые влияли на плановые начисления. Здесь нужно искать документы, даты начала действия которых приходятся на 1-е число проблемного месяца. Проанализируем, нет ли там лишних записей ИзменениеОплатыТруда, НазначениеПлановогоНачисления или повторных кадровых переводов, которые могли «перетряхнуть» плановые показатели.
Если визуальный осмотр документов не дал результата, необходимо обратиться к «сердцу» механизма начислений — регистру сведений ПлановыеНачисления. Именно данные этого регистра используются программным кодом при заполнении документа НачислениеЗарплатыИВзносов.
Разберем последовательность действий для программиста или опытного пользователя:
ПлановыеНачисления.ДействуетДо, ДокументОснование и Регистратор.Типичная причина проблемы, которую мы рассматриваем: задвоение прав на начисление. Например, премия была назначена документом ПриемНаРаботу в ноябре. Позже, в декабре, бухгалтер создал документ НазначениеПлановыхНачислений, где снова указал эту же премию. В итоге в регистре образовались две действующие записи на один и тот же вид расчета. Программа пытается «схлопнуть» эти записи, но из-за нюансов в датах или настройках (например, если один документ был создан на основании другого некорректно), расчетный механизм выделяет один день как переходный период между этими двумя записями.
Выяснив причину, мы должны привести данные в порядок. Рассмотрим, как это сделать правильно, не прибегая к опасным ручным корректировкам регистров.
ИзменениеПлановыхНачислений, убедитесь, что в колонке Действие не стоит значение, создающее дубль уже существующего права.ПлановыеНачисления «с чистого листа».Рассмотрим ситуацию из сообщения автора темы: расчетная база за этот один день составила сумму за количество часов, отработанных именно 1-го февраля. Это происходит потому, что когда система выделяет 1 февраля в отдельный период расчета, она ограничивает и выборку данных для расчетной базы (если премия является зависимой). Программа видит: «Для этого начисления период — 1 день. Значит, и базу я соберу только за этот 1 день».
Такое поведение подтверждает, что проблема не в формуле премии, а именно в дроблении периода. Как только мы объединим период в одну строку (убрав дубли в плановых начислениях), расчетная база автоматически соберется за весь месяц целиком.
Чтобы в будущем не сталкиваться с «вылезшими» днями в начислениях, рекомендуем придерживаться следующих правил работы в 1С:ЗУП 3.1:
ПриемНаРаботу) задним числом, если расчетные периоды уже закрыты. Это может инициировать механизм пересчетов, который «всплывет» в текущем месяце.ИзменениеОплатыТруда), так как они корректно прекращают действие предыдущих начислений и начинают новые, предотвращая «наложение» периодов.ПлановыеНачисления — это кратчайший путь к пониманию логики программы.Таким образом, ситуация с «лишним днем» премии — это не программная ошибка, а следствие избыточности данных в системе. Тщательный контроль за историей назначений сотрудников позволит избежать подобных сложностей и обеспечит корректность регламентированной отчетности.