Périmètre

🛠️ API

Historique des remboursements d'une commande logistique

Contexte

Le back-office doit pouvoir afficher, sur la page détail d'une commande, l'historique détaillé des remboursements effectués. Jusqu'ici, l'API permettait d'initier un remboursement mais aucun endpoint n'exposait la liste des remboursements d'une commande logistique.

Fonctionnement

Un nouvel endpoint retourne la liste paginée et chronologique des remboursements d'une commande logistique. Chaque remboursement expose son identifiant, sa date de création et d'exécution, son montant et sa devise, la raison saisie à l'initiation (reasonCode), son mode (complet ou partiel par montant), son statut, ainsi que la référence PSP et le motif d'échec le cas échéant.

En complément, la raison (reasonCode) fournie lors d'un remboursement complet est désormais persistée, comme c'était déjà le cas pour les remboursements partiels. Une raison saisie est ainsi conservée et restituée dans l'historique quel que soit le mode de remboursement. Le champ reste optionnel : un remboursement sans raison continue de fonctionner à l'identique.

Impact API

GET /v1/logistic-orders/{logisticOrderId}/refunds (operationId : ADM-ORDER-553) — nouvel endpoint réservé aux opérateurs (dj-client: OPERATOR)

• Réponse paginée (page, size, sort)
• idType : DJUST_ID (défaut) ou EXTERNAL_ID

POST /v1/logistic-orders/{logisticOrderId}/refunds (operationId : ADM-ORDER-100) — le champ optionnel reasonCode est désormais persisté également en mode remboursement complet (contrat inchangé).

📄 Documentation : Refunds

👉 Côté métier : les opérateurs disposent d'un historique complet et traçable des remboursements d'une commande — montants, dates, raisons, statuts — directement depuis la page détail commande.

👉 Côté technique : nouvel endpoint GET /v1/logistic-orders/{logisticOrderId}/refunds (ADM-ORDER-553) et persistance du reasonCode pour les remboursements complets sur ADM-ORDER-100.

Checkout V3 — Distinction du prix initial et du prix remisé

Contexte

Dans le tunnel d'achat Checkout V3, le front ne pouvait pas distinguer le prix initial du prix remisé d'une ligne : en l'absence de remise, le prix remisé était renseigné avec le prix normal. Les deux valeurs étant toujours présentes et identiques sans remise, il était impossible d'afficher un prix barré à côté du prix remisé lorsqu'un acheteur bénéficiait d'une réduction.

Fonctionnement

Le prix remisé n'est désormais renseigné que lorsqu'une remise s'applique réellement :

• ligne sans remise — le prix remisé est vide ; seul le prix initial est renseigné, l'absence de remise devient explicite
• ligne avec remise — le prix initial et le prix remisé sont tous deux renseignés, même lorsque les montants sont identiques

Le comportement est identique sur tous les écrans où un prix de ligne est présenté à l'acheteur : panier, tunnel d'achat, récapitulatif avant validation, confirmation de commande et historique. Le calcul des remises et des totaux est inchangé, sans régression sur les lignes sans remise dans le reste de la chaîne (totaux, commande).

Impact API

Réponses des routes du tunnel d'achat Checkout V3 : le champ de prix remisé des lignes n'est plus renseigné en l'absence de remise (auparavant, il reprenait la valeur du prix initial). Action requise : les fronts qui affichaient systématiquement le prix remisé doivent prévoir un repli sur le prix initial lorsque le prix remisé est vide.

👉 Côté métier : les acheteurs bénéficiant d'une remise peuvent enfin la visualiser dans leur panier et tout au long du tunnel d'achat, avec le prix initial barré à côté du prix remisé.

👉 Côté technique : le prix remisé des lignes Checkout V3 est vide en l'absence de remise ; prévoir un repli sur le prix initial côté front.