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