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.

Périmètre

❗️

La version intialement prévue la semaine du 23 mars a été décalée à la semaine suivante. Les autres releases sont également mécaniquement décalées.

🖥️ Back-Office

📘

NEW

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

Contexte

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

Fonctionnement

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

Règles principales :

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

📄 Documentation :

• Job Configuration Import Ftp
• Job Configuration Import Api Connector

Bénéfices

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

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

👍

UPDATE

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

Contexte

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

Fonctionnement

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

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

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

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

📄 Documentation : Job Configuration Import Api Connector

Bénéfices

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

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

Capture manuelle des commandes PCard L3

Contexte

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

Fonctionnement

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

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

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

📄 Documentation :

• Capture Level 3
• Introduction To Djust Pay

Bénéfices

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

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

Création de compte client sans utilisateur obligatoire

Contexte

Lors de la création d'un compte client depuis le Back-Office, la saisie d'un customer user était systématiquement requise. Or, dans de nombreux scénarios métier, le profil utilisateur existe déjà dans le système et doit simplement être rattaché ultérieurement au nouveau compte. Cette obligation forçait la création de doublons ou bloquait le parcours de création.

Fonctionnement

L'étape de création d'un customer user dans le formulaire de création de compte client est désormais optionnelle. L'opérateur peut :

• Créer un compte client avec un nouveau customer user (comportement existant inchangé).
• Créer un compte client sans customer user, puis rattacher un utilisateur existant dans un second temps.

Rétrocompatibilité : le parcours existant avec création d'utilisateur reste pleinement fonctionnel.

Impact API

POST /v1/customer-accounts — le champ user dans le body de la requête devient optionnel. Si le champ est absent ou null, le compte est créé sans customer user associé.

Bénéfices

👉 Côté métier : créez des comptes clients sans être contraint de créer un nouvel utilisateur, facilitant le rattachement d'utilisateurs existants et évitant les doublons.

👉 Côté technique : le champ user du POST /v1/customer-accounts est désormais optionnel. Aucun breaking change — les appels existants incluant un user restent fonctionnels.

Tooltips sur les rôles d'attributs dans les classifications

Contexte

