MCC WMS — Documentation projet

1. Vue d'ensemble

Architecture, acteurs, principes

Le projet WMS connecte deux systèmes critiques de MCC :

Stealth 3000 — l'ERP qui gère commandes, stocks, articles, clients et fournisseurs (format XML, namespace http://www.csc.com/stealth3000).
Reflex WMS — le système de gestion d'entrepôt qui pilote la préparation, le stockage et l'expédition (format texte à colonnes fixes, rubriques HL16xxx en sortie et HL52xxx en réponse).

Un middleware Python orchestré par n8n sur un VPS Hostinger transforme les données en bidirectionnel, gère les transferts SFTP, garde la traçabilité de chaque fichier dans une base SQLite, et expose un dashboard temps réel.

Acteurs et systèmes

Acteur	Rôle	Interface
Stealth (CSC)	ERP source — référent métier (commandes, stock, clients)	XML + API REST
Reflex (Hardis)	WMS d'exécution — préparation, stockage, expédition	SFTP + TXT colonnes fixes
n8n	Ordonnancement et orchestration des flux	n8n.mccstudio.eu
Shopify	Suivi commandes web et tracking	API REST
VPS Hostinger	Exécution des scripts Python et stockage tracker	SSH
ADV MCC	Validation Delivery Notes côté Stealth (workflow métier)	Interface Stealth

Environnements

Env	Stealth	Reflex SFTP	Statut
prod	API Stealth (FR1)	`/wms/prod/mcc_to_reflex/`	Actif
test	API Stealth (FR1)	`/wms/test/mcc_to_reflex/`	Actif (recette)

2. Cycle de vie d'une commande

De l'arrivée d'une commande dans Stealth à son expédition — toutes les étapes de la chaîne

Une commande client passe par 11 étapes successives entre Stealth, le middleware, Reflex et l'ADV. Les étapes 2 à 8 sont entièrement automatisées et tournent en boucle toutes les 5 minutes. L'étape 10 (Delivery Note) est manuelle, réalisée par l'ADV dans Stealth.

Stealth — l'ERP source

Middleware — nos scripts Python

Reflex — l'entrepôt physique

ADV — équipe Administration des Ventes

Saisie de la commandeStealth

L'ADV ou le canal e-commerce (Shopify) saisit une commande dans Stealth. Stealth lui assigne une référence du type FR1-2026-AC-22 (B2B), FR1-2026-NS-29 (B2B autre type) ou FR1-2026-EC-105 (e-commerce). Une fois validée et payée (pour le e-com), la commande génère une Picking List dans la queue de synchronisation Stealth.
Dépilage de la queue StealthMiddleware

Toutes les 5 minutes, le script dequeue_stealth.py interroge la queue Stealth via l'API et récupère tous les types de messages : Picking List, Customer, Supplier, autres. Chaque message est routé vers son flux dédié dans data/sync/ (sous-dossiers par type). Les types inconnus sont stockés dans data/sync/store/{TYPE}/ pour analyse ultérieure.
Mise à jour du référentiel clientMiddleware

Si de nouvelles fiches client ont été dépilées, le script customer.py les transforme en TXT à colonnes fixes (HL16) et les place dans data/outbound/customer/output/. Cette étape doit obligatoirement précéder la Picking List car Reflex a besoin du client référencé avant d'accepter une PL.
Mise à jour du référentiel fournisseurMiddleware

Le script supplier.py traite les éventuelles fiches fournisseur dépilées. Faible cadence métier (quelques messages par semaine). Format identique : TXT à colonnes fixes vers data/outbound/supplier/output/.
Génération du fichier Picking ListMiddleware

Le script picking_list.py transforme chaque XML Picking List en TXT Reflex (rubriques HL16110/111/120/129 pour le B2B, et 11A/114/115 en plus pour le B2C). Les EAN13 manquants sont résolus via l'API Stealth. Le résultat est déposé dans data/outbound/picking_list/output/. Les XMLs portant PBT_F_RICCANC=1 sont déviés vers le flux d'annulation (en DRY-RUN actuellement).
Upload SFTP vers ReflexMiddleware

Le script ftp_upload.py envoie tous les TXT générés (Customer + Supplier + Picking List) vers le SFTP Reflex dans /wms/{env}/mcc_to_reflex/out. Chaque fichier uploadé est archivé localement dans archive/ et tracé dans le tracker SQLite avec le statut uploaded.
Préparation physique en entrepôtReflex

