Périmètre

🖥️ Back-Office

📘
NEW

Import de type fichier par dépôt d'un CSV depuis le Back-Office

Contexte

Jusqu'ici, un import Data Hub reposait sur une source automatique : un dépôt SFTP ou un appel API. Pour charger ou corriger ponctuellement quelques données, il fallait passer par le SFTP ou solliciter une intervention technique, même pour quelques lignes.

Fonctionnement

Un import peut désormais être alimenté par un fichier CSV déposé directement dans le Back-Office.

À la création de l'import, choisissez le type fichier, indiquez le délimiteur de votre CSV, puis glissez-déposez le fichier. Un aperçu des premières lignes et le nombre de lignes vous permettent de le vérifier avant de configurer le mapping des colonnes, identique à celui d'un import SFTP.
Lancez l'import immédiatement, ou enregistrez le fichier pour le lancer plus tard depuis la page de l'import. Un fichier en attente reste disponible pendant le délai de rétention ; au-delà, il suffit d'en déposer un nouveau.
Réutilisez l'import : à chaque nouveau besoin, déposez un nouveau CSV sur sa page et lancez-le.
Suivez chaque exécution : l'historique de l'import affiche le nom du fichier qui l'a alimentée, y compris après la purge du fichier.

Un fichier au mauvais format ou trop volumineux est signalé dès le dépôt, avant tout lancement. Les imports SFTP et API existants ne changent pas.

📄 Documentation :

👉 Côté métier : importez ou corrigez vos données en quelques clics en déposant un CSV depuis le Back-Office, sans SFTP ni intervention technique.

👉 Côté technique : aucun nouvel endpoint, le Back-Office s'appuie sur les routes de dépôt de fichier et d'import de type fichier déjà disponibles via API ; le nom du fichier affiché dans l'historique provient de l'entrée fileName du tableau metadata de la liste des exécutions.

👍
UPDATE

Page Devis — customer tags et comptes clients identifiés par leur nom ou identifiant externe

Contexte

Sur la page d'un devis, la consultation des prix d'une offre (bouton « œil ») affichait, pour les prix définis au niveau d'un customer tag ou d'un compte client, l'identifiant interne DJUST du customer tag ou du compte. Cet identifiant technique n'a aucune signification pour un opérateur, qui ne pouvait pas reconnaître à quel groupe ou compte s'appliquait le prix.

Fonctionnement

Le détail des prix d'une offre affiché depuis un devis identifie désormais chaque customer tag et chaque compte client par une donnée métier lisible (nom ou identifiant externe) à la place de l'identifiant interne DJUST.

Le reste de la page Devis et le calcul des prix sont inchangés : seule la présentation de la cible du prix évolue.

👉 Côté métier : un opérateur reconnaît immédiatement le groupe client ou le compte auquel s'applique chaque prix d'une offre depuis un devis.

👉 Côté technique : évolution d'affichage uniquement, aucun changement d'API.

🛠️ API

📘
NEW

Liste des utilisateurs fournisseurs

🚧 API uniquement pour le moment.

Contexte

Contrairement aux utilisateurs opérateurs et aux customer users, les utilisateurs fournisseurs ne disposaient d'aucune liste globale : ils n'étaient consultables que fournisseur par fournisseur. Retrouver un utilisateur sans connaître son fournisseur de rattachement était impossible, et tout sélecteur d'utilisateurs fournisseurs imposait un parcours en deux étapes.

Fonctionnement

Un nouvel endpoint d'administration retourne les utilisateurs fournisseurs du tenant, tous fournisseurs confondus, de manière paginée. Il est réservé au rôle OPERATOR et gardé par la permission SUPPLIER_USER_READ, comme les autres endpoints de lecture des utilisateurs fournisseurs. Aucune modification du catalogue de rôles n'est nécessaire.

Filtres facultatifs et combinables (ET entre filtres, OU entre les valeurs d'un même filtre) :

supplierIds : un ou plusieurs fournisseurs ;
search : recherche texte sur le nom, le prénom et l'email ;
statuses : un ou plusieurs statuts utilisateur ;
ids : lot d'identifiants d'utilisateurs.

Tous les identifiants échangés sont des identifiants externes, pour les utilisateurs comme pour les fournisseurs : une valeur reçue en réponse peut être renvoyée telle quelle dans le filtre correspondant. Chaque utilisateur est retourné avec ses informations (email, prénom, nom, civilité, langue, statut, dates) et son fournisseur de rattachement, identifiant et nom.

Les groupes d'appartenance ne sont ni filtrables ni retournés. Les entêtes de store n'ont aucun effet : les utilisateurs fournisseurs sont rattachés au tenant. Les endpoints existants, dont la liste par fournisseur, sont inchangés.

Impact API

GET /v1/supplier-users (operationId : ADM-SUPPLIER-USER-550)

Filtres : supplierIds, search, statuses, ids
Pagination : page (0-based), size (défaut 20, maximum 100) ; entrées de tri invalides ignorées silencieusement
Identifiants : EXTERNAL_ID uniquement, en filtre comme en réponse

📄 Documentation : Suppliers Users

👉 Côté métier : les intégrations peuvent rechercher un utilisateur fournisseur à l'échelle du tenant, avec le nom de son fournisseur, sans connaître au préalable son fournisseur de rattachement.

👉 Côté technique : nouvel endpoint paginé ADM-SUPPLIER-USER-550, symétrique de la liste des utilisateurs opérateurs, entièrement basé sur les identifiants externes et protégé par SUPPLIER_USER_READ.

👍
UPDATE

Offres — quantité minimum de commande par défaut alignée sur 1

Contexte

La quantité minimum de commande d'une offre créée sans valeur renseignée différait selon le canal : une offre importée via le Data Hub recevait la valeur 1, tandis qu'une offre créée via l'API ou depuis le Back-Office recevait 0. Rien ne justifiait fonctionnellement cette différence, qui rendait la donnée incohérente entre la fiche offre, la liste des offres et l'export.

Fonctionnement

La valeur par défaut de minOrderQuantity est désormais 1 quel que soit le canal de création ou de modification :

champ absent ou null à la création ou à la mise à jour d'une offre via l'API → 1 ;
création d'une offre depuis le Back-Office sans renseigner le champ → 1 ;
import d'offres avec colonne vide → 1, comportement inchangé.

Un 0 explicitement envoyé est conservé : il est désormais distingué d'un champ absent. Toute valeur renseignée est respectée.

Aucun impact sur le comportement du panier ni sur la validation des commandes, qui traitent 0 et 1 de façon identique. Les offres existantes créées à 0 ne sont pas modifiées : l'alignement s'applique aux créations et mises à jour futures.

Impact API

POST /v1/offer-inventories et PUT /v1/offer-inventories/{offerInventoryId} — minOrderQuantity absent ou null vaut désormais 1 (au lieu de 0) ; un 0 explicite est conservé

📄 Documentation : Offers and Prices

👉 Côté métier : la quantité minimum de commande affichée sur les offres est cohérente quel que soit le canal de création, sans différence inexpliquée entre import et saisie.

👉 Côté technique : valeur par défaut unique de minOrderQuantity (1) sur la création et la mise à jour d'offres via l'API ; un 0 explicite reste accepté et persisté.