Périmètre

🖥️ Back-Office

📘

NEW

Sélecteur multi-stores pour les jobs d'import

Contexte

Dans un contexte multi-stores, il n'était pas possible de configurer directement dans le Back-Office les stores cibles d'un job d'import. Le store devait être indiqué dans le fichier d'import ou le payload.

Fonctionnement

Lors de la création ou de la modification d'un job d'import, un nouveau sélecteur multi-stores est disponible dans le formulaire de configuration. Ce sélecteur permet de définir les stores auxquels les entités importées seront automatiquement rattachées.

Règles principales :

• Le sélecteur apparaît uniquement pour les types de jobs compatibles multi-stores (isMultiStore = true) et pour les tenants multi-stores.
• Le champ est optionnel : si aucun store n'est sélectionné, le comportement classique est conservé (store défini dans le fichier d'import ou le payload).
• En cas de conflit, la configuration du job prévaut sur les valeurs du fichier d'import.
• Un bouton "Sélectionner tout / Désélectionner tout" facilite la gestion.
• Le type de job NAVIGATION_CATEGORY conserve son comportement actuel (sélecteur single-store + store view).

📄 Documentation :

• Job Configuration Import Ftp
• Job Configuration Import Api Connector

Bénéfices

👉 Côté métier : configurez une fois les stores cibles directement sur le job d'import, sans avoir à les spécifier dans chaque fichier d'import.

👉 Côté technique : nouveau champ storeExternalIds dans les payloads de création et modification de job (POST / PATCH). Le champ isMultiStore sur le type de job générique conditionne l'affichage du sélecteur.

👍

UPDATE

Affichage de l'ID d'exécution sur les jobs d'import et d'export

Contexte

Lorsqu'un job d'import ou d'export était en erreur, les utilisateurs devaient le signaler en indiquant des informations ambigüe (date, nom de job etc.).

Fonctionnement

Chaque exécution de job (import et export) affiche désormais son identifiant unique ("ID d'exécution") directement dans l'historique des exécutions :

• dans la liste des exécutions, via une colonne dédiée.
• dans le détail d'une exécution, sous la date.

Un bouton "Copier" permet de récupérer l'ID en un clic pour le transmettre au support DJUST lors d'un signalement d'incident. L'ID est visible pour tous les rôles BO, sans restriction.

Si un job n'a jamais été exécuté, aucun ID n'est affiché. Si l'UUID est trop long, il est tronqué visuellement avec un tooltip affichant l'identifiant complet.

📄 Documentation : Job Configuration Import Api Connector

Bénéfices

👉 Côté métier : identifiez précisément chaque exécution de job grâce à son ID unique et communiquez-le sans ambiguïté au support en cas d'incident.

👉 Côté technique : aucun développement backend — les champs jobStatusId (import) et exportIntegrationId (export) étaient déjà retournés par l'API. Changement purement front-end.

Capture manuelle des commandes PCard L3

Contexte

La capture manuelle d'un paiement depuis le Back-Office était limitée aux commandes de type CREDIT_CARD. Les commandes de type carte achat (PCARD_L3) nécessitent systématiquement une capture manuelle, mais cette action n'était pas disponible dans le BO pour ce type de paiement.

Fonctionnement

Lorsqu'une commande logistique remplit les conditions suivantes, le bouton de capture manuelle est désormais affiché dans le Back-Office :

• provider de paiement : DJUST_PAY
• type de paiement : PCARD_L3
• statut de paiement : AUTHORIZED

Le comportement de la capture reste identique à celui existant pour les cartes de crédit classiques.

📄 Documentation :

• Capture Level 3
• Introduction To Djust Pay

Bénéfices

👉 Côté métier : les opérateurs peuvent désormais capturer manuellement les commandes payées par carte achat (PCard L3) directement depuis le Back-Office.

👉 Côté technique : extension de la condition d'affichage du bouton de capture pour inclure le type PCARD_L3 en plus de CREDIT_CARD.

🛠️ API

📘

NEW

Calcul et exécution des payouts supplier

Contexte

Dans le cadre de DJUST PAY, les reversements fournisseurs (payouts supplier) doivent être calculés à partir des commandes éligibles, puis exécutés de manière contrôlée avec vérification des fonds disponibles. Ces deux étapes complètent le workflow de payout marketplace en offrant une gestion complète du cycle de vie des reversements.

Fonctionnement

Calcul des payouts

Pour une période donnée, DJUST PAY identifie toutes les commandes éligibles et les regroupe par supplier :

• Conditions d'éligibilité : statut de paiement PAID, statut logistique dans la liste configurée au niveau tenant (allowedLogisticStatuses), commande non déjà associée à un payout SETTLED ou PENDING.
• Le montant reversé correspond au montant net crédité sur le balance account supplier (montant capturé moins commissions marketplace, DJUST).
• Un payout est créé au statut COMPUTED par supplier. Si le montant est nul, le statut est SKIPPED.
• Le calcul est idempotent : relancer sur la même période ne duplique pas les payouts existants.

Exécution des payouts

Lorsqu'un payout est prêt (COMPUTED), DJUST PAY vérifie le solde du balance account supplier :

• Si les fonds sont suffisants : un payout PSP est déclenché depuis le BA supplier vers le compte bancaire du supplier. Le payout passe au statut PENDING.
• Si les fonds sont insuffisants : le payout passe au statut INSUFFICIENT_FUNDS, aucun appel PSP n'est effectué.
• La confirmation finale est gérée par webhooks PSP : succès → SETTLED (commandes marquées comme reversées), échec → FAILED (commandes restent éligibles pour un futur payout).

Traçabilité complète : date de tentative, date de confirmation, identifiant PSP, cause d'échec éventuelle.

Impact API

Nouvelles routes internes DJUST PAY pour le calcul et l'exécution des payouts supplier. Configuration des statuts logistiques éligibles via GET /v1/settings/payouts.

📄 Documentation :

• Supplier Payout Lifecycle
• Introduction To Djust Pay

Bénéfices

👉 Côté métier : les reversements fournisseurs sont calculés automatiquement à partir des commandes éligibles, avec vérification des fonds avant exécution et suivi complet du statut jusqu'à confirmation finale.

👉 Côté technique : cycle de vie complet des payouts supplier — COMPUTED → PENDING → SETTLED / FAILED, avec gestion du cas INSUFFICIENT_FUNDS et idempotence du calcul.

Configuration des modes de calcul des taxes

Contexte

Le calcul des taxes sur les lignes de commande logistique reposait uniquement sur un arrondi au niveau unitaire multiplié par la quantité. Cette approche pouvait générer des écarts par rapport à un calcul basé sur le montant total de la ligne, ne répondant pas aux exigences comptables de certains clients.

Fonctionnement

Deux modes de calcul exclusifs sont désormais disponibles :

• UNIT_ROUNDED_THEN_MULTIPLY (comportement existant, valeur par défaut) : la taxe est calculée sur le prix unitaire, arrondie, puis multipliée par la quantité.
• LINE_TOTAL_THEN_ROUND (nouveau) : la taxe est calculée sur le montant total de la ligne (prix unitaire × quantité), puis arrondie une seule fois.

La configuration est paramétrable au niveau tenant et surchargeable au niveau store. Le mode d'arrondi (roundingMode) est également configurable : centime supérieur, inférieur ou le plus proche (NEAREST). Le mode sélectionné s'applique de manière homogène à toutes les lignes d'une commande logistique et est persisté sur la commande pour traçabilité.

Rétrocompatibilité : le mode par défaut (UNIT_ROUNDED_THEN_MULTIPLY) est appliqué automatiquement si aucune configuration n'est définie.

Impact API

Nouvelles routes d'administration (réservées OPERATOR) :

• GET /v1/settings/tax-mode (operationId : ``) — récupération de la configuration tenant
• PUT /v1/settings/tax-mode (operationId : ``) — mise à jour de la configuration tenant → 204 No Content
• GET /v1/stores/{storeId}/tax-mode (operationId : ``) — récupération de la configuration store (avec fallback sur les valeurs par défaut)
• PUT /v1/stores/{storeId}/tax-mode (operationId : ``) — surcharge de la configuration au niveau store → 204 No Content

📄 Documentation : Tax Management With Custom Field Roles

Bénéfices

👉 Côté métier : adaptez le mode de calcul des taxes à vos exigences comptables, avec une granularité tenant ou store, sans impact sur les commandes existantes.