Dans le Back-Office, les rôles assignables aux attributs au niveau des classifications (ex. : rôle de nom, rôle de description, rôle d'image…) n'étaient pas accompagnés d'explications. Les utilisateurs devaient se référer à la documentation externe pour comprendre la fonction de chaque rôle.

Fonctionnement

Chaque rôle d'attribut disponible dans la configuration des classifications affiche désormais une tooltip explicative au survol. Ces tooltips décrivent en quelques mots la finalité du rôle et son impact sur le comportement du produit dans le contexte catalogue.

Cette amélioration est purement visuelle et n'a aucun impact sur le comportement existant ni sur l'API.

👉 Côté métier : comprenez instantanément la fonction de chaque rôle d'attribut grâce aux tooltips, sans quitter le Back-Office.

👉 Côté technique : aucun impact API — changement purement front-end.

🔗 Data Hub

👍

UPDATE

Affichage des durées de job en heures

Contexte

Sur la page d'historique des jobs d'import du Data Hub, la durée d'exécution était systématiquement affichée en minutes, même lorsque le job durait plusieurs heures. Cela rendait la lecture peu intuitive pour les exécutions longues.

Fonctionnement

Lorsque la durée d'un job d'import dépasse 60 minutes, l'affichage adopte désormais le format heures / minutes / secondes : Xh Ymin Zs (exemple : 1h 12min 34s).

En dessous de 60 minutes, le format existant en minutes et secondes est conservé.

👉 Côté métier : lisez instantanément la durée des jobs longs grâce à un affichage en heures, plus lisible que l'équivalent en minutes.

👉 Côté technique : aucun impact API — changement purement front-end sur le formatage de la durée.

🛠️ API

📘

NEW

Calcul et exécution des payouts supplier

Contexte

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

Fonctionnement

Calcul des payouts

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

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

Exécution des payouts

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

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

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

Impact API

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

📄 Documentation :

• Supplier Payout Lifecycle
• Introduction To Djust Pay

Bénéfices

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

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

Configuration des modes de calcul des taxes

Contexte

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

Fonctionnement

Deux modes de calcul exclusifs sont désormais disponibles :

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

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

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

Impact API

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

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

📄 Documentation : Tax Management With Custom Field Roles

Bénéfices

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

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

👍

UPDATE

Modification des prix confirmés en statut DRAFT

Contexte

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

Fonctionnement

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

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

Impact API

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

Bénéfices

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

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

Nouveau champ isReciprocal pour les related products

Contexte

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

Fonctionnement

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

Impact API

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

📄 Documentation : Ftp Related Products Import

Bénéfices

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

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

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

Contexte

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

Fonctionnement

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

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

Impact API

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

📄 Documentation : Api Client

Bénéfices

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

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

Périmètre

Back-Office

👍

UPDATE

Export Order SFTP : exemple de format du nom de fichier

Contexte

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

Fonctionnement

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

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

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

Pagination de la page des règles de quotas

Contexte

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

Fonctionnement

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

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

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

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

Data Hub

📘

NEW

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

Contexte

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

Fonctionnement

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

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

Impact API

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

📄 Documentation : Job Configuration Overview

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

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

👍

UPDATE

Jobs internes : client de connexion optionnel

Contexte

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

Fonctionnement

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

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

Impact API

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

📄 Documentation :

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

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

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

Auto-activation des produits existants au réimport

Contexte

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

Fonctionnement

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

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

📄 Documentation : Products And Variants

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

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

API

👍

UPDATE

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

Contexte

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

Fonctionnement

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

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

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

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

Impact API

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

📄 Documentation :

• Products And Variants
• Synchronize A Draft Order

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

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

Filtrage par supplier sur les jobs d'export

Contexte

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

Fonctionnement

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

Impact API

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

📄 Documentation :

• Job Configuration Export Api Connector
• Job Configuration Export Ftp

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

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

Périmètre

API

📘

NEW

Liste des transactions

Contexte

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

Fonctionnement

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

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

Impact API

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

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

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

Configuration des payouts fournisseur

Contexte

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

Fonctionnement

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

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

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

Deux nouveaux endpoints permettent de lire et modifier la configuration :

Impact API

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

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

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

👍

UPDATE

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

Contexte

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

Fonctionnement

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

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

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

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

Contexte

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

Fonctionnement

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

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

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

⚠️

IMPORTANT UPDATE

Renommage de route Data Hub (suite)

Contexte

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

Impact API

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

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

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

Data Hub - Suppression d'anciens types de jobs Orders

Contexte

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

Fonctionnement

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

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

Impact API

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

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

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

Périmètre

🛠️ API

📘

NEW

Liste des événements de transaction

Contexte

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

Fonctionnement

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

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

Recherche et filtres :

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

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

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

Impact API

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

Bénéfices

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

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

👍

UPDATE

Synchronisation des commandes commerciales - Mode standard

Contexte

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

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

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

Fonctionnement

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

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

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

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

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

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

Quand appeler la synchronisation

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

Impact API

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

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

Bénéfices

📄 Documentation : Commercial Order Data Model

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

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

Data Hub (Import) - Support multi-store

Contexte

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

Fonctionnement

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

Impact API

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

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

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

Enrichissement des données fournisseur sur les lignes logistiques

Contexte

Lors de la consultation d'une commande logistique, les informations relatives au fournisseur (snapshot) et au délai d'expédition (leadTimeToShip) n'étaient pas exposées sur les lignes logistiques. Ces données, pourtant présentes côté serveur, n'étaient pas remontées dans le DTO, obligeant les intégrateurs à effectuer des appels supplémentaires pour les obtenir.

Fonctionnement

Les endpoints retournant des lignes de commande logistique exposent désormais :

• Le supplier snapshot (supplierSnapshot) directement sur chaque ligne logistique, contenant les informations du fournisseur au moment de la commande.
• Le champ leadTimeToShip dans le bloc offerInventorySnapshot de chaque ligne, indiquant le délai d'expédition associé à l'offre.

Ces données sont en lecture seule et reflètent l'état capturé au moment de la création de la commande logistique. Aucune modification de comportement sur les endpoints existants — il s'agit uniquement d'un enrichissement de la réponse.

Impact API

• Champs ajoutés dans le DTO OrderLogisticLine : supplierSnapshot (objet)
• Champ ajouté dans offerInventorySnapshot : leadTimeToShip
• Rétrocompatibilité : enrichissement additif, aucun impact sur les intégrations existantes.

👉 Côté métier : les opérateurs et fournisseurs accèdent directement aux informations fournisseur et délai d'expédition sur chaque ligne logistique, sans appels supplémentaires.

👉 Côté technique : nouveaux champs supplierSnapshot et leadTimeToShip exposés sur les lignes logistiques — enrichissement additif sans breaking change.

Correction du code erreur pour un custom field introuvable

Contexte

Lorsqu'un custom field était référencé avec un identifiant inexistant pour un type de ressource donné (par exemple ORDER_COMMERCIAL), l'API retournait une erreur 403 Forbidden avec le code CF0011 ("Custom field is forbidden"). Ce comportement était incorrect : un custom field introuvable doit retourner une 404, et non une erreur d'autorisation.

Fonctionnement

Lorsqu'un identifiant de custom field ne correspond à aucun custom field existant pour le type de ressource ciblé, l'API retourne désormais :

• HTTP 404 avec le code F-E-002
• Message : "At least one resource does not exist in Djust system"
• Détail : "No custom field of type {sealedTarget} found for the provided customFieldId : {id}"

Ce correctif s'applique à tous les endpoints utilisant des custom fields (commandes commerciales, offres, lignes, etc.).

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

👉 Côté métier : les messages d'erreur sont désormais explicites lorsqu'un custom field référencé n'existe pas, facilitant le diagnostic.

👉 Côté technique : le code erreur passe de 403 / CF0011 à 404 / F-E-002 pour les custom fields introuvables — adapter les éventuels traitements d'erreur côté client.

⚠️

IMPORTANT UPDATE

Renommage de route Data Hub

Contexte

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

Impact API

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

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

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

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

Périmètre

BackOffice

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

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

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

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

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

⚠️

Attention

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

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

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

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

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

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

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

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

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

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

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

API

📘

NEW

Stores

• Affectation de stores aux operator users

Contexte

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

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

Fonctionnement

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

Impact API

Nouvelle sous-ressource sur le domaine Operator Users :

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

Bénéfices

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

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

Transactions

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

Contexte

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

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

Nouvelle API

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

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

Règles de visibilité

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

• Liste des événements de transaction de paiement

Contexte

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

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

Nouvelle API

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

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

Règles de visibilité

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

👍

UPDATE

Cart v1 / v2

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

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

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

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

Liste des APIs concernées :

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

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

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

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

Mapper

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

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

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

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

• Filtrage des exports de commandes par Supplier

Contexte

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

Fonctionnement

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

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

Impact API

Endpoint : POST /jobout

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

Endpoint : PUT /jobout/{jobOutId}

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

Bénéfices

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

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

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

Contexte

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

Fonctionnement

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

Impact API

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

Bénéfices

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

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

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

Contexte

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

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

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

Fonctionnement

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

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

Aucun changement fonctionnel n’est introduit :

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

Impact API

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

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

Contexte

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

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

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

Fonctionnement

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

Ce job permet toujours par CSV :

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

Impact API

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

Orders

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

Contexte

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

Fonctionnement

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

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

Impact API

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

Bénéfices

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

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