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.