👉 Côté technique : quatre nouvelles routes d'administration pour la configuration des taxes. Le mode par défaut est conservé — aucun breaking change.

👍

UPDATE

Modification des prix confirmés en statut DRAFT

Contexte

La route d'administration de modification des prix confirmés (confirmedPrices) et quantités (confirmedQuantity) sur les lignes de commande logistique n'autorisait pas les modifications lorsque la commande était en statut DRAFT ou DRAFT_ON_HOLD. Cette limitation empêchait certains cas d'usage métier, notamment l'application d'escomptes dynamiques par un système externe avant finalisation de la commande.

Fonctionnement

Les champs confirmedPrices et quantity des lignes de commande logistique sont désormais éditables lorsque la commande est au statut DRAFT_ORDER ou DRAFT_ORDER_ON_HOLD, en plus des statuts déjà autorisés. L'opérateur doit disposer du droit ORDER_UPDATE.

Ce changement permet à un module externe (par exemple un moteur d'escompte) de modifier dynamiquement les prix confirmés sur les lignes avant la finalisation de la commande, puis de les restaurer si le parcours de paiement est abandonné.

Impact API

PUT /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId} — extension des statuts autorisés pour inclure DRAFT_ORDER et DRAFT_ORDER_ON_HOLD.

Bénéfices

👉 Côté métier : les prix confirmés et quantités des lignes de commande logistique peuvent être ajustés en amont de la finalisation, permettant des scénarios d'escompte dynamique.

👉 Côté technique : ajout des statuts DRAFT_ORDER et DRAFT_ORDER_ON_HOLD à la liste des statuts autorisant la modification via la route d'administration existante. Aucun breaking change.

Nouveau champ isReciprocal pour les related products

Contexte

La réciprocité entre produits liés (related products) pouvait être gérée via import, mais pas via l'API Back. Il n'était donc pas possible de définir ou de retirer la réciprocité d'une relation produit directement par appel API.

Fonctionnement

Un nouveau champ isReciprocal (booléen, optionnel, valeur par défaut false) est disponible sur la route de liaison de produits. Lorsqu'il est positionné à true, la relation est créée dans les deux sens : le produit A est lié au produit B, et inversement. Lorsqu'il est positionné à false ou absent, seule la relation unidirectionnelle est créée. Le retrait de la réciprocité supprime automatiquement la relation inverse.

Impact API

PUT /v1/products/{productId}/related-products/{relatedProductId} — nouveau champ isReciprocal (boolean, optionnel, défaut : false).

📄 Documentation : Ftp Related Products Import

Bénéfices

👉 Côté métier : gérez la réciprocité des produits liés directement via l'API, sans passer par un import.

👉 Côté technique : nouveau champ optionnel sur la route PUT existante. Rétrocompatible — le comportement par défaut (non réciproque) est inchangé.

Mise à jour partielle des configurations client Data Hub (PATCH)

Contexte

La mise à jour d’une configuration client (connecteur SFTP, API…) sur le Data Hub nécessitait un appel PUT imposant de renvoyer l’intégralité de l’objet, même pour modifier un seul champ. Cela complexifiait les intégrations et augmentait le risque d’écrasement involontaire de données.

Fonctionnement

Un endpoint PATCH est désormais disponible sur les configurations client. Seuls les champs fournis dans le body sont mis à jour, les champs absents conservent leur valeur existante :

• Modifier le statut actif/inactif d’une configuration sans toucher au reste
• Modifier la configuration du connecteur (SFTP, API…) sans changer le statut

Impact API

• Endpoint : PATCH /v1/mapper/client/{clientId}
• Réponse : 200 OK avec la configuration mise à jour
• Rétrocompatibilité : le PUT existant reste fonctionnel mais est déprécié

📄 Documentation : Api Client

Bénéfices

👉 Côté métier : modifiez uniquement les paramètres souhaités d'une configuration client Data Hub sans risquer d'écraser le reste de la configuration.

👉 Côté technique : endpoint PATCH standard. Le PUT existant reste fonctionnel.

Périmètre

Back-Office

👍

UPDATE

Export Order SFTP : exemple de format du nom de fichier

Contexte

Lors de la configuration d'un job d'export Order via SFTP, l'opérateur pouvait choisir le format du nom de fichier généré (Standard ou Short), mais aucune indication visuelle ne permettait de comprendre à quoi correspond chaque format ni son impact sur le fichier produit.

Fonctionnement

Un exemple de nom de fichier est désormais affiché directement dans l'interface de configuration du job d'export Order SFTP, en fonction du format sélectionné (Standard ou Short). L'opérateur visualise immédiatement le résultat attendu avant de valider sa configuration.

👉 Côté métier : comprenez en un coup d'œil le format de nommage de vos fichiers d'export SFTP grâce à l'exemple affiché lors de la configuration.

👉 Côté technique : aucun impact API — évolution purement interface Back-Office.

Pagination de la page des règles de quotas

Contexte

La page des règles de quotas (business pricing) dans le Back-Office présentait une pagination incomplète : la navigation entre les pages était limitée et le nombre total de résultats n'était pas affiché, rendant difficile le parcours de listes volumineuses.

Fonctionnement

La pagination de la page des règles de quotas est désormais alignée sur le standard des autres pages du Back-Office (commandes, produits, etc.) :

• Navigation complète entre les pages (première, précédente, suivante, dernière).
• Affichage du nombre total de résultats.

👉 Côté métier : naviguez facilement dans vos règles de quotas grâce à une pagination complète et au compteur de résultats, comme sur les autres pages du Back-Office.

👉 Côté technique : aucun impact API — correction de la pagination côté interface Back-Office uniquement.

Data Hub

📘

NEW

Arrêt manuel d'une exécution de job

Contexte

Lorsqu'une exécution de job Data Hub se bloquait, les exécutions suivantes s'accumulaient en statut PENDING sans possibilité pour l'opérateur d'intervenir depuis le Back-Office. Il fallait alors une action technique pour débloquer la file d'exécution.

Fonctionnement

Un bouton "Stopper l'exécution" est désormais disponible sur la page de détail d'un job Data Hub, au niveau de chaque exécution en cours. Le bouton est visible uniquement pour les exécutions dans un statut stoppable (JOB_INITIALIZING, JOB_STARTED, INTEGRATION_WAITING, INTEGRATION_STARTED, JOB_PENDING) et nécessite la permission MAPPER_WRITE.

• Une confirmation est demandée avant l'arrêt (action irréversible).
• Après arrêt, la liste des exécutions est rafraîchie automatiquement.
• Les exécutions terminées ou en erreur ne présentent pas le bouton.

Impact API

• POST /v1/mapper/status/{jobStatusId}/stop
• Paramètre : jobStatusId (ID de l'exécution, pas l'ID du job)
• Permission requise : MAPPER_WRITE
• Réponse : 200 OK (corps vide)

📄 Documentation : Job Configuration Overview

👉 Côté métier : débloquez vous-même une exécution de job Data Hub problématique directement depuis le Back-Office, sans intervention technique.

👉 Côté technique : nouveau bouton d'arrêt appelant POST /v1/mapper/status/{jobStatusId}/stop, conditionné par le statut de l'exécution et la permission MAPPER_WRITE.

👍

UPDATE

Jobs internes : client de connexion optionnel

Contexte

Jusqu'à présent, un client technique "Internal Client" était automatiquement créé pour les jobs de type Order Validation et Indexation, bien que ces jobs n'utilisent aucune connexion externe. Le champ clientConfigurationId étant obligatoire à la création de tout job, ce client inutile devait systématiquement être généré.

Fonctionnement

Le champ clientConfigurationId est désormais optionnel pour les jobs de type INDEXATION_JOB et ORDER_VALIDATION_JOB :

• Si le champ n'est pas renseigné pour ces types de jobs, aucune configuration client n'est sauvegardée en base.
• Pour tous les autres types de jobs (ex. PRODUCT_CSV), le client reste obligatoire — une erreur est retournée si le champ est absent.
• Les jobs internes existants avec un client configuré continuent de fonctionner à l'identique.

Impact API

• Endpoint : création de job Data Hub
• Champ modifié : clientConfigurationId devient nullable pour les jobs internes (INDEXATION_JOB, ORDER_VALIDATION_JOB)
• Rétrocompatibilité : aucun impact sur les jobs existants

📄 Documentation :

• Client Connection Overview
• Job Configuration Overview
• Job Configuration Export Api Connector
• Job Configuration Export Ftp

