Périmètre

🖥️ Back-Office

📘
NEW

Configuration des valeurs de custom fields sur les stores

Contexte

Des custom fields peuvent être rattachés à la cible STORE et alimentés par une intégration via l'API, mais leurs valeurs n'étaient consultables nulle part dans le Back-Office. Un opérateur ne pouvait ni vérifier ce qui était réellement stocké sur un store, ni corriger une valeur sans passer par un appel API.

Fonctionnement

La fiche d'un store expose désormais une section dédiée aux custom fields, alignée sur celle déjà présente sur les autres entités (comptes clients, utilisateurs, fournisseurs, offres, commandes, devis…).

L'opérateur y consulte et modifie les valeurs des custom fields configurés sur la cible STORE, chaque valeur étant présentée dans le champ correspondant à son type (TEXT, LONG_TEXT, DATE, BOOLEAN, NUMBER, LIST_TEXT). Une valeur vidée puis enregistrée est supprimée ; un enregistrement du formulaire sans modification des custom fields laisse les valeurs existantes intactes.

Si aucun custom field n'est configuré sur la cible STORE, la section ne s'affiche pas. Le reste de la fiche store (informations générales, store views, locales, mode de taxe) est inchangé.

📄 Documentation :

👉 Côté métier : les valeurs de custom fields des stores deviennent visibles et administrables directement depuis le Back-Office, sans dépendre d'un appel API ni d'une intervention technique.

👉 Côté technique : la lecture et la mise à jour s'appuient sur les champs customFieldValues déjà exposés par le contrat store existant, sans nouvel endpoint.

👍
UPDATE

Identifiant externe sur la fiche d'un utilisateur fournisseur

Contexte

La fiche détail d'un utilisateur fournisseur n'affichait aucun identifiant. Un opérateur devant rapprocher un utilisateur du Back-Office avec une donnée issue du système du client n'avait aucun moyen de le faire depuis l'écran.

Fonctionnement

L'identifiant externe de l'utilisateur fournisseur est désormais affiché dans le bloc d'informations de l'en-tête de sa fiche, à côté de l'adresse email.

Il est copiable en un clic, avec le retour visuel habituel du Back-Office, et présenté en lecture seule : l'identifiant externe n'est pas modifiable après la création de l'utilisateur. Si un utilisateur n'en porte pas, rien n'est affiché plutôt qu'un bloc vide. Le libellé est disponible en français et en anglais.

L'affichage de l'identifiant externe dans la liste des utilisateurs fournisseurs, ainsi que la recherche ou le filtre sur cet identifiant, restent hors périmètre.

👉 Côté métier : un opérateur retrouve immédiatement un utilisateur fournisseur à partir de l'identifiant utilisé dans les systèmes du client.

👉 Côté technique : l'identifiant externe exposé sur la fiche est celui retourné par l'API de consultation d'un utilisateur fournisseur.

Langue des emails transactionnels contextualisée sur le store

Contexte

Les emails transactionnels étaient envoyés dans la langue principale du tenant, quel que soit le store sur lequel la commande était passée. Un client commandant sur un store d'une autre langue recevait sa confirmation de commande ou son email de réinitialisation de mot de passe dans une langue qui n'était pas la sienne.

Fonctionnement

La langue d'envoi des emails transactionnels est désormais résolue sur la locale principale du store à l'origine de l'événement, et non plus sur la locale principale du tenant.

Un mécanisme de repli est prévu : si aucun template n'est configuré pour la locale du store, l'envoi est retenté sur la locale principale du tenant. Si aucun template n'est configuré non plus pour cette locale, l'email n'est pas envoyé et le log d'échec existant est conservé — comportement inchangé par rapport à aujourd'hui.

Aucune configuration supplémentaire n'est requise : les templates déjà configurés par locale sont utilisés tels quels.

Limite connue : un store exposant plusieurs locales actives enverra la même langue à tous ses clients, celle de sa locale principale. La contextualisation sur la locale réellement active côté front n'est pas couverte.

📄 Documentation : Email Localization

👉 Côté métier : les clients reçoivent leurs emails transactionnels dans la langue du store sur lequel ils commandent, sans configuration supplémentaire.

👉 Côté technique : la résolution de la locale d'envoi s'appuie sur la locale principale du store, avec repli sur la locale principale du tenant.

🔗 Data Hub

📘
NEW

Import par dépôt de fichier — connector de type File

Contexte

Les jobs d'import du Data Hub nécessitaient jusqu'ici une source externe (SFTP, pull API). Un import ponctuel imposait donc de mettre en place une source dédiée, alors que le mapping et les règles du job existaient déjà.

Fonctionnement

Un nouveau type de connector « File » est disponible sur les jobs d'import. Il permet de déposer un fichier CSV et de déclencher l'exécution d'un job sur ce fichier, sans source externe à configurer.

