Relier Shippingbo à un ERP sans connecteur

Votre équipe prépare les commandes dans Shippingbo, mais ressaisit encore leurs résultats dans l’ERP. Le retard de remontée bloque la confirmation des livraisons dans l’ERP et oblige le support à comparer les deux logiciels. Les commerciaux ne savent plus quel stock annoncer tandis que la comptabilité attend les objets nécessaires à ses écritures. Le logiciel apparaît dans un catalogue d’intégrations, sans que personne puisse confirmer la couverture de votre version, de vos commandes B2B et de vos retours.

Le raccordement doit couvrir les opérations de votre entreprise dans les deux sens, avec un responsable pour chaque donnée. La présence d’un connecteur ne prouve pas qu’il gère vos objets ERP ; son absence ne signifie pas qu’il faut remplacer le logiciel. Le choix se fait entre une solution existante qualifiée, son adaptation et un middleware dont les responsabilités sont précisément délimitées.

Vous allez pouvoir vérifier ce que le raccordement doit prendre en charge, comparer ces options et préparer une recette métier. Le scénario corrigé suit une commande professionnelle, une expédition partielle et un retour, sans confondre stock physique et quantité vendable. Les règles de démonstration sont explicitement fictives ; elles servent à poser les questions à valider dans votre environnement.

Dawap réalise des missions d’intégration API entre logiciels et systèmes d’entreprise, avec un accompagnement d’intégrateur Shippingbo pour les flux logistiques concernés. Nous qualifions les interfaces et les objets de l’ERP avec votre installateur, puis organisons les correspondances, les reprises et les contrôles nécessaires à l’exploitation.

Un ERP cité par Shippingbo dispose-t-il forcément d’un connecteur prêt à l’emploi ?

Commencez par distinguer présence commerciale, compatibilité technique et couverture métier. Un éditeur peut présenter une intégration réalisée par ses partenaires, un module disponible dans certaines configurations ou une possibilité de développement via API. Ces situations ne conduisent pas au même devis, au même calendrier ni au même partage de maintenance.

Qualifier la nature exacte de l’intégration proposée

La présentation officielle des API Shippingbo indique que les entreprises peuvent utiliser des connecteurs développés par l’éditeur ou réaliser leur propre connexion lorsqu’un connecteur n’est pas disponible. Cette possibilité ne garantit pas l’accès à toutes les opérations de votre ERP, ni l’activation de toutes les capacités sur votre compte logistique.

La page officielle consacrée à Odoo décrit notamment une intervention d’intégrateur et un développement adapté au projet. Elle distingue commandes B2B, commandes B2C, catalogue, stocks et retours, avec des comportements dépendant de la configuration. Un nom de logiciel dans la liste ne doit donc pas devenir une promesse de branchement universel.

Demander les preuves avant d’accepter le périmètre du devis

• Le logiciel ERP, son édition, sa version et les modules utilisés correspondent-ils au périmètre effectivement pris en charge ?
• Quels objets sont lus ou écrits, dans quel sens et à quel moment du traitement de la commande ?
• Qui fournit la connexion, qui la maintient et qui intervient lorsque l’un des éditeurs modifie son interface ?
• Quels cas sont déjà démontrés : annulation, livraison partielle, changement d’entrepôt, retour et rejet métier ?

Un contrat précis permet de comparer deux propositions qui portent toutes deux le nom de « connecteur ». Une solution peut seulement envoyer les commandes à préparer, tandis qu’une autre retrouve les expéditions et produit les livraisons ERP attendues. Comparer leurs seuls prix confond des prestations dont les résultats sont différents.

D’où viennent les commandes : ERP, boutique ou marketplaces ?

Une entreprise peut saisir ses commandes professionnelles dans l’ERP et recevoir les ventes en ligne directement dans Shippingbo. Les deux parcours convergent dans l’entrepôt, mais leurs correspondances restent différentes. Le raccordement doit connaître l’origine de la commande avant de décider s’il crée un objet ou complète un objet déjà présent.

