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