← На главную

При работе с 1С:Зарплата и управление персоналом 3.1 (ЗУП 3.1) мы часто сталкиваемся с необходимостью начисления различных выплат. Стандартные механизмы ЗУП 3.1 ориентированы преимущественно на работу с данными по сотруднику. Однако что делать, если требуется настроить начисление, которое зависит от показателя, введенного не для конкретного сотрудника, а для целого подразделения? Например, если подразделение выиграло конкурс, и всем его сотрудникам полагается бонус, или если существует доплата за вредные условия труда, зависящая от стоимости "молока" в регионе, где расположено подразделение. Рассмотрим эту задачу подробнее и выясним, какие подходы и обходные пути существуют для ее решения.

Первое, что мы должны понимать, — это ограничения стандартного функционала. В ЗУП 3.1 нет прямого механизма, который позволяет настроить начисление с условием "начислять только если введен показатель по подразделению". Это связано с тем, что сотрудники могут часто менять подразделения в течение месяца. Если бы система жестко привязывала показатель к подразделению, это могло бы привести к некорректным расчетам при перемещениях сотрудников, ведь месячный интервал достаточно длинный, и сотрудники могут "мерцать" между различными структурными единицами. Если, например, 5 сентября сотрудник перешел из одного подразделения в другое, а через неделю вернулся, как система должна распределить начисление, завязанное на показателе подразделения?

Несмотря на отсутствие штатного решения, существуют эффективные обходные пути, требующие некоторой настройки или доработки. Мы проанализируем несколько таких подходов.

Решение 1: Использование разовых начислений с внешней обработкой заполнения

Этот вариант является одним из наиболее часто предлагаемых и достаточно гибких. Вместо того чтобы пытаться привязать показатель напрямую к подразделению через стандартные настройки начисления, мы создаем разовое начисление (например, вид начисления "Премия" или специальная "Разовая доплата"), а для его заполнения используем внешнюю обработку.

1. Создание вида начисления: В первую очередь, мы создаем новый вид начисления в ЗУП 3.1. Это может быть "Премия", "Разовая доплата" или другое разовое начисление, которое будет рассчитываться по определенной формуле, например, ПоказательПодразделения (если мы вводим его для подразделения) или ВремяВДнях * Показатель.
2. Ввод показателя для подразделения: Мы вводим необходимый показатель (например, "БонусЗаКонкурс" или "СтоимостьМолока") для каждого подразделения. Этот показатель может вводиться через документ "Данные для расчета зарплаты", но при этом мы не будем использовать его напрямую в настройках начисления, а лишь как источник данных.
3. Разработка внешней обработки: Самый важный шаг – это разработка внешней обработки заполнения табличной части. Эта обработка будет выполнять следующие функции:
   • Выбор подразделения: Пользователь выбирает подразделение, для которого нужно выполнить начисление.
   • Определение сотрудников: Обработка определяет всех сотрудников, которые числились в выбранном подразделении на определенную дату или в определенный период. Важно учесть кадровые перемещения и определить, кто и сколько дней отработал в этом подразделении.
   • Получение значения показателя: Обработка считывает значение показателя, введенного для выбранного подразделения (например, из документа "Данные для расчета зарплаты").
   • Расчет и заполнение табличной части: Для каждого сотрудника подразделения обработка рассчитывает сумму начисления (возможно, пропорционально отработанному времени в этом подразделении) и заполняет табличную часть документа начисления (например, "Премия" или "Начисление зарплаты").

   Пример логики для определения сотрудников и заполнения:

   Скопировать код

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

Преимущество этого подхода в том, что он позволяет работать с одним документом начисления (например, "Премия"), а не с несколькими. Он также дает полную гибкость в логике определения сотрудников и расчета суммы начисления.

Решение 2: Применение документа "Данные для расчета зарплаты" с доработками

Еще один вариант, который мы можем рассмотреть, предполагает использование документа "Данные для расчета зарплаты", но с определенными модификациями.

1. Ввод показателя через "Данные для расчета зарплаты": Мы можем использовать этот документ для ввода показателя, связанного с подразделением. Однако стандартно он предназначен для ввода данных по сотрудникам.
2. Модификация документа: Чтобы сделать этот подход удобным, мы можем добавить внешнюю кнопку или обработку в форму документа "Данные для расчета зарплаты". Эта кнопка будет выполнять функцию, аналогичную внешней обработке из предыдущего пункта:
   • Пользователь указывает подразделение (или оно определяется по контексту).
   • Обработка автоматически заполняет табличную часть документа "Данные для расчета зарплаты" всеми сотрудниками выбранного подразделения на нужную дату.
   • Далее для этих сотрудников можно будет ввести значение показателя (например, "бонус" или "доплата").
3. Последующее начисление: После того как "Данные для расчета зарплаты" заполнены, мы используем стандартный документ "Начисление зарплаты и взносов", который будет считывать введенные показатели и выполнять расчеты.

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

Решение 3: Расчет показателей на основе фактически отработанного времени

Для случаев, когда сумма начисления зависит от отработанного времени, а не от фиксированного бонуса (например, доплата за вредные условия труда или "молоко"), мы можем использовать формулу, которая учитывает время. Это особенно актуально, когда речь идет о разных подразделениях в разных регионах, где стоимость компенсации может отличаться.

