Périmètre

🖥️ Back-Office

Gestion des incidents depuis la fiche d'une commande

Contexte

Le Back-Office signalait qu'une commande portait un incident par un pictogramme d'alerte, sans rien en dire de plus : ni le motif, ni l'état d'avancement, ni le message écrit par le client. Les incidents déclarés depuis le site marchand restaient donc sans réponse, faute d'écran pour les lire.

Fonctionnement

Un onglet Incidents apparaît sur la fiche d'une commande dès qu'elle porte au moins un incident, avec le nombre total en compteur.

Les incidents portant sur la commande entière et ceux portant sur des lignes sont présentés séparément. Chaque incident occupe une carte qui porte son numéro, son statut, ses motifs et sa date de déclaration. Pour un incident sur lignes, la carte liste les lignes concernées avec le produit, la quantité concernée et le statut de traitement de chaque ligne.

Trois statuts sont disponibles : Ouvert, En cours et Clos. L'incident a son statut, chaque ligne d'incident a le sien, et les deux restent indépendants : clore un incident ne clôt pas ses lignes, et clore toutes les lignes ne clôt pas l'incident. Rien n'est mis à jour automatiquement, de façon à garder la main et à pouvoir revenir en arrière. Lorsqu'un écart apparaît entre le statut d'un incident et celui de ses lignes, un bandeau le signale sans rien corriger.

Quand l'incident a une discussion, elle s'ouvre depuis la carte : les messages y sont affichés avec leur auteur et leur date, et une zone de saisie permet de répondre au client. La discussion appartient à l'incident, pas à ses lignes : un incident portant sur plusieurs lignes n'a qu'un seul fil.

👉 Côté métier : les incidents déclarés par les clients se consultent et se traitent enfin depuis la commande, avec une réponse possible dans le fil et un suivi de l'avancement par statut.

👉 Côté technique : l'onglet n'est présent que sur les commandes portant un incident ; les statuts d'incident et de ligne sont portés indépendamment et ne se propagent pas.

Filtre par statut d'incident dans la liste des commandes

Contexte

La liste des commandes ne proposait qu'un filtre binaire « Avec incident » / « Sans incident » : on savait qu'il s'était passé quelque chose, jamais où cela en était.

Fonctionnement

Un filtre Statut d'incident s'ajoute au panneau de filtres de la liste des commandes. Il propose les trois valeurs Ouvert, En cours et Clos, en sélection multiple, et se combine avec les autres filtres.

Une commande remonte dès qu'un seul de ses incidents porte l'un des statuts sélectionnés : une commande ayant un incident clos et un incident ouvert apparaît aussi bien sur « Clos » que sur « Ouvert ».

Le filtre porte sur le statut de l'incident, pas sur celui de ses lignes. Un incident ouvert dont toutes les lignes sont closes remonte sur « Ouvert ».

Libellés et couleurs sont identiques à ceux de l'onglet Incidents : un statut garde la même apparence entre la liste et la fiche.

👉 Côté métier : les équipes retrouvent en un filtre les commandes dont l'incident est encore ouvert ou en cours, et suivent leur charge de traitement depuis la liste.

👉 Côté technique : filtre à valeurs multiples, combinable avec les filtres existants de la liste des commandes.

Modification de l'adresse email d'un customer user

Contexte

Sur la fiche d'un customer user, le Back-Office n'affichait pas l'adresse email : seuls la civilité, le prénom, le nom, le téléphone et les groupes y figuraient. Une erreur de saisie à la création ne pouvait donc se corriger qu'en supprimant l'utilisateur puis en le recréant — au prix de ses rattachements, et sans même cette issue lorsqu'il avait déjà un devis ou un avis, la suppression étant alors refusée.

Fonctionnement

L'adresse email figure désormais dans la carte d'informations de la fiche et se modifie comme les autres champs. Un opérateur sans droit de modification sur les utilisateurs la voit en lecture seule.

Le format est vérifié dans le formulaire, comme à la création, et le champ ne peut pas être vidé : l'email sert d'identifiant de connexion.

Une fois la modification enregistrée, l'utilisateur se connecte au front office avec sa nouvelle adresse ; l'ancienne est refusée. Son mot de passe reste inchangé.

Trois refus sont possibles, chacun avec son message et sans perte de la saisie :

• l'adresse est déjà utilisée par un autre utilisateur ;
• le compte est partagé avec un opérateur — changer l'email modifierait aussi l'identifiant de connexion de l'opérateur, le changement est donc refusé ;
• le format est invalide.

👉 Côté métier : une erreur d'adresse à la création se corrige depuis la fiche, sans supprimer ni recréer l'utilisateur et sans lui faire perdre ses rattachements.