Conserver le sens de circulation pour chaque canal

Pour une commande B2B saisie dans l’ERP, le premier passage peut transmettre à Shippingbo les informations nécessaires à la préparation. Les expéditions reviennent ensuite vers l’ERP pour alimenter les objets convenus. Pour une commande issue d’une marketplace, Shippingbo peut déjà posséder la commande logistique avant que le middleware n’en crée ou complète la représentation commerciale dans l’ERP.

Le contrat précise ces parcours au lieu de lancer une synchronisation bidirectionnelle identique sur toutes les commandes. Une commande importée dans l’ERP depuis Shippingbo ne doit pas repartir immédiatement vers Shippingbo comme une nouvelle demande. L’identifiant d’origine, le canal et la relation entre objets doivent permettre de reconnaître le parcours déjà engagé.

Repérer un doublon avant qu’il devienne une seconde préparation

Un premier signal faible apparaît quand un numéro commercial correspond à plusieurs préparations sans fractionnement prévu. Cherchez une double origine, une référence externe perdue ou une reprise qui a changé de clé. Le rapprochement doit porter sur les commandes et leurs lignes ; un numéro de suivi identique ou un nom client ne constitue pas une protection suffisante.

La journalisation relie référence ERP, identité Shippingbo, canal d’origine et intention de traitement. La responsabilité de reprise porte sur cette intention, avec un contrat d’idempotence qualifié sur la cible. Lorsque l’écriture est incertaine, le middleware recherche son résultat selon les moyens autorisés avant de proposer une nouvelle création.

Quels flux inclure dans le premier raccordement ERP et Shippingbo ?

La liste des objets doit préciser le résultat utilisable par le métier. Recevoir une information d’expédition n’est pas nécessairement créer une livraison validée dans l’ERP. Lire un stock physique n’est pas publier une quantité vendable. Chaque ligne du périmètre associe source, destination et confirmation attendue.

• Catalogue logistique : transmettre les références, unités et caractéristiques nécessaires à la préparation, depuis la source produit qualifiée.
• Commandes B2B : envoyer les commandes dont les conditions autorisent effectivement la préparation, avec leurs références et contraintes de livraison.
• Commandes en ligne : retrouver dans l’ERP les ventes reçues par la chaîne logistique, sans les renvoyer comme de nouvelles préparations.
• Disponibilité : fournir le niveau ou les variations convenus, avec entrepôt, date de constat et définition de la quantité transmise.
• Expéditions : rapprocher les unités réellement parties avec les livraisons ou statuts attendus côté ERP.
• Réceptions : comparer les quantités attendues et reçues lorsque le réapprovisionnement appartient au premier lot.
• Retours : transmettre les événements nécessaires à la réception, à l’inspection et aux traitements ERP autorisés.

Écrire le maître de la donnée et les exceptions possibles

La source du catalogue peut rester l’ERP tandis que la logistique porte les constats de préparation et d’expédition. Ce partage dépend de votre architecture. Si un PIM ou un WMS tiers intervient, sa responsabilité doit apparaître explicitement ; le middleware ne choisit pas le dernier message reçu comme vérité par défaut.

Les intégrations WMS, OMS et stock demandent notamment de distinguer donnée observée, calcul de disponibilité et publication aux canaux. Un même logiciel peut porter plusieurs de ces étapes, mais elles doivent rester identifiables pour comprendre un écart. La matrice doit nommer les corrections autorisées et les équipes habilitées à les réaliser.

Accepter les décalages prévus et détecter ceux qui bloquent une opération

Un traitement par lot peut suffire pour une donnée qui n’engage pas immédiatement un achat. Une quantité vendable sur un produit très demandé peut imposer une autre cadence. Le besoin se définit par le délai acceptable entre l’événement métier et la confirmation dans la cible, en tenant compte des horaires et des capacités des interfaces.

