Ordre de transport : modèle et checklist des informations à réunir avant la saisie

Trois statuts pour ne pas confondre fait, règle et hypothèse

Avant toute saisie, attribuez un statut à chaque information. Une donnée reçue est lisible dans la demande ou dans une pièce identifiée. Une règle connue vient d’un référentiel, d’un contrat ou d’une consigne métier validée pour ce client et ce flux. Une information manquante ne possède aucune réponse suffisamment sûre dans les sources autorisées.

Cette séparation est plus utile qu’une simple case « commande complète ». Elle montre ce qui peut être repris tel quel, ce qui exige l’application explicite d’une règle et ce qui doit être demandé. Elle conserve aussi la provenance de la valeur qui sera finalement proposée au TMS.

• Donnée reçue : conserver la source, la date et, lorsqu’elle existe, la version du document ou du message.
• Règle connue : indiquer le périmètre, la version et la personne ou le processus qui l’a validée.
• Information manquante : nommer la décision empêchée et l’interlocuteur capable de la préciser.

Modèle vierge d’ordre de transport à compléter

Copiez ce modèle pour chaque nouvelle demande. Les formulations entre crochets sont des invites de travail : remplacez-les par une valeur sourcée ou laissez explicitement la donnée dans la colonne « À préciser ». Une ligne vide ne doit pas être interprétée comme un accord tacite.

Remplir la checklist dans l’ordre des décisions

La complétude dépend du workflow réel. Un champ peut être indispensable dans un flux et sans effet dans un autre. L’équipe doit donc définir les critères de préparation et de saisie avec les personnes responsables du TMS, des engagements client et de l’exécution opérationnelle.

1. 01
   Qualifier la demande

   Déterminer s’il s’agit d’une création, d’une modification, d’une annulation ou d’un complément. En cas de doute, ne créez pas un nouvel ordre par défaut.

2. 02
   Identifier les parties et les sites

   Relier le donneur d’ordre, les contacts, l’enlèvement et la livraison aux références réellement fournies ou aux référentiels autorisés.

3. 03
   Structurer le temps et la marchandise

   Conserver les dates, fuseaux, créneaux, quantités, unités, poids et volumes tels qu’ils ont été exprimés, puis signaler toute conversion appliquée.

4. 04
   Faire apparaître les contraintes

   Séparer les instructions explicites des règles déjà validées : accès, matériel, manutention, contact préalable ou autre condition propre au flux.

5. 05
   Décider du prochain état

   Si chaque décision nécessaire possède une base vérifiable, le dossier peut être préparé. Sinon, formulez une question ciblée ou transmettez le cas avec son contexte.

Exemples remplis : une commande exploitable et une commande à faire préciser

Les deux lignes suivantes sont des exemples fictifs. Elles montrent comment le même modèle rend visible la différence entre une commande suffisamment étayée et une demande dont une décision reste impossible.

Passer du modèle à une saisie contrôlée

Une fois la checklist renseignée, la saisie reste une action distincte. Les valeurs préparées doivent être relues selon le niveau de supervision retenu, écrites par le moyen autorisé — API, fichier ou interaction avec l’interface — puis comparées à l’état réellement affiché dans le TMS.

Vigilo peut relier la demande, les pièces, les règles applicables et la décision autour du même dossier. Sur un périmètre configuré et validé, il peut préparer ou exécuter l’action autorisée, contrôler son résultat et transmettre à l’équipe les cas ambigus avec leur contexte. Cela ne suppose ni compatibilité instantanée avec tout TMS, ni disparition de la validation humaine.

• conserver la source de chaque valeur préparée ;
• marquer les règles effectivement appliquées ;
• bloquer les champs ambigus ou hors périmètre ;
• vérifier l’identifiant et l’état obtenus après la saisie ;
• rattacher toute correction ultérieure à la bonne version du dossier.