Améliorations graphiques et optimisations de design :
Dans la continuité de la refonte globale du Back Office de Djust, un redesign des pages suivantes a été apporté afin de simplifier l'expérience utilisateur.
Page de détail produit : Catalog -> Products -> Product detail.
Opérations - Gestion des custom fields Opérations :
Afin de pouvoir manipuler les Custom Fields de type OPERATION dans le Back Office Djust, une nouvelle page de settings identique aux pages de CF existantes a été créée. La page est accessible via Settings -> Catalog and offer management -> Operation custom fields.
Order
Ajout d'un statut de paiement initial : NOT_INITIATED
Afin de rendre plus compréhensible les commandes sans paiement initié ou sans aucun paiement, un statut initial NOT_INITIATED a été ajouté. Il remplace le statut AUTHORIZED qui pouvait apparaître à tort.
Filtrage et tri des commandes commerciales par source
Contexte :
Les acheteurs (ACCOUNT) peuvent désormais repérer et segmenter leurs commandes issues d’une Opération directement dans la liste des commandes.
Objectifs : retrouver rapidement « mes commandes de l’opération X », comparer des périodes, analyser l’impact des campagnes, et exporter facilement des vues cohérentes.
Route concernée : GET /v1/shop/commercial-orders (ORDER-560)
Update des adresses email dans l'import des Customer Users
Il est désormais possible de modifier l’adresse email des utilisateurs lors de l’import des Customer users depuis le data hub.
Cette amélioration permet de corriger plus facilement les erreurs d’adresses, de mettre à jour des informations obsolètes et d’assurer une meilleure qualité des données utilisateurs.
Punchout
Ajout de la clé de punchout dans le retour de l'authentification
Dans le cas des solutions multi-punchouts, l’attribut tenantConfigurationKey est désormais présent dans le JWT généré afin de connaître le punchout utilisé par le front client.
Ajout de la suppression d'adresse dans le détail d'un account
La suppression d’une adresse directement depuis la page de détail d’un account est désormais possible, avec les contraintes suivantes :
Un account doit toujours posséder au moins une adresse de billing.
L’option de suppression n’est donc disponible que si l’account a plus d’une adresse.
Ajout de la possibilité de configurer les URLs front d'un environnement (hors multi-stores)
Il est désormais possible de configurer les URLs front d'un environnement mono store comme il était possible de le faire pour les environnements multi-stores.
La page Application Settings a été complétée pour configurer ces URLs en autonomie.
API
📘
NEW
Operations
Récupération des opérations visibles par un acheteur
Contexte :
Les customer users (acheteurs) peuvent désormais consulter la liste des opérations actives auxquelles leur compte a accès, directement depuis leur environnement connecté.
Cette évolution leur permet de découvrir les campagnes en cours et de démarrer leurs achats sur les opérations pertinentes selon leur store et leurs droits.
⚙️ Cette route est réservée aux clients de type ACCOUNT et protégée par le Feature Flag OPERATIONS.
Fonctionnement métier :
Visibilité
Seules les opérations au statut ACTIVE et actives temporellement sont visibles (now ∈ [startDate, endDate]).
Type PUBLIC → visible par tous les accounts rattachés au store effectif.
Type PRIVATE → visible uniquement si le customer user ou son account est explicitement associé à l’opération.
API correspondante :
🔍 Récupérer les opérations visibles pour l’acheteur
Récupération unitaire d’une opération par l’acheteur
Contexte :
Les customer users (ACCOUNT) peuvent désormais consulter le détail d’une opération spécifique à laquelle ils ont accès, directement depuis leur environnement connecté.
Cette évolution permet d’afficher la page de détail d’une opération (nom, description, période, champs personnalisés, etc.) sans exposer l’ensemble du catalogue de produits associé.
⚙️ Cette route est réservée aux clients ACCOUNT et protégée par le Feature Flag OPERATIONS.
🔒 Elle ne renvoie que les métadonnées d’une opération (pas les lignes produits).
Fonctionnement métier :
Visibilité
Seules les opérations :
au statut ACTIVE,
et actives temporellement (now ∈ [startDate, endDate])
sont consultables.
Les opérations de type PUBLIC sont visibles par tous les accounts du store effectif.
Les opérations de type PRIVATE ne sont visibles que si le customer user ou son account y est explicitement associé.
API correspondante :
🔍 Récupération unitaire d’une opération
OPERATION-500 - GET /v1/shop/operations/{operationId}
Récupération des lignes d’une opération par l’acheteur
Contexte :
Les customer users (acheteurs) peuvent désormais récupérer la liste des produits (variants) d’une opération à laquelle ils ont accès, avec leurs libellés localisés et contraintes de quantités (minQuantity, maxQuantity, recommendedQuantity).
Cette évolution permet d’afficher l’assortiment réel visible pour le compte connecté, en respectant le scoping catalogue et les règles de visibilité applicables au store effectif.
⚙️ Cette route est réservée aux clients de type ACCOUNT et protégée par le Feature Flag OPERATIONS.
Fonctionnement métier :
Visibilité de l’opération
Seules les opérations ACTIVE et actives temporellement (now ∈ [startDate, endDate]) sont consultables.
Type PUBLIC → visible pour tous les accounts du store effectif.
Type PRIVATE → visible uniquement si le customer user ou son account est explicitement associé.
Visibilité des variants
Les variants retournés sont ceux présents à la fois dans l’assortiment de l’opération et dans le catalogue visible pour l’account connecté.
Les variants non visibles sont ignorés silencieusement.
Si aucun variant n’est visible → 200 OK avec lines: [].
API correspondante :
🔍 Récupération des lignes produits d’une opération
OPERATION-551 - GET /v1/shop/operations/{operationId}/lines
Créer une commande depuis une Opération (FULL ou PARTIAL)
Contexte :
Les acheteurs (ACCOUNT) peuvent désormais initialiser une commande directement depuis une Opération à laquelle ils ont accès.
Deux modes sont proposés :
FULL : ajout automatique de toutes les lignes éligibles et visibles de l’Opération, avec des quantités par défaut.
PARTIAL : création de la commande vide mais liée à l’Opération, puis ajout des lignes au cas par cas.
⚙️ Feature flag requis : OPERATIONS
🏬 Store effectif : dj-store s’il est fourni, sinon store par défaut du tenant (le user doit y être rattaché).
🔐 Visibilité Opération : uniquement les opérations ACTIVE, dans la fenêtre [startDate, endDate], et visibles pour l’acheteur :
PUBLIC → tous les accounts du store effectif,
PRIVATE → seulement si l’account (ou le user) est explicitement associé.
Fonctionnement métier :
Source unique par création
La commande peut être créée à partir d’une seule source (MVP : OPERATION uniquement).
Le couple sourceType + sourceId est optionnel, mais si sourceId est renseigné, sourceType est requis.
Modes d’initialisation des lignes
FULL (isFull = true, défaut quand une source est fournie)
Ajoute toutes les lignes de l’Opération éligibles & visibles pour l’acheteur (catalogue, offre/prix/variant actifs, fenêtre de dates, éligibilité tarifaire, stock…).
Quantité par défaut par ligne :
recommendedQuantity > 0 → utilisée,
sinon minQuantity > 0 → utilisée,
sinon 1,
puis bornage par minQuantity / maxQuantity s’ils existent.
PARTIAL (isFull = false)
La commande est créée vide mais marquée comme issue de l’Opération.
Les lignes sont ajoutées ensuite via ORDER-150, avec application des contraintes de l’Opération uniquement pour les variants appartenant à l’Opération (date/visibilité + min/max).
Les variants hors Opération restent autorisés (règles standards uniquement).
API correspondante :
✅ Créer une commande (support de la source OPERATION)
Tris sur la liste des blocages de comptes (Credit Hold)
Contexte :
Les opérateurs peuvent désormais trier la liste des blocages de comptes (credit holds) pour analyser plus rapidement les situations (nouveaux blocages, fin proche, derniers modifiés, etc.).
Cette amélioration s’applique à la route existante de listing et vient compléter les filtres introduits précédemment.
Fonctionnement métier :
Tri par date de création décroissante par défaut → les blocages les plus récents apparaissent en premier.
Possibilité de combiner plusieurs tris pour affiner l’ordre d’affichage (ex. trier par date de fin puis, à égalité, par compte).
Cas particuliers gérés pour éviter les surprises d’affichage (ex. dates de fin non renseignées envoyées en dernier).
API correspondante :
🔍 Lister les blocages (triable)
ADM-OPERATION-550 - GET /v1/buying-policies/credit-control/holds
Multi-tris : répéter le paramètre, ex. ?sort=endDate:asc&sort=accountId:asc
Tri par défaut : createdAt:desc
Comportements spécifiques :
Pour endDate, les valeurs null sont toujours renvoyées en dernier, quel que soit le sens.
Règle Djust : tout tri invalide ou mal formé est ignoré silencieusement ; la requête réussit avec les tris valides restants.
En cas d’égalité, le tri par défaut (createdAt:desc) est ajouté en tie-breaker.
Exemples d'appels :
Derniers modifiés d’abord :
?sort=updatedAt:desc
Blocages qui finissent bientôt :
?sort=endDate:asc
Puis par compte à égalité :
?sort=endDate:asc&sort=accountId:asc
Les opérateurs et les customer users habilités peuvent désormais modifier les métadonnées d’une opération existante, tant qu’elle est en statut DRAFT.
Cette évolution permet de corriger ou d’ajuster les informations planifiées avant la publication d’une opération — par exemple mettre à jour le nom, la description, les dates ou les champs personnalisés.
⚙️ La fonctionnalité est protégée par le Feature Flag global OPERATIONS.
🔒 Elle ne permet pas de modifier les produits, variants ou comptes associés à l’opération.
Fonctionnement métier :
Opérateur (dj-client: OPERATOR) : peut modifier toute opération en DRAFT, sans contrainte de store.
Customer User (dj-client: ACCOUNT) :
doit avoir le droit OPERATIONS_UPDATE = true,
doit être owner de l’opération (ownerId = customerUserId),
doit être rattaché au store effectif (dj-store si fourni, sinon store par défaut du tenant).
Les trois conditions sont cumulatives.
Les opérations en statut ACTIVE ou INACTIVE ne peuvent pas être modifiées.
Si une endDate est fournie, elle doit être postérieure ou égale à startDate.
API correspondante :
✏️ Mise à jour d’une opération existante
ADM-OPERATION-200 - PUT /operations/{operationId}
{
"names": {
"en-GB": "Black Friday - Updated",
"fr-FR": "Black Friday - Mis à jour"
},
"descriptions": {
"en-GB": "New details added for this campaign",
"fr-FR": "Nouveaux détails ajoutés pour cette campagne"
},
"startDate": "2025-11-22T00:00:00Z",
"endDate": "2025-11-29T23:59:59Z",
"customFieldValues": [
{
"customFieldId": "cf_1234",
"customFieldValue": "10%"
}
]
}
Suppression d’une Opération
Contexte :
Les opérateurs et les customer users habilités peuvent désormais supprimer une opération, y compris ses métadonnées (nom, type, code), lorsque celle-ci n’est plus utilisée.
Cette action permet de nettoyer les opérations obsolètes ou erronées, tout en garantissant la sécurité des données grâce à des contrôles stricts d’usage et d’accès.
La suppression :
est définitive et irréversible,
est protégée par le Feature Flag OPERATIONS,
n’est autorisée que si l’opération n’est liée à aucun panier ni commande.
Fonctionnement métier :
Opérateur (dj-client: OPERATOR)
Peut supprimer toute opération, quel que soit son statut (DRAFT, ACTIVE, INACTIVE).
Pas de contrainte liée au store.
Suppression bloquée si l’opération est liée à un panier ou une commande.
Customer User (dj-client: ACCOUNT)
Doit cumuler les trois conditions suivantes :
Droit OPERATIONS_DELETE = true,
Être owner de l’opération (ownerId = customerUserId),
Être rattaché au store effectif (dj-store si fourni, sinon store par défaut du tenant).
Si l’une des conditions n’est pas remplie → accès refusé (403).
Effets en cascade :
Si la suppression est autorisée, les associations aux produits et aux comptes sont également supprimées automatiquement.
Les opérateurs et les customer users habilités peuvent désormais activer ou désactiver une opération afin de la rendre visible ou non pour les acheteurs concernés.
Cette fonctionnalité offre plus de flexibilité dans la gestion du cycle de vie d’une campagne commerciale, tout en garantissant la cohérence avec les droits d’accès et le Feature Flag OPERATIONS.
Une opération ACTIVE devient immédiatement visible pour les comptes associés.
Une opération INACTIVE reste enregistrée, mais n’est plus affichée ni accessible côté acheteur.
Il est impossible de repasser en DRAFT une fois l’opération publiée.
Le changement de statut est indépendant des dates (startDate / endDate).
L’action est soumise au Feature Flag global OPERATIONS.
Fonctionnement métier :
Opérateur (dj-client: OPERATOR) :
Peut toujours activer ou désactiver une opération, sans restriction de store.
Customer User (dj-client: ACCOUNT) :
Doit disposer du droit OPERATIONS_UPDATE_STATUS = true,
Être owner de l’opération (ownerId = customerUserId),
Être rattaché au store effectif (dj-store si fourni, sinon store par défaut du tenant).
Les trois conditions sont cumulatives et obligatoires.
Transitions autorisées :
DRAFT → ACTIVE
DRAFT → INACTIVE
ACTIVE → INACTIVE
INACTIVE → ACTIVE
❌Aucune opération ne peut redevenir DRAFT après publication.
🔄 Ces transitions sont indépendantes des dates de début et de fin de l’opération.
Les opérateurs et les customer users habilités peuvent désormais supprimer un ou plusieurs variants d’une opération, afin de maintenir un assortiment à jour ou corriger des erreurs avant publication.
Cette évolution permet de gérer plus facilement le contenu d’une opération en préparation, sans avoir à recréer l’ensemble de la configuration.
⚙️ L’action est protégée par le Feature Flag OPERATIONS et limitée aux opérations au statut DRAFT.
🔒 La suppression est possible uniquement pour :
les opérateurs (accès complet, sans contrainte de store),
les customer users qui cumulent les trois conditions suivantes :
être owner de l’opération (ownerId = customerUserId),
disposer du droit OPERATIONS_UPDATE,
être rattachés au store effectif (dj-store si fourni, sinon store par défaut du tenant).
Fonctionnement métier :
Les variants sont identifiés par leurs identifiants externes (variantIds).
Les IDs non valides ou non liés à l’opération sont ignorés ; si aucun variant n’est valide, la suppression échoue.
La suppression ne prend effet que sur les opérations en DRAFT ; une opération active ou inactive ne peut pas être modifiée.
Cette action n’affecte pas les locales, car elle agit uniquement sur des identifiants techniques.
API correspondante :
🗑️ Suppression d’un ou plusieurs variants d’une opération
Ajout de l’option de compression GZIP pour les exports API
Les opérateurs back-office peuvent désormais sélectionner le mode de compression GZIP lors de la configuration d’un job d’export par API.
Dans certains cas, comme l’export de commandes contenant plusieurs centaines de lignes, la taille des données peut devenir conséquente. En activant le mode de compression GZIP, les données sont compressées avant d’être transmises via l’API, ce qui permet de réduire significativement la taille des appels API.
API
📘
NEW
Operations
Suppression d’accounts d’une Opération (PRIVATE)
Contexte :
Les opérateurs et customer users habilités peuvent désormais retirer un ou plusieurs comptes associés à une opération de type PRIVATE.
Cette évolution permet de révoquer l’accès à une opération ciblée, par exemple lorsqu’un compte ne doit plus bénéficier d’une campagne.
La suppression n’est possible que pour les opérations :
de type PRIVATE,
au statut DRAFT.
L’action est protégée par le Feature Flag OPERATIONS.
Opérateur : peut supprimer des comptes de toute opération PRIVATE en DRAFT, sans contrainte de store.
Customer User : doit cumuler trois conditions pour supprimer des comptes :
droit OPERATIONS_UPDATE = true,
être owner de l’opération (ownerId = customerUserId),
être rattaché au store effectif (dj-store si fourni, sinon store par défaut du tenant).
Fonctionnement métier :
Les IDs fournis doivent correspondre à des accounts déjà liés à l’opération.
Les accounts inconnus ou non liés sont ignorés ; si aucun des accounts fournis n’est valide, une erreur est renvoyée.
Une opération de type PUBLIC n’accepte jamais de suppression d’accounts (cas rejeté).
Les opérateurs de la plateforme peuvent désormais forcer manuellement la validation d’une commande bloquée par une ou plusieurs buying policies (encours, quotas).
Cette évolution permet de reprendre le traitement d’une commande bloquée lorsque les conditions initiales ne peuvent être satisfaites automatiquement, tout en conservant une traçabilité complète des actions opérateur.
Fonctionnement métier :
Seules les commandes au statut BLOCKED_BY_POLICY peuvent être forcées. (Ceci exclut pour le moment les buying policies de validation manuelle historiques).
Une commande bloquée par plusieurs policies n’est débloquée que si plus aucune ne s’applique.
Le statut évolue de BLOCKED_BY_POLICY → WAITING_SUPPLIER_APPROVAL une fois la validation forcée acceptée.
Chaque action de forçage est enregistrée avec la date, l’auteur et la policy concernée.
Le processus reste auditables via un endpoint d’historique dédié.
Exemple : une commande bloquée par la policy de quota peut être validée manuellement si l’opérateur décide d’autoriser exceptionnellement son envoi au fournisseur.
API correspondante :
✅ Forcer la validation d’une ou plusieurs commandes bloquées
ADM-ORDER-150 - POST /v1/logistic-orders/unblock
{
"orderIds": ["ORD-12345", "ORD-67890"]
}
🔍 Consulter l’historique des validations forcées
ADM-ORDER-550 - GET /v1/logistic-orders/{logisticOrderId}/unblock-history
Configuration de nouveaux rôles pour la configuration des Buying Policies
Deux nouveaux rôles ont été ajoutés pour gérer les configuration de Buying Policies de quotas et d'encours :
Rôle de gestion de quota minimum pour un fournisseur associé à un CF de type number
Rôle de gestion des limites de crédit et d'encours pour un compte client associé à des CF de type number.
API
📘
NEW
Operations
Création d'une Opération
Contexte :
Les utilisateurs peuvent désormais créer une nouvelle opération (campagne commerciale ou organisationnelle) directement via l’API.
Cette action permet d’initialiser une opération en statut DRAFT, sans produits ni comptes associés, en amont de toute configuration (variants, accounts, prix…).
La visibilité (PRIVATE ou PUBLIC) est définie à la création et n’est pas modifiable par la suite.
Le créateur de l’opération (ownerId) est automatiquement enregistré et sera le seul à pouvoir la modifier côté compte client (hors opérateur).
La création est protégée par le feature flag OPERATIONS.
L’internationalisation est supportée via les locales autorisées du store (IETF BCP 47). La locale par défaut du store (ou du tenant si le store n’en définit pas) doit obligatoirement être présente.
Fonctionnement métier :
Opérateur (dj-client: OPERATOR) : peut toujours créer une opération, quel que soit le store.
Customer User (dj-client: ACCOUNT) :
doit disposer du droit OPERATIONS_CREATE = true,
ne peut créer que sur un store auquel il est rattaché (ou le store par défaut du tenant).
À la création, le statut de l’opération est toujours DRAFT.
Ajout et modification des variants d’une Opération
Contexte :
Il est désormais possible, pour les opérateurs et les customer users habilités, d’ajouter des variants à une opération et/ou de modifier les quantités associées (minQuantity, maxQuantity, recommendedQuantity).
Cette évolution permet d’ajuster les contraintes d’achat avant la publication d’une opération.
Fonctionnement métier :
Ajout : un variant ne peut être associé qu’une seule fois à une opération.
Mise à jour : possible en masse, chaque ligne correspondant à un variantId externe.
Validation des quantités :
minQuantity ≥ 0 (facultatif, permet de rendre l’achat obligatoire si > 0),
maxQuantity ≥ minQuantity (si défini),
recommendedQuantity ∈ [minQuantity, maxQuantity] si maxQuantity est défini, sinon ≥ minQuantity.
API correspondante :
✏️ Modification des variants d’une opération
ADM-OPERATION-250 - PUT /operations/{operationId}/lines
Il est désormais possible d’ajouter des comptes à une opération de type PRIVATE, afin de restreindre sa visibilité uniquement aux accounts explicitement autorisés.
Cette action est réservée aux opérations en statut DRAFT et de type PRIVATE.
API correspondante :
➕ Ajout d’accounts à une opération
ADM-OPERATION-251 - PUT /operations/{operationId}/accounts
[
"ACC-001",
"ACC-002",
"ACC-XYZ"
]
Récupération des accounts d’une Opération (PRIVATE)
Contexte :
Les opérateurs et les customer users habilités peuvent désormais consulter la liste des comptes associés à une opération PRIVATE.
Cette évolution permet de contrôler qui a accès à une opération restreinte, afin de sécuriser la diffusion des campagnes commerciales ou organisationnelles.
Fonctionnement métier :
Les résultats peuvent être filtrés par accountIds (externalIds uniquement) et/ou accountName (recherche partielle, insensible à la casse).
Le tri par défaut est effectué sur accountName dans le sens ASC.
Autres tris possibles : accountName, accountId.
API correspondante :
🔍 Récupérer les accounts liés à une opération
ADM-OPERATION-552 - GET /operations/{operationId}/accounts
Les opérateurs et les customer users habilités peuvent désormais consulter la liste des variants associés à une opération, avec leurs quantités configurées (minQuantity, maxQuantity, recommendedQuantity).
Cette route permet de contrôler le contenu d’une opération et de préparer sa modification ou son utilisation.
Les équipes Opérations et Sales peuvent désormais consulter la liste des Opérations (campagnes) via une route d’administration unique.
L’accès est contrôlé (owner, droits, store) et filtrable (statut, nom, dates, type…), afin de retrouver rapidement une opération, vérifier son statut et l’ouvrir pour suivi/édition.
Fonctionnement métier :
Visibilité opérateur (dj-client: OPERATOR)
Voit toutes les opérations.
Si dj-store est fourni → résultats restreints à ce store.
Si dj-store est absent → résultats restreints au store par défaut du tenant.
Visibilité customer user (dj-client: ACCOUNT)
Ne voit que ses propres opérations (ownerId = customerUserId) et uniquement si le droit OPERATIONS_READ = true.
Doit être rattaché au store demandé :
Si dj-store est fourni → le caller doit être attaché à ce store.
Si dj-store est absent → fallback sur le store par défaut du tenant ; le caller doit y être attaché.
Locales
Le paramètre locale (optionnel) détermine la langue des champs localisés (name).
La locale doit faire partie des locales autorisées du store de l’opération ; sinon, fallback sur la locale par défaut du store.
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 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
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
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
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é).
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 siblockedByBuyingPolicy = true. Sinon, il est ignoré.
Améliorations graphiques et optimisations de design :
Dans la continuité de la refonte globale du Back Office de Djust, un redesign des pages suivantes a été apporté afin de simplifier l'expérience utilisateur.
Il est désormais possible d'ordonner les valeurs des custom fields grâce au drag and drop.
Avant :
Après :
Data Hub
Définition d'une adresse de livraison et/ou facturation à l'import
Il est désormais possible de définir si une adresse doit être utilisée pour la livraison (shipping) et/ou la facturation (billing) lors de l’import des comptes clients depuis le data hub.
📘
Si aucune valeur n’est renseignée à l’import, l’adresse sera considérée comme valable pour la livraison et la facturation.
⚠️
Un compte doit avoir au moins une adresse de facturation.
API
📘
NEW
Buying Policies
Définition d'une limite de quota minimum par défaut à la plateforme
Contexte :
Les opérateurs peuvent désormais définir un quota de commande minimum global.
Ce quota est utilisé automatiquement pour tous les couples Customer Account × Supplier qui ne disposent pas d’une configuration spécifique.
Il garantit une homogénéité dans le contrôle des commandes et permet de bloquer celles qui ne respectent pas le volume minimum attendu.
Fonctionnement :
Si un quota spécifique est défini au niveau du Supplier ou du couple Customer Account × Supplier, celui-ci prévaut.
Si aucun quota spécifique n’est défini, la valeur par défaut s’applique.
Une valeur de 0 signifie qu’aucune restriction n’est appliquée par défaut.
Lors de la création d’un nouvel environnement, la valeur par défaut est initialisée à 0.
APIs correspondantes :
🔍 Consultation du quota par défaut
ADM-BUYING-POLICY-501 - GET /v1/buying-policies/quotas
Retourne le statut de la policy (ACTIVE ou INACTIVE), la valeur du quota par défaut et la date de dernière mise à jour.
Accessible uniquement avec le header dj-client: OPERATOR.
Activation / désactivation globale de la policy de quotas
Contexte :
Les opérateurs peuvent désormais activer ou désactiver globalement la buying policy de quotas.
Cette règle permet de contrôler si les commandes doivent être bloquées en fonction d’un quota minimum configuré (spécifique ou par défaut).
Elle est particulièrement utile en phase de migration ou de test, ou encore pour ajuster rapidement le niveau de contrôle sans modifier la configuration des comptes ou des suppliers.
Quand la policy est ACTIVE : toutes les commandes sont validées selon les règles de quota (valeurs définies au niveau du Supplier ou valeur par défaut si absente).
Quand la policy est INACTIVE : aucune vérification ni blocage n’est appliqué.
Par défaut, lors de la création d’un environnement, la policy est initialisée à INACTIVE.
APIs correspondantes :
🔍 Consultation de la configuration globale
ADM-BUYING-POLICY-501 - GET /v1/buying-policies/quotas
La route est commune entre la gestion des statuts et des quotas par défaut.
Retourne l’état actuel de la policy (ACTIVE ou INACTIVE), la valeur du quota minimum par défaut (minQuotaValue) et la date de dernière mise à jour.
Améliorations graphiques et optimisations de design :
Dans la continuité de la refonte globale du Back Office de Djust, un redesign des pages suivantes a été apporté afin de simplifier l'expérience utilisateur.
Page de gestion des tags produits : Settings -> Product Tags.
Page de creation/mise à jour des restrictions de catalogues : Product -> Catalog Views.
Affichage du statut Online/Offline en page liste offres
L'état d’une offer est désormais affiché (à la manière des produits) au niveau de la colonne de statut.
Celui-ci n'est affiché que si le feature flag SEARCH_V2 est actif
API
📘
NEW
Opérations
Une nouvelle entité "Opérations" en cours de développement devrait voir le jour courant septembre. Voici les premiers éléments qui sont livrés dans cette version (d'autres suivront sur les releases futures).
Pilotage de la feature Opérations via Feature Flag
Un nouveau Feature Flag OPERATIONS permet désormais d’activer ou de désactiver dynamiquement l’ensemble de la feature Opérations (endpoints, jobs et pricing override associés).
Quand OPERATIONS = false :
Tous les endpoints /admin/operations/** et /shop/operations/** deviennent inaccessibles.
Toutes les règles de pricing spécifiques liées aux opérations sont ignorées.
Le fallback de prix est alors appliqué selon la hiérarchie standard : Account → Customer Tags → Public
Par défaut, la feature est désactivée, l'activation se fait via les équipes CSM et Support.
👍
UPDATE
Orders
Ajouter de champs supplémentaires dans l’export order par API
Les champs suivants ont été ajoutés dans l'export order API du Data Hub :
