Mise à jour des données de livraison
Ce workflow couvre les demandes où le client veut corriger une information utilisée pour la livraison de sa commande : adresse, code postal, ville ou numéro de téléphone.
Le comportement a évolué côté backend et Logidav. La règle à documenter ici doit donc rester alignée avec la source de vérité validée pour la production.
Données collectées
Le chatbot transmet les valeurs dans custom_fields.
| Champ | Description |
|---|---|
new_address | Nouvelle adresse de livraison. |
new_postal_code | Nouveau code postal. |
new_town | Nouvelle ville. |
new_number | Nouveau numéro de téléphone. |
Les champs vides ou égaux à - ne doivent pas être considérés comme des valeurs utiles.
Conditions d'acceptation
La demande peut être traitée uniquement si :
- au moins une donnée de livraison exploitable est fournie,
- la commande est retrouvée,
- l'état de la commande permet encore une modification,
- la modification ne contredit pas une règle Logidav ou transporteur.
Règles de création de ligne
La modification doit être appliquée sur Logidav lorsque les données sont valides et que la commande reste modifiable. La création d'une ligne dans le tableau SAV dépend ensuite du contexte logistique.
| Contexte | Action attendue |
|---|---|
| Hors IDF, étiquette non imprimée | Changement direct sur Logidav, ajout dans l'historique Logidav, pas de ligne tableau SAV. |
| Hors IDF, étiquette déjà créée | Changement sur Logidav, ajout dans l'historique Logidav, création d'une ligne tableau SAV pour intervention transporteur. |
| IDF, feuille déjà imprimée | Changement sur Logidav, ajout dans l'historique Logidav, création d'une ligne tableau SAV pour intervention transporteur. |
La ligne tableau SAV sert à rendre visible une action humaine nécessaire auprès du transporteur. Elle ne doit pas être créée lorsque le changement peut être appliqué directement sans intervention transporteur.
Cas de refus connus
| Situation | Comportement attendu |
|---|---|
Aucun champ utile dans custom_fields | Refuser la demande et demander au client une donnée exploitable. |
| Commande déjà en cours d'expédition | Appliquer la règle transporteur validée : changement Logidav si autorisé, puis ligne SAV si une intervention transporteur est nécessaire. |
| Produit ou commande non retrouvée | Rebasculer vers un traitement SAV ou support. |
| Transporteur incompatible après changement | Appliquer la règle backend/Logidav validée pour le recalcul transporteur. |
Impact système
Selon la version validée du flow, la mise à jour peut impliquer :
- mise à jour directe de l'adresse de livraison Logidav,
- recalcul du transporteur disponible,
- synchronisation aval via événement Logidav,
- ligne SAV ou ticket technique lorsque l'intervention transporteur est nécessaire.
Point métier à valider
Les sources consultées montrent une divergence historique :
- le diff Logidav initial
869dgyn74décrit une mise à jour directe sans création de SAV ni relance, - les docs backend plus récentes mentionnent le recalcul transporteur et une observation SAV lorsque le flow crée une demande.
Avant de figer cette page, il faut valider le comportement de production attendu pour update-shipment-details / delivery-info-update.
Diagramme existant à revalider
Le schéma ci-dessous est conservé pour ne pas perdre la représentation existante du workflow. Il doit être revalidé avec le comportement métier final, car il contient encore des étapes liées à l'upload photo ou à l'avis client qui ne sont pas forcément applicables à la mise à jour des données de livraison.