Как «качели» графиков ломают табель в ЗУП 3.1: разбор архитектурного бага механизма сшивания периодов

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

В материале я разберу реальный инцидент: сотрудница за один месяц сменила общий график работы 5 раз. В итоге документ «Табель учета рабочего времени» выдал парадоксальный результат: вместо плановых ночных часов на определенные даты (7–8 июля ожидались часы по графику «Смена №4») программа подставила «Выходные» и «Явку 12 часов» от совершенно другого графика.

Давайте заглянем под капот конфигурации и посмотрим, почему внутренний механизм ЗУП не смог переварить эту ситуацию.

Часть 1. Анатомия инцидента

Сотрудник А. работала по сменному графику. В июле 2026 года кадровики оформили несколько изменений общего графика работы, создав настоящие «качели». Выгрузка из регистра сведений "График работы сотрудников" показала 5 интервалов действия:

Рис. 1. Записи регистра сведений «График работы сотрудников» по сотруднику за период апрель–июль 2026 года. Видно 6 записей, созданных документами «Изменение графика работы списком» и «Кадровый перевод списком».

Если перевести эти записи в табличный вид для наглядности, мы получим следующую картину:

При заполнении документа «Табель» за июль, на период 07.07–08.07 программа вместо продолжения графика «Смена №4» подставила часы по графику «Смена №1». В табеле это выглядело так: 07.07 — Выходной, 08.07 — Явка 12 часов.

Рис. 2. Документ «Табель». Красным кругом выделены ошибочные ячейки: 07.07 — «В» (выходной вместо ночных часов), 08.07 — «Я 12» (явка 12 часов вместо графика «Смена №4»).

Часть 2. Как ЗУП формирует плановое время (Архитектура)

Чтобы понять причину сбоя, вспомним, как ЗУП получает плановые часы. Весь механизм крутится вокруг общего модуля "УчетРабочегоВремениРасширенный" и функции СоздатьВТДанныеУчетаВремениИСостоянийСотрудников.

Платформа выполняет пакетный запрос, создающий цепочку временных таблиц. Ключевые из них:

1. ВТГрафикиСотрудниковСрезИДвижения — получает срез последних записей регистра "График работы сотрудников".
2. ВТИнтервалыГрафиков — формирует непрерывные интервалы. Окончание интервала вычисляется как НачалоСледующегоПериода - 1 Секунда.
3. ВТДанныеРегистровУчетаВремени — итоговая таблица, где часы умножаются на дни.

Подводный камень: функция УточнитьПериодыЗаполненияПоСотрудникам.
Если бы табель заполнялся с нуля, ЗУП, возможно, переварил бы эти 5 записей. Проблема кроется в том, что табель по сотруднику за июль уже был заполнен ранее (до ввода последних кадровых переводов).

В ЗУП 3.1 существует регистр сведений "Параметры зарегистрированных данных учета времени". При заполнении табеля программа ставит там флаги: УстановленДень1 = Истина, УстановленДень2 = Истина и т.д. Функция УточнитьПериодыЗаполненияПоСотрудникам вызывается внутри пакета запроса. Ее задача — «вырезать» из периодов действия графиков те дни, которые уже заполнены в табеле, чтобы не задвоить часы. Но при наличии «осколочных» периодов (как в нашем случае: 07.07–08.07, а потом 09.07–09.07) эта функция ломает логику сшивания.

Часть 3. Вскрытие ВТ (Анализ дампов)

Самая сложная задача при отладке — понять, что именно пошло не так внутри пакетного запроса. Чтобы упростить диагностику, мы разработали специальное расширение-отладчик (оно доступно для скачивания в этой статье). Оно перехватывает и сохраняет все временные таблицы пакета сразу после выполнения запроса, до их автоматической очистки платформой. Это позволяет буквально «заглянуть» под капот алгоритма и увидеть корень проблемы. Например, при анализе дампа мы видим, что в таблице ВТГрафикиСотрудниковСрезИДвижения корректно зафиксировались все 5 интервалов с точностью до секунды:

Рис. 3. Дамп временной таблицы ВТГрафикиСотрудниковСрезИДвижения. Видно 5 строк (первые три записи апреля-мая отсечены функцией СрезПоследних на дату 01.07.2026).

Но при объединении с флагами "Параметры зарегистрированных данных учета времени" математика сшивания сломалась. Функция уточнения периодов сформировала пересекающиеся интервалы в таблице ВТПериодыДействияОбщихГрафиковСотрудников.

Из-за этого в итоговой таблице ВТДанныеРегистровУчетаВремени на даты 07.07 и 08.07 произошел рассинхрон. Срез последних (СрезПоследних) выбрал график с более свежим моментом времени (Смена №1), а функция вырезания периодов не смогла корректно сопоставить дату с уже стоящим там флагом УстановленДень8.

Фрагмент дампа итоговой таблицы ВТДанныеРегистровУчетаВремени (первые 15 дней месяца):

Как мы видим, 07.07 и 08.07 платформа проигнорировала логику смены №4 и выдала данные по Смене №1, которая в регистре была записана более поздним документом.

Часть 4. Как мы это чинили (и как чинить нельзя)

Чего делать категорически нельзя:
Просто удалить «лишние» записи из регистра "График работы сотрудников" напрямую, если Табель уже проведен. Функция УточнитьПериоды все равно будет опираться на «залипшие» флаги в "Параметры зарегистрированных данных учета времени", и часы останутся кривыми.

Пользовательский «костыль», который сработал:
Мы ввели еще один, финальный документ изменения графика на проблемные даты (07.07 и 08.07), перекрыв «грязные» данные. Поскольку у нового документа был более свежий номер и момент времени, СрезПоследних выбрал именно его, игнорируя старый мусор. Табель был перезаполнен, флаги сбросились, и часы встали верно. Этот способ работает, но не является архитектурно чистым.

Рекомендуемый алгоритм исправления:

1. Отменить проведение документа «Табель» за проблемный месяц (очистить регистр "Параметры зарегистрированных данных учета времени").

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

3. Заполнить «Табель» заново.

Часть 5. Памятка для расчетчиков (Превентивные меры)

Чтобы не ловить этот баг в будущем, мы внедрили в проекте жесткие правила, которыми делимся с сообществом:

1. Запрет на «качели». Менять общий график работы внутри месяца допускается не более одного раза. Если нужно поменять режим на 2–3 дня — используйте документ «Индивидуальный график», не трогая основной.
2. Строгая очередность. Если сотруднику меняют график задним числом: сначала отменяем проведение Табеля; затем вводим кадровый документ; затем заполняем Табель заново. Менять график при уже заполненном Табеле нельзя.
3. Контроль стыков. Интервалы графиков не должны пересекаться. ЗУП отлично переваривает стык «день в день» (старый график действует по 09.07.2026 23:59:59, новый начинается с 10.07.2026 00:00:00), но ломается при малейшем наложении дат.

Заключение

Механизм УточнитьПериодыЗаполненияПоСотрудникам — яркий пример того, как попытка разработчиков 1С «оптимизировать» расчеты через временные таблицы приводит к хрупкости системы при нештатных пользовательских вводах.

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

Связанные публикации и материалы

• Автоматическая диагностика графиков работы в табеле 1С:ЗУП 3.1: внешняя печатная форма для предотвращения ошибок расчета