Reflex récupère les fichiers depuis le SFTP, les ingère, et déclenche la préparation physique : picking, contrôle, packing, étiquetage transporteur. À l'issue, Reflex génère un fichier de réponse au format HL52xxx contenant les quantités effectivement préparées (AST_QTA_PICKED) et les références colis (SSCC). Les préparations partielles ou à zéro article sont aussi envoyées.
Download SFTP depuis ReflexMiddleware

Le script ftp_download.py récupère les fichiers déposés par Reflex dans /wms/{env}/mcc_to_reflex/in. Chaque fichier téléchargé est placé dans data/inbound/picking_response/incoming/ pour traitement immédiat.
Génération du BOINPICKED et envoi APIMiddleware

Le script picking_response.py parse le HL52xxx, reconstruit l'XML BOINPICKED attendu par Stealth, complète si besoin avec le tracking Shopify, et l'envoie à l'API Stealth (POST /v1/...). En cas de succès, le fichier passe en sent_api/. En cas d'erreur (timeout, ligne refusée, etc.), il bascule en error/ avec un log .err attaché et reste rejouable depuis le dashboard.
Allocation complète côté StealthStealth

Quand Stealth reçoit le BOINPICKED avec succès, il met à jour la ligne de PL : allocStatus = 40 (Complete allocation) et associe la référence colis (Packages Reference). À ce stade, la PL est techniquement prête à être expédiée mais la commande client n'est pas encore marquée comme expédiée.
Création du Delivery NoteADV

Étape manuelle réalisée par l'équipe ADV dans Stealth. Une fois le Delivery Note créé pour la commande, les lignes en allocStatus=40 basculent en « Shipped Rows », et le logisticStatus de la commande passe à sent. Cette étape clôt le cycle côté ERP : la commande est officiellement expédiée et facturable.

Récapitulatif chronologique

Étape	Acteur	Déclencheur	Durée typique	Trace
1. Saisie commande	ADV / Shopify	Manuel ou automatique	—	Stealth
2. Dépilage queue	Middleware	Schedule n8n (5 min)	~10s	Tracker · flux `dequeue`
3. Customer	Middleware	Étape suivante de la chaîne	~5s par fichier	Tracker · flux `customer`
4. Supplier	Middleware	Étape suivante de la chaîne	~5s par fichier	Tracker · flux `supplier`
5. Picking List	Middleware	Étape suivante (après Customer)	~5-30s par fichier	Tracker · flux `picking_list`
6. Upload SFTP	Middleware	Étape suivante de la chaîne	~3s par fichier	Tracker · action `uploaded`
7. Préparation physique	Reflex	Réception SFTP	Quelques heures à 1 jour	Reflex (hors périmètre middleware)
8. Download SFTP	Middleware	Étape suivante (à chaque cycle 5 min)	~3s par fichier	Tracker · action `downloaded`
9. BOINPICKED API	Middleware	Étape suivante de la chaîne	~2-5s par PL	Tracker · flux `picking_response`
10. allocStatus = 40	Stealth	Réception BOINPICKED	Instantané	API Stealth
11. Delivery Note	ADV	Manuel	Variable (heures à jours)	Stealth (workflow ADV)

Points de vigilance opérationnels

Ordre dans la chaîne — Customer doit toujours précéder Picking List ; sinon Reflex rejette la PL pour client introuvable. C'est garanti par l'enchaînement séquentiel dans n8n.
Erreurs Reflex (étape 7) — invisibles côté middleware. C'est le download SFTP (étape 8) qui révèle un fichier .err émis par Reflex le cas échéant. Affichage automatique dans le dashboard.
BOINPICKED en erreur (étape 9) — déposé dans error/ avec son log. Rejouable d'un clic depuis le dashboard. Cause typique : EAN inconnu côté Stealth, ligne déjà BOINPICKED, format invalide.
PL en attente Delivery Note (étape 11) — la Picking Response est OK mais la commande reste en logisticStatus != sent. Le dashboard expose ces cas dans la pastille « PL en attente Delivery Note » pour relance ADV.
Réconciliation toutes les 30 min — interroge l'API Stealth pour vérifier l'état réel de chaque PL en doute, et marque automatiquement stealth_synced ou stealth_cancelled selon le cas. Évite les faux positifs persistants dans le dashboard.

