Périmètre

🖥️ Back-Office

📘
NEW

Sélecteur multi-stores pour les jobs d'import

Contexte

Dans un contexte multi-stores, il n'était pas possible de configurer directement dans le Back-Office les stores cibles d'un job d'import. Le store devait être indiqué dans le fichier d'import ou le payload.

Fonctionnement

Lors de la création ou de la modification d'un job d'import, un nouveau sélecteur multi-stores est disponible dans le formulaire de configuration. Ce sélecteur permet de définir les stores auxquels les entités importées seront automatiquement rattachées.

Règles principales :

Le sélecteur apparaît uniquement pour les types de jobs compatibles multi-stores (isMultiStore = true) et pour les tenants multi-stores.
Le champ est optionnel : si aucun store n'est sélectionné, le comportement classique est conservé (store défini dans le fichier d'import ou le payload).
En cas de conflit, la configuration du job prévaut sur les valeurs du fichier d'import.
Un bouton "Sélectionner tout / Désélectionner tout" facilite la gestion.
Le type de job NAVIGATION_CATEGORY conserve son comportement actuel (sélecteur single-store + store view).

📄 Documentation :

Bénéfices

👉 Côté métier : configurez une fois les stores cibles directement sur le job d'import, sans avoir à les spécifier dans chaque fichier d'import.

👉 Côté technique : nouveau champ storeExternalIds dans les payloads de création et modification de job (POST / PATCH). Le champ isMultiStore sur le type de job générique conditionne l'affichage du sélecteur.

👍
UPDATE

Affichage de l'ID d'exécution sur les jobs d'import et d'export

Contexte

Lorsqu'un job d'import ou d'export était en erreur, les utilisateurs devaient le signaler en indiquant des informations ambigüe (date, nom de job etc.).

Fonctionnement

Chaque exécution de job (import et export) affiche désormais son identifiant unique ("ID d'exécution") directement dans l'historique des exécutions :

dans la liste des exécutions, via une colonne dédiée.
dans le détail d'une exécution, sous la date.

Un bouton "Copier" permet de récupérer l'ID en un clic pour le transmettre au support DJUST lors d'un signalement d'incident. L'ID est visible pour tous les rôles BO, sans restriction.

Si un job n'a jamais été exécuté, aucun ID n'est affiché. Si l'UUID est trop long, il est tronqué visuellement avec un tooltip affichant l'identifiant complet.

📄 Documentation : Job Configuration Import Api Connector

Bénéfices

👉 Côté métier : identifiez précisément chaque exécution de job grâce à son ID unique et communiquez-le sans ambiguïté au support en cas d'incident.

👉 Côté technique : aucun développement backend — les champs jobStatusId (import) et exportIntegrationId (export) étaient déjà retournés par l'API. Changement purement front-end.

Capture manuelle des commandes PCard L3

Contexte

La capture manuelle d'un paiement depuis le Back-Office était limitée aux commandes de type CREDIT_CARD. Les commandes de type carte achat (PCARD_L3) nécessitent systématiquement une capture manuelle, mais cette action n'était pas disponible dans le BO pour ce type de paiement.

Fonctionnement

Lorsqu'une commande logistique remplit les conditions suivantes, le bouton de capture manuelle est désormais affiché dans le Back-Office :

provider de paiement : DJUST_PAY
type de paiement : PCARD_L3
statut de paiement : AUTHORIZED

Le comportement de la capture reste identique à celui existant pour les cartes de crédit classiques.

📄 Documentation :

Bénéfices

👉 Côté métier : les opérateurs peuvent désormais capturer manuellement les commandes payées par carte achat (PCard L3) directement depuis le Back-Office.

👉 Côté technique : extension de la condition d'affichage du bouton de capture pour inclure le type PCARD_L3 en plus de CREDIT_CARD.

🛠️ API

📘
NEW

Calcul et exécution des payouts supplier

Contexte

Dans le cadre de DJUST PAY, les reversements fournisseurs (payouts supplier) doivent être calculés à partir des commandes éligibles, puis exécutés de manière contrôlée avec vérification des fonds disponibles. Ces deux étapes complètent le workflow de payout marketplace en offrant une gestion complète du cycle de vie des reversements.

