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 :

👉 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 :

👉 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.