1. Создание показателя и вида начисления:
   • Мы создаем показатель, например, "ДоплатаВместоМолока", который будет вводиться ежемесячно для подразделения (например, через тот же документ "Данные для расчета зарплаты" или через специальный регистр сведений). Важно, чтобы этот показатель имел область действия "для всех сотрудников" или "для подразделения", если он не зависит от конкретного человека.
   • Создаем вид начисления с формулой: ВремяВДнях * ДоплатаВместоМолока.
2. Ввод значения показателя: Значение "ДоплатаВместоМолока" может вводиться ежемесячно для каждого подразделения или для организации в целом, если оно едино. В случае, когда стоимость различается по регионам или подразделениям, нам потребуется механизм для его ввода с привязкой к подразделению. Здесь можно использовать:
   • Документ "Данные для расчета зарплаты": Вводить показатель для каждого сотрудника подразделения (автоматизируя заполнение через внешнюю обработку, как мы обсуждали выше).
   • Специальный регистр сведений: Если показатель не меняется часто, его можно хранить в регистре сведений с привязкой к подразделению и периоду.
3. Учет перемещений сотрудников: Мы анализируем ситуацию, когда сотрудник перемещается между подразделениями в течение месяца. ЗУП 3.1 автоматически отслеживает кадровые события и позволяет распределять отработанные дни по каждому подразделению. Это очень важный момент!
   • Система будет собирать ВремяВДнях (или ОтработаноСмен) по конкретному подразделению для каждого сотрудника.
   • НормаДней (или НормаСмен) также будет определяться с учетом диапазона кадровых событий.

   Таким образом, если сотрудник отработал часть месяца в Подразделении А, а часть в Подразделении Б, начисление "Доплата вместо молока" будет рассчитано пропорционально для каждого подразделения, используя соответствующее значение "ДоплатаВместоМолока" для этого подразделения и фактически отработанные дни. Например, если сотрудник отработал 10 дней в Подразделении А и 12 дней в Подразделении Б, то его доплата будет рассчитываться как 10 * ДоплатаА + 12 * ДоплатаБ.

Этот подход очень хорош для регулярных начислений, зависящих от времени и специфики подразделения, поскольку он использует встроенные механизмы ЗУП 3.1 для учета рабочего времени и кадровых перемещений. Главная задача — обеспечить корректный ввод значения показателя для каждого подразделения.

Важные моменты и дополнительные соображения

1. Суть проблемы — "мерцание" сотрудников: Как мы уже обсуждали, основная причина отсутствия прямого функционала для начислений по показателям подразделений в ЗУП 3.1 заключается в динамике перемещений сотрудников. Любое решение должно корректно обрабатывать ситуацию, когда сотрудник меняет подразделение в течение месяца. Формулы, учитывающие отработанное время (как в Решении 3), наиболее устойчивы к таким изменениям, так как ЗУП сам по себе умеет учитывать рабочее время по разным подразделениям.
2. Оценка полезности и простоты: Мы всегда должны стремиться к максимально простым и понятным расчетам. Чем проще формула и ввод показателей, тем меньше проблем возникает при расчете зарплаты и тем легче поддерживать систему. Иногда "ленивая" автоматизация (например, автоматическое заполнение всего подразделения одной кнопкой вместо ручного ввода для каждого сотрудника) может привести к скрытым сложностям и ошибкам, если не учесть все нюансы.
3. Ограничения настройки показателя "разовое использование только в этом месяце": Мы выяснили, что если для показателя установлена настройка "разовое использование только в этом месяце", то этот показатель может быть недоступен для выбора в настройках начисления. Это техническое ограничение требует внимания при выборе типа показателя и способа его использования. Если показатель должен быть разовым и влиять на начисление, скорее всего, придется использовать внешнюю обработку, которая будет "подкладывать" это значение в документ начисления, минуя стандартную настройку вида начисления.
4. Необходимость внешней разработки: В большинстве предложенных обходных путей мы видим, что нам потребуется разработка дополнительных внешних обработок или модификация существующих документов. Это означает, что для реализации такого функционала, скорее всего, потребуется помощь квалифицированного программиста 1С.
5. Поощрение вместо молока: Иногда вместо денежной компенсации за вредные условия труда лучше организовать натуральную выдачу, как это было в советское время (молоко, сок). Это не только соответствует рекомендациям врачей, но и снимает часть сложностей с расчетами в ЗУП 3.1. Однако это уже организационный вопрос, а не технический.

Заключение

Итак, прямого и типового механизма "начисление только если введен показатель по подразделению" в ЗУП 3.1 не существует. Однако это не означает, что задача нерешаема. Мы рассмотрели несколько подходов, которые позволяют реализовать подобную логику:

1. Использование разовых начислений (премий) в сочетании с внешней обработкой, которая автоматически заполняет список сотрудников подразделения и рассчитывает суммы.
2. Доработка документа "Данные для расчета зарплаты" путем добавления кнопки для автоматического заполнения сотрудников по подразделению.
3. Построение формулы начисления на основе отработанного времени (ВремяВДнях * Показатель), где ЗУП 3.1 сам учитывает перемещения сотрудников между подразделениями.

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