Périmètre

🖥️ Back-Office

👍
UPDATE

Filtre « utilisateurs sans compte »

Contexte

La liste des utilisateurs du Back-Office ne permettait pas d'isoler les utilisateurs orphelins (rattachés à aucun compte).

Fonctionnement

Un nouveau filtre permet de n'afficher que les utilisateurs rattachés à aucun compte, afin de les identifier et de les corriger rapidement.

👉 Côté métier : les opérateurs repèrent et corrigent en un coup d'œil les utilisateurs sans compte.

👉 Côté technique : nouveau filtre « utilisateurs sans compte » sur la liste des utilisateurs du Back-Office.

Gestion des groupes et des rôles — ouverture aux clients

Contexte

Le module de gestion des groupes et des rôles est consolidé pour pouvoir être ouvert aux clients.

Fonctionnement

Principales évolutions :

Rôles regroupés par typologie dans les réponses API et l'affichage des permissions, en remplacement de la liste à plat.
Description fonctionnelle sur chaque rôle, expliquant en une phrase ce qu'il autorise, affichée à côté du nom du rôle.
Renommage d'un groupe désormais possible (API + UI).
Onglet « Utilisateurs » disponible pour les groupes Opérateur et Fournisseur (en plus des groupes Compte).
Création de rôle possible depuis l'interface Back-Office.
Rafraîchissement de session après modification de droits (reconnexion JWT).
Module généralisé (retrait du feature flag) et documentation publiée pour les endpoints de gestion des groupes et des rôles.

👉 Côté métier : la gestion des groupes et des rôles devient plus lisible et peut être ouverte aux clients (rôles typés, descriptions, renommage, création de rôle).

👉 Côté technique : module généralisé (feature flag retiré), réponses API structurées par typologie de rôle, endpoints documentés.

🔗 Data Hub

👍
UPDATE

Import des comptes clients — champ « département »

Contexte

Le champ « département » des adresses n'était pas pris en charge par l'import Data Hub.

Fonctionnement

Le champ department est désormais pris en charge dans l'import des adresses via le Data Hub, en création comme en mise à jour des comptes clients et des organisations. Le champ est optionnel : absent du fichier d'import, il reste null sans générer d'erreur ; renseigné, il est persisté sur l'adresse. Les imports existants ne sont pas impactés.

👉 Côté métier : les adresses importées peuvent désormais porter leur département, utile à la détermination de la zone de livraison.

👉 Côté technique : champ department supporté en création et mise à jour dans l'import d'adresses Data Hub (optionnel, rétrocompatible).

Import des produits — effacement des valeurs vides pour les attributs et champs personnalisés

Contexte

Lors d'un import de produits, une valeur vide transmise pour un attribut ou un champ personnalisé était ignorée, empêchant de vider une valeur existante depuis le fichier d'import. Ce comportement était jusqu'ici conditionné à une activation spécifique.

Fonctionnement

Une valeur vide transmise pour un attribut ou un champ personnalisé (custom field) efface désormais la valeur existante sur la fiche produit, au lieu d'être ignorée. Ce comportement est généralisé à tous les clients : il permet de vider un attribut ou un champ personnalisé directement depuis le fichier d'import, sans intervention manuelle.

👉 Côté métier : vider un attribut ou un champ personnalisé se fait directement depuis le fichier d'import, sans action manuelle.

👉 Côté technique : l'effacement des valeurs vides (attributs et custom fields) à l'import produits est généralisé à tous les clients.

🛠️ API

📘
NEW

Modes de calcul de la TVA

Contexte

Pour s'aligner sur les réglementations locales, DJUST introduit la gestion de deux modes de calcul de la TVA sur les commandes logistiques.

Fonctionnement

Deux modes sont disponibles :

UNIT_ROUNDED_THEN_MULTIPLY — arrondi de la TVA à l'unité, puis multiplication par la quantité ;
LINE_TOTAL_THEN_ROUND — calcul de la TVA sur le total de la ligne, puis arrondi.

Le mode peut être défini au niveau du tenant et surchargé store par store (un store belge peut différer du tenant français). L'override est optionnel : un store sans override hérite du mode du tenant, et à défaut de toute configuration, le mode système UNIT_ROUNDED_THEN_MULTIPLY s'applique. L'override peut être créé, modifié ou supprimé à tout moment (sa suppression fait retomber le store sur le mode du tenant) ; chaque modification est tracée (auteur, date, valeur avant/après).

À la création d'une commande logistique, le mode applicable est figé sur la commande (snapshot) et utilisé pour toutes ses lignes. Une modification ultérieure du mode tenant ou store n'affecte que les nouvelles commandes : les commandes déjà créées conservent leur mode initial, y compris lors d'un recalcul de ligne ou de l'émission d'un avoir. Le mode reste consultable a posteriori pour le SAV et l'audit comptable.

