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.