Une petite demande est arrivée : « On a seulement besoin de trois champs dans l’ERP. » Sur papier, ça devait prendre quelques minutes. Puis j’ai ouvert le modèle de données et le mot seulement a commencé à perdre beaucoup de force.

Dans un ERP, le même numéro apparent peut désigner une commande, sa ligne, une livraison ou une facture. Ce n’est pas de la complexité ajoutée pour le plaisir. Une commande de dix vélos peut être livrée en deux fois, facturée en deux documents et partiellement retournée. Une seule rangée ne pourrait pas représenter ces événements sans répéter ou écraser de l’information.

Un modèle simplifié ressemble plutôt à ceci :

Commande (IdCommande, IdClient, DateCommande, Statut)
    1 ─── n LigneCommande (IdLigne, IdCommande, Article, QteCommandee)
              1 ─── n LigneLivraison (IdLivraison, IdLigne, QteLivree)
              1 ─── n LigneFacture   (IdFacture, IdLigne, QteFacturee, Montant)

Le trajet métier fait évoluer ces lignes dans le temps. Une commande est saisie, confirmée, réservée dans l’inventaire, préparée, expédiée, puis facturée. Chaque étape a son propre statut parce qu’elles ne se terminent pas toujours ensemble. Un en-tête Commande.Statut = 'OUVERTE' ne dit pas combien a déjà été livré ni si une facture attend une correction.

Le danger d’une extraction rapide est la cardinalité. Si je joins une ligne de commande à deux livraisons et deux factures, le résultat peut contenir quatre rangées. Additionner directement QteLivree doublera alors la quantité. Il faut agréger chaque branche avant de les réunir :

SELECT lc.IdLigne,
       lc.QteCommandee,
       COALESCE(liv.QteLivree, 0) AS QteLivree,
       COALESCE(fac.QteFacturee, 0) AS QteFacturee
FROM LigneCommande lc
LEFT JOIN (
    SELECT IdLigne, SUM(QteLivree) AS QteLivree
    FROM LigneLivraison
    GROUP BY IdLigne
) liv ON liv.IdLigne = lc.IdLigne
LEFT JOIN (
    SELECT IdLigne, SUM(QteFacturee) AS QteFacturee
    FROM LigneFacture
    GROUP BY IdLigne
) fac ON fac.IdLigne = lc.IdLigne

Même une requête techniquement juste dépend d’une définition. « Commandes actives » peut vouloir dire non annulées, pas complètement livrées, pas complètement facturées ou encore modifiables par le service à la clientèle. Je veux écrire cette règle en mots avec une personne qui connaît le processus, puis la traduire en statuts et quantités.

Les exceptions expliquent souvent les colonnes moins élégantes. Une livraison partielle, une substitution d’article, une correction urgente ou un retour après facturation ne suit pas la belle flèche du diagramme. Si l’ERP ne permet pas l’exception, elle finit dans un chiffrier ou une note. Mon rapport doit alors annoncer ce qu’il ne voit pas au lieu de présenter l’extraction comme toute la réalité.

Lire directement les tables de production ajoute des contraintes. Une grosse requête peut garder des verrous et ralentir la saisie. Une lecture sans verrou peut voir une combinaison incohérente pendant qu’une transaction modifie plusieurs tables. Pour un rapport fréquent, une extraction planifiée vers une base de reporting peut stabiliser les données. Elle doit conserver une heure de coupe et permettre une réconciliation, par exemple comparer le nombre et le total des commandes chargées au système source.

En cas de panne ou d’échec au milieu de l’extraction, je garde le lot précédent comme dernière version complète et je reprends avec le même identifiant de lot. Publier la moitié des commandes donnerait un rapport propre en apparence, mais faux jusque dans ses totaux.

Je ne modifierais jamais les tables de l’ERP avec un UPDATE improvisé. Les règles applicatives, le journal et les écritures comptables associées pourraient être contournés. Une interface officielle, une procédure documentée ou l’écran prévu garde le processus cohérent. Les droits SQL de mon compte de rapport devraient d’ailleurs être en lecture seulement.

Avant mon premier SELECT, je veux maintenant le dictionnaire de données, un schéma des relations, cinq cas réels dont une livraison partielle et une définition signée du chiffre demandé. Ensuite je vérifie un petit échantillon jusque dans les documents source. « Trois champs » peut rester la sortie; comprendre les tables et les transitions est le travail qui rend ces trois champs vrais.