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