Périmètre

Back Office

• Revue des lignes de prix et ajout du prix remisé dans l'affichage des lignes de prix d'une offre :

Le champ quantité min n’est plus bloqué et lié au champ articles par lot.

• Dans le cas d’un prix par unité, la notion d'articles par lot n’existe pas.

• Dans le cas d’un prix par lot, la valeur d'articles par lot n’est pas égale à la valeur de quantité min

  

• Ajouts des nouveaux rôles pour la gestion du flux cartes achats niveau 3 :

Deux nouveaux rôles distincts sont ajoutés pour le flux cartes achats niveau 3.

• Rôle identifiant de marché à l'account :

  Le rôle MARKET_ID est associé à un custom field à l'account de type TEXT. Il est disponible dans l'interface de configuration des rôles.

  

• Rôle identifiant d'engagement :

  Le rôle ENGAGEMENT_ID est associé à un custom field à la commande commerciale de type TEXT. Il est disponible dans l'interface de configuration des rôles.

  
  

API

📘

NEW

Orders

• Consultation des informations de paiement d’une commande logistique :

Contexte

Une nouvelle route d’administration permet désormais aux opérateurs et fournisseurs autorisés de consulter les métadonnées de paiement associées à une commande logistique.

L’objectif : offrir un accès rapide et lisible au provider, au mode de paiement et au statut du cycle de paiement, sans jamais exposer d’informations sensibles.

Fonctionnement métier

> Ce que retourne la route

Uniquement 3 champs métier, strictement limités à l’information de paiement :

• provider - prestataire utilisé (ex. DJUST_PAY, LEMONWAY, MANGOPAY)
• option - option / méthode de paiement (ex. CREDIT_CARD, BANK_WIRE, PURCHASE_CARD_L3, etc.)
• status - statut du paiement selon le référentiel interne Djust (ex. PAID, AUTHORIZED, WAITING_PAYMENT, REFUND_FAILED…)

Aucune donnée de commande, aucune donnée sensible → exposition minimale et conforme PCI.

L'API est la suivante :

ADM-ORDER-500 - GET /v1/logistic-orders/{logisticOrderId}/payment-information

{
  "provider": "DJUST_PAY",
  "option": "CREDIT_CARD",
  "status": "PAID"
}

👍

UPDATE

Incidents

• Filtrage par motif d’incident :

Afin de pouvoir réduire le nombre d’incidents à traiter en front et de faciliter la recherche, un filtre par motif d’incident est ajouté.

Il fonctionne de la même manière que le filtre customerAccountIds, il s'agit d'une liste d'id de reasons passées en query param sur la route ORDER-559 - GET /v1/shop/incidents.

Le param reasonCodes ajouté prendra en entrée une liste d’ID de reasons et fonctionne via un OU logique entre chaque valeur.

• Tri des incidents par fournisseur :

Contrairement au filtre par fournisseur, le tri par fournisseur doit s’appliquer sur le nom du fournisseur via la route ORDER-559 - GET /v1/shop/incidents.

Ainsi la possibilité de trier sur les noms des fournisseurs se fait désormais avec le sort suivant :

• supplierName:asc ou supplierName:desc qui trient respectivement les incidents par noms de fournisseurs dans l’ordre croissant (A > Z) et décroissant (Z > A).

Buying Policies

• Refus / abandon d’une commande logistique en statut BLOCKED_BY_POLICY par un opérateur

Contexte

Historiquement, seule une logique “fournisseur” permettait de refuser une commande logistique, et uniquement lorsqu’elle était en attente de traitement (ORDER_CREATED, WAITING_SUPPLIER_APPROVAL). Avec l’arrivée des buying policies (encours, quotas), certaines commandes peuvent désormais rester bloquées très tôt dans leur cycle, au statut BLOCKED_BY_POLICY.

Pour permettre un abandon explicite dans ces situations, la route de decline est étendue : • NEW Les opérateurs peuvent désormais refuser une commande bloquée par une buying policy. • Les fournisseurs conservent leur comportement historique. • Les customer users (ACCOUNT) ne peuvent jamais utiliser cette action.

La route API mise à jour :

• ADM-ORDER-200 - PUT /v1/logistic-orders/{logisticOrderId}/decline

L'action dans le backoffice sera disponible prochainement