Inbound orders : le manifest qui ne ment pas

Chaque camion qui entre au dock a une histoire. Le contrat dit une chose. Le chauffeur en dit une autre. Les pallet labels en disent une troisième. L’inbound order est l’endroit où ces histoires convergent — et où, si c’est bien fait, elles sont réconciliées avant que les assets deviennent inventory.

Cinq types d’inbound

Un inbound order a un type qui dit de quel genre d’arrivée il s’agit : standard (achat ponctuel ou trade-in), lease return (matériel en fin de leasing, avec chargeback rules sur l’order), buyback (vous l’avez vendu, le client vous le renvoie), recycling (downstream uniquement, pas de resale), ou donation. Le type décrit la nature commerciale du shipment. Le workflow que suivent les assets, lui, vient du contrat sous lequel l’order est placé — le workflow template a été choisi à la création de ce contrat, et il est le même pour chaque order qui en dépend.

Numéros et statuts

Chaque order reçoit un numéro du type INB-2026-00017, émis par tenant et par année par un compteur en base sur lequel deux collègues créant un order à la même seconde ne peuvent pas se télescoper. L’order passe par draft, confirmed, in transit, arrived, receiving, received, puis completed ou cancelled. Votre équipe avance le statut étape par étape et peut le reculer là où son rôle l’autorise. Modifier la commande — client, contrat, coordonnées de contact, quantité attendue, arrivée planifiée, références, notes — reste disponible jusqu’à Received ; ensuite l’order est verrouillé, avec la raison à l’écran, parce que le record de ce qui est arrivé ne devrait pas dériver après l’arrivée.

Manifests

Chaque inbound order peut porter un manifest attendu — les line items que le client a annoncés, importés depuis Excel ou CSV. Le manifest n’est pas la vérité, c’est la claim. Le receiving est l’endroit où la claim est réconciliée avec la réalité : l’onglet matching affiche chaque ligne comme matched, pending, partial, missing ou extra, et les lignes pending peuvent être reçues en masse avec une condition commune quand 200 machines identiques arrivent exactement comme promis. Exporter en CSV écrit les assets reçus et les lignes de manifest encore ouvertes dans un seul fichier, pour le client qui veut voir les deux colonnes côte à côte.

Photo report

Chaque inbound order a un photo report — une vue prête à imprimer des photos prises par vos opérateurs à l’intake, ancrée à l’order. C’est l’artefact qui évite le débat « ce Dell avait une charnière fissurée à l’arrivée, non il ne l’avait pas » trois semaines plus tard. Si l’order n’a pas encore d’assets reçus, ou des assets mais pas de photos, le rapport le dit dans un avertissement visible, et l’impression ou l’enregistrement en PDF demande d’abord une confirmation. Un rapport vide peut être utile en interne ; il ne devrait jamais quitter le bâtiment en ayant l’air d’une preuve.

D’où vient l’order

Un inbound order né d’une collection affiche cette collection dans son en-tête, pour que n’importe qui sur le dock puisse vérifier où les marchandises ont été promises, planifiées et livrées avant le début du receiving. Si le handoff automatique depuis une collection delivered a échoué, la page collection garde un bouton Créer la commande entrante tant qu’aucun order n’est lié — même chemin de création, aucune ressaisie.

Pourquoi un order n’est pas une session

Un inbound order est la claim contractuelle. Une receiving session est la réception physique. Ce sont deux entités séparées pour une raison — voir l’article receiving-sessions. L’order reste ouvert sur plusieurs sessions si un même shipment arrive en deux camions, et l’onglet des assets reçus cherche dans tout ce qui a été reçu sous l’order avant de paginer, donc les serials de la huitième palette se retrouvent aussi facilement que ceux de la première.