Fonctionnement

Calcul des payouts

Pour une période donnée, DJUST PAY identifie toutes les commandes éligibles et les regroupe par supplier :

Conditions d'éligibilité : statut de paiement PAID, statut logistique dans la liste configurée au niveau tenant (allowedLogisticStatuses), commande non déjà associée à un payout SETTLED ou PENDING.
Le montant reversé correspond au montant net crédité sur le balance account supplier (montant capturé moins commissions marketplace, DJUST).
Un payout est créé au statut COMPUTED par supplier. Si le montant est nul, le statut est SKIPPED.
Le calcul est idempotent : relancer sur la même période ne duplique pas les payouts existants.

Exécution des payouts

Lorsqu'un payout est prêt (COMPUTED), DJUST PAY vérifie le solde du balance account supplier :

Si les fonds sont suffisants : un payout PSP est déclenché depuis le BA supplier vers le compte bancaire du supplier. Le payout passe au statut PENDING.
Si les fonds sont insuffisants : le payout passe au statut INSUFFICIENT_FUNDS, aucun appel PSP n'est effectué.
La confirmation finale est gérée par webhooks PSP : succès → SETTLED (commandes marquées comme reversées), échec → FAILED (commandes restent éligibles pour un futur payout).

Traçabilité complète : date de tentative, date de confirmation, identifiant PSP, cause d'échec éventuelle.

Impact API

Nouvelles routes internes DJUST PAY pour le calcul et l'exécution des payouts supplier. Configuration des statuts logistiques éligibles via GET /v1/settings/payouts.

📄 Documentation :

Bénéfices

👉 Côté métier : les reversements fournisseurs sont calculés automatiquement à partir des commandes éligibles, avec vérification des fonds avant exécution et suivi complet du statut jusqu'à confirmation finale.

👉 Côté technique : cycle de vie complet des payouts supplier — COMPUTED → PENDING → SETTLED / FAILED, avec gestion du cas INSUFFICIENT_FUNDS et idempotence du calcul.

Configuration des modes de calcul des taxes

Contexte

Le calcul des taxes sur les lignes de commande logistique reposait uniquement sur un arrondi au niveau unitaire multiplié par la quantité. Cette approche pouvait générer des écarts par rapport à un calcul basé sur le montant total de la ligne, ne répondant pas aux exigences comptables de certains clients.

Fonctionnement

Deux modes de calcul exclusifs sont désormais disponibles :

UNIT_ROUNDED_THEN_MULTIPLY (comportement existant, valeur par défaut) : la taxe est calculée sur le prix unitaire, arrondie, puis multipliée par la quantité.
LINE_TOTAL_THEN_ROUND (nouveau) : la taxe est calculée sur le montant total de la ligne (prix unitaire × quantité), puis arrondie une seule fois.

La configuration est paramétrable au niveau tenant et surchargeable au niveau store. Le mode d'arrondi (roundingMode) est également configurable : centime supérieur, inférieur ou le plus proche (NEAREST). Le mode sélectionné s'applique de manière homogène à toutes les lignes d'une commande logistique et est persisté sur la commande pour traçabilité.

Rétrocompatibilité : le mode par défaut (UNIT_ROUNDED_THEN_MULTIPLY) est appliqué automatiquement si aucune configuration n'est définie.

Impact API

Nouvelles routes d'administration (réservées OPERATOR) :

GET /v1/settings/tax-mode (operationId : ``) — récupération de la configuration tenant
PUT /v1/settings/tax-mode (operationId : ``) — mise à jour de la configuration tenant → 204 No Content
GET /v1/stores/{storeId}/tax-mode (operationId : ``) — récupération de la configuration store (avec fallback sur les valeurs par défaut)
PUT /v1/stores/{storeId}/tax-mode (operationId : ``) — surcharge de la configuration au niveau store → 204 No Content

📄 Documentation : Tax Management With Custom Field Roles

Bénéfices

👉 Côté métier : adaptez le mode de calcul des taxes à vos exigences comptables, avec une granularité tenant ou store, sans impact sur les commandes existantes.