👉 Côté métier : le client technique "Internal Client" n'apparaît plus inutilement dans la liste des connexions, simplifiant la lisibilité de l'interface.

👉 Côté technique : simplification de la configuration des jobs internes et suppression d'une dépendance inutile au client de connexion.

Auto-activation des produits existants au réimport

Contexte

Jusqu'à présent, le setting "Auto-activate products & variants on import" n'était pris en compte que lors de la création d'un produit par import. Un produit créé avec le setting désactivé conservait le statut NEW même après un réimport avec le setting activé, obligeant à une activation manuelle depuis le Back-Office.

Fonctionnement

Le setting "Auto-activate products & variants on import" s'applique désormais également lors de la mise à jour d'un produit par import :

• Un produit en statut NEW est automatiquement passé à ACTIVE au réimport lorsque le setting est activé.
• Le comportement à la création reste inchangé.
• Les produits déjà en statut ACTIVE ou autre ne sont pas impactés.

📄 Documentation : Products And Variants

👉 Côté métier : éliminez l'étape manuelle d'activation des produits réimportés. Tous vos produits passent automatiquement en statut actif dès le réimport.

👉 Côté technique : le setting "Auto-activate products & variants on import" couvre désormais la création et la mise à jour, garantissant un comportement cohérent sur l'ensemble du cycle d'import.

API

👍

UPDATE

Synchronisation des commandes commerciales — Vérification de l'éligibilité des catalog views

Contexte

Dans le cadre de la synchronisation des commandes commerciales en mode standard (sans RTP), la vérification de l'éligibilité des produits vis-à-vis des catalog views n'était pas effectuée. Un produit retiré d'une catalog view pouvait rester dans une commande sans être détecté comme inéligible.

Fonctionnement

