Périmètre

🛠️ API

📘

NEW

Matrice de prix shipping — CRUD complet

Contexte

Le module de livraison s'enrichit d'une matrice de prix permettant aux opérateurs de définir les tarifs de livraison en fonction de plusieurs dimensions : famille logistique, zone de livraison, type de livraison et fournisseur. Cette matrice constitue le référentiel tarifaire utilisé lors du calcul des frais de port au checkout.

Fonctionnement

L'opérateur (OPERATOR) dispose désormais de cinq endpoints pour gérer intégralement la matrice de prix shipping :

• Création en bulk : chaque ligne associe une combinaison unique de dimensions (famille logistique, zone, type de livraison, et fournisseur en contexte marketplace). Le prix (price) doit être ≥ 0, le franco de port (francoAmount) strictement > 0 s'il est renseigné (null = pas de franco). Les éléments valides sont créés et les invalides rejetés avec un message d'erreur détaillé.
• Lecture unitaire et liste paginée : la liste supporte des filtres multi-valués combinés en AND (logisticFamilyIds, shippingZoneIds, shippingTypeIds, supplierIds, plages de dates), avec tri et pagination. Chaque ligne retourne les noms associés aux dimensions (famille, zone, type, fournisseur) pour faciliter l'affichage.
• Modification en bulk : remplacement intégral des champs modifiables (full update), avec les mêmes règles de validation que la création.
• Suppression en bulk : chaque ligne est traitée indépendamment. La suppression est possible même si des commandes passées référencent ces lignes.

La combinaison (logisticFamilyId + shippingZoneId + shippingTypeId + supplierId) doit rester unique — tout doublon est rejeté avec le code F-E-003.

Impact API

Toutes les routes requièrent dj-client: OPERATOR et dj-api-key. Codes d'erreur : F-E-001 (champ manquant), F-E-002 (référence inexistante), F-E-003 (doublon), F-E-010 (valeur invalide), F-E-012 (format d'ID invalide).

📄 Documentation : Shipping Price Matrix

👉 Côté métier : les opérateurs peuvent désormais configurer et maintenir leur grille tarifaire de livraison directement via l'API, avec une gestion fine par famille logistique, zone, type de livraison et fournisseur.

👉 Côté technique : cinq nouveaux endpoints CRUD sur la ressource shipping-prices, avec traitement bulk et validation indépendante par élément.

---

Exposition de la famille logistique d'une classification

Contexte

Lors de la gestion des familles logistiques dans le Back-Office, il est nécessaire de connaître la famille logistique actuellement rattachée à une classification — que ce soit pour l'afficher dans une liste ou pour avertir l'opérateur avant un changement d'affectation.

Fonctionnement

Un nouvel endpoint permet d'interroger en masse la famille logistique associée à un ensemble de classifications. Pour chaque classification connue, la réponse inclut l'identifiant, le nom de la famille logistique, et un indicateur system qui distingue la famille système par défaut des familles personnalisées.

Règles de comportement :

• Chaque classification possède toujours une famille (au minimum la famille système par défaut) — la réponse n'est jamais null.
• Les identifiants inconnus sont silencieusement omis (Tolerant Reader).
• Ce endpoint sert aussi de pré-check avant affectation : le Back-Office peut afficher un avertissement si la classification est déjà rattachée à une famille non-système différente de la cible.

Impact API

GET /v1/logistic-families/assignments?classificationCategoryIds=cat-001,cat-002 — operationId : ADM-LOGISTIC-FAMILY-560

Requiert dj-client: OPERATOR et la permission LOGISTIC_FAMILY_READ. Le flag system dans la réponse permet de distinguer les familles personnalisées de la famille par défaut.

📄 Documentation : Logistic Families

👉 Côté métier : les opérateurs visualisent directement la famille logistique de chaque classification et sont avertis en cas de réaffectation, avant même de confirmer l'action.

👉 Côté technique : nouveau endpoint de lecture en masse, sans pagination, optimisé en une seule requête (pas de N+1).

---

Ajout de localisations à une shipping zone

Contexte

La configuration des zones de livraison nécessite de pouvoir y rattacher des pays et, pour la France, des départements spécifiques. Ce nouvel endpoint permet de composer finement le périmètre géographique d'une zone.

Fonctionnement

L'opérateur peut ajouter à une zone de livraison :

• Des pays entiers (type country), avec possibilité d'exclure certains départements français (excludedDepartments).
• Des départements français individuels (type department) — ce type n'est autorisé que pour countryCode: "FR".

Une zone peut combiner pays étrangers et départements français. Si un pays ou département est déjà rattaché à une autre zone, il en est automatiquement retiré avant d'être affecté à la nouvelle zone (pas de doublon inter-zones).

Impact API

PATCH /v1/shipping-zones/{shippingZoneId}/locations — operationId : ADM-SHIPPING-ZONE-210

Requiert dj-client: OPERATOR. Retourne 204 No Content en cas de succès. Code F-E-012 si le type department est utilisé pour un pays non-FR.

📄 Documentation : Shipping Zones And Types

👉 Côté métier : les opérateurs configurent précisément le périmètre géographique de chaque zone de livraison, avec une granularité au département pour la France.

👉 Côté technique : nouveau endpoint PATCH avec gestion automatique du transfert de localisations entre zones.

---

Shipping types — Modification et suppression

Contexte

Après la création et la consultation des shipping types, les opérateurs disposent désormais des endpoints de modification et de suppression pour gérer le cycle de vie complet de ces ressources.

Fonctionnement