3. Flux en production

6 flux métier traités automatiquement, traçabilité fichier-par-fichier dans le tracker SQLite

EN PROD · workflow n8n actif et events tracés

Picking List (Bons de préparation)

EN PROD

Stealth XML → Reflex TXT (rubriques HL16xxx)

Direction: outbound (Stealth vers Reflex)
Cadence: Toutes les 5 minutes (chaîne MCC WMS – PROD)
Volume 7j: 699 fichiers traités
Format: HL16110 (entête) + HL16120 (lignes article) + HL16129 (commentaires PLL/PL2/WEB) + HL11A/114/115 (adresse + contacts e-com)
Logique métier: Détection B2B vs B2C via PBT_INP_COD (EC = e-commerce). EAN13 résolu via API Stealth si absent du XML.
Optimisations perf (18/05/2026): Cache bearer token (1 login/run au lieu de 1/ligne) + cache EAN par variante (MOD/PAR/COL/TGL/ETI/CAR) → gain mesuré ×8 sur PL volumineuses (NS-185 308 lignes : 10 min → 74 s)
Priorisation: Wholesale d'abord par défaut : les PL NS/AC/RNS/RAC sont traitées avant les EC. Désactivable via MCC_PL_WHOLESALE_FIRST=0.
Script: scripts/outbound/picking_list.py sur le VPS

Picking Response (Réponse de préparation)

EN PROD

Reflex TXT (HL52xxx) → Stealth XML (BOINPICKED via API)

Direction: inbound (Reflex vers Stealth)
Cadence: Toutes les 5 minutes (chaîne MCC WMS – PROD)
Volume 7j: 693 fichiers traités
Format: HL52110 (entête) + HL52220 (quantités préparées) + tracking. Quantités partielles et zéro-pick gérées.
Logique métier: Génération de l'opération BOINPICKED envoyée à l'API Stealth. Lookup tracking Shopify pour les commandes web.
Script: scripts/inbound/picking_response.py sur le VPS

Customer (Données clients)

EN PROD

Stealth XML → Reflex TXT

Direction: outbound (Stealth vers Reflex)
Cadence: Toutes les 5 minutes (chaîne MCC WMS – PROD)
Volume 7j: 129 fichiers traités
Logique métier: Normalisation des numéros de téléphone multi-pays (FR, IT, MC). Mapping codes service transporteur.
Précondition: Doit s'exécuter avant la Picking List (Reflex a besoin du référentiel client à jour).
Script: scripts/outbound/customer.py sur le VPS

Supplier (Données fournisseurs)

EN PROD

Stealth XML → Reflex TXT

Direction: outbound (Stealth vers Reflex)
Cadence: Toutes les 5 minutes (chaîne MCC WMS – PROD)
Volume 7j: 3 fichiers traités (faible cadence métier)
Script: scripts/outbound/supplier.py sur le VPS

Retours Web

EN PROD

Reflex → Stealth (workflow dédié)

Direction: retour
Cadence: Quotidien à 11h00 (workflow MCC WMS – Retours Web PROD)
Volume 7j: 8 retours traités
Script: scripts/retour/run_retour_web.py --send

Dequeue Stealth

EN PROD

Extraction de la queue de synchronisation Stealth

Direction: sync
Cadence: Toutes les 5 minutes (chaîne MCC WMS – PROD, première étape)
Volume 7j: 2 162 messages dépilés
Logique: Récupère tous les types de messages de la queue Stealth. Les types connus sont routés vers les flux dédiés (Customer, Supplier, Picking List, etc.). Les types inconnus sont stockés dans data/sync/store/{TYPE}/ pour analyse ultérieure.
Script: scripts/sync/dequeue_stealth.py

4. Outils opérationnels en production

3 services support qui tournent en parallèle des flux métier

Réconciliation automatique Stealth

EN PROD

Workflow MCC WMS – Reconcile Stealth · toutes les 30 min

Pour chaque Picking List dont la Picking Response est en erreur ou n'arrive jamais, le script interroge l'API Stealth (/v1/core/allocation/sales-picking-list/...) pour vérifier le statut réel côté ERP :