Le délai de traitement doit être mesuré séparément du délai de transport. Si la collecte réussit mais que les confirmations ERP s’accumulent, la liaison réseau n’est pas forcément le problème. L’observabilité du flux doit montrer la dépendance bloquante et l’ancienneté des objets concernés, plutôt qu’un simple pourcentage d’appels techniques réussis.

Comment éviter que l’ERP et Shippingbo réservent deux fois le même stock ?

Une réservation représente une demande identifiée, pas seulement une quantité à soustraire. Lorsque l’ERP et la logistique connaissent la même commande, ils peuvent décrire la même réserve. Additionner leurs valeurs sans identifier cette relation réduit artificiellement la disponibilité ; ignorer toutes les réservations produit le risque inverse.

Faire correspondre les définitions avant de choisir un champ à synchroniser

Demandez ce que chaque donnée contient : unités présentes, unités réservées, quantités bloquées, stock en transit ou disponible à la vente. Qualifiez aussi l’entrepôt et l’unité de mesure. Un carton, une pièce et un lot ne se comparent pas sans conversion validée ; une quantité issue d’un autre dépôt ne peut pas tenir une promesse locale automatiquement.

Le raccordement précise si la cible reçoit une quantité déjà nette ou les composants nécessaires à son calcul. Dans le premier cas, elle ne retire pas à nouveau les réservations déjà incluses. Dans le second, elle applique une règle qualifiée avec ses sources. Ces deux contrats sont possibles, mais leur mélange crée des écarts difficiles à diagnostiquer.

Ne pas remettre en vente un retour avant son contrôle

Un retour reçu physiquement peut rester en quarantaine, incomplet ou impropre à la revente. Le flux distingue arrivée, inspection et décision de remise en disponibilité. Le choix de l’événement qui augmente la quantité vendable se valide avec l’équipe entrepôt ; un remboursement financier ne prouve pas l’état du produit retourné.

Un deuxième signal faible apparaît quand les écarts de stock sont concentrés sur les retours alors que les ventes nominales se rapprochent correctement. Vérifiez les événements utilisés, les états de quarantaine et les éventuelles corrections manuelles. Multiplier la fréquence de synchronisation ne répare pas une définition de disponibilité incorrecte.

Cas corrigé : une commande B2B, deux unités expédiées et un retour

Le scénario est entièrement fictif et ne reproduit aucun calcul natif Shippingbo. Une référence compte initialement quatorze unités physiques, quatre réservées pour d’autres demandes et deux bloquées. La disponibilité de démonstration est calculée par soustraction : physique moins réservé moins bloqué, soit huit unités. Les unités réservées et bloquées ne se recouvrent pas dans l’exercice.

La commande ERP B2B-74 demande trois unités, toutes acceptées en réservation par la logistique. Deux sont ensuite expédiées ; une reste réservée. L’une des unités expédiées revient en quarantaine avant d’être déclarée revendable. Aucun autre mouvement n’intervient pendant cette simulation, et les valeurs ne sont pas des champs API garantis par l’éditeur.

Retrouver ce qui doit changer dans l’ERP à chaque étape

Après acceptation, la réservation de trois unités est déjà comprise dans la disponibilité de cinq. Si l’ERP reçoit cette quantité nette et retranche encore B2B-74, il affiche deux unités à tort. Le message reçu une seconde fois retrouve la même commande et sa même réservation ; il ne consomme pas trois unités supplémentaires.

L’expédition porte deux unités, avec un reliquat d’une unité. Le flux ERP doit produire le résultat convenu pour ces quantités réellement expédiées, sans annoncer trois unités livrées. Les opérations documentaires ou financières restent régies par les objets et validations de l’ERP ; le tableau de stock ne les déclenche pas à lui seul.

Comprendre pourquoi le retour physique ne change pas encore la disponibilité

La réception du retour augmente le physique de douze à treize et le bloqué de deux à trois. La disponibilité reste donc cinq. Elle passe à six seulement après la décision de revente. Ce résultat montre pourquoi un événement de réception et une décision de qualité ne doivent pas être fusionnés dans le raccordement.

