Périmètre
BackOffice Djust
Possibilité de suppression d'un utilisateur opérateur :
Il est désormais possible de supprimer un utilisateur opérateur directement depuis le BackOffice Djust.
- Depuis la page de détail d’un opérateur
- Depuis le listing des opérateurs
API
NEW
Buying Policies
- Validation des commandes et blocages par quota
Contexte :
Une nouvelle buying policy de quotas permet désormais de bloquer les commandes tant que la quantité minimum attendue par fournisseur (univers) et par compte client n’est pas atteinte.
Cette règle complète la validation des commandes déjà existante (encours, validation manuelle). Elle vise à optimiser la préparation logistique en regroupant des volumes suffisants avant expédition.
- Chaque commande est vérifiée individuellement par rapport au quota défini.
- Il n’y a pas de cumul entre plusieurs commandes pour atteindre le quota : chaque commande doit respecter le seuil minimum seule.
- Le blocage est appliqué au niveau de la commande : si le quota n’est pas atteint, le statut passe en
BLOCKED_BY_POLICY. - Une commande bloquée peut être validée manuellement par un opérateur ou revalidée automatiquement à la prochaine exécution du job de validation (si les conditions sont remplies).
Fonctionnement :
- Ordre de validation des commandes :
- Policy d’encours
- Policy de quotas
- Validation manuelle (policy historique)
- Règles appliquées :
- Si un quota spécifique existe pour le couple Account × Supplier, c’est cette valeur qui s’applique.
- Sinon, on utilise la valeur par défaut définie au niveau du Supplier (via un Custom Field + rôle).
- Si rien n’est configuré, c’est la valeur globale de la buying policy qui est utilisée.
- Si aucune configuration n’est trouvée, la commande est bloquée par défaut.
- Cas de validation :
- Quantité de la commande
<quota→ commande bloquée (BLOCKED_BY_POLICY). - Quantité de la commande
≥quota→ workflow continue vers les autres policies, puis passage enWAITING_SUPPLIER_APPROVAL.
- Quotas minimums spécifiques par Account x Supplier
Contexte :
Les opérateurs peuvent désormais définir des quotas minimums spécifiques pour chaque couple Customer Account × Supplier.
Ces règles surchargent la valeur globale de la policy de quotas ainsi que la valeur éventuellement définie au niveau Supplier.
Objectif : refléter les accords commerciaux au plus fin, débloquer/bloquer des commandes de façon ciblée et piloter les comportements d’achat par fournisseur.
Fonctionnement métier :
- Priorité des valeurs : Account × Supplier > Supplier > valeur globale de la policy.
- Une commande est bloquée si les quantités commandées sont
< minQuotaValuedéfini pour le couple concerné. - En l’absence de configuration Account × Supplier, le système retombe sur le quota Supplier, puis sur la valeur globale.
- La suppression d’une règle spécifique prend effet immédiatement (retombée sur Supplier/global).
APIs correspondantes :
Quatre APIs ont été ajoutées pour gérer ces quotas spécifiques.
➕ Créer des règles Account × Supplier (bulk)
ADM-BUYING-POLICY-152 - POST /v1/buying-policies/quotas/rules
[
{ "customerAccountId": "acc-123", "supplierId": "sup-456", "minQuotaValue": 1500 }
]🔎 Lister / filtrer les règles spécifiques
ADM-BUYING-POLICY-553 - GET /v1/buying-policies/quotas/rules
Query params (tous external ids) :
- customerAccountIds (array)
- supplierIds (array)
✏️ Mettre à jour une règle spécifique
ADM-BUYING-POLICY-206 - PUT /v1/buying-policies/quotas/rules/{ruleId}
{ "minQuotaValue": 1200 }🗑️ Supprimer une règle spécifique
ADM-BUYING-POLICY-302 - DELETE /v1/buying-policies/quotas/rules/{ruleId}
- Groupes de co-validation de quotas (Account × Supplier)
Contexte :
Il est désormais possible de lier plusieurs règles de quotas (couples Customer Account × Supplier) dans un groupe de co-validation.
Objectif : valider ou bloquer les commandes ensemble — si au moins un fournisseur du groupe ne respecte pas son quota, toutes les commandes du groupe sont bloquées.
Le contrôle s’exécute au moment de la validation des commandes lorsque celles-ci sont vérifiées par les Buying Policies.
Fonctionnement métier :
- Périmètre d’un groupe : un même account et ≥ 2 suppliers distincts.
- Aucune addition de seuil : chaque supplier conserve son quota propre (priorité : Account×Supplier > Supplier > global). Le groupe impose la validation conjointe.
- Co-validation stricte : si une commande d’un supplier du groupe n’atteint pas son quota, toutes les commandes du groupe passent en
BLOCKED_BY_POLICY. - Absence de pair : si au cut-off il n’existe pas encore de commande pour un des suppliers du groupe, les autres commandes du groupe sont bloquées. Dès qu’une commande éligible apparaît pour le supplier manquant (et respecte les critères), la revalidation déverrouille l’ensemble.
APIs correspondantes :
Quatre APIs ont été ajoutées pour gérer ces quotas spécifiques.
➕ Créer un groupe de co-validation
ADM-BUYING-POLICY-153 - POST /v1/buying-policies/quotas/groups
{
"quotaRuleIds": ["qr-001", "qr-002"]
}🔎 Lister les groupes
ADM-BUYING-POLICY-554 - GET /v1/buying-policies/quotas/groups
[
{
"id": "qgroup-001",
"quotaRuleIds": ["qr-001","qr-002"],
"createdAt": "2025-08-02T10:00:00Z",
"updatedAt": "2025-08-02T10:00:00Z"
}
]✏️ Mettre à jour un groupe
ADM-BUYING-POLICY-207 - PUT /v1/buying-policies/quotas/groups/{groupId}
{ "quotaRuleIds": ["qr-001","qr-005","qr-006"] }🗑️ Supprimer un groupe
ADM-BUYING-POLICY-303 - DELETE /v1/buying-policies/quotas/groups/{groupId}
- Récupération des raisons de blocage des commandes
Contexte :
Les opérateurs peuvent désormais identifier les raisons pour lesquelles une ou plusieurs commandes sont bloquées par les buying policies.
L’objectif est de faciliter le diagnostic et d’accélérer les actions correctives ou validations manuelles, sans surcharger les réponses de l’API Orders.
Fonctionnement métier :
- Le nouvel endpoint dédié permet de lister les policies responsables d’un blocage pour chaque commande logistique.
- Une commande peut être bloquée par plusieurs policies ; pour la version actuelle, seule la raison courante est remontée.
API correspondante :
🔍 Récupération des raisons de blocage
ADM-BUYING-POLICY-552 - GET /v1/buying-policies/blocking-reasons
{
"blockingReasons": [
{
"logisticOrderId": "ORD-001",
"blockingPolicies": [
{
"type": "MANUAL_VALIDATION",
"id": "BP-MANUAL-001"
}
]
},
{
"logisticOrderId": "ORD-002",
"blockingPolicies": []
}
]
}Opérations
- Consultation du détail d'une Opération
Contexte :
Les Opérations (campagnes commerciales, actions marketing ou opérationnelles) peuvent désormais être consultées individuellement via un nouvel endpoint.
Cette évolution permet :
- aux opérateurs de la plateforme de consulter n’importe quelle opération existante sans restriction,
- aux customer users habilités d’accéder uniquement aux opérations qu’ils possèdent (
ownerId = customerUserId), à condition d’avoir le droitOPERATIONS_READactif et d’être rattachés au store concerné.
⚠️ Le feature flag OPERATIONS doit être activé pour que la route soit disponible.
Fonctionnement métier :
- Opérateur : visibilité complète, quel que soit le store ou l’owner.
- Customer User :
- doit être owner de l’opération,
- doit disposer du droit
OPERATIONS_READ = true, - doit être rattaché au store concerné (ou au store par défaut du tenant si aucun n’est précisé).
API correspondante :
🔍 Récupération du détail d’une opération
ADM-OPERATION-500 - GET /operations/{operationId}
{
"id": "ope_001",
"externalId": "SUMMER_OPE_0825",
"names": {
"en-GB": "Summer Operation · Fine Food",
"fr-FR": "Opération Été · Produits raffinés"
},
"descriptions": {
"en-GB": "Seasonal operation focused on gourmet product sales",
"fr-FR": "Opération saisonnière axée sur les produits gastronomiques"
},
"status": "ACTIVE",
"type": "PRIVATE",
"startDate": "2025-11-21T00:00:00Z",
"endDate": "2025-11-28T23:59:59Z",
"createdAt": "2025-08-04T12:34:56Z",
"updatedAt": "2025-08-05T10:00:00Z",
"ownerId": "usr_987",
"ownerFirstName": "Alice",
"ownerLastName": "Durand",
"customFieldValues": []
}
UPDATE
Orders
- Visualisation des commandes bloquées
Contexte :
Les opérateurs peuvent désormais filtrer et visualiser les commandes bloquées par une ou plusieurs buying policies.
L’objectif est de faciliter le suivi des commandes en anomalie, de comprendre rapidement la nature du blocage (encours, quota, validation manuelle) et d’orienter leur traitement.
Trois cas sont couverts :
- Récupérer toutes les commandes bloquées par au moins une buying policy
- Récupérer les commandes bloquées uniquement par un type de buying policy
- Récupérer les commandes bloquées par la validation manuelle d’un autre utilisateur (buying policies historiques)
Fonctionnement métier :
- Une commande est considérée comme bloquée si elle est au statut
BLOCKED_BY_POLICYouWAITING_CUSTOMER_APPROVAL. - Les filtres permettent de :
- Lister uniquement les commandes bloquées (
blockedByBuyingPolicy = true) - Restreindre la recherche à certains types de policies (
blockingPolicyTypes) :CREDIT_CONTROLQUOTAMANUAL_VALIDATION
- Lister uniquement les commandes bloquées (
- Les valeurs du filtre
blockingPolicyTypesfonctionnent en OU : une commande est incluse si elle correspond à au moins une des policies listées. - ⚠️ Le filtre
blockingPolicyTypesn’est appliqué que siblockedByBuyingPolicy = true. Sinon, il est ignoré.
API correspondante :
ADM-ORDER-551 - POST /v1/logistic-orders
Exemples :
{
"blockedByBuyingPolicy": true
}{
"blockedByBuyingPolicy": true,
"blockingPolicyTypes": ["CREDIT_CONTROL"]
}{
"blockedByBuyingPolicy": true,
"blockingPolicyTypes": ["MANUAL_VALIDATION"]
}
