Repérer les commandes en retard dans vos données
Préparez un rapport opérationnel qui distingue les commandes encore en attente de celles expédiées en retard.
Par l'équipe Datarelix · Publié le · Mis à jour le · Vérifié le
Une « commande en retard » peut désigner une commande non expédiée, expédiée après la date promise ou livrée trop tard. Ce sont trois rapports différents. Choisissez l’événement sur lequel l’équipe peut agir avant de demander un total ; vous pouvez ensuite interroger la base des opérations en langage naturel et examiner les lignes renvoyées.
Cet exemple repère les commandes en attente d’expédition à une date fixe. Il faut un accès aux identifiants, aux paiements et aux dates d’expédition promises et réelles ; les coordonnées des clients ne sont pas nécessaires au premier rapport.
Définir la référence et les exclusions
La référence est le 8 septembre 2026 à 00:00 UTC. Incluez les commandes payées avant cette borne, promises avant cette borne et non expédiées avant elle. Excluez les commandes annulées. Une date promise absente relève de la qualité des données, pas d’une livraison à l’heure.
| Commande | Expédition promise, UTC | Expédition réelle, UTC | Incluse à la référence ? |
|---|---|---|---|
| 1042 | 5 sept., 10:00 | Non enregistrée | Oui |
| 1056 | 7 sept., 16:00 | 8 sept., 09:00 | Oui, expédiée après la borne |
| 1061 | 7 sept., 12:00 | 7 sept., 11:00 | Non, déjà expédiée |
| 1070 | 8 sept., 00:00 | Non enregistrée | Non, promise exactement à la borne |
Les quatre commandes sont payées et non annulées. Le résultat attendu est de deux commandes en attente. Les cas limites permettent de vérifier la définition.
Demander les lignes à examiner
Au 8 septembre 2026 à 00:00 UTC, liste les commandes payées non annulées promises avant cette heure, sans expédition avant cette heure. Affiche l’identifiant, l’expédition promise et l’expédition réelle. Trie les promesses les plus anciennes en premier.
Exemple PostgreSQL :
SELECT order_id, ship_by, shipped_at
FROM orders
WHERE status <> 'cancelled'
AND paid_at < TIMESTAMPTZ '2026-09-08 00:00:00+00'
AND ship_by < TIMESTAMPTZ '2026-09-08 00:00:00+00'
AND (shipped_at IS NULL
OR shipped_at >= TIMESTAMPTZ '2026-09-08 00:00:00+00')
ORDER BY ship_by, order_id;
Ce calcul utilise le statut d’annulation conservé. Si une annulation peut intervenir après la borne et écraser l’ancien statut, un historique est nécessaire pour reconstituer exactement le passé. Précisez cette limite dans le rapport. La requête découle de la formulation de la demande, comme le montre comment le text-to-SQL génère les requêtes : indiquez explicitement la borne et son fuseau horaire.
Pour les expéditions partielles, décidez si la première expédition ou l’expédition complète clôt la commande. Un horodatage au niveau de la commande peut ne pas suffire. Demandez quel événement représente la règle choisie.
Comparer des périodes équivalentes
Le nombre en attente est un instantané. Le taux d’expédition en retard porte sur une cohorte de commandes. Pour un taux hebdomadaire, le dénominateur peut être les commandes éligibles promises cette semaine ; le numérateur, celles expédiées tard ou encore en attente à la date de revue. Utilisez des fenêtres de revue comparables.
Huit retards sur 100 commandes représentent 8 %. Douze sur 200 représentent 6 %. La seconde semaine a plus de retards en nombre, mais un taux plus faible. Présentez le nombre et le dénominateur avant de conclure.
Regroupez par entrepôt ou transporteur seulement si ces champs sont renseignés de façon cohérente. Le résultat indique où enquêter ; il n’établit pas la cause du retard.
Examiner les exceptions avant d’attribuer le travail
Le responsable opérationnel définit la promesse et l’événement d’expédition. L’analyste vérifie l’effet de l’historique des statuts, des envois fractionnés et des doublons d’événements. Fixez la borne du rapport avant de le comparer à l’écran de gestion, qui peut afficher un état plus récent.
Vérifiez la commande la plus ancienne incluse et une commande exclue à la borne, puis appliquez les contrôles de jointure et de filtre de vérifier le SQL et les résultats générés par IA avant d’utiliser la liste. Isolez les dates promises manquantes et les statuts inconnus pour investigation, sans les classer silencieusement à l’heure. Le livrable utile contient les identifiants vérifiables, la raison de leur inclusion et des décomptes cohérents avec la liste.
Préparer la revue opérationnelle
Dans Datarelix, examinez les lignes et le SQL, puis demandez un nombre de commandes par date promise. Vérifiez que le total du graphique correspond au tableau. Enregistrez le graphique vérifié dans un tableau de bord privé, comme le montre créer un tableau de bord à partir de questions sur vos données ; son actualisation manuelle relance la requête.
La borne fixe conserve la question historique. Pour le suivi du jour, demandez une borne relative avec son fuseau horaire. Si la source est un réplica, contrôlez sa fraîcheur avant de considérer une commande récemment expédiée comme encore en attente.
Datarelix ne modifie pas les commandes et n’avertit pas les clients. Utilisez les identifiants vérifiés dans votre procédure opérationnelle autorisée. Consultez le guide de reporting MySQL ou connectez une autre source.