автоматизация табелей связывает события прихода, ухода и отсутствия с записью фактически отработанного времени, которую подтверждает ответственный сотрудник. Плановая смена помогает найти расхождение, но строка табеля отражает проверенный факт и принятые поправки. Для рабочего маршрута понадобятся источники событий, правила сверки, очередь исключений, журнал решений и передача утверждённого набора в расчёт. Такой проект проверяют по полноте происхождения каждой строки и понятному статусу спорных записей.
План и факт
Плановый график показывает ожидаемую смену; табель собирают из подтверждённых событий и решений по расхождениям. Скрипт сверяет данные, а руководитель и кадровик принимают поправки.
Расписание говорит, кто должен выйти на смену. Табель фиксирует, что произошло в действительности: присутствие, отсутствие, согласованную поправку и основание для изменения записи. Одинаковая плановая строка может получить разный итоговый статус после сверки с событиями. Поэтому в схеме храните план, сырые события и утверждённый факт отдельно. Источники времени и роли владельцев задаёт компания в своём регламенте. Статья про график и подмены отвечает на вопрос будущего расписания; здесь центр работы — подтверждение уже произошедшего.
У строки факта нужен понятный путь происхождения: исходное событие, версия сверки, найденное расхождение, комментарий, автор поправки и утверждающий. Если сотрудник отметил приход в системе доступа, это лишь входное событие. Руководитель смотрит связь события с выполненной работой и установленной сменой. Кадровик сверяет статус отсутствия или корректировки со своим источником. Модель может описать, почему записи расходятся, но решение о факте и его учётной трактовке остаётся у людей с назначенными полномочиями.
| Слой | Что содержит | Кто подтверждает |
|---|---|---|
| План | Ожидаемую смену и подмены | Владелец графика |
| События | Отметки прихода, ухода, отсутствия | Владелец источника |
| Факт | Принятую строку с основанием | Руководитель и кадровик |
Связь с общей автоматизацией кадровых действий описана в материале о процессах HR. Для нашего маршрута важна граница: система предлагает строку табеля, но до подтверждения она остаётся черновиком. Так удобно разбирать исключения без тихой подмены учётного факта.
Источники событий
Начните с реестра источников. Это могут быть отметки пропуска, записи системы учёта времени, заявки об отсутствии и утверждённый график. Для каждого источника укажите владельца, идентификатор сотрудника, дату события, тип, первичную запись и способ исправления. Скрипт получает данные из разрешённых выгрузок или интерфейсов, нормализует идентификаторы и сохраняет ссылку на оригинал. Любое преобразование оставляет след: исходное значение, приведённое значение и правило сопоставления. Без этой связи итоговую строку трудно проверить.
Сверка должна различать отсутствие отметки и подтверждённое отсутствие сотрудника. Пробел в источнике образует отдельный вопрос для проверки. Пара отметок также требует проверки на дубль, пересечение и принадлежность нужному сотруднику. Скрипт способен выполнить эти повторяемые условия по правилам компании. Для формул суммирования и полной выгрузки используйте код с воспроизводимым результатом; языковая модель объясняет найденные отклонения и предлагает гипотезы. Человек сверяет исходные записи и решает, что попало в табель.
- Назначьте владельца каждого источника и ключ для связи записей с сотрудником.
- Запишите допустимые типы событий и внутренние правила их сопоставления.
- Сохраните сырые данные отдельно от нормализованной версии и поправок.
- Для пропуска, дубля и конфликта создавайте отдельный статус проверки.
В пилоте предложите ограниченный тестовый набор без реальных персональных подробностей. Он должен включать обычную запись, пропуск отметки, дубль и конфликт с заявкой об отсутствии. Критерий здесь качественный: по каждой итоговой строке проверяющий видит первичное событие и правило преобразования. Общий подход к карте процесса и разбору исключений показан в статье о пилоте автоматизации рутины.
Очередь расхождений
После сверки записи с совпавшими источниками получают статус черновика для проверки, спорные переходят в очередь расхождений. Каждой карточке нужны сотрудник, период, ссылка на план, исходные события, причина сигнала и запрошенное подтверждение. Список причин сформулируйте так, чтобы ответственный мог отличить технический пробел от вопроса к фактическому выходу. Например, система видит отсутствующую отметку ухода и предлагает проверить источник; окончательное решение остаётся за человеком.
Для очереди полезен приоритет по влиянию на передачу данных: строка с непроверенной поправкой остаётся открытой до решения владельца. Модель может кратко объяснить конфликт между событиями, заявкой и графиком, подготовить понятный вопрос руководителю и перечислить документы для проверки. Статус отсутствия и учётное основание определяют уполномоченные сотрудники по проверенным источникам. Руководитель уточняет фактические обстоятельства, кадровик проверяет допустимую трактовку в своём контуре. Оба решения сохраняются с автором и ссылкой на подтверждение.
- Скрипт помечает пропуск, дубль, пересечение и конфликт с планом.
- Модель составляет краткое объяснение сигнала со ссылками на исходные записи.
- Руководитель проверяет факт работы и запрашивает уточнение при необходимости.
- Кадровик сверяет причину отсутствия или исправления по внутреннему источнику.
- Система сохраняет решение и повторно проверяет строку перед утверждением.
Особенно важен отказ от молчаливого исправления: автоматическая догадка может выглядеть правдоподобно, но скрыть проблему исходного события. Очередь нужна именно для сохранения вопроса и ответственного. Если доказательств пока мало, строка остаётся спорной. Так следующий участник видит, что требует ответа, а подтверждённые записи сохраняют ясное происхождение.
Согласование правок
Поправка к табелю — отдельная запись с прежним значением, новым предложением, причиной и ссылкой на подтверждение. Интерфейс показывает различие человеку до отправки решения. Руководитель принимает фактическую сторону поправки в рамках своей роли; кадровик проверяет статус и основание в своём контуре. Сервер проверяет роль, допустимое действие и состояние строки при каждом подтверждении. Подсказка модели помогает подготовить пояснение. Право изменить факт задаёт серверная политика.
Предусмотрите возврат карточки на уточнение и видимый журнал версий. Храните исходное событие и каждую его поправку: эта история объяснит расхождение при повторной сверке. Экспорт разрешён лишь для строк с нужными подтверждениями по правилам компании. Если решение отменено, система сохраняет отмену и актуальный статус, а следующий экспорт получает обновлённую версию данных. Владелец процесса задаёт порядок таких переходов до разработки, затем проверяет их на тестовых карточках.
Покажите проверяющему исходное событие, предложенную правку, автора и причину. Кнопка утверждения доступна только роли с нужным правом; сервер повторно проверяет это право и статус строки.
Для проверки прав подготовьте разрешённый и запрещённый сценарии: руководитель подтверждает свою строку, посторонняя роль получает отказ. Отдельно проверьте повторную отправку уже утверждённой поправки. Итог подтверждают журнал сервера и просмотр карточки человеком. После такой проверки можно обсуждать подготовку передачи данных в расчёт.
Хотите разобрать маршрут подтверждения табеля в вашей команде?
Передача в расчёт
Передача утверждённого факта — отдельный этап после сбора и согласования. Сформируйте набор строк с идентификатором сотрудника, периодом, принятым статусом, ссылкой на подтверждение и версией записи. Скрипт проверяет структуру, повторы и наличие предусмотренных процессом подтверждений, затем создаёт контрольный итог по отправленному набору. Принимающая система подтверждает получение и возвращает идентификатор приёма либо ошибку. Ошибка оставляет строку в очереди передачи с причиной для оператора. Здесь речь о передаче факта, без расчёта зарплаты или определения обязательных форм.
В предлагаемом пилоте проверьте обычную строку, исправленную строку и открытое расхождение. Последнее должно остаться вне утверждённого набора. Сравните выгрузку с журналом решений и входными событиями, затем проверьте подтверждение приёма. Языковая модель может объяснить расхождение в отчёте, а полное сопоставление выгрузок выполняет скрипт. Кадровик и руководитель подтверждают смысл строк, специалист по расчётному контуру проверяет формат передачи и результат приёма.
Цена внедрения зависит от состояния источников, числа правил сверки, ролей согласования и интерфейса принимающей системы. Смету полезно привязать к карте данных, исключениям и критериям приёмки, без универсальной суммы. Обсудить такой контур можно на странице внедрения автоматизации бизнес-процессов. Для кадровой команды связанным материалом остаётся обзор задач ИИ-агента HR-отдела; табель требует собственного журнала подтверждённого факта и отдельной приёмки.
Каждая переданная строка должна вести к исходному событию, принятой поправке при её наличии и подтверждению ответственного. Открытые расхождения остаются в очереди с назначенным владельцем.