В процессе работы с конфигурацией 1С:Зарплата и управление персоналом 3.1 многие специалисты сталкиваются с методологической и технической сложностью при настройке ежемесячных премий. Типовой сценарий, когда премия за текущий месяц (например, июнь) рассчитывается на основании базы предыдущего месяца (мая), работает корректно только до тех пор, пока у сотрудника не случаются кадровые изменения внутри базового периода.
Проанализируем ситуацию: в мае сотрудник был переведен с одной должности на другую с изменением оклада и процента премии. Если мы используем стандартный механизм РасчетнаяБаза, указывая период «Предыдущий месяц», система соберет все начисления мая в одну общую сумму и умножит её на показатель премии, действующий на момент расчета (или на конец месяца). В итоге «слайсинг» (разделение расчета по периодам внутри месяца) теряется. Рассмотрим подробнее, почему это происходит и какими способами можно решить данную задачу.
Выясним причину, по которой типовая формула не справляется с задачей. В ЗУП 3.1 программный движок расчета настроен таким образом, что если период действия начисления (июнь) не совпадает с периодом сбора базы (май), система выполняет агрегацию данных. Регистр расчета не может «пробросить» кадровые срезы из прошлого месяца в текущий так, чтобы формула Результат = РасчетнаяБаза * ПроцентПремии отработала дважды за разные части мая.
Для программы «прошлый месяц» — это просто число, полученное из виртуальной таблицы базы. Чтобы обойти это ограничение, нам придется либо использовать внешние инструменты заполнения, либо вносить изменения в логику работы документов через расширения.
Этот метод считается наиболее «чистым» с точки зрения поддержки конфигурации, так как он не требует изменения логики проведения документов. Разберем его по шагам:
НачисленияУдержанияПоСотрудникам за прошлый месяц.ГрафикиРаботыПоВидамВремени или ДанныеСостоянийСотрудников, чтобы четко разделить суммы базы по датам кадровых перемещений.Данные для расчета зарплаты.Таким образом, в самом начислении премии будет стоять простая формула: Результат = ВведенныйПоказательПремии. Вся сложность расчета переносится на этап подготовки данных.
Если бизнес-процесс требует использования специализированного документа Премия, мы можем применить механизм расширений. Посмотрим на пример реализации, который упоминали эксперты на форумах.
Нам потребуется перехватить процедуру заполнения табличной части документа. Основная задача — подменить стандартный сбор базы собственным алгоритмом, который учитывает историю изменений показателей. Проанализируем примерный алгоритм, который можно внедрить в модуль менеджера или через обработку заполнения:
// Пример логики получения базы с учетом периодов в расширении
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Зарплата.Сотрудник,
| Зарплата.Результат КАК СуммаБазы,
| Зарплата.ПериодДействияНачало,
| Зарплата.ПериодДействияКонец,
| ПлановыеПоказатели.Значение КАК ПроцентПремии
|ИЗ
| РегистрНакопления.НачисленияУдержанияПоСотрудникам КАК Зарплата
|ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияПериодическихПоказателейРасчетаЗарплатыСотрудников.СрезПоследних(&ДатаБазы, ) КАК ПлановыеПоказатели
|ПО Зарплата.Сотрудник = ПлановыеПоказатели.Сотрудник
|ГДЕ
| Зарплата.ПериодРегистрации = &ПредыдущийМесяц";
Важно помнить, что при использовании расширения необходимо программно добавлять строки в таблицу Начисления документа так, чтобы поле Размер или Результат соответствовало вашим расчетам. Как отмечают практики, можно добавить на форму документа специальную кнопку «Рассчитать по периодам прошлого месяца», которая выполнит пересчет Результата на лету, опираясь на данные о перемещениях.
Иногда проблему пытаются решить через настройки самих показателей. Рассмотрим, поможет ли это в нашем случае. Если у показателя ПроцентПремии установлено значение «Во всех месяцах после ввода значения (постоянное использование)», программа будет знать его историю. Однако, как мы выяснили ранее, при обращении к РасчетнаяБаза прошлого месяца, формула все равно не разделится на части автоматически.
Тем не менее, этот показатель критически важен, если вы решите писать свой запрос. Только имея историю изменения показателя в регистре сведений ЗначенияПериодическихПоказателейРасчетаЗарплатыСотрудников, вы сможете сопоставить нужный процент с нужным периодом перемещения в базовом месяце.
При реализации собственного алгоритма расчета базы (через код или внешние инструменты) обязательно учитывайте следующие моменты:
БазовыеВидыРасчета).Данные для расчета зарплаты налоги будут рассчитаны в общем порядке в документе Начисление зарплаты и взносов, что минимизирует риск ошибок в отчетности.Подведем итог: типовыми формулами ЗУП 3.1 невозможно заставить расчетную базу прошлого месяца «распадаться» на периоды кадровых перемещений. Наиболее эффективным и безопасным решением является использование внешней обработки заполнения для документа Премия или промежуточного документа Данные для расчета зарплаты. Это позволяет сохранить прозрачность учета и точность начислений без внесения критических изменений в ядро системы.