← На главную
Ситуация, когда после планового обновления конфигурации или платформы у сотрудников внезапно искажаются остатки отпусков (появляются нереальные цифры в 50–60 дней у новичков или остатки удваиваются), встречается на практике довольно часто. Разберем детально механизм формирования отпускного стажа в программе, выясним технические и учетные причины возникновения сбоя и пошагово восстановим корректный расчет.
Особенности механизма расчета остатков отпусков в 1С
Для понимания причин сбоя проанализируем, как программа определяет право на отпуск. В конфигурации 1С:Зарплата и Управление Персоналом итоговое количество неотгулянных дней обычно не хранится в виде одной фиксированной константы в таблице. Расчет выполняется динамически («на лету») при формировании кадровых справок, отчетов или документов увольнения.
Алгоритм обращается к сложной цепочке данных:
- Кадровая история сотрудника: дата приема, перемещения, ставки, графики работы.
- Сведения о праве на ежегодные отпуска (основные и дополнительные), назначенные должности по штатному расписанию или персонально сотруднику.
- Регистры фактически использованных дней отпуска (записи документов кадрового или расчетного контура).
- Периоды отсутствия, влияющие на сдвиг рабочего года (например, отпуска без сохранения заработной платы свыше 14 календарных дней).
Если на любом из этапов выборки данных происходит сбой — на уровне СУБД или на уровне записей конфигурации — результирующий остаток искажается.
Причина 1: Специфика платформы и генератора SQL-запросов
Проанализируем техническую сторону вопроса, когда ошибка проявляется исключительно в клиент-серверном варианте работы. В определенных сборках платформы (в частности, в ветке 8.3.9, например 8.3.9.2033) присутствовали ошибки генератора запросов к MS SQL Server. При трансляции сложных пакетов запросов 1С с временными таблицами и левыми соединениями оптимизатор СУБД строил некорректный план выполнения, что приводило к паразитному декартову произведению строк в выборке.
В результате выборка задваивала отработанные периоды или положенные дни. В файловом варианте информационной базы трансляция в T-SQL отсутствует, поэтому на файловых базах расчет оставался абсолютно корректным.
Также важное значение имеет процедурный кэш планов запросов СУБД. Именно поэтому ночной бэкап или база сразу после тестирования и исправления может показывать верные цифры, а через некоторое время работы кавардак возвращается: при повторном формировании и сохранении дефектного плана запроса в кэше SQL Server выборка снова начинает двоить.
Способ решения 1: Устранение платформенных сбоев и регламентные работы на СУБД
Если проблема вызвана платформенным поведением на стороне СУБД, выполним следующие шаги:
- Смена версии платформы 1С:Предприятие. Оптимальным решением является переход на проверенные стабильные сборки более старших веток (например,
8.3.10 и выше) либо временный откат на стабильную версию (например, релизы линейки 8.3.8), где генератор T-SQL отрабатывает корректно. - Очистка серверного кэша. Остановим службу сервера 1С:Предприятия (
ragent) и очистим содержимое каталогов сеансовых данных и кэша конфигураций на сервере приложений. - Обновление статистики и очистка планов в СУБД. Выполним регламентное обслуживание базы данных средствами MS SQL Server: обновим статистику таблиц и очистим процедурный кэш запросов, чтобы принудить оптимизатор заново построить корректные планы.
- Тестирование и исправление (ТиИ). Запустим информационную базу в режиме Конфигуратора, перейдем в меню
Администрирование – Тестирование и исправление..., выберем пункты реиндексации таблиц и пересчета итогов.
Причина 2: Сбой в прикладных данных и учетной политике
Если смена платформы не требуется или не устранила проблему целиком, перейдем к проверке учетного контура:
- Дублирование видов отпусков. Проверим справочник
Виды отпусков и регистр сведений, назначающий права на отпуска. Нередко пользователи заводят дублирующие элементы (например, два одинаковых основных отпуска) или по ошибке назначают сотрудникам дополнительный отпуск общего действия с некорректным количеством положенных дней. - Несоответствие контуров списания. В настройках параметров учета зарплаты определяется, какими документами регистрируется факт использования отпуска: кадровыми приказами или расчетными документами. Если этот параметр переключался во время ведения учета без последовательного перепроведения документов, регистр
Фактические отпуска организаций начинает содержать взаимоисключающие или задвоенные движения. - Смещение рабочих лет. Наличие непроведенных или некорректно введенных кадровых приказов на отпуска за свой счет нарушает непрерывность отпускного стажа и расчет границ рабочих лет.
Способ решения 2: Аудит и восстановление учетных данных
Разберем последовательность действий по исправлению учетных ошибок:
- Проверка прав на отпуск. Откроем кадровую справку по остаткам отпуска проблемного сотрудника. Выясним, из каких видов отпусков и рабочих лет сложился завышенный остаток. Проверим справочник видов отпусков на наличие дублей и права на отпуск, зафиксированные в штатном расписании или кадровых приказах.
- Перепроведение документов контура отпусков. Если в базе менялась политика учета фактических отпусков, выполним последовательное перепроведение кадровых документов (приказов на отпуск) или расчетных документов (начислений отпуска) в зависимости от того, какой контур выбран в параметрах учета зарплаты.
- Проверка внутреннего совместительства. Убедимся, что остатки не суммируются по физическому лицу. Если сотрудник оформлен как основной работник и как внутренний совместитель, отпуска должны вестись и рассчитываться отдельно по каждому трудовому договору (по объекту
Сотрудники, а не ФизическиеЛица). - Корректировка начальных остатков. Если сбой затронул прошлые закрытые периоды, для исправления ситуации воспользуемся документом ввода остатков отпусков (или ручной корректировкой соответствующего регистра), зафиксировав точное сальдо дней на начало текущего рабочего года сотрудника, избегая нажатия кнопки автоматического расчета прошлых периодов, если в них присутствуют системные ошибки.