Le fichier est d'abord uploadé, puis référencé lors du déclenchement du job : l'exécution réutilise le mapping et les règles déjà définis. Le déclenchement peut être immédiat ou différé. Un fichier déposé peut être consulté ou supprimé tant qu'il n'a pas été purgé.

Les jobs existants et leurs connectors actuels ne sont pas impactés.

Impact API

POST /v1/import/files (operationId : ADM-JOB-103) — dépôt d'un fichier CSV
GET /v1/import/files/{id} (operationId : ADM-JOB-500) — consultation d'un fichier déposé
DELETE /v1/import/files/{id} (operationId : ADM-JOB-303) — suppression d'un fichier déposé
POST /v2/mapper/jobs (operationId : ADM-JOB-101) et PATCH /v2/mapper/jobs/{jobId} (operationId : ADM-JOB-200) — prise en charge du connector de type File
GET /v1/mapper/jobs/start/{jobId} (operationId : ADM-JOB-501) — déclenchement d'un job sur un fichier déposé

📄 Documentation :

👉 Côté métier : un import ponctuel se fait par simple dépôt d'un CSV, en réutilisant le paramétrage d'un job existant, sans mise en place d'un flux automatisé.

👉 Côté technique : nouveaux endpoints de gestion des fichiers d'import et prise en charge du connector File sur la création, la modification et le déclenchement d'un job.

👍
UPDATE

Nom du fichier source dans l'historique des exécutions

Contexte

L'historique des exécutions d'un job ne permettait pas de savoir quel fichier avait été traité par chaque exécution. L'information devait être reconstituée par un appel supplémentaire, et devenait indisponible après la purge du fichier.

Fonctionnement

Chaque exécution retournée par l'historique d'un job porte désormais le nom du fichier source traité. L'information reste disponible même après la purge du fichier concerné, et permet d'afficher directement le fichier associé à une exécution dans le Back-Office.

Le reste de la réponse est inchangé : les consommateurs existants ne sont pas impactés.

Impact API

GET /v2/jobs/{jobId}/executions (operationId : ADM-JOB-550) — ajout du nom du fichier source sur chaque exécution.

👉 Côté métier : l'historique d'un job indique directement quel fichier a été importé à chaque exécution.

👉 Côté technique : nouveau champ en lecture seule sur les exécutions retournées par ADM-JOB-550, ajout rétrocompatible.

🛠️ API

📘
NEW

Consultation et liste des incidents côté administration

Contexte

Les incidents étaient pilotables uniquement depuis le storefront. Côté administration, seules la mise à jour d'un incident et la gestion des fils de discussion existaient : un opérateur ne disposait d'aucun moyen de lister les incidents du tenant ni d'en consulter un depuis le Back-Office.

Fonctionnement

Deux nouveaux points d'entrée d'administration complètent le périmètre incidents :

une liste paginée des incidents du tenant, avec filtres et tri disponibles dès la première version ;
une consultation unitaire d'un incident par son identifiant.

Ils reprennent la structure de réponse des routes storefront équivalentes. Le rôle OPERATOR est requis, et l'opérateur accède à l'ensemble des incidents du tenant : contrairement au storefront, aucun cloisonnement automatique par compte client ou par utilisateur n'est appliqué.

Les routes storefront existantes restent inchangées.

📄 Documentation : Order Incident Management Order Order Line

👉 Côté métier : les opérateurs peuvent suivre et consulter l'ensemble des incidents du tenant depuis le Back-Office.

👉 Côté technique : deux nouveaux endpoints d'administration en lecture, miroirs des routes storefront de liste et de consultation unitaire d'un incident.

👍
UPDATE

Liste des commandes logistiques — tris et filtres exploitables côté serveur

Contexte

La recherche de commandes logistiques côté storefront disposait déjà de nombreuses capacités de tri et de filtrage, mais celles-ci étaient inutilisables en pratique : convention de nommage des clés de tri non documentée, absence de tri par défaut, filtres non exposés. Les intégrateurs devaient charger l'intégralité des commandes pour trier et filtrer côté navigateur.

Fonctionnement

La recherche de commandes logistiques du storefront devient pleinement exploitable côté serveur :

