Processus de données / 14
Transférer les commandes. Garder les statuts traçables.
La boutique signale le paiement, l’ERP n’a pas encore de commande et le service d’expédition dispose déjà d’un numéro de suivi. Nous relions ces étapes avec des états définis, des références de commande uniques et une reprise planifiée.
La situation initiale
Un même libellé de statut peut avoir un sens différent dans chaque système.
Le statut « terminé » peut clôturer le traitement dans la boutique, mais désigner une comptabilisation de facture dans l’ERP. Une livraison partielle concerne certaines lignes ; un remboursement n’annule pas automatiquement toute la commande.
Nous définissons les événements métier et les transitions autorisées. Paiement, commande, stock, expédition et facture restent des domaines de responsabilité distincts. L’intégration rend leurs relations visibles.
Ce que DataSource prend en charge
Transfert de commande. Modèle de statuts. Retour.
Transfert de commande
Associer le numéro externe de commande à l’identifiant cible. Vérifier les lignes, taxes, devises et adresses de livraison avant la création.
Modèle de statuts
Mapper les statuts système sur les états métier. Spécifier séparément quantités partielles, annulations, remboursements et modifications ultérieures.
Retour
Renvoyer les états cibles confirmés et les informations d’expédition. Traiter les événements répétés et les réponses d’écriture ambiguës à partir de l’identité de la commande.
angenommen → im ERP bestätigt → in Bearbeitung
↓
teilversendet
↓
versendet
Doppeltes Ereignis → bekannten Effekt abgleichen
Älteres Ereignis → aktuellen Zustand erhaltenScénario technique / Exemple illustratif
Renvoyer l’expédition sans réappliquer d’anciens états.
Extrait illustratif d’une machine à états. Les noms de statuts réels sont définis avec les systèmes concernés. Les événements s’appliquent à une commande ou une ligne, pas à l’ensemble des données.
Données d’exemple et règles proposées. Les interfaces et règles métier concrètes seront examinées pour votre projet.
Gestion des erreurs, sécurité et exploitation
Doublons : vérifier et exploiter.
Doublons
Après un timeout, vérifier d’abord si la commande a déjà été créée. Une seconde création peut doubler les réservations, factures ou expéditions.
Ordre
Les événements peuvent arriver en retard. Vérifier l’état cible et la version ; isoler les transitions problématiques pour clarification.
Rapprochement
Comparer régulièrement les commandes ouvertes entre les systèmes. Signaler de manière ciblée les transferts non confirmés et les lignes définitivement rejetées.
Questions métier
Les détails qui comptent avant la mise en œuvre.
Commandes · Stocks · Transitions d’état · Livraison partielle · Rapprochement
Peut-on simplement copier le stock de la boutique vers l’ERP ?
Cela dépend du système de référence pour les stocks et réservations. Sinon, une même commande peut réduire plusieurs fois la quantité disponible.
Comment représenter les livraisons partielles ?
Avec des lignes, des quantités et des références de livraison uniques. Un seul statut de commande ne suffit souvent pas.
Les webhooks sont-ils indispensables ?
Non. Un rapprochement périodique via API peut convenir. Les webhooks peuvent réduire les délais, mais nécessitent les mêmes règles d’identité et de répétition.
Pour la clarification technique
Partir de votre processus concret.
Décrivez les systèmes, listes de statuts, exemples de commandes et lignes, ainsi que le processus réel de paiement et d’expédition. Un incident réel anonymisé facilite la priorisation.
Le premier échange clarifie les accès disponibles, la responsabilité des données et un premier flux limité. Nous convenons ensuite du périmètre, des responsabilités et des conditions.
Des exemples anonymisés suffisent pour commencer. Merci de ne pas envoyer de mots de passe, tokens ou données personnelles de production dans la première demande.
Problématiques associées
La prochaine connexion dans son contexte.
Connecter WooCommerce à votre ERP
Les articles sont gérés dans l’ERP, retravaillés dans la boutique et mis à jour par fichiers. Nous relions les modèles de données et clarifions quelles informations relèvent de l’ERP et lesquelles restent dans la boutique.
Traiter les webhooks de manière fiable
Un événement arrive et doit déclencher une action dans le système suivant. Livraisons multiples, retards ou panne de l’API cible en font un processus d’exploitation. Nous le développons avec des événements explicites et des effets vérifiables.
Synchroniser les données entre systèmes
Un client est modifié dans le CRM et aussi dans l’ERP. Quelle version fait autorité ? Nous construisons la synchronisation autour des responsabilités métier et des identités stables afin que les transferts réguliers ne créent pas de conflits silencieux.