Lors de la synchronisation d'une commande commerciale, chaque ligne est désormais contrôlée sur la visibilité du produit dans les catalog views éligibles du customer user. Si un produit n'est plus visible dans le contexte courant (retrait d'une catalog view, changement de périmètre), un avertissement bloquant est remonté :

• Code F-W-015 — "The product with id {entityId} is not eligible in the current context."

Cette même vérification est également appliquée à l'ajout au panier : un produit non éligible dans les catalog views du contexte courant ne peut plus être ajouté à une commande commerciale.

Le comportement général de la synchronisation reste inchangé : en présence d'au moins un avertissement bloquant, aucune modification n'est appliquée à la commande et l'ensemble des avertissements est retourné.

Impact API

• PUT /v1/shop/commercial-orders/{commercialOrderId}/sync (operationId : ORDER-223)
• Nouveau code d'avertissement bloquant : F-W-015
• Référence complète des codes : Error / Warning codes

📄 Documentation :

• Products And Variants
• Synchronize A Draft Order

👉 Côté métier : les commandes commerciales sont désormais contrôlées sur la visibilité catalogue, garantissant qu'aucun produit inéligible ne persiste dans le panier ou la commande après synchronisation.

👉 Côté technique : nouveau warning bloquant F-W-015 sur la route de synchronisation et vérification d'éligibilité catalog view ajoutée à l'ajout au panier.

Filtrage par supplier sur les jobs d'export

Contexte

L'endpoint de listing des jobs d'export ne permettait pas de distinguer ni de filtrer les jobs par supplier. Les opérateurs devaient parcourir l'ensemble de la liste pour retrouver les jobs liés à un supplier spécifique.

Fonctionnement

• Un nouveau query parameter supplierIds permet de filtrer les jobs d'export par supplier.
• Lorsque supplierIds est renseigné, seuls les jobs configurés avec au moins un des suppliers indiqués sont retournés.
• Les jobs sans supplier configuré (export global) ne sont pas inclus lors d'un filtrage par supplier.
• Sans le paramètre supplierIds, tous les jobs sont retournés (comportement inchangé).
• La réponse inclut désormais les informations supplier (ID + nom) pour chaque job.

Impact API

• GET /v1/mapper/jobout
• Nouveau query parameter : supplierIds (type List<String>, optionnel) — ex. ?supplierIds=SUP1,SUP2
• Réponse enrichie : chaque job retourne la liste des suppliers associés (ID + nom)
• Rétrocompatibilité totale : sans le paramètre, le comportement reste identique.

📄 Documentation :

• Job Configuration Export Api Connector
• Job Configuration Export Ftp

👉 Côté métier : retrouvez instantanément les jobs d'export liés à un supplier spécifique, sans parcourir l'ensemble de la liste.

👉 Côté technique : nouveau paramètre de filtre supplierIds et informations supplier ajoutées dans la réponse de GET /v1/mapper/jobout.

Périmètre

API

📘

NEW

Liste des transactions

Contexte

DJUST expose désormais un endpoint dédié pour consulter l'ensemble des transactions de paiement. Il centralise la recherche, le filtrage et le tri des transactions directement dans l'API, sans passer par le PSP.

Fonctionnement

• Route réservée aux OPERATOR (dj-client: OPERATOR), contextualisée par dj-store.
• Recherche textuelle sur : référence de commande commerciale, compte client (nom, externalId), PSP reference, last event ID.
• Filtres : customerAccountIds, paymentMethods, paymentNetwork, status, lastEventStatus, amountMin/amountMax, updatedAtFrom/updatedAtTo, createdAtFrom/createdAtTo.
• Tri : updatedAt (défaut desc), createdAt, amount, status, commercialOrderReference.

Chaque transaction expose notamment : commercialOrderReference, customerAccountId/Name, paymentMethod, paymentNetwork, amount, status, lastEventStatus, pspReference, lastEventId, updatedAt, createdAt.

Impact API

• Endpoint : GET /v1/transactions
• operationId : ADM-TRANSACTION-550
• Accès : dj-client: OPERATOR
• Pagination : standard DJUST

👉 Côté métier : vue consolidée de toutes les transactions de paiement avec recherche et filtres avancés, directement dans DJUST.

👉 Côté technique : nouvel endpoint paginé, filtrable et triable — aucun impact sur les intégrations existantes.

Configuration des payouts fournisseur

Contexte

Dans un contexte marketplace, DJUST Pay calcule les payouts fournisseur à partir des commandes éligibles. Jusqu'à présent, toutes les commandes payées pouvaient être reversées, indépendamment du statut logistique. Cette évolution introduit une configuration tenant-level qui définit précisément quelles commandes sont éligibles à un payout supplier.

Fonctionnement

Une commande est éligible à un payout supplier si toutes les conditions sont remplies :

• Statut de paiement = SETTLED
• Statut logistique dans la liste des statuts autorisés (configurable par tenant, défaut : SHIPPED)
• Non déjà incluse dans un payout exécuté avec succès (SETTLED)

Les commandes associées à un payout FAILED, INSUFFICIENT_FUNDS ou SKIPPED restent éligibles pour un calcul ultérieur. L'éligibilité est indépendante du solde des balance accounts.

Deux nouveaux endpoints permettent de lire et modifier la configuration :

Impact API

• GET /v1/settings/payouts — operationId : ADM-SETTINGS-507 — lecture de la configuration
• PUT /v1/settings/payouts — operationId : ADM-SETTINGS-207 — mise à jour de la configuration (204 No Content)
• Accès : dj-client: OPERATOR uniquement
• Champ principal : supplierPayoutEligibility.allowedLogisticOrderStatuses (liste de statuts logistiques)
• Liste vide = aucune commande éligible. Statuts inconnus ignorés silencieusement.
• Rétrocompatibilité : comportement par défaut inchangé (SHIPPED), pas d'impact sur les tenants existants.

👉 Côté métier : contrôle précis de l'éligibilité des commandes au payout fournisseur, adapté aux contraintes de chaque client marketplace.

👉 Côté technique : deux nouveaux endpoints de settings, configuration tenant-level avec valeur par défaut — aucun impact sur les intégrations existantes.

👍

UPDATE

Data Hub (Import) - Fournisseur optionnel à l'import d'offres

Contexte

Lors de l'import d'offres via le Data Hub, l'external ID du supplier était obligatoire dans le fichier d'import, même pour les clients mono-fournisseur qui n'ont qu'un supplier par défaut généré automatiquement.

Fonctionnement

• La colonne supplierExternalId n'est plus obligatoire à l'import d'offres.
• Pour les clients non marketplace (mono-fournisseur) : si le supplier n'est pas renseigné, le système utilise automatiquement le supplier par défaut du tenant.
• Pour les clients marketplace : le champ reste obligatoire — une erreur est retournée si absent.
• Aucun changement si le champ est fourni explicitement.

👉 Côté métier : simplification des fichiers d'import pour les clients mono-fournisseur — plus besoin de renseigner un supplier Id technique.

👉 Côté technique : aucun breaking change — le champ reste accepté s'il est fourni. Fallback automatique côté backend pour les tenants non marketplace.

Data Hub (Import) - Réciprocité optionnelle des related products

Contexte

Lors d'un import de related products via le Data Hub, les produits étaient systématiquement reliés de façon réciproque (A ↔ B). Certains clients souhaitent pouvoir créer des relations univoques (A → B).

Fonctionnement

• Nouvelle colonne optionnelle Reciprocal dans le fichier d'import (défaut : true).
• true : relation réciproque (A ↔ B) — comportement existant inchangé.
• false : relation univoque (A → B).
• Renommage des colonnes pour plus de clarté : productId → Product External Id, delete → Remove Related Products.

👉 Côté métier : contrôle fin de la réciprocité des liens entre produits à l'import, sans impact sur les imports existants.

👉 Côté technique : nouvelle colonne optionnelle avec valeur par défaut — aucun breaking change.

⚠️

IMPORTANT UPDATE

Renommage de route Data Hub (suite)

Contexte

Suite du renommage des routes du Data Hub entamé en 3.107 — alignement avec les conventions DJUST (nom de ressource au pluriel).

Impact API

• Ancienne route : POST /v1/mapper/job/{id}/duplicate — supprimée
• Nouvelle route : POST /v1/mapper/jobs/{id}/duplicate
• Breaking change : les intégrateurs utilisant l'ancienne route doivent migrer vers la route pluralisée.

👉 Côté métier : aucun impact fonctionnel.

👉 Côté technique : remplacer /v1/mapper/job/{id}/duplicate par /v1/mapper/jobs/{id}/duplicate dans les appels existants.

Data Hub - Suppression d'anciens types de jobs Orders

Contexte

Dans le cadre de l'harmonisation du naming des jobs Orders et de la clarification des cas d'usage entre import et mise à jour de commandes, certains anciens enums devenus obsolètes sont supprimés.

Fonctionnement

L'endpoint POST /v1/mapper/jobs n'accepte plus les types de job suivants dans le champ jobType :

Les nouveaux enums couvrent exactement les mêmes comportements fonctionnels.

Impact API

• Endpoint : POST /v1/mapper/jobs
• Champ : jobType
• Enums supprimés : EXTERNAL_ORDER_CSV_JOB, ORDER_API_JSON_JOB
• Breaking change : les intégrateurs utilisant les anciens enums doivent migrer vers les nouveaux.

👉 Côté métier : aucun impact fonctionnel, les comportements restent identiques.

👉 Côté technique : remplacer les anciens enums par leurs équivalents dans les appels de création de job.

Périmètre

API

📘

NEW

Liste des événements de transaction

Contexte

DJUST expose désormais l'historique complet des événements de paiement directement via l'API. Jusqu'à présent, le suivi détaillé des événements (autorisations, captures, remboursements, chargebacks…) nécessitait de passer par support pour avoir le détail. Ce nouvel endpoint centralise toutes les informations dans DJUST, avec une gestion fine des droits selon le rôle appelant.

Fonctionnement

L'endpoint retourne une liste paginée de tous les événements de paiement enregistrés sur les transactions du tenant.

• OPERATOR (dj-client: OPERATOR) : accès à l'ensemble des événements.
• SUPPLIER (dj-client: SUPPLIER) : accès restreint aux événements liés à ses propres transactions. Sur les événements d'autorisation de commande commerciale, les montants et le détail fournisseur sont masqués tant que l'événement n'a pas atteint le statut CAPTURED.

Recherche et filtres :

• Recherche textuelle sur orderReference, supplier (nom ou identifiant), eventId
• Filtres : status, amountMin, amountMax, transactionId, logisticOrderReference
• Tri : createdAt (défaut ascendant), amount, status, orderReference

17 statuts couvrent le cycle de vie complet du paiement : INIT_PAYMENT, AUTHORIZED, CAPTURED, PAID, REFUNDED, CHARGEBACK, etc.

Les événements sont append-only : l'historique est immuable et constitue une trace d'audit fiable.

Impact API

• Endpoint : GET /v1/transactions/events
• operationId : ADM-TRANSACTION-551
• Accès : dj-client: OPERATOR ou SUPPLIER
• Pagination : standard DJUST
• Rétrocompatibilité : nouvel endpoint, aucun impact sur les intégrations existantes

Bénéfices

👉 Côté métier : visibilité complète sur le cycle de vie des paiements sans quitter l'écosystème DJUST — suivi des autorisations, captures, remboursements et chargebacks en un seul point.

👉 Côté technique : endpoint unique, paginé et filtrable, avec gestion fine des droits OPERATOR/SUPPLIER et un historique append-only garantissant l'intégrité de la trace d'audit.

👍

UPDATE

Synchronisation des commandes commerciales - Mode standard

Contexte

Dans le cadre de l'Order-based Checkout, une commande commerciale en DRAFT peut rester ouverte pendant un temps significatif avant d'être placée. Entre-temps, les données du catalogue peuvent évoluer : prix mis à jour, stocks réduits, produits désactivés, règles de quantité modifiées.

Jusqu'à présent, ces écarts n'étaient détectés qu'au moment du placement (ORDER-212), ce qui pouvait provoquer des erreurs inattendues pour l'acheteur.

Le nouvel endpoint de synchronisation permet de réconcilier une commande DRAFT avec l'état courant du catalogue DJUST à tout moment, sans attendre le placement.

Fonctionnement

La synchronisation valide l'ensemble des lignes existantes de la commande contre les données persistées dans DJUST (mode standard - aucune API externe impliquée) :

• Catalogue : statut d'activation des produits et variants, visibilité dans les vues catalogue
• Prix : valeurs des offer prices, éligibilité par compte ou groupe de comptes
• Stock : niveaux d'inventaire des offres
• Règles de quantité : minimum, maximum, item per pack
• Custom fields : validité des champs personnalisés (offre, commande, ligne)

Le endpoint retourne un tableau de warnings, chacun portant un flag blocked :

• blocked: true (bloquant) : la commande n'est pas modifiée. Tous les warnings sont retournés pour correction.
• blocked: false (informatif) : la commande est mise à jour. Le warning signale un changement appliqué automatiquement (ex : mise à jour du prix unitaire).

Si au moins un warning bloquant existe, aucune modification n'est appliquée à la commande.

En cas de succès, le champ lastSyncAt est mis à jour sur la commande commerciale. Ce timestamp peut être utilisé pour décider si une re-synchronisation est nécessaire.

Quand appeler la synchronisation

• A l'affichage de la commande : à chaque ouverture ou retour sur la vue de la commande DRAFT
• Après édition des lignes : après ajout, suppression ou modification de quantités
• Avant le placement : comme vérification finale avant ORDER-212

Impact API

• Endpoint : PUT /v1/shop/commercial-orders/{commercialOrderId}/sync
• operationId : ORDER-223
• Accès : dj-client: ACCOUNT uniquement
• Paramètre de chemin : commercialOrderId de type REFERENCE
• Pas de body : la synchronisation s'applique à toutes les lignes existantes
• Réponse : 200 OK avec un tableau de warnings (vide si tout est à jour)
• Nouveau champ : lastSyncAt sur la commande commerciale
• Rétrocompatibilité : aucun impact sur les intégrations existantes - nouvel endpoint optionnel

Pour la liste complète des codes de warning (F-W-001 à F-W-030) et des codes d'erreur, voir Error / Warning codes.

Bénéfices

👉 Côté métier : les acheteurs visualisent toujours des prix et disponibilités à jour sur leur commande, et les écarts sont détectés bien avant le placement.

👉 Côté technique : nouvel endpoint idempotent, sans body, retournant un diagnostic complet des lignes. S'intègre naturellement dans le flux Order-based Checkout existant sans modifier les endpoints actuels.

Data Hub (Import) - Support multi-store

Contexte

Dans un contexte multi-stores, l'association entre les entités importées et les stores se faisait jusqu'ici exclusivement via la colonne StoreId du fichier CSV. Cette évolution permet de définir le ou les stores au niveau de la configuration du Job, rendant facultative la définition du store dans le fichier d'import.

Fonctionnement

• Configurez directement les stores cibles sur un job d'import via le nouveau champ storeExternalIds. Toutes les entités importées par ce job seront automatiquement associées aux stores choisis.
• La colonne StoreId du fichier CSV devient facultative : si des stores sont configurés sur le job, la colonne CSV est ignorée silencieusement.
• Sans configuration, le comportement existant est inchangé : l'association se fait via la colonne CSV comme avant.
• Un nouvel indicateur isMultiStore identifie les types de jobs compatibles (produits, fournisseurs, offres, attributs, customer users, assortiments).
• Toute modification de configuration prend effet à la prochaine exécution du job.

Impact API

• GET /v2/mapper/job/generic-job-types — Champ ajouté : isMultiStore (boolean)
• POST /v2/mapper/job — Champ ajouté : storeExternalIds (list, optionnel, défaut : vide)
• PATCH /v2/mapper/job/{jobId} — Champ ajouté : storeExternalIds (list, optionnel)
• Rétrocompatibilité : aucun impact sur les intégrations existantes — champ optionnel, comportement par défaut inchangé.

👉 Côté métier : les clients multi-stores peuvent configurer l'association aux stores directement sur le job sans modifier les fichiers CSV.

👉 Côté technique : nouveau champ storeExternalIds sur les endpoints de création/mise à jour de job, avec override automatique lors du processing.

⚠️

IMPORTANT UPDATE

Renommage de route Data Hub

Contexte

Alignement de la nomenclature des routes du Data Hub avec les conventions DJUST (nom de ressource au pluriel).

Impact API

• Ancienne route : GET /v1/mapper/job/{id} — supprimée
• Nouvelle route : GET /v1/mapper/jobs/{id}
• Breaking change : les intégrateurs utilisant l'ancienne route doivent migrer vers la route pluralisée.

👉 Côté métier : aucun impact fonctionnel.

👉 Côté technique : remplacer /v1/mapper/job/{id} par /v1/mapper/jobs/{id} dans les appels existants.

La version 3.105.0 initialement prévue la semaine du 16 février sortira avec la 3.106.0 la semaine du 24 février 2026.

Périmètre

BackOffice

• Ajout des noms de comptes (avec tris) sur les listes de configuration des Buying Policies d'encours.

Afin de faciliter la lecture et la configuration, les noms sont désormais affichés dans les listes de configuration des tolérances d'encours et dans les blocages de comptes.

Il est aussi possible de trier sur le nom du compte par ordre alphabétique ou inverse.

• Ajout de l'affectation de stores aux utilisateurs opérateurs

Les utilisateurs opérateurs sont désormais liés aux stores. Ainsi, il est possible d'activer une segmentation par store entre les utilisateurs du backoffice.

⚠️

Attention

• Tous les utilisateurs créés avant cette version seront systématiquement affectés sur TOUS les stores existants pour assurer la rétrocompatibilité.
• Les environnements sans store ne sont pas concernés.
• La création d'un nouvel opérateur après cette version n'aura pas d'affectation par défaut. Il faudra explicitement préciser les stores liés à cet utilisateur.

• Import et mise à jour de commandes via le Connecteur API

Le job d'import de commandes est désormais disponible via le Connecteur API

Il permet d’exécuter les mêmes opérations que l’import de commandes par CSV tout en s’intégrant directement à vos APIs :

• Créer des commandes externes
• Mettre à jour des commandes existantes (internes ou externes)
• Ajouter ou modifier des lignes
• Supprimer des lignes
• Mettre à jour le statut des commandes

Lors de la configuration du job, il suffit de sélectionner le type ORDER et le connecteur de type API.

• Renommage du job de mise à jour de commandes internes via le Connecteur API

Le job de mise à jour de commandes internes via le Connecteur API est désormais nommé: ORDER_UPDATE.

Il permet exclusivement de mettre à jour des commandes internes en s’intégrant directement à vos APIs :

• Ajouter ou modifier des lignes
• Supprimer des lignes
• Mettre à jour le statut des commandes

Lors de la configuration du job, il suffit de sélectionner le type ORDER_UPDATE.

API

📘

NEW

Stores

• Affectation de stores aux operator users

Contexte

Dans un environnement multi-stores, tous les operator users avaient jusqu'ici une visibilité sur l'ensemble des stores du tenant dans le Back Office DJUST. Il n'était pas possible de restreindre l'accès d'un utilisateur à un périmètre de stores spécifique.

Cette évolution introduit la possibilité de rattacher un operator user à un ou plusieurs stores, posant ainsi les bases d'une segmentation par store dans le Back Office. Un opérateur affecté uniquement aux stores France et Belgique ne verra pas les stores Allemagne ou Espagne dans son interface.

Fonctionnement

• Accès explicite uniquement : il n'existe pas de mode implicite "tous les stores". L'affectation doit être réalisée store par store. Pour donner accès à l'ensemble des stores, il faut envoyer la liste complète.
• Pas d'héritage automatique : lorsqu'un nouveau store est créé sur le tenant, il n'est pas automatiquement accessible aux operator users existants. L'accès doit être explicitement ajouté.
• Création d'un operator user : par défaut, aucun store n'est affecté à la création. L'affectation se fait dans un second temps via les endpoints dédiés.
• Identification des stores : les stores sont référencés par leur externalId (identifiant externe).
• Rétrocompatibilité : les operator users existants ne sont pas impactés. Tant qu'aucune affectation n'est configurée, le comportement reste inchangé.

Impact API

Nouvelle sous-ressource sur le domaine Operator Users :

Les endpoints d'écriture (PUT, PATCH, DELETE) acceptent un body avec le champ storeExternalIds (tableau d'identifiants externes de stores). Accès réservé aux operator users (dj-client: OPERATOR).