PL absente de l'API Stealth → marquée stealth_cancelled (annulation côté Stealth)
logisticStatus = sent → marquée stealth_synced (cas résolu, Delivery Note créé)
PL toujours active → reste en stealth_pending (en attente Delivery Note ADV)

Cela permet d'exclure automatiquement les faux positifs du dashboard.

Maintenance et monitoring

EN PROD

Workflow MCC WMS – Maintenance · toutes les heures

check_missing_pl.py — détection des commandes web payées sans Picking List émise
calc_speed.py — calcul des temps de traitement (Stealth → Picking → Réponse)
compress_archives.sh 7 — compression des archives de plus de 7 jours
archive_cleanup.sh 90 — purge des archives de plus de 90 jours
check_retours.py — vérification du flux retours

Dashboard temps réel

EN PROD

HTTP server léger sur le VPS, expose tracker SQLite + alertes

Accessible sur wms-tracker.mccstudio.eu (auth basic).

Vues disponibles :

Liste des événements (filtres env / direction / flux / statut) — timestamps au format FR 11/05/2026 14:23
Détail d'un événement avec téléchargement du fichier source et des logs d'erreur
Possibilité de rejouer un événement en erreur
Possibilité de renvoyer un BOINPICKED à Stealth
Pastilles agrégées : commandes web sans PL, PL en attente Delivery Note, état des flux par environnement
Liens directs : /doc (cette documentation), /dequeue (explorateur archives)

Explorateur Dequeue

EN PROD

Consultation des archives XML dépilées des queues Stealth (REFLEX_WEB + SAGE)

Accessible sur wms-tracker.mccstudio.eu/dequeue.

Permet de retrouver et télécharger n'importe quel XML stocké localement après dequeue :

6 types exposés : BARCODE, CUSTOMER, CUSTOMERINVOICE, STYLEITEM, SUPPLIER, WHMOVEMENT_03
Deux sources par type : store (archive principale, dédupliquée) et duplicates (versions reçues en double)
Pagination 50 par page, tri du plus récent au plus ancien
Recherche par nom de fichier (n° message Stealth, date, etc.)
Téléchargement direct du XML (utile pour pousser une CUSTOMERINVOICE vers Sage par exemple)
Téléchargement zip groupé : 📦 bouton pour récupérer tous les fichiers d'un type (ou ceux du filtre actif) en un seul zip — streaming serveur, fonctionne sur des volumes 2 GB+
Sécurité : path traversal bloqué, lecture seule, chemins confinés à /opt/mcc-wms/data/sync/

Suivi cycle de vie PL (vue ADV + tech)

EN PROD

API REST + vue HTML pour suivre une PL de bout en bout

Accessible sur wms-tracker.mccstudio.eu/pl/ (page de recherche) ou directement par /pl/{ref}.

3 formats de ref acceptés : FR1-2026-NS-190, 2026NS190, NS-190 (raccourci)
Deux vues :
- Vue ADV (par défaut, utilisateur adv) : 5 étapes métier (saisie → bon prêt → entrepôt → préparation finie → expédiée) sans jargon technique. Tracking colis visible. Action suggérée par catégorie d'erreur.
- Vue tech (utilisateur mcc) : 8 étapes complètes avec event_id et filenames cliquables. Toggle via bouton.
Croise 3 sources : tracker SQLite (events), XML PICKINGLIST archive (métadonnées commande), API Stealth live (allocStatus/logisticStatus)
Endpoint REST : GET /api/v1/pl/{ref}/timeline?view=adv|tech → JSON avec champ summary LLM-friendly

Auth séparée ADV / IT

Deux comptes basic auth dans le middleware Traefik :

mcc : accès complet (tracker, dequeue, doc, suivi PL avec toggle tech)
adv : accès lecture seule, vue ADV forcée sur /pl/ (pas de toggle tech)

Catégorisation automatique des erreurs Stealth

EN PROD

Les rejets BOINPICKED sont classés en 8 catégories métier avec action suggérée

Le rendu de la vue PL affiche un libellé clair et un hint action pour l'ADV plutôt que le message brut Stealth :

