NEDLOG — ERPNext, l'ERP de la confection textile
Étude de cas ERPNext : chez NEDLOG (vêtements de travail), ERPNext v16 importe les commandes Excel, calcule les manques et gère achats et stock.

NEDLOG : un ERPNext taillé pour la confection de vêtements de travail
NEDLOG fait partie du groupe Workwear Tunisia, qui confectionne en Tunisie des vêtements professionnels pour le marché européen : tenues haute visibilité pour les équipes de chantier et de voirie, vêtements de protection, tenues de secours et de santé. Chaque vêtement associe un tissu principal à des dizaines de fournitures (bandes réfléchissantes, fil haute visibilité, velcros, fermetures, boutons, étiquettes tissées), et chaque modèle se décline en une dizaine de tailles ou plus.
NEDLOG pilote toute cette chaîne dans ERPNext, étendu par deux applications métier : du fichier Excel de commande envoyé par le client jusqu'à la sortie des matières vers l'atelier de coupe. Apeiron Technologies a repris la plateforme en 2026 : audit, mise sous contrôle de version, plan de tests fonctionnels, corrections, migration vers ERPNext v16 et application mobile. Cette étude de cas parcourt le système écran par écran.
En bref
| Client | NEDLOG, groupe Workwear Tunisia |
| Secteur | Vêtements de travail et de protection, fabriqués en Tunisie pour des clients européens |
| Plateforme | ERPNext v16 sur Frappe 16, plus deux applications Frappe sur mesure |
| Périmètre | Prise de commande, nomenclatures, planification, achats, magasins, réceptions, contrôle des entrepôts |
| Rôle d'Apeiron | Reprise de projet : audit, versionnement, plan de tests, corrections, migration v16, application mobile Flutter, évolutions |
Les captures ci-dessous proviennent d'une copie complète du système en service. Les noms des clients et des fournisseurs sont remplacés par des codes neutres (CLIENT-A, FOURN-A…).
Le défi : des commandes Excel, des centaines de matières, deux magasins
Un confectionneur de vêtements de travail qui produit pour des marques européennes vit une complexité bien particulière :
- Les commandes arrivent en classeurs Excel, dans la mise en page du client et parfois dans sa langue : bon de commande, répartition par taille, liste de coupe, nomenclature, proforma, étiquettes de colis. Chaque client a son format, et ce format peut changer d'une saison à l'autre.
- Un modèle, ce sont beaucoup d'articles. Un pantalon haute visibilité est un modèle avec une variante par taille (tailles spéciales comprises), chacune avec sa propre nomenclature (BOM). Les quantités de tissu et de fournitures varient selon la taille.
- Une partie des matières est fournie par le client. Le reste est acheté auprès de fournisseurs. Les deux circuits diffèrent : on demande au client d'expédier les premières, on passe une commande d'achat pour les secondes.
- Deux magasins, deux magasiniers. Les tissus (Fabric) et les fournitures (Trims) sont stockés et préparés par des équipes distinctes, sur plus de 700 emplacements, dont certains réservés à un seul client.
Sans un système pensé pour ce métier, tout se passe dans des tableurs : les lignes de commande sont ressaisies, les besoins matières calculés à la main, et la fermeture manquante se découvre sur la table de coupe plutôt qu'au moment de planifier.
La solution ERPNext en un schéma

