Почему больничный лист сторнирует сдельные работы в 1С:ЗУП 3.1 и как это исправить

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом
← На главную

При работе в программе 1С:Зарплата и управление персоналом 8 (редакция 3.1) бухгалтеры и расчетчики часто сталкиваются с ситуацией, когда документ Больничный лист (особенно его продолжение) начинает странным образом сторнировать начисления по сдельной оплате. Ситуация осложняется, когда используется типовая формула вида Макс(СдельныйЗаработок, Оклад * ДоляНеполногоРабочегоВремени * ВремяВДнях / НормаДней).

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

Разбираем причину проблемы: двойная природа начисления

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

Почему происходит сторнирование? В настройках этого начисления на вкладке "Приоритеты" в списке вытесняющих видов расчета указан Больничный лист. Когда мы регистрируем отсутствие сотрудника, система видит наложение периодов. Поскольку начисление за сделку "привязано" к графику работы и норме времени, 1С обязана "освободить" время болезни от других начислений. Это базовый принцип работы механизма вытеснения в 1С:ЗУП.

Рассмотрим, что происходит в программе пошагово:

  1. Сотруднику начислена зарплата за полный месяц (например, по результатам сдельной выработки).
  2. Вводится Больничный лист. Программа видит, что за период болезни уже начислена "Сделка".
  3. Система автоматически создает сторно-записи, чтобы уменьшить сумму сделки пропорционально дням болезни, так как считается, что в эти дни сотрудник не мог выполнять сдельную работу.

Особенности сторнирования в документе "Продолжение больничного"

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

Это происходит из-за цепочки перерасчетов. Когда создается "продолжение", программа анализирует не только исходную зарплату, но и корректировки, внесенные первым больничным. Если записи в регистре Перерасчеты не были отработаны или если больничные попадают на стык периодов, система пытается "перевытеснить" уже вытесненное время.

Решение №1: Изменение архитектуры начислений (Рекомендуемое)

Самый методически верный способ — уйти от использования одной сложной формулы, которая заставляет сделку вести себя как оклад. Проанализируем, как можно разделить эти понятия. Вместо одного вида расчета создадим два:

  1. Сдельный заработок (чистый):

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

  2. Доплата до гарантированного оклада:

    Создаем отдельный вид расчета с формулой:

    
    Макс(0, Оклад * ДоляНеполногоРабочегоВремени * ВремяВДнях / НормаДней - СдельныйЗаработок)
    

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

Решение №2: Настройка приоритетов и зависимости от времени

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

Проанализируем вкладку "Приоритеты":

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

Решение №3: Работа с сервисом "Перерасчеты"

Часто проблема кроется не в формулах, а в накопленных записях в служебных регистрах. Посмотрим, как это проверить:

  1. Перейдите в раздел Зарплата — Сервис — Перерасчеты.
  2. Найдите записи по проблемному сотруднику. Если там висят невыполненные перерасчеты за прошлые периоды по виду расчета "Сдельный заработок", то любой новый документ (больничный) будет пытаться их "подтянуть" в свою табличную часть.
  3. Попробуйте удалить эти записи вручную, если вы уверены, что зарплата за прошлые периоды рассчитана верно. После этого перевыполните заполнение Продолжения больничного листа.

Решение №4: Ручная корректировка в документе

Как крайний вариант, если ситуация разовая и сложная архитектура не оправдана, в последних релизах 1С:ЗУП 3.1 разработчики разрешили редактирование сторно-записей. Рассмотрим этот процесс:

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

Итоги и рекомендации

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

Мы рекомендуем:

Такой подход позволит вам избежать хаоса в расчетных листках и избавит от необходимости ежемесячно "чистить" результаты автоматического сторнирования в документах.

← На главную