Djust 3.138.0 - Semaine du 19 Octobre 2026
Périmètre
🖥️ Back-Office
NEW
Séquencement des imports
Contexte
Un import démarrait à l'heure dite. Pour enchaîner deux imports dépendants — un référentiel puis les offres qui s'y rattachent — il fallait décaler les horloges en estimant la durée du premier. Le réglage était silencieux dans les deux sens : si l'import amont débordait, l'aval partait sur des données incomplètes sans que personne ne s'en aperçoive ; s'il était rapide, la marge était perdue.
Fonctionnement
Le déclenchement d'un import se règle désormais selon trois modes exclusifs : à heure fixe, à la fin de l'exécution d'un autre import, ou manuel. Un import porte soit une planification, soit un déclencheur, jamais les deux : basculer d'un mode à l'autre retire la configuration du mode quitté, après confirmation.
Un déclencheur désigne un import amont et au moins un statut de fin parmi « Terminé », « Terminé avec avertissements », « Rien à traiter » et « Terminé avec erreurs », les quatre retenus par défaut. Un import qui échoue, est arrêté ou abandonné ne déclenche rien. Un import inactif n'est jamais réveillé par un déclencheur : la chaîne s'arrête à lui et reprend dès sa réactivation.
Un import peut en déclencher plusieurs, sans ordre imposé entre eux, et la longueur de la chaîne n'est pas limitée. Les cycles sont refusés quelle que soit leur profondeur. Si l'import amont est supprimé, les imports qu'il déclenchait repassent en mode manuel.
La chaîne se lit dans les deux sens : la page d'un import liste les imports qu'il déclenche, et son historique indique, pour chaque exécution, le mode qui l'a lancée ainsi que l'exécution déclencheuse.
Périmètre : imports de type fichier, imports SFTP et imports API. Les exports ne sont pas concernés. Les imports déjà planifiés conservent leur planification et leur comportement.
📄 Documentation : Job Configuration - Overview
👉 Côté métier : les imports dépendants s'enchaînent sans horloges décalées, et l'on sait après coup quelle exécution en a lancé une autre.
👉 Côté technique : un import porte un scheduler ou un déclencheur, jamais les deux ; chaque exécution déclenchée conserve l'identifiant de l'exécution qui l'a déclenchée, restitué à la lecture des exécutions.
Import d'un fichier depuis la page d'une entité
Contexte
Charger un fichier CSV sur une entité imposait de quitter son écran de travail et de configurer un import complet dans le Data Hub, avec son vocabulaire propre. Un opérateur qui corrige son catalogue ou ses comptes n'a pas à connaître le Data Hub pour y arriver.
Fonctionnement
Un bouton Importer figure à côté d'Exporter sur douze pages liste : commandes, produits, tags produit, catégories de classification, catégories de navigation, comptes, utilisateurs client, assortiments, attributs, offres, stores et fournisseurs. Déposez votre fichier CSV, associez ses colonnes aux champs DJUST, lancez l'import : tout se fait sans quitter la page.
Le fichier est accepté au format CSV jusqu'à 10 Mo. Son délimiteur est détecté automatiquement et reste modifiable, et un aperçu des premières lignes confirme le découpage avant d'aller plus loin. L'option « Inclure les valeurs vides », désactivée par défaut, détermine si les cellules vides écrasent les valeurs existantes.
Deux points de départ pour le mapping : un nouveau mapping, ou le mapping d'un import existant de la même entité. Dans ce second cas, les en-têtes correspondant exactement sont repris, les champs laissés non couverts sont signalés, et le lancement met à jour cet import sans le dupliquer ni le renommer. Les colonnes préfixées ATTR_ et CF_ sont associées automatiquement et affichent le nom de l'attribut ou du champ personnalisé correspondant. Une colonne non associée est simplement ignorée, et un champ requis non couvert bloque le lancement.
Un import dont une exécution est en cours n'est pas sélectionnable comme mapping. L'import lancé est asynchrone : une confirmation s'affiche avec un accès direct à son historique d'exécution, où le suivi se poursuit comme pour n'importe quel import du Data Hub.
📄 Documentation : Job Configuration - Import - File
👉 Côté métier : un fichier s'importe depuis la page de l'entité concernée, en réutilisant un mapping déjà défini plutôt qu'en reconfigurant un import à chaque fois.
👉 Côté technique : les imports créés ou mis à jour par ce parcours sont des imports de type fichier standard, visibles dans la liste des imports du Data Hub et dotés du monitoring et de l'historique habituels.
Suppression d'un document de commande
Contexte
Un document rattaché à une commande ne pouvait être retiré que par appel API. Un document déposé par erreur restait donc visible tant qu'une intervention technique n'avait pas été demandée.
Fonctionnement
Un document rattaché à une commande se supprime désormais depuis le Back-Office, sans passer par l'API. Les autres documents de la commande et la commande elle-même ne sont pas affectés.
👉 Côté métier : un document déposé par erreur se retire directement depuis la commande, sans demande d'intervention.
👉 Côté technique : la suppression d'un document de commande, jusqu'ici réservée à l'API, est exposée dans le Back-Office.
UPDATE
Liste des imports : pagination serveur, recherche et filtres
Contexte
La liste des imports chargeait tous les imports du tenant à chaque rafraîchissement, puis triait, filtrait et cherchait dans le navigateur. Sur un tenant qui porte plusieurs centaines d'imports, l'écran devenait lent, et la recherche ne portait que sur le nom de l'import ou celui de son client.
Fonctionnement
La liste est désormais paginée côté serveur : seules les lignes affichées sont chargées, et les onglets « En cours », « Actifs » et « Inactifs » n'en chargent chacun que leur propre contenu. La recherche par nom d'import ou nom de client, la pagination et le tri par date de création ou par nom sont traités côté serveur, de même que le rafraîchissement, qui ne recharge que la page affichée et les compteurs d'onglets.
Deux filtres s'ajoutent à la barre d'outils :
- Objet — l'entité importée, par exemple les produits, les offres ou les commandes.
- Type de connecteur — API, FTP, SFTP, Mirakl, interne ou fichier.
Les deux se combinent entre eux, avec la recherche et avec l'onglet affiché. Les filtres actifs apparaissent en tags supprimables, se conservent dans l'URL — donc après un rafraîchissement ou un retour depuis la fiche d'un import — et les compteurs d'onglets les reflètent. Changer un filtre revient en première page et vide la sélection en cours, pour qu'une action en masse ne porte jamais sur un import qui n'est plus affiché.
L'indexation du catalogue reste exclue de cette liste, comme auparavant.
📄 Documentation : Job Configuration - Overview
👉 Côté métier : la liste des imports s'ouvre et se rafraîchit sans attente, et un parc de plusieurs centaines d'imports se restreint en deux clics à une entité ou à une source donnée.
👉 Côté technique : la liste s'appuie sur GET /v2/mapper/jobs (operationId : ADM-JOB-552), avec pagination, recherche et filtres genericJobType et clientConfigurationType traités côté serveur.
Liste des comptes clients : filtres sur les dates
Contexte
La liste des comptes clients se filtrait sur les comptes, les tags client et le statut, mais sur aucune date. Retrouver les comptes créés le mois dernier, ou ceux modifiés depuis une date donnée, imposait un export et un retraitement.
Fonctionnement
Deux filtres s'ajoutent à la liste des comptes clients : Date de création et Date de mise à jour. Ils reprennent la présentation, les libellés et le comportement des filtres de date des autres listes du Back-Office, notamment celle des commandes : même façon de choisir une période, mêmes règles sur les bornes.
Ils se combinent entre eux et avec les filtres existants, et s'affichent comme eux une fois appliqués. Les cartes d'indicateurs en haut de la liste ne sont pas affectées, comme pour les autres filtres. Sans ces filtres, la liste se comporte exactement comme avant.
📄 Documentation : Customers
👉 Côté métier : les comptes se segmentent sur leur date de création ou de dernière modification, directement depuis la liste.
👉 Côté technique : deux critères de date facultatifs s'ajoutent à la recherche des comptes clients, bornes incluses, combinables avec les critères existants.
Quotas par fournisseur : recherche, filtres et noms
Contexte
L'onglet des quotas par fournisseur n'affichait que l'identifiant de la règle, la valeur du quota et les identifiants externes du compte client et du fournisseur. Sans recherche ni filtre, vérifier ou corriger le quota d'un client précis revenait à faire défiler les pages en comparant des identifiants techniques.
Fonctionnement
Une barre de recherche permet de retrouver une règle par le nom ou l'identifiant externe d'un compte client ou d'un fournisseur, ainsi que par l'identifiant de la règle. La recherche est insensible à la casse et aux accents.
Deux filtres multi-sélection, Comptes clients et Fournisseurs, restreignent la liste ; plusieurs valeurs d'un même filtre s'additionnent, les deux filtres se combinent, et chaque valeur active apparaît en tag supprimable.
Les colonnes du compte client et du fournisseur affichent désormais leur nom en information principale et leur identifiant externe en secondaire. Un compte ou un fournisseur supprimé reste affiché par son seul identifiant externe.
La sélection multiple, la suppression groupée, l'édition et la création d'une règle sont inchangées. Toute modification de la recherche ou des filtres ramène en première page.
Impact API
GET /v1/buying-policies/quotas/rules (operationId : ADM-BUYING-POLICY-553)
Nouveau paramètre search : recherche « contient », insensible à la casse et aux accents, sur l'identifiant de la règle, le nom et l'identifiant externe du compte client et du fournisseur. Il se combine en ET avec les filtres customerAccountIds et supplierIds, inchangés.
Nouveaux champs customerAccountName et supplierName dans la réponse, à null lorsque la ressource référencée n'existe plus. Un appel sans ces paramètres renvoie le même contenu, le même ordre et les mêmes champs qu'auparavant.
📄 Documentation : Quotas Rules — Per Account & Supplier
👉 Côté métier : la règle d'un client ou d'un fournisseur se retrouve en une saisie, et le tableau se lit en noms plutôt qu'en identifiants.
👉 Côté technique : paramètre search et champs customerAccountName / supplierName ajoutés à la liste des quota rules, sans nouvel endpoint ni appel complémentaire.
Liens de commande reçus par email sur un tenant multi-store
Contexte
Sur un tenant multi-store, ouvrir le lien d'une commande reçu par email alors que le Back-Office était positionné sur un autre store affichait une page introuvable. L'opérateur devait identifier le bon store, le sélectionner, puis retrouver la commande à la main.
Fonctionnement
Les liens vers le Back-Office générés par la plateforme — emails de nouvelle commande, de nouvelle discussion, d'approbation et de devis fournisseur — portent désormais le store de la ressource concernée. Le store transporté est celui de la commande, et non celui du contexte d'envoi : un email parti d'un import pointe donc sur le bon store.
À l'ouverture d'un tel lien, le Back-Office bascule sur le store de la ressource sans déconnexion et charge la page demandée. La bascule est annoncée par un bandeau : elle n'est jamais silencieuse. Le store courant reste propre à chaque onglet, donc une bascule dans un onglet ne change pas le contexte des autres.
Si le store n'est pas accessible à l'opérateur, aucune bascule n'a lieu et le comportement actuel est conservé. Les tenants mono-store et les liens déjà envoyés au format précédent ne changent pas de comportement.
👉 Côté métier : un lien de commande reçu par email s'ouvre sur la bonne commande du premier coup, quel que soit le store sur lequel le Back-Office était positionné.
👉 Côté technique : les liens Back-Office générés par la plateforme portent l'identifiant externe du store de la ressource en paramètre de requête, lu à l'ouverture de la page pour aligner le contexte de store.
🛠️ API
NEW
Frais de livraison par devise
🚧 API uniquement pour le moment. L'interface Back-Office associée arrivera dans une prochaine version.
Contexte
Une ligne de la matrice de frais de livraison portait un prix et un franco de port sans devise, implicitement en euros. Un tenant qui vend en plusieurs devises ne pouvait donc pas définir de frais de livraison en livres ou en francs suisses, ni les facturer dans la devise de la commande.
Fonctionnement
Chaque ligne de la matrice porte désormais une devise, qui s'applique à son prix de livraison, à son franco de port et aux seuils de montant de ses tranches. La devise fait partie de l'unicité d'une ligne : une même combinaison famille logistique × zone × type de livraison × fournisseur peut exister une fois par devise, avec des montants différents. Deux lignes identiques dans la même devise restent refusées comme doublon, et le mode de tarification — prix fixe ou tranches — se choisit par devise.
Au checkout, la ligne appliquée est celle dont la devise est la devise de la commande, sans aucune conversion, et le franco de port se compare au montant de la commande dans cette même devise. S'il n'existe aucune ligne dans la devise de la commande, la ligne par défaut de cette devise s'applique si elle existe ; sinon le checkout est bloqué comme auparavant. Il n'y a jamais de repli sur une ligne dans une autre devise.
Rétrocompatibilité assurée : une ligne enregistrée sans devise est en euros, et un tenant mono-devise en euros ne constate aucune différence — mêmes lignes, mêmes frais, même franco.
Impact API
POST /v1/shipping-prices (operationId : ADM-SHIPPING-PRICE-150) et PUT /v1/shipping-prices (operationId : ADM-SHIPPING-PRICE-250)
Nouveau champ currency sur chaque ligne : code ISO 4217 parmi les devises de la plateforme, insensible à la casse, EUR lorsqu'il est omis ou nul. Une devise inconnue est refusée en 400 (F-E-012) ; une combinaison de dimensions déjà existante, devise comprise, est refusée en 409 (F-E-003).
GET /v1/shipping-prices (operationId : ADM-SHIPPING-PRICE-550) — nouveau filtre currencies, liste de codes ISO 4217 séparés par des virgules.
Référence complète des codes : Error / Warnings codes
📄 Documentation : Shipping Rates configuration
👉 Côté métier : les frais de livraison se définissent dans chacune des devises de vente et sont facturés dans la devise de la commande, sans conversion.
👉 Côté technique : champ currency sur les lignes de frais de livraison, devise intégrée à la clé d'unicité, filtre currencies sur la liste, et EUR par défaut pour les lignes existantes.
UPDATE
Liste des commandes logistiques : filtre sur la date de validation
🚧 API uniquement pour le moment. L'interface Back-Office associée arrivera dans une prochaine version.
Contexte
La recherche de commandes logistiques se filtrait sur la date de création et sur la date de mise à jour, mais pas sur la date de validation. Or les indicateurs de commandes sont datés par la date de validation : sur une même période, la liste ne retrouvait pas les commandes que comptaient les indicateurs.
Fonctionnement
Deux critères facultatifs s'ajoutent à la recherche : une borne de début et une borne de fin sur la date de validation, bornes incluses. Combinés au filtre de statut, qui accepte déjà plusieurs statuts, ils renvoient exactement les commandes comptées par les indicateurs sur la même période.
Les commandes provisoires, qui n'ont pas de date de validation, ne sont jamais renvoyées par ce filtre. Les commandes validées avant la mise en place de l'historisation de cette date sont retrouvées par leur date de création, afin qu'une période ancienne reste cohérente avec les indicateurs.
Les mêmes critères s'appliquent à l'export CSV des commandes : un export suit la liste filtrée. Le filtre vaut également pour le back-office fournisseur, restreint comme aujourd'hui à ses propres commandes. Aucun paramètre existant n'est modifié : sans ces nouveaux critères, la liste et l'export se comportent exactement comme avant.
Impact API
POST /v1/logistic-orders et POST /v1/logistic-orders/export
Nouveaux critères validationDateFrom et validationDateTo, facultatifs, au format instant, bornes incluses, sur le modèle des critères de date existants.
📄 Documentation : Search, Filter & Sort Logistic Orders
👉 Côté métier : une période de validation donne la même liste de commandes que les indicateurs sur cette même période, à l'écran comme à l'export.
👉 Côté technique : deux critères de date de validation ajoutés à la recherche et à l'export des commandes logistiques, sans modification des critères existants.
IMPORTANT UPDATE
Mise à jour des lignes d'une commande commerciale : stock et conditionnement distingués
Contexte
Lorsqu'aucune ligne ne pouvait être appliquée, la mise à jour et la synchronisation des lignes d'une commande commerciale renvoyaient toujours 400 OR0034. Deux causes très fréquentes — une quantité supérieure au stock disponible et une quantité qui n'est pas un multiple du conditionnement de l'offre — ne se distinguaient qu'en analysant le texte libre du detail.
Fonctionnement
Le code d'erreur distingue désormais ces deux causes lorsqu'elles expliquent à elles seules le rejet de toutes les lignes :
OR0038— aucune ligne appliquée, chaque avertissement bloquant porte sur le stock disponible (F_W_022).OR0039— aucune ligne appliquée, chaque avertissement bloquant porte sur le conditionnement de l'offre (F_W_020).OR0034— tout autre cas : causes mélangées, autre motif, ou liste de lignes vide. Inchangé.
Le champ detail conserve son format actuel dans les trois cas, et le comportement général reste identique : lorsque aucune ligne ne survit à la validation, rien n'est écrit.
Action requise : une intégration qui teste aujourd'hui OR0034 pour détecter un problème de stock ou de conditionnement doit désormais traiter OR0038 et OR0039.
Impact API
PUT /v2/shop/commercial-orders/{commercialOrderId}/lines (operationId : ORDER-150)
PUT /v1/shop/commercial-orders/{commercialOrderId}/sync (operationId : ORDER-223)
Deux nouveaux codes d'erreur en 400 : OR0038 et OR0039. Référence complète des codes : Error / Warnings codes
📄 Documentation :
👉 Côté métier : un rejet pour stock insuffisant se distingue d'un rejet pour conditionnement, ce qui permet d'afficher le bon message à l'acheteur.
👉 Côté technique : nouveaux codes OR0038 (stock) et OR0039 (conditionnement) sur la mise à jour et la synchronisation des lignes d'une commande commerciale ; OR0034 subsiste pour les causes mixtes ou autres.