Vier-Crate-Workspace mit:
- Domain: Account, Car, Tour, Delivery, DeliveryItem, DeliveryNote, Customer,
Article, Warehouse, ScanState, AuditAction — alle mit serde + feature-gated
utoipa::ToSchema.
- Application: Ports (TourRepository, DeliveryRepository, ScanRepository,
DeliveryNoteRepository, CarRepository, AuthService) und Use Cases.
- Infrastructure: Postgres-Adapter via sqlx (PgTourRepository etc.) +
Keycloak-AuthService mit JWKS-Cache + OIDC-Discovery.
- API: Axum 0.8, utoipa-OpenAPI + Swagger-UI, JWT-Bearer-Middleware,
AuthenticatedUser-Extractor.
Endpoints:
- GET /me/tours/today, /tours/{id}, /accounts/{pn}, /me/cars, /health
- POST /sync/tour, /scans (bulk + idempotent via clientScanId),
/deliveries/{id}/{hold,resume,cancel,complete,notes}, /me/cars
- PUT /tours/{id}/delivery-order, /deliveries/{id}/assigned-car, /me/cars/{id}
- PATCH /me/cars/{id}
Datenmodell:
- 6 Migrationen (accounts, tours/deliveries/items + Stammdaten,
scan_audit mit clientScanId-UNIQUE, state_reason refactor,
delivery_notes, cars + FKs nachziehen).
- Business-stabile Beleg-Keys (belegart_id, belegnummer) für ERP-Sync.
- Append-only scan_audit + embedded scan_state als doppelte Wahrheit.
Dev-Setup:
- docker-compose mit Postgres 17 + Keycloak 26
- Keycloak-Realm 'holzleitner' mit Public-Client (PKCE), Testfahrer
(PN 1001) + Audience-/Personalnummer-Mapper
51 lines
1.7 KiB
Rust
51 lines
1.7 KiB
Rust
use chrono::{DateTime, NaiveDate, Utc};
|
|
use serde::{Deserialize, Serialize};
|
|
use uuid::Uuid;
|
|
|
|
/// Phasen des geführten Tagesablaufs eines Fahrers.
|
|
///
|
|
/// Die Reihenfolge der Varianten entspricht dem natürlichen Fortschritt;
|
|
/// `PartialOrd`/`Ord` werden derived, sodass `current < max_reached`
|
|
/// als „besucht"-Check funktioniert.
|
|
///
|
|
/// `Auswaehlen` ist optional und nur sichtbar bei Accounts mit mehreren
|
|
/// Fahrzeugen — die Eintrittsphase bei einem Ein-Auto-Account ist
|
|
/// `Sortieren`.
|
|
#[derive(
|
|
Debug, Clone, Copy, Serialize, Deserialize, PartialEq, Eq, Hash, PartialOrd, Ord,
|
|
)]
|
|
#[cfg_attr(feature = "openapi", derive(utoipa::ToSchema))]
|
|
#[serde(rename_all = "snake_case")]
|
|
pub enum DeliveryPhase {
|
|
Auswaehlen,
|
|
Sortieren,
|
|
Beladen,
|
|
Ausliefern,
|
|
}
|
|
|
|
/// Prozess-State pro Fahrzeug pro Tag. Trägt sowohl die aktuelle Phase
|
|
/// als auch die höchste je erreichte Phase — damit Rück- und
|
|
/// Vorwärtssprünge zwischen besuchten Phasen erlaubt sind.
|
|
///
|
|
/// `sorting_order` ist die in der Sortier-Phase festgelegte
|
|
/// Auslieferungsreihenfolge (Liste von [`crate::domain::Delivery`]-IDs).
|
|
/// Bei der Beladung wird sie umgekehrt benutzt (letzte Lieferung zuerst
|
|
/// ins Auto).
|
|
#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, Eq)]
|
|
#[cfg_attr(feature = "openapi", derive(utoipa::ToSchema))]
|
|
#[serde(rename_all = "camelCase")]
|
|
pub struct DeliveryProcessState {
|
|
pub id: Uuid,
|
|
pub car_id: Uuid,
|
|
pub date: NaiveDate,
|
|
|
|
pub current_phase: DeliveryPhase,
|
|
pub max_reached_phase: DeliveryPhase,
|
|
|
|
pub sorting_order: Vec<Uuid>,
|
|
|
|
/// Gesetzt sobald die Sortierung bestätigt wurde — markiert den
|
|
/// Übergang von `Sortieren` nach `Beladen` als „offiziell".
|
|
pub confirmed_at: Option<DateTime<Utc>>,
|
|
}
|