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.