La recette doit vérifier ces six étapes et leurs identités, puis répéter la demande initiale après l’expédition. La protection contre les doublons conserve l’état déjà atteint ; elle ne remet pas la commande au début de son parcours. Le seuil attendu sur ce scénario déterministe est zéro seconde commande et zéro réserve supplémentaire causée par une répétition.

Expédition partielle, annulation et avoir : quels objets l’ERP attend-il ?

L’ERP peut posséder une commande, un bon de livraison, une facture et un avoir, tandis que la logistique représente préparation, colis et expédition. La correspondance doit être validée objet par objet. Un statut général « terminé » n’est pas assez précis pour produire tous les documents attendus sans erreurs.

Qualifier une annulation selon l’opération déjà réalisée

Une demande d’annulation avant préparation ne se traite pas comme une demande reçue après expédition. Le connecteur vérifie l’état effectivement connu et les actions encore permises par les contrats. Il conserve le résultat de l’annulation et les éventuelles unités restantes ; un message arrivé tard ne supprime pas silencieusement les preuves d’une opération déjà exécutée.

Dans le scénario, la dernière unité peut suivre un traitement différent des deux unités expédiées. Si elle est annulée selon les règles validées, sa réserve doit être libérée une seule fois. Le retour d’une unité déjà expédiée suit encore un autre parcours, avec réception et contrôle physique indépendants de cette annulation.

Coordonner le flux avec l’installateur ERP

Votre installateur confirme les types de documents, les permissions et les contraintes de validation de l’ERP. L’intégrateur qualifie les données Shippingbo accessibles, leurs correspondances et leur traitement. La finance valide ce qui doit produire une écriture ou rester en contrôle ; cette répartition évite qu’un développement logistique réinterprète seul les règles comptables.

Dawap intervient sur les échanges et les applications nécessaires autour de ce système. Une adaptation de l’ERP peut être une dépendance du projet, à chiffrer et à réaliser avec le partenaire compétent. Le périmètre doit identifier cette dépendance plutôt que promettre qu’un middleware pourra créer des objets pour lesquels aucune interface autorisée n’existe.

Décision : connecteur existant, adaptation ou middleware sur mesure ?

• Retenir un connecteur existant lorsque version ERP, flux et cas d’exception sont démontrés, avec une maintenance identifiable et des moyens de reprise accessibles.
• Adapter une connexion existante lorsque la couverture est suffisante mais qu’un champ, une convention d’entrepôt ou un objet précis manque. L’extension doit rester compatible avec les mises à jour du socle.
• Développer un middleware sur mesure lorsque plusieurs systèmes participent au traitement ou que les correspondances et validations dépassent le périmètre de l’outil standard.
• Différer une automatisation lorsque les données, interfaces ou responsabilités nécessaires ne peuvent pas encore être qualifiées. Un contrôle manuel borné vaut mieux qu’une écriture répétée sans résultat vérifiable.

Le développement de middleware sur mesure devient pertinent lorsqu’il apporte une mémoire des traitements, une supervision métier et des reprises que les autres systèmes ne portent pas ensemble. Il ne doit pas remplacer les fonctions de préparation du WMS ou devenir un second ERP avec ses propres règles commerciales contradictoires.

Comparer les coûts de connexion et d’exploitation

Le coût complet comprend qualification, accès ERP, correspondances, développements, tests, hébergement, surveillance et maintenance lors des évolutions des logiciels. Les heures de diagnostic et les corrections manuelles restent visibles dans la comparaison. Un abonnement moins cher peut devenir plus coûteux si chaque rejet nécessite une intervention impossible à cibler.

Paradoxalement, un premier lot plus réduit peut réduire le coût du projet même si le raccordement complet demeure prévu. Il permet de prouver les identités et les confirmations sur une commande avant d’ajouter réceptions, retours et autres canaux. Cette progression évite de financer plusieurs flux bâtis sur une correspondance ERP qui reste à corriger.

Projets liés : le middleware Shippingbo, Odoo et Wix de 1UP Distribution

Une continuité entre canal de vente, logistique et objets ERP

