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

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

⚠️

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.