Périmètre

API

📘

NEW

Buying Policies

• Contrôle d’activation de la policy de contrôle d’encours:

Deux nouveaux endpoints ont été ajoutés au module Buying Policies, permettant aux utilisateurs opérateurs de consulter et modifier l’état global de la policy de contrôle d’encours sur la plateforme.

⚠️

Attention

Ces routes de gestion des buying policies ne sont disponibles que pour les utilisateur BackOffice opérateurs.

• Consultation du statut de la policy d’encours :

ADM-BUYING-POLICY-500 - GET /v1/buying-policies/credit-control

Permet de récupérer l’état d’activation actuel de la policy de contrôle d’encours ainsi que la limite de crédit par défaut.

Exemple de réponse :

{
  "status": "ACTIVE",
  "creditLimit": 10000,
  "updatedAt": "2025-06-06T14:15:22Z"
}

• Activation / désactivation de la policy d’encours :

ADM-BUYING-POLICY-200 - PATCH /v1/buying-policies/credit-control

Permet d’activer ou de désactiver globalement l’application de la policy (ACTIVE ou INACTIVE).

Contenu de la requête :

{
  "status": "INACTIVE"
}

🗒️

Notes

ℹ️ Lorsque la policy est en statut INACTIVE, les commandes ne sont plus bloquées en cas de dépassement d’encours.
⚠️ Par défaut, la policy est désactivée (INACTIVE) dans les environnements nouvellement initialisés.

• Définition d’une limite de crédit par défaut:

La policy de contrôle d’encours peut désormais s’appuyer sur une valeur de crédit par défaut, configurable globalement depuis l’API d’administration. Cette valeur s’applique à tous les comptes clients qui n’ont pas de limite de crédit personnalisée définie. Deux endpoints sont disponibles :

• Consultation de la configuration de la policy d’encours:

Cf. ci-dessus, il s'agit de la même route ADM-BUYING-POLICY-500

ℹ️ Si un account ne dispose pas de limite de crédit spécifique, c’est la valeur par défaut qui est utilisée pour valider les commandes.
Si un account possède un crédit personnalisé (via un champ custom), cette valeur surcharge celle par défaut.

• Mise à jour de la limite de crédit par défaut:

ADM-BUYING-POLICY-201 - PATCH /v1/buying-policies/credit-control/credit-limit

Permet de modifier la valeur globale appliquée aux comptes sans configuration individuelle.

Contenu de la requête :

{
  "creditLimit": 15000
}

⚠️ La valeur transmise doit être supérieure ou égale à 0.
⚠️ Par défaut, la valeur initiale est 0 lors de la création d’un nouvel environnement.

Accounts

• Nouvelle structure de configuration des encours via des champs custom des comptes clients:

Les éléments de définition de l’encours sont désormais portés par des Custom Fields associés aux comptes clients (Customer Accounts). Cette évolution permet de rendre la gestion plus flexible, centralisée et pilotable via les APIs d’Account Management (et prochainement le BackOffice Djust).

⚠️

Attention

Contrairement à la logique actuelle, un Custom Field associé à un rôle n’est plus automatiquement requis : la mécanique de validation a été assouplie.

• Ces champs sont utilisés par la buying policy d’encours lors de la validation des commandes.
• La logique de validation distingue clairement les valeurs personnalisées (au niveau du compte) et les valeurs par défaut (définies globalement).
• La valeur du crédit disponible est désormais calculée dynamiquement selon la formule suivante :

🔎

crédit disponible = (limite crédit - encours) + tolérance

• En cas d’absence de valeur dans les champs "Limite de crédit" ou "Encours", la logique applique :
  • la valeur par défaut (buying policy) pour la limite,
  • un blocage de sécurité si l’encours est inconnu, pour éviter tout risque de dépassement.
• Les valeurs des champs "Limite de crédit" et "Encours" doivent être synchronisées régulièrement via les jobs de Data Hub.
• Aucun fetch temps réel depuis les ERP n’est prévu pour cette première version.