Périmètre

Back-Office

👍
UPDATE

Export Order SFTP : exemple de format du nom de fichier

Contexte

Lors de la configuration d'un job d'export Order via SFTP, l'opérateur pouvait choisir le format du nom de fichier généré (Standard ou Short), mais aucune indication visuelle ne permettait de comprendre à quoi correspond chaque format ni son impact sur le fichier produit.

Fonctionnement

Un exemple de nom de fichier est désormais affiché directement dans l'interface de configuration du job d'export Order SFTP, en fonction du format sélectionné (Standard ou Short). L'opérateur visualise immédiatement le résultat attendu avant de valider sa configuration.

👉 Côté métier : comprenez en un coup d'œil le format de nommage de vos fichiers d'export SFTP grâce à l'exemple affiché lors de la configuration.

👉 Côté technique : aucun impact API — évolution purement interface Back-Office.

Pagination de la page des règles de quotas

Contexte

La page des règles de quotas (business pricing) dans le Back-Office présentait une pagination incomplète : la navigation entre les pages était limitée et le nombre total de résultats n'était pas affiché, rendant difficile le parcours de listes volumineuses.

Fonctionnement

La pagination de la page des règles de quotas est désormais alignée sur le standard des autres pages du Back-Office (commandes, produits, etc.) :

Navigation complète entre les pages (première, précédente, suivante, dernière).
Affichage du nombre total de résultats.

👉 Côté métier : naviguez facilement dans vos règles de quotas grâce à une pagination complète et au compteur de résultats, comme sur les autres pages du Back-Office.

👉 Côté technique : aucun impact API — correction de la pagination côté interface Back-Office uniquement.

Data Hub

📘
NEW

Arrêt manuel d'une exécution de job

Contexte

Lorsqu'une exécution de job Data Hub se bloquait, les exécutions suivantes s'accumulaient en statut PENDING sans possibilité pour l'opérateur d'intervenir depuis le Back-Office. Il fallait alors une action technique pour débloquer la file d'exécution.

Fonctionnement

Un bouton "Stopper l'exécution" est désormais disponible sur la page de détail d'un job Data Hub, au niveau de chaque exécution en cours. Le bouton est visible uniquement pour les exécutions dans un statut stoppable (JOB_INITIALIZING, JOB_STARTED, INTEGRATION_WAITING, INTEGRATION_STARTED, JOB_PENDING) et nécessite la permission MAPPER_WRITE.

Une confirmation est demandée avant l'arrêt (action irréversible).
Après arrêt, la liste des exécutions est rafraîchie automatiquement.
Les exécutions terminées ou en erreur ne présentent pas le bouton.

Impact API

POST /v1/mapper/status/{jobStatusId}/stop
Paramètre : jobStatusId (ID de l'exécution, pas l'ID du job)
Permission requise : MAPPER_WRITE
Réponse : 200 OK (corps vide)

📄 Documentation : Job Configuration Overview

👉 Côté métier : débloquez vous-même une exécution de job Data Hub problématique directement depuis le Back-Office, sans intervention technique.

👉 Côté technique : nouveau bouton d'arrêt appelant POST /v1/mapper/status/{jobStatusId}/stop, conditionné par le statut de l'exécution et la permission MAPPER_WRITE.

👍
UPDATE

Jobs internes : client de connexion optionnel

Contexte

Jusqu'à présent, un client technique "Internal Client" était automatiquement créé pour les jobs de type Order Validation et Indexation, bien que ces jobs n'utilisent aucune connexion externe. Le champ clientConfigurationId étant obligatoire à la création de tout job, ce client inutile devait systématiquement être généré.

Fonctionnement

Le champ clientConfigurationId est désormais optionnel pour les jobs de type INDEXATION_JOB et ORDER_VALIDATION_JOB :

Si le champ n'est pas renseigné pour ces types de jobs, aucune configuration client n'est sauvegardée en base.
Pour tous les autres types de jobs (ex. PRODUCT_CSV), le client reste obligatoire — une erreur est retournée si le champ est absent.
Les jobs internes existants avec un client configuré continuent de fonctionner à l'identique.

Impact API

Endpoint : création de job Data Hub
Champ modifié : clientConfigurationId devient nullable pour les jobs internes (INDEXATION_JOB, ORDER_VALIDATION_JOB)
Rétrocompatibilité : aucun impact sur les jobs existants

📄 Documentation :

