À 9 h 02, votre ERP envoie sept unités pour remettre un produit en vente. Le connecteur affiche « accepté ». À 9 h 08, le compte attendu est toujours en rupture. Sur un second compte de la même marketplace, la référence semble soudain disponible. Les deux comptes utilisent le même SKU vendeur, mais ils vendent à partir de stocks distincts.
Avant de renvoyer le stock, vérifiez quelle offre le flux a réellement modifiée. En pratique, une destination valide peut masquer deux problèmes à la fois : un produit indisponible là où il devrait se vendre et un risque de survente sur l’autre compte.
Les équipes e-commerce et les exploitants peuvent retrouver la destination en rapprochant les deux offres avec le journal du connecteur ERP et marketplaces. Ce diagnostic fait partie de notre accompagnement des vendeurs marketplace. Le cas Atelier et Maison montre comment limiter l’incident puis vérifier que la correction tient au passage suivant.
Que vérifier quand le flux stock est vert ?
Retrouver le sens exact du statut « accepté »
Ouvrez le détail du traitement pour savoir qui a produit ce statut et pour quel objet. Un lot accepté par l’outil de transport peut encore contenir une ligne en attente ou rejetée. Paradoxalement, l’acceptation peut être un indice de l’erreur : le canal a reconnu une offre valide, qui appartient à un autre compte. Notez l’identifiant de la ligne et la destination qui figurent sur la requête envoyée. Le statut du lot seul ne permet pas de les reconstruire.
Sur Amazon, la documentation du cycle de vie des offres distingue l’acceptation de la soumission et l’état de l’offre pendant son exploitation. La référence de getListingsItem identifie la lecture par vendeur, SKU et place de marché. Elle permet notamment de demander les données de disponibilité et les problèmes associés. C’est un exemple de lecture par destination. Sur un autre canal, vérifiez l’identifiant d’offre et les données réellement exposées.
Comparer la même offre, du journal à la page acheteur
Relevez d’un côté l’offre attendue par le vendeur et de l’autre la destination expédiée par le connecteur. Comparez le compte, le marché et l’identifiant de l’offre ou de la variante. Ajoutez le mode d’expédition ou le dépôt seulement si ce champ sélectionne une disponibilité différente dans votre flux. Deux captures de fiches ayant le même titre ne suffisent pas à identifier le vendeur dont la quantité a changé.
La page publique sert à constater si l’offre du vendeur choisi est proposée pour une destination de livraison donnée. Elle ne montre pas toujours une quantité exacte et peut sélectionner un autre vendeur. Relevez le contexte et l’heure de consultation. Si la lecture authentifiée n’est pas disponible, indiquez que la quantité de la cible reste inconnue et laissez l’incident ouvert.
Dans quels cas suspecter la destination ?
Commencez par une référence vendue sur plusieurs comptes, places de marché ou variantes, surtout si le défaut suit un ajout de compte, une migration de catalogue ou un changement de clé. Deux indices orientent le tri : une offre qui passe soudain de zéro à une quantité positive sans mouvement chez elle, ou deux comptes dont les valeurs deviennent identiques alors que leurs stocks sont séparés.
Si la ligne a été rejetée sur le bon compte, examinez la validation de la quantité plutôt que la correspondance entre comptes. Si la valeur est correcte côté canal et que l’offre reste indisponible pour un acheteur, vérifiez la publication, le vendeur sélectionné et la livraison. Si le journal ne conserve pas la cible effectivement envoyée, la proximité entre deux quantités est un indice à corroborer par une trace de la marketplace ou du transport.
Cas concret : sept unités sur le mauvais compte
Un même SKU sur deux comptes, deux décisions de stock
Le distributeur fictif vend le produit CAISSE-18 via deux comptes français. Le compte Atelier sert les commandes du dépôt Nord. Il vient de réceptionner douze unités physiques. Trois sont déjà engagées et deux sont conservées en réserve de sécurité, soit sept unités à diffuser. Le compte Maison dépend du dépôt Sud, qui dispose d’une unité diffusable. Le scénario suppose que ces deux stocks ne sont ni mutualisés ni transférables pendant l’incident.
Lors de l’ajout du second compte, la table de correspondance du connecteur a conservé une recherche par SKU vendeur seul. Les deux offres ont donc partagé la même clé. L’import le plus récent a associé CAISSE-18 au compte Maison. À 9 h 02, le flux d’Atelier calcule sept, puis la requête part vers Maison. Le canal reçoit une demande valide pour une offre existante.
| Compte | Cible ERP | Stock relu | Écart |
|---|---|---|---|
| Atelier · Nord | 7 | 0 | −7 |
| Maison · Sud | 1 | 7 | +6 |
Le support a d’abord vu la rupture Atelier. La relecture des deux offres révèle une priorité plus urgente : Maison annonce six pièces de plus que sa cible à cet instant. Ces six unités mesurent l’écart d’exposition. Pour établir une survente effective, il faut compter les commandes confirmées et vérifier les quantités que le dépôt peut servir.
Relier la décision ERP à l’offre qui a bougé
Conserver la correspondance utilisée au moment de l’envoi
Pour chaque écriture, conservez un identifiant de corrélation, l’entité et la référence source, la quantité calculée, le compte et le marché attendus, la version de la correspondance utilisée, la cible envoyée et l’accusé de la ligne lorsqu’il existe. Les lectures après envoi portent leurs propres horaires. Cette trace permet de retrouver un incident même si la table des correspondances a déjà été corrigée depuis.
Dans le dossier, la révision de stock d’Atelier porte bien une cible de sept. La requête associée porte le compte Maison et son identifiant d’offre. La relecture de Maison retrouve sept. Ces éléments situent l’erreur entre le calcul et l’envoi. Si la requête avait visé Atelier et que seule la page publique était restée fermée, il aurait fallu examiner le délai de traitement, l’état de l’offre et le contexte d’achat. Le cas eBay d’une offre qui reste à zéro détaille une autre cause possible, liée aux deux niveaux de quantité sur cette plateforme.
Faire refuser une correspondance incomplète
Le SKU reste utile pour la recherche. En revanche, pour choisir la destination d’une écriture, la résolution doit inclure le canal, le compte et le marché. Ajoutez l’identifiant local de la variante ou du périmètre de disponibilité si plusieurs cibles restent possibles pour la même combinaison. La correspondance retenue donne ensuite un identifiant de destination unique. Vérifiez aussi que les droits d’écriture du connecteur correspondent bien au compte résolu.
Lors de l’incident, il faut donc pouvoir lire un enregistrement de ce type : décision ERP D-314 pour Atelier, marché France, SKU CAISSE-18, cible 7. La correspondance version 18 a produit Maison, offre M-22. L’accusé A-830 se rattache à cette requête. L’identifiant de l’offre attendue est A-17. Avec ces deux identifiants, l’exploitant peut vérifier les valeurs séparément et demander à l’intégrateur de reproduire la résolution avec la même version de correspondance.
À l’entrée du traitement, conservez le compte attendu avec la décision ERP. À la sortie de la résolution, comparez ce compte et le marché avec ceux de l’offre choisie avant que la file d’envoi accepte le message. La journalisation doit conserver le résultat de cette comparaison et le motif du blocage. Cela permet de distinguer une clé absente d’une correspondance qui existe mais contredit le compte attendu.
Une correspondance absente ou multiple doit bloquer cette ligne et fournir à l’exploitant les informations nécessaires pour la qualifier. Dans cet exemple, un repli sur le dernier compte importé convertit une erreur de configuration en écriture commerciale. Préférez une ligne en attente, avec le compte attendu et la référence à corriger, à une mise à jour confirmée sur une autre offre.
Plan d’action : corriger les deux offres dans le bon ordre
Limiter d’abord l’exposition du compte qui a reçu trop de stock
- Isolez les écritures de stock sur les deux cibles concernées pendant l’enquête. Gardez la collecte des commandes active et vérifiez que l’isolement couvre aussi les tâches en attente susceptibles de réécrire ces offres.
- Recalculez la disponibilité du compte sur-exposé à partir des engagements actuels. Dans le cas fictif, une commande Maison est confirmée à 9 h 10 et engage la dernière pièce du Sud. Sa nouvelle cible est zéro. Rétablir l’ancienne valeur d’une unité la remettrait en vente.
- Utilisez une correction approuvée qui désigne explicitement Maison et son offre. Relisez cette cible après traitement. Tant que la correction reste en attente ou que la quantité ne peut pas être lue, gardez la protection du périmètre et le suivi des commandes.
- Vérifiez la correspondance Atelier, recalculez sa cible et publiez-la séparément. Aucun mouvement n’a touché le Nord dans l’exemple, donc sept restent justifiés. Relisez Atelier et Maison après traitement, puis vérifiez leur stabilité après un cycle normal du connecteur.
L’arbitrage dépend du périmètre connu. Si seuls Atelier et Maison sont concernés et que le connecteur permet de bloquer les écritures par offre, une pause ciblée laisse le reste du catalogue en service. Si la clé défectueuse est utilisée par d’autres comptes et que le périmètre reste inconnu, le responsable du flux peut suspendre la diffusion des lignes ambiguës le temps d’établir la liste. Dans les deux cas, quelqu’un doit surveiller les commandes qui continuent d’arriver. Préparez aussi la remise en route : une tâche déjà transmise peut produire un effet après la pause locale.
Confiez la sortie de l’isolement à un responsable du flux. Il vérifie que la file de reprise a écarté les tâches construites avec la version défectueuse. Pour chaque tâche écartée, l’intégrateur conserve la trace et, si une mise à jour reste nécessaire, construit une nouvelle demande à partir du stock courant et de la bonne correspondance. La première exécution normale doit produire deux lectures identifiées et horodatées. Si une cible diverge à nouveau, le repli consiste à remettre les écritures concernées en pause et à conserver les observations du second écart.
Traiter les commandes déjà acceptées comme des engagements
Une correction de stock agit sur les prochaines commandes. Elle ne résout pas les commandes déjà acceptées. Rapprochez chacune d’elles des réservations et du délai promis. L’équipe opérationnelle décide de la suite selon les pièces réellement disponibles, les règles du canal et ses possibilités d’expédition. Elle doit garder la liste des commandes affectées distincte de la liste des offres corrigées.
Si plusieurs comptes partagent la même table, recherchez alors les autres clés ambiguës en lecture seule. Le résultat constitue un périmètre à examiner. Avant toute correction, comparez la trace sortante et l’état observé pour éviter d’écraser une autre offre qui fonctionne correctement.
Le responsable du dépôt confirme les unités effectivement réservées. L’équipe marketplace garde la main sur la promesse faite au client. L’intégrateur remet le flux en service quand les deux offres concordent avec les cibles recalculées. Ces responsabilités évitent qu’une correction de quantité soit interprétée comme la résolution d’une commande encore bloquée.
Tester le routage avant de relancer le flux
Reproduisez les deux offres avec des données de test. Vérifiez la destination de la requête en plus de sa quantité. Demandez une preuve négative sur l’autre compte. Un test qui contrôle seulement la valeur envoyée ou le statut retourné laisserait passer la collision.
| Scénario | Résultat exigé |
|---|---|
| Même SKU, deux comptes | Atelier reçoit 7. Aucune requête stock n’est envoyée à Maison. |
| Destination absente ou multiple | La ligne reste en attente avec son compte et son marché. Aucun appel d’écriture. |
| Correction après la commande Maison | Maison reçoit 0, calculé après réservation. L’ancienne cible 1 est écartée. |
| Ancien envoi en attente au redémarrage | Le connecteur requalifie la ligne avec la correspondance et la disponibilité actuelles avant tout nouvel envoi. |
| Relecture indisponible | La ligne reste à confirmer. La valeur attendue ne remplace pas la valeur observée. |
Au retour en exploitation, comptez les lignes bloquées pour ambiguïté et les écritures dont la destination envoyée diffère de la destination attendue. Suivez aussi l’âge des écritures encore à confirmer. Définissez ce délai à partir du traitement observé sur votre canal et du rythme des ventes. En cas de panne large, la méthode pour retrouver le point de coupure d’un flux marketplace aide à déterminer quelles écritures doivent encore être examinées.
Erreurs fréquentes pendant l’incident
- Relancer tout le catalogue. Un rejeu avec la même correspondance envoie de nouveau le stock au mauvais compte et rend l’historique plus difficile à lire.
- Comparer un total agrégé. Une quantité totale proche de la cible peut masquer un manque sur une offre et un excédent sur l’autre. Vérifiez chaque couple compte et offre.
- Recopier les valeurs d’avant l’incident. Des commandes ont pu engager du stock pendant l’enquête. Calculez les deux cibles au moment de corriger.
- Clore sur la première offre revenue. La correction est complète lorsque l’offre attendue et l’offre touchée par erreur sont toutes deux relues, et que les commandes exposées sont prises en charge.
Projets liés : Stock Dispatcher
Suivre séparément le calcul, l’envoi et la relecture
Le projet Stock Dispatcher illustre comment une règle de diffusion produit une quantité cible par offre, puis comment l’envoi et la relecture du canal sont suivis à part. Ce parcours montre les preuves qu’une équipe peut demander à son propre connecteur. Le scénario Atelier et Maison reste un exercice fictif.
Pour une équipe qui doit comparer ces quantités tous les jours, Ciama pour le pilotage marketplace peut servir de point de départ à l’évaluation. Vérifiez, canal par canal, que les comptes et les offres restent distincts et que la quantité relue peut être rapprochée de la dernière demande émise.
Pour évaluer un dispositif comparable, demandez quelle valeur a été calculée, quelle offre a reçu la demande et comment le résultat a été observé. Ces trois éléments doivent pouvoir être consultés pour une offre précise, y compris après un changement de configuration. Ils aident le commerce à qualifier la promesse et l’intégrateur à corriger la correspondance.
Guides complémentaires sur le stock marketplace
Si le compte et l’offre sont corrects mais que le chiffre change au fil de la journée, le diagnostic du stock fantôme sur une marketplace élargit l’enquête à la fraîcheur de la donnée, aux réservations et au rapprochement. Il permet de distinguer une mauvaise quantité dès le calcul d’une écriture partie vers le mauvais compte.
Si la quantité envoyée inclut des unités déjà promises, reprenez d’abord le calcul du stock diffusable par canal. Une correction du routage peut faire arriver le chiffre au bon endroit tout en conservant une erreur d’allocation.
Si le même écart de références touche aussi les commandes ou les prix, reprenez le guide de priorisation des flux ERP côté vendeur pour décider quels échanges vérifier après le stock.
Conclusion : prouver la quantité et sa destination
Quand un flux stock est accepté et que la mauvaise offre bouge, commencez par rapprocher l’intention de l’ERP, la destination réellement envoyée et les deux lectures du canal. Ici, sept unités ont été calculées correctement. Le diagnostic tient à une erreur de correspondance entre deux comptes qui partageaient le même SKU.
Ramenez d’abord l’offre sur-exposée à sa disponibilité actuelle, puis rétablissez l’offre attendue. La correction doit tenir au traitement suivant et les commandes prises pendant l’incident doivent rester visibles pour l’équipe.
La prestation Connecteurs marketplace ERP couvre la correction du routage et la recette sur les offres qui partagent une référence. Les équipes disposent ensuite d’une trace qui rapproche la cible calculée, la demande envoyée et la lecture après traitement.
Notre agence marketplace pour vendeurs peut cadrer ce diagnostic avec vos équipes commerce et logistique, depuis le premier écart relevé jusqu’au retour à une disponibilité vérifiée sur les deux comptes.
