Intégration de boutique avec SAP Business One : flux, prérequis et contrôles

Nous connectons la boutique à SAP Business One selon un flux précis et l’interface disponible. La commande doit être liée au Business Partner, à l’Item et au cycle convenu des documents commerciaux. La boutique ne doit pas réduire livraison, facturation et annulation à de simples changements de statut générique.

Dans SAP Business One, la commande doit être liée au Business Partner, à l’Item et au cycle convenu des documents commerciaux. Livraison, facturation et annulation ne sont pas de simples changements de statut. La conception utilise les actions métier disponibles de Service Layer et conserve le lien entre événement externe et documents SAP. Le responsable SAP définit séries, entrepôts, champs requis et conditions d’achèvement métier.

Service Layer expose les données et services de Business One. La référence officielle recommande OData v4 comme protocole principal depuis FP2405 et considère v3 comme obsolète, tout en le conservant pour compatibilité. Business One n’est pas S/4HANA : points d’accès, objets, configuration et flux diffèrent. Service Layer n’est pas non plus fonctionnellement identique à DI API.

Un distributeur de pièces enregistre un achat B2B en commande client. Les articles rejoignent l’Item master et l’acheteur le bon Business Partner. Une livraison partielle actualise la boutique selon les documents confirmés, sans indication globale arbitraire. Une annulation est évaluée au stade réel et exécutée uniquement par un traitement autorisé. Le lien entre commande et documents suivants reste disponible pour réconciliation et assistance.

Un scénario critique apparaît lorsqu’une annulation est tentée par simple modification de champ au lieu de l’action métier adaptée. Nous conservons référence externe et identifiant cible confirmé avant répétition. Nous distinguons échec d’accès, rejet métier et résultat incertain. L’opérateur doit examiner l’enregistrement et rétablir l’état sans répéter les étapes terminées. Champs journalisés et responsable des attentes sont convenus.

Nous testons création de commande, annulation prise en charge et lien correct au document suivant. Chaque cas documente données initiales attendues, enregistrement cible et statut client. Nous ajoutons échec de permissions et interruption de réponse. Un événement confirmé est répété pour vérifier son effet inchangé. Le procès-verbal définit équipe responsable et preuves de résolution.

L’étude confirme Service Layer actif et accessible, version OData et utilisateur autorisé convenus, responsable SAP des objets et règles. Avant production, nous documentons Articles/clients SAP → correspondance boutique → Commande → commande client SAP → Confirmation → livraison/statut convenus. Nous attribuons renouvellement des accès, surveillance et corrections. Un changement de configuration ou règle métier déclenche un contrôle ciblé. Nous commençons par ce flux et ajoutons un canal après clarification de sa responsabilité et de ses scénarios d’acceptation.