Учёт выходов персонала: заявка, назначение и факт

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

Ниже предложена информационная модель на вымышленной заявке. Она не устанавливает трудовые отношения, правила допуска, нормы времени, порядок оплаты или законность конкретного способа предоставления персонала. Эти вопросы рассматривают со специалистами отдельно. Условные номера людей и часы служат для проверки программы; они не являются табелем, документом расчёта или данными настоящих сотрудников.

Сначала определите единицу потребности

В учебной заявке объекту А нужны три человека с 09:00 до 13:00. Это три одновременно требуемых места и двенадцать плановых человеко-часов: три умножить на четыре. Две величины связаны, но отвечают на разные вопросы. Число назначенных людей не показывает, была ли потребность закрыта в каждый момент выбранного периода.

У места в заявке сохраните объект, задачу, предусмотренный интервал и необходимые уточнения по процессу компании. Если разные работы требуют разных условий, не объединяйте их общей цифрой. Два человека на одну задачу и один на другую — другой состав потребности, чем три взаимозаменяемых места. Программа должна показывать такое различие до назначения исполнителей.

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

Назначение не равно подтверждению выхода

Назначение показывает принятое решение о предполагаемом исполнителе. Сообщение человека о готовности, подтверждение диспетчера и наблюдение на объекте относятся к разным событиям. Определите, какие сведения доступны в вашей работе и кто их вносит. Если факт ещё не подтверждён, программа должна показывать ожидание уточнения, а не автоматически записывать присутствие по плану.

В учебном списке назначены У-1, У-2 и У-3. У-1 и У-2 подтверждены с 09:00. По У-3 до 10:00 подтверждённого присутствия нет; затем на третье место выходит замена У-4. Четыре разных номера в истории не означают четыре одновременно закрытых места. Для разбора нужны назначения, результаты и интервалы их действия.

Отсутствие подтверждения не является автоматическим доказательством неявки. В конкретном процессе диспетчер уточняет сведения и фиксирует установленный результат. В учебном расчёте ниже отдельно задано, что третье место с 09:00 до 10:00 оставалось незакрытым. Такой вывод основан на условии примера, а не на пустой ячейке программы.

Замена связывает две истории, не стирая первую

Запишите, какое назначение заменяется, с какого момента и на какое место выходит новый человек. Не переписывайте У-3 на У-4 во всей карточке так, будто первоначального назначения не существовало. Иначе исчезнут причина обращения диспетчера и объяснение утреннего разрыва. Одновременно не оставляйте оба назначения действующими на одном месте без обозначения смысла.

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

У замены сохраняют причину в необходимой детализации и следующий шаг. Не собирайте медицинские или другие избыточные подробности ради заполнения поля. Для диспетчерской задачи может быть достаточно установленного основания изменения и того, кто продолжает обработку. Доступ к сведениям о людях определяют отдельно; общий экран клиента не должен случайно раскрывать внутреннюю историю других объектов.

Покрытие считают по времени, а не по сумме отметок

Для учебного примера У-1 даёт четыре часа покрытия первого места, У-2 — четыре второго, У-4 — три третьего. Получается одиннадцать человеко-часов при плановых двенадцати. С 09:00 до 10:00 закрыты два места из трёх, с 10:00 до 13:00 — три из трёх. Поэтому итоговое количество нельзя использовать как доказательство полной обеспеченности во всём периоде.

Если к третьему месту ошибочно прикрепили два перекрывающихся интервала присутствия, простое сложение завысит покрытие этого места. Для показателя обеспеченности требуется разбор объединения подтверждённых интервалов в пределах согласованной потребности. Фактически присутствовавшие люди при этом остаются отдельными записями: их нельзя удалить ради удобного итога.

Различайте показатель покрытия заявки и другие показатели времени. Время нахождения на объекте, принятые работы, согласованные перерывы и основания расчётов могут иметь собственные правила. Нельзя применять приведённую арифметику как универсальную методику начислений. Её назначение — показать диспетчеру промежуток незакрытой потребности в рамках явно заданной модели.

Исправление отметки не должно удваивать результат

Сведения могут прийти повторно или быть исправлены после уточнения. Повтор сообщения об У-4 не создаёт ещё три часа покрытия. Исправленный интервал должен иметь связь с предыдущим основанием и понятное решение о действующей записи. Совпадение имени и даты недостаточно для автоматического объединения любых сообщений.

Сохраните автора, время внесения и относящийся к событию период там, где это предусмотрено процессом. Позднее внесение сведений не означает позднее начало работы. Если диспетчер получил подтверждение в 11:00 о начале в 10:00, эти две отметки отвечают на разные вопросы. Не копируйте время получения автоматически в поле начала подтверждённого интервала.

При противоречии оставляйте вопрос видимым до разбора. Например, один ответ указывает 10:00, другой — 10:30. Программа не должна выбирать удобное значение для полного закрытия плана. Назначьте ответственного за уточнение и покажите, что зависит от решения. Итоговая цифра должна быть объяснимой, даже когда часть сведений ещё не установлена.

На общем экране отдельно показывайте назначенного и подтверждённого исполнителя. Если эти значения отличаются, рядом должно быть объяснение замены или открытый вопрос. Для незавершённой смены полезно обозначить границу доступных сведений: подтверждено по определённый момент, окончательный результат ещё ожидается. Иначе промежуточная запись будет выглядеть как принятый итог всего дня.

Принимайте программу на одной неполной смене

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

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

Учёт кандидатов по вакансиям описан в отдельной статье о нескольких подборах одного человека. Здесь результат другой: понятно, какая потребность в конкретном периоде подтверждена и что осталось уточнить. Такое разграничение помогает обсуждать разработку программы без смешения подбора, диспетчеризации и расчётов в одной недостоверной отметке.