Une commande B2B existe dans SAP Business One, mais l’entrepôt la ressaisit dans Shippingbo. Quand six unités sur dix partent, l’administration des ventes reçoit un numéro de suivi sans savoir quelle ligne livrer dans l’ERP. Le lendemain, une relance du connecteur crée un second traitement. La reprise manuelle ne corrige plus seulement une donnée : elle expose l’entreprise à une double préparation ou à un document commercial erroné.
Le raccordement doit conserver la société SAP, la commande, ses lignes et les quantités effectivement expédiées. Une référence client ou un SKU seul ne suffit pas lorsque plusieurs documents, dépôts ou lignes portent le même libellé. L’intégration doit également distinguer une commande acceptée par Shippingbo d’une commande disposant du stock nécessaire à sa préparation.
En pratique, le flux doit suivre les documents et leurs lignes, puis rapprocher chaque retour logistique avant de créer une pièce SAP. L’expédition partielle, le rejeu et le résultat inconnu sont des cas de recette dès le départ. Le choix d’un connecteur se fait sur leur couverture dans vos installations, pas sur la seule présence du mot SAP dans un catalogue.
Dawap accompagne l’intégration API entre vos logiciels, avec une expertise d’intégrateur Shippingbo pour la partie logistique. Le raccordement à SAP Business One est qualifié avec votre intégrateur ERP : objets disponibles, règles de validation, quantités, droits et pièces attendues. Les essais chiffrés qui suivent sont fictifs ; ils ne décrivent pas un déploiement client de cette combinaison.
Pour qui relier commandes SAP Business One et préparation Shippingbo ?
Ce raccordement concerne les grossistes et distributeurs dont les commandes sont validées dans Business One avant de rejoindre l’entrepôt. Il devient prioritaire lorsque la ressaisie ou le retour des colis partiels empêche l’administration des ventes de retrouver les lignes livrées.
Le catalogue ERP de Shippingbo consulté pour cette vérification cite SAP S/4HANA. SAP Business One est un autre produit : cette présence ne confirme ni un module prêt à installer pour Business One, ni les fonctions couvertes dans votre environnement. L’absence du nom dans cette liste ne démontre pas davantage qu’aucune offre partenaire n’existe.
Demander une démonstration sur vos pièces
La présentation Shippingbo dédiée à S/4HANA prévoit notamment un cadrage puis un développement par l’intégrateur. Pour Business One, demandez la nature précise de la solution proposée : produit maintenu, connecteur partenaire, adaptation ou développement. Son fournisseur doit préciser versions supportées, objets traités et responsabilités de maintenance.
La démonstration doit commencer par une commande professionnelle de votre ERP et revenir sur ses lignes après une expédition partielle. Ajoutez une annulation et une interruption de transmission. Si le prestataire montre seulement un import de commande nominale, la couverture des bons de livraison et des reprises reste à établir avant engagement.
La méthode de raccordement Shippingbo à un ERP sans connecteur adapté compare les options générales. Le besoin Business One ajoute ici une contrainte précise : conserver l’identité des documents et la filiation des lignes, sans déduire les écritures ERP d’un statut logistique global.
Qualifier le Service Layer et les responsabilités de chaque équipe
SAP Business One garde les données de gestion retenues par votre organisation : clients, commandes commerciales, documents de livraison et finance. Shippingbo exécute la partie logistique configurée. Le middleware traduit leurs échanges ; il ne devient pas un troisième ERP dont les règles financières évolueraient indépendamment.
Vérifier les interfaces dans l’installation du client
La référence officielle SAP Service Layer expose notamment les entités Orders et DeliveryNotes. Elle indique qu’à partir de FP 2405, OData v3 est déprécié et OData v4 devient le protocole principal. Cette référence ne confirme pas que votre serveur possède la version, les droits ou les objets nécessaires au parcours envisagé.
Votre intégrateur SAP confirme version, base société, accès au Service Layer, schéma disponible et personnalisations. Les règles d’approbation, séries de documents, dépôts, lots ou numéros de série sont également relus. Le compte technique reçoit les droits nécessaires au périmètre retenu, avec une gestion des accès adaptée ; les identifiants ne sont jamais transmis dans une fiche de diagnostic public.
Le contrat d’échange attribue les responsabilités : SAP valide le document commercial, Shippingbo produit les faits logistiques, l’intégrateur contrôle les correspondances et l’exploitation traite les dossiers refusés. Les entrées et sorties attendues sont décrites pour chaque opération, avec une preuve de résultat. Une indisponibilité du serveur ouvre une reprise technique ; une ligne non autorisée attend une décision métier.
Conserver société, DocEntry et LineNum avant le transfert
La documentation SDK définit DocEntry comme la clé du document et DocNum comme son numéro. Gardez les deux : la clé sert au raccordement, le numéro aide les équipes à retrouver la pièce. La base société et le type de document complètent le contexte du connecteur.
Ne pas rapprocher deux lignes sur le seul article
Une commande peut contenir deux lignes du même article, avec des dépôts ou conditions différents. Le dictionnaire de correspondance conserve alors la ligne SAP et l’objet logistique qui la représente. Si le flux Shippingbo regroupe les lignes par référence, vérifiez quelle règle permet de répartir les quantités revenues. Sans règle approuvée, une quantité expédiée par SKU ne peut pas être attribuée arbitrairement à la première ligne SAP.
Exemple concret fictif : la société A possède la commande DocEntry 52001, affichée sous le numéro 2600412. La ligne 0 commande dix unités de P24 depuis D01 ; la ligne 1 en commande quatre depuis D02. Un retour « six P24 expédiés » laisse deux lignes candidates si la filiation manque. La recette doit refuser cette ambiguïté avant de créer un bon de livraison.
Choisir les documents réellement préparables
Le circuit ne doit pas exporter tous les brouillons ou devis comme des commandes à préparer. Définissez avec l’administration des ventes les validations nécessaires : accord commercial, approbation, crédit, paiement ou autre condition propre à votre activité. Le document conserve l’état qui autorise sa transmission et la règle appliquée. Une mise à jour après départ du flux demande ensuite sa propre décision de propagation.
La référence Service Layer signale aussi un comportement particulier lors de la création d’Orders avec des procédures d’approbation : un brouillon peut être créé. Si votre intégration crée des commandes dans SAP, vérifiez le résultat métier au-delà de la réponse HTTP. Dans le parcours présenté ici, nous partons d’une commande ERP déjà autorisée à rejoindre la préparation.
Créer les adresses Shippingbo avant la commande B2B
La documentation Shippingbo des commandes B2B décrit deux étapes : créer les adresses, puis créer la commande en référençant leurs identifiants. Adresse de livraison et adresse de facturation peuvent partager un identifiant si elles sont identiques, ou demander deux objets distincts. Le connecteur conserve les résultats intermédiaires.
Distinguer une adresse prête d’une commande créée
Si la deuxième étape échoue, des identifiants d’adresse peuvent déjà exister alors que la commande n’existe pas encore. La reprise doit retrouver le dossier et ces références avant de décider quoi recréer. Une adresse acceptée ne devient pas la preuve que l’entrepôt a reçu la demande. Le journal indique l’étape terminée et celle dont le résultat reste à obtenir.
Cette documentation indique une contrainte d’unicité sur le couple source et source_ref pour identifier la commande. Le format utilisé par votre connecteur doit distinguer les sociétés SAP et les documents autorisés. Une règle fictive peut combiner société, type et DocEntry ; elle reste un choix d’intégration à vérifier, pas un format SAP ou Shippingbo imposé par défaut.
Préserver l’adresse de la prestation à exécuter
L’adresse de la commande est relue avant l’envoi : établissement, destinataire, pays, contact et informations nécessaires au service choisi. Le fait qu’un client SAP possède une adresse actuelle ne prouve pas qu’elle remplace celle de la commande en cours. Une correction doit garder sa date et son effet sur la préparation, surtout lorsque l’étiquette ou le départ physique existe déjà.
La recette vérifie une différence livraison/facturation, une adresse refusée et une interruption entre les deux étapes. Elle observe la commande réellement visible dans Shippingbo et la référence retrouvée par le support. Elle ne se contente pas de compter les réponses réussies de l’API d’adresses.
Rapprocher articles, unités et dépôts sans effacer les différences
Le catalogue logistique doit retrouver les articles à préparer. La correspondance porte la référence SAP, la référence Shippingbo et les unités utilisées. Un carton de six pièces ne doit pas devenir six cartons lors du retour d’expédition. Le mapping précise également quels dépôts SAP correspondent aux points de stock ou aux circuits logistiques choisis.
Séparer présence de l’article et capacité d’expédition
Contre-intuitivement, une commande acceptée ne prouve pas que son stock permet la préparation. Une référence reconnue ne garantit pas non plus un emplacement préparable. La documentation B2B Shippingbo précise que la création de commande peut être acceptée malgré un manque de stock, avec un état adapté. Le connecteur doit lire cette conséquence et rendre l’attente visible dans le dossier ERP. Créer la commande ne justifie aucun bon de livraison.
Le premier signal faible est l’apparition de lignes correctes dans les deux logiciels, mais dont les quantités évoluent avec un rapport constant, par exemple six pour un. Cherchez une conversion de conditionnement avant d’ajouter un correctif de stock. Le second est une concentration des erreurs sur un dépôt : la référence produit peut être juste tandis que le circuit d’exécution est mal rapproché.
Définir ce que le stock retourné doit alimenter
Stock logistique, stock comptable et disponibilité commerciale répondent à des usages distincts. Décidez quelles observations reviennent dans SAP et quel processus peut créer un mouvement. Recopier une quantité instantanée dans un autre système n’équivaut pas à enregistrer tous les mouvements qui l’expliquent. L’intégrateur ERP valide la méthode compatible avec l’organisation des dépôts et les opérations déjà comptabilisées.
Une rupture de synchronisation conserve une information datée et une prochaine vérification. Le monitoring montre le dernier relevé accepté par article et dépôt ; il ne rajeunit pas toutes les lignes à l’heure du dernier job. Le repli autorisé doit indiquer si la publication commerciale est suspendue ou si une validation opérationnelle prend le relais.
Revenir des colis aux bonnes lignes SAP
La documentation Shippingbo des expéditions décrit une Shipment par colis, avec référence de transport et URL de suivi. Elle présente également les quantités et, selon les données disponibles, les lots ou numéros de série dans les informations d’expédition. Ces objets doivent rester reliés à la commande et aux correspondances établies.
Une commande partiellement expédiée ne livre pas toutes ses lignes
La documentation du retour vers l’ERP distingue notamment les expéditions partielles et demande d’examiner les quantités par ligne. Dans le scénario 52001, six unités attribuées à la ligne 0 laissent encore quatre unités sur cette ligne et quatre sur la ligne 1. Un tracking global ne doit pas clore ces huit unités restantes.
Conservez chaque colis et sa quantité rapprochée. Si une source fournit un cumul expédié, comparez-le à l’observation et aux effets déjà acceptés avant de calculer la quantité nouvelle. Si elle fournit des colis identifiés, dédupliquez chaque colis. Le contrat doit choisir cette interprétation à partir du schéma réellement reçu ; il ne peut pas traiter indistinctement les deux formes comme un delta.
Préparer la filiation du bon de livraison
Les propriétés SDK BaseType, BaseEntry et BaseLine décrivent respectivement le type, le document et la ligne source dans la filiation des documents. Le type commande de vente vaut 17 dans l’énumération SAP correspondante.
Vérifiez avec votre intégrateur leur exposition et leur utilisation dans l’interface de votre installation. Dans notre proposition de modèle, les six unités conservent la société A, la commande 52001 et la ligne 0 avant la création de la pièce. Le dépôt, les unités, les lots et les droits complètent la validation. Cette correspondance ne constitue pas une requête Service Layer prête à exécuter sans recette.
Exercice : huit contrôles avant les écritures de livraison
Les sociétés, commandes, lignes et résultats suivants sont fictifs. La commande 52001 de la société A contient dix P24 sur la ligne 0 et quatre P24 sur la ligne 1. Le modèle local conserve des commandes logistiques et des pièces de livraison en mémoire. Il ne se connecte ni à SAP ni à Shippingbo et ne réalise aucune préparation physique.
Établir la décision attendue à chaque frontière
| Contrôle | Situation | Sortie vérifiée | Ce que l’équipe conserve |
|---|---|---|---|
| A · Validation SAP | Document encore en brouillon | Aucune commande logistique créée | La décision d’autoriser la préparation |
| B · Sociétés | Même DocEntry dans A et B | Deux références logistiques distinctes | Le contexte société dans l’identité |
| C · Stock | Commande acceptée, préparation en attente | Aucune pièce de livraison créée | Création et exécution séparées |
| D · Ligne ambiguë | Six P24, sans allocation entre lignes 0 et 1 | Retour refusé pour livraison | Une correspondance à qualifier |
| E · Première expédition | Six unités explicitement liées à la ligne 0 | Une pièce ; reste quatre et quatre | La ligne source et le colis |
| F · Rejeu | Même colis et mêmes six unités | Même pièce retrouvée ; pas de nouvel effet | La preuve du traitement initial |
| G · Solde | Autre colis : quatre sur chaque ligne | Deux pièces au total ; quatorze unités rapprochées | Le détail des deux expéditions |
| H · Résultat inconnu | Pièce enregistrée, accusé perdu, rapprochement | Une pièce sur cette branche ; aucune recréation | La référence de contrôle de l’écriture |
Les huit contrôles sont exécutés par assertions dans un modèle séquentiel. E, F et G forment une suite ; H utilise une branche séparée pour éprouver la perte d’accusé. Les autres cas repartent d’un état connu. Le mécanisme d’unicité du modèle n’est pas une preuve des garanties natives d’une API ni de la concurrence entre plusieurs serveurs.
Le corrigé conserve deux pièces et quatorze unités rapprochées dans la suite E à G, sans facture ni paiement. La recette réelle doit ensuite observer les objets écrits dans votre environnement autorisé. Le seuil du pilote est zéro deuxième pièce pour le même effet logistique, avec chaque refus rattaché à sa commande et à la prochaine action responsable.
Reprendre une transmission sans recréer son effet
La création d’une commande, celle d’un bon de livraison et la mise à jour d’un suivi n’ont pas la même clé d’idempotence. La première suit le document commercial autorisé ; la deuxième suit la quantité logistique rapprochée selon le contrat ; la troisième peut évoluer plusieurs fois pour un même colis. Le connecteur ne doit pas dédupliquer toutes les opérations avec la seule référence commande.
Distinguer refus certain et résultat à rapprocher
Après un refus de validation, le support connaît la correction attendue. Après un timeout, une écriture peut avoir réussi. Le runbook précise comment rechercher la pièce concernée, quelles références sont conservées et qui intervient lorsque l’interface ne permet pas le rapprochement automatique. Un retry ne devient autorisé qu’après cette qualification ; un nouveau numéro de message ne constitue pas un nouvel engagement métier.
Le cas H suppose que l’interface fictive retrouve la pièce par une référence corrélée. Faites confirmer cette capacité dans SAP, par les champs et recherches effectivement disponibles. Une référence personnalisée ne doit pas être présentée comme une contrainte d’unicité native garantie. La protection en production comprend la journalisation durable, les règles de concurrence et la vérification des effets externes.
Présenter une file de travail par document
L’écran d’exploitation réunit société, numéro SAP, clé interne, commande Shippingbo, lignes, colis, pièce ERP et état de rapprochement. Les entrées reçues et les sorties attendues restent reliées par le contrat du connecteur. Les responsabilités de reprise distinguent données commerciales, allocation logistique et erreur technique ; elles ne sont pas cachées derrière un unique message « synchronisation échouée ».
Une alerte indique le dernier résultat connu, l’étape suspendue et l’action autorisée. Une donnée absente reste absente ; une quantité zéro reçoit son sens métier. La queue de reprise conserve les versions et la preuve des effets déjà appliqués. Le retour au service ne rejoue pas automatiquement toutes les pièces en attente comme des créations neuves.
Garder facture, retour et disponibilité sous leurs propres contrôles
Un bon de livraison, une facture et un paiement sont trois objets distincts. L’administration des ventes et la finance décident quelles pièces sont produites, à quel moment et sur quelle quantité. Le statut d’expédition alimente cette décision ; il n’impose pas à lui seul de facturer toute la commande, ni de considérer le client comme payé.
Ne pas remplacer les règles de prix SAP par le retour logistique
La documentation financière Shippingbo décrit un rôle de transmission des prix reçus et des comportements dépendant de l’option de facturation. Vérifiez les champs disponibles dans votre compte avant de reprendre taxes, remises et transport. Le prix contractuel de la commande SAP ne doit pas être remplacé silencieusement par une valeur logistique dont l’origine ou l’unité n’a pas été qualifiée.
Cas concret fictif : un champ en centimes vaut 12 500 avec la devise EUR ; sa valeur est 125,00 €. La recette vérifie cette conversion exacte, puis confirme que la présence de ce montant ne crée aucune facture ni preuve de règlement dans le modèle. Pour une autre devise ou un autre champ, contrôlez sa convention réelle au lieu de généraliser la conversion depuis le seul nom de la propriété.
Traiter une réception de retour sans remboursement implicite
Le retour retrouve la vente, la ligne et les unités concernées, puis reçoit la décision qualité. La réception physique ne prouve pas que le produit peut être revendu ni que le remboursement est dû dans le montant initial. L’ERP conserve les documents nécessaires selon votre processus, et le connecteur transmet les observations sans inventer un avoir.
Une annulation reçue après expédition partielle doit être examinée avec les pièces déjà créées. Ne supprimez pas une livraison passée pour rendre le dossier visuellement cohérent. L’administration des ventes décide du traitement commercial et l’intégrateur applique les opérations ERP autorisées. La recette porte aussi sur les notifications : le client ne doit pas recevoir deux informations contradictoires lors d’une reprise.
Plan d’action : raccorder une société et un dépôt avant l’extension
Le pilote commence avec un jeu de commandes représentatives et les personnes qui traiteront ses refus. Choisissez une société SAP, un dépôt, quelques articles et un circuit Shippingbo connu. Les entrées comprennent documents, unités, adresses et validations ; les sorties couvrent commande visible, quantités rapprochées et pièces ERP. L’intégrateur SAP confirme les dépendances avant l’ouverture des écritures.
Mesurer la ressaisie et le coût des exceptions
Exemple de budget fictif : huit cents commandes mensuelles, avec quatre minutes de reprise chacune, représentent 53 heures et 20 minutes. Réduire ce temps à deux minutes laisserait encore 26 heures et 40 minutes à financer. Le pilote mesure les temps observés, les erreurs évitées et la charge de maintien ; ces calculs ne constituent pas un retour sur investissement garanti.
Ajoutez la surveillance, les mises à jour des deux logiciels, les personnalisations SAP et les changements d’entrepôt. Le coût caché vient aussi des exceptions : une ligne ambiguë peut monopoliser administration des ventes, logistique et intégrateur. Un traitement assisté sur un cas rare peut coûter moins qu’une automatisation dont personne ne peut valider la règle.
Refuser les erreurs qui compromettraient les pièces
- À faire d’abord : qualifier documents, lignes, adresses et références de rapprochement dans une société.
- À tester avant écriture : expédition partielle, même SKU sur deux lignes, refus de validation et accusé perdu.
- À différer : facturation automatique, lots sensibles et autres sociétés tant que leurs règles restent non vérifiées.
- À refuser : deuxième livraison du même effet, attribution au hasard d’une ligne ou facture déduite du seul tracking.
Le rollback suspend les nouvelles écritures du connecteur et rétablit le circuit assisté convenu. Il conserve les documents déjà créés et les correspondances nécessaires au rapprochement. L’extension attend que le support puisse traiter les huit cas depuis la file avec leurs références, plutôt que demander à un développeur de reconstruire la vente dans les logs.
Erreurs fréquentes : trois raccourcis qui faussent la livraison SAP
- Utiliser DocNum comme seule clé : le numéro affiché aide l’équipe à chercher une pièce, mais ne remplace pas la clé interne et son contexte société. Le journal retrouve la commande avec société, type et DocEntry ; la recette rapproche cette identité du numéro visible.
- Transformer tout cumul expédié en quantité nouvelle : si six unités ont déjà créé une livraison et que le retour suivant indique dix unités cumulées, seules quatre restent nouvelles dans cette convention. Le connecteur compare l’observation aux effets enregistrés avant de décider ; il doit d’abord confirmer que le champ est bien cumulatif.
- Déduire le paiement de la livraison : une pièce logistique ne démontre ni une facture émise ni un règlement rapproché. La finance conserve ses documents et son circuit de validation ; les états financiers ne sont pas recalculés depuis le statut d’un colis.
Ces raccourcis deviennent particulièrement coûteux lorsqu’une correction change les pièces déjà produites. Le support suspend l’opération concernée, conserve ses références et soumet la différence à l’équipe compétente. Une correction de mapping reçoit une nouvelle recette sur les anciennes correspondances avant de reprendre les commandes restantes.
Approfondir la préparation, le middleware et la réutilisation du connecteur
Comprendre la chaîne Shippingbo au-delà du document SAP
Le parcours Shippingbo, de la commande à l’expédition relie préparation, colis, étiquette et statuts. Il complète le raccordement lorsque l’enquête se situe dans l’exécution logistique plutôt que dans la filiation du bon de livraison.
Le contrôle Business One conserve toutefois son propre résultat : quelle ligne commerciale a été rapprochée et quelle pièce est réellement créée ? Une étiquette trouvée dans la chaîne transport ne répond pas encore à ces deux questions.
Répartir les responsabilités entre WMS, TMS et ERP
La méthode WMS, TMS et intégration logistique aide à délimiter les systèmes et leurs échanges. Elle devient utile lorsqu’un 3PL ou un autre WMS intervient entre la commande commerciale et le résultat d’expédition.
Le contrat doit alors nommer la source des faits physiques, celle des pièces financières et les références qui permettent de les rapprocher. Le connecteur SAP ne doit pas corriger dans l’ERP une donnée dont l’écart provient encore de l’entrepôt.
Réutiliser sans supposer des installations identiques
Le raccordement d’un logiciel à l’ERP de plusieurs clients précise les limites de réutilisation. Il s’applique lorsqu’un éditeur ou un groupe veut reproduire le pont Shippingbo–Business One dans plusieurs contextes.
La logique commune peut être réutilisée, tandis que sociétés, dépôts, validations, unités et interfaces demeurent configurés et recettés séparément. Une deuxième installation ne reçoit pas une promesse de compatibilité parce que la première a réussi.
Pour un autre ERP, le parcours Business Central et Shopify, lignes d’expédition et dépôts illustre une restriction différente : une ligne répartie dans le canal peut perdre sa ventilation dans le document ERP. Ses huit cas distinguent total commercial et quantité autorisée sur l’affectation visée. Ils ne constituent pas une recette du connecteur SAP, dont les pièces et interfaces restent distinctes.
Conclusion : retrouver la commande, la ligne et la pièce produite
Relier Shippingbo à SAP Business One demande davantage qu’un transfert de commandes. Le parcours conserve le contexte société, les clés de documents, les lignes et les quantités réellement exécutées. La qualification des interfaces et du connecteur vient avant l’ouverture des effets ERP.
Les huit contrôles donnent une recette bornée : refuser un brouillon, distinguer les sociétés, conserver l’attente de stock, résoudre une ligne ambiguë et rapprocher les expéditions sans rejouer leurs effets. Le modèle garde quatorze unités livrées en deux pièces sur sa suite principale, sans facture ni paiement automatique.
Une transmission incertaine attend une preuve de résultat. Une réception de retour attend sa qualification commerciale et qualité. Ces frontières permettent à l’administration des ventes, à la logistique et à la finance de reprendre le dossier avec les mêmes références, même lorsque plusieurs systèmes interviennent.
Dawap peut cadrer et réaliser cette intégration API dans votre SI, en coordination avec votre intégrateur SAP Business One. Une commande réelle anonymisée, ses lignes, votre circuit Shippingbo et les documents attendus fourniront le périmètre de recette avant de choisir le connecteur, son adaptation ou un middleware spécifique.