Clés de tri en camelCase acceptées, en complément du snake_case déjà fonctionnel. Les tris sur la référence, le statut, la date de création, l'origine de commande et le montant total produits hors taxe sont ainsi accessibles.
Tri par défaut stable lorsque aucun sort n'est fourni, garantissant une pagination déterministe.
Clés de tri invalides ignorées silencieusement : une clé inconnue ne fait plus échouer l'ensemble de la requête, les clés valides de la même requête restent appliquées.
Nouveau filtre sur le numéro de commande, appliqué sur la référence, l'identifiant externe et l'identifiant métier.
Nouveau filtre sur l'origine de commande, permettant par exemple d'exclure les commandes externes côté serveur plutôt qu'après pagination.
Filtre multi-valeurs sur un même custom field : plusieurs valeurs demandées sur un même custom field sont désormais combinées en OU, les critères portant sur des custom fields différents restant combinés en ET. Les custom fields de type MEDIA sont exclus du filtrage.
Tri sur une valeur de custom field, une nouveauté sur la plateforme. Ce tri est limité à une seule clé custom field par requête et n'est disponible que sur le storefront.

Les clés de tri acceptées sont documentées dans le contrat.

Impact API

POST /v1/shop/logistic-orders — nouveaux champs de recherche orderIdentifier et orderOrigin, nouvelle clé de sort sur valeur de custom field, sémantique OU/ET clarifiée sur les critères de custom fields.

📄 Documentation :

👉 Côté métier : les écrans « Mes commandes » d'un storefront peuvent trier et filtrer sur les colonnes métier, y compris les custom fields, sans charger l'intégralité des commandes.

👉 Côté technique : clés de tri en camelCase acceptées et documentées, tri par défaut stable, clés invalides ignorées, nouveaux filtres numéro de commande et origine, tri et filtre multi-valeurs sur custom field côté storefront.

Identifiant externe sur les utilisateurs fournisseurs

Contexte

Les utilisateurs fournisseurs étaient les seuls utilisateurs de la plateforme à ne pas porter d'identifiant externe : les utilisateurs opérateurs, les customer users et les suppliers en disposaient déjà. Les API manipulant ces utilisateurs ne pouvaient donc exposer que l'identifiant interne généré par la plateforme, ce qui est contraire aux conventions des nouveaux contrats.

Fonctionnement

Les utilisateurs fournisseurs portent désormais un identifiant externe, avec le même comportement que partout ailleurs sur la plateforme :

facultatif à la création : le client peut fournir son propre identifiant métier, qui est alors conservé tel quel ;
généré automatiquement s'il n'est pas fourni : tout utilisateur fournisseur en porte donc un ;
unique à l'échelle du tenant : une création en doublon est rejetée avec une erreur explicite ;
non modifiable après la création.

Tous les utilisateurs fournisseurs existants se voient attribuer un identifiant externe généré, sur l'ensemble des tenants : aucun utilisateur ne reste sans identifiant.

Rétrocompatibilité assurée : les endpoints existants de gestion des utilisateurs fournisseurs conservent leur identifiant de référence actuel. Le champ est ajouté, il ne remplace rien, et aucun consommateur existant n'est impacté. La recherche par identifiant externe sur ces endpoints reste hors périmètre.

Impact API

Les endpoints existants de création, consultation, modification et liste par fournisseur acceptent l'identifiant externe à la création et le retournent en lecture. Les nouveaux contrats de liste des utilisateurs fournisseurs exposeront cet identifiant externe comme identifiant principal (id), conformément aux conventions.

📄 Documentation : Supplier Users

👉 Côté métier : les utilisateurs fournisseurs peuvent être rapprochés des référentiels du client via leur propre identifiant métier.

👉 Côté technique : nouveau champ d'identifiant externe, facultatif à la création, généré s'il est absent, unique par tenant et immuable ; ajout rétrocompatible sur les endpoints existants.

Erreurs de validation : code stable et champ fautif dans la réponse 400

Contexte

Une erreur de validation renvoyait bien un statut 400, mais le corps de la réponse était inexploitable : le message brut de la contrainte occupait le champ code, le champ message restait vide, et rien n'indiquait quel paramètre était en cause. Le format variait en plus d'un contrôleur à l'autre pour une même erreur.

Fonctionnement

Les réponses 400 de validation exposent désormais un format homogène sur l'ensemble des routes :

un code d'erreur stable INV0001 lorsque la contrainte ne porte pas de code métier dédié ;
un message lisible préfixé du nom du champ fautif ;
le nom du champ concerné dans le détail de l'erreur.

Exemple de réponse pour un paramètre hors bornes :

{"errors":[{"code":"INV0001","message":"nbPreviewLines : must be less than or equal to 100","detail":"nbPreviewLines"}]}

Rétrocompatibilité : les erreurs qui portaient déjà un code métier conservent exactement le même code et le même message, seul le détail est enrichi du nom du champ. Seules les réponses jusqu'ici inexploitables changent de forme.

Référence complète des codes : Error / Warning codes

📄 Documentation : Error Warnings Codes

👉 Côté métier : une erreur d'appel est immédiatement compréhensible, sans investigation pour identifier le champ en cause.

👉 Côté technique : code INV0001 stable, nom du champ fautif exposé dans le message et le détail, et format de réponse aligné sur toutes les routes.