Ожидание погрузки: какие события должен хранить учёт рейса

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

Что хочет выяснить диспетчер

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

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

Плановое окно не является фактом прибытия

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

В руководстве X5Transport описано внесение и изменение фактического прибытия и убытия по точкам. Это подтверждает наличие ручного источника в конкретном сервисе, но не автоматическую точность GPS и не одинаковое признание времени всеми сторонами.

Учебная карта одной точки маршрута

Все времена ниже вымышлены и относятся к одной дате в одном часовом поясе. Согласованное окно принято с 09:00 до 09:30. Источники в таблице показывают, какие сведения стоило бы сохранить; это не выполненный нами рейс и не установленные доказательства реального спора.

В одном рейсе несколько разных длительностей

От прибытия до начала работы в примере прошло 80 минут. Сама погрузка заняла 40 минут, а всё присутствие до убытия — 140 минут. Интервал до допуска составляет 30 минут, после допуска до работы — 50, после окончания — 20. Эти величины не стоит называть одним словом без определения.

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

Источник времени должен оставаться видимым

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

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

Исправление факта отличается от нового события

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

Для API-интеграции определите идентификаторы точки и события. Повтор уведомления не должен создавать второе прибытие. При разных часовых поясах сохраняйте однозначный момент и нужное местное представление; одна строка часов без даты и контекста недостаточна.

Если начало операции неизвестно

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

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

Расчёт для претензии требует отдельного основания

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

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

Как принять учёт одной погрузки

1. Создайте учебную точку с плановым окном и пятью фактическими событиями из таблицы. Проверьте дату и часовой пояс.
2. Сверьте отдельно ожидание до работы, длительность операции и общее присутствие. Названия показателей должны соответствовать границам.
3. Удалите факт начала. Полный интервал присутствия остаётся, а точное ожидание до операции становится неизвестным.
4. Добавьте разногласие источников. Принятое значение и первоначальные наблюдения должны быть различимы.
5. Исправьте время после формирования отчёта и повторите внешнее сообщение. Не должно возникнуть второго события или необъяснимого пересчёта.
6. Проверьте отдельное правило расчёта для обращения, не устанавливая универсальный штраф по учебным минутам.

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