Release Notes — DJUST 3.122

Integration

Back-Office

Recherchez une exécution de job par son ID directement depuis l'historique

Un champ de recherche est désormais disponible sur les écrans d'historique des jobs d'import, d'indexation et d'export. Saisissez un ID d'exécution (complet ou partiel) pour retrouver instantanément l'exécution correspondante, sans parcourir manuellement les pages de résultats. Idéal pour retrouver rapidement une exécution à partir d'un ID communiqué par le support ou un collègue.

API

📘
UPDATE

Orders — Import

Mettez à jour les Custom Fields de vos commandes directement via l'import Data Hub

Contexte

Jusqu'à présent, l'enrichissement des Custom Fields portés par une commande et ses lignes n'était pas accessible librement via l'import : l'avancement logistique de la commande pouvait bloquer la mise à jour de ses métadonnées métier. Il est désormais possible de créer ou de modifier les valeurs des Custom Fields sur une Order Logistic et ses Order Lines via l'import, quel que soit le statut de la commande.

Fonctionnement

Création ou mise à jour des valeurs des Custom Fields sur une Order Logistic et ses Order Lines.
Disponible via le job d'import SFTP (ORDER_CSV_JOB) et via le Connecteur API (ORDER_API_JOB).
Fonctionne indépendamment du statut de la commande — y compris SHIPPED, DELIVERED ou CANCELED.

Impact API

Jobs : ORDER_CSV_JOB (import SFTP), ORDER_API_JOB (Connecteur API)
Périmètre : Custom Fields sur Order Logistic et Order Lines
Rétrocompatibilité : aucun impact sur les imports de commandes existants

Bénéfices

👉 Côté métier : Enrichissez ou corrigez les métadonnées métier (facture, tracking, code interne…) tout au long du cycle de vie d'une commande, sans être bloqué par son avancement logistique.
👉 Côté technique : Mise à jour des Custom Fields d'Order via les pipelines d'import existants, sans contrainte de statut.

Catalog

Back-Office

Comprenez en un coup d'œil pourquoi un produit, un variant ou une offre est hors ligne

Le statut de visibilité search (En ligne / Hors ligne) est désormais affiché sur les listes et les pages détail des produits, variants et offres. Sur la page détail d'une entité hors ligne, les raisons précises (prix manquant, offre inactive, stock à zéro, catégorie de navigation absente…) s'affichent avec le mode d'indexation, pour diagnostiquer en self-service sans ouvrir de ticket support. L'affichage est activé pour les clients en Search V2.

API

📘
NEW

Products / Variants / Offers — Search

Diagnostiquez en un appel pourquoi un produit, un variant ou une offre n'apparaît pas en ligne

Contexte

Jusqu'à présent, le statut de visibilité search se limitait à un booléen online, sans aucune explication : impossible de savoir si une entité était hors ligne à cause d'un prix manquant, d'un stock à zéro, d'une offre inactive ou d'une catégorie de navigation absente. Trois nouveaux endpoints exposent désormais, pour une entité donnée, son statut online/offline et la liste des raisons précises de mise hors ligne, en cohérence avec le mode d'indexation de la dernière indexation.

Fonctionnement