Le principe est simple : chaque document naît du précédent. Le fichier Excel crée la commande client et les nomenclatures. Les commandes sont regroupées dans un batch de production. Le batch calcule les besoins et les manques, qui génèrent les documents d'achat. Les colis reçus soldent ces documents, et la collecte fait passer les matières en en-cours. Chaque quantité remonte jusqu'à sa commande.
1. Importer les commandes Excel des clients dans ERPNext, sans ressaisie
Un lot d'import qui reconnaît le fichier
Le planificateur crée un Excel Import Batch, choisit le client et y dépose un ou plusieurs fichiers de commande. Chaque fichier est analysé en arrière-plan : le système lit les noms des onglets du classeur (sa « signature »), retrouve le template d'import correspondant et extrait les données.
Chaque fichier reçoit un statut explicite :
- Parsé : la mise en page est connue, les données sont extraites.
- Mapping requis : la mise en page est nouvelle, le système demande qu'on la lui apprenne.
- Anomalie détectée : les totaux ne concordent pas (par exemple, la répartition par taille ne correspond pas à la quantité totale). La raison est expliquée, et un fichier faux n'est jamais marqué « Parsé » en silence.

Apprendre une nouvelle mise en page en quelques clics
Quand un client change de format, personne n'a besoin d'écrire du code. L'écran « Mapper ce fichier » affiche un aperçu de chaque onglet. L'utilisateur choisit un champ à gauche (code article, quantité, prix unitaire, date de livraison, tableau des tailles), clique sur le libellé dans la feuille, puis sur la cellule qui contient la valeur. Chaque règle affiche la valeur qu'elle extrait avant d'être enregistrée.

Les tableaux de tailles et les blocs (par exemple la longueur des fermetures par taille) se définissent de la même façon. Avant d'enregistrer, le template peut être testé sur les autres fichiers du lot. Une fois enregistré, il lit automatiquement tous les fichiers suivants de même format.

Du fichier à la commande et aux nomenclatures
Depuis chaque fichier parsé, deux boutons font le reste, chacun avec un aperçu avant toute création :
- Créer Sales Order (brouillon) : client, date de livraison, total des pièces, et une ligne par variante de taille avec son prix. S'il manque un article ou sa nomenclature par défaut, le système dit lequel au lieu de créer une commande incomplète.

- Créer articles et BOM : le modèle d'article et ses variantes de taille, puis les nomenclatures avec les quantités de matières par taille. L'aperçu liste les BOM à créer, celles qui sont identiques à l'existant et celles qui diffèrent : rien n'est écrasé par surprise.

2. Planification de la production : des batches hebdomadaires
La production se planifie à la semaine. Depuis la liste des commandes clients, des boutons propres à NEDLOG lancent la planification : Créer Batch de Production, Analyse le besoin, Create Purchase Order et Envoyer aux Magasiniers.

Un Batch de Production regroupe les commandes d'une semaine de production. Il porte le numéro de semaine, l'année, le responsable et la société, et son tableau de bord affiche d'un coup d'œil le nombre de commandes, d'articles Fabric, d'articles Trims et de manquants.

Chaque batch suit des statuts clairs : Brouillon → En cours → Email envoyé → Achat lancé → Collecte → Manques répartis → Clôturé. La vue liste montre où en est chaque semaine.

3. Calcul des besoins matières : voir les manques avant la coupe
De la nomenclature au tableau des besoins
Recalculer les Besoins éclate les nomenclatures de toutes les commandes du batch et construit un tableau des besoins. Pour chaque matière, il affiche le type (Fabric, Trims ou Autre), la quantité nécessaire, la quantité disponible dans tous les entrepôts, le manque, ainsi que ce qui est déjà commandé dans d'autres bons de commande et demandes de matières, et l'éventuel article alternatif utilisé.

Chaque recalcul est aussi inscrit dans un historique des stocks, ce qui permet d'expliquer plus tard pourquoi une quantité a été commandée.

Toutes les actions dans un seul menu
Le planificateur pilote le batch depuis un unique menu Actions : recalculer les besoins, ouvrir la vue complète, envoyer les alternatives aux magasiniers, imprimer la feuille de collecte, saisir une collecte, répartir les manques.

La vue complète rassemble tout le tableau des besoins sur une page imprimable : besoin, stock, manque, quantités en colisage, alternatives, répartition par commande, commandes ouvertes et unités.

