Guide 08 - Import par upload d'un export Excel/CSV (chemin actif)
✅ Chemin retenu le 2026-07-13 après échec de HiFlow (
GetAppIdError, compte non provisionné), impossibilité de l'API WeCom Smart Sheet (tableur classique), et blocage du téléchargement direct (document Enterprise, lecture seule → lien non téléchargeable sans session). La Voie A OpenAPI (guide 07) reste dispo pour une future automatisation 100%.
Principe
n8n expose une page web avec un champ d'upload. L'utilisateur exporte le tableur Tencent Docs en Excel, dépose le fichier, et n8n envoie les emails de suivi. Aucune API Tencent, aucun OAuth, aucun HiFlow. L'anti-doublon (UNIQUE (numero_commande, tracking_number), ADR 0004) rend l'opération répétable sans risque de doublon.
Flux
Formulaire d'upload → Extraire le fichier (Excel/CSV) → Normaliser → [pipeline commun : upsert, email, anti-doublon]
Étapes
- Importer
n8n/workflow-tracking-notifier.jsondans n8n. - Credentials Postgres + SMTP → voir guide 06.
- Activer le workflow → le node « Formulaire d'upload » donne une Production URL (une page web). C'est le lien que l'équipe utilisera.
- Exporter le tableur côté Tencent Docs : menu ☰ → 导出为 (Exporter en) → Excel (.xlsx).
- Déposer le fichier sur la page du formulaire.
⚠️ Le PREMIER import : mode « baseline » (ne pas spammer les anciennes commandes)
La table notification est la seule mémoire de « qui a déjà reçu un email ». Sur une base neuve elle est vide → un import normal enverrait un email à toutes les commandes existantes qui ont déjà un tracking (dont celles déjà notifiées à la main). Pour l'éviter :
- Tout premier import : dans le menu « mode » du formulaire, choisir « Premier import (baseline, sans email) ».
→ n8n enregistre tout en base et marque chaque couple (commande + tracking) existant avec
statut='backfill'dansnotification, sans envoyer aucun email. - Tous les imports suivants : choisir « Envoi normal ».
→ seuls les nouveaux trackings (absents de
notification) déclenchent un email.
Le node « Déjà notifié ? » considère statut IN ('envoye','backfill') comme « déjà traité » - donc les lignes marquées au baseline ne seront jamais re-emailées. Les backfill restent distincts des envoye pour l'audit (on sait que l'email n'a pas réellement été envoyé par le système).
Astuce : fais le baseline le jour où tu démarres, avec l'export le plus à jour. Tout ce qui existe à ce moment est considéré « déjà géré » ; seul le futur sera notifié.
Mapping des colonnes (vérifié sur le vrai CSV - par INDICE, pas par en-tête)
⚠️ Les en-têtes du fichier (ligne 1) sont bilingues et désalignés (cellules fusionnées) : le vrai statut de livraison est sous l'en-tête « currency », la colonne « Customer email » contient des notes de retour, etc. On ne peut donc pas se fier aux noms. Le fichier est lu sans en-tête (headerRow=false, includeEmptyCells=true) et « Normaliser » mappe par indice (positions vérifiées, 72 colonnes) :
| Champ | Col | Champ | Col |
|---|---|---|---|
| numero_commande | 5 | tracking_number | 19 |
| nom | 6 | email (colonne dédiée, souvent vide) | 21 |
| telephone | 7 | statut_logistique (réel) | 25 |
| date_expedition | 15 | numero_facture | 28 |
| entrepot | 16 | sku | 17 |
Réglages à vérifier au 1er test
- Nom de la binaire : après un upload de test, ouvrir l'exécution → vérifier le nom de la propriété binaire produite par le formulaire (supposé
fichier) →binaryPropertyName. - Format : node « Extraire le fichier » réglé sur
operation = csv. Pour un.xlsx, passer àxlsx. - Colonnes : vérifier que
numero_commandetombe bien en colonne 5 (sinon ajuster l'objetIDXdu node « Normaliser » - un décalage viendrait deincludeEmptyCells). - ⚠️ Emails absents : dans les données actuelles il n'y a aucun email exploitable → sans l'enrichissement Shopify/Shifter (guides 04/05), les lignes finissent en « email manquant » et aucun mail ne part. C'est normal au début.
- ⚠️ Statut STOCK : ~990 lignes ont un tracking mais un statut
STOCK(encore en entrepôt). Voir ci-dessous si un garde-fou est souhaité.
Renvoyer un email à la demande (bouton « Renvoyer »)
Second workflow n8n/workflow-renvoyer-email.json : une page web distincte où le support saisit un numéro de commande (ex. KO260107-2) → l'email de suivi est renvoyé même s'il a déjà été envoyé (il court-circuite volontairement le contrôle anti-doublon). Champ optionnel pour forcer une adresse si celle en base est absente/erronée. Le renvoi met à jour la notification (statut='envoye', date_envoi=now()).
Importer ce 2ᵉ workflow, brancher les mêmes credentials Postgres + SMTP, l'activer, et partager sa Production URL à l'équipe support. Le vrai bouton « Renvoyer » par commande viendra plus tard dans l'app admin (ADR 0003).
Confort (optionnel, plus tard)
- Rappel programmé : ajouter un cron/rappel qui envoie un email à l'équipe « pense à réimporter le fichier » (ex. chaque matin).
- Passer en 100% auto : basculer sur la Voie A OpenAPI (guide 07) une fois l'app développeur Tencent Docs approuvée - le pipeline aval (upsert/email) est identique, seule l'entrée change.
Checklist
-
db/schema.sqlappliqué avant le 1er import réel. - Workflow importé, credentials Postgres + SMTP OK (guide 06).
- Workflow activé, Production URL du formulaire récupérée et partagée à l'équipe.
- 1er upload de test : binaire =
fichier, format =csv(ouxlsx), mapping colonnes vérifié. - 1er import réel en mode « baseline » (marque l'existant sans email).
- Imports suivants en mode « Envoi normal ».
