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