👉 Côté technique : aucun changement de contrat — l'écran s'appuie sur la mise à jour d'un customer user déjà exposée par l'API.

🔗 Data Hub

Adresses de livraison et de facturation à l'import ORDER

Contexte

À l'import ORDER, seule l'adresse de livraison pouvait être renseignée champ par champ. L'adresse de facturation d'une commande externe était toujours la première adresse de facturation du compte client : pour un compte en portant plusieurs, ou pour une commande facturée à une adresse ponctuelle, la commande arrivait avec une adresse erronée, à corriger manuellement. Aucune des deux adresses ne pouvait non plus être désignée par son identifiant externe, obligeant à ressaisir des adresses déjà connues de DJUST.

Fonctionnement

L'import ORDER accepte désormais sept champs cibles Billing Address * — Full Name, Country, Street Name, City, Zip Code, State et (Additional) — symétriques des champs Shipping Address * existants, en import de type fichier comme en import API.

Dès qu'un champ Billing Address * est renseigné, l'adresse de facturation de la commande est construite à partir des valeurs importées, à la création comme à la mise à jour. Les cinq champs Full Name, Country, Street Name, City et Zip Code deviennent alors obligatoires : la ligne est rejetée avec le code F-E-001 si l'un d'eux manque. L'adresse importée est un instantané porté par la commande, elle n'est ni créée ni rattachée au compte client.

Deux champs supplémentaires, Shipping Address External Id et Billing Address External Id, permettent de rattacher une adresse existante du tenant par son identifiant externe, en import de type fichier. L'identifiant externe prime sur les champs détaillés de la même adresse, qui sont alors ignorés ; un identifiant inconnu entraîne le rejet de la ligne.

Tous ces champs sont optionnels et disponibles dans le mapping de l'import ORDER, au même titre que les champs Shipping Address *. Sans eux, l'import conserve son comportement actuel : première adresse de livraison et première adresse de facturation du compte client.

📄 Documentation : ORDER

👉 Côté métier : les commandes externes portent l'adresse de facturation attendue dès l'import, sans reprise manuelle, et les adresses déjà référencées dans DJUST se rattachent par leur identifiant externe plutôt que par ressaisie.

👉 Côté technique : neuf nouveaux champs cibles optionnels dans le mapping de l'import ORDER, sans impact sur les imports existants.

🛠️ API

Deux champs dépréciés ne sont plus renvoyés par défaut aux nouveaux tenants

Contexte

Les lignes de commande logistique transportent deux champs dépréciés depuis la version 3.29, dont le contenu est déjà disponible ailleurs dans la même réponse. Sur les listes de commandes, où chaque commande affiche plusieurs lignes d'aperçu, ces champs alourdissent sensiblement les réponses sans rien apporter.

Fonctionnement

Un réglage par tenant détermine désormais si ces deux champs sont renvoyés. Il est actif sur tous les tenants existants : rien ne change pour les intégrations en place, qui continuent de les recevoir.

Le réglage est en revanche inactif par défaut sur les tenants créés à partir de cette version : leurs réponses ne contiennent pas ces deux champs. Un tenant existant peut également demander leur retrait pour alléger ses réponses.

Aucune donnée n'est perdue dans les deux cas : le contenu reste disponible à valeurs identiques dans les champs qui remplacent ces deux-là depuis la 3.29. Les intégrations qui les lisent encore ont intérêt à basculer dès maintenant sur leurs remplaçants.

Impact API

Champs concernés sur les lignes de commande logistique, et leurs remplaçants :

• orderLogisticLinePriceDto → offerPriceSnapshotDto pour le prix, offerInventorySnapshotDto pour le taux de taxe, la quantité par unité, la source externe, la devise et le type de conditionnement
• offerCustomFieldSnapshotDtos → offerInventorySnapshotDto.customFieldValueSnapshots

Le réglage s'applique à l'ensemble des routes exposant des lignes de commande logistique, listes comme détail.

Allègement constaté sur les lignes d'aperçu : de l'ordre de 15 % à 38 % selon le nombre de champs personnalisés d'offre du tenant.

📄 Documentation : Search, Filter & Sort Logistic Orders

👉 Côté métier : les réponses des listes de commandes s'allègent pour les tenants qui le demandent, sans perte d'information.

👉 Côté technique : deux champs dépréciés depuis la 3.29 cessent d'être renvoyés par défaut aux nouveaux tenants ; la bascule vers offerPriceSnapshotDto et offerInventorySnapshotDto est à prévoir avant d'activer le retrait sur un tenant existant.