👉 Côté métier : le client technique "Internal Client" n'apparaît plus inutilement dans la liste des connexions, simplifiant la lisibilité de l'interface.

👉 Côté technique : simplification de la configuration des jobs internes et suppression d'une dépendance inutile au client de connexion.

Auto-activation des produits existants au réimport

Contexte

Jusqu'à présent, le setting "Auto-activate products & variants on import" n'était pris en compte que lors de la création d'un produit par import. Un produit créé avec le setting désactivé conservait le statut NEW même après un réimport avec le setting activé, obligeant à une activation manuelle depuis le Back-Office.

Fonctionnement

Le setting "Auto-activate products & variants on import" s'applique désormais également lors de la mise à jour d'un produit par import :

Un produit en statut NEW est automatiquement passé à ACTIVE au réimport lorsque le setting est activé.
Le comportement à la création reste inchangé.
Les produits déjà en statut ACTIVE ou autre ne sont pas impactés.

📄 Documentation : Products And Variants

👉 Côté métier : éliminez l'étape manuelle d'activation des produits réimportés. Tous vos produits passent automatiquement en statut actif dès le réimport.

👉 Côté technique : le setting "Auto-activate products & variants on import" couvre désormais la création et la mise à jour, garantissant un comportement cohérent sur l'ensemble du cycle d'import.

API

👍
UPDATE

Synchronisation des commandes commerciales — Vérification de l'éligibilité des catalog views

Contexte

Dans le cadre de la synchronisation des commandes commerciales en mode standard (sans RTP), la vérification de l'éligibilité des produits vis-à-vis des catalog views n'était pas effectuée. Un produit retiré d'une catalog view pouvait rester dans une commande sans être détecté comme inéligible.

Fonctionnement

Lors de la synchronisation d'une commande commerciale, chaque ligne est désormais contrôlée sur la visibilité du produit dans les catalog views éligibles du customer user. Si un produit n'est plus visible dans le contexte courant (retrait d'une catalog view, changement de périmètre), un avertissement bloquant est remonté :

Code F-W-015 — "The product with id {entityId} is not eligible in the current context."

Cette même vérification est également appliquée à l'ajout au panier : un produit non éligible dans les catalog views du contexte courant ne peut plus être ajouté à une commande commerciale.

Le comportement général de la synchronisation reste inchangé : en présence d'au moins un avertissement bloquant, aucune modification n'est appliquée à la commande et l'ensemble des avertissements est retourné.

Impact API

PUT /v1/shop/commercial-orders/{commercialOrderId}/sync (operationId : ORDER-223)
Nouveau code d'avertissement bloquant : F-W-015
Référence complète des codes : Error / Warning codes

📄 Documentation :

👉 Côté métier : les commandes commerciales sont désormais contrôlées sur la visibilité catalogue, garantissant qu'aucun produit inéligible ne persiste dans le panier ou la commande après synchronisation.

👉 Côté technique : nouveau warning bloquant F-W-015 sur la route de synchronisation et vérification d'éligibilité catalog view ajoutée à l'ajout au panier.

Filtrage par supplier sur les jobs d'export

Contexte

L'endpoint de listing des jobs d'export ne permettait pas de distinguer ni de filtrer les jobs par supplier. Les opérateurs devaient parcourir l'ensemble de la liste pour retrouver les jobs liés à un supplier spécifique.

Fonctionnement

Un nouveau query parameter supplierIds permet de filtrer les jobs d'export par supplier.
Lorsque supplierIds est renseigné, seuls les jobs configurés avec au moins un des suppliers indiqués sont retournés.
Les jobs sans supplier configuré (export global) ne sont pas inclus lors d'un filtrage par supplier.
Sans le paramètre supplierIds, tous les jobs sont retournés (comportement inchangé).
La réponse inclut désormais les informations supplier (ID + nom) pour chaque job.

Impact API

GET /v1/mapper/jobout
Nouveau query parameter : supplierIds (type List<String>, optionnel) — ex. ?supplierIds=SUP1,SUP2
Réponse enrichie : chaque job retourne la liste des suppliers associés (ID + nom)
Rétrocompatibilité totale : sans le paramètre, le comportement reste identique.

📄 Documentation :

👉 Côté métier : retrouvez instantanément les jobs d'export liés à un supplier spécifique, sans parcourir l'ensemble de la liste.

👉 Côté technique : nouveau paramètre de filtre supplierIds et informations supplier ajoutées dans la réponse de GET /v1/mapper/jobout.