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