← На главную

В процессе автоматизации расчета заработной платы в 1С:ЗУП часто возникают ситуации, когда стандартный механизм расчета оклада вступает в конфликт с требованиями учета. Одна из таких задач — необходимость расчета оплаты по окладу исходя из нормы времени по Производственному календарю, тогда как у сотрудника назначен Индивидуальный график. Разберем, как справиться с этой задачей, не нарушая работу системы и сохраняя корректность данных.

Понимание проблемы: почему возникает конфликт

Стандартная формула расчета оклада в 1С:ЗУП выглядит следующим образом: Оклад * ДоляНеполногоРабочегоВремени * ВремяВДнях / НормаДней. Параметр НормаДней в этой формуле жестко привязан к графику работы сотрудника. Если мы назначаем Индивидуальный график, система автоматически подтягивает норму из него. При попытке изменить глобальную настройку в разделе Настройка — Расчет зарплаты, мы воздействуем на всю организацию, что недопустимо, если часть сотрудников работает по стандартным графикам.

Вариант 1: Использование графиков с поддержкой неполного рабочего времени

Если индивидуальные графики сотрудников имеют некоторую цикличность или повторяемость, мы можем применить более гибкую настройку графиков. Рассмотрим этот подход по шагам:

1. Создадим основной график, заполненный по Производственному календарю (например, стандартная пятидневка).
2. В настройках графика установим признак Неполное рабочее время.
3. В поле «Норма времени определяется» укажем, что она должна браться из другого, базового графика, заполненного по Производственному календарю.
4. При кадровом переводе сотрудника мы будем назначать ему именно этот «настроенный» график.

Этот метод позволяет избежать использования Индивидуального графика в чистом виде и корректно рассчитывает норму, соответствующую Производственному календарю.

Вариант 2: Применение расширений для создания собственного показателя

Для продвинутых пользователей и разработчиков самым правильным путем является использование Расширений конфигурации. Это позволяет добавить в систему собственный Показатель для расчета зарплаты, который будет автоматически вычислять норму по производственному календарю. Плюсы этого решения заключаются в следующем:

• Конфигурация остается на поддержке.
• Мы используем уже имеющиеся в ядре системы функции для получения нормы, что гарантирует точность вычислений.
• Отсутствует необходимость в ручном вводе данных.

В коде расширения мы можем перехватить расчет показателя и, используя стандартные функции платформы, получить значение НормаДней для конкретного сотрудника на конкретный период. Это значение затем подставляется в формулу начисления вместо типового.

Вариант 3: Использование тернарного оператора в формуле начисления

Если необходимо быстрое решение «здесь и сейчас» без глобальных доработок, можно прибегнуть к изменению формулы начисления. Рассмотрим пример реализации логики через тернарный оператор ?.

Мы можем создать дополнительный показатель, который будет заполняться вручную или через Данные для расчета зарплаты, и модифицировать формулу:

?(ЗначениеЗаполнено(МойПоказательНормы), МойПоказательНормы, НормаДней)

В данном случае система проверяет, введено ли вручную значение нашей нормы. Если оно заполнено, расчет идет по нему, если нет — берется стандартная НормаДней из графика. Это решение помогает в исключительных ситуациях, но требует внимательности при ежемесячном вводе данных.

Подведем итоги: что выбрать?

Проанализировав все варианты, мы рекомендуем придерживаться следующей стратегии:

1. Для массовых случаев старайтесь уходить от Индивидуальных графиков в пользу правильно настроенных Графиков работы с использованием механизма Неполного рабочего времени.
2. Если задача специфична и требует автоматизации без участия пользователя, используйте Расширение. Это позволит внедрить вызов функции расчета нормы по производственному календарю непосредственно в формулу, сделав процесс прозрачным и надежным.
3. Метод с тернарным оператором оставляйте как «костыльный» вариант для разовых корректировок, так как он несет риски ошибок при ручном вводе показателей.

Всегда помните, что изменения в формулах расчетов требуют обязательного тестирования на копии базы перед применением к основной конфигурации.