Bénéfices

👉 Côté métier : permet de segmenter la visibilité des operator users par store dans le Back Office, renforçant le contrôle des accès dans les organisations multi-stores.

👉 Côté technique : 4 nouveaux endpoints CRUD dédiés à la gestion de l'affectation store/operator user, avec une approche explicite (pas de "all stores" implicite) garantissant un contrôle fin des accès.

Transactions

• API de détail d’un événement de transaction de paiement

Contexte

Djust expose désormais une API dédiée pour récupérer le détail complet d’un événement de transaction (authorization, capture, refund, etc.) à partir de son identifiant eventId.

Objectif : permettre l’investigation fine d’un paiement à une étape précise, avec références PSP, informations d’erreur, et breakdown des montants / commissions selon le profil utilisateur.

Nouvelle API

ADM-TRANSACTION-552 - GET /v1/transactions/events/{eventId}

Retourne la fiche détail d’un event identifié par eventId, destinée à alimenter la page “Event detail”.

Règles de visibilité

• OPERATOR : peut accéder à n’importe quel event (tous suppliers / toutes transactions).
• SUPPLIER : peut accéder uniquement aux events liés à ses propres commandes logistiques / transactions.

• Liste des événements de transaction de paiement

Contexte

Une nouvelle API Backend permet désormais de consulter la liste des événements de paiement associés à une transaction commerciale, avec support de la recherche, des filtres, du tri et de la pagination.

Cette API expose une vision event-based du cycle de vie d’un paiement (authorization, capture, refund, etc.) afin de faciliter le diagnostic, l’audit et le support.

Nouvelle API

ADM-TRANSACTION-551 - GET /v1/transactions/events

Permet de récupérer la liste chronologique des événements rattachés à une transaction.

Règles de visibilité

• OPERATOR :
  • Accès à tous les events de toutes les transactions
  • Accès aux suppliers liés aux events
• SUPPLIER:
  • Accès uniquement aux events rattachés à ses propres transactions / commandes logistiques

👍

UPDATE

Cart v1 / v2

• L'ensemble des routes historiques Cart v1 et v2 sont désormais dépréciées

Il est fortement conseillé de migrer progressivement vers les API "Order based checkout". Les routes historiques Cart v1 et v2 ne sont plus mises à jour.

Les routes sont évidemment toujours disponibles mais ne bénéficieront plus d'évolution (hors anomalie bloquante).

L'ensemble de ces routes sera supprimé à moyen terme quand l'ensemble des migrations client aura été sécurisée.

Liste des APIs concernées :

CART-100 : POST /v1/shop/carts (Créer un panier)
CART-300 : DELETE /v1/shop/carts (Supprimer un panier)
CART-500 : GET /v1/shop/carts (Récupérer un panier)
CART-201 : PUT /v1/shop/carts/{cartId} (Affecter ou modifier une adresse de facturation/livraison)
CART-200 : PUT /v1/shop/carts/{cartId}/lines (Ajouter/Mettre à jour/Supprimer des lignes)
CART-301 : DELETE /v1/shop/carts/{cartId}/lines (Supprimer des lignes de panier)

