Périmètre

🖥️ Back-Office

Paramétrage de la recherche en autonomie (modes & boost)

Contexte

Jusqu'ici, la configuration de la recherche (mode de matching et pondération par champ) ne pouvait être ajustée que par l'équipe DJUST — un point de blocage pour les clients. Le Back-Office expose désormais ce paramétrage.

Fonctionnement

Un nouvel écran permet de lister les champs recherchables et de modifier leur configuration :

• Mode de matching par champ (searchType)
• Pondération par champ (score), borné dans l'interface pour éviter les valeurs extrêmes
• Activation de la recherche par champ (searchable)

Les modes proposés sur les champs de recherche libre sont restreints aux modes sûrs (EXACT, PREFIX) afin de préserver les performances du moteur de recherche ; les modes coûteux sont masqués ou signalés par un avertissement explicite.

Deux points sont indiqués à l'utilisateur : la modification prend effet sous ~5 min et aucune réindexation n'est nécessaire — le changement n'agit qu'au moment de la requête.

Impact API

Lecture via GET /v2/settings, écriture via PUT /v2/settings. Une validation serveur complémentaire encadre la valeur de boost.

📄 Documentation : Search Configuration

👉 Côté métier : les clients configurent eux-mêmes les modes de recherche et la pertinence par champ depuis le Back-Office, sans intervention de l'équipe et avec une prise d'effet quasi immédiate.

👉 Côté technique : exposition des endpoints de settings de recherche (GET/PUT /v2/settings) dans le Back-Office, avec restriction des modes et bornage du boost pour protéger le cluster mutualisé.

Suppression manuelle d'un utilisateur FOC

Contexte

Dans le cadre de la mise en cohérence des actions disponibles par import et manuellement dans le Back-Office, un écart avait été identifié : la suppression d'un utilisateur front (FOC) était possible via un job d'import mais pas manuellement. Les opérateurs devaient donc passer par un import pour supprimer un utilisateur à l'unité.

Fonctionnement

La suppression d'un utilisateur FOC est désormais possible directement depuis le Back-Office, de façon cohérente avec ce que permet déjà l'import. L'opérateur peut supprimer un utilisateur à l'unité sans recourir à un job d'import.

👉 Côté métier : suppression d'un utilisateur front à l'unité directement dans le Back-Office, plus rapide et moins risquée que le passage par un import.

👉 Côté technique : parité import ↔ Back-Office rétablie sur la suppression d'utilisateur FOC.

🛠️ API

Attribution d'un externalId sur les lignes de commande logistique

Contexte

Les opérateurs ont besoin de retrouver une ligne de commande logistique à partir de leur propre référence. La route de mise à jour en masse des lignes accepte désormais un externalId par ligne, en complément des valeurs de champs personnalisés.

Fonctionnement

La mise à jour est traitée ligne par ligne (succès partiel) : les lignes valides sont mises à jour, les lignes en échec sont ignorées et remontées dans le tableau warnings de la réponse. L'externalId doit être unique (toutes lignes de commande logistique confondues) ; une ligne portant un externalId déjà utilisé est ignorée et signalée par le warning F_W_040, les autres lignes valides restant mises à jour. Définir un externalId sur une ligne qui en porte déjà un écrase la valeur existante.

Impact API

PATCH /v1/shop/logistic-orders/{logisticOrderId}/lines (operationId : ORDER-251)

• Nouveau champ optionnel externalId par ligne (caractères non réservés RFC 3986 : lettres, chiffres, -, ., _, ~)
• Chaque entrée doit contenir au moins customFieldValues ou externalId
• Réponse 200 avec tableau warnings (succès partiel) ; warning F_W_040 sur externalId déjà existant
• dj-client : OPERATOR, ACCOUNT ou SUPPLIER
• Référence des codes : Error / Warning codes

👉 Côté métier : les opérateurs retrouvent une ligne de commande via leur propre référence, avec une mise à jour en masse tolérante aux erreurs (les lignes valides passent, les échecs sont reportés).

👉 Côté technique : champ externalId optionnel ajouté au bulk update des lignes (ORDER-251), unicité tenant contrôlée avec warning F_W_040.

Préservation du shipping négocié sur les commandes issues d'une quote

Contexte

Avec le module shipping, la matrice de prix s'applique automatiquement au checkout pour calculer les frais de livraison des commandes logistiques. En parallèle, le flux quote permet au supplier de saisir manuellement le shipping au niveau de chaque ligne — reflet de la négociation supplier ↔ customer. Lorsqu'une quote est convertie en commande, ce shipping négocié devait être préservé plutôt qu'écrasé par la matrice.

Fonctionnement

La résolution du shipping distingue désormais l'origine de la commande :

• Commande directe (checkout classique, panier puis validation) → la matrice s'applique, comportement inchangé.
• Commande issue d'une quote (conversion quote → commande) → les valeurs de shipping saisies sur les lignes de la quote (shippingPrice, shippingTaxAmount, shippingTaxRate) sont recopiées telles quelles ; la matrice n'est pas appliquée.

Le franco de la matrice ne s'applique pas aux commandes issues d'une quote (le shipping négocié par le supplier prime, y compris les éventuels 0 € négociés), et les avertissements de synchronisation shipping ne remontent pas sur ces commandes. Aucune régression sur les commandes directes.

Impact API

Comportement pris en compte lors de la résolution du shipping : récupération du panier, PUT shipping-information (ORDER-215) et validation (ORDER-207).

📄 Documentation : Start From A Source Operation Or Quote

👉 Côté métier : le shipping négocié sur une quote est garanti sur la commande qui en découle, sans être écrasé par la matrice de prix.

👉 Côté technique : la résolution du shipping intègre un contrôle d'origine de la commande ; matrice et franco désactivés pour les commandes dérivées d'une quote, comportement des commandes directes inchangé.

Dépréciation du search type EXACT_MATCH sur les champs de recherche libre

Contexte

Sur les champs de recherche libre, le search type EXACT_MATCH fait doublon avec EXACT et sa sémantique y est trompeuse : sensible à la casse et permissif en multi-mot, il produit des résultats contre-intuitifs.

Fonctionnement

EXACT_MATCH n'est plus assignable via l'API de settings sur les champs de recherche libre : une tentative d'attribution est rejetée. Pour un « exact » sur du texte, utiliser EXACT (match_phrase, insensible à la casse). Le search type reste disponible en interne sur les champs non modifiables par l'utilisateur, où sa sémantique est correcte.

Impact API

PUT /v2/settings — l'attribution de EXACT_MATCH sur un champ de recherche libre est désormais refusée. Utiliser EXACT en remplacement.

👉 Côté métier : un mode de recherche trompeur est retiré des options configurables, au profit d'un comportement « exact » cohérent sur les champs texte.

👉 Côté technique : EXACT_MATCH retiré des search types assignables sur les champs de recherche libre via PUT /v2/settings ; conservé en interne sur les champs non exposés. Aucune migration requise.