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 :

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