Collections: schedule -> confirm -> drive -> deliver -> inbound
Le workflow pickup qui finit par creer un inbound order, avec client et contrat déjà remplis.
Une collection en ITAD, c'est l'action d'aller sur le site du client et d'y récupérer l'équipement. C'est aussi la partie du workflow où, dans la plupart des opérations, on retape le plus de choses — nom du client, référence de contrat, contact info, tout saisi trois fois dans trois systèmes.
Le status flow
Une collection commence en requested (depuis /request-collection sur le site marketing ou créée par l'opérateur). Elle passe à confirmed quand le créneau est verrouillé et le client notifié. À scheduled quand un driver et un vehicle sont assignés. À in_progress lorsque le driver check in sur le site client. À collected quand l'équipement est chargé. À delivered lorsqu'il arrive au warehouse — et à ce moment-là, l'inbound order se crée automatiquement avec le client, le contrat, le contact et la vehicle reference déjà remplis.
Multi-trip pickups
Certaines collections ne tiennent pas dans un seul truck. Une collection peut contenir plusieurs trips, chacun avec son driver, vehicle, scheduled-date et sous-enregistrement items-loaded. La collection reste un pickup logique unique côté client ; les trips suivent la réalité physique. L'inbound order créé à la fin consolide tous les trips dans un seul inbound — le manifest se réconcilie contre l'union, pas contre trip-1-only.
Driver and fleet
Drivers et vehicles vivent dans leurs propres catalogues (/settings/core/drivers, /settings/core/fleet) afin d'être assignés sans saisie manuelle. Un driver a une license-class et un certification-level (certains sites exigent un driver security-cleared). Un vehicle a une capacity et des access constraints (un van 3.5T passe là où un truck 7.5T ne passe pas).
Tracking and revert
La page détail collection (/core/collections/[slug]) affiche status, driver, vehicle, scheduled-date et items-expected. Si un statut doit être réverti (le driver a été assigné au mauvais créneau, la collection n'a pas réellement eu lieu), le revert-preview montre les side-effects qui seront inversés avant que le changement soit committed. Les database triggers protègent les transitions : impossible de marquer "delivered" sans un record "collected" avant.
Public request form
/request-collection sur le site marketing est la version public-facing : un formulaire en cinq étapes permettant aux prospects de demander eux-mêmes un pickup. La submission arrive comme draft collection avec les données structurées, prête à être confirmée ou ajustée par l'opérateur.