Catégorie	Verdict	Couleur	Action suggérée
`couleur_inexistante`	boinpicked_rejected	🔴 rouge	Créer la variante manquante dans le catalogue maître Stealth
`modele_inexistant`	boinpicked_rejected	🔴 rouge	Créer le modèle dans le catalogue maître Stealth
`deja_traitee`	ready_to_ship	🟢 vert	Aucune action — affichage du tracking dispo (extrait depuis le BOINPICKED XML)
`pl_deja_executee`	ready_to_ship	🟢 vert	Aucune action — la PL a déjà été acceptée par Stealth
`pl_non_trouvee`	annulee	🟣 violet	Vérifier avec ADV si la commande a été annulée
`ligne_inconnue_pl`	boinpicked_rejected	🔴 rouge	PL modifiée côté Stealth après émission — demander à l'ADV de re-générer
`quantite_invalide`	boinpicked_rejected	🔴 rouge	Vérifier les quantités HL52 vs attendues
`http_5xx_stealth_down`	transient_error	🟠 orange	Retenter plus tard
`timeout`	transient_error	🟠 orange	Retenter, éventuellement augmenter le timeout
`autre`	boinpicked_rejected	🔴 rouge	Inspecter le message d'erreur complet

Cas spécial deja_traitee / pl_deja_executee : Stealth dit "déjà existant" ou "PL exécutée" car la PL a déjà été BOINPICKED-é avec succès. Ce n'est pas une erreur métier. L'affichage devient "Déjà traitée — Tracking dispo : XXX" en vert.

Le verdict global se base sur le meilleur historique : si une PL a au moins un api_send=ok, le verdict reste ready_to_ship même si des resends ultérieurs échouent.

Replay manuel avec protection

EN PROD

Bouton "🔁 Rejouer" sur tout event en erreur, contourne la protection get_error_files automatiquement

Quand on clique "Rejouer" depuis le détail d'un event :

Tous les events status=error précédents pour le même filename (.txt + .xml) sont marqués error_superseded
Le fichier source est copié de error/ vers incoming/
Un event replay est tracé avec le compteur de supersession
Le prochain cycle n8n retraite le fichier (la protection ne le bloque plus)

La trace originale de l'erreur est préservée : seul le status change, les détails restent.

Renvoi BOINPICKED direct (single + batch)

EN PROD

Bouton "📤 Renvoyer à Stealth" + endpoint batch pour rejouer plusieurs events d'un coup

L'envoi du BOINPICKED à Stealth se fait directement depuis le container dashboard via urllib.request stdlib (plus de subprocess). Pas besoin du venv host ni de la lib requests installée.

3 endpoints disponibles :

POST /api/resend_boinpicked/{event_id} : renvoi single (bouton "📤 Renvoyer à Stealth")
POST /api/resend-batch?ids=A,B,C : batch jusqu'à 50 events explicites
POST /api/resend-batch?mode=all_errors : batch auto-pick de tous les api_send/error actuels (max 50)

Le résumé du batch indique le nb OK/erreurs et la catégorie d'erreur Stealth de chaque cas.

Génération CLL_COD pour les BOINPICKED EC

EN PROD

Format unique 9YY + 7 digits pour éviter les collisions Stealth

Pour les BOINPICKED EC, deux sources possibles pour le CLL_COD (identifiant colis côté Stealth) :

Si Reflex fournit un SSCC dans la rubrique HL52 410 → le CNUF de ce SSCC est utilisé (format 0000XXXXXX, garanti unique GS1).
Sinon → fallback synthétique généré côté middleware avec le nouveau format 9YY + num_PL_padded_7 (ex: 9260000801 pour EC-801 année 2026).

Le préfixe 9 évite les collisions avec :

Les CNUF Reflex (format 0000XXXXXX) pour les B2B
L'ancien format synthétique (année + 6 digits) qui causait régulièrement des erreurs "il y a déjà un colis avec le numéro X" côté Stealth

Pour les B2B (NS / AC / RAC / RNS), le CLL_COD vient toujours du SSCC réel fourni par Reflex (HL52 310/410), aucune génération côté middleware.

5. Indicateurs (7 derniers jours)

Volumes et cadences observés en production

2 241

Messages dépilés Stealth

699

Picking Lists générées

895

Picking Responses traitées

Mises à jour clients

5 min

Cadence chaîne principale

Environnements (prod / test)

Archive dequeue (cumulé depuis le démarrage)

