Le magasin a expédié deux unités et l’entrepôt en a envoyé trois. Dans Business Central, la commande semble servie ; dans Shopify, elle reste partiellement traitée. Le service client doit retrouver deux bons de livraison, vérifier les dépôts et expliquer au client ce qui est réellement parti. Relancer la synchronisation sans comprendre les lignes peut ajouter une confirmation incohérente.
Cette charge support concerne les responsables e-commerce qui utilisent Shopify avec Business Central, leur ADV et leurs équipes logistiques. Elle devient coûteuse avec les reliquats, les mêmes produits présents sur plusieurs lignes et les préparations réparties entre sites. Le colis peut être parti correctement alors que le raccordement entre ligne ERP et traitement Shopify a perdu une information.
Vous allez distinguer quantité commandée, quantité expédiée et quantité confirmée par dépôt, puis examiner huit situations corrigées. Le risque vient de la perte d’identité : la méthode conserve chaque ligne et son affectation logistique. Un total exact ne suffit pas : cinq unités annoncées depuis le mauvais dépôt ne décrivent pas les deux expéditions attendues.
Notre accompagnement en intégration API aide à diagnostiquer ce parcours avec votre équipe Shopify et votre installateur ERP. Nous qualifions ce que le connecteur existant peut prendre en charge, puis les compléments nécessaires sans donner à deux composants le droit de confirmer la même expédition.
Pour qui diagnostiquer une commande partielle dans Shopify ?
Commencez par une commande dont les colis et les quantités sont connus. Le diagnostic compare les pièces d’expédition de Business Central à la représentation logistique actuelle dans Shopify. Il cherche une perte de correspondance, un export non confirmé ou une différence de périmètre avant de conclure à une panne générale.
Reconstruire une ligne plutôt que le statut global
Une commande de cinq unités peut produire une sortie de deux unités aujourd’hui et une sortie de trois demain. Conservez les deux pièces, leurs lignes, leurs dépôts et leurs quantités. Le statut affiché en haut de la commande résume ce parcours ; il ne donne pas, à lui seul, la raison d’un reliquat.
Demandez au support ce qu’il voit réellement : un colis non remonté, un second suivi absent, une ligne recréée dans l’ERP ou une quantité rattachée au mauvais site. Chaque symptôme conduit à un contrôle différent. Repartir du numéro de commande sans ses lignes rend ces situations artificiellement semblables.
Délimiter ce qui dépend du transporteur et du connecteur
La confirmation dans Shopify et le scan du transporteur répondent à deux questions. La première représente une opération déclarée par votre système ; le second documente le parcours physique du colis. Une confirmation manquante n’autorise pas une réexpédition, et un numéro de suivi présent ne prouve pas que toutes les quantités ont été correctement affectées.
Le pilote utile porte sur un seul parcours connu : un magasin et un entrepôt, une boutique, une société ERP et quelques lignes. Différez l’automatisation si l’équipe ne peut pas retrouver les bons de livraison ou distinguer les quantités préparées des quantités sorties. Un middleware ne peut pas inventer cette preuve terrain.
Quelles limites du connecteur natif faut-il éprouver ?
Le connecteur Shopify de Microsoft couvre notamment commandes, stocks et informations de traitement. Cette couverture justifie de commencer par le composant disponible et sa configuration. Elle ne garantit pas que toutes vos manières de fractionner les préparations conservent les informations nécessaires.
Lire les restrictions sur les lignes et les dépôts
Dans sa documentation de synchronisation des expéditions, Microsoft décrit une ligne répartie entre deux sites, puis ramenée à une ligne ERP avec un seul dépôt. Le traitement de l’ensemble peut échouer ; l’envoi en deux étapes ne résout pas nécessairement toute la commande. Les produits identiques sur plusieurs lignes constituent aussi une restriction documentée.
Ces observations, vérifiées le 11 octobre 2026, donnent des cas à reproduire dans votre version. Elles ne permettent pas de conclure qu’une extension installée chez vous se comporte exactement comme le standard. Notez la version de Business Central, celle du connecteur, les extensions et le résultat constaté sur chaque ligne du pilote.
Vérifier les références conservées sur les pièces validées
Microsoft explique également qu’une référence Shopify de ligne absente sur une expédition validée empêche son inclusion dans la synchronisation. Une recréation manuelle de ligne peut provoquer ce défaut. Le contrôle porte donc sur la filiation entre la commande importée et le document effectivement expédié, au-delà de la présence du SKU.
En pratique, rassemblez une capture des correspondances et des pièces avant de modifier le paramétrage. L’installateur ERP vérifie comment les lignes sont copiées, remplacées ou ventilées ; l’équipe commerce compare les affectations visibles. L’incident demande une correction ciblée, pas une recréation du client ou de l’ensemble de ses commandes.
Quels identifiants relient commande, expédition et traitement Shopify ?
Le SKU identifie un produit dans votre catalogue. La ligne de commande identifie une occurrence de ce produit dans une vente. L’affectation logistique précise ce qui doit être traité depuis un site. Ces trois niveaux restent distincts même lorsque l’interface affiche le même libellé partout.
Garder les lignes commerciales et logistiques distinctes
Deux lignes peuvent porter le même produit avec des quantités, conditions ou origines différentes. Retrouver P100 ne dit pas si l’expédition vise L1 ou L2. Un connecteur qui prend la première correspondance par SKU peut consommer la mauvaise ligne tout en affichant un produit correct.
Pour chaque ligne ERP, le dossier doit permettre de retrouver la ligne commerciale source et l’affectation logistique visée. Si une transformation a regroupé plusieurs entrées, sa règle garde leur détail. Une correspondance ambiguë reste visible dans la revue ; la présence de quantité disponible sur une autre ligne ne suffit pas à la résoudre.
Utiliser un contrat Shopify daté pour les compléments API
La référence fulfillmentCreate de Shopify, affichée en version 2026-10 lors du contrôle, décrit une création pour des affectations d’une même commande et d’un même emplacement. Elle précise aussi les droits requis et les erreurs métier retournées. Une réponse reçue doit être interprétée avant d’enregistrer la confirmation locale.
Le contrat de ligne de traitement utilise un identifiant de ligne logistique et une quantité. Dans un complément destiné aux envois partiels, fournissez explicitement ce périmètre : l’omission des lignes dans la création peut traiter l’ensemble de l’affectation. La recette vérifie les droits et la version réellement retenus par votre application.
Comment préserver une répartition entre magasin et entrepôt ?
La répartition appartient à la promesse logistique. Deux unités prévues à EAST et trois à WEST ne deviennent pas cinq unités prévues à WEST parce que la ligne ERP ne conserve qu’un code. Votre contrat doit dire où la répartition est décidée et comment elle est maintenue jusqu’à la confirmation.
Comparer la quantité avec la capacité de l’affectation visée
Dans notre exemple fictif, l’affectation FE autorise deux unités à EAST et FW trois unités à WEST. Le seuil d’admission est la quantité restante sur l’affectation visée. Une demande de cinq sur FW dépasse sa capacité de deux, même si la commande entière contient bien cinq unités. L’admission proposée refuse cette demande avant toute confirmation.
Ce refus ne démontre pas une erreur de stock physique. Il indique que la demande ne représente pas le plan logistique connu. Le responsable du routage décide si ce plan doit changer ; le middleware relit ensuite la nouvelle répartition et ses références. Une modification de quantité seule ne remplace pas cette décision.
Revoir les regroupements de dépôts avant de les généraliser
Une boutique peut présenter un emplacement commun alors que plusieurs sites ERP participent à sa préparation. Cette représentation peut convenir si l’équipe conserve ailleurs la provenance des pièces et un responsable du traitement. Elle devient difficile à exploiter quand un reliquat ou un retour demande de retrouver le site réel.
Documentez le regroupement avec un cas de réception incomplet, un changement de site et un colis annulé. Le contrat précise si ces opérations réclament une nouvelle affectation ou une correction manuelle. Ne laissez pas une table de mapping résoudre simultanément la vente, la disponibilité et l’expédition sans montrer quelle décision elle porte.
Exercice corrigé : huit contrôles d’expédition par ligne
Le modèle local utilise la société C1, la boutique SHOP1, la commande O1 et le produit P100, avec une valeur commerciale fictive de 40 € par pièce. Les références FE, FW et FD sont fictives. Il éprouve des décisions proposées pour un adaptateur ; il n’exécute ni le connecteur Microsoft ni une mutation Shopify et ne reproduit pas tous leurs champs.
Prédire le résultat avant de lire le tableau
A envoie deux puis trois unités depuis une affectation unique de cinq. B conserve deux unités à EAST et trois à WEST. C tente de déclarer les cinq depuis WEST. D présente deux lignes du même produit et recherche la seconde. E perd la ligne d’origine ou soumet une pièce non validée.
F utilise une affectation fermée, une ancienne révision ou une autre société. G reprend une expédition connue, puis change sa quantité sous la même référence. H simule un accusé perdu et attend une preuve exacte. Pour chaque situation, prévoyez la quantité confirmée et l’information qu’un opérateur doit encore qualifier.
| Cas | Expédition examinée | Décision locale | Action d’exploitation |
|---|---|---|---|
| A | Deux unités puis trois, affectation unique de cinq | Deux confirmées, trois restantes ; cinq à la fin | Conserver les deux pièces du parcours |
| B | Deux à EAST et trois à WEST, références distinctes | Cinq confirmées avec leur répartition | Éprouver séparément le connecteur installé |
| C | Cinq annoncées sur WEST, capacité de trois | Quantité refusée ; zéro confirmée | Retrouver ou revoir l’affectation EAST |
| D | Deux lignes portent P100 ; l’envoi vise L2 | Correspondance L2–FE refusée ; L2–FD admise | Conserver les références de ligne |
| E | Ligne source absente ou pièce non validée | Envoi suspendu ; zéro confirmée | Qualifier filiation et validation ERP |
| F | Affectation fermée, révision ancienne ou société C2 | Trois motifs de refus ; zéro confirmée | Relire le contexte actuel avant admission |
| G | Envoi de deux repris, puis modifié en trois | Un seul effet de deux ; mutation refusée | Ouvrir une décision distincte pour la correction |
| H | Accusé perdu après demande de deux unités | Zéro admise avant preuve ; deux après lecture exacte | Réconcilier avant toute nouvelle écriture |
Lire les témoins positifs et les refus ensemble
Dans le scénario A, les deux unités confirmées représentent 80 € de produits sur une commande de 200 €, et le reliquat de trois représente 120 €. Cette valeur commerciale fictive aide le support à qualifier la portion encore attendue ; elle ne déclenche aucune facture ni aucun remboursement. Le contrôle conserve les deux pièces pour expliquer le reliquat. B vérifie la représentation proposée des deux dépôts ; il ne prouve pas que le connecteur natif réussit ce cas. D possède un témoin positif avec FD, après le refus de la mauvaise référence FE.
Les huit groupes ont été exécutés hors connexion. Le modèle vérifie quantités, références, contexte et reprise locale, sans colis envoyé, courrier client ni écriture ERP. Il ne certifie pas la concurrence entre travailleurs ni une transaction distribuée. H reçoit une preuve fictive fournie au test ; la lecture réelle nécessaire devra être construite et éprouvée dans votre intégration.
Comment reprendre un export sans confirmer deux fois le même envoi ?
La reprise doit distinguer un refus connu d’une réponse perdue. Dans le premier cas, vous avez une décision à expliquer. Dans le second, l’effet distant peut avoir eu lieu alors que votre journal ne l’a pas confirmé. Réutiliser le bouton de synchronisation comme seul diagnostic masque cette différence.
Retrouver l’effet avant d’en demander un nouveau
Le contrat du handler définit son entrée : une demande dans une queue du middleware avec pièce, ligne et affectation. Il garde le payload normalisé et la révision examinée, puis sépare le journal des demandes du journal des confirmations. G conserve une référence d’expédition et son contenu admis. Une reprise identique retrouve les deux unités déjà confirmées ; une nouvelle quantité sous cette référence ouvre une revue. La règle locale protège la décision connue, sans prétendre que le fournisseur utilise automatiquement la même clé d’idempotence.
Un timeout classe la demande comme incertaine avant tout retry. Le backoff peut espacer les lectures de rapprochement ; il ne transforme pas une absence de réponse en autorisation d’écriture. H garde la demande incertaine séparément. Une preuve absente ou contradictoire ne devient pas une preuve d’absence d’effet. Le runbook indique comment retrouver le traitement distant, ses lignes et quantités, puis quand une nouvelle tentative peut être autorisée. Le support n’a pas à choisir entre abandon et répétition aveugle.
Contrôler le reliquat au même niveau que la confirmation
Dans le scénario de contre-test, deux unités sont proposées sur FE, puis quatre sur FW. Le total demandé atteint six pour une commande de cinq ; FW ne dispose que de trois. À la valeur fictive de 40 € par pièce, l’annonce représenterait 240 € de produits au lieu de 200 €, soit 40 € supplémentaires. Le second envoi est refusé et les deux unités déjà admises restent intactes : le support retrouve la quantité excessive sans annuler l’effet connu.
Un contrôle global effectué seulement après les deux écritures arriverait trop tard pour prévenir l’annonce incorrecte. Dans une application réelle, la lecture du disponible et l’admission doivent être protégées contre les demandes concurrentes. La recette locale n’éprouve pas ce verrou : ajoutez un scénario de deux travailleurs visant la même affectation avant l’ouverture des volumes.
Quelles informations montrer au client et au service après-vente ?
La commande peut conserver plusieurs suivis et des quantités encore attendues. Le message client doit s’appuyer sur les confirmations admises, tout en gardant les incidents d’intégration accessibles au support. Un retard de synchronisation ne doit pas faire disparaître le premier colis de la lecture du dossier.
Associer chaque suivi aux lignes réellement parties
Le suivi du magasin décrit ses deux unités ; celui de l’entrepôt ses trois unités. Si votre interface rassemble les colis, elle garde cette ventilation consultable. Le support retrouve la pièce ERP, le transporteur et la quantité depuis le même dossier, sans attribuer un suivi à toutes les lignes par commodité.
Décidez également quel composant déclenche la notification. Lorsque le standard et une application complémentaire peuvent prévenir le client, leur frontière doit être explicite. La recette observe le nombre de messages et leur contenu ; les tests hors connexion de cet exercice n’envoient aucune notification et ne certifient pas cette partie.
Distinguer une confirmation tardive d’une demande de retour
Une réclamation peut arriver alors que la seconde confirmation n’est pas encore rapprochée. Le SAV vérifie d’abord ce qui est sorti et ce qui a été remis au client. Le statut partiel affiché ne doit pas servir seul à décider d’un remboursement, d’un renvoi ou d’une remise en stock.
Les flux de retour ont leurs propres pièces et décisions. Ils utilisent l’historique de l’expédition sans le réécrire pour rendre les statuts plus simples. Un produit réexpédié à titre commercial conserve son nouveau parcours ; il ne se présente pas comme une répétition technique du premier export.
Connecteur natif, Celigo ou complément sur mesure : comment choisir ?
Le choix part de vos exceptions mesurées. Si le composant installé représente correctement les lignes du pilote, son paramétrage et son exploitation peuvent suffire. Si une transformation efface la répartition ou les références, le besoin porte sur cette frontière précise et sa maintenabilité.
Comparer les solutions sur le même dossier d’expédition
La présentation du template Celigo Business Central–Shopify annonce un flux d’expéditions validées vers Shopify, incluant le partiel, ainsi qu’un mapping des emplacements. Elle précise un périmètre cloud. Ces capacités constituent une autre piste à examiner ; elles ne prouvent pas la résolution de votre cas multi-dépôts.
Présentez A à H au prestataire du composant évalué. Demandez la démonstration de B et D, puis la reprise de H avec les traces utiles. Une annonce « commandes et stocks synchronisés » ne décrit pas l’admission d’une ligne ambiguë. Le comparatif doit garder les exclusions et les responsabilités de support de chaque solution.
Limiter le sur mesure à une responsabilité définie
Un complément peut conserver une ventilation perdue, reconstruire les correspondances ou organiser les demandes incertaines. Sa valeur tient à une information et une décision que le parcours actuel ne représente pas correctement. Refaire tout le connecteur ajoute des responsabilités de catalogue, clients et finance qui ne découlent pas de ce seul incident.
Définissez qui importe la commande, qui qualifie la préparation et qui confirme le traitement. Un seul composant possède l’écriture finale pour un périmètre donné. Votre projet d’intégration Business Central doit préciser cette répartition avec l’installateur ERP et le propriétaire de la boutique avant le développement.
Plan d’action : qualifier cinq unités sur deux sites avant la généralisation
Le premier livrable est un dossier que l’ADV et la logistique peuvent relire : commande source, lignes, affectations, pièces validées, quantités confirmées et demandes encore incertaines. Il permet de décider ce qui manque dans le standard et ce qui relève d’une pratique de préparation à corriger.
Préparer la recette avec les propriétaires du parcours
L’équipe Shopify rassemble les lignes et leurs affectations. L’installateur Business Central vérifie la filiation des pièces et les extensions. Le responsable logistique confirme les dépôts et les sorties ; l’intégrateur décrit les lectures, admissions et reprises. Chaque preuve appartient au système ou au métier qui peut l’établir.
Le contrat de mapping précise ses entrées : société, environnement, boutique, commande, ligne, affectation, emplacement et pièce d’expédition. Il produit en sortie une admission motivée ou une demande de revue. Le monitoring suit les quantités admises, les correspondances manquantes et l’âge des demandes incertaines. Fixez un responsable et une prochaine action pour chaque motif, afin qu’une erreur ne reste pas indéfiniment dans une file anonyme.
- Reproduire une expédition unique puis son reliquat.
- Rejouer une ligne répartie entre les deux sites réellement utilisés.
- Tester deux occurrences du même SKU avec leurs références distinctes.
- Retirer une référence, fermer une affectation et changer une révision.
- Perdre l’accusé, puis rapprocher une preuve exacte et une preuve contradictoire.
Mesurer le coût actuel et définir les critères d’arrêt
Un échantillon hypothétique de vingt et un dossiers à seize minutes représente 336 minutes, soit cinq heures et trente-six minutes de recherche. Le calcul exécuté sert à préparer une mesure support, pas à annoncer une économie client. Comparez vos temps de recherche avant et après, ainsi que le nombre de dossiers réellement expliqués.
Le seuil d’arrêt du pilote proposé est explicite : une confirmation sur la mauvaise ligne ou le mauvais site suspend le périmètre concerné. Une demande incertaine reste hors nouvelle écriture jusqu’à réconciliation. L’ouverture dépend de ces décisions et de la lecture des pièces, pas du seul nombre d’appels réussis. L’exploitation livre un runbook, les versions retenues et les scénarios nécessaires après toute mise à jour.
Erreurs fréquentes : quelles corrections aggravent une commande partielle ?
Les raccourcis les plus tentants rendent souvent l’écran plus simple avant de rendre le dossier plus exact. Examinez leur effet sur les lignes, les pièces et les notifications. Une correction utile doit laisser une preuve consultable de ce qui a changé et de ce qui reste à faire.
Refuser les totaux qui masquent la provenance
Ramener toutes les quantités au dépôt de la ligne ERP peut faire disparaître la distinction EAST–WEST. Grouper les occurrences d’un SKU peut supprimer L2. Copier le premier suivi sur toute la commande peut faire croire que le second colis suit le même trajet. Ces changements dégradent trois preuves différentes.
Dans C, cinq est le bon total commercial et la mauvaise quantité pour FW. Paradoxalement, la somme correcte peut accompagner une annonce fausse. Le contrôle de répartition explique le refus et indique quelle affectation manque, au lieu de remplacer l’écart par un statut global rassurant.
Ne pas utiliser le rejeu comme un outil de découverte
Réexporter toutes les pièces pour découvrir celle qui manque expose les confirmations déjà réussies. Une modification silencieuse de la demande sous une référence connue empêche aussi de comprendre G. Le runbook retrouve d’abord la pièce, son contenu et sa dernière décision, puis autorise une correction explicite.
Si un opérateur a confirmé un traitement manuellement, le rapprochement l’intègre avant la tentative automatique suivante. Le parcours protège ainsi le travail déjà réalisé. Les quantités et les preuves gouvernent la reprise ; le simple fait qu’un indicateur local affiche une erreur ne donne pas le droit de répéter l’effet distant.
Lectures complémentaires : prolonger le diagnostic vers le reste du SI
Le fractionnement d’une expédition se situe entre import de commande, préparation logistique et information du client. Les guides suivants approfondissent ces frontières avec d’autres logiciels et parcours. Ils aident à conserver une responsabilité claire lorsque le besoin dépasse Business Central et Shopify.
Qualifier le logiciel logistique et ses pièces ERP
Le dossier Shippingbo relié à un ERP sans connecteur disponible explique comment choisir le premier parcours et ses interfaces vérifiables. Il devient utile si le traitement passe aussi par un OMS ou un WMS, plutôt que directement par la préparation ERP.
L’étude Shippingbo et SAP Business One, de la commande à la livraison traite la relation entre préparation et document ERP. Les objets propres à SAP ne s’appliquent pas automatiquement à Business Central ; la méthode aide à qualifier les preuves attendues de chaque côté.
Distinguer la réception et la maintenance d’un connecteur
Les réceptions fournisseurs partielles entre Odoo et un 3PL montrent pourquoi une quantité reçue ne se confond pas avec un statut d’approvisionnement. Ce parcours amont fournit une autre manière de relire les reliquats sans fusionner les documents.
Pour l’éditeur d’une solution logistique, la connexion d’un SaaS aux ERP de ses clients précise le socle partagé, les installations et le support. Elle aide à financer la maintenance d’une adaptation dont les règles doivent rester vérifiables chez plusieurs clients.
Conclusion : confirmer chaque expédition avec sa ligne et son dépôt
Une commande partielle demande d’expliquer des pièces et des quantités. Le premier contrôle relie l’expédition validée à sa ligne source, puis à l’affectation logistique actuelle. Il conserve la différence entre ce qui est sorti, ce qui a été confirmé et ce qui reste incertain.
Les huit situations éprouvent une méthode locale de décision. Elles rendent visible la différence entre cinq unités commerciales et trois unités autorisées à WEST, entre deux occurrences d’un produit et entre refus connu et accusé perdu. La recette de votre connecteur reste nécessaire pour établir son comportement réel.
Commencez par le standard et les pratiques de préparation observées. Un middleware ou une adaptation devient pertinent lorsqu’un manque précis est établi et qu’un responsable peut en assurer l’exploitation. La solution retenue doit retrouver les preuves du parcours après une interruption ou une évolution de logiciel.
Dawap vous accompagne dans l’intégration de vos flux e-commerce et ERP, avec votre installateur Business Central : cadrage des interfaces, mapping par ligne, reprise et recette des expéditions. Une commande, deux sites et des pièces vérifiables permettent de préparer ce service avant son ouverture à l’ensemble de vos ventes.
