Sommaire
Réponse directe
ERP-STOK distingue shipment_type normal et exchange. Un échange enregistre exchange_old_tracking et exchange_old_order_id pour lier le remplacement et empêcher la réutilisation du même ancien tracking. Le payload transporteur varie (ex. Coliaty package_old_tracking ; Truship contexte exchange) — le support n’est pas identique d’un transporteur à l’autre, ni universel. Le stock du nouvel envoi baisse au ramassé (pickup) du nouveau tracking ; la restauration de l’ancien article intervient après scan puis validation retour, pas à la création de l’échange ni au seul statut provider. Les écrans scan retour peuvent résoudre sur tracking_number ou exchange_old_tracking.
Normal vs exchange (shipment_type)
Un envoi normal (shipment_type normal) n’a pas d’ancien tracking lié : déduction stock au ramassé du nouveau colis uniquement.
Un envoi exchange enregistre exchange_old_tracking (suivi du colis remplacé) et exchange_old_order_id (commande d’origine) pour tracer le remplacement.
Un contrôle métier empêche de réutiliser le même exchange_old_tracking pour deux échanges distincts.
Support transporteur : pas universel
ConfirmationController construit des payloads différents selon l’intégration. Coliaty peut recevoir package_old_tracking. Truship accepte un contexte exchange_old_tracking pour certains types d’envoi.
Si un prestataire ne gère pas l’échange côté API, cocher exchange dans ERP-STOK ne crée pas la capacité transporteur — vérifiez l’intégration configurée et disponible sur le compte.
En cas de prestataire sans support échange, l’ops peut traiter retour + nouvel envoi normal séparément, avec rigueur sur le scan retour de l’ancien colis.
| Élément | Rôle |
|---|---|
| shipment_type = exchange | Marque l’envoi comme remplacement lié à un ancien colis |
| exchange_old_tracking | Suivi du colis retourné / remplacé — transmis au carrier si supporté |
| exchange_old_order_id | Référence commande d’origine pour traçabilité |
| Contrôle « already used » | Bloque la réutilisation du même ancien tracking |
| Support API carrier | Variable — Coliaty, Truship partiellement ; autres selon intégration |
Scan retour : résolution tracking ou exchange_old_tracking
Les écrans de scan session retour associent le colis physique à la commande. La résolution accepte le tracking_number principal ou exchange_old_tracking — utile quand le colis scanné porte l’ancien suivi d’un échange.
Le scan seul n’augmente pas le stock : c’est la validation post-scan qui déclenche la restauration via le workflow retour / DeliverySaleService.
Ne confondez pas le statut transporteur « retourné » (sync polling) avec un retour entrepôt validé — voir guide retour signalé sans stock restauré.
Stock : neuf au ramassé, ancien après validation
Le nouvel envoi exchange déduit au ramassage/pickup du nouveau tracking_number — même règle qu’un envoi normal (DeliverySaleService).
La création de l’échange ou l’envoi API ne déduit pas le stock du remplacement : attendez le signal ramassé du nouveau colis.
L’ancien colis doit suivre return_pending_scan → scan → validation. Restaurer l’ancien article avant validation crée un stock fictif ; restaurer deux fois aussi.
Ordre typique sain : ramassage neuf (stock variante neuve −1) → retour physique ancien → scan + validation (stock variante ancienne +1).
- Identifier la commande d’origine et son tracking_number valide.
- Créer l’envoi shipment_type exchange avec exchange_old_tracking et exchange_old_order_id.
- Vérifier que le transporteur choisi supporte l’échange côté API.
- Envoyer le nouveau colis ; attendre ramassage pour la déduction du neuf.
- À réception de l’ancien colis : scanner (tracking ou exchange_old_tracking) puis valider pour restaurer l’ancien.
Exemple fictif
Exemple opérationnel
Client reçoit taille M (tracking A, order #1204), veut L. L’équipe crée un envoi exchange : exchange_old_tracking = A, exchange_old_order_id = 1204, transporteur Coliaty (package_old_tracking). Nouveau tracking B part ; stock L baisse au ramassé de B uniquement. L’ancien colis A arrive : scan session résout sur A → validation → restauration M. Entre ramassage de B et validation de A, le stock affiché peut sembler « bas » sur M et « déjà sorti » sur L — c’est normal tant que l’ancien n’est pas validé.
Limites et points d’attention
- Support d’échange non identique pour chaque transporteur — pas de promesse universelle.
- exchange_old_tracking déjà utilisé est bloqué côté validation métier.
- Restauration ancien article uniquement après scan + validation — pas au statut provider seul.
- Ce guide ne modifie pas la logique stock/retour/delivery.