Le client renvoie un produit sur trois, mais les systèmes voient trois réalités : la marketplace rembourse une ligne, l’OMS attend encore tout le colis et l’ERP crée un avoir sur la commande complète. Le dossier paraît traité côté support alors que stock, paiement et comptabilité ne partagent plus le même solde.
En pratique, le vrai risque vient du solde : un retour partiel doit conserver l’identité de chaque unité et séparer demande, réception, décision, remboursement et réintégration. Contre-intuitivement, rembourser plus vite sans preuve d’unicité peut dégrader le service. La commande reste le cadre financier ; la ligne porte l’état opérationnel.
Une agence marketplace chargée des opérations vendeur peut fermer cette chaîne. L’expertise centralisation des commandes marketplace aligne les statuts ; Ciama Marketplace peut réunir événements, preuves et exceptions.
Vous allez comprendre comment définir les états, répartir remises et frais, orchestrer le paiement, traiter les événements rejoués et prouver le solde. Les règles juridiques, fiscales et contractuelles doivent être validées dans votre contexte ; les calculs proposés servent à concevoir un système auditable.
Conserver la commande et ses lignes séparément
Une commande porte acheteur, devise, paiement, livraison et total. Chaque ligne porte produit, vendeur, quantité, prix, taxe, remise et état d’exécution. Le retour ajoute une troisième identité stable qui référence une ou plusieurs unités sans effacer la vente d’origine.
Cette granularité permet qu’une unité soit livrée, une autre en retour et une troisième déjà remboursée. Un statut unique « retourné partiellement » reste utile à l’interface, mais il ne doit jamais remplacer les états détaillés utilisés pour calculer ou réconcilier.
Le système conserve les identifiants de la marketplace, de l’OMS, du paiement, de l’ERP et du transport. La table de correspondance est versionnée et recherchable. Sans elle, l’équipe rapproche les dossiers par montant ou adresse, deux indices trop fragiles pour automatiser un remboursement.
Définir le contrat de retour avant l’intégration
Le contrat métier précise les motifs acceptés, fenêtres, conditions, responsabilités de transport et résultats possibles : remboursement, remplacement, réparation, refus ou geste. Il distingue rétractation, non-conformité, dommage et erreur logistique, car leurs frais et obligations peuvent différer.
Chaque canal apporte des statuts et délais. L’intégration traduit ces valeurs vers un vocabulaire interne sans perdre la valeur source. Une inconnue rejoint une file de qualification ; elle ne devient pas automatiquement « accepté » ou « reçu ».
Les autorités de décision sont écrites. Le support peut ouvrir un dossier, l’entrepôt confirmer l’état physique, le métier accepter une exception et la finance autoriser certains montants. Séparer ces rôles réduit le risque qu’une même action crée simultanément stock et argent sans contrôle.
Le droit applicable et les politiques de plateforme prévalent sur la commodité technique. Le système doit permettre d’appliquer la bonne règle par pays, vendeur, produit et motif, tout en conservant la version utilisée au moment de la décision.
Construire une machine à états par unité
Un parcours courant distingue demandé, autorisé, étiquette émise, expédié par le client, reçu, contrôlé, décision prise, remboursement demandé, remboursé et clôturé. Certains motifs sautent des étapes ; cette variation est explicite plutôt que corrigée après coup.
Chaque transition possède un déclencheur, un auteur, un horodatage, des préconditions et un effet. « Reçu » peut réserver l’unité dans une zone de contrôle, mais ne la rend pas vendable. « Remboursé » constate la réponse du prestataire de paiement, pas seulement l’envoi de la demande.
Les transitions impossibles sont bloquées. Un colis ne peut pas passer de demandé à remis en stock sans réception ni contrôle. Une correction administrative utilise un événement dédié qui conserve l’ancien état et le motif au lieu de réécrire l’historique.
La commande agrège ensuite les lignes : ouverte si un traitement reste actif, partiellement remboursée si le montant confirmé est inférieur au total remboursable, clôturée lorsque toutes les unités et tous les effets financiers possèdent un verdict final.
Calculer le remboursement de façon reproductible
Reconstituer le montant de vente historique
Le moteur repart de la vente : prix de ligne, quantité, remises de ligne, remise de panier, frais de livraison, taxes, avoirs antérieurs et remboursements déjà confirmés. Il n’utilise pas seulement le prix catalogue actuel, qui peut avoir changé depuis l’achat.
La remise de panier exige une règle d’allocation stable, par exemple au prorata des montants admissibles, avec gestion explicite des arrondis. Le même moteur calcule vente, retour et avoir afin que la somme des lignes reste égale au total de commande dans la devise concernée.
Les frais de livraison dépendent du motif, du droit applicable et de la politique. Ils peuvent être conservés, remboursés en tout ou partie, ou pris en charge séparément. Le calcul expose chaque composant au support au lieu de produire un montant opaque.
Appliquer le plafond avant tout effet financier
Exemple illustratif : une commande contient des lignes nettes de 60 €, 30 € et 10 €, après répartition d’une remise. Le retour de la ligne à 30 € ne signifie pas automatiquement 30 € remboursés si transport, taxe ou compensation précédente s’appliquent. Les montants doivent être recalculés depuis les données réelles ; cet exemple n’est pas une règle fiscale.
Le plafond protège contre le sur-remboursement : cumul des remboursements confirmés et de la nouvelle demande ne dépasse pas le montant remboursable calculé. Tout écart supérieur à la tolérance d’arrondi rejoint une validation humaine avant l’appel au paiement.
Orchestrer plateforme, OMS, paiement et ERP
Séparer la décision métier de son exécution
Une seule fonction métier décide le montant et produit une intention de remboursement. L’adaptateur du canal ou du paiement exécute ensuite l’effet. Cette séparation évite que deux webhooks différents recalculent chacun le dossier et lancent deux mouvements.
L’OMS conserve la chronologie des lignes ; le prestataire de paiement porte l’état du mouvement ; l’ERP enregistre l’avoir et la comptabilité ; la marketplace expose le résultat au client. Le contrat désigne la vérité de chaque objet et la règle de rapprochement lorsque les statuts divergent.
Les appels asynchrones utilisent une file, des reprises bornées et une file d’erreur attribuée. Un timeout ne signifie pas échec : avant de renvoyer une demande, l’intégration recherche l’opération existante avec sa clé. Le support ne déclenche pas un second remboursement pour « débloquer » l’écran.
Les étapes peuvent être compensées, pas effacées. Si l’avoir ERP échoue après remboursement, le paiement reste réel ; une action comptable est reprise jusqu’à convergence. Annuler artificiellement le statut financier créerait une fausse vérité supplémentaire.
Empêcher doublons et événements hors ordre
La clé d’idempotence combine retour, ligne, quantité, type d’effet et version de décision. Le même message rejoué retrouve le résultat précédent. Une nouvelle décision volontaire reçoit une version distincte et reste liée à l’ancienne.
Les webhooks peuvent arriver en retard ou dans le désordre. Le consommateur compare la version ou vérifie les préconditions plutôt que de croire l’heure de réception. Un événement « reçu » ne doit pas rouvrir un retour déjà refusé et clôturé sans instruction explicite.
Le journal conserve payload utile, signature vérifiée, identifiant source, tentative et résultat. Les données sensibles sont limitées selon les besoins. Cette trace permet d’expliquer un doublon sans dépendre des logs temporaires d’une plateforme.
Règle conditionnelle illustrative : si un effet financier reste sans confirmation après trois tentatives et 30 minutes, alors le dossier passe en revue manuelle au lieu de multiplier les appels. Le nombre et le délai doivent suivre les caractéristiques du prestataire et le risque métier.
Réceptionner sans remettre en stock trop tôt
Le colis entrant est associé au retour puis à chaque unité. L’entrepôt constate quantité, identité, état et accessoires. Une unité inattendue ou manquante ouvre une anomalie ; elle n’est pas forcée dans la ligne la plus proche pour fermer rapidement le dossier.
La réception physique et la décision qualité restent distinctes. Le produit rejoint une zone de quarantaine jusqu’au contrôle. Seulement ensuite, un verdict autorise remise en vente, reconditionnement, réparation, retour fournisseur ou sortie de stock.
Le WMS produit la preuve du lot, du scan et de la personne. Si le remboursement précède la réception selon la politique, cette avance financière n’autorise toujours pas le stock. Argent et marchandise convergent au rapprochement, mais suivent des contrôles propres.
Expliquer un dossier fractionné au client
Le client voit les articles concernés, quantités, étapes et montants. Le message distingue « retour autorisé », « colis reçu », « remboursement demandé » et « remboursement confirmé ». Dire « remboursé » avant la confirmation bancaire crée une nouvelle promesse difficile à défendre.
Une commande peut générer plusieurs colis et remboursements. L’interface rassemble ces mouvements sans les confondre : montant de chaque opération, moyen de paiement, date et solde restant. Le support dispose de la même vue pour éviter des explications contradictoires.
Lorsqu’un montant diffère de l’attente, le détail montre prix d’origine, remise, frais et remboursement antérieur. L’explication ne remplace pas la validation juridique, mais réduit les dossiers créés uniquement parce que le calcul interne était invisible.
Rapprocher argent, marchandises et commissions
Le dossier se ferme après comparaison de quatre soldes : unités vendues et retournées, remboursements demandés et confirmés, avoirs comptables, commissions ou frais ajustés par la marketplace. Une égalité financière sans état physique final reste incomplète.
Les écarts sont classés : latence normale, arrondi, commission non restituée, remboursement échoué, avoir absent, unité non reçue ou geste hors retour. Chaque catégorie possède un propriétaire et une échéance. Les fichiers de paiement et de plateforme complètent les événements temps réel.
La supervision suit âge des retours ouverts, montants sans confirmation, unités en quarantaine, écarts ERP et remboursements multiples bloqués. Elle mesure aussi le coût complet par motif afin d’orienter correction produit, transport ou information catalogue.
Étudier un cas illustratif à trois produits
Cas illustratif Dawap : un panier contient trois articles expédiés ensemble. Le client retourne deux unités pour des motifs différents ; l’une peut être revendue, l’autre est endommagée. La marketplace émet un événement par ligne, puis renvoie le premier après un timeout.
L’OMS crée deux dossiers, alloue la remise historique et génère deux intentions. La clé idempotente absorbe l’événement rejoué. Le WMS contrôle séparément les unités ; l’ERP reçoit deux lignes d’avoir tandis que la commande conserve l’article gardé.
La recette simule 40 scénarios : quantités partielles, colis incomplet, remboursement échoué, webhook inversé et geste antérieur. Si un scénario produit plus d’un effet financier pour la même version, alors le déploiement reste bloqué. Ce volume et ce critère sont pédagogiques.
Le scénario ne représente ni taux d’erreur moyen ni garantie de performance. Les états, calculs, taxes, délais et responsabilités doivent être adaptés aux plateformes, prestataires et règles applicables au vendeur.
Recetter les chemins qui ne suivent pas le nominal
Provoquer les erreurs avant qu’elles touchent le paiement
La recette ne se limite pas à un retour accepté puis remboursé. Elle envoie d’abord un webhook de réception avant l’autorisation, rejoue la demande, retire une unité du colis et modifie le motif après le contrôle. Chaque événement doit produire un état explicable sans effet financier inattendu.
Un test force ensuite le timeout du prestataire juste après l’acceptation du remboursement. Le worker redémarre, recherche l’opération par sa clé et constate son résultat avant toute nouvelle tentative. Par exemple, une réponse tardive ne doit jamais être interprétée comme l’autorisation de créer un second mouvement.
La finance injecte aussi un avoir manuel déjà comptabilisé. Le plafond remboursable et le rapprochement doivent signaler l’écart avant l’automatisation. Le dossier conserve la compensation externe avec son auteur, son montant et sa justification plutôt que de la faire disparaître dans un ajustement de solde.
Faire reprendre le dossier par une autre équipe
Une personne qui n’a pas conçu le flux reçoit un dossier incomplet. Elle doit retrouver la vente, les unités, les événements, le mouvement de paiement et l’avoir, puis choisir la prochaine action. Ses hésitations révèlent les identifiants invisibles, droits absents et instructions trop implicites.
Le scénario se termine par une panne de l’ERP alors que le client est déjà remboursé. La reprise maintient la vérité du paiement, met l’écriture en file et alerte son propriétaire. Elle ne rouvre ni le retour ni le stock pour obtenir artificiellement des écrans verts.
La campagne est versionnée et rejouée à chaque modification de mapping, de calcul ou de moyen de paiement. Les résultats attendus couvrent états, montants, écritures et stock. Une différence non expliquée bloque le périmètre concerné, même si le parcours principal reste fonctionnel.
Éviter les compensations irréversibles
Cinq raccourcis qui empêchent la convergence
Passer toute la commande en retournée. Les lignes conservées perdent leur vérité et peuvent être remboursées par erreur.
Recalculer au prix actuel. La vente historique, ses remises et taxes sont la base opposable du calcul.
Renvoyer l’appel après un timeout. Sans recherche ni clé idempotente, l’incertitude devient un doublon financier.
Fermer les états physiques et financiers
Remettre en stock à la réception. L’état qualité et les accessoires restent inconnus jusqu’au contrôle.
Clôturer sur le statut marketplace. Paiement, ERP, stock et commission doivent également disposer d’un verdict final rapproché.
Plan d’action : industrialiser le retour partiel
Construire une chaîne réversible avant d’automatiser
Le pilote commence par les motifs et canaux les plus fréquents, avec une machine à états assez précise pour prouver chaque effet. Les exceptions rares restent manuelles mais utilisent les mêmes identifiants et journaux.
- D’abord, modéliser : définir retour, ligne, unité, états, autorités, motifs et sources de vérité. Conserver les identifiants de tous les systèmes.
- Ensuite, calculer : rejouer ventes historiques, remises, frais, taxes et remboursements précédents. Valider arrondis et plafond avec finance.
- Puis, intégrer : séparer décision et effet, ajouter idempotence, gestion du désordre, files d’erreur et contrôle qualité avant stock.
- Enfin, rapprocher : tester événements rejoués et effets partiels, puis fermer seulement après convergence commande, paiement, ERP, stock et plateforme.
Le dossier de production contient transitions autorisées, formule versionnée, clés, délais, alertes, droits, modèles clients et procédure de reprise. Le support peut observer et escalader sans disposer d’un bouton qui contourne tous les contrôles.
Les entrées de webhook, les sorties financières, les responsabilités, les dépendances ERP et la journalisation sont testées avec leurs seuils. Une file d’erreur retient chaque échec ; le rollback suspend l’automatisme tout en conservant les mouvements déjà confirmés.
Valider la reprise financière et l’escalade
Un second passage contrôle le contrat de retry, l’idempotence et la traçabilité de bout en bout. La responsabilité de reprise reste nominative ; son seuil d’escalade déclenche le repli avant qu’une file bloquée ne soit contournée par le support.
La recette utilise des commandes représentatives, plusieurs quantités, remises panier, frais, paiements et états logistiques. Elle vérifie aussi la suppléance : une personne différente doit comprendre le solde et reprendre un échec sans correction directe en base.
Après lancement, les écarts réels améliorent le modèle. Une nouvelle politique de canal ou un nouveau moyen de paiement entre par un contrat testé, pas par une condition cachée. La vitesse de remboursement progresse sans sacrifier l’auditabilité.
- Automatiser les transitions stables et réconciliables.
- Examiner toute inconnue avant un effet financier.
- Replier si le système ne peut plus garantir l’unicité ou expliquer le solde.
Approfondir commandes, litiges et cash
Conserver une chronologie commune
L’analyse du litige transport après remboursement prolonge le rapprochement lorsqu’une indemnisation arrive après le geste client.
L’article consacré à la centralisation des commandes dans un OMS marketplace aide à choisir les vérités et identifiants.
Surveiller les effets qui restent ouverts
La méthode des alertes marketplace sur commandes, litiges et cash permet d’attribuer les divergences au bon responsable.
Le runbook vendeur en cas de panne majeure prépare le repli lorsque paiement ou canal cesse de confirmer les effets.
Sources officielles et limites
La documentation Stripe sur les annulations et remboursements partiels décrit notamment le remboursement de tout ou partie d’un paiement et ses états. L’implémentation dépend du prestataire et des moyens de paiement du vendeur.
La page officielle Your Europe sur les retours et le droit de rétractation rappelle le délai applicable aux achats à distance et certaines exceptions. Une analyse juridique reste nécessaire selon produit, motif et pays.
Les montants, seuils, délais et scénarios sont illustratifs. Cette méthode n’établit ni calcul fiscal universel ni conseil juridique. Finance, comptabilité et juridique doivent valider le contrat réel.
Conclusion : prouver le solde final
Un retour partiel est réussi lorsque chaque unité, euro et écriture possède un état final explicable. La granularité par ligne, l’idempotence et le rapprochement empêchent qu’une réponse rapide au client crée une dette cachée dans le stock ou la comptabilité.
Commencez par rejouer vos dossiers les plus difficiles : remises panier, deux colis, événement dupliqué et remboursement en attente. Si une autre personne peut retrouver le calcul et reprendre l’effet sans improviser, la chaîne est prête à être étendue.
Si vos retours reposent encore sur des statuts globaux ou des corrections manuelles, Dawap peut vous accompagner pour fiabiliser le run marketplace, de l’événement de ligne jusqu’au rapprochement paiement, ERP et stock.
