Release Notes
Start typing to search…
Back to All

Djust 3.82.0 - Semaine du 08 Sept 2025

about 2 months ago

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 :

  1. Ordre de validation des commandes :
    1. Policy d’encours
    2. Policy de quotas
    3. Validation manuelle (policy historique)
  2. 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.
  1. 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 en WAITING_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 < minQuotaValue dé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 droit OPERATIONS_READ actif 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_POLICY ou WAITING_CUSTOMER_APPROVAL.
  • Les filtres permettent de :
    • Lister uniquement les commandes bloquées (blockedByBuyingPolicy = true)
    • Restreindre la recherche à certains types de policies (blockingPolicyTypes) :
      • CREDIT_CONTROL
      • QUOTA
      • MANUAL_VALIDATION
  • Les valeurs du filtre blockingPolicyTypes fonctionnent en OU : une commande est incluse si elle correspond à au moins une des policies listées.
  • ⚠️ Le filtre blockingPolicyTypes n’est appliqué que si blockedByBuyingPolicy = 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"]
}