Répartir un manque entre les commandes
Quand une matière manque, le stock disponible doit malgré tout aller quelque part. Répartir les Manques affiche, pour chaque matière manquante, toutes les commandes du batch avec leur besoin BOM, le stock qui leur est alloué et ce qui reste à trouver. Le planificateur donne la priorité aux commandes qui partent en premier.

Des articles alternatifs, tracés
Si une matière équivalente est en stock, elle peut remplacer celle qui manque (via les articles alternatifs d'ERPNext). Chaque substitution est enregistrée dans un Alternative Item Log : article d'origine, alternative, quantité et batch.

Un rapport des manques pour tous les batches
Le rapport Shortage list rassemble tout : pour chaque article et chaque batch, les quantités requises, disponibles, commandées et reçues, avec la traçabilité vers le bon de commande, la demande de matières et le colis.

4. Acheter exactement ce qui manque
Lancer PO / MR transforme les manques en documents d'achat, après un aperçu :
- Des bons de commande groupés par fournisseur (le fournisseur par défaut de l'article), avec des alertes sur la quantité minimale de commande et le stock de sécurité, et le dernier prix d'achat prérempli.
- Des demandes de matières pour les matières fournies par le client, afin de lui demander de les expédier, et pour les articles qui n'ont pas encore de fournisseur.
Les documents créés sont rattachés au batch (dans son tableau Documents générés) et aux commandes clients, qui portent aussi les dates prévue et réelle de réception des matières.

5. Les magasiniers : feuille de collecte et prélèvement
Tissus et fournitures ne sortent pas du même magasin. Envoyer aux Magasiniers adresse à chacun, par e-mail, sa propre feuille de collecte : pour chaque matière, la quantité nécessaire, l'emplacement où la prélever et le stock disponible à cet endroit, avec des colonnes pour noter le prélevé et l'écart. Les alternatives sont envoyées à part.

Le prélèvement est ensuite saisi dans l'ERP avec Saisir Collecte : un entrepôt de destination (l'en-cours), une catégorie (Fabric ou Trims), puis pour chaque matière les emplacements à prélever et les quantités, proposées automatiquement et plafonnées au besoin réel. Fabric et Trims sont saisis séparément sur le même batch, et le tout produit une écriture de stock vers l'en-cours.

6. Réceptionner les colis
Au quai, chaque carton reçu est saisi dans une Packing List Received contre son bon de commande ou sa demande de matières : numéro de colis, article, quantité reçue et quantité réellement reçue. Le système calcule le pourcentage réceptionné, puis crée la réception d'achat (Purchase Receipt), ou une écriture de stock pour les matières fournies par le client.

7. Contrôler qui stocke quoi, et où
Certains emplacements sont réservés aux matières d'un client. Chaque entrepôt a donc un client assigné, un statut (Disponible / Réservé) et un mode de contrôle (Désactivé, Avertissement, Strict).

À chaque validation d'une réception, d'une écriture de stock, d'une demande de matières, d'un bon de livraison ou d'un ordre de fabrication, le système vérifie l'entrepôt de destination. Si les marchandises d'un client vont entrer dans l'emplacement d'un autre, il avertit (ou bloque, en mode strict) et inscrit l'événement dans un Warehouse Control Log.

Architecture ERPNext : un cœur intact et deux applications métier

Le cœur d'ERPNext n'est pas modifié. La logique métier de NEDLOG vit dans deux applications Frappe séparées :
textile_productiongère la prise de commande : le moteur d'import Excel et ses templates, le mapping cliquable, le contrôle des totaux, les modèles d'articles, les variantes de taille et les nomenclatures.custom_nedloggère la production et le stock : batches, besoins, manques, alternatives, génération des PO/MR, magasiniers, colisage et contrôle des entrepôts.
Autour d'elles : une soixantaine de réglages (champs affichés ou masqués, séries de numérotation, vues de liste), le plan comptable tunisien et un format d'impression dédié pour les listes de prélèvement. Parce que le code est posé à côté du cœur, ERPNext reste évolutif, comme l'a montré le passage à la v16.
Comment Apeiron a repris le projet ERPNext

Les applications métier ont été développées lors d'une première phase du projet. Quand Apeiron a repris la main, le système était déjà utilisé au quotidien. Pas question de tout réécrire : il faut d'abord comprendre l'existant avant d'y toucher.
1. Audit
Revue en lecture seule du code (les deux applications, environ 20 000 lignes), des trois bases de données, du serveur et des accès. Résultat : une cartographie des 23 types de documents sur mesure, des 60+ modifications de configuration et de chaque personnalisation, plus une liste de risques classés par priorité, avec recommandations.
2. Sécuriser et versionner
Tout le code a été regroupé dans un dépôt Git appartenant à l'entreprise. Une copie complète du système tourne désormais en local sous Docker, e-mails sortants coupés et tâches planifiées à l'arrêt, pour tester sur des données réelles sans rien envoyer aux magasiniers, fournisseurs ou clients.
3. Un plan de tests écrit
Un guide fonctionnel pas à pas couvre 14 tests sur quatre domaines : import Excel (T1–T4), planification de production (P1–P6), réception et stock (R1–R3) et configuration (C1). Il y ajoute six scénarios de stock de bout en bout, avec des quantités rondes que l'on vérifie de tête : stock suffisant ; manque couvert par le client ; manque acheté au fournisseur ; un mélange des deux ; priorité à une autre commande ; remplacement par un article alternatif. Ce guide sert désormais de référence à chaque évolution.
4. Corrections et migration vers ERPNext v16
Les anomalies relevées pendant les tests ont été corrigées dans les applications (par exemple, la quantité proposée à la collecte est désormais plafonnée au besoin réel de l'article). Puis la plateforme est passée de Frappe 15 / ERPNext 15 à Frappe 16.52 / ERPNext 16.51, sur Python 3.14, Node 24 et MariaDB 11.8.
Chaque changement incompatible de la v16 a été confronté au code spécifique :
| Changement v16 | Impact chez NEDLOG |
|---|---|
| Plus de commit en base dans les hooks de documents | Corrigé : le journal de contrôle des entrepôts est enregistré avec le document qui le déclenche |
Les URL /app deviennent /desk | Les anciens liens sont redirigés automatiquement |
| Tri par défaut sur la date de création | Aucune requête ne dépendait de l'ancien ordre |
| Scripts de rapports et de pages exécutés isolément | Rapport des manques vérifié : fonctionne |
| Python 3.14 | Les deux applications compilent sans erreur |
La migration a été répétée sur une copie de la base réelle. Un test automatisé de 21 contrôles (besoins du batch, aperçu PO/MR, répartition des manques, alternatives, rapports, colisage, import Excel de vrais fichiers, contrôle des entrepôts) passe 21/21 en v15 et 21/21 en v16, et les écrans clés ont aussi été vérifiés dans le navigateur.
5. Une application mobile pour le terrain
Apeiron a aussi développé l'application mobile NEDLOG en Flutter, pour iOS et Android. Elle se connecte à ERPNext avec les identifiants habituels de l'utilisateur.

- Accueil : indicateurs (commandes à livrer et à facturer, achats à réceptionner, ordres de fabrication en cours, batches de production ouverts), actions rapides et activité récente.
- Modules : ventes, achats, stock, production (batches de production et colisage compris) et collaboration, avec recherche, filtres par statut et défilement infini.
- Fiches de documents génériques, construites à partir des métadonnées ERPNext : sections, tableaux enfants, liens, validation et annulation.
- Nouvelle commande client en mobilité : client avec devise et liste de prix préremplies, dates, entrepôt, lignes depuis le catalogue ou un scan, tarifées par ERPNext.
- Scan et stock : lecture de codes-barres à la caméra, résolution des codes-barres, numéros de série et de lot, puis stock par entrepôt.
Résultats pour NEDLOG
- Une seule chaîne de documents, du fichier Excel du client jusqu'à l'en-cours. Rien n'est ressaisi, et chaque quantité remonte à sa commande.
- Les manques sont visibles dès la planification de la semaine, article par article et commande par commande, pas sur la table de coupe.
- Des achats justes : bons de commande groupés par fournisseur et demandes au client pour les matières qu'il fournit, générés à partir des besoins calculés.
- Des magasins qui travaillent sur feuille, avec des prélèvements saisis et plafonnés au besoin.
- Une plateforme sous contrôle : code versionné, plan de tests documenté, migration v16 validée et application mobile pour les équipes hors du bureau.
Prochaines étapes : bascule de la production en v16, rôles dédiés (planificateur, acheteur, magasinier) et déploiement de l'application mobile dans les magasins.
Stack technique
| Couche | Technologie |
|---|---|
| ERP | ERPNext 16.51 (Ventes, Achats, Stock, Fabrication, Comptabilité) |
| Framework | Frappe 16.52, Python 3.14, MariaDB 11.8, Redis, Node 24 |
| Applications métier | textile_production (prise de commande), custom_nedlog (production et stock) |
| Mobile | Flutter (iOS et Android), API REST Frappe, scan de codes-barres |
| Environnements | Git, Docker, copie de préproduction complète e-mails coupés, tests automatisés |
Questions fréquentes
ERPNext peut-il importer les commandes clients depuis des fichiers Excel ?
Oui. Chez NEDLOG, une application Frappe sur mesure lit le classeur Excel de chaque client selon un template d'import enregistré, contrôle les totaux et crée la commande client en brouillon. Une nouvelle mise en page s'apprend en cliquant sur les libellés et les valeurs dans un aperçu de la feuille, sans code.
ERPNext gère-t-il les variantes de taille et les nomenclatures d'un vêtement ?
Oui. Chaque modèle est un article modèle avec une variante par taille, et chaque variante a sa propre nomenclature (BOM) avec les quantités de matières de cette taille. Chez NEDLOG, variantes et nomenclatures sont créées ou mises à jour directement depuis le fichier de commande, après un aperçu.
Comment ERPNext calcule-t-il les manques de matières pour la production ?
Un batch de production éclate les nomenclatures de toutes ses commandes en besoins matières et les compare au stock de tous les entrepôts, aux bons de commande ouverts, aux demandes de matières et aux colis attendus. Un manque peut ensuite être réparti entre les commandes, couvert par un article alternatif, acheté à un fournisseur ou demandé au client.
Un ERPNext personnalisé peut-il encore être mis à jour ?
Oui, si les personnalisations vivent dans des applications séparées plutôt que dans le cœur d'ERPNext. Les deux applications métier de NEDLOG sont passées d'ERPNext v15 à v16 après vérification de chaque changement incompatible, et 21 contrôles automatisés passent sur les deux versions.
Apeiron peut-il reprendre un projet ERPNext lancé par une autre équipe ?
Oui. Nous commençons par un audit en lecture seule du code, des bases de données et du serveur, nous plaçons le code sous contrôle de version et rédigeons un plan de tests fonctionnels. Ensuite seulement, nous corrigeons, mettons à jour et faisons évoluer le système.
Ce que montre ce projet
ERPNext peut s'adapter à un métier très spécifique, ici la confection de vêtements de travail sur commande pour des clients européens, sans toucher à son cœur. Et la reprise d'un ERP existant est un projet à part entière : on le comprend d'abord, puis on le sécurise, on le teste, on le corrige et on le met à jour, avant d'ajouter quoi que ce soit.
En savoir plus sur notre offre d'intégrateur ERPNext, notre guide ERPNext et notre article ERPNext pour les usines textiles en Tunisie.