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 creation d'un fournisseur : Suppliers.
Page détail d'un utilisateur fournisseur.
Page de creation d'un job d'export : Data Hub -> Create a new job -> Export.
Page de detail d'un job d'export : Data Hub -> Export -> Configure job.
Filtrage des comptes clients :
Page liste des comptes clients : Customers > Accounts
Le champ de filtre "ID compte" utilise maintenant l’ID externe et l’ID interne.
API
📘
NEW
Buying policies
Montants de tolerance de crédit
Quatre nouveaux endpoints ont été ajoutés au module Buying Policies, permettant aux utilisateurs opérateurs de consulter et modifier l’état global des montants de tolerance de crédit sur la plateforme.
⚠️
Attention
Ces routes de gestion des buying policies ne sont disponibles que pour les utilisateur BackOffice opérateurs.
Consultation des montants de tolérance de crédit :
ADM-BUYING-POLICY-551 - GET /v1/buying-policies/credit-control/grace-amounts
Permet de de récupérer toutes les montants de tolérance de crédit configurées.
Chaque tolérance est définie par :
un montant ajouté au crédit disponible,
une période d’application (début obligatoire, fin facultative),
ADM-BUYING-POLICY-203 - PUT /v1/buying-policies/credit-control/grace-amounts/{graceAmountId}
Permet de mettre à jour l’intégralité du contenu de la tolérance existante pour le compte client.
Vous pouvez mettre à jour le montant, la startDate et/ou la endDate.
Supprime une seule blocage/tolérance existante en fonction de son identifiant (ID).
Mirakl settings
⚠️
Attention
Ce changement s'applique uniquement aux utilisateurs qui utilisent le connecteur Mirakl.
Mise à jour des paramètres du connecteur Mirakl:
Un nouveaux endpoint a été ajouté au module Settings, permettant aux utilisateurs opérateurs qui utilisent le connecteur Mirakl de consulter et modifier l’état global des montants de tolerance de crédit sur la plateforme.
ADM-SETTINGS-200 - PATCH /v1/settings/mirakl}
Permet de mettre à jour les paramètres du connecteur Mirakl, tels que les clés API, l’URL de l’hôte ou la zone de livraison.
⚠️ Seuls les champs fournis dans le body de la requête seront mis a jour. Les autres champs resteront inchangés.
👍
UPDATE
Search V2
Support des intervalles de valeurs pour les attributs
Les attributs peuvent désormais fonctionner en tant qu'intervalles de valeurs. Ainsi toutes les routes d'administration suivantes voient apparaître la nouvelle propriété searchableRange au niveau des attributeSettings
GET /v1/catalog-views/{id}/products
GET /v1/classification-categories
POST /v1/classification-categories
GET /v1/classification-categories/{classificationCategoryId}
PATCH /v1/classification-categories/{classificationCategoryId}
PATCH /v1/classification-categories/{classificationCategoryId}/attribute-settings
PUT /v1/classification-categories/{classificationCategoryId}/attribute-settings
GET /v1/classification-categories/{classificationCategoryId}/parent-tree
PUT /v1/navigation-categories/{navigationCategoryId}/classification-categories
GET /v1/offer-inventories
PATCH /v1/offer-inventories
GET /v1/offer-inventories/{offerInventoryId}
GET /v1/products
PATCH /v1/products
POST /v1/products
PUT /v1/products/back-office/{productId}
GET /v1/products/catalog-views/{id}
GET /v1/products/with-count
GET /v1/products/{id}
PUT /v1/products/{productId}
GET /v1/products/{productId}/related-products
PUT /v1/products/{productId}/related-products/{relatedProductId}
L'ajout d'un nouveau paramètre attributesRange dans l'API PRODUCT-552 permet - grâce à la nouvelle configuration des attributs - désormais de filtrer les produits selon un intervalle de valeurs.
Par exemple, il est possible de rechercher des produits dont la taille est comprise entre 38 et 42.
Améliorations sur l'affichage et le filtrage des comptes clients :
Page liste des comptes clients : Customers > Accounts
L’ID externe du compte client est désormais affiché à côté du nom dans le tableau des comptes clients.
Le champ de filtre "ID compte" utilise maintenant l’ID externe au lieu de l’ID interne.
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 détail des catalogues produits : Catalog > Catalog views.
Page détail des paramètres du moteur de recherche : Settings > Search engine settings.
Affichage des champs de mappings disponibles pour l’export des commandes :
La configuration du mapping des jobs d’export est désormais disponible directement dans le Data Hub, via l’interface du Back Office.
Champs disponibles pour le mapping :
Order reference
Order id
Account External Id
Supplier External Id
Order Creation Date
Order Lines :
Order Line Id
Offer External Id
Variant External Id
Quantity Per Unit
Variant GTIN
Order Line Quantity
API
📘
NEW
Orders [DJUST PAY]
Nouveau endpoint
L'ajout d'un nouveau endpoint POST /v1/logistic-orders/{logisticOrderId}/refunds
Initialise un processus de remboursement pour une commande logistique donnée. Le remboursement sera appliqué au(x) paiement(s) associé(s) à cette commande.
Ajout d'un nouveau statut de paiement:
Le statut de paiement REFUND_FAILED a été ajouté sur les commandes logistiques ainsi que sur les lignes de commande.
⚠️
Attention
Ce changement concerne exclusivement les utilisateurs du module DJUST-PAY.
Les autres moyens de paiement (PSP) ne sont pas affectés.
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.
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.
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).
Nouveau rôle (associé à un CF Account)
Type
Description
Limite de crédit
Number
Montant maximal autorisé. Si vide, la limite par défaut définie dans la buying policy est appliquée.
Encours
Number
Montant total des commandes non payées. Valeur synchronisée depuis les systèmes de gestion externe.
⚠️
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 :
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 détail des assortiments produits : Catalog > Assortments.
Page détail des organisations : Customers > Organisations.
Page de configuration des devises : Settings > Currencies.
API
📘
NEW
Buying Policies
Nouvelle fonctionnalité de gestion des comptes en backoffice permettant de bloquer temporairement ou définitivement un ou plusieurs comptes clients afin d’empêcher toute validation de commande, indépendamment de leur encours ou de leur limite de crédit.
Ainsi, voici les nouveaux endpoints API correspondants :
Récupération des blocages en cours ou programmés :
ADM-BUYING-POLICY-550 - GET /v1/buying-policies/credit-control/holds
Création de blocages manuels sur un ou plusieurs comptes :
ADM-BUYING-POLICY-150 - POST /v1/buying-policies/credit-control/holds
Modification d’un blocage existant, avec règles de cohérence sur les dates :
ADM-BUYING-POLICY-202 - PUT /v1/buying-policies/credit-control/holds/{creditHoldId}
Chaque commande logistique liée à un incident possède un fournisseur.
Pour pouvoir filtrer par fournisseur, un paramètre supplémentaire de filtre suppliers qui prend en entrée une liste d’external ID de suppliers est ajouté à la route ORDER-559 - GET /v1/shop/incidents.
Son fonctionnement reste similaire au filtre par customerAccountIds.
En résultat, on remonte l’ensemble des incidents liés à une commande/ligne de commande correspondant à au moins un des id de fournisseur passé en paramètre.
Si aucune correspondance n’est trouvée, aucun résultat n’est remonté.
Customer Accounts
Suppression de la contrainte d’unicité sur le nom des comptes clients
Il est désormais possible de créer plusieurs comptes clients portant le même nom, que ce soit via les APIs d'administration, Frontend ou les imports (FTP/API).
Les traitements ne s’appuient plus sur le nom pour identifier un compte, mais uniquement sur son identifiant technique (customerAccountId).
La recherche par nom retourne tous les comptes correspondants, même en cas d’homonymie.
Les processus d’import (FTP ou API) n’échouent plus lorsqu’un doublon de nom est détecté.
Les APIs suivantes ont été mises à jour :
POST /v1/customer-accounts
PUT /v1/customer-accounts/{customerAccountId}
ACCOUNT-100 - POST /v1/shop/customer-accounts
ACCOUNT-201 - PUT /v1/shop/customer-accounts
📌 Aucune action corrective sur les données existantes : les noms précédemment uniques restent valides et modifiables.
Data Hub
Exposition des mappings disponibles à l’export pour les commandes
Il est désormais possible d’interroger par API les mappings utilisables pour l’export des commandes via l’endpoint GET /jobout/mappings?type=ORDER
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 des utilisateurs fournisseurs (Portail fournisseur uniquement) : Users.
Page de recherche des produits/variants : Catalog > Product list.
Page de détail et de création des utilisateurs front : Customers > Customer users.
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 recherche des utilisateurs fournisseurs (Portail fournisseur uniquement) : Users.
Page de recherche des devis : Quotes.
Affichage de l'External ID des variants dans la section Produits d’un devis
Dans la page de détail d’un devis, au sein de la section Produits, un nouveau champ informatif a été ajouté.
Ce champ affiche l’External ID du variant associé à chaque ligne de produit.
Cette amélioration permet de faciliter l’identification et le suivi des variants.
API
📘
NEW
Data Hub - Mise à jour des noms des jobs d’import
Une nouvelle route API permet de mettre à jour le nom des jobs d'import.
PATCH /v2/mapper/job/{jobId}
{
"jobName": "string"
}
Le nom doit être unique pour tous les jobs d’import.
👍
UPDATE
Incidents
Tri des incidents par supplier :
Il est désormais possible de trier les incidents par fournisseur sur la route :
ORDER-559 - GET /v2/shop/incidents
Contrairement au filtre par fournisseur, le tri par fournisseur doit s’appliquer sur le nom du fournisseur.
Ainsi la possibilité de trier sur les noms des fournisseurs se fait 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).
⚠️
Attention
Il s'agit d'une v2 de l'API, la v1 ne pouvant pas supporter le tri, elle a été dépréciée au profit de celle-ci.
Nouveau filtre ajouté sur la page liste des commandes : Custom Field Order
Un nouveau filtre qui concerne les champs personnalisés des commandes, a été ajouté à la page liste des commandes.
Cette amélioration permet aux utilisateurs d’affiner leur recherche et de retrouver plus facilement des commandes en fonction des valeurs de leurs champs personnalisés. Ce filtre facilite la navigation et améliore la gestion des commandes.
Modification du champ “numéro de téléphone” pour les utilisateurs clients
Le champ numéro de téléphone n’est désormais plus obligatoire lors de la création ou de la mise à jour d’un utilisateur. Cette contrainte a été levée afin de faciliter la gestion des comptes clients ne disposant pas nécessairement d’un numéro de téléphone. Cette évolution améliore la flexibilité et réduit les frictions lors de l’enregistrement ou de la modification des utilisateurs.
Data Hub
Import des assortiments par Connecteur API
Un nouveau type de job a été introduit pour permettre l’import et la gestion d’assortiments via Connecteur API. Ce type de job, identifié par l’enum ASSORTMENT_API_JSON_JOB, est désormais pris en charge dans l’ensemble des endpoints liés aux jobs et configurations de mapping.
Objectif du job
La création d’un ou plusieurs assortiments
La liaison d’un ou plusieurs produits à un assortiment
Délier un ou ou plusieurs produits d’un assortiment
Champs pris en charge
Champ
Type
Obligatoire à la création
Update possible
Par défaut
assortment_external_id
String
✅ Oui
✅ Oui
—
assortment_name
String
Non
✅ Oui
—
product_external_id
String Array ou String
Non
—
—
unlink
Boolean
Non
✅ Oui
false
Règles métier
Création/Update d’un Assortment nécessite assortment_external_id.
Liaison à un ou plusieurs produits via product_external_id.
Suppression du lien entre un Assortment et un ou plusieurs produits via unlink: true.
Un produit peut être lié à plusieurs assortiments, sans limite.
Autorisation de la modification/suppression de lignes pour un user non owner en contexte (Checkout v3) :
En B2B il est nécessaire d’ouvrir la possibilité pour un utilisateur de pouvoir modifier/supprimer les éléments d’une commande qu’il n’a pas créé sur ces route :
ORDER-150 - PUT /v2/shop/commercial-orders/{commercialOrderId}/lines
ORDER-350 - DELETE /v2/shop/commercial-orders/{commercialOrderId}/lines
Il doit cependant être présent dans le même compte que celui où est rattaché la commande.
Ainsi, le droit existant suivant est étendu : ORDER_UPDATE_LINES_ON_ALL_ACCOUNT
Ce droit existe déjà pour la modification des quantités sur les commandes logistiques sur ORDER-250 et ORDER-150.
Ce droit est donc étendu pour autoriser l’utilisateur à modifier/supprimer les lignes des commandes sous les conditions suivantes :
Le user appartient au même compte que celui lié à la commande
Le user a le droit ORDER_UPDATE_LINES_ON_ALL_ACCOUNT à true associé à son rôle
⚠️
Attention
La suppression des lines n’est possible que si la commande commerciale n’a pas été validée (i.e si les commandes logistiques liées sont au statut DRAFT ou DRAFT_ON_HOLD).
Search
Il est dorénavant possible de filtrer sur un interval de prix.
Les informations suivantes ont été ajoutées dans les snapshots d’offer inventories de chaque ligne de commande :
minOrderQuantity : issu de l’offre (inventory), il correspond à la quantité minimale achetable par commande
maxOrderQuantity : issu de l’offre (inventory), il correspond à la quantité maximale achetable par commande
De même, les informations suivantes ont été ajoutées dans les snapshots de products de chaque ligne de commande :
navigationCategory : issu du produit, on ne récupère que le nom du noeud le plus fin sur lequel est rattaché le produit.
navigationCategoryExternalId : issu du produit, on ne récupère que l’external id du noeud le plus fin sur lequel est rattaché le produit.
Les routes concernées par les changements sont :
ORDER-560 - GET /v1/shop/commercial-orders\
ORDER-100 - POST /v1/shop/commercial-orders
ORDER-561 - GET /v1/shop/commercial-orders/{commercialOrderId}/lines
ORDER-500 - GET /v1/shop/commercial-orders/{orderCommercialId}
N/A - GET /v1/shop/logistic-orders
ORDER-550 - POST /v1/shop/logistic-orders
ORDER-501 - GET /v1/shop/logistic-orders/{orderLogisticId}
ORDER-205 - PATCH /v1/shop/logistic-orders/{orderLogisticId}
ORDER-200 - PUT /v1/shop/logistic-orders/{orderLogisticId}/approve
ORDER-556 - GET /v1/shop/logistic-orders/{orderLogisticId}/approvers
ORDER-201 - PUT /v1/shop/logistic-orders/{orderLogisticId}/cancel
ORDER-203 - PUT /v1/shop/logistic-orders/{orderLogisticId}/confirm-reception
ORDER-204 - PUT /v1/shop/logistic-orders/{orderLogisticId}/disapprove
ORDER-555 - GET /v1/shop/logistic-orders/{orderLogisticId}/lines
ORDER-206 - PATCH /v1/shop/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
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 configuration des stores : Settings > Stores.
Page de recherche des customer users : Customers > Users.
API
👍
UPDATE
Data Hub - Mise à jour des noms des jobs d’import
Une nouvelle route API permet de mettre à jour le nom des jobs d'import.
PATCH /v2/mapper/job/{jobId}
{
"jobName": "string"
}
Le nom doit être unique pour tous les jobs d’import.
Data Hub - Création multiple de transcoding
L’endpoint POST /v1/mapper/job/{jobId}/transcodings accepte désormais une liste d’objets pour convertir plusieurs valeurs pour plusieurs mappings sur un job d’import donné.
Exemple:
POST /v1/mapper/job/ad249986-0048-4a95-9fb7-8c4d1e01617f/transcodings