ORDER-202 : PUT /v1/shop/commercial-orders/{orderCommercialId}/shipping-address
ORDER-100 : POST /v1/shop/commercial-orders

Fast-cart v1 :
CART-101 : POST /v1/shop/carts/import (Initialiser un import fast-cart depuis un fichier)
CART-551 : GET /v1/shop/carts/import (Récupérer la progression d'un import fast-cart)
CART-506 : GET /v1/shop/carts/import/error-report (Récupérer le rapport d'import fast-cart)

CART-550 : GET /v2/shop/carts (Récupérer les paniers paginés)
CART-351 : DELETE /v2/shop/carts (Supprimer tous les paniers)
CART-100 : POST /v2/shop/carts (Créer un panier)
CART-500 : GET /v2/shop/carts/{cartId} (Récupérer un panier par ID)
CART-200 : PUT /v2/shop/carts/{cartId} (Mettre à jour un panier)
CART-300 : DELETE /v2/shop/carts/{cartId} (Supprimer un panier)
CART-101 : POST /v2/shop/carts/{cartId}/initialize-orders (Initialiser les commandes en DRAFT)
CART-551 : GET /v2/shop/carts/{cartId}/lines (Récupérer les lignes de panier paginées)
CART-150 : PUT /v2/shop/carts/{cartId}/lines (Ajouter/Mettre à jour/Supprimer des lignes)
CART-350 : DELETE /v2/shop/carts/{cartId}/lines (Supprimer des lignes de panier)
CART-151 : PUT /v2/shop/carts/{cartId}/lines-by-variant (Mettre à jour les lignes par variante)

Mapper

• Les routes historiques listées ci-dessous sont désormais dépréciées

Elles ont été dupliquées et remplacées par de nouveaux endpoints respectant les standards REST.

Les routes dépréciées restent disponibles mais ne sont plus amenées à évoluer.

Ces routes seront supprimées à moyen terme après sécurisation des migrations.

• Filtrage des exports de commandes par Supplier

Contexte

Lors d’un export de commandes, il est parfois nécessaire d’envoyer uniquement les commandes d’un Supplier donné vers son système cible. Jusqu’ici, un job unique exportait l’ensemble des commandes vers un ERP central, laissant le dispatch multi-fournisseurs côté client.

Fonctionnement

Les endpoint POST /jobout et PUT /jobout/{jobOutId} acceptent désormais un champ suppliers dans le body de la requête.

• Ajout ou mise à jour : le champ suppliers permet de définir la liste des supplierExternalId autorisés pour le job d’export. Lors d’une création ou d’une mise à jour, la valeur fournie remplace la configuration existante.
• Suppression : envoyer suppliers avec une chaîne vide ("") efface le filtrage par Supplier.
• Comportement par défaut : si suppliers est vide ([]) ou Null, toutes les commandes éligibles sont exportées.

Impact API

Endpoint : POST /jobout

• Nouveau champ modifiable : suppliers (type list)
• Réponse : 201 Created (inchangé)
• Accès : dj-client: OPERATOR
• Rétrocompatibilité : aucun impact sur les intégrations existantes — le champ est optionnel.

Endpoint : PUT /jobout/{jobOutId}

• Nouveau champ modifiable : suppliers (type list)
• Réponse : 200 OK (inchangé)
• Accès : dj-client: OPERATOR
• Rétrocompatibilité : aucun impact sur les intégrations existantes — le champ est optionnel.

Bénéfices

👉 Côté métier : permet de gérer nativement les exports de commandes multi-fournisseurs directement depuis DJUST.

👉 Côté technique : nouveau champ optionnel sur un endpoint existant, aucun breaking change. Les intégrations actuelles fonctionnent sans modification.

• Création de job d'import de commandes via API pour le Connecteur API

Contexte

Avec l’introduction de l’import et de la mise à jour de commandes via Connecteur API, il est désormais possible de configurer un job dédié par API.

Fonctionnement

L’endpoint POST /v1/mapper/jobs accepte désormais un nouveau type de job ORDER_API_JOB dans le champ jobType.

Impact API

• Endpoint : POST /v1/mapper/jobs
• Champ : jobType
• Nouvel enum : ORDER_API_JOB
• Réponse : 201 Job successfully created (inchangé)
• Accès : dj-client: OPERATOR

Bénéfices

👉 Côté métier : Permet de configurer des imports de commandes via API sans dépendre d’un flux CSV.

👉 Côté technique : nouvel enum sur un endpoint existant, aucun breaking change. Les intégrations actuelles fonctionnent sans modification.

• Renommage du type de job d’update de commandes internes via le Connecteur API

Contexte

Avec l’introduction de l’import de commandes via Connecteur API, le périmètre de l'objet Order a été clarifié afin de mieux distinguer :

• l’import et la mise à jour globale de commandes.
• la mise à jour spécifique des commandes internes.

Dans ce cadre, le type de job précédemment nommé ORDER_API_JSON_JOB porte le nouveau nom ORDER_UPDATE_API_JSON_JOB

Fonctionnement

L’endpoint POST /v1/mapper/jobs accepte désormais le type de job ORDER_UPDATE_API_JSON_JOB dans le champ jobType.

Ce type de job est dédié uniquement à la mise à jour de commandes internes via Connecteur API.

Aucun changement fonctionnel n’est introduit :

• le comportement du job reste identique
• seule la dénomination évolue pour refléter plus clairement son usage.

Impact API

• Endpoint : POST /v1/mapper/jobs
• Enum renommé : ORDER_API_JSON_JOB → ORDER_UPDATE_API_JSON_JOB
• Réponse : 201 Job successfully created (inchangé)
• Accès : dj-client: OPERATOR

• Renommage du type de job d'import et de mise à jour de commandes via CSV

Contexte

Avec l’introduction de l’import de commandes via Connecteur API, le périmètre de l'objet Order a été clarifié afin de mieux distinguer :

• l’import et la mise à jour globale de commandes.
• la mise à jour spécifique des commandes internes.

Dans ce cadre, le type de job précédemment nommé EXTERNAL_ORDER_CSV_JOB porte le nouveau nom ORDER_CSV_JOB

Fonctionnement

L’endpoint POST /v1/mapper/jobs accepte désormais le type de job ORDER_CSV_JOB dans le champ jobType.

Ce job permet toujours par CSV :

• La création de commandes externes
• La mise à jour de commandes existantes
• L’ajout, la modification ou la suppression des lignes
• La mise à jour du statut des commandes

Impact API

• Endpoint : POST /v1/mapper/jobs
• Enum renommé : EXTERNAL_ORDER_CSV_JOB → ORDER_CSV_JOB
• Réponse : 201 Job successfully created (inchangé)
• Accès : dj-client: OPERATOR

Orders

• Mise à jour de l'external ID sur les commandes logistiques

Contexte

Lorsqu'une commande logistique est manipulée à la fois depuis un front-end (Back Office) et un middleware (ERP, WMS…), il est nécessaire de pouvoir injecter ou mettre à jour l'identifiant externe (externalId) de la commande après sa création. Jusqu'ici, ce champ ne faisait pas partie des champs modifiables via l'API d'administration.

Fonctionnement

Le endpoint ADM-ORDER-201 - PATCH /v1/logistic-orders/{logisticOrderId} accepte désormais le champ externalId dans le body de la requête :

• Ajout ou mise à jour : envoyer externalId avec une valeur non vide assigne ou remplace l'identifiant externe existant.
• Suppression : envoyer externalId avec une chaîne vide ("") efface l'identifiant externe.
• Pas d'impact sur le cycle de vie : la modification de l'externalId n'affecte ni le statut de la commande, ni l'identifiant interne DJUST, ni les traitements déjà effectués.
• Mise à jour partielle : comme pour les autres champs du PATCH (shippingTrackingUrl, customFieldValues), seuls les champs envoyés sont modifiés.

Impact API

• Endpoint : PATCH /v1/logistic-orders/{logisticOrderId} — ADM-ORDER-201
• Nouveau champ modifiable : externalId (type string)
• Réponse : 204 No Content (inchangé)
• Accès : dj-client: OPERATOR ou SUPPLIER
• Rétrocompatibilité : aucun impact sur les intégrations existantes — le champ est optionnel.

Bénéfices

👉 Côté métier : permet de synchroniser l'identifiant externe d'une commande logistique entre le Back Office et un système tiers (ERP, WMS), sans recréation de commande.

👉 Côté technique : nouveau champ optionnel sur un endpoint existant, aucun breaking change. Les intégrations actuelles fonctionnent sans modification.

Périmètre

Back Office Djust

Finalisation d'une commande

Il est désormais possible de finaliser une commande (la passer au statut terminé) à partir du statut SHIPPED via le Back Office depuis la page détail de commande.

👍

UPDATE

Reset Password

• Nouveau champ activationResult a été ajouté à la réponse de l’API de reset password.

Lorsqu’un mot de passe est défini pour la première fois, le Customer User peut, sous certaines conditions, être automatiquement activé.

Le champ activationResult indique le résultat de cette tentative d’activation :

ACTIVATED : l’utilisateur vient d’être activé

ALREADY_ACTIVE : l’utilisateur était déjà actif

NOT_ACTIVATED : l’activation a échoué lors des validations

Mise à jour API

POST /auth/reset-password

Nouveau champ de réponse : activationResult

Assortiments

• Filtres numériques sur le nombre de produits et de variants

L’endpoint d'administration GET /v1/assortments permet désormais de filtrer les assortments selon le nombre de variants (productVariantCount) et le nombre de produits (productCount) qu’ils contiennent.

Pour chaque métrique, deux filtres numériques (non multi-valeurs) sont exposés : Min et Max. Lorsqu’un seul seuil est renseigné, le filtrage s’applique de manière unilatérale (≥ Min ou ≤ Max). Lorsque les deux sont fournis, le filtrage s’effectue sur un intervalle inclusif.

L’ensemble de ces filtres est optionnel et cumulable avec le paramètre search existant (limité aux champs de l’assortment) ainsi qu’avec les filtres multi-valeurs produit / variant. La combinaison des filtres de natures différentes suit une logique AND : un assortment doit respecter l’ensemble des contraintes appliquées pour être retourné.

• Filtres multi-valeurs sur le contenu Produit / Variant

L’endpoint d'administration GET /v1/assortments supporte désormais des filtres multi-valeurs permettant de restreindre la liste des assortments en fonction du contenu produit et/ou variant qu’ils contiennent, en complément du paramètre search (qui reste limité aux champs de l’assortment).

Les filtres productIds[] et variantIds[] sont disponibles et acceptent des IDs Djust. Chaque filtre est optionnel. Les valeurs d’un même filtre sont combinées avec une logique OR, tandis que les filtres entre eux sont combinés avec une logique AND.

Un assortment est retourné dès lors qu’il contient au moins un produit ou variant correspondant aux filtres appliqués.

⚠️

IMPORTANT UPDATE

ORDER-560 - Correctif sur le retour des valeurs d'attributs sur les lignes de commandes

Les valeurs d'attributs produits retournés dans cette API rencontraient un problème. Les chaines de caractères et listes de chaines étaient échappées à tort. Un backslash était systématiquement ajouté en début et fin de valeurs.

Désormais les chaines de caractères n'ont plus de caractères d'échappement.

Périmètre

API

👍

UPDATE

Buying Policies

• Ajout du nom du compte dans le retour API de récupération des blocages de BP d'encours

La réponse de l'API ADM-BUYING-POLICY-550 évolue pour remonter également le nom du compte : accountName. Il permet de mieux identifier les comptes associés aux configurations de blocages des buying policies d'encours.

Le nouvel attribut accountName est également filtrable et triable.

• Alimentation en continu de l'encours courant pour chaque compte

Désormais, les buying policies d'encours évoluent pour alimenter en continu l'encours courant de chaque compte. Jusqu'à présent, on se basait uniquement sur les valeurs synchronisées avec un système distant sur chaque compte. C'était source d'erreurs potentielles pour les validations, l'encours n'était recalculé que sur un jour calendaire et non sur une période glissante.

Maintenant, l'encours est systématiquement incrémenté à chaque commande validée pour refléter au plus près la réalité. Il peut être écrasé par une synchronisation quotidienne comme c'était le cas jusqu'à présent.

Périmètre

🚀 Gestion catalogue centrée sur le variant

La plateforme évolue pour adopter une gestion catalogue unifiée au niveau du variant, aussi bien dans les Assortiments que dans les Catalog Views.

Cette évolution améliore la lisibilité, le contrôle et la cohérence de la gestion des catalogues.

🎯 Objectif

Permettre aux opérateurs de :

• contrôler précisément quels variants sont visibles dans les catalogues,
• comprendre rapidement où un produit ou un variant est utilisé,
• gérer les contenus sans doublons ni ambiguïté.

📋 Listes Assortments

La liste des assortiments permet aux operators de visualiser et de gérer efficacement leurs assortiments grâce à des informations enrichies et des outils de recherche avancés.

Chaque assortiment affiche désormais le nombre de produits et le nombre de variants qu’il contient, offrant une meilleure compréhension de sa composition. La liste peut être affinée à l’aide d’une recherche textuelle insensible à la casse sur le nom et l’identifiant externe de l’assortiment, ainsi que de filtres par source, date minimale de création ou de mise à jour, et catégories de navigation personnalisées. Ces fonctionnalités facilitent l’identification rapide des assortiments pertinents et améliorent leur gestion dans l’interface, sans modifier le comportement existant des assortiments.

📋 Listes Produits & Variants

• Introduction de deux vues complémentaires dans la page de detail d’un assortiment et restrictions de catalogue:
  • Vue Produit : vision globale avec indicateur de couverture des variants.
  • Vue Variant : vision détaillée des variants réellement inclus.
• Bascule instantanée entre les vues
• Recherche intégrée, adaptée à la vue active.

➕➖ Ajout et retrait (Assortiments & Catalog Views)

• Ajout possible :
  • par produit (tous les variants inclus),
  • ou par variant (gestion granulaire).
• Actions unitaires ou en masse, avec confirmation.
• Prévention des doublons : éléments déjà présents grisés.
• Retrait possible par produit ou par variant, avec nettoyage automatique.

🧾 Pages de détail produit et variant

Variant

• Affiche les :
  • Assortiments
  • Catalog Views
  • Navigation Categories dans lesquels le variant est utilisé.
• Recherche disponible dans chaque section.

Produit

• Vue consolidée des usages via ses variants :
  • assortiments
  • catalog views concernés

🔌 APIs – Détail des évolutions

🆕 Nouveaux endpoints

Catalog Views

• GET /v1/catalog-views/{id}/product-variants
  • Liste paginée des variants inclus dans un Catalog View
  • Recherche sur les champs variant et produit parent
  • Tri par défaut : product.name, variant.name
• POST /v1/catalog-views/{id}/product-variants
  • Ajout de variants à un Catalog View
• DELETE /v1/catalog-views/{id}/product-variants
  • Retrait de variants d’un Catalog View

Assortiments

• GET /v1/assortments/{id}/variants
  • Liste paginée des variants d’un assortiment
  • Filtrage possible par produit

Produit

• GET /v1/products/{id}/assortments
  • Liste des assortiments contenant au moins un variant du produit
• GET /v1/products/{id}/catalog-views
  • Liste des Catalog Views contenant des variants du produit

Variant

• GET /v1/product-variants/{id}/assortments
• GET /v1/product-variants/{id}/catalog-views
• GET /v1/product-variants/{id}/navigation-categories

Tous les endpoints ci-dessus supportent le paramètre search.

🔄 APIs mises à jour

• GET /v1/catalog-views/{id}/products
  • Ajout des champs :
    • variantsIncludedCount
    • variantsTotalCount
  • Introduction d’un nouveau DTO allégé.
• GET /v1/assortments/{id}/products
  • Désormais basé sur l’association assortment ↔︎ variant.
• GET /v1/assortments
• Enrichissement de la réponse avec les champs :
  • productCount
  • productVariantCount
• Introduction d’un nouveau DTO dédié afin d’éviter les impacts sur les usages existants.
• Ajout de nouveaux paramètres de recherche et de filtrage :
  • search : recherche insensible à la casse sur :
    • nom de l’assortiment
    • external ID de l’assortiment
  • externalSources : filtrage par source (valeurs documentées dans le Swagger ; toute valeur inconnue retourne simplement aucun résultat)
  • createMinDate : date minimale de création (borne inférieure uniquement)
  • updateMinDate : date minimale de dernière mise à jour (borne inférieure uniquement)
  • navigationIds : récupération des assortiments liés à une ou plusieurs catégories de navigation custom

⚠️ dépréciées :

• POST /v1/catalog-views
  • Dépréciation de la liste des produits au profit de la gestion par variants.

API

👍

UPDATE

Djust Pay Marketplace

• Calcul dynamique des commissions et application des splits à la capture CB

Contexte

Djust PAY gère désormais le calcul dynamique des commissions et l’application des splits financiers directement lors de la capture carte bancaire. Jusqu’à présent, l’autorisation CB était réalisée sans split, et la capture ne permettait pas de refléter précisément les répartitions contractuelles entre la plateforme, la marketplace et le fournisseur.

Cette évolution permet d’appliquer, au moment de la capture, des splits complets et conformes aux accords financiers, tout en conservant un haut niveau de sécurité et de traçabilité.

Fonctionnement métier

• Les commissions sont calculées exclusivement côté backend Djust PAY, sans aucune influence possible des clients ou fournisseurs.
• Deux sources de vérité sont utilisées :
  • le taux de commission plateforme (settings tenant),
  • le taux de commission marketplace fournisseur (matrice marketplace).
• Chaque taux est optionnel.

API

• Le contrat API de la capture CB ADM-PAY-101 ne change pas, il s'appuie juste automatiquement sur les règles de splits configurées.

Commandes

• Nouveau droit de validation des commandes logistiques pour les customer users

Contexte

Il est désormais possible, pour les administrateurs de la plateforme, de donner ou retirer le droit de valider une commande logistique à un customer user, y compris pour ses propres commandes. Cette évolution répond à des besoins de séparation des rôles et de supervision, notamment lorsque certaines commandes doivent être relues, corrigées ou reprises par un utilisateur tiers (manager, superviseur, back-office interne).

Fonctionnement métier

🆕 Nouveau droit : ORDER_VALIDATE Un nouveau droit explicite est introduit pour contrôler la capacité d’un utilisateur à sortir une commande de la phase de checkout.

• ORDER_VALIDATE = true (cas par défaut)
  • comportement identique à l’existant :
    • l’utilisateur peut valider ses propres commandes,
    • s’il dispose aussi de ORDER_VALIDATE_ON_ALL_ACCOUNT, il peut valider toutes les commandes du compte (les siennes et celles des autres).
• ORDER_VALIDATE = false
  • l’utilisateur ne peut plus valider ses propres commandes,
  • même s’il dispose de ORDER_VALIDATE_ON_ALL_ACCOUNT, il ne peut valider que les commandes des autres utilisateurs du compte, jamais les siennes.

👉 Ce droit est distinct de ORDER_VALIDATE_ON_ALL_ACCOUNT, qui contrôle uniquement le périmètre des commandes (toutes vs autres), pas l’auto-validation.

Impact sur le workflow de commande

Le contrôle du droit ORDER_VALIDATE est appliqué à toutes les actions permettant de quitter la phase de checkout, notamment :

• Validation directe de la commande
  • PUT /v1/shop/commercial-orders/{orderCommercialId}/created (ORDER-212)
• Mise en attente de la commande
  • PUT /v1/shop/commercial-orders/{orderCommercialId}/hold (ORDER-207)
• Initialisation d’un paiement
  • POST /v1/shop/payments (PAY-101)

Si le droit ORDER_VALIDATE est à false, ces routes retournent désormais : 403 – F-E-030 (Permission denied).

Buying Policies

• Ajout du nom du compte dans le retour API de récupération des tolérances de BP d'encours

La réponse de l'API ADM-BUYING-POLICY-551 évolue pour remonter également le nom du compte : accountName. Il permet de mieux identifier les comptes associés aux configurations de tolérance des buying policies d'encours.

Le nouvel attribut accountName est également filtrable et triable.

Périmètre

API

📘

NEW

Djust Pay Marketplace

• Consultation de la liste des commissions marketplace

Contexte

Les opérateurs disposent désormais d’une vue globale des commissions marketplace configurées sur la plateforme. Cette fonctionnalité permet de consulter l’ensemble des règles de commission par fournisseur, afin de comprendre précisément quels taux sont appliqués lors des calculs de split de paiement à la capture.

Elle complète les fonctionnalités existantes de création, mise à jour, activation/désactivation et suppression des commissions marketplace, en apportant une vision transverse et auditable.

Fonctionnement métier • La liste retourne toutes les lignes de commission marketplace existantes, chacune associée à un fournisseur identifié par son externalId.

• La consultation est strictement réservée aux utilisateurs OPERATOR.

Nouveauté API

🔍 Lister les commissions marketplace

ADM-PAY-550 - GET /v1/payments/marketplace-commissions

La réponse expose la liste complète des règles de commission marketplace.

👍

UPDATE

Search

• Nouveau paramètre de requête pour le comportement de navigation dans l'API de recherche

Un nouveau paramètre de requête facultatif menuCategory a été ajouté à l'API de recherche.

• menuCategory permet de distinguer la navigation par menu de la navigation par facettes.
• Lorsque menuCategory est utilisé, les facettes de navigation sont limitées aux navigations liées aux produits renvoyés par la recherche.

Mise à jour API

GET /v2/shop/search

Nouveau paramètre de requête : menuCategory (facultatif)

Périmètre

Back Office

• Dépôt de documents à la commande

Il est désormais possible de déposer un document à la commande quelque soit le statut de cette dernière. Jusqu'à présent seuls certains statuts étaient possibles, la limitation a été levée pour correspondre à un plus grand nombre de cas d'usages.

• Nouveau rôle pour la gestion du numéro de facture pour le paiement PCard L3

Un nouveau rôle INVOICE_NUMBER associé à un custom field de type TEXT de la commande commerciale a été ajouté à la page de gestion des rôles pour permettre la construction des éléments à envoyer aux systèmes bancaires dans le cadre d'un paiement par Cartes Achats niveau 3.

API

📘

NEW

Global

• Déclaration de l’entité légale du tenant

Contexte

Les opérateurs peuvent désormais déclarer et maintenir l’entité légale du tenant (raison sociale et adresse du siège). Cette information, portée au niveau tenant, constitue une donnée de référence transverse pouvant être utilisée par différents services. Le premier cas d’usage est le paiement par carte achat niveau 3 (P-Card L3), afin de transmettre au PSP les informations du merchant of record (la plateforme), et non celles du fournisseur marketplace.

Fonctionnement métier

• La donnée est globale au tenant (pas de multi-entités légales à ce stade).
• Les champs gérés sont :
  • legalName (raison sociale),
  • registeredAddress (adresse du siège : adresse, complément, ville, région, code postal, pays).

Nouveautés API

🔍 Consulter l’entité légale du tenant

• ADM-SETTINGS-501 - GET /v1/settings/legal-entity

  Retourne la raison sociale, l’adresse du siège et la date de dernière mise à jour.

✏️ Créer / mettre à jour l’entité légale du tenant

• ADM-SETTINGS-202 - PUT /v1/settings/legal-entity

  Opération d’upsert (création ou mise à jour).

Djust Pay Marketplace

• Mise à jour du taux de commission marketplace par fournisseur

Contexte

Les opérateurs peuvent désormais mettre à jour le taux de commission marketplace associé à un fournisseur existant. Cette évolution permet d’ajuster dynamiquement le pourcentage de commission appliqué lors des calculs de split de paiement en capture, sans recréer ni supprimer la règle existante.

Cette fonctionnalité complète le socle de gestion des commissions marketplace.

Fonctionnement métier

• La mise à jour concerne exclusivement le taux de commission (commissionRate) :
  • exprimé en pourcentage,
  • ≥ 0 et < 100,
  • avec un maximum de 4 décimales, sans arrondi automatique.
• La commission est identifiée uniquement par le externalId du fournisseur.
• Une seule ligne de commission existe par fournisseur ; l’opération met à jour la règle en place.
• Aucun impact rétroactif :
  • les splits déjà calculés restent inchangés,
  • seuls les paiements futurs utilisent le nouveau taux.

Nouveauté API

✏️ Mettre à jour une commission marketplace

• ADM-PAY-200 - PUT /v1/payments/marketplace-commissions/{supplierId}

{ "commissionRate": 2.5000 }

Data Hub

• Dupliquer la configuration d’un job

Ajout d’une nouvelle route API permettant de dupliquer un job existant :

POST /v1/mapper/jobs/{jobId}/duplicate

La duplication copie toute la configuration du job, avec le job inactif et le scheduler réinitialisé et désactivé.