Retour (return)
Dossier durable d’un retour client : il conserve ce qui a été demandé, autorisé, physiquement expédié, reçu et inspecté, puis la résolution commerciale finale et les objets créés pour l’appliquer.
Rôle
Un return concerne exactement une commande et son acheteur. Il ne remplace ni l’avoir, ni le remboursement, ni le processus qui orchestre le traitement. Son rôle est de conserver le dossier métier du retour et les faits successifs qui doivent rester consultables après la fin du processus.
Deux axes à ne pas confondre
| Axe | Champ / faits | Question |
|---|---|---|
| Cycle du dossier | status : open, resolved, cancelled | Le dossier est-il encore actif ? |
| Résolution commerciale | resolution_status : pending, accepted, partially_accepted, rejected, withdrawn | Quelle part de la demande le marchand accepte-t-il finalement ? |
| Faits physiques | quantités autorisées, reçues, acceptées + timestamps | Que s’est-il réellement passé sur les marchandises ? |
Cette séparation permet par exemple d’avoir un dossier encore open alors que certaines lignes ont déjà été reçues, ou de résoudre un retour en partially_accepted lorsque seule une partie des quantités inspectées est retenue commercialement.
Cycle opérationnel
Le graphe montre le parcours opérationnel usuel. Les dates authorized_at, shipped_at, received_at et inspected_at conservent les jalons physiques ; la résolution commerciale intervient explicitement à la fin.
Le retour naît avec les lignes demandées et leurs motifs. Il peut ensuite être autorisé, associé à une expédition retour, enregistré comme reçu puis inspecté. Le processus peut omettre une étape seulement si son parcours métier le permet ; il ne doit pas inventer un fait physique qui ne s’est pas produit.
Une quantité différente à chaque étape
Chaque return_item peut porter plusieurs quantités afin de ne pas écraser l’histoire du dossier :
| Quantité | Signification | Étape |
|---|---|---|
quantity_requested | Quantité demandée par l’acheteur. | Création du retour. |
quantity_authorized | Quantité autorisée à être retournée. | authorize_return |
quantity_received | Quantité physiquement reçue. | receive_return |
quantity_accepted | Quantité acceptée après inspection. | inspect_return |
Les nodes qui créent les avoirs ou finalisent le retour utilisent un quantity_basis explicite :requested, authorized, received ou accepted. Ormuz vérifie que le jalon choisi existe réellement et qu’aucune quantité utilisée ne dépasse la quantité initialement demandée.
Résolution commerciale
finalize_return ferme le dossier avec une résolution finale : accepted, partially_accepted,rejected ou withdrawn. Le résultat doit être cohérent avec les quantités retenues pour la base choisie.
- accepted — la quantité de référence est acceptée intégralement.
- partially_accepted — seule une partie de cette quantité est acceptée.
- rejected — aucune quantité n’est acceptée commercialement.
- withdrawn — la demande est retirée sans résolution normale.
resolution_detail peut expliquer le résultat et related_objects relie explicitement les objets créés pour l’appliquer : avoir, remboursement, commande de remplacement ou pièce documentaire.
Avoirs et remboursements
create_return_credit_note_drafts transforme les quantités retenues en propositions d’avoirs contre les factures sources. Les avoirs restent des objets de facturation distincts.
Si la vente avait déjà été payée, un remboursement PSP ou bancaire peut ensuite être créé à partir des avoirs et des paiements réellement alloués. Le retour ne doit donc pas fabriquer lui-même un mouvement de cash : il expose le fait commercial qui justifie les étapes financières.
Dans un processus
Les Core nodes couvrent le lifecycle sans enfermer le parcours dans une UX unique :
create_return— ouvre le dossier et les lignes demandées.collect_return_authorization+authorize_return— collecte puis persiste l’autorisation.record_return_shipment— enregistre transporteur, tracking et étiquette facultative.collect_return_receipt+receive_return— enregistre les quantités reçues.collect_return_inspection+inspect_return— enregistre l’acceptation physique et l’état des articles.finalize_returnoucancel_return— termine le dossier.
Événements
Le lifecycle est observable à travers les événements plateforme :
return.created → return.authorized → return.shipped → return.received → return.inspected → return.resolved, avec return.cancelled comme fin alternative.