👉 Côté technique : quatre nouvelles routes d'administration pour la configuration des taxes. Le mode par défaut est conservé — aucun breaking change.

👍
UPDATE

Modification des prix confirmés en statut DRAFT

Contexte

La route d'administration de modification des prix confirmés (confirmedPrices) et quantités (confirmedQuantity) sur les lignes de commande logistique n'autorisait pas les modifications lorsque la commande était en statut DRAFT ou DRAFT_ON_HOLD. Cette limitation empêchait certains cas d'usage métier, notamment l'application d'escomptes dynamiques par un système externe avant finalisation de la commande.

Fonctionnement

Les champs confirmedPrices et quantity des lignes de commande logistique sont désormais éditables lorsque la commande est au statut DRAFT_ORDER ou DRAFT_ORDER_ON_HOLD, en plus des statuts déjà autorisés. L'opérateur doit disposer du droit ORDER_UPDATE.

Ce changement permet à un module externe (par exemple un moteur d'escompte) de modifier dynamiquement les prix confirmés sur les lignes avant la finalisation de la commande, puis de les restaurer si le parcours de paiement est abandonné.

Impact API

PUT /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId} — extension des statuts autorisés pour inclure DRAFT_ORDER et DRAFT_ORDER_ON_HOLD.

Bénéfices

👉 Côté métier : les prix confirmés et quantités des lignes de commande logistique peuvent être ajustés en amont de la finalisation, permettant des scénarios d'escompte dynamique.

👉 Côté technique : ajout des statuts DRAFT_ORDER et DRAFT_ORDER_ON_HOLD à la liste des statuts autorisant la modification via la route d'administration existante. Aucun breaking change.

Nouveau champ isReciprocal pour les related products

Contexte

La réciprocité entre produits liés (related products) pouvait être gérée via import, mais pas via l'API Back. Il n'était donc pas possible de définir ou de retirer la réciprocité d'une relation produit directement par appel API.

Fonctionnement

Un nouveau champ isReciprocal (booléen, optionnel, valeur par défaut false) est disponible sur la route de liaison de produits. Lorsqu'il est positionné à true, la relation est créée dans les deux sens : le produit A est lié au produit B, et inversement. Lorsqu'il est positionné à false ou absent, seule la relation unidirectionnelle est créée. Le retrait de la réciprocité supprime automatiquement la relation inverse.

Impact API

PUT /v1/products/{productId}/related-products/{relatedProductId} — nouveau champ isReciprocal (boolean, optionnel, défaut : false).

📄 Documentation : Ftp Related Products Import

Bénéfices

👉 Côté métier : gérez la réciprocité des produits liés directement via l'API, sans passer par un import.

👉 Côté technique : nouveau champ optionnel sur la route PUT existante. Rétrocompatible — le comportement par défaut (non réciproque) est inchangé.

Mise à jour partielle des configurations client Data Hub (PATCH)

Contexte

La mise à jour d’une configuration client (connecteur SFTP, API…) sur le Data Hub nécessitait un appel PUT imposant de renvoyer l’intégralité de l’objet, même pour modifier un seul champ. Cela complexifiait les intégrations et augmentait le risque d’écrasement involontaire de données.

Fonctionnement

Un endpoint PATCH est désormais disponible sur les configurations client. Seuls les champs fournis dans le body sont mis à jour, les champs absents conservent leur valeur existante :

Modifier le statut actif/inactif d’une configuration sans toucher au reste
Modifier la configuration du connecteur (SFTP, API…) sans changer le statut

Impact API

Endpoint : PATCH /v1/mapper/client/{clientId}
Réponse : 200 OK avec la configuration mise à jour
Rétrocompatibilité : le PUT existant reste fonctionnel mais est déprécié

📄 Documentation : Api Client

Bénéfices

👉 Côté métier : modifiez uniquement les paramètres souhaités d'une configuration client Data Hub sans risquer d'écraser le reste de la configuration.

👉 Côté technique : endpoint PATCH standard. Le PUT existant reste fonctionnel.