Type Stealth	Source queue	Fichiers store	Duplicates
BARCODE	REFLEX_WEB	21 713	0
CUSTOMER	REFLEX_WEB	3 988	20 749
CUSTOMERINVOICE	SAGE	1 000	22
STYLEITEM	REFLEX_WEB	17 650	1 881
SUPPLIER	REFLEX_WEB	181	729
WHMOVEMENT_03	REFLEX_WEB	959	0

Cadences des workflows n8n

Workflow	Fréquence	Statut
MCC WMS – PROD (chaîne complète)	Toutes les 5 minutes	Actif
MCC WMS – Reconcile Stealth	Toutes les 30 minutes	Actif
MCC WMS – Maintenance	Toutes les heures	Actif
MCC WMS – Retours Web PROD	Quotidien à 11h00	Actif

6. Flux prévus / en cours

Roadmap : ce qui n'est pas encore en production

EN COURS · code prêt ou validation en cours

PRÉVU · spec établie, attente d'un déclencheur

Cancel Order (Annulation HL16810)

EN COURS

Stealth XML (PBT_F_RICCANC=1) → Reflex TXT HL16810

Statut: Code prêt en mode DRY-RUN (aucun envoi à Reflex). Détection automatique des XMLs avec flag d'annulation, génération de la rubrique HL16810 (128 chars).
Bloqueur: Validation du format avec Reflex avant activation des envois.
Prochaine étape: Échange technique avec Reflex sur la rubrique 810 (référence : annulation odp.pdf de Hardis).
Code: scripts/cancel_order.py (déployé sur VPS, désactivé)

Codes Retail (RAC / RNS)

EN COURS

Nouveau Motif ODP pour différencier les flux retail des flux wholesale

Statut: Validé côté Stealth (Marco). En attente du retour Reflex.
Principe: Aujourd'hui : PBT_INP_COD envoie AC / NS pour le wholesale et WEB (forcé depuis EC) pour l'e-commerce. À ajouter : RAC / RNS pour le retail.
Contrainte: Le champ Reflex pos 77-79 du HL16111 fait 3 caractères → préfixe R retenu.
Bloqueur: Le contact Reflex est en congés. Reprise du sujet à son retour pour valider l'absence d'impact warehouse.

Workflow Delivery Note ADV

EN COURS

Bascule des Picking Lists vers logisticStatus=sent via la création de Delivery Note dans Stealth

Statut: Process documenté. 32 PLs en attente de traitement par l'ADV à date.
Workflow: BOINPICKED OK (côté nous) → allocStatus = 40 (Stealth) → création Delivery Note par l'ADV → logisticStatus = sent (Shipped Rows).
Action en cours: Liste des 32 PLs (2 B2B + 23 e-com + 7 pré-prod) communiquée à l'ADV pour traitement.

Q&L Stealth « GO_000 »

PRÉVU

Endpoint Query & List pour automatiser le suivi des statuts de Picking List

Statut: Demande envoyée à Marco. En attente du contextCode exact pour invoquer l'extraction « Detailed Picking List ».
Bénéfice attendu: Permettrait d'automatiser la vérification de l'allocStatus sans dépendre d'un appel REST par PL.

API monitoring pour agent IA (V2)

PRÉVU

Agent IA qui consomme l'API tracker pour alerter et diagnostiquer automatiquement

État au 18/05/2026: L'API REST read-only de consultation du tracker est déjà en place : /api/v1/pl/{ref}/timeline avec champ summary LLM-friendly. La couche "agent IA + alertes Slack" reste à brancher.
Endpoints encore à ajouter: /api/v1/health · /api/v1/anomalies · /api/v1/errors · /api/v1/events/{id} · /api/v1/flows/{flow}/stats · /api/v1/stealth/pl?refs=...
Couche agent: Workflow n8n qui interroge /anomalies toutes les 30 min, transmet le JSON à un LLM (Claude API), qui décide d'alerter sur Slack/email en cas de sévérité critique.
Règles d'anomalie: Flux silencieux >30min · cluster ≥5 erreurs/h · PL bloquée >48h en to_send · latence p95 >10min · fichier en erreur non rejoué >24h · réconciliation Stealth KO >2 cycles · BOINPICKED en attente API >1h.

Avis de réception (INT_015)

PRÉVU

Stealth WHMOVEMENT → Reflex INT_015

