s’applique aux variants et aux custom fields présents dans le payload
ne s’applique pas à la master quote, qui ne possède pas encore d’external ID
Le comportement par défaut reste inchangé :
👉 si idType n’est pas fourni, l’API continue d’interpréter les identifiants en DJUST_ID pour garantir la compatibilité existante.
Création d'une commande depuis un devis :
Contexte
Les customer users (ACCOUNT) peuvent désormais créer une commande à partir d’un devis auquel ils ont accès, via la route de checkout v3 ORDER-108 - POST /v2/shop/commercial-orders.
L’objectif est de permettre la conversion directe d’un devis en commande, en reprenant ses lignes et conditions, tout en conservant un contrôle strict sur l’éligibilité du devis et le cycle de vie de la commande.
Fonctionnement métier
Nouvelle source QUOTE supportée dans ORDER-108
La création de commande supporte désormais deux types de source :
OPERATION (déjà existant)
QUOTE (nouveau)
Pour pouvoir être transformé en commande, le devis doit :
être valide (non expiré, non annulé),
être au statut WAITING_FOR_CUSTOMER au moment de l’appel,
appartenir à l’account du caller,
être dans le store effectif (scoping via dj-store ou store par défaut).
Si une de ces conditions n’est pas remplie, la création est refusée.
Contrairement aux opérations, seul le mode FULL est accepté.
La commande créée est au statut initial DRAFT_ORDER_ON_HOLD.
Elle est non éditable : les appels de type ORDER-150, ORDER-213, ORDER-215… sont refusés.
Le paiement via PAY-101 est autorisé ; en cas de succès, la commande passe en CREATED (workflow standard).
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)
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
Nouvelle version d'API pour la mise à jour de adresses de facturation - ORDER-213
Contexte :
L’API historique ORDER-213 (/billing-information) n’acceptait qu’un business ID Djust dans son path, ce qui ne correspond plus au standard actuel des routes Checkout v3 basées sur les REFERENCE IDs.
Pour corriger cela, une nouvelle version /v2 de la route est introduite, tandis que la version existante est désormais dépréciée.
Fonctionnement :
• Aucun changement fonctionnel : seul le type d’ID attendu dans le path évolue.
Nouveauté API :
ORDER-213 - PUT /v2/shop/commercial-orders/{commercialOrderId}/billing-information
• commercialOrderId doit être un REFERENCE ID, conformément au comportement des routes du checkout order v3.
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.
Cette version comprend les périmètres 3.91.0 et 3.92.0.
Périmètre
Back Office
Ajout de la configuration de la gestion d'activation des produits :
L'activation/désactivation du workflow simplifié d'activation de produit est désormais accessible via les paramètres globaux d'application.
Ajout de la configuration du mode d'indexation :
Il est désormais possible de positionner le mode d'indexation via la page des paramètres globaux d'application.
Ajout de la possibilité de modifier un nom de job dans le Data Hub :
Il est désormais possible de mettre à jour le nom d’un job d’import.
⚠️ Le nom doit être unique
Ajout de la possibilité de filtrer la liste des tolérances des Buying Policies d'encours :
API
📘
NEW
Paiement
Paiement par carte achat niveau 3 (P-Card L3)
Contexte :
Djust PAY supporte désormais le démarrage d’un paiement Carte Achat Niveau 3 (P-Card L3) via une PayPage embarquée en mode “token-only”.
Ce mécanisme permet d’afficher une page de paiement hébergée (par notre prestataire dédié ITS), où l’acheteur saisit sa carte, sans que Djust ne manipule de PAN - conformité PCI 100% maintenue.
Ce token PayPage est généré côté serveur, puis transmis au front dans la réponse PAY-101 sous forme d’action de redirection POST.
L’autorisation carte est ensuite réalisée en server-to-server.
Fonctionnement métier :
Pré-check obligatoire (PAY-502)
Avant l’appel PAY-101, le front exécute un pré-check.
Il valide la complétude des champs L3 nécessaires au flux carte achat.
• Si ready = false → pas de démarrage PayPage.
• Si ready = true → le front peut appeler PAY-101.
Génération du Token PayPage
Lorsqu’un paiement est initié avec (PAY-101) :
paymentMethodData.type = "purchasing_card_l3"
Saisie carte + 3DS v2
Le front exécute l’action retournée par PAY-101 :
• method = POST
• url = PayPageURL (configurable via ADM-SETTINGS-201)
• data = { SupplierID, Token }
La PayPage s’affiche dans l’iFrame, la saisie carte est entièrement gérée par Djust et son prestataire de paiement ITS.
Postback
Après saisie → Djust reçoit un callback S2S contenant les informations nécessaires au déclenchement de l'autorisation.
Filtrage des commandes d'une organisation par statut logistique
Contexte :
Les customer users peuvent désormais filtrer les commandes logistiques de leur organisation par statut lorsqu’ils consultent la liste des commandes via la route ACCOUNT-555.
Cette évolution améliore la lisibilité et la recherche des commandes, en s’alignant sur ce qui existe déjà côté endpoint ACCOUNT-550.
Fonctionnement métier :
Nouveau filtre : logisticOrderStatuses
Filtre optionnel, multi-valeurs.
Accepte une ou plusieurs valeurs séparées par virgule :
Ajout de la référence externe de la commande dans la page détail order :
La référence externe d'une commande est désormais affichée dans son détail.
API
📘
NEW
Paiement
Paiement par carte achat niveau 3 (P-Card L3)
Contexte :
Djust PAY va très prochainement prendre en charge le paiement par carte achat (P-Card) au niveau 3.
Cette évolution permet aux entreprises clientes d’utiliser leurs cartes d’achat pour régler leurs commandes B2B tout en bénéficiant du niveau de granularité requis par les programmes de facturation corporate (Level 3), notamment sur les marchés publics en France.
Fonctionnement métier :
Pour pouvoir mettre en place la saisie des informations de cartes, il est nécessaire avant tout de pouvoir configurer par un administrateur les différentes URLs de redirection possibles pour le bon fonctionnement du paiement :
onSuccessPath → chemin relatif pour la redirection succès UX.
onErrorPath → chemin relatif pour la redirection échec UX.
postbackUrl → URL HTTPS absolue du callback S2S (réception du token de paiement).
payPageUrl → URL HTTPS absolue de la PayPage utilisée comme PAY-101.action.url.
Les données sensibles ne transitent jamais par le front ni par Djust.
Les URLs front sont construites à partir de la base de redirection effective (effectiveRedirectBaseUrl), calculée automatiquement selon la configuration du store view.
APIs correspondantes :
🔍 Récupérer la configuration PCard-L3 (provider ITS couplé à Djust PAY)
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