• Modification : remplacement intégral du nom et de la description du shipping type (full update). Le nom est obligatoire (1 à 255 caractères), la description est optionnelle (jusqu'à 10 000 caractères). Passer null ou "" pour la description vide le champ. L'identifiant reste immutable.
• Suppression : la suppression est bloquée tant que des lignes de la matrice de prix sont associées au shipping type (code F-E-042). L'opérateur doit d'abord retirer les lignes de matrice concernées.

Impact API

Requièrent dj-client: OPERATOR. La suppression retourne 409 (F-E-042) si le shipping type est encore référencé dans la matrice de prix.

👉 Côté métier : cycle de vie complet des types de livraison — les opérateurs peuvent renommer, mettre à jour la description, ou supprimer un type devenu obsolète (après nettoyage de la matrice de prix).

👉 Côté technique : deux nouveaux endpoints avec contrôle d'intégrité référentielle à la suppression.

Périmètre

🖥️ Back-Office

📘

NEW

Paramètre "mode d'import" dans la configuration des jobs

Contexte

Les jobs d'import (CSV, Mirakl, API) permettaient jusqu'à présent de créer ou mettre à jour des données, mais ne proposaient aucun mécanisme de suppression des valeurs existantes pour les custom fields et les attributs produit.

Fonctionnement

Un nouveau paramètre "mode d'import" est désormais disponible dans la configuration des jobs. Deux modes sont proposés :

• Mode standard (par défaut) : comportement inchangé, seules les données présentes dans le fichier sont créées ou mises à jour.
• Mode full : les données de type Custom Field ou Attribute non présentes dans le fichier d'import sont supprimées.

Le paramètre est disponible sur chaque entité concernée : Produit, Offre, Fournisseur, Compte, Catégories de navigation, Catégories de classification, Utilisateur client et Commande.

📄 Documentation :

• Job Configuration Overview
• Job Configuration Import Ftp
• Job Configuration Import Api Connector

👉 Côté métier : les opérateurs peuvent désormais nettoyer les données obsolètes des Custom Fields et Attributes directement via l'import, en activant le mode full sur les jobs concernés.

👉 Côté technique : nouveau paramètre de configuration sur les jobs d'import. Aucun impact sur les imports existants — le mode standard reste le comportement par défaut.

🔗 Data Hub

📘

NEW

Historique des exécutions — Recherche par ID et filtre par statut

Contexte

Jusqu'à présent, retrouver une exécution spécifique dans l'historique d'un job nécessitait de parcourir manuellement les pages de résultats. Aucun mécanisme de recherche par ID ni de filtrage par statut n'était disponible côté API. Cette évolution introduit deux nouveaux endpoints v2 avec recherche partielle par ID et filtre multi-valeurs par statut, remplaçant les anciens endpoints v1 désormais dépréciés.

Fonctionnement

Deux nouveaux endpoints permettent de lister les exécutions d'un job avec des capacités de recherche et de filtrage :

• Jobs d'import / indexation : GET /v2/jobs/{jobId}/executions — remplace GET /v1/mapper/status/all/{jobId} (deprecated).
• Jobs d'export : GET /v2/jobouts/{jobOutId}/executions — remplace GET /v1/mapper/jobout/{jobOutId}/exported-item-statuses (deprecated).

Recherche par ID : le query param search permet une recherche partielle (type "contains") sur l'identifiant d'exécution.

Filtre par statut : le query param statuses accepte plusieurs valeurs. Pour les jobs d'import/indexation, les statuts disponibles correspondent aux étapes du cycle de vie du job. Pour les jobs d'export, les valeurs possibles sont SUCCESS et ERROR. Les valeurs inconnues sont silencieusement ignorées.

Si aucun paramètre de recherche ou de filtre n'est fourni, toutes les exécutions sont retournées.

Les réponses utilisent l'enveloppe de pagination standard DJUST (content, numberOfElements, number, size, first, last, empty). Le tri est configurable via le query param sort (tri par défaut : createdAt,desc pour import/indexation, executedAt,desc pour export).

Accès réservé aux opérateurs (dj-client: OPERATOR).

Impact API

• GET /v2/jobs/{jobId}/executions — operationId : ADM-JOB-550
• GET /v2/jobouts/{jobOutId}/executions — operationId : ADM-JOBOUT-550
• Paramètres communs : search (string, optionnel), statuses (array, optionnel), sort, page, size
• Réponse : 200 OK avec pagination standard
• Rétrocompatibilité : les endpoints v1 restent fonctionnels mais sont marqués deprecated

📄 Documentation : Job Configuration Overview

👉 Côté métier : retrouvez instantanément une exécution de job à partir de son ID ou filtrez les exécutions par statut, sans parcourir l'historique page par page.

👉 Côté technique : nouveaux endpoints RESTful v2 pour l'historique des exécutions (import/indexation et export) avec recherche partielle par ID, filtre multi-valeurs par statut et pagination standard DJUST. Les anciens endpoints v1 restent disponibles mais deprecated.

🛠️ API

📘

NEW

Création d'une shipping zone

Contexte

Dans le cadre du nouveau module de livraison, il est désormais possible de créer des zones de livraison (shipping zones) qui serviront de base à la configuration des règles d'expédition.

Fonctionnement

Un opérateur (dj-client: OPERATOR) peut créer une shipping zone en fournissant un nom obligatoire et, optionnellement, un identifiant et une description. Si aucun identifiant n'est fourni, il est auto-généré. L'identifiant est unique sur la plateforme et immutable une fois créé.

La shipping zone est immédiatement disponible pour configuration après création.

Impact API

POST /v1/shipping-zones — operationId : ADM-SHIPPING-ZONE-100

• Réponse : 201 Created avec l'id de la zone créée
• Erreurs notables : 422 si le nom est absent ou invalide, 409 en cas de doublon sur l'identifiant

---

Récupération d'un shipping type par ID

Contexte

Toujours dans le cadre du module de livraison, un nouvel endpoint permet de consulter le détail d'un type de livraison (shipping type) à partir de son identifiant.

Fonctionnement

Un opérateur (dj-client: OPERATOR) peut récupérer les informations d'un shipping type : identifiant, nom, description, dates de création et de mise à jour.

Impact API

GET /v1/shipping-types/{id} — operationId : ADM-SHIPPING-TYPE-500

• Réponse : 200 OK avec les champs id, name, description, createdAt, updatedAt
• Erreur 404 si le shipping type n'existe pas

---

Liste des catégories de classification d'une famille logistique

Contexte

Le module de livraison introduit la notion de famille logistique, qui regroupe des catégories de classification pour déterminer les règles d'expédition applicables. Un nouvel endpoint permet de lister les catégories rattachées à une famille logistique donnée.

Fonctionnement

Un opérateur (dj-client: OPERATOR) peut consulter les catégories de classification associées à une famille logistique. La réponse est paginée (page, size).

Par défaut, au démarrage de la plateforme, toutes les catégories du tenant sont implicitement rattachées à la famille logistique "Par défaut". Cet endpoint les retourne toutes tant qu'aucun rattachement explicite n'a été effectué. Le champ id retourné correspond à l'external ID de la catégorie.

Impact API

GET /v1/logistic-families/{logisticsFamilyId}/classification-categories — operationId : ADM-LOGISTIC-FAMILY-551

• Réponse : 200 OK, paginée (format standard DJUST)
• Erreur 404 si la famille logistique n'existe pas

📄 Documentation :

• Logistic Families
• Shipping Zones And Types

👉 Côté métier : le module de livraison s'enrichit avec la gestion des zones de livraison, la consultation des types de livraison et le rattachement des catégories aux familles logistiques — permettant une configuration fine des règles d'expédition.

👉 Côté technique : trois nouveaux endpoints administration sur le module shipping (ADM-SHIPPING-ZONE-100, ADM-SHIPPING-TYPE-500, ADM-LOGISTIC-FAMILY-551), accessibles uniquement en dj-client: OPERATOR.

Périmètre

🔗 Data Hub

📘

NEW

Import Full — Suppression des attributs et custom fields via le Data Hub

Contexte

Jusqu'à présent, les imports via le Data Hub (SFTP, connecteur API) ne permettaient pas de supprimer la valeur d'un attribut ou d'un custom field existant sur une entité. Envoyer une valeur vide ou null dans un fichier d'import n'avait aucun effet : la valeur en base était conservée. Pour les clients qui synchronisent leurs données produit ou compte depuis un ERP, il était donc impossible de « vider » un champ sans intervention manuelle.

Fonctionnement

Un nouveau paramètre importFull est désormais disponible sur la configuration des jobs d'import (CSV, connecteur API, Mirakl). Lorsqu'il est activé :

• Les attributs produit dont la valeur est null dans le fichier d'import sont supprimés de l'entité cible.
• Les custom fields dont la valeur est null sont également supprimés de l'entité cible.

Lorsque importFull est désactivé (valeur par défaut), le comportement reste inchangé : les valeurs vides ou null sont ignorées et les données existantes sont préservées. Tous les jobs existants conservent automatiquement ce comportement par défaut — aucune action n'est requise.

Le paramètre est configurable à la création (POST /job) et à la modification (PUT /job/{id}) d'un job, et visible en lecture (GET /job/{id}).

📄 Documentation : Job Configuration Overview

👉 Côté métier : il est désormais possible de supprimer des attributs et custom fields directement via les flux d'import, sans intervention manuelle, garantissant une synchronisation fidèle avec le système source.

👉 Côté technique : nouveau champ importFull (booléen, défaut false) sur la configuration des jobs d'import. Rétrocompatibilité totale — aucun changement de comportement sans activation explicite.

---

Import de commandes — Mise à jour du statut sans lignes de commande

Contexte

L'import de commandes via SFTP ou connecteur API imposait jusqu'ici de fournir les lignes de commande, même pour une simple mise à jour de statut sur une commande logistique existante. Cette contrainte rendait les cas d'usage de mise à jour de statut inutilement complexes.

Fonctionnement

Il est désormais possible d'envoyer un fichier csv ou payload minimal contenant uniquement l'identifiant de la commande (External Id ou Reference) et le nouveau statut, sans fournir de lignes de commande. Le système met à jour le statut de la commande logistique en conservant intactes les informations sur la commande.

Si le csv ou payload ne contient pas de lignes et que la commande référencée n'existe pas, une erreur de validation explicite est retournée.

📄 Documentation : Order Update Import

👉 Côté métier : les mises à jour de statut de commandes logistiques sont simplifiées — un fichier contenant uniquement l'identifiant et le statut suffit.

👉 Côté technique : le job d'import CSV/Connecteur API accepte un csv/payload sans lignes de commande pour les mises à jour de statut.

🛠️ API

📘

NEW

Gestion des shipping types — Création et consultation

Contexte

Dans le cadre du nouveau module de livraison, les opérateurs ont besoin de définir des types d'expédition (shipping types) pour configurer leurs options de livraison. Deux nouveaux endpoints permettent désormais de créer et de consulter les shipping types disponibles sur la plateforme.

Fonctionnement

Création — Un opérateur peut créer un shipping type en fournissant un nom (obligatoire) et une description (optionnelle). Un identifiant peut être spécifié manuellement ; s'il est absent, il est généré automatiquement. L'identifiant est unique sur la plateforme et immutable après création. Le shipping type est immédiatement disponible pour configuration.

Consultation — La liste des shipping types est paginée et filtrable :

• Recherche partielle sur le nom (insensible à la casse)
• Filtrage par plage de dates de création et de modification
• Tri par name, createdAt ou updatedAt (défaut : createdAt:desc)

Tous les filtres sont combinés en logique AND.

Impact API

POST /v1/shipping-types (operationId : ADM-SHIPPING-TYPE-100) Crée un shipping type. Retourne 201 Created avec l'identifiant de la ressource créée.

GET /v1/shipping-types (operationId : ADM-SHIPPING-TYPE-550) Liste paginée et filtrable des shipping types. Retourne 200 OK.

Les deux routes requièrent dj-client: OPERATOR.

📄 Documentation : Shipping Types

👉 Côté métier : les opérateurs peuvent désormais définir et consulter leurs types d'expédition directement via l'API, première brique du module de livraison.

👉 Côté technique : deux nouveaux endpoints administration sur /v1/shipping-types (POST + GET). Pagination, filtres et tri standards DJUST.

---

Gestion des familles logistiques — Consultation et détachement de catégories

Contexte

Le module de livraison introduit la notion de famille logistique, qui permet de regrouper des catégories de classification pour appliquer des règles d'expédition cohérentes. Deux nouveaux endpoints permettent de consulter les familles logistiques et de détacher des catégories de classification d'une famille.

Fonctionnement

Consultation — La liste des familles logistiques est paginée et filtrable :

• Recherche partielle sur le nom (insensible à la casse)
• Filtrage par identifiants de catégories de classification rattachées
• Filtrage par plage de dates de création et de modification
• Tri par name, createdAt ou updatedAt (défaut : createdAt:desc)

Chaque famille logistique indique si elle est système (famille par défaut) et expose le nombre de catégories de classification rattachées.

Détachement de catégories — Il est possible de retirer une ou plusieurs catégories de classification d'une famille logistique. Les catégories détachées retombent automatiquement sur la famille logistique par défaut (système). Si une catégorie listée n'est pas rattachée à la famille ciblée, elle est ignorée silencieusement. Un tableau vide ou null est accepté sans erreur et n'entraîne aucune modification.

Les identifiants de catégories attendus sont les External IDs (externalId).

Impact API

GET /v1/logistic-families (operationId : ADM-LOGISTIC-FAMILY-550) Liste paginée et filtrable des familles logistiques. Retourne 200 OK.

DELETE /v1/logistic-families/{logisticsFamilyId}/classification-categories (operationId : ADM-LOGISTIC-FAMILY-350) Détache des catégories de classification d'une famille logistique. Retourne 204 No Content.

Les deux routes requièrent dj-client: OPERATOR.

📄 Documentation : Logistic Families

👉 Côté métier : les opérateurs peuvent consulter leurs familles logistiques et réorganiser le rattachement des catégories de classification, avec un retour automatique vers la famille par défaut pour les catégories détachées.

👉 Côté technique : deux nouveaux endpoints administration sur /v1/logistic-families (GET + DELETE). Les catégories détachées sont référencées par External ID. Pagination, filtres et tri standards DJUST.

👍

UPDATE

Recherche étendue sur les Offer Inventories

Contexte

Le paramètre search de l'endpoint GET /internal/v1/offer-inventories ne couvrait pas les identifiants d'offre, obligeant les utilisateurs à utiliser d'autres moyens pour retrouver un offer inventory à partir de son offre.

Fonctionnement

Le paramètre search prend désormais en charge deux nouveaux critères de recherche :

• Offer External Id — l'identifiant externe de l'offre (fourni par le client / ERP)
• Offer Djust Id — l'identifiant interne DJUST de l'offre

Les champs de recherche déjà couverts par search restent fonctionnels sans régression.

Impact API

GET /internal/v1/offer-inventories?search={value} Le paramètre search matche désormais également sur l'Offer External Id et l'Offer Djust Id.

👉 Côté métier : les offer inventories sont désormais directement retrouvables à partir de l'identifiant de leur offre, simplifiant la recherche depuis le Back-Office ou les intégrations.

👉 Côté technique : le paramètre search de GET /internal/v1/offer-inventories couvre deux champs supplémentaires (Offer External Id, Offer Djust Id). Aucun changement de contrat, aucun nouveau paramètre.

---

---

Paramètre de tri — Support du format property:direction

Contexte

Les APIs DJUST exposaient le paramètre de tri sort uniquement au format property,direction (séparateur virgule).

Fonctionnement

L'ensemble des APIs DJUST exposant un paramètre sort acceptent désormais les deux formats :

• property:direction — format conforme à la convention DJUST (recommandé)
• property,direction — format historique, conservé pour la rétrocompatibilité

Les deux séparateurs sont interprétés de manière strictement équivalente. Le tri multi-critères fonctionne avec les deux formats, y compris en les combinant dans une même requête. Les entrées utilisant un séparateur non reconnu (ex. property-direction) sont ignorées silencieusement, conformément au comportement existant.

Aucune migration n'est requise pour les intégrations existantes — le format historique reste pleinement supporté.

Impact API

Toutes les routes exposant un paramètre sort (Admin et Shop) sont concernées. Exemples :

• ?sort=createdAt:desc (nouveau format)
• ?sort=name:asc&sort=createdAt:desc (multi-tri)
• ?sort=createdAt,desc (format historique, toujours supporté)

📄 Documentation : Get Logisitic Orders List

👉 Côté métier : aucun impact — le comportement existant est préservé, le nouveau format s'ajoute de manière transparente.

👉 Côté technique : le format property:direction est désormais accepté sur toutes les routes paginées. Il est recommandé de l'adopter pour les nouvelles intégrations. Aucun breaking change.

Périmètre

👍

UPDATE

Améliorations techniques et correctifs

Cette release ne contient pas de nouvelles fonctionnalités visibles. Elle apporte des améliorations techniques mineures et des correctifs internes, sans impact sur les contrats API.

👉 Côté métier : pas d'évolution fonctionnelle. Aucune action requise.

👉 Côté technique : améliorations et corrections diverses sans changement de contrat API.

Périmètre

🖥️ Back-Office

📘

NEW

Dashboard Payouts Marketplace

Contexte

Les opérateurs marketplace ne disposaient pas d'interface dédiée pour consulter les payouts marketplace depuis le back-office. Le suivi nécessitait un accès direct aux systèmes de paiement ou une extraction manuelle, là où les dashboards supplier payouts et funding transfers étaient déjà disponibles.

Fonctionnement

Un nouveau dashboard back-office permet désormais de consulter les payouts marketplace :

• Liste paginée : vue d'ensemble des payouts marketplace avec filtres et tri, alignée sur l'ergonomie des dashboards existants (supplier payouts, funding transfers).
• Détail : consultation du détail complet d'un payout marketplace (montant, statut, dates, informations associées).

L'accès est réservé aux utilisateurs OPERATOR disposant des droits d'administration sur le domaine Payments.

👉 Côté métier : les opérateurs marketplace peuvent désormais suivre et consulter leurs payouts directement depuis le back-office, sans dépendance aux outils internes ou au PSP.

👉 Côté technique : nouveau dashboard administration aligné sur le pattern existant des dashboards PAY (supplier payouts, funding transfers).

🔗 Data Hub

📘

NEW

Sélection du Store cible sur les jobs d'import Order

Contexte

Dans un contexte multi-store, les commandes importées via un job d'import Order (CSV ou Connecteur API) étaient systématiquement rattachées à la Store View par défaut du tenant. Il n'était pas possible de cibler un Store spécifique sans manipulation manuelle.

Fonctionnement

Le paramètre storeExternalIds, déjà disponible sur les endpoints de création et mise à jour de jobs, permet désormais de préciser le Store cible pour les jobs d'import Order. Les commandes externes créées par un job configuré sont automatiquement rattachées à la Store View par défaut du Store choisi, sans manipulation d'identifiant de Store View.

Sans configuration, le comportement reste inchangé : les commandes sont rattachées au Store par défaut du tenant.

Un job dont le Store configuré n'existe pas ou plus est rejeté à la création/mise à jour (HTTP 400) ou signalé en erreur dans le rapport d'exécution.

Impact API

• POST /v2/mapper/jobs et PUT /v1/mapper/jobs/{jobId} : utilisation du paramètre storeExternalIds pour les jobs de type Order
• Erreur HTTP 400 si le Store référencé est invalide ou inexistant

📄 Documentation :

• Orders Import
• Job Configuration Overview

👉 Côté métier : les opérateurs multi-store peuvent désormais cibler précisément le Store de destination de leurs imports de commandes, sans intervention technique.

👉 Côté technique : le paramètre storeExternalIds est exploité sur les jobs d'import Order — aucun nouveau endpoint, rétrocompatibilité totale.

👍

UPDATE

Renommage du label d'import Supplier « Supplier Deleted »

Contexte

Le label Supplier Deleted affiché dans le mapping d'import Supplier laissait penser à une suppression définitive, alors que le champ correspond à une désactivation (passage à inactif).

Fonctionnement

Le label est renommé en Mark Supplier as Inactive, cohérent avec les conventions déjà en place pour les autres flags d'action (Mark Order Line For Deletion, Mark Account as Inactive, etc.).

Aucun changement de comportement : seul le libellé affiché dans l'interface de configuration des mappings est modifié.

👉 Côté métier : le libellé du champ de mapping reflète désormais fidèlement l'action réalisée (désactivation, non suppression), évitant toute confusion lors de la configuration.

👉 Côté technique : aucun impact sur les mappings existants ni sur la logique d'import — changement de label uniquement.

🛠️ API

📘

NEW

Téléchargement des fichiers exportés

Contexte

Les fichiers générés lors d'un export (SFTP ou Connecteur API) n'étaient pas conservés après l'envoi. En cas de perte côté client ou d'écart dans les données, il était impossible de vérifier ce qui avait été transmis sans intervention technique.

Fonctionnement

Chaque fichier exporté (SFTP XML/JSON ou Connecteur API JSON) est désormais automatiquement archivé avant la tentative d'envoi. En cas d'échec d'envoi (erreur SFTP, timeout HTTP), le fichier reste disponible au téléchargement.

Les fichiers archivés sont nommés de manière explicite (exported-file-{exportIntegrationId}.{extension}), facilitant l'identification lors du téléchargement de plusieurs archives.

La signed URL retournée est valide 24 h. Les fichiers sont conservés 90 jours puis supprimés automatiquement. Ce mécanisme ne s'applique qu'aux exports postérieurs à la mise en production.

Impact API

• GET /v2/jobouts/executions/{executionId}/exported-file/signed-url — operationId : ADM-JOBOUT-501
• Réponse : 302 Found avec header Location contenant la signed URL, ou 404 si le fichier est absent ou expiré
• Accès : OPERATOR uniquement

📄 Documentation :

• Job Configuration Export Ftp
• Job Configuration Export Api Connector

👉 Côté métier : vérifiez et re-transmettez les données exportées en toute autonomie, sans solliciter l'équipe technique.

👉 Côté technique : nouvel endpoint GET sous le tag Jobs Administration, aucune modification des flux d'export existants.

---

---

---

Gestion des processus d'onboarding PAY

Contexte

La gestion des processus d'onboarding des suppliers sur la plateforme de paiement nécessitait des interventions manuelles ou des accès directs aux systèmes internes. Aucune API ne permettait de consulter, piloter ou relancer ces processus de manière autonome.

Fonctionnement

Deux axes sont désormais couverts par l'API :

Consultation : un endpoint de liste paginée avec filtres (type, statut, supplierId, supplierName) et un endpoint de détail complet (organizationProfile, pspEntities, steps) permettent de suivre l'état de chaque processus d'onboarding.

Le scoping SUPPLIER est appliqué : un supplier ne voit que ses propres processus (404 si tentative d'accès à un processus tiers).

Cycle de vie : cinq actions sont disponibles pour piloter les processus :

• Démarrage depuis le brouillon
• Relance après échec
• Suspension
• Réactivation
• Annulation (avec nettoyage côté PSP)

Un contrôle strict des transitions de statut est appliqué : une transition invalide retourne le code d'erreur F-E-028. Référence des codes d'erreur : Error / Warning codes

Impact API

Consultation :

• GET /v1/payments/onboarding — operationId : ADM-PAY-557
• GET /v1/payments/onboarding/{processId} — operationId : ADM-PAY-508

Cycle de vie :

• POST /v1/payments/onboarding/{processId}/start — operationId : ADM-PAY-109
• POST /v1/payments/onboarding/{processId}/retry — operationId : ADM-PAY-110
• POST /v1/payments/onboarding/{processId}/suspend — operationId : ADM-PAY-111
• POST /v1/payments/onboarding/{processId}/reactivate — operationId : ADM-PAY-112
• POST /v1/payments/onboarding/{processId}/cancel — operationId : ADM-PAY-113

📄 Documentation : Merchant Onboarding Manual Flow

👉 Côté métier : suivez et pilotez l'onboarding de vos suppliers directement depuis l'API, avec une visibilité complète sur chaque étape du processus.

👉 Côté technique : 7 nouveaux endpoints sous le domaine Payments, avec scoping SUPPLIER et contrôle strict des transitions de statut.

---

---

Rattachement de catégories de classification à une famille logistique

Contexte

Dans le cadre du module de livraison, les familles logistiques peuvent être associées à des catégories de classification pour définir les règles de shipping applicables. Un nouvel endpoint permet de gérer ce rattachement.

Fonctionnement

L'endpoint permet d'attacher une ou plusieurs catégories de classification à une famille logistique. Les règles suivantes s'appliquent :

• Une catégorie ne peut être rattachée qu'à une seule famille logistique à la fois.
• Si une catégorie est déjà rattachée à une autre famille, elle est automatiquement détachée de l'ancienne et rattachée à la nouvelle.
• Un tableau vide ou null dans le champ classificationCategoryIds est accepté silencieusement (204, aucune modification).
• Les identifiants attendus sont les external IDs des catégories.

Accès réservé aux utilisateurs OPERATOR.

Impact API

• PATCH /v1/logistic-families/{logisticsFamilyId}/classification-categories — operationId : ADM-LOGISTIC-FAMILY-210
• Réponse : 204 No Content
• Erreurs : 401 (authentification manquante), 403 (client non OPERATOR), 404 (famille ou catégorie inexistante)

📄 Documentation : Logistic Families

👉 Côté métier : les opérateurs peuvent organiser leurs familles logistiques en les associant aux catégories de classification pertinentes, directement via l'API.

👉 Côté technique : nouvel endpoint PATCH sous le domaine Shipping Administration, identifiants attendus en external ID.

---

---

Déclenchement automatique des payouts marketplace

Contexte

Dans un contexte marketplace, le déclenchement des payouts suppliers nécessitait une action manuelle ou une orchestration externe. Aucun mécanisme natif ne permettait de planifier automatiquement les payouts à intervalles réguliers.

Fonctionnement

Un mécanisme de déclenchement automatique (CRON) est désormais intégré à la plateforme. Les payouts sont déclenchés de manière planifiée, par tenant, sans intervention manuelle.

La fréquence par défaut est hebdomadaire (chaque lundi matin). Ce paramétrage est géré côté plateforme et ne nécessite aucune configuration Adyen complémentaire.

👉 Côté métier : les payouts marketplace sont désormais déclenchés automatiquement selon un calendrier régulier, garantissant la ponctualité des versements sans action manuelle.

👉 Côté technique : mécanisme CRON natif par tenant pour le déclenchement des payouts — aucun endpoint exposé, orchestration entièrement côté plateforme.

👍

UPDATE

Affectation d'un acheteur à plusieurs buying policies

Contexte

Un customer user ne pouvait être buyer que dans une seule buying policy, ce qui bloquait les utilisateurs multi-comptes (franchisés, commerciaux, support). Cette contrainte d'unicité globale est levée.

Fonctionnement

Le lien entre une buying policy et un customer account est désormais explicite : chaque buying policy est associée à un customer account spécifique. La contrainte d'unicité du buyer s'applique désormais par account (et non plus globalement).

Un même customer user peut donc être buyer dans plusieurs buying policies, à condition que chacune soit rattachée à un account différent.

Les champs customerAccountId et customerAccountName sont ajoutés aux réponses des endpoints de gestion des buying policies.

Ce changement concerne uniquement les buying policies historiques (validation manuelle).

Impact API

• Endpoints de gestion des buying policies : ajout des champs customerAccountId et customerAccountName dans les réponses
• Unicité du buyer désormais par account (non plus globale)
• Rétrocompatibilité : les tenants mono-account ne sont pas impactés

📄 Documentation : Manual Order Validation

👉 Côté métier : les utilisateurs multi-comptes peuvent désormais être acheteurs dans plusieurs buying policies, une par account, sans contournement nécessaire.

👉 Côté technique : ajout de customerAccountId / customerAccountName sur les endpoints buying policies, contrainte d'unicité buyer réduite au scope account.

---

---

---

Nouveau statut de transaction PAYMENT_INITIATED

Contexte

Les transactions disposant uniquement d'un événement d'initialisation de paiement étaient affichées avec le statut PAYMENT_AUTHORIZED, ce qui portait à confusion avec les transactions réellement autorisées.

Fonctionnement

Un nouveau statut PAYMENT_INITIATED est introduit pour distinguer les transactions dont le paiement a été initié mais pas encore autorisé. Ce statut remplace PAYMENT_AUTHORIZED pour les transactions qui n'ont qu'un événement d'initialisation.

Les transactions déjà autorisées conservent le statut PAYMENT_AUTHORIZED.

Impact API

• Nouveau statut PAYMENT_INITIATED dans le cycle de vie des transactions
• Les filtres et endpoints de consultation des transactions acceptent ce nouveau statut

📄 Documentation : Transactions

👉 Côté métier : distinction claire entre les paiements initiés et les paiements autorisés, pour un suivi plus précis des transactions.

👉 Côté technique : nouveau statut PAYMENT_INITIATED dans l'énumération des statuts de transaction — à prendre en compte dans les intégrations consommant les statuts.

---

---

Verrouillage de la commande pendant l'autorisation de paiement

Contexte

Lorsqu'une commande commerciale était en cours d'autorisation de paiement, il était possible d'effectuer des modifications sur celle-ci avant la confirmation de l'autorisation, ce qui pouvait entraîner des incohérences entre le montant autorisé et le contenu réel de la commande.

Fonctionnement

Une commande en statut CREATED est désormais verrouillée dès qu'une demande d'autorisation de paiement est en cours (AUTHORIZATION_PENDING). Tant que l'autorisation n'est pas confirmée ou rejetée, aucune modification n'est autorisée sur la commande.

Ce verrouillage garantit la cohérence entre le montant soumis à l'autorisation et le contenu de la commande au moment de la validation.

Impact API

• Les endpoints de modification d'une commande en statut CREATED retournent une erreur si une autorisation de paiement est en cours
• Rétrocompatibilité : aucun impact sur les commandes dont le paiement est déjà autorisé ou qui ne sont pas en cours d'autorisation

👉 Côté métier : les commandes ne peuvent plus être modifiées pendant l'autorisation de paiement, éliminant tout risque de décalage entre le montant autorisé et le contenu de la commande.

👉 Côté technique : nouveau contrôle bloquant sur les commandes en AUTHORIZATION_PENDING — les modifications sont rejetées jusqu'à résolution de l'autorisation.

⚠️

IMPORTANT UPDATE

Mise à jour partielle des paramètres généraux (PATCH) et dépréciation du PUT

Contexte

L'endpoint PUT /v1/settings/general imposait un payload complet pour toute modification, même pour un seul paramètre. Ce comportement rendait les mises à jour ciblées risquées (écrasement involontaire de valeurs) et empêchait la modification de certains flags comme supplierCustomerAccountAssociationAllowed, absent du DTO de mise à jour.

Fonctionnement

Un nouvel endpoint PATCH permet désormais la mise à jour partielle des paramètres généraux : seuls les champs fournis dans le payload sont modifiés, les autres restent inchangés en base.

Règles :

• Un body vide ou avec tous les champs à null retourne une erreur 400 (code F-E-001).
• Le flag supplierCustomerAccountAssociationAllowed est désormais modifiable via ce nouvel endpoint.
• Permission requise : GENERAL_SETTING_UPDATE (identique au PUT existant).

Le PUT /v1/settings/general reste fonctionnel mais est désormais déprécié. Il est recommandé de migrer vers le PATCH pour toute mise à jour de paramètres généraux.

Impact API

• PATCH /v1/settings/general — nouvel endpoint de mise à jour partielle
• PUT /v1/settings/general — déprécié (marqué deprecated dans le contrat OpenAPI), reste fonctionnel
• Nouveau champ modifiable : supplierCustomerAccountAssociationAllowed
• Erreur 400 / F-E-001 si aucun champ fourni

Référence des codes d'erreur : Error / Warning codes

📄 Documentation : Job Configuration Overview

👉 Côté métier : les paramètres généraux peuvent désormais être modifiés individuellement, sans risque d'écrasement des autres valeurs.

👉 Côté technique : nouveau PATCH /v1/settings/general (mise à jour partielle), dépréciation du PUT — migration recommandée pour les intégrations existantes.

Périmètre

🖥️ Back-Office

📘

NEW

Mode d'apparence (Clair / Sombre / Auto)

Contexte

Jusqu'à présent, le back-office DJUST n'offrait qu'un seul thème visuel. Les utilisateurs travaillant dans des environnements variés (bureau lumineux, travail de nuit, etc.) ne pouvaient pas adapter l'interface à leur confort visuel.

Fonctionnement

Un sélecteur d'apparence à trois options est désormais disponible dans le menu utilisateur de la sidebar :

• Clair : thème lumineux (mode par défaut pour tout nouvel utilisateur)
• Sombre : thème sombre appliqué à l'ensemble de l'interface
• Auto : suit automatiquement la préférence système de l'OS (clair ou sombre), avec mise à jour en temps réel

Le choix est persisté localement et survit au rafraîchissement de page ainsi qu'aux déconnexions/reconnexions.

Précisions :

• La sidebar de navigation reste toujours en mode sombre, quel que soit le thème choisi (choix design).
• Les pages d'authentification (login, mot de passe oublié, reset) restent en mode clair pour garantir la cohérence de branding.
• L'éditeur d'email Unlayer reste en mode clair (contrainte technique iframe).
• Les graphiques du dashboard s'adaptent au thème sélectionné.

👉 Côté métier : chaque utilisateur peut désormais adapter l'interface à son environnement de travail et à ses préférences visuelles.

👉 Côté technique : aucun impact API. Le choix de thème est géré côté client via localStorage.

🛠️ API

📘

NEW

Exécution d'un payout marketplace

Contexte

Dans le cadre de DJUST PAY, les commissions marketplace acquises lors des captures sont consolidées en un payout marketplace au statut COMPUTED. Jusqu'à présent, aucun mécanisme ne permettait de déclencher l'exécution de ce payout pour reverser les fonds vers le compte bancaire de la marketplace.

Fonctionnement

L'exécution d'un payout marketplace est déclenchée manuellement par un opérateur (depuis le back-office ou par API). Le système suit le flux suivant :

1. Vérification que le payout est au statut COMPUTED (seul statut autorisant l'exécution).
2. Contrôle de la disponibilité des fonds sur le balance account marketplace (BA_MKP).
3. Si les fonds sont suffisants : déclenchement du payout PSP, passage au statut PENDING, puis suivi asynchrone via webhooks PSP (SETTLED en cas de succès, FAILED en cas d'échec).
4. Si les fonds sont insuffisants : passage au statut INSUFFICIENT_FUNDS, aucun appel PSP effectué.

Lorsqu'un payout est confirmé (SETTLED), les commandes associées sont marquées comme ayant leur commission marketplace reversée et ne seront plus reprises dans un futur payout. En cas d'échec, les commandes restent éligibles pour une prochaine tentative.

La période couverte par le payout est déterminée automatiquement entre la dernière exécution réussie et la date courante.

📄 Documentation : Marketplace Payout Lifecycle

👉 Côté métier : les opérateurs marketplace peuvent désormais déclencher le reversement des commissions acquises vers le compte bancaire de la marketplace, avec un suivi complet du statut d'exécution.

👉 Côté technique : nouveau flux d'exécution avec vérification de solde sur le BA_MKP, appel PSP, et réconciliation asynchrone via webhooks. Statuts possibles : COMPUTED → PENDING → SETTLED / FAILED, ou COMPUTED → INSUFFICIENT_FUNDS.

---

---

Export CSV des payouts marketplace

Contexte

Les équipes finance et ops paiement avaient besoin de pouvoir exporter les données de payouts marketplace au format CSV, comme c'est déjà le cas pour les payouts supplier.

Fonctionnement

De nouveaux endpoints d'administration permettent de gérer l'export CSV asynchrone des payouts marketplace :

• Création d'une demande d'export
• Consultation de la liste des exports
• Suivi du statut d'un export

Le mécanisme est identique à celui déjà en place pour les exports de payouts supplier : l'export est généré de manière asynchrone et un email de notification est envoyé au demandeur lorsque le fichier est prêt.

👉 Côté métier : les équipes finance peuvent désormais exporter les données de payouts marketplace au format CSV pour leurs besoins de rapprochement et de reporting.

👉 Côté technique : nouveaux endpoints d'administration pour l'export CSV asynchrone des payouts marketplace, suivant la même mécanique que l'export des payouts supplier.

---

---

Consultation des funding transfers

Contexte

Les transferts internes de funding (mouvements entre balance accounts, par exemple MARKETPLACE → SUPPLIER) sont essentiels pour le suivi opérationnel des paiements. Jusqu'à présent, les équipes finance ne disposaient d'aucune vue dédiée pour consulter, filtrer et diagnostiquer ces mouvements.

Fonctionnement

Deux nouvelles routes API permettent de consulter les funding transfers :

Liste paginée — filtrable par période, statut (PENDING, COMPLETED, FAILED), supplier, montant, type de balance account source/destination (MARKETPLACE, SUPPLIER), entité liée (PAYOUT, REFUND), et identifiant d'entité liée. Le tri est supporté sur createdAt, amount et status (tri par défaut : createdAt:desc). Les tris invalides sont silencieusement ignorés.

Détail unitaire — consultation complète d'un funding transfer avec toutes ses informations (montant, statut, raison d'échec, référence de réconciliation, entité liée, etc.).

Les règles d'accès suivent le standard DJUST :

• OPERATOR : accès à tous les funding transfers du tenant, filtrable par supplier
• SUPPLIER : accès restreint aux funding transfers impactant le supplier connecté (restriction serveur)

Impact API

• GET /v1/payments/funding-transfers (operationId : ADM-PAY-553) — liste paginée avec filtres
• GET /v1/payments/funding-transfers/{transferId} (operationId : ADM-PAY-503) — détail unitaire

📄 Documentation :

• Marketplace Payouts Export
• Funding Transfers

👉 Côté métier : les équipes finance et ops paiement peuvent consulter et diagnostiquer les transferts internes de funding directement depuis le back-office, sans dépendre d'exports manuels.

👉 Côté technique : deux nouvelles routes API (ADM-PAY-553, ADM-PAY-503) avec filtres avancés, pagination, tri, et scoping par rôle (OPERATOR / SUPPLIER).

---

---

Renvoi de l'email d'export

Contexte

Lorsqu'un export (transactions, payouts, funding transfers, payouts marketplace) est généré, un email contenant le lien de téléchargement est envoyé au demandeur. Si cet email est perdu ou non reçu, l'utilisateur devait jusqu'à présent recréer un export complet.

Fonctionnement

Un nouvel endpoint permet de renvoyer l'email de confirmation d'un export existant, sans regénérer le fichier CSV. Conditions :

• L'export doit être au statut READY.
• Le destinataire principal est toujours l'utilisateur connecté (non modifiable).
• La liste des destinataires en copie (cc) peut être redéfinie via le body de la requête (max 20 adresses). Si aucun body n'est fourni, les cc originaux sont conservés.

Ce endpoint est générique et fonctionne pour tous les types d'exports : transaction events, supplier payouts, funding transfers, payouts marketplace.

Impact API

POST /v1/exports/{exportId}/resend-email (operationId : ADM-EXPORT-200)

• Body optionnel avec champ cc (liste d'emails)
• Réponse 200 avec confirmation des destinataires
• Erreurs : 403 si l'export appartient à un autre utilisateur, 409 si l'export n'est pas au statut READY

📄 Documentation :

• Export Email Resend
• Transactions Export
• Supplier Payouts Export
• Funding Transfers Export
• Introduction To Djust Pay

👉 Côté métier : les utilisateurs peuvent renvoyer l'email de téléchargement d'un export sans avoir à relancer la génération du fichier, et peuvent ajuster la liste des destinataires en copie.

👉 Côté technique : nouvelle route POST /v1/exports/{exportId}/resend-email (ADM-EXPORT-200), générique pour tous les types d'exports, avec gestion des cc et contrôle de statut.

---

---

Gestion des familles logistiques (création et modification)

Contexte

Dans le cadre du module de livraison, les familles logistiques permettent de catégoriser les produits selon leurs contraintes d'expédition (produits fragiles, volumineux, etc.). Deux nouveaux endpoints permettent désormais de créer et modifier ces familles.

Fonctionnement

Création — Un opérateur peut créer une famille logistique en renseignant un nom (obligatoire), un identifiant personnalisé (optionnel, auto-généré si absent, immutable et unique) et une description (optionnelle). La famille est immédiatement disponible après création. L'attachement de catégories se fait via des endpoints dédiés.

Modification — Un opérateur peut modifier le nom et la description d'une famille logistique existante. La modification applique un remplacement complet des champs modifiables (full update). L'identifiant est immutable.

Règle commune : la famille système "Par défaut" ne peut être ni créée ni modifiée via ces endpoints.

Impact API

• POST /v1/logistic-families (operationId : ADM-LOGISTIC-FAMILY-100) — création, réponse 201 Created
• PUT /v1/logistic-families/{id} (operationId : ADM-LOGISTIC-FAMILY-200) — modification, réponse 204 No Content

Accès réservé à dj-client: OPERATOR.

📄 Documentation : Logistic Families

👉 Côté métier : les opérateurs peuvent désormais créer et organiser des familles logistiques pour structurer les contraintes d'expédition de leur catalogue produit.

👉 Côté technique : deux nouvelles routes d'administration (ADM-LOGISTIC-FAMILY-100, ADM-LOGISTIC-FAMILY-200) pour la gestion CRUD des familles logistiques.

👍

UPDATE

Refonte du template d'email des exports

Contexte

Le mail envoyé après la génération d'un export contenait deux liens (téléchargement + lien vers le back-office) et un wording technique peu lisible (ex. "Transaction_event"). Le template nécessitait une refonte pour améliorer la clarté et l'accessibilité, notamment pour les destinataires en copie qui n'ont pas nécessairement accès au back-office.

Fonctionnement

Le template d'email a été harmonisé pour les quatre types d'exports (transaction events, supplier payouts, funding transfers, payouts marketplace) :

• Un seul lien : le lien de téléchargement signé (valable 24h). Le lien vers le back-office est supprimé.
• Même lien pour tous les destinataires : le demandeur et les destinataires en copie reçoivent le même email.
• Wording corrigé : les noms d'exports sont désormais lisibles (ex. "transaction events", "supplier payouts").
• Ton neutre : le wording ne suppose plus que le destinataire est un opérateur avec accès au back-office.

👉 Côté métier : les emails d'export sont plus clairs, avec un seul lien de téléchargement et un wording adapté à tous les destinataires.

👉 Côté technique : template d'email unifié pour les 4 types d'exports. Suppression du lien back-office, conservation du lien signé uniquement.

Périmètre

🖥️ Back-Office

📘

NEW

Export des supplier-payouts

Contexte

Les opérateurs DJUST PAY avaient la possibilité d'exporter les transactions, mais pas les supplier-payouts. Pour faciliter le suivi comptable et le rapprochement des reversements fournisseurs, il est désormais possible d'exporter les supplier-payouts et de consulter l'historique des exports générés.

Fonctionnement

Une nouvelle action « Exporter les supplier-payouts » est disponible dans le menu d'actions de la page PAY. L'export est total (sans filtre) et envoyé par email au destinataire principal (l'utilisateur connecté), avec possibilité d'ajouter des destinataires en copie (CC).

Une page dédiée à l'historique des exports supplier-payouts est également disponible. Elle affiche la liste paginée des exports avec les colonnes : Export ID, Destinataires, Créé le (triable) et Statut. Des filtres par statut et par plage de dates sont disponibles et persistés dans l'URL. Le téléchargement est possible tant que le lien n'a pas expiré ; au-delà, le statut affiché passe à EXPIRED.

L'accès à ces fonctionnalités est conditionné par les permissions utilisateur.

Impact API

• POST /v1/payments/supplier-payouts/export — déclenche l'export (réponse 202)
• GET /v1/payments/supplier-payouts/export — liste l'historique des exports

👉 Côté métier : les opérateurs peuvent désormais récupérer un export complet des supplier-payouts par email et retrouver facilement leurs exports passés.

👉 Côté technique : deux nouvelles routes d'export supplier-payouts sont consommées par le back-office, sur le même modèle que les exports de transactions.

---

---

Export des funding-transfers

Contexte

De la même manière que pour les supplier-payouts, les opérateurs DJUST PAY avaient besoin de pouvoir exporter les funding-transfers (mouvements internes entre balance accounts) et de consulter l'historique de ces exports.

Fonctionnement

Une action « Exporter les funding-transfers » est ajoutée dans le menu d'actions de la page PAY. L'export est total, envoyé par email à l'utilisateur connecté avec possibilité d'ajouter des destinataires en copie.

Une page d'historique des exports funding-transfers est disponible, avec le même fonctionnement que pour les supplier-payouts : tableau paginé, colonnes Export ID / Destinataires / Créé le / Statut, filtres par statut et plage de dates, téléchargement conditionnel et gestion de l'expiration des liens.

L'accès est soumis aux permissions utilisateur.

Impact API

• POST /v1/payments/funding-transfers/export — déclenche l'export (réponse 202)
• GET /v1/payments/funding-transfers/export — liste l'historique des exports

📄 Documentation :

• Supplier Payouts Export
• Funding Transfers Export
• Introduction To Djust Pay

👉 Côté métier : les opérateurs disposent d'un export complet des funding-transfers et d'un historique consultable, facilitant le suivi des mouvements financiers internes.

👉 Côté technique : deux nouvelles routes d'export funding-transfers sont consommées par le back-office, alignées sur le pattern existant des exports de transactions.

👍

UPDATE

Authorization Code dans le détail des événements de transaction

Contexte

Pour les plateformes utilisant le paiement par carte achat, le code d'autorisation (authorizationCode) est une information essentielle au rapprochement bancaire. Ce champ est désormais visible dans le back-office et inclus dans les exports d'événements de transaction.

Fonctionnement

Le champ authorizationCode est affiché dans le détail d'un événement de transaction lorsqu'il est disponible. Pour les plateformes n'utilisant pas la carte achat, ce champ n'existe pas et n'est pas affiché. Le même champ est également inclus dans les exports CSV des événements de transaction.

Impact API

Le champ authorizationCode est ajouté à la réponse des événements de transaction et à l'export associé. Sa valeur est null pour Adyen.

📄 Documentation : Event Details

👉 Côté métier : les opérateurs peuvent consulter et exporter le code d'autorisation directement depuis le back-office, sans recourir à un outil tiers pour le rapprochement bancaire.

👉 Côté technique : nouveau champ authorizationCode disponible sur les événements de transaction (API et export).

---

---

Quantité totale sur le bandeau de détail d'une commande

Contexte

Sur la page de détail d'une commande, le bandeau supérieur affichait le statut, le statut de paiement et les montants HT/TTC, mais pas la quantité totale. Cette information obligeait l'opérateur à consulter l'onglet « Order lines » pour connaître le volume de la commande.

Fonctionnement

La quantité totale (somme des quantités de chaque ligne) est désormais affichée dans le bandeau supérieur de la page de détail, aux côtés des montants existants.

👉 Côté métier : vision immédiate du volume d'une commande sans navigation supplémentaire.

👉 Côté technique : aucun impact API — affichage d'une donnée déjà disponible dans la réponse.

---

---

Ordre des onglets Products / Variants dans les Catalog Views

Contexte

Dans la page de détail d'une Catalog View, les onglets de contenu étaient affichés dans l'ordre « Variants | Products », ce qui ne correspondait pas au parcours naturel de gestion (on travaille d'abord sur les produits, puis sur les variantes).

Fonctionnement

L'ordre des onglets est désormais inversé : Products | Variants. Aucun changement fonctionnel sur le contenu des onglets.

👉 Côté métier : navigation plus intuitive dans la gestion du contenu des catalog views.

👉 Côté technique : aucun impact API — changement d'affichage uniquement.

---

---

Masquage de l'onglet Commissions hors mode Marketplace

Contexte

L'onglet « Commissions » et les informations associées dans DJUST PAY n'ont de sens que pour les plateformes configurées en mode Marketplace. Sur les plateformes en mode standard, cet onglet était affiché inutilement.

Fonctionnement

Le back-office détecte désormais le mode de la plateforme (marketplace ou standard) via la configuration Adyen exposée par l'API. Lorsque la plateforme n'est pas en mode Marketplace, l'onglet Commissions et les informations liées aux commissions sont masqués.

Impact API

Le champ mode est désormais exposé dans le adyenConfigurationDto retourné par l'API de settings.

👉 Côté métier : interface PAY simplifiée pour les plateformes non-marketplace, sans informations inutiles sur les commissions.

👉 Côté technique : nouveau champ mode dans la réponse de configuration Adyen, utilisé pour conditionner l'affichage.

---

---

Colonne Bundles sur la liste des produits

Contexte

Les opérateurs devaient ouvrir chaque fiche produit pour savoir si des bundles y étaient associés. L'ajout d'une colonne dédiée dans la liste des produits permet d'identifier ces produits en un coup d'œil.

Fonctionnement

Une colonne « Bundles » est ajoutée dans la liste des produits, affichant le nombre de bundles associés à chaque produit. Cette colonne n'est visible que si le feature flag BUNDLE est actif sur la plateforme.

Impact API

Exploitation du champ bundlesCount déjà disponible dans le DTO ProductSimpleInfo.

👉 Côté métier : identification rapide des produits avec bundles directement depuis la liste, sans ouvrir chaque fiche.

👉 Côté technique : affichage conditionné au feature flag BUNDLE, basé sur le champ bundlesCount du DTO existant.

🔗 Data Hub

👍

UPDATE

Copie de l'ID d'exécution depuis le menu contextuel

Contexte

L'identifiant unique de chaque exécution de job (import, export, indexation) est une information nécessaire pour communiquer avec le support DJUST en cas de problème. Cet ID était auparavant moins accessible dans l'interface.

Fonctionnement

L'ID d'exécution est désormais accessible via le menu contextuel (⋯) de chaque ligne dans l'historique des exécutions. Un clic sur « Copier l'ID » copie l'identifiant complet dans le presse-papier, prêt à être transmis au support.

👉 Côté métier : communication facilitée avec le support DJUST grâce à un accès direct à l'ID d'exécution.

👉 Côté technique : aucun impact API — amélioration d'interface uniquement.

---

---

Détection des expressions CRON avancées sur la planification d'indexation

Contexte

Le configurateur de planification d'indexation ne supportait que des exécutions à des heures fixes (ex. 8h, 10h, 14h). Certaines configurations nécessitent des expressions CRON plus complexes (ex. toutes les 30 minutes), qui ne pouvaient pas être exprimées dans le picker standard et provoquaient un dysfonctionnement de l'affichage.

Fonctionnement

Le back-office détecte automatiquement le type d'expression CRON configurée :

• Expression simple (heures fixes) → le picker d'heures classique s'affiche, sans changement.
• Expression avancée → le configurateur CRON complet (CronConfigurator) s'affiche, avec un message rappelant le quota journalier d'indexations.

La bascule est automatique et transparente. Si un opérateur modifie une expression avancée pour revenir à un pattern simple, le picker d'heures reprend la main au prochain chargement. Les configurations existantes ne sont pas impactées.

Impact API

PATCH /v1/indexation-jobs/{id} — champ cronExpression (inchangé)

👉 Côté métier : les configurations de planification avancées (ex. toutes les 30 minutes) sont désormais correctement affichées et éditables dans le back-office.

👉 Côté technique : détection automatique du pattern CRON avec bascule transparente entre picker simplifié et configurateur avancé. Rétrocompatibilité totale.

🛠️ API

📘

NEW

Calcul des commissions marketplace éligibles au payout

Contexte

Dans le cadre du flux de payout marketplace, DJUST PAY doit pouvoir déterminer automatiquement quelles commissions sont éligibles au reversement, à partir des commandes dont le paiement a été capturé.

Fonctionnement

Un mécanisme de calcul automatique des commissions marketplace éligibles au payout est mis en place. À partir des commandes capturées, le système identifie les commissions à reverser vers le compte bancaire de la marketplace. Ce calcul garantit la traçabilité et l'auditabilité des montants préparés pour le payout.

👉 Côté métier : les commissions marketplace sont automatiquement calculées et préparées pour le reversement, sans intervention manuelle.

👉 Côté technique : nouveau mécanisme de calcul des commissions éligibles au payout, intégré au flux existant de gestion des payouts marketplace.

👍

UPDATE

Documentation des champs triables sur les lignes de commande

Contexte

Les contrats OpenAPI des routes de listing des lignes de commande ne documentaient pas les champs disponibles pour le tri. Cette mise à jour aligne la documentation Swagger avec les capacités réelles de l'API.

Fonctionnement

Les champs triables sont désormais explicitement documentés dans le Swagger pour les deux routes concernées. Les descriptions et le contrat ont été réalignés pour refléter fidèlement le comportement de l'API.

Impact API

• GET /v1/shop/logistic-orders/{id}/lines (ORDER-555) — champs triables documentés
• GET /v1/shop/commercial-orders/{ref}/lines (ORDER-561) — champs triables documentés

👉 Côté métier : aucun changement fonctionnel — amélioration de la documentation uniquement.

👉 Côté technique : les intégrateurs peuvent désormais consulter dans le Swagger la liste exacte des champs acceptés par le paramètre sort.

Périmètre

🖥️ Back-Office

📘

NEW

Export CSV des funding transfers

Contexte

Les transferts internes de funding (mouvements entre balance accounts) n'étaient consultables que via le listing du Back-Office. Les équipes finance ne disposaient d'aucun moyen d'exporter ces données pour réaliser des rapprochements, contrôles ou analyses en dehors de la plateforme.

Fonctionnement

Un export CSV des funding transfers est désormais disponible depuis le Back-Office. L'export est asynchrone : l'utilisateur lance la demande, puis reçoit un e-mail avec un lien de téléchargement une fois le fichier généré. Des destinataires en copie (CC) peuvent être ajoutés lors de la demande.

Filtres disponibles : période (date de création), statut, suppliers, montant min/max, type de balance account source et cible (MARKETPLACE, SUPPLIER).

Colonnes du CSV : transferId, createdAt, status, amount, currency, sourceBalanceAccountType, targetBalanceAccountType, supplierExternalId, supplierName, reference, relatedEntityType, relatedEntityId, failureReason.

Règles d'accès :

• OPERATOR : accès à tous les transferts du tenant, avec possibilité de filtrer par supplier.
• SUPPLIER : export restreint aux transferts impliquant son propre balance account. Le filtre supplierIds est silencieusement ignoré.

Chaque export n'est visible que par son créateur (listing et détail).

Impact API

Trois nouveaux endpoints :

• POST /v1/payments/funding-transfers/export — ADM-PAY-105 — Déclenche un export asynchrone avec filtres et CC optionnels. Réponse : 201.
• GET /v1/payments/funding-transfers/export — ADM-PAY-552 — Liste paginée des exports de l'utilisateur courant. Réponse : 200.
• GET /v1/payments/funding-transfers/export/{exportId} — ADM-PAY-504 — Détail d'un export avec lien de téléchargement (si statut READY). Réponse : 200.

Accès : OPERATOR et SUPPLIER.

👉 Côté métier : exportez vos transferts de funding au format CSV pour vos contrôles financiers, rapprochements et analyses, directement depuis le Back-Office.

👉 Côté technique : trois nouveaux endpoints asynchrones avec filtres, tri et pagination. Le modèle suit le même pattern que les exports existants (produits, commandes, payouts).

---

Export CSV des transactions

Contexte

Les transactions PAY n'étaient consultables que via le listing du Back-Office. Les équipes finance et contrôle de gestion ne disposaient d'aucun mécanisme d'export pour exploiter ces données dans leurs outils d'analyse et de rapprochement.

Fonctionnement

Un bouton d'export est désormais disponible sur l'écran des transactions du Back-Office. L'utilisateur peut déclencher un export CSV et ajouter des destinataires en copie (CC) via une modale dédiée.

L'export est accessible aux profils OPERATOR et SUPPLIER, chacun dans le périmètre de ses données.

👉 Côté métier : exportez la liste de vos transactions au format CSV pour vos contrôles, rapprochements et analyses financières sans dépendre du Back-Office.

👉 Côté technique : nouvel export CSV des transactions accessible depuis le Back-Office, avec support des profils opérateur et supplier.

👍

UPDATE

Pagination de la liste des comptes clients d'une catalog view

Contexte

Lorsqu'une catalog view était associée à un grand nombre de comptes clients, la navigation dans la liste devenait difficile. Aucun mécanisme de pagination ni de recherche n'était disponible sur cet écran.

Fonctionnement

La table des comptes clients sur le détail d'une catalog view est désormais paginée côté front avec 10 résultats par page. Un champ de recherche locale permet de filtrer les comptes par nom. La recherche réinitialise automatiquement la pagination à la page 1.

La sélection multiple et la suppression en masse restent fonctionnelles. Si la catalog view contient moins de 10 comptes, la pagination ne s'affiche pas.

👉 Côté métier : naviguez plus facilement dans les comptes clients associés à une catalog view, même lorsqu'il y en a un grand nombre.

👉 Côté technique : pagination front-end et recherche locale sur le composant CatalogViewDetailCustomerAccountsTable, sans modification de l'API.

---

---

Indicateur Online / Offline sur la page détail produit

Contexte

La mention "Online" / "Offline" indiquant la disponibilité d'un produit n'était visible que sur la page liste produit. Les utilisateurs devaient revenir à la liste pour connaître le statut de disponibilité d'un produit.

Fonctionnement

L'indicateur "Online" / "Offline" est désormais affiché directement sur la page de détail d'un produit, offrant un contexte immédiat sur sa disponibilité en front sans navigation supplémentaire.

👉 Côté métier : visualisez instantanément si un produit est en ligne ou hors ligne depuis sa fiche détail.

👉 Côté technique : ajout de l'indicateur de statut sur la page détail produit, sans impact API.

---

---

Événements de transaction — Adaptation des filtres multi-valeurs

Contexte

Les paramètres transactionId et logisticOrderReference sur l'écran des événements de transaction PAY étaient limités à une seule valeur. Le backend supporte désormais des tableaux pour ces paramètres.

Fonctionnement

Les filtres transactionId et logisticOrderReference acceptent désormais plusieurs valeurs simultanément, alignant le Back-Office avec les capacités de l'API. L'affichage des événements de transaction fonctionne correctement sur la page de détail transaction (opérateur et fournisseur) ainsi que dans l'onglet transaction d'une commande.

👉 Côté métier : les événements de transaction s'affichent correctement avec les nouveaux filtres multi-valeurs.

👉 Côté technique : les paramètres transactionId et logisticOrderReference passent de string à string[] côté front.

🔗 Data Hub

📘

NEW

Historique des exécutions — Recherche par ID et filtre par statut

Contexte

Retrouver une exécution spécifique dans l'historique d'un job nécessitait de parcourir manuellement les pages de résultats. Aucun mécanisme de recherche par ID ni de filtrage par statut n'était disponible côté API.

Fonctionnement

Un nouveau endpoint permet de lister les exécutions d'un job d'import ou d'indexation avec recherche et filtrage :

• Recherche par ID via le query param search : match partiel (contains) sur le champ executionId.
• Filtre par statut via le query param statuses (multi-valeurs). Valeurs inconnues silencieusement ignorées.
• Tri par défaut : createdAt:desc. Réponse paginée standard DJUST.

L'endpoint export existant supporte désormais les mêmes paramètres search (sur exportIntegrationId) et statuses (valeurs : SUCCESS, ERROR).

Impact API

• Nouveau : GET /v2/jobs/{jobId}/executions — ADM-JOB-550
• Mis à jour : GET /v1/mapper/jobout/{jobOutId}/exported-item-statuses — ADM-JOBOUT-550
• Paramètres : search (string, optionnel), statuses (array, optionnel)
• Réponse : 200
• Accès : dj-client: OPERATOR
• Rétrocompatibilité : GET /v1/mapper/status/all/{jobId} reste fonctionnel mais marqué deprecated.

📄 Documentation : Job Configuration Overview

👉 Côté métier : retrouvez instantanément une exécution de job par son ID ou filtrez par statut, sans parcourir l'historique page par page.

👉 Côté technique : nouveau endpoint RESTful en v2 avec recherche partielle et filtre multi-valeurs. L'ancien endpoint reste disponible mais deprecated — planifiez la migration.

---

---

Ajout et retrait partiel de suppliers sur un job d'export

Contexte

La modification des suppliers d'un job d'export passait exclusivement par le PUT, qui remplace l'intégralité de l'objet. Dans un contexte multi-opérateurs où chaque opérateur ne voit que les suppliers de ses stores, un PUT écrasait les suppliers configurés par les autres opérateurs.

Fonctionnement

• PATCH : ajoute les suppliers fournis à la liste existante du job (merge additif). Les doublons sont ignorés.
• DELETE : retire les suppliers fournis de la liste existante. Les suppliers absents sont ignorés silencieusement.
• Le champ supplierExternalIds est obligatoire et doit contenir au moins un élément.
• L'API ne vérifie pas l'existence des suppliers.
• Si tous les suppliers sont retirés, le job exporte les commandes de tous les suppliers (comportement par défaut).

Impact API

• PATCH /v2/jobouts/{jobOutId}/suppliers — ADM-JOBOUT-200
• DELETE /v2/jobouts/{jobOutId}/suppliers — ADM-JOBOUT-300
• Body : { "supplierExternalIds": ["", ""] }
• Réponse : 204 No Content
• Accès : OPERATOR uniquement
• Rétrocompatibilité : aucun impact — nouveaux endpoints. Le PUT existant continue de fonctionner.

👉 Côté métier : gérez vos suppliers indépendamment des autres opérateurs — ajoutez ou retirez vos suppliers sans risquer d'écraser la configuration existante.

👉 Côté technique : opérations partielles PATCH/DELETE sur la liste de suppliers, garantissant l'intégrité des données en contexte multi-opérateurs.

👍

UPDATE

Ajout du lead time to ship dans l'export de commande

Contexte

Le champ lead-time-to-ship n'était pas disponible dans les exports de commandes, obligeant les opérateurs à récupérer cette information séparément.

Fonctionnement

Le champ lead-time-to-ship est désormais inclus dans les exports de commandes aux formats CSV et XML. Aucune action n'est requise : le champ est automatiquement disponible dans les prochains exports.

👉 Côté métier : retrouvez le délai d'expédition directement dans vos exports de commandes, sans manipulation supplémentaire.

👉 Côté technique : ajout du champ lead-time-to-ship aux formats d'export CSV et XML.

⚠️

IMPORTANT UPDATE

Refonte du champ suppliers sur les jobs d'export

Contexte

Les endpoints de gestion des jobs d'export (création, mise à jour, listing) utilisaient les IDs internes DJUST pour identifier les suppliers. Or les opérateurs et systèmes tiers travaillent avec l'external ID, qui est l'identifiant métier. Cette refonte aligne l'ensemble des endpoints sur le champ supplierExternalIds.

Fonctionnement

Création et mise à jour (POST / PUT) :

• Le champ suppliers (array d'IDs internes) est remplacé par supplierExternalIds (array d'external IDs).
• L'ancien champ suppliers n'est plus accepté et retourne une erreur 400.
• L'API ne vérifie pas l'existence des suppliers.

Listing et détail (GET) :

• Le champ suppliers retourne désormais un tableau d'objets [{ externalId, name }] au lieu d'un tableau de strings d'IDs internes.
• Le filtre de listing supplierIds est renommé en supplierExternalIds. L'ancien filtre est silencieusement ignoré.
• La liste des suppliers retournée est filtrée selon les stores accessibles par l'operator user connecté. Les suppliers non accessibles sont silencieusement exclus.

Impact API

• POST /v1/mapper/jobout — champ suppliers → supplierExternalIds — Breaking change
• PUT /v1/mapper/jobout/{jobOutId} — champ suppliers → supplierExternalIds — Breaking change
• GET /v1/mapper/jobout / GET /v1/mapper/jobout/{id} — champ suppliers passe de string[] à Array<{ externalId, name }> — Breaking change
• Filtre renommé : supplierIds → supplierExternalIds
• Les endpoints de mutation (PATCH, DELETE) ne sont pas impactés.

📄 Documentation :

• Job Configuration Export Ftp
• Job Configuration Export Api Connector

👉 Côté métier : retrouvez directement le nom et l'identifiant externe de vos suppliers dans la configuration des jobs d'export, sans manipulation d'identifiants techniques internes.

👉 Côté technique : le champ suppliers change de structure sur les GET et est renommé en supplierExternalIds sur POST/PUT. Le filtre de listing est également renommé. Mettez à jour vos intégrations.

🛠️ API

📘

NEW

Liste des suppliers par opérateur

Contexte

Pour récupérer les suppliers associés à ses stores, un opérateur devait appeler GET /public/v1/suppliers avec le header dj-store autant de fois que de stores rattachés. Ce fonctionnement multipliait les appels API et complexifiait l'intégration.

Fonctionnement

Un nouvel endpoint permet de récupérer en un seul appel tous les suppliers des stores de l'opérateur authentifié :

• Retourne uniquement les suppliers des stores auxquels l'opérateur est rattaché.
• Recherche (search) sur id, name, externalId.
• Filtres : storeIds, status, createMinDate, updateMinDate (AND entre clés, OR entre valeurs).
• Tri (sort) sur createdAt, updatedAt, name — défaut : createdAt:desc.
• Pagination standard DJUST. Dédoublonnage des suppliers présents dans plusieurs stores.

Impact API

• GET /v1/suppliers — ADM-SUPPLIER-550
• Réponse : 200 avec liste paginée standard
• Accès : OPERATOR uniquement
• Rétrocompatibilité : aucun impact — nouvel endpoint. GET /public/v1/suppliers reste inchangé.

📄 Documentation : Suppliers

👉 Côté métier : récupérez tous vos suppliers en un seul appel, quel que soit le nombre de stores rattachés à votre compte opérateur.

👉 Côté technique : réduit le nombre d'appels API de N (un par store) à 1. Supporte search, filtres, tri et pagination.

---

---

Association de Customer Tags à un Customer Account via External Ids

Contexte

L'association de Customer Tags à un Customer Account passait par le champ customerTagList sur le PUT /v1/customer-accounts/{customerAccountId}, qui n'acceptait que les noms des tags. Les noms pouvant changer ou contenir des caractères ambigus, cette approche n'était pas fiable pour les intégrations programmatiques.

Fonctionnement

Un nouvel endpoint dédié permet de gérer les associations via les External Ids des Customer Tags :

• Remplacement intégral de la liste des tags associés (full replace).
• Envoyer une liste vide supprime toutes les associations.
• Comportement atomique : si un seul External Id est invalide, aucun changement n'est appliqué.
• L'endpoint existant PUT /v1/customer-accounts/{customerAccountId} et son champ customerTagList restent inchangés.

Impact API

• PUT /v1/customer-accounts/{customerAccountId}/customer-tags — ADM-ACCOUNT-250
• Path param : customerAccountId (External Id du Customer Account)
• Champ : customerTagExternalIds (array of string)
• Réponse : 204 No Content
• Accès : OPERATOR uniquement

📄 Documentation : Customers

👉 Côté métier : gérez vos associations Customer Tags de manière fiable, sans dépendre de noms susceptibles de changer.

👉 Côté technique : nouvel endpoint PUT dédié, basé sur les External Ids — intégration simplifiée et identifiants stables.

---

---

Refund partiel par montant libre et financement avec politique marketplace

Contexte

Jusqu'à présent, seul le refund total était supporté par DJUST PAY. Les opérateurs marketplace n'avaient pas la possibilité d'effectuer un remboursement partiel sur une commande, ni de configurer une politique de financement impliquant le balance account marketplace en cas de fonds insuffisants côté supplier.

Fonctionnement

Refund partiel par montant libre :

• L'opérateur peut désormais déclencher un refund partiel en spécifiant un montant libre (champ amount).
• Plusieurs refunds partiels successifs sont possibles sur une même commande, dans la limite du montant total de la commande.
• Le statut de paiement de la commande reflète l'état du remboursement (total ou partiel).
• La commission marketplace est recalculée proportionnellement au montant remboursé.

Financement du refund :

• Le refund (total ou partiel) est financé depuis le balance account supplier.
• Si les fonds du supplier sont insuffisants, la politique de financement configurée au niveau du tenant permet de recourir au balance account marketplace pour couvrir la différence.
• Le mécanisme de financement est identique pour les refunds totaux et partiels.

Impact sur les payouts supplier :

• Une commande partiellement remboursée reste éligible au payout, avec un montant ajusté tenant compte du remboursement effectué.

Impact API

• POST /v1/orders/{orderId}/refund — ADM-ORDER-100
• Champ amount (optionnel) : montant du refund partiel. Si absent, refund total.
• Réponse : 200
• Accès : OPERATOR

📄 Documentation :

• Refunds
• Introduction To Djust Pay
• Managing Card Payments
• Supplier Payout Lifecycle

👉 Côté métier : remboursez partiellement vos clients avec un montant libre, tout en garantissant le financement du refund même si les fonds supplier sont insuffisants grâce à la politique marketplace.

👉 Côté technique : le champ amount sur l'endpoint de refund permet le remboursement partiel. Le financement supporte le fallback sur le balance account marketplace. Les payouts sont ajustés automatiquement.

👍

UPDATE

Exposition du mode Adyen dans la configuration

Contexte

L'attribut mode (standard ou marketplace) n'était pas remonté dans la réponse de l'endpoint de configuration Adyen, empêchant le Back-Office d'adapter l'affichage en fonction du mode actif (notamment la visibilité des commissions).

Fonctionnement

L'attribut mode est désormais inclus dans le DTO adyenConfigurationDto retourné par l'API /settings/adyen. Le Back-Office peut ainsi conditionner l'affichage des fonctionnalités spécifiques au mode marketplace (commissions, balance accounts, etc.).

Impact API

• GET /settings/adyen — nouveau champ mode dans la réponse
• Rétrocompatibilité : ajout d'un champ — aucun breaking change.

👉 Côté métier : l'affichage du Back-Office s'adapte automatiquement au mode Adyen configuré (standard ou marketplace).

👉 Côté technique : nouveau champ mode dans adyenConfigurationDto, permettant de conditionner l'affichage côté front.

Périmètre

🖥️ Back-Office

📘

NEW

Export des transactions supplier au format CSV

Contexte

Les équipes finance et contrôle de gestion ne disposaient pas d'un accès direct à l'export des transactions supplier depuis le Back-Office DJUST. L'extraction de ces données nécessitait des manipulations manuelles ou des requêtes techniques, freinant les opérations de rapprochement et d'analyse.

Fonctionnement

Un nouvel export CSV est désormais disponible depuis le Back-Office, permettant de télécharger la liste des transactions associées aux suppliers. Cet export est conçu pour être exploité directement dans Excel ou un outil BI pour les besoins de contrôle, rapprochement comptable et analyse financière.

👉 Côté métier : les équipes finance peuvent désormais exporter les transactions supplier en quelques clics depuis le Back-Office, sans dépendance technique.

👉 Côté technique : aucun impact sur les API existantes. Fonctionnalité limitée à l'interface Back-Office.

👍

UPDATE

Import Job SFTP — Sélection obligatoire du délimiteur CSV

Contexte

Lors de la configuration d'un job d'import CSV, le champ Délimiteur disposait d'une valeur par défaut (Virgule). Un utilisateur pouvait sauvegarder un job sans avoir consciemment vérifié le délimiteur, ce qui pouvait entraîner un import en succès apparent mais sans aucune donnée réellement intégrée si le fichier source utilisait un autre séparateur.

Fonctionnement

Le champ Délimiteur est désormais vide par défaut à la création d'un nouveau job d'import CSV. Il devient obligatoire au même titre que le nom du job et le connecteur : une erreur de validation s'affiche si l'utilisateur tente de sauvegarder sans avoir effectué de sélection explicite.

Ce changement s'applique uniquement aux jobs d'import de format CSV. Les jobs existants ne sont pas impactés.

👉 Côté métier : les erreurs d'import silencieuses liées à un mauvais délimiteur sont éliminées grâce à la sélection explicite obligatoire.

👉 Côté technique : aucun impact API. Changement limité à l'interface Back-Office de configuration des jobs d'import.

🔗 Data Hub

📘

NEW

Synchronisation manuelle des produits Mirakl (CM21)

Contexte

La synchronisation des produits vers Mirakl (appel CM21) nécessitait jusqu'ici de passer par un cycle d'import complet. En cas d'incident ou de désynchronisation, il n'existait aucun moyen de re-déclencher cette synchronisation de manière ciblée sans intervention côté Mirakl.

Fonctionnement

Un nouvel endpoint permet de déclencher manuellement la synchronisation CM21 sur une liste ciblée de produits, sans import complet.

• Envoyez une liste de produits sous forme de paires miraklProductId / productSku.
• Le système résout automatiquement le client Mirakl à utiliser :
• Si un clientSpecificationId est fourni, cette configuration est utilisée directement.
• Si non fourni et qu'un seul client Mirakl actif existe, il est utilisé automatiquement.
• Si plusieurs clients actifs existent, une erreur 400 est renvoyée avec la liste des IDs disponibles.
• Si aucun client Mirakl n'est configuré ou si tous sont inactifs, une erreur 400 explicite est renvoyée.
• Les erreurs Mirakl (API indisponible, produit inconnu) sont propagées dans la réponse.
• Cet endpoint est un ajout pur : aucune API existante n'est modifiée.

Impact API

POST /v1/mapper/mirakl/product-synchronizations — operationId : ADM-MIRAKL-100

• Body :
• clientSpecificationId (string, format uuid, optionnel) — ID de la configuration Mirakl à utiliser
• products (array, requis, min 1 élément) — Liste d'objets { miraklProductId, productSku }
• Réponse : 200 avec synchronizedProducts (nombre de produits envoyés) et clientSpecificationId (client utilisé)
• Erreurs : 400 (validation, résolution client), 401, 403, 404 (clientSpecificationId inconnu)
• Accès : Opérateur uniquement (dj-client: OPERATOR)

📄 Documentation : Mirakl Product Synchronization

👉 Côté métier : débloquez vos produits en attente de synchronisation Mirakl en quelques secondes, sans import complet ni intervention côté Mirakl.

👉 Côté technique : nouvel endpoint POST ciblé qui déclenche CM21 à la demande, avec résolution automatique du client Mirakl et gestion d'erreurs explicite.

⚠️

IMPORTANT UPDATE

Jobs d'export — Enrichissement des suppliers et renommage de filtre

Contexte

La réponse des endpoints de consultation des jobs d'export retournait les suppliers sous forme d'identifiants internes DJUST, obligeant les consommateurs à effectuer des appels API supplémentaires pour obtenir les noms lisibles. Par ailleurs, le paramètre de filtre utilisait les IDs internes, en décalage avec la convention des autres endpoints qui privilégient les identifiants externes.

Fonctionnement

Le champ suppliers dans la réponse retourne désormais un tableau d'objets { externalId, name } au lieu d'un tableau de chaînes d'IDs internes. Cette modification s'applique au listing et au détail des jobs d'export.

Le filtre supplierIds est renommé en supplierExternalIds (multi-valeurs, relation OR). L'ancien filtre supplierIds est ignoré silencieusement.

La liste des suppliers retournée est filtrée selon les stores accessibles par l'opérateur : les suppliers hors périmètre sont silencieusement exclus.

⚠️ Breaking change : le format du champ suppliers en réponse passe de string[] à [{ externalId, name }]. Les intégrations existantes qui consomment ce champ doivent être adaptées.

Impact API

• GET /v1/mapper/jobout (listing) — champ suppliers enrichi, filtre supplierExternalIds remplace supplierIds
• GET /v2/mapper/jobout/{id} (détail) — champ suppliers enrichi
• Deprecation : GET /v1/mapper/jobout/{jobOutId} est deprecated au profit de GET /v2/mapper/jobout/{id}

📄 Documentation :

• Job Configuration Export Ftp
• Job Configuration Export Api Connector

👉 Côté métier : identifiez immédiatement les suppliers de chaque job d'export grâce à leur nom, sans appel API supplémentaire.

👉 Côté technique : réponse enrichie avec externalId + name. Filtrage par external IDs aligné avec les conventions des autres endpoints. Migration vers le endpoint v2 recommandée.

🛠️ API

👍

UPDATE

Détail d'un événement de transaction — Champ authorisationCode

Contexte

Dans le cadre de la consultation du détail d'un événement de transaction, le code d'autorisation bancaire (authorisationCode) n'était pas exposé dans la réponse API. Cette information est pourtant essentielle pour le rapprochement des opérations de paiement et le suivi des transactions côté métier.

Fonctionnement

Le champ authorisationCode est désormais remonté dans la réponse du endpoint de détail d'un événement de transaction. Ce champ contient le code d'autorisation retourné par l'acquéreur lors du traitement du paiement.

Ce changement est rétrocompatible : il s'agit d'un ajout de champ dans la réponse, sans modification du comportement existant.

Impact API

Ajout du champ authorisationCode dans la réponse du GET détail d'un événement de transaction.

📄 Documentation : Event Details

👉 Côté métier : le code d'autorisation bancaire est désormais directement accessible dans le détail d'un événement de transaction, facilitant le rapprochement et le suivi des paiements.

👉 Côté technique : nouveau champ authorisationCode ajouté à la réponse existante, sans rupture de compatibilité.

Périmètre

🖥️ Back-Office

📘

NEW

Export des transactions supplier

Contexte

Les équipes finance et contrôle de gestion avaient besoin d'exporter les transactions supplier depuis le back-office DJUST, afin de réaliser des rapprochements comptables et des analyses dans Excel ou un outil BI.

Fonctionnement

Un opérateur (dj-client: OPERATOR) peut désormais déclencher un export CSV des transactions supplier directement depuis le back-office. L'export est asynchrone : une fois lancé, il apparaît dans une nouvelle page dédiée au suivi des exports.

Cette page de suivi permet de :

• Consulter la liste des exports en cours et terminés
• Visualiser le statut de chaque export (en cours, terminé, en erreur)
• Comprendre les erreurs éventuelles
• Télécharger le fichier CSV une fois l'export terminé

📄 Documentation : Transactions Export

👉 Côté métier : les équipes finance disposent d'un accès direct à l'export des transactions depuis le back-office, avec un suivi complet du cycle de vie de chaque export.

👉 Côté technique : nouvelle fonctionnalité back-office d'export CSV asynchrone avec page de suivi intégrée.

👍

UPDATE

Affichage des horaires en UTC dans le scheduler d'import

Contexte

Les horaires configurés dans le scheduler des jobs d'import sont exécutés en UTC côté plateforme. Cependant, l'interface du back-office ne mentionnait pas explicitement ce fuseau horaire, ce qui pouvait entraîner des confusions lors de la planification, notamment en période de changement d'heure (DST).

Fonctionnement

L'interface de planification des jobs d'import affiche désormais clairement que les horaires sont exprimés en UTC :

• La mention (UTC) apparaît à côté des champs de configuration horaire.
• Un texte explicatif sous le titre « Planification automatique » précise que les horaires sont en UTC.
• Cette indication est présente sur tous les onglets de planification : Min., Heure, Jour, Semaine, Mois, Avancé.

Ce changement est purement cosmétique : le comportement du scheduler et les expressions CRON générées restent strictement identiques.

👉 Côté métier : les utilisateurs identifient immédiatement que les horaires de planification sont en UTC, évitant toute confusion lors de la configuration des jobs d'import.

👉 Côté technique : aucun impact API ni changement de comportement — modification d'affichage uniquement.

---

Catalog View Rules — Navigation améliorée dans les listes longues

Contexte

Sur la page de détail d'une Catalog View, les boutons d'ajout de règles étaient uniquement positionnés en haut de la liste. Lorsque le nombre de règles est important (plusieurs pages de résultats), l'utilisateur devait systématiquement remonter en haut de page pour ajouter une nouvelle règle, ce qui pénalisait l'ergonomie.

Fonctionnement

Un bouton de remontée rapide (curseur) est désormais affiché en bas de la liste des règles, après la dernière règle visible. Il permet de revenir en haut de la liste sans scroll manuel.

Le bouton « Save a rule » reste positionné en haut de la page, son emplacement est inchangé.

👉 Côté métier : la gestion des règles de Catalog View est plus fluide sur les listes longues, avec un accès rapide aux actions d'ajout sans scroll inutile.

👉 Côté technique : aucun impact API — amélioration d'ergonomie back-office uniquement.

🔗 Data Hub

👍

UPDATE

Activation automatique des settings d'export

Contexte

Les settings d'export (exportOrderEnabled, exportIncidentEnabled) étaient jusqu'à présent gérés manuellement via le back-office ou par feature flag. Cette gestion manuelle pouvait entraîner des incohérences entre la configuration et les jobs d'export réellement configurés.

Fonctionnement

Les settings d'export sont désormais pilotés automatiquement par la plateforme :

• Lorsqu'un job d'export est créé (commandes ou incidents), le setting correspondant est automatiquement activé.
• Lorsque le dernier job d'un type donné est supprimé, le setting est automatiquement désactivé.

Ce comportement s'applique aux deux types d'export :

• Commandes : exportOrderEnabled
• Incidents : exportIncidentEnabled

Les settings exportOrderEnabled et exportIncidentEnabled deviennent en lecture seule via l'API : ils restent consultables via GET /v1/settings/general, mais ne sont plus modifiables via PUT /v1/settings/general. Toute mise à jour des settings généraux via le PUT ignorera ces deux champs.

Impact API

PUT /v1/settings/general : les champs exportOrderEnabled et exportIncidentEnabled ne sont plus pris en compte lors de la mise à jour. Ils sont toujours retournés en lecture via GET /v1/settings/general.

Rétrocompatibilité : aucune action requise côté intégrateur. Les appels existants au PUT continuent de fonctionner, ces champs sont simplement ignorés.

📄 Documentation : Job Configuration Overview

👉 Côté métier : la configuration des exports est désormais entièrement automatique et toujours cohérente avec les jobs d'export configurés, sans intervention manuelle.

👉 Côté technique : les settings exportOrderEnabled et exportIncidentEnabled passent en lecture seule sur l'API. Leur valeur est pilotée automatiquement par le cycle de vie des jobs d'export.

🛠️ API

📘

NEW

Financement des payouts supplier via le balance account marketplace

Contexte

Certaines marketplaces refusent d'avancer de la trésorerie pour financer les payouts supplier, tandis que d'autres souhaitent pouvoir débloquer des paiements en utilisant leur propre balance account marketplace (BA_MKP) comme source de financement.

Fonctionnement

Un opérateur marketplace peut désormais activer ou désactiver l'utilisation du balance account marketplace comme source de financement des payouts supplier.

Lorsque cette option est activée :

• Le BA_MKP peut être utilisé pour compléter le financement d'un payout supplier lorsque le balance account supplier ne dispose pas de fonds suffisants.

Lorsque cette option est désactivée :

• Seul le solde disponible sur le balance account supplier est utilisé. Si les fonds sont insuffisants, le payout reste en attente.

Ce paramétrage respecte les contraintes propres à chaque marketplace en matière de gestion de trésorerie.

📄 Documentation : Supplier Payout Lifecycle

👉 Côté métier : les opérateurs marketplace disposent d'un levier de configuration pour choisir s'ils acceptent d'avancer de la trésorerie via leur BA pour financer les payouts supplier.

👉 Côté technique : nouveau paramétrage permettant d'activer ou désactiver le BA_MKP comme source de financement des payouts supplier.

---

Mise à jour en masse des custom fields sur les lignes de commande logistique

Contexte

Jusqu'à présent, la mise à jour des custom fields sur les lignes d'une commande logistique nécessitait des appels unitaires ligne par ligne. Pour les commandes comportant de nombreuses lignes, cette approche était coûteuse en nombre d'appels et peu pratique pour les intégrateurs.

Fonctionnement

Un nouveau endpoint permet de mettre à jour les custom fields de 1 à 100 lignes d'une commande logistique en une seule requête.

L'endpoint fonctionne en mode partial success : chaque ligne est traitée indépendamment. Les lignes valides sont mises à jour, tandis que les lignes en erreur sont ignorées et remontées sous forme de warnings dans la réponse.

La réponse (HTTP 200) ne contient que les lignes en échec. Un tableau de warnings vide signifie que toutes les lignes ont été mises à jour avec succès.

Règles de validation :

• Chaque logisticOrderLineId doit exister dans la commande logistique ciblée et ne peut apparaître qu'une seule fois dans la requête.
• Chaque customFieldId doit référencer un custom field valide (identifié par son EXTERNAL_ID).
• Si customFieldValue est omis ou null, la valeur du custom field est effacée.

Scoping : réservé aux customer users (dj-client: ACCOUNT), avec support du scoping par dj-store et dj-store-view.

Impact API

PATCH /v1/shop/logistic-orders/{logisticOrderId}/lines (operationId : ORDER-251)

• Le path parameter logisticOrderId attend un identifiant de type REFERENCE.
• Query parameter optionnel locale pour les custom fields traduisibles.
• Réponse 200 avec tableau de warnings (codes F-W-001, F-W-004).
• Erreurs structurelles (body vide, doublons, dépassement de 100 lignes) : 422.

Référence complète des codes : Error / Warning codes

📄 Documentation : Bulk Update Custom Fields On Logistic Order Lines

👉 Côté métier : les custom fields des lignes de commande logistique peuvent être mis à jour en masse, simplifiant la gestion des commandes volumineuses.

👉 Côté technique : nouveau endpoint PATCH en mode partial success, traitant jusqu'à 100 lignes par requête avec remontée granulaire des erreurs par ligne.

👍

UPDATE

Enrichissement des filtres et du tri sur la liste des operator users

Contexte

Suite à l'introduction de l'affectation de stores aux operator users, la route de listing des operator users a été enrichie pour offrir des capacités avancées de recherche, filtrage et tri.

Fonctionnement

La route de listing des operator users propose désormais :

Recherche full-text : le paramètre search permet une recherche sur les champs email, firstName et lastName.

Nouveaux filtres :

• ids — filtrage par identifiant(s) interne(s) DJUST
• externalIds — filtrage par identifiant(s) externe(s)
• status — filtrage par statut (ACTIVE / INACTIVE)
• groups — filtrage par groupe(s) / profil(s)
• storeIds — filtrage par store(s) affecté(s)

Tous les filtres multi-valeurs fonctionnent en logique OR. Les paramètres de filtre inconnus sont silencieusement ignorés.

Tri : les champs triables sont id, externalId, email, civility, firstName, lastName, fullName, locale, status, createdAt, updatedAt. Le format attendu est field:direction (ex : lastName:asc). Les entrées de tri malformées sont silencieusement ignorées.

Impact API

GET /v1/operator-users (operationId : ADM-OPERATOR-USER-550)

• Nouveaux query parameters : search, ids, externalIds, status, groups, storeIds
• Support du tri multi-critères via sort
• Réservé aux opérateurs (dj-client: OPERATOR)

Rétrocompatibilité : les appels existants sans les nouveaux paramètres continuent de fonctionner à l'identique.

📄 Documentation : Back End Users

👉 Côté métier : la gestion des operator users bénéficie de capacités de recherche et filtrage avancées, notamment par store, groupe ou statut, facilitant l'administration des accès.

👉 Côté technique : nouveaux filtres et options de tri sur ADM-OPERATOR-USER-550. Rétrocompatible, aucune migration nécessaire.

---

Enrichissement des warnings de synchronisation avec le détail des changements

Contexte

Lors de la synchronisation d'une commande commerciale, les warnings retournés contenaient un message texte décrivant les modifications détectées. Le front-end devait parser ce texte pour en extraire les valeurs avant/après, ce qui était fragile et peu maintenable.

Fonctionnement

Chaque warning retourné par la synchronisation peut désormais inclure un champ structuré changes, un tableau d'objets décrivant précisément les modifications détectées :

• field : le nom du champ impacté
• previousValue : la valeur avant synchronisation
• newValue : la valeur après synchronisation (ou la valeur de la contrainte pour les warnings bloquants)

Toutes les valeurs sont exprimées en string pour garantir l'homogénéité du format.

Le champ changes est optionnel : il est présent uniquement lorsque des différences de valeurs sont applicables (changement de prix, de quantité, de custom fields, etc.). Pour les warnings portant sur l'existence, l'activation ou l'éligibilité d'une ressource, le champ est absent.

Rétrocompatibilité : les champs existants (id, code, blocked, detail) restent inchangés. Le champ changes est un ajout non-breaking.

Impact API

PUT /v1/shop/commercial-orders/{commercialOrderId}/sync (operationId : ORDER-223)

• Nouveau champ optionnel changes (array) dans chaque objet warning de la réponse 200.
• Structure de chaque entrée : { field: string, previousValue: string, newValue: string }.

Référence complète des codes : Error / Warning codes

📄 Documentation : Synchronize a draft order

👉 Côté métier : les modifications détectées lors de la synchronisation sont désormais structurées et exploitables directement, permettant un affichage clair des valeurs avant/après dans l'interface.

👉 Côté technique : nouveau champ optionnel changes dans les warnings de ORDER-223, éliminant le besoin de parser le champ detail pour extraire les valeurs modifiées.