Почему в 1С:ЗУП 2.5 в фактическом периоде действия нет записей по больничному листу при наличии сторно?

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

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

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

Физика работы регистра расчета и формирование ФПД

Для начала проанализируем, как платформа «1С:Предприятие 8» формирует виртуальную таблицу Фактического периода действия. Этот механизм опирается на настройки вытеснения, заданные в Плане видов расчета (ПВР), и подчиняется жестким платформенным правилам.

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

Чтобы «освободить» время в прошлом периоде для нового начисления, используется механизм сторнирования. Сторно-запись (запись с флагом Сторно = Истина) решает две задачи:

  1. Корректирует финансовый результат прошлого периода (уменьшает сумму оклада).
  2. Снимает блокировку времени в прошлом периоде. Платформа понимает, что старое начисление за эти дни аннулировано, и позволяет новой записи (нашему больничному листу) занять освободившийся интервал в таблице ФПД.

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

Рассмотрим ситуацию, с которой столкнулся пользователь. В январе регистрируется больничный лист за декабрь. В документе рассчитывается сам больничный и одновременно сторнируется оклад за декабрь. Но в виртуальной таблице ФПД за этот период видны только сторно-записи оклада, а сам больничный лист отсутствует.

Проанализируем структуру регистра расчета с помощью простого запроса:


ВЫБРАТЬ
    Регистратор,
    ВидРасчета,
    ПериодДействияНачало,
    ПериодДействияКонец,
    ФактическийПериодДействияНачало,
    ФактическийПериодДействияКонец
ИЗ
    РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.ФактическийПериодДействия
ГДЕ
    Сотрудник = &Сотрудник

При выполнении этого запроса мы увидим, что для записи больничного листа колонки фактического периода действия остаются пустыми. Это означает, что платформа по какой-то причине считает данный период времени заблокированным другим начислением, которое имеет более ранний период регистрации и не было сторнировано.

Выявление скрытого конкурента: влияние зависимых начислений

Выясним причину этой блокировки. Если оклад за декабрь был успешно сторнирован, но больничный все равно не получает свой ФПД, значит, в декабре действовало еще одно начисление, которое конкурирует за этот временной интервал.

В рассматриваемом примере таким начислением оказалась "Доплата за питание". Давайте разберем по шагам, почему она заблокировала расчет:

  1. В настройках вида расчета "Доплата за питание" было включено свойство Использует период действия. Это необходимо, чтобы рассчитывать доплату пропорционально отработанным дням.
  2. Так как доплата использует период действия, она создает запись в регистре расчета, претендующую на дни декабря.
  3. Больничный лист по своей природе должен вытеснять не только оклад, но и "Доплату за питание".
  4. При проведении больничного листа система автоматически сформировала сторно-запись для оклада, но не сформировала сторно-запись для "Доплаты за питание".
  5. В результате платформа увидела следующую картину: оклад в декабре отменен (время свободно), но "Доплата за питание" за декабрь все еще активна и зарегистрирована более ранней датой. Так как сторно по ней нет, она продолжает удерживать за собой дни декабря и блокирует запись больничного листа.

Как только мы сторнируем "Доплату за питание" (или исключаем ее влияние), платформа тут же освобождает временной интервал, и ФПД больничного листа рассчитывается корректно.

Как решить проблему в 1С:ЗУП 2.5?

Для устранения этой коллизии нам необходимо выполнить несколько последовательных действий:

Способ 1. Проверка и настройка вытеснения в Плане видов расчета

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

  1. Откроем План видов расчета Основные начисления организаций.
  2. Найдем предопределенный вид расчета Оплата больничных листов.
  3. Перейдем на вкладку Прочее и проанализируем список вытесняющих видов расчета.
  4. Убедимся, что в списке присутствуют все начисления, которые зависят от времени присутствия сотрудника, включая такие виды расчета, как "Доплата за питание", "Доплата за проезд" и т.д. Если их там нет — добавим их в список вытесняемых.

Способ 2. Корректное разделение документов

Если автоматическое сторнирование в одном документе отрабатывает некорректно из-за сложной цепочки начислений, рекомендуется воспользоваться разделением операций:

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

Архитектурные отличия: ЗУП 2.5 против ЗУП 3.1

Посмотрим на эту ситуацию шире и проанализируем, почему аналогичная проблема не возникает в современных версиях программы, например, в 1С:Зарплата и управление персоналом 3.1.

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

В ЗУП 3.1 разработчики фирмы "1С" кардинально изменили архитектуру учета времени:

Таким образом, понимание физики работы Фактического периода действия в 1С:ЗУП 2.5 позволяет быстро диагностировать подобные ошибки, находить "скрытые" начисления, блокирующие расчеты, и поддерживать корректность ведения учета в базах данных.

← На главную