Trois endpoints unitaires (un par type d'entité) : produit, variant, offre.
L'entité est identifiée par son id en path, interprété selon le paramètre idType (DJUST_ID par défaut ou EXTERNAL_ID).
La réponse retourne id, externalId, online, indexationMode et offlineReasons[] (codes raison).
Les raisons remontées dépendent du mode d'indexation de la dernière indexation (ex : pas de raison liée au stock si ce mode ne vérifiait pas le stock).
Une réponse 404 est retournée si l'entité n'existe pas.

Impact API

Endpoints :
GET /v1/products/{productId}/search-status
GET /v1/product-variants/{productVariantId}/search-status
GET /v1/offer-inventories/{offerInventoryId}/search-status
Paramètre : idType (enum DJUST_ID / EXTERNAL_ID, défaut DJUST_ID)
Réponse : { id, externalId, online, indexationMode, offlineReasons[] } ; 404 si entité introuvable
Accès : opérateurs Back Office (dj-client: OPERATOR)
Rétrocompatibilité : nouveaux endpoints, aucun impact sur les APIs catalogue existantes

Bénéfices

👉 Côté métier : Diagnostiquez en autonomie pourquoi une entité est hors ligne, sans ouvrir de ticket support.
👉 Côté technique : Trois endpoints de diagnostic dédiés, sans impact sur l'existant, consommables par le Back Office et le monitoring.

OMS

API

📘
NEW

Shipping — Shipping zones

Consultez vos zones de livraison et gérez les pays/départements qui les composent via l'API

Contexte

Le module de livraison ne disposait pas d'API pour consulter les shipping zones et leur composition géographique. De nouveaux endpoints permettent désormais de lister les zones, d'en récupérer le détail et de retirer des pays/départements d'une zone.

Fonctionnement

Listing paginé et filtrable des shipping zones : filtres name (recherche partielle, insensible à la casse), createdAtFrom/createdAtTo, updatedAtFrom/updatedAtTo (combinés en logique AND), tri sur name/createdAt/updatedAt (défaut createdAt:desc), pagination page/size.
Détail d'une zone par son ID fonctionnel : id, name, description, locationsCount, createdAt, updatedAt.
Retrait de pays/départements d'une zone via une liste de locations (country ou department avec countryCode/departmentCode).

Impact API

Endpoints :
GET /v1/shipping-zones — liste paginée et filtrable
GET /v1/shipping-zones/{id} — détail d'une zone (404 si zone non trouvée)
DELETE /v1/shipping-zones/{shippingZoneId}/locations — retrait de locations (204 No Content ; 400 F-E-012 si location invalide ; 404 si zone non trouvée)
Accès : opérateurs (dj-client: OPERATOR)
Rétrocompatibilité : nouveaux endpoints, aucun impact sur l'existant

Bénéfices

👉 Côté métier : Visualisez et ajustez la composition géographique de vos zones de livraison.
👉 Côté technique : Endpoints de consultation et de gestion des locations des shipping zones, filtrables et paginés.

📘
UPDATE

Shipping — Famille logistique des classifications

Identifiez directement la famille logistique d'une classification, sans appel inverse

Contexte

Les APIs admin de listing et de détail des catégories de classification ne retournaient pas la famille logistique rattachée à chaque catégorie, et il n'existait pas de moyen de récupérer en masse la famille de plusieurs classifications. Ces APIs sont désormais enrichies, et un nouvel endpoint permet de résoudre en un seul appel la famille logistique de plusieurs classifications.

Fonctionnement

Les endpoints GET /v1/classification-categories (liste) et GET /v1/classification-categories/{id} (détail) retournent désormais logisticFamilyId et logisticFamilyName.
La famille retournée est la famille résolue : rattachement explicite si présent, sinon la famille « Par défaut ».
Ces champs sont toujours retournés, que le module shipping soit activé ou non.
Read-only : ces endpoints ne permettent pas de modifier la famille logistique.
Un nouvel endpoint de lecture résout en masse la famille logistique d'un ensemble de classifications, identifiées par leur externalId. La réponse retourne, pour chaque classification, sa famille (id, name, system). Une classification connue ressort toujours avec une famille (jamais null) ; un id inconnu est omis silencieusement ; une entrée vide retourne une liste vide.

Impact API

Endpoints enrichis : GET /v1/classification-categories, GET /v1/classification-categories/{id} — ajout des champs logisticFamilyId (string, UUID) et logisticFamilyName (string)
Nouvel endpoint : GET /v1/logistic-families/assignments?classificationCategoryIds=… — résolution en masse de la famille logistique
Accès : opérateurs (dj-client: OPERATOR) ; le nouvel endpoint requiert la permission LOGISTIC_FAMILY_READ et le module shipping activé
Rétrocompatibilité : champs ajoutés et nouvel endpoint, aucun impact sur l'existant

Bénéfices

👉 Côté métier : Affichez la famille logistique d'une classification directement depuis le Back-Office et anticipez les rattachements déjà existants.
👉 Côté technique : Lecture de la famille logistique des classifications sans appel inverse, en unitaire ou en masse, sans couplage supplémentaire.