Réponse directe
ERP-STOK distingue shipment_type normal et exchange. Un échange lie le nouvel envoi à exchange_old_tracking / exchange_old_order_id (un ancien tracking ne doit pas être réutilisé deux fois). Le payload transporteur varie (ex. Coliaty package_old_tracking ; Truship context d’échange). Le stock du nouvel envoi suit le ramassage ; la restauration de l’ancien dépend du scan/validation retour — pas d’un double crédit anticipé. Le support n’est pas identique pour tous les transporteurs.
Normal vs exchange
Un envoi normal n’a pas d’ancien tracking lié.
Un envoi exchange enregistre l’ancien suivi et l’ancien order id pour tracer le remplacement et éviter qu’un même ancien colis serve deux fois d’échange.
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, forcer le flag dans ERP-STOK ne crée pas magiquement la capacité transporteur.
| Élément | Rôle |
|---|---|
| shipment_type = exchange | Marque l’envoi comme remplacement |
| exchange_old_tracking | Lien vers l’ancien colis |
| Contrôle already used | Empêche de réutiliser le même ancien tracking |
| Scan retour | Peut matcher tracking ou exchange_old_tracking |
Stock : éviter restauration prématurée ou double
Le nouvel envoi déduit au ramassage comme un envoi normal (tracking du nouveau colis).
L’ancien colis doit suivre le flux retour (pending scan → validation). Restaurer trop tôt ou deux fois crée un stock fictif.
Les écrans de scan retour peuvent résoudre aussi sur exchange_old_tracking pour retrouver la bonne commande.
- Identifier l’ancienne commande avec tracking valide.
- Créer / confirmer le remplacement en type exchange lié à l’ancien tracking.
- Vérifier que le transporteur choisi supporte l’échange.
- Envoyer le nouveau colis ; attendre ramassage pour la déduction du neuf.
- Scanner / valider le retour de l’ancien avant de considérer le stock restauré.
Exemple opérationnel
Client reçoit taille M (tracking A), veut L. L’équipe crée un envoi exchange lié à A, transporteur qui accepte l’ancien tracking. Nouveau tracking B part ; stock de L baisse au ramassage de B. Le retour de A est scanné en entrepôt puis validé → restauration M. On ne restaure pas M au seul statut « échange créé ».
Limites et points d’attention
- Support d’échange non identique pour chaque transporteur.
- Mauvaise sélection d’ancien tracking ou double usage est bloquée côté validation métier.
- Ce guide ne modifie pas la logique stock/retour/delivery.