← На главную

Переход со старой конфигурации «Зарплата и Кадры 7.7» (ЗиК) на современную «Зарплата и Управление Персоналом 3.1» (ЗУП) — это сложный процесс, который часто сопровождается расхождениями в расчете среднего заработка, переносе премий и переносе сложных схем оплаты труда. В этой статье мы подробно разберем, как исправить типичные ошибки переноса данных, настроить несколько комиссионных выплат для одного сотрудника без оформления фиктивного совместительства, а также выясним причины расхождений в расчете отработанного времени для сотрудников на шестидневном графике.

---

Методика ручной корректировки годовой премии в среднем заработке

При переносе данных на начало года (например, на 01.01.2020) штатная обработка переносит сведения о заработке за предшествующие периоды в специальные технические документы Перенос данных. Данные для расчета среднего заработка (отпуска, командировки) фиксируются в документах с буквенным кодом ЗП_СЗО (Зарплата — Средний заработок общий).

Часто пользователи замечают, что годовая премия, начисленная в январе предыдущего года, не попадает в расчет среднего заработка текущего года. Рассмотрим, почему это происходит и как правильно отразить премию.

Согласно пункту 15 Положения № 922, при определении среднего заработка годовые премии, начисленные за предшествующий календарный год, учитываются независимо от времени начисления премии. Это означает следующее:

1. Если мы рассчитываем отпуск в 2020 году, то в расчет среднего может войти только годовая премия за 2019 год.
2. Годовая премия за 2018 год (даже если она была начислена в расчетном периоде — в январе 2019 года) в расчете среднего заработка для отпусков 2020 года участвовать не должна. Программа ЗУП 3.1 отслеживает это автоматически и отсекает такие премии при переносе данных, что является абсолютно корректным с точки зрения законодательства.
3. Если же вам необходимо скорректировать годовую премию за 2019 год, начисленную в начале 2020 года, чтобы она правильно учитывалась в последующих отпусках, или принудительно добавить премию прошлых лет, нам придется отредактировать документы переноса данных.

Разберем по шагам, как выполнить корректировку:

1. Перейдем в раздел Администрирование — Переносы данных.
2. Найдем документ с кодом ЗП_СЗО за нужный месяц (например, за январь года переноса).
3. В табличной части документа найдем нужного сотрудника. По умолчанию его общий заработок может быть перенесен одной строкой. Нам необходимо разбить эту запись или добавить новую строку.
4. Добавим новую строку для сотрудника, выбрав в колонке вида заработка соответствующий тип: «Годовая премия, учитываемая частично» или «Годовая премия, учитываемая полностью» (в зависимости от того, пропорционально ли отрабатывалось время в периоде начисления премии).
5. Укажем сумму премии в соответствующем поле.

Важное примечание для новых релизов ЗУП 3.1: В современных версиях программы расчет среднего заработка оптимизирован. Помимо классического регистра накопления Данные о начислениях для расчета среднего заработка (общий), разработчики используют новые регистры: Данные для расчета среднего заработка по начислениям и Данные для расчета среднего заработка по начислениям (ФСС) (последний отвечает за расчет больничных). Если вы вносите ручные правки в старые документы переноса данных, обязательно зайдите в раздел Зарплата — Сервис — Обновить данные для расчета среднего заработка и запустите перерасчет данных, чтобы программа синхронизировала ваши ручные изменения по всем новым регистрам.

---

Столбец «Индексируется»: влияние на средний заработок

При анализе перенесенных данных в документах ЗП_СЗО пользователи часто обращают внимание на колонку «Индексируется» со значениями «Да» или «Нет». Выясним, какую роль играет этот признак.

Этот флаг носит информативно-предупредительный характер для алгоритмов расчета среднего заработка при будущей индексации тарифов и окладов:

• Если в вашей организации в будущем будет оформлен официальный документ «Индексация заработка», программа автоматически умножит все исторические начисления за прошлые периоды (перенесенные из ЗиК), у которых стоит отметка «Да», на коэффициент индексации.
• Если вы не используете механизм официальной индексации, а повышаете оклады сотрудникам вручную (например, документами Изменение плановых начислений или Изменение штатного расписания), этот флаг никак себя не проявит. Автоматического пересчета прошлых периодов при расчете среднего заработка для отпусков не произойдет.

Тем не менее рекомендуется оставлять значение «Да» для всех окладных и процентных начислений по умолчанию (как это настроено в типовых алгоритмах переноса). Согласно Положению № 922, если оклады повышаются по всему предприятию или крупному структурному подразделению, работодатель обязан проиндексировать и средний заработок для расчета отпусков. Наличие флага «Да» позволит корректно отработать этому механизму, если вы решите провести повышение именно через документ индексации.

---

Особенности расчета времени для шестидневного графика

Бухгалтеры, привыкшие к логике работы старой программы ЗиК 7.7, часто удивляются, почему в ЗУП 3.1 при расчете отпуска сотрудника, работающего по шестидневной рабочей неделе, доля отработанного времени рассчитывается на основе пятидневки. Выясним причину такого поведения системы.

В действующем Положении № 922 не закреплена четкая и детальная методика расчета пропорции отработанного времени для премий при нестандартных графиках работы. Чтобы привести расчеты к справедливому единообразию, фирма 1С реализовала в ЗУП 3.1 методику, опирающуюся на разъяснения Минздравсоцразвития (в частности, Письмо № 2337-17).

Согласно этой методике, время, отработанное сотрудником на любом графике (шестидневка, сменный график, суммированный учет), пересчитывается пропорционально норме пятидневной рабочей недели. Это позволяет корректно сопоставлять заработок сотрудников с разными режимами работы и не завышать (или занижать) долю премий, учитываемую в среднем заработке. Отклонения в расчетах по сравнению со старой методикой ЗиК (которая базировалась на нормах до 2002 года) обычно составляют незначительные копейки, поэтому с этим поведением программы следует согласиться.

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

---

Настройка двух различных комиссионных выплат без совместительства

Типичная проблема: сотруднику необходимо начислять процент от выручки по двум разным видам деятельности (например, «Работа № 1» — 34% от выручки направления А, и «Работа № 2» — 25% от выручки направления Б) в рамках одного и того же трудового договора.

Если мы попытаемся назначить сотруднику два одинаковых начисления кадровым документом (например, Начальная штатная расстановка), программа выдаст ошибку проведения: «Период действия начисления пересекается с заданным». Это происходит потому, что основное начисление контролирует рабочее время сотрудника, и программа не позволяет задваивать учет времени.

Рассмотрим два решения этой задачи: гибкий пользовательский обходной путь и правильный стандартный метод ЗУП 3.1.

Вариант 1. Использование механизма дополнительных начислений (Пользовательский метод)

Мы можем оставить первое начисление («Работа № 1») как основное, учитывающее время, а для второго начисления («Работа № 2») создать отдельную схему, которая не пересекается по учету времени.

Разберем этот процесс по шагам:

1. Создадим два новых показателя расчета (раздел Настройка — Показатели расчета зарплаты):
   • ПроцентОтРаботы2 — назначение показателя: «Для организации» (постоянный).
   • ВыручкаЗаРаботу2 — назначение показателя: «Для сотрудника», вводится только в месяце расчета (ежемесячный).
2. Создадим новое начисление «Работа № 2» со следующими настройками:
   • Назначение начисления: Прочие начисления и выплаты.
   • Начисление выполняется: Только если введено значение показателя (выбираем показатель ВыручкаЗаРаботу2).
   • Формула расчета: ПроцентОтРаботы2 * ВыручкаЗаРаботу2 / 100
   • Вкладка «Учет времени»: Установим переключатель в положение «Дополнительная оплата за уже оплаченное время». Это критически важно, так как данное начисление не будет конфликтовать с основным окладом или первой комиссионной выручкой по периоду действия.
3. Создадим шаблоны ввода исходных данных (раздел Настройка — Шаблоны ввода исходных данных):
   • Шаблон для ввода постоянного процента ПроцентОтРаботы2.
   • Шаблон для ежемесячного ввода суммы выручки ВыручкаЗаРаботу2.

Теперь расчетчику достаточно один раз установить процент (например, 25%) для организации или подразделения, а в конце месяца вносить сумму выручки по конкретным сотрудникам через журнал Данные для расчета зарплаты. При заполнении документа Начисление зарплаты и взносов программа автоматически рассчитает обе строки.

Вариант 2. Использование типовой настройки «Несколько одновременно действующих начислений» (Рекомендуемый метод)

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

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

После включения этой настройки система позволит назначить сотруднику одно и то же начисление несколько раз кадровыми документами (например, через Изменение оплаты труда или Назначение планового начисления).

В табличную часть кадрового документа мы сможем добавить две строки с одинаковым видом расчета, но указать в них разные параметры: в первой строке задать процент 34%, во второй — 25%. При расчете заработной платы программа автоматически создаст две отдельные строки и рассчитает суммы по каждой из них на основе введенных данных по выручке. Это исключает необходимость загромождать базу данных лишними показателями и шаблонами.