Il est 3 h 07 du matin. Votre téléphone vibre : encore une vente en excédent signalée par Shopify. Le client vient d'acheter le dernier exemplaire d'un article dont vous saviez qu'il était en rupture de stock depuis trois jours. SAP Business One indique zéro. Shopify en indique deux. C'est toujours la même histoire.
Si vous exploitez une boutique en ligne sur SAP Business One, ce problème, sous une forme ou une autre, vous coûte de l'argent et vous empêche de dormir. Les problèmes de synchronisation sont rarement dus à un seul élément défaillant. Ils relèvent d'un petit ensemble de catégories de défaillances, et la plupart des opérateurs s'attaquent au symptôme plutôt qu'à la cause.
Les problèmes de synchronisation des stocks dans SAP B1 e-commerce relèvent presque toujours de l'une des quatre catégories suivantes : décalages de synchronisation et de latence entre SAP et la boutique en ligne, incompatibilités entre les modèles de données concernant les références et les entrepôts, défaillances du middleware ou des connecteurs, et erreurs de configuration des processus au sein de SAP. Pour y remédier, il faut déterminer à quelle catégorie le problème appartient, car une solution adaptée aux problèmes de synchronisation ne résoudra pas un problème lié au modèle de données.
En quoi consiste exactement la synchronisation des stocks pour le commerce électronique dans SAP B1 ?
La synchronisation des stocks e-commerce SAP B1 consiste à garantir l'exactitude des niveaux de stock, des données produit et des engagements de commande entre SAP Business One et un ou plusieurs canaux de vente en ligne. Elle s'effectue via un intergiciel ou un connecteur, et nécessite que les deux systèmes s'accordent sur la structure des références, les définitions des entrepôts et le calendrier des mises à jour. En l'absence d'un tel accord, on risque de se retrouver face à des surventes, des ruptures de stock ou des stocks fantômes : des articles que la boutique en ligne considère comme disponibles, mais qui ne le sont pas dans l'entrepôt.
Les quatre types de défaillances à l'origine de la plupart des problèmes de synchronisation SAP B1
La plupart des responsables des opérations décrivent leur problème de synchronisation de la même manière : les chiffres ne correspondent pas. Cette cause relève presque toujours de l'une des quatre catégories suivantes. Savoir dans quelle catégorie vous vous situez vous permet de déterminer ce qu'il faut corriger et qui est responsable de cette correction.
1. Problèmes de synchronisation et de latence
Il s'agit du type de défaillance le plus courant. Votre boutique en ligne actualise son stock à une certaine fréquence, SAP à une autre, et le middleware effectue le rapprochement à une troisième fréquence. Entre-temps, les clients continuent d'acheter. Si votre synchronisation s'effectue toutes les quinze minutes et que votre référence la plus vendue se vend toutes les quatre minutes, vous serez en situation de survente pour ce produit chaque semaine. Les problèmes de synchronisation s'aggravent lors des promotions et des pics saisonniers, c'est-à-dire précisément au moment où vous pouvez le moins vous le permettre.
2. Incompatibilités entre les modèles de données
SAP B1 fonctionne avec des articles, des entrepôts, des emplacements de stockage et des groupes d'unités de mesure. Shopify fonctionne avec des produits, des variantes et des emplacements. Magento, BigCommerce et Amazon ont chacun leur propre modèle. Lorsqu'un article SAP est réparti sur trois entrepôts et que votre boutique en ligne ne dispose que d'un seul numéro de stock, c'est la logique qui regroupe ces trois éléments en un seul qui est à l'origine de la plupart des incohérences.
Symptômes courants : des articles affichés comme disponibles alors qu'ils se trouvent en réalité dans un entrepôt où ils ne peuvent pas être vendus, des variantes incorrectement associées à leurs produits parents, et des lots dont le stock diminue pour les mauvais composants.
3. Défaillances des intergiciels et des connecteurs
La couche d'intégration est rarement développée par la même équipe qui gère l'un ou l'autre des systèmes, et c'est dans cette brèche que s'accumulent les défaillances silencieuses. Les appels API expirent sans jamais être réessayés. Les files d'attente s'engorgent lors des pics de trafic. Une mise à jour de la plateforme modifie le schéma d'un webhook, mais le middleware continue d'envoyer des données à l'ancien schéma pendant des semaines avant que quiconque ne s'en aperçoive.
Ces défaillances sont insidieuses, car elles ne déclenchent souvent aucune alerte visible par l'équipe. L'intégration fonctionnait encore ce matin, donc personne ne vérifie, et dès l'après-midi, on a déjà deux cents commandes de retard.
4. Défaillances des processus et de la configuration
Parfois, les systèmes fonctionnent correctement, mais le problème réside dans la manière dont l'équipe les utilise. Des ajustements manuels des stocks qui contournent la synchronisation, des transferts entre entrepôts enregistrés par lots, des retours traités via la boutique en ligne mais jamais répercutés dans SAP, des stocks négatifs autorisés par les paramètres, et des autorisations permettant à un utilisateur non habilité de modifier les inventaires. Aucun achat de middleware ne permet de résoudre ces problèmes.
Comment déterminer à quelle catégorie de défaillance vous appartenez
Diagnostic rapide. Pour identifier la cause de votre échec de synchronisation des stocks SAP B1, sélectionnez un cas récent de survente ou de rupture de stock et répondez à trois questions. Premièrement, que montrait chaque système au moment de la vente, et la dernière synchronisation réussie était-elle antérieure à l'écart ? Deuxièmement, l'article concernait-il plusieurs entrepôts, variantes ou lots ? Troisièmement, un ajustement manuel a-t-il été effectué au cours des dernières vingt-quatre heures ? Les réponses correspondent à des catégories de défaillance liées au timing, au modèle de données, au middleware ou au processus.
Les tableaux de bord ne reflètent pas fidèlement la réalité lors du diagnostic, car ils indiquent l'état actuel du système et non celui qui prévalait au moment où le problème s'est produit. La seule méthode fiable consiste à retracer le déroulement de l'incident : il faut reconstituer la chronologie d'une panne réelle et identifier les points de divergence entre les systèmes.
Corrections, classées par catégorie de défaillance
En ce qui concerne les problèmes de synchronisation et de latence :
- Transférez les références à forte rotation vers un canal de synchronisation en temps quasi réel, même si le reste du catalogue continue d'être synchronisé selon le calendrier prévu
- Prévoyez des marges de stock côté e-commerce pour les produits qui se vendent plus vite que votre fréquence de synchronisation
- Utilisez des mises à jour via webhooks plutôt que des lectures par interrogation
En cas d'incompatibilité entre les modèles de données :
- Documenter la correspondance entre les entrepôts SAP et le modèle d'implantation des points de vente, et la réviser chaque trimestre
- Uniformiser la structure des références et l'appliquer lors de la création des articles, et non lors de la synchronisation
- Pour les lots et les kits, choisissez un seul système de référence et empêchez l'autre de réduire le nombre de composants
- Marquer les entrepôts non commercialisables et les exclure du calcul des stocks disponibles
Pour les problèmes liés aux intergiciels et aux connecteurs :
- Surveiller et générer des alertes au niveau de la couche d'intégration, et pas seulement au niveau des terminaux
- Exiger une politique de réessai avec gestion des messages non livrables pour les appels API ayant échoué
- Suivez chaque modification de schéma de part et d'autre et testez l'intégration en fonction de celles-ci
- Renseignez-vous sur le contrat de niveau de service (SLA) et la procédure d'escalade de votre fournisseur de middleware avant d'en avoir besoin
En cas de défaillances au niveau des processus et de la configuration :
- Supprimer la possibilité de modification manuelle. Toute modification du nombre d'unités dans SAP devrait déclencher une synchronisation
- Aligner la fréquence des transferts entre entrepôts sur celle des mises à jour des ventes
- Les retours de Mirror e-commerce sont répercutés dans SAP le jour même de leur enregistrement
- Vérifiez chaque trimestre les autorisations des utilisateurs et retirez les droits de modification à toute personne qui n'en a pas besoin
Quand remplacer votre middleware et quand le conserver
Décision de remplacement. Remplacez votre middleware e-commerce SAP B1 lorsque trois conditions sont réunies : les incidents de synchronisation persistent après l'application des correctifs par le fournisseur, ce dernier n'est pas en mesure d'expliquer les causes profondes de manière technique et détaillée, et vos besoins métier ont dépassé les capacités du connecteur. Conservez-le si les incidents sont résolus et si l'architecture correspond toujours à votre feuille de route. De nombreuses équipes procèdent à un remplacement prématuré, pour découvrir ensuite que le véritable problème résidait dans leur modèle de données.
Des schémas que vous reconnaîtrez
Imaginons un détaillant de vêtements de taille moyenne qui organise une promotion de deux jours et qui vend quelques centaines d'unités de plus que prévu pour l'un de ses produits phares. On aurait instinctivement tendance à attribuer la faute à la promotion, mais la cause profonde est probablement le modèle de données : l'article est réparti entre un entrepôt principal et un entrepôt dédié au traitement des retours, et le middleware additionne les stocks des deux pour calculer le nombre d'unités disponibles. La promotion n'a fait que mettre en évidence ce que le mappage faisait déjà, mais à un rythme plus lent.
Imaginons un distributeur dont le middleware ignore discrètement un faible pourcentage des mises à jour de stock pendant l'heure de pointe de l'après-midi. Le connecteur ne disposant pas de file d'attente pour les messages perdus, les mises à jour ayant échoué disparaissent tout simplement. Personne ne s'en rend compte jusqu'à ce qu'un responsable d'entrepôt compare manuellement un rapport SAP hebdomadaire aux totaux des points de vente. Ce scénario est courant précisément parce qu'il passe inaperçu : l'intégration signale la réussite des appels qui ont abouti, mais rien n'indique ce qu'il en est des appels qui ont échoué.
Prenons l'exemple d'une équipe qui constate que les excédents de ventes se concentrent le lundi. Cela est généralement dû à des ajustements manuels effectués dans SAP pendant le week-end, qui contournent la synchronisation. Aucune modification du middleware ne permet de résoudre ce problème. En revanche, une modification du workflow — consistant à acheminer tous les ajustements via le chemin synchronisé — permet d'y remédier en une semaine.
Voici les trois schémas qui reviennent le plus souvent dans les catégories d'échecs mentionnées ci-dessus. Si l'un d'entre eux vous rappelle vos lundis matins, vous savez sans doute déjà à quelle catégorie vous appartenez.
Liste de contrôle préalable au lancement pour l'état de la synchronisation des stocks dans SAP B1 E-commerce
- Synchronisation de la cadence enregistrée par niveau de vitesse des références
- La mise en correspondance entre l'entrepôt et les emplacements est à jour et a été révisée au cours des quatre-vingt-dix derniers jours
- Les alertes de surveillance du middleware sont transmises à un opérateur qui les consultera effectivement
- Politique de réessai et de gestion des messages non remis confirmée auprès de votre fournisseur d'intégration
- Processus de réglage manuel terminé, ou enregistré et synchronisé automatiquement
- Les retours provenant de la vitrine et enregistrés dans SAP ont été vérifiés ce trimestre
- Suivi des incidents liés aux surventes et aux ruptures de stock grâce au marquage des causes profondes
Quand le commerce électronique natif SAP devient la solution
Si vous avez passé en revue les quatre catégories de défaillances et que les solutions ne s'avèrent toujours pas efficaces, c'est peut-être l'architecture elle-même qui constitue le frein. Le commerce électronique dépendant d’un middleware s’alourdit avec le temps : chaque nouveau canal, chaque promotion ou chaque règle d’entrepôt ajoute un nouveau point de réconciliation, et l’équipe finit par passer plus de temps à maintenir l’intégration qu’à développer l’activité. Une plateforme de commerce électronique native SAP supprime entièrement cette couche d’intégration en s’exécutant directement sur SAP Business One. Ainsi, les stocks, les comptes clients, la tarification et la logique des commandes partagent une source unique de vérité, sans middleware susceptible de tomber en panne. C'est le modèle sur lequel repose FocusPoint, et il s'avère souvent judicieux pour les opérateurs dont le journal des incidents renvoie systématiquement à l'intégration, quel qu'en soit le propriétaire. Ce ne sera pas la solution idéale pour tout le monde — mais si vous lisez ceci à 3 heures du matin pour la troisième fois ce trimestre, cela vaut la peine d'évaluer cette option avant de renouveler le contrat du connecteur.
Foire aux questions
Quelle est la cause la plus fréquente des problèmes de synchronisation des stocks dans SAP B1 ? Les problèmes liés au timing et à la latence sont les plus courants, suivis par les incompatibilités entre les modèles de données. Ces deux types de problèmes génèrent des chiffres erronés, mais nécessitent des solutions différentes.
SAP B1 peut-il synchroniser les stocks en temps réel avec Shopify ? Oui, grâce à un intergiciel basé sur des webhooks qui transmet les mises à jour dès qu'un changement survient, plutôt que selon un calendrier prédéfini. La synchronisation en temps réel est possible pour la plupart des catalogues, bien que le coût augmente en fonction du volume de transactions et du nombre de références.
Pourquoi l'inventaire présente-t-il un décalage même lorsque le middleware signale que l'opération a réussi ? Le middleware signale souvent qu'un appel d'API a réussi dès que celui-ci a été accepté, et non pas lorsque les données ont été synchronisées. Ce décalage provient généralement de tentatives de réessai qui n'ont jamais eu lieu, de non-correspondances de schémas qui ont été corrigées en arrière-plan, ou d'ajustements manuels effectués en dehors du processus de synchronisation.
À quelle fréquence faut-il synchroniser les stocks entre SAP B1 et ma plateforme de commerce électronique ? Adaptez la fréquence au rythme des ventes. Les références à rotation rapide justifient une synchronisation en temps quasi réel. Les produits à rotation lente peuvent être synchronisés toutes les heures, voire moins souvent. Un calendrier unique ne convient presque jamais à l'ensemble de votre catalogue.
S'agit-il d'un problème lié à SAP B1 ou au middleware ? En général, cela concerne le middleware ou les processus. SAP B1 en soi provoque rarement des problèmes de synchronisation. La couche d'intégration et la manière dont les équipes utilisent SAP en sont les causes les plus fréquentes.
Puis-je résoudre ces problèmes sans remplacer mon système actuel ? La plupart du temps, oui. Des ajustements au niveau des processus et de la configuration permettent de résoudre une grande partie des problèmes de synchronisation sans avoir à changer de logiciel. Le remplacement n'est la solution qu'après l'échec des solutions moins coûteuses.
Que faire ensuite ?
Si votre équipe est régulièrement confrontée à des problèmes de surchargement, la première mesure utile consiste à choisir un incident survenu au cours des trente derniers jours et à l'analyser à la lumière des quatre catégories de défaillance mentionnées ci-dessus. En général, dès la deuxième catégorie, vous saurez à qui incombe la responsabilité du problème. Le plus difficile n'est pas de trouver la solution, mais de rompre avec l'habitude de considérer chaque échec de synchronisation comme un problème identique.
Demandez un devis gratuit et sans engagement, adapté à votre environnement SAP Business One, à vos intégrations et à vos workflows e-commerce B2B et B2C.