Le cas 1UP Distribution, de Wix à Shippingbo puis Odoo présente une réalisation Dawap qui conserve les correspondances entre ces systèmes. Le middleware prépare les commandes du canal, récupère les objets logistiques et alimente l’ERP selon des passages distincts. Cette réalisation montre une organisation du flux, sans garantir une compatibilité universelle avec toutes les versions ERP.

Le projet décrit aussi des traitements asynchrones séparés, la recherche des ressources et des reprises ciblées. Ces moyens permettent de situer le passage concerné lorsqu’une opération échoue. Ils illustrent le rôle d’un middleware exploitable après livraison ; les quantités et incidents du scénario précédent restent fictifs et ne sont pas attribués à ce client.

Plan d’action : préparer une recette qui traverse toute la chaîne

Réunissez les responsables entrepôt, commerce, finance et ERP autour des opérations réellement attendues. Les entrées de recette comprennent versions logicielles, comptes de test autorisés, produits qualifiés et références de commande. Les sorties attendues désignent les objets logistiques et ERP à retrouver, avec une responsabilité explicite pour chaque confirmation.

Prouver une commande avant d’ouvrir tous les flux

Commencez par un produit et une commande représentative, puis vérifiez les identifiants, quantités, entrepôts et unités de mesure. Conservez les réponses et la journalisation nécessaires au support, sans exposer des secrets ou des données client inutiles dans les tickets. Le contrat de recette fixe les délais acceptables et la procédure de repli lorsqu’une dépendance est indisponible.

• Une commande B2B rejoint la préparation prévue puis remonte les unités effectivement expédiées dans l’ERP.
• Une commande reçue par un canal en ligne n’est pas renvoyée comme une nouvelle demande logistique.
• Une répétition ou une confirmation perdue n’entraîne pas une deuxième commande ou une deuxième livraison.
• Un retour reste bloqué jusqu’à la décision physique prévue, indépendamment de son traitement financier.
• Une annulation tardive ou une référence inconnue présente un refus explicable et une correction ciblée.

Accès API, notifications et contrôles de rattrapage

Le dossier de connexion décrit l’authentification requise par chaque logiciel, les permissions et le renouvellement des accès. Un token de recette ne doit pas être réutilisé comme un accès permanent de production. Le responsable de chaque système confirme les opérations autorisées ; la supervision conserve les références et résultats utiles sans afficher les secrets dans les tickets.

Une notification webhook doit être rapprochée de l’état effectivement consultable dans la source. Un contrôle périodique par batch peut rechercher les objets qui n’ont pas reçu de confirmation, avec les filtres et la pagination prévus par l’interface. Ce rattrapage réutilise les identités déjà connues et ne transforme pas toutes les commandes consultées en nouvelles demandes de création.

Le mapping des références et entrepôts conserve une version applicable à chaque traitement. Une correction de correspondance permet de cibler les objets rejetés par cette règle ; elle ne réécrit pas toutes les livraisons historiques. La politique de retry distingue une indisponibilité temporaire d’un refus métier à corriger, avec une limite de tentatives et un responsable pour les dossiers qui restent bloqués.

Organiser l’ouverture et le retour arrière

Ouvrez le volume par périmètre contrôlé, avec les opérations et les seuils convenus. Le responsable d’exploitation doit pouvoir suspendre un flux nouveau sans abandonner les commandes déjà confirmées. La reprise conserve les intentions en attente et vérifie les effets obtenus avant de réactiver une écriture.

La documentation remise aux équipes explique la cause des rejets courants, les droits de correction et la preuve de clôture. Le suivi mesure notamment ancienneté des confirmations, doublons détectés et dossiers de retour incomplets. Une amélioration doit réduire un écart identifié ; le nombre de messages traités ne suffit pas à déclarer l’intégration réussie.

Erreurs fréquentes lorsque l’ERP et Shippingbo restent mal raccordés

• Assimiler présence au catalogue et module disponible : le périmètre promis ne correspond pas aux opérations réellement démontrées sur l’ERP installé.
• Envoyer toutes les commandes dans les deux sens : une vente déjà reçue par la logistique devient une nouvelle préparation après son import commercial.
• Soustraire deux fois la réservation : une quantité déjà nette est diminuée à nouveau dans la cible.
• Confondre retour, disponibilité et remboursement : des décisions physiques et financières différentes sont déclenchées par un seul événement.
• Rejouer toute la commande pour réparer une livraison : la correction produit des effets supplémentaires sur des étapes déjà confirmées.

Le diagnostic doit partir de l’objet et du résultat manquants : commande, réservation, livraison, disponibilité ou document ERP. Une alerte générale « synchronisation échouée » peut signaler le problème, mais elle ne fournit pas la décision. Le dossier de traitement conserve la dernière étape confirmée, la dépendance en défaut et les actions encore autorisées.

Lectures pour situer le raccordement dans votre architecture logistique

La connexion ERP doit s’inscrire dans les responsabilités de la logistique et dans les capacités des interfaces. Les deux lectures suivantes approfondissent l’architecture Shippingbo et la mémoire des traitements. Elles permettent de préparer le périmètre technique sans confondre son existence avec la validation de votre processus métier.

• L’organisation des expéditions multi-entrepôts avec Shippingbo traite préparation, colis et suivi des canaux. Ces décisions donnent le contexte logistique des événements que l’ERP devra interpréter selon ses propres objets.

• La traçabilité des traitements API pour le support précise les informations nécessaires pour retrouver une erreur et sa correction. Elle complète les références croisées sans imposer de conserver tous les contenus des messages dans chaque écran.

Si votre périmètre utilise aussi Shopify et Business Central, le diagnostic des expéditions partielles Business Central vers Shopify examine la perte d’une répartition entre deux dépôts et les références de ligne. Un pont logistique peut transmettre le bon total sans conserver l’affectation nécessaire à la confirmation du canal ; ce contrôle se joue avant de relancer l’export.

Vérifier quels entrepôts contribuent au compteur reçu

Une disponibilité globale peut couvrir davantage de sites que le détail physique transmis à l’ERP. Le contrôle du stock détaillé Shippingbo et des entrepôts manquants conserve la couverture de chaque compteur avant de calculer un écart. Il complète la qualification du raccordement lorsque les WMS connectés n’exposent pas tous les mêmes informations.

Listez les sites attendus indépendamment des lignes reçues. Un entrepôt absent du détail garde une demande de qualification ; sa quantité ne devient pas zéro. Une fois le périmètre établi, l’ERP peut comparer la donnée de même nature ou conserver une reprise assistée sur le site non couvert.

Conclusion : choisir une connexion qui produit les résultats attendus dans l’ERP

Le raccordement entre Shippingbo et votre ERP se choisit sur ses opérations démontrées. Une mention dans un catalogue, une connexion technique ou un flux nominal réussi ne prouvent pas la livraison complète du besoin. Le périmètre doit identifier commandes, disponibilités, expéditions, retours et documents à retrouver dans leurs systèmes respectifs.

Le scénario montre les distinctions qui changent le résultat : commande répétée, quantité déjà nette, expédition partielle et retour en quarantaine. Leur traitement repose sur les identités et les décisions conservées. Une reprise réussie confirme l’effet attendu sans répéter les opérations déjà réalisées.

La qualification avec votre installateur ERP permet de choisir entre outil existant, adaptation et middleware. Le premier lot doit traverser la chaîne avec des preuves lisibles pour l’entrepôt et la finance. L’extension vient ensuite, lorsque les responsables disposent des moyens de corriger et de surveiller les échanges.

Dawap peut qualifier ce périmètre, réaliser les correspondances et organiser la supervision avec vos équipes et partenaires logiciels. Notre accompagnement en intégration API pour relier votre ERP à la logistique associe les interfaces accessibles à une recette métier, puis aux outils de reprise nécessaires lorsque l’activité rencontre ses exceptions.