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