В процессе работы с программой 1С:Зарплата и Управление Персоналом (редакция 3.1) расчетчики и системные аналитики часто сталкиваются с ситуацией, когда после очередного обновления конфигурации привычные алгоритмы расчета начинают вести себя некорректно. Одной из таких проблем является неожиданное появление нескольких строк (задвоение или дробление на периоды) для одного и того же начисления в документе Начисление зарплаты и взносов. Особенно часто это происходит с начислениями, которые завязаны на расчетную базу и используют сложные формулы с проверкой показателей.
В этой статье мы подробно проанализируем, почему возникает подобное поведение программы, разберем внутренние механизмы расчетного ядра «1С:ЗУП 3.1» и рассмотрим несколько практических способов устранения данной проблемы — от простых методических изменений до продвинутых технических лайфхаков.
Рассмотрим классический пример настройки начисления (назовем его НАШЕ_НАЧИСЛЕНИЕ), который часто используется на практике для создания зависимых премий:
(0.5 * РасчетнаяБаза + ПроцентПремии * 0)ПроцентПремии).Логика этой настройки выглядит следующим образом: расчетчику необходимо, чтобы в определенном месяце сотруднику была начислена основная «Премия месячная» (которая рассчитывается напрямую от показателя ПроцентПремии). В то же время должно автоматически сработать второе начисление (НАШЕ_НАЧИСЛЕНИЕ), которое возьмет половину от расчетной базы (в которую как раз входит первая премия). Чтобы не дублировать ввод данных, разработчики формулы привязали второе начисление к тому же показателю ПроцентПремии, умножив его на ноль, чтобы сам процент не влиял на сумму, но служил триггером для расчета.
До определенного момента (в старых релизах ветки 3.1) эта схема успешно работала: в документе Начисление зарплаты и взносов оба начисления рассчитывались строго по одной строке. Однако после обновления конфигурации (начиная с версии 3.1.11 и выше) расчетчики обнаружили, что НАШЕ_НАЧИСЛЕНИЕ начало рассчитываться двумя, а иногда и более строками. При этом базовая премия по-прежнему рассчитывается одной строкой.
Выясним, в чем кроется причина такого поведения системы.
---
Давайте разберем по шагам, как программа «1С:ЗУП 3.1» определяет периоды действия начислений. Главная причина разделения расчета на несколько строк — это наличие начисления в списке плановых начислений сотрудника в сочетании с изменениями параметров его работы внутри месяца.
Когда начисление назначено сотруднику как плановое (например, документами Прием на работу, Кадровый перевод или Назначение планового начисления), программа жестко контролирует его актуальность на каждый день расчетного периода. Если в течение месяца у сотрудника происходят какие-либо изменения, расчетный период разбивается на микропериоды. К таким изменениям относятся:
Если начисление является чисто плановым (например, обычный оклад), программа делит его расчет по периодам вполне оправданно. Однако в нашем случае начисление имеет хитрый статус: оно назначено как плановое, но фактически рассчитывается только при наличии разового показателя ПроцентПремии.
В обновленных алгоритмах «1С» расчетный модуль видит, что плановое начисление должно действовать весь месяц, но из-за кадровых изменений период разбился, например, на два интервала (до кадрового перевода и после). Так как разовый показатель введен на весь месяц, программа применяет его к каждому из этих интервалов, порождая две строки в документе начисления зарплаты. Расчетная база при этом также собирается отдельно за каждый микропериод, что приводит к некорректным результатам и путанице в расчетных листках.
---
Самый правильный способ решить эту проблему раз и навсегда — исключить данное начисление из списка плановых. Нам не нужно регистрировать его кадровыми документами. Программа способна сама понять, когда нужно выполнить расчет, ориентируясь исключительно на факт ввода показателя.
Проанализируем настройку этого механизма по шагам:
НАШЕ_НАЧИСЛЕНИЕ).ПроцентПремии).Теперь расчет будет происходить следующим образом:
ПроцентПремии. Начисление вообще не появляется в документе расчета зарплаты.---
Иногда использование одного и того же показателя для двух разных по смыслу начислений приводит к методическим тупикам. Рассмотрим альтернативный вариант настройки, предложенный экспертами, который исключает логические конфликты при расчете базы.
Вместо того чтобы привязываться к показателю ПроцентПремии и умножать его на ноль, мы можем создать отдельный управляющий показатель-маркер. Назовем его, например, РассчитыватьДоплатуБазы.
Выполним следующие настройки:
РассчитыватьДоплатуБазы
0.5 * РасчетнаяБаза * РассчитыватьДоплатуБазы
РассчитыватьДоплатуБазы.При таком подходе в месяце расчета премии расчетчик вводит значение 1 для показателя РассчитыватьДоплатуБазы. Программа выполняет математически точный расчет: умножает половину расчетной базы на единицу и выводит результат одной строкой, полностью исключая влияние других плановых показателей.
---
Что делать, если начисление обязательно должно оставаться плановым (например, этого требуют смежные системы автоматизации или сложные внутренние регламенты учета), но при этом кадровые переводы упорно продолжают дробить его на части? Существует элегантный технический прием, позволяющий принудительно «склеить» периоды расчета планового начисления внутри месяца.
Для реализации этого метода нам понадобится создать специальный вспомогательный показатель, который мы добавим в формулу начисления:
НеРазделятьПоПериодам
((0.5 * РасчетнаяБаза + ПроцентПремии * 0) + НеРазделятьПоПериодам * 0)
Рассмотрим, как работает эта магия на уровне программного кода расчетного модуля «1С»:
Присутствие в формуле показателя, который имеет признак Накапливается по отдельным значениям, заставляет расчетный механизм временно отключать стандартный алгоритм поденного разбиения планового начисления. Система понимает, что данный показатель может накапливаться в течение всего месяца, и физически не может рассчитать его по отдельным микропериодам. В результате программа выполняет расчет начисления одной общей строкой за весь месяц, корректно собирая всю расчетную базу целиком.
При этом расчетчику даже не нужно вводить этот показатель физически в документах — так как он умножается на ноль, его отсутствие (значение по умолчанию 0) никак не повлияет на итоговую сумму начисления, но свою техническую роль по «склеиванию» периодов он выполнит безупречно.
---
Мы проанализировали проблему задвоения строк начислений в «1С:ЗУП 3.1» и убедились, что она связана с ужесточением контроля периодов действия плановых начислений в современных релизах платформы. При возникновении подобной ситуации рекомендуем придерживаться следующего плана действий: