lumnik. / scénarios Tous les scénarios · English

Quatre fichiers EDI pour une seule ligne de commande

Objectif Merger les quatre flux pour savoir si chaque ligne est commandée, confirmée ou livrée, et être alerté quand une date confirmée passe sans livraison.

Un fabricant et son logisticien s'échangent quatre fichiers à plat autour d'une ligne de commande: la commande, l'accusé, la date confirmée, le bon de livraison.

L'ADV demande, ligne par ligne:

ZINT_CC_42100001.txt
SAPPRD           NPEC      
SAPPRD           NPEC      EC100001  M. DURAND                               12 RUE DES LILAS                                  69003   FR 42100001    KIT0012     Couverture à barres automatique 8x4 coul30.000    M2  6880001   
SAPPRD           NPEC      EC100001  M. DURAND                               12 RUE DES LILAS                                  69003   FR 42100001    KIT0031     Kit anti-soulèvement sur tube pour couve1.000     U   6880002   
SAPPRD           NPEC      EC100001  M. DURAND                               12 RUE DES LILAS                                  69003   FR 42100001    LIV0000     Livraison couverture à barres France mét1.000     U   6880003   
SAPPRD           NPEC      EC100245  MME FAURE                               LIEU-DIT LES ÉPINETTES - 4 CHEMIN DU MOULIN       84120   FR 42100002    BAC0450     Bâche hiver opaque 10x5                 50.000    M2  6880011   
SAPPRD           NPEC      EC100245  MME FAURE                               LIEU-DIT LES ÉPINETTES - 4 CHEMIN DU MOULIN       84120   FR 42100002    ENR0002     Enrouleur télescopique                  2.000     U   6880012   
SAPPRD           NPEC      EC100245  MME FAURE                               LIEU-DIT LES ÉPINETTES - 4 CHEMIN DU MOULIN       84120   FR 42100002    LIV0000     Livraison bâche France métropole        1.000     U   6880013   
ZINT_CA_0000060001.txt
450017000142100001
ZINT_C1_4500170001.txt
SAPPRD           NPEC      
4500170001  6880001          KIT0012           20261020
4500170001  6880002          KIT0031           20261020
4500170001  6880003          LIV0000           20261021
ZINT_BL_63170001.txt
SAPPRD           NPHC      
63170001        4500170001KIT0012           30.000    6880001
63170001        4500170001KIT0031           1.000     6880002
63170001        4500170001LIV0000           1.000     6880003
manifests/50-order-line-cycle.yaml
kind: Entityname: order_line_cycle_blabel: Cycle d'une ligne de commandedescription: "One order line across the four flows: ordered, acknowledged, confirmed, delivered — the stage is the most advanced flow that names the line."match: [line_id]scopes: [logistics-b]columns:  line_id: { label: "Ligne" }  order_no: { label: "Commande" }  customer_name: { label: "Client" }  article: { label: "Article", prefer: t_scenario_cycle_cc_b }  ordered_qty: { label: "Commandé" }  confirmed_date: { label: "Livraison confirmée" }  delivered_qty: { label: "Livré" }  bl_no: { label: "Bon de livraison" }  stage: { label: "Étape", conflicts: false }   # the flows progress, they do not disagreesources:                                 # the order is the priority: the furthest flow names the stage  - table: t_scenario_cycle_bl_b    map: { line_id: line_id, article: article, delivered_qty: delivered_qty, bl_no: bl_no, stage: stage }  - table: t_scenario_cycle_c1_b    map: { line_id: line_id, article: article, confirmed_date: confirmed_date, stage: stage }  - table: t_scenario_cycle_cc_b    map: { line_id: line_id, order_no: order_no, customer_name: customer_name, article: article,           ordered_qty: ordered_qty, stage: stage }joins:  - table: t_scenario_cycle_ca_b           # the acknowledgement is per order, not per line    from: order_no    to: order_no    map: { po: acknowledged_po }
manifests/60-line-lifecycle.yaml
apiVersion: apps.lumnik.io/v1kind: Workflowmetadata:  name: order-line-cycle-bspec:  scope: logistics-b  provenance: declared  on:    table: connector.v_order_line_cycle_b   # the fused view: the stage only exists there    column: stage    key: line_id                            # one document per order line  states:    - { code: ORDERED, label: "Commandée", initial: true }    - { code: CONFIRMED, label: "Date confirmée" }    - { code: DELIVERED, label: "Livrée", terminal: true }  due:                                      # the deadline is a date the data carries, not a first sighting    column: confirmed_date    states: [CONFIRMED]    zone: Europe/Paris                      # a date-only column: due at the end of that day in Paris    message: "Ligne {doc_key}: livraison confirmée pour le {due}, toujours pas livrée"
$ lm entity get order_line_cycle_f --filter stage=CONFIRMED
LINE_ID  ARTICLE  DELIVERED_QTY  BL_NO  STAGE      CONFIRMED_DATE  ORDER_NO  CUSTOMER_NAME  ORDERED_QTY  ACKNOWLEDGED_PO  _CONFLICTS
6880012  ENR0002                        CONFIRMED  2026-10-22      42100002  MME FAURE      2            4500170002       {}

$ lm entity get order_line_cycle_f --filter stage=ORDERED
LINE_ID  ARTICLE  DELIVERED_QTY  BL_NO  STAGE    CONFIRMED_DATE  ORDER_NO  CUSTOMER_NAME  ORDERED_QTY  ACKNOWLEDGED_PO  _CONFLICTS
6880021  ENR0002                        ORDERED                  42100003  M. NGUYEN      1                             {}
$ lm inbox --type decision.overdue.order-line-cycle-f
ID     WHEN      PROCESS                      MESSAGE                                                                     ENTITY_KEY
20367  just now  workflow:order-line-cycle-f  Ligne 6880012: livraison confirmée pour le 2026-10-22, toujours pas livrée  6880012

Limites

  • La date est lue à la fin du jour, heure de Paris. Une date confirmée changée pour un autre jour passé relance une alerte. Une date déjà signalée, non.
  • Une quantité livrée différente se voit côte à côte. Aucun filtre ne compare deux colonnes.
  • Fichiers synthétiques, sur le gabarit d'un échange réel.

ADV · EDI

Où en est cette ligne de commande?

Quatre fichiers, un partenaire logistique, aucune vue d'ensemble.

Commande, accusé, date confirmée, bon de livraison: chacun dans son format.

Fichiers synthétiques, sur le gabarit d'un échange réel

Le problème

L'ADV ouvre quatre fichiers pour une réponse.

  • Jamais accusée?
  • Confirmée mais pas livrée?
  • Livrée dans une autre quantité?

Rien n'est modifié

Les fichiers restent tels quels.

  • lumnik lit les quatre flux.
  • Il les rapproche ligne par ligne.
  • Chaque ligne prend son étape la plus avancée.

Ce qu'il a fallu écrire

due:
  column: confirmed_date
  states: [CONFIRMED]

La date confirmée devient une échéance.

Le scénario complet tient en 6 fichiers de déclaration, 144 lignes.

Les réponses

Chaque ligne, son étape.

  • 6880012: date confirmée, pas livrée.
  • 6880021: jamais accusée.
  • 6880011: livrée 45 pour 50.

Le retard

La date est passée. La ligne n'est pas livrée.

Boîte de décisions
Ligne 6880012: livraison confirmée pour le 2026-10-22, toujours pas livrée

Message réel, rejeu du 28 octobre 2026.

La limite

lumnik montre l'écart. L'ADV le juge.

  • 45 pour 50 se lit côte à côte.
  • Aucun filtre ne compare deux colonnes.

Essayer

Le scénario se rejoue de bout en bout.

Quatre flux, une fusion, un cycle, une alerte: chaque étape est publiée avec sa sortie.

Ce scénario tourne sur lumnik Open, gratuit et open source.

Essayer lumnik Open →