Statut: Script local développé (AVIS DE RECEPTION/stealth_to_int015.py). Pas encore déployé en production (jamais activé dans le pipeline n8n).
Prochaine étape: Tests de recette avec un volume réel, puis déploiement VPS et ajout au workflow n8n.

Articles / Products

PRÉVU

Stealth XML → Reflex TXT (référentiel article)

Statut: Scripts locaux développés (ARTICLE/, PRODUCT/). Pas encore déployés en production.
Prochaine étape: Validation du périmètre avec Reflex (champs requis, fréquence) puis déploiement.

7. Écosystème technique

Infrastructure, accès, contacts

Infrastructure

Composant	Détail
VPS	Hostinger · 31.97.54.176 · accès SSH
Orchestration	n8n.mccstudio.eu (workflows, scheduling, monitoring)
Base de traçabilité	SQLite `/opt/mcc-wms/data/tracker.db` (table `file_events`)
SFTP Reflex	`46.202.168.81:2022` (user MCC)
API Stealth	`https://mcc-test.stealthgo.cloud/StealthApi/` (Basic Auth, société FR1)
API Shopify	Lookup tracking pour les Picking Responses e-com

Conventions de répertoires Reflex SFTP

Sens	Chemin	Rôle
Sortant (nous → Reflex)	`/wms/{env}/mcc_to_reflex/out`	Dépose des fichiers à traiter par Reflex
Entrant (Reflex → nous)	`/wms/{env}/mcc_to_reflex/in`	Récupération des fichiers émis par Reflex
Archive sortant	`/wms/{env}/mcc_to_reflex/arc/out`	Archive des fichiers déposés
Archive entrant	`/wms/{env}/mcc_to_reflex/arc/in`	Archive des fichiers reçus

Contacts

Côté	Contact	Domaine
Stealth (CSC)	Marco	API, format XML, workflow Stealth (Delivery Notes, allocStatus)
Stealth (CSC)	Matteo	Picking List, codes ODP, évolutions de spec
Reflex (Hardis)	Contact en congés	Format HL16xxx / HL52xxx, déploiement de nouvelles rubriques
MCC ADV	Équipe ADV	Création des Delivery Notes (bascule logisticStatus)
MCC IT	Morad Maghrebi	Middleware, n8n, dashboard, intégration

8. Glossaire

Terme	Définition
HL16xxx	Format texte à colonnes fixes utilisé par Reflex pour les flux entrants (Picking List, Customer, Supplier). Le suffixe désigne la rubrique (110 = entête, 120 = ligne article, 129 = commentaire, etc.).
HL52xxx	Format Reflex pour les flux sortants (Picking Response). 110 = entête, 220 = quantité préparée.
HL16810	Rubrique d'annulation d'une Picking List (128 caractères).
BOINPICKED	Code d'opération Stealth correspondant à une Picking Response confirmée (XML envoyé à l'API Stealth).
allocStatus	Statut d'allocation d'une ligne de PL côté Stealth. `30` = en cours, `40` = allocation complète (déclenche la création du Delivery Note).
logisticStatus	Statut logistique global d'une commande Stealth. `sent` = expédié, posé après création du Delivery Note.
Delivery Note	Document de livraison créé manuellement par l'ADV dans Stealth après réception du BOINPICKED.
ODP	Ordine di Preparazione (Ordre de préparation). Le « Motif ODP » est le code à 3 caractères en pos 77-79 du HL16111 qui pilote le routing warehouse côté Reflex.
PBT_INP_COD	Champ Stealth qui porte le type de commande (AC / NS / EC). Utilisé comme Motif ODP (avec EC remplacé par WEB côté Reflex).
EAN13	Code-barres standard. Résolu via API Stealth lors de la génération des Picking Lists si absent du XML source.
SSCC	Identifiant logistique GS1 sur 18 caractères (numéro de colis).
B2B / B2C	Wholesale (B2B, code AC ou NS) vs e-commerce (B2C, code EC). Détecté via `PBT_INP_COD`.
Tracker	Base SQLite qui trace chaque fichier traité (id, timestamp, env, direction, flux, filename, action, status, details). Source de vérité pour le dashboard.
Dequeue	Processus qui extrait les messages de la queue de synchronisation Stealth pour les router vers les flux dédiés.