À la mise en production, toutes les commandes existantes sont renseignées avec le mode UNIT_ROUNDED_THEN_MULTIPLY (mode historique). Aucun montant de TVA n'est recalculé : seule la valeur du mode est inscrite, les totaux des commandes existantes restent strictement identiques.

👉 Côté métier : la TVA des commandes logistiques peut être calculée selon deux modes, configurables par tenant et par store, pour respecter les réglementations locales.

👉 Côté technique : mode de calcul TVA (UNIT_ROUNDED_THEN_MULTIPLY / LINE_TOTAL_THEN_ROUND) figé sur la commande à sa création ; aucun recalcul sur les commandes existantes à la MEP.

Avoirs — réexport manuel

Contexte

En cas d'échec d'export d'un avoir, aucune relance manuelle n'était possible, contrairement aux commandes.

Fonctionnement

Un nouvel endpoint permet de relancer manuellement l'export d'un avoir resté en échec, en parité avec le réexport déjà disponible sur les commandes. L'opérateur peut renvoyer un avoir bloqué directement depuis le Back-Office, sans intervention technique. L'action requiert la permission de déclenchement d'export ; l'avoir repasse en attente d'export puis exporté lorsque l'API client est saine.

Impact API

Nouvel endpoint de réexport d'un avoir — réponse 202 Accepted. Requiert la permission de déclenchement d'export.

👉 Côté métier : un avoir bloqué en échec d'export peut être relancé en autonomie depuis le Back-Office.

👉 Côté technique : nouvel endpoint de réexport d'avoir (202 Accepted), en parité avec le réexport des commandes.

Zones de livraison (shipping zones)

Contexte

Le module de gestion des zones de livraison s'enrichit de trois nouvelles opérations Back-Office (opérateur).

Fonctionnement

Modification d'une zone : mise à jour du nom et de la description.
Suppression d'une zone : bloquée tant que des lignes de la matrice de prix référencent la zone (retirer ces lignes d'abord).
Liste des localisations (pays / départements) d'une zone, avec gestion des départements exclus.

Impact API

PUT /v1/shipping-zones/{id} — modification
DELETE /v1/shipping-zones/{id} — suppression
GET /v1/shipping-zones/{shippingZoneId}/locations — liste des localisations

👉 Côté métier : les opérateurs gèrent en autonomie le nom, la description et la composition géographique de leurs zones de livraison.

👉 Côté technique : trois opérations Back-Office (modification, suppression conditionnée, liste des localisations) sur les shipping zones.

👍
UPDATE

Produits — limite de tags portée à 100

Contexte

La limite du nombre de tags associables à un même produit était fixée à 10.

Fonctionnement

La limite passe de 10 à 100 tags par produit.

👉 Côté métier : jusqu'à 100 tags par produit, pour une catégorisation plus fine.

👉 Côté technique : limite de tags par produit portée de 10 à 100.

Commandes logistiques — famille logistique

Contexte

Les commandes logistiques ne portaient pas leur famille logistique.

Fonctionnement

Split du panier par famille : au checkout, le panier est découpé en commandes logistiques selon le triplet (fournisseur, délai d'expédition, famille logistique). Un panier comportant plusieurs familles logistiques pour un même fournisseur et un même délai génère donc une commande logistique par famille. La famille est résolue à partir de la classification de chaque ligne, avec repli sur la famille « Par défaut » en l'absence de rattachement explicite.
Les commandes existantes sans famille restent pleinement fonctionnelles (champ optionnel, rétrocompatible).

Impact API

Les champs logisticFamilyId et logisticFamilyName sont ajoutés au niveau racine des réponses de consultation d'une commande logistique (Front Office et Back Office). Ces champs sont toujours retournés, que le module shipping soit activé ou non. Les commandes commerciales, qui peuvent regrouper plusieurs familles, ne sont pas enrichies.

👉 Côté métier : chaque commande logistique porte sa famille logistique, et le panier est découpé par famille au checkout.

👉 Côté technique : champs logisticFamilyId / logisticFamilyName ajoutés aux réponses de commande logistique (FO et BO), toujours présents ; split du panier par (fournisseur, délai, famille).

Champ « département » dans les adresses

Contexte

Les adresses ne disposaient pas d'un champ département, nécessaire à la détermination de la zone de livraison applicable.

Fonctionnement

Un champ department (optionnel, texte libre — ex. « 75 », « 2A », « 971 ») est ajouté au modèle d'adresse des comptes clients et des organisations. Les adresses existantes sans département continuent de fonctionner et le champ reste null lorsqu'il n'est pas renseigné.

Impact API

Champ department exposé en création, modification et consultation sur l'ensemble des APIs d'adresse (Front Office et Back Office), sans rupture de compatibilité.

👉 Côté métier : les adresses peuvent porter un département, base du calcul de la zone de livraison.

👉 Côté technique : champ department (optionnel) ajouté au modèle d'adresse et exposé sur toutes les APIs d'adresse (FO et BO), rétrocompatible.