Mode d'emploi — QUOTELUI (ARTISAN ENGINE)

Guide utilisateur de l'application web. Cette plateforme gère toute l'activité d'une entreprise artisanale : clients, chantiers, catalogue, devis (avec PDF et envoi par email), relevés de terrain, et administration. Les données sont isolées par entreprise.

1. Se connecter

1. Ouvrez l'adresse de l'application dans un navigateur (ex. http://localhost:8000/).
2. Saisissez votre adresse email et votre mot de passe, puis Se connecter.

Sur cette page de connexion : liens publics « Confidentialité » (politique RGPD) et « Mentions légales » — accessibles sans compte.

Les comptes sont créés par l'administrateur de l'entreprise (voir §14) ou via la commande de démonstration seed_demo. Les identifiants des comptes de démonstration partagés sont communiqués par l'éditeur sur demande — ils ne figurent ni dans cette documentation, ni dans sa version en ligne (enregistrez-les dans votre gestionnaire de mots de passe).

Comptes de démonstration verrouillés : le mot de passe de ces comptes reste fixe et ne peut pas être réinitialisé (ni depuis Administration → Membres, ni depuis l'espace éditeur). Le verrou est porté par le champ User.is_demo (posé par seed_demo) et appliqué par set_user_password, unique point de réinitialisation de l'application. Ainsi la démo reste utilisable par les futurs testeurs.

Démo isolée pour un prospect : au lieu du compte partagé ci-dessus, créez une entreprise dédiée (métier activé, scénario de projection — chantier daté et adressé, donc navigation Waze/Google Maps au planning, relevé guidé, devis à relancer, admin au vrai email du prospect, mot de passe de première connexion) : manage.py seed_prospect --company "Dupont Menuiserie" --trade menuiserie --email j.dupont@dupont.fr --pdf — 1 prospect = 1 commande (entreprise isolée) ; l'option --pdf génère en plus le document de prise en main personnalisé (docs/QUOTELUI-demo-<entreprise>.pdf : accès, parcours de découverte, métier) à joindre au message d'envoi. Avec --send-email, le PDF est généré et l'email d'accès part immédiatement au prospect (pièce jointe), envoyé depuis la boîte configurée dans Réglages → Envoi (option --smtp-from "Nom entreprise" pour choisir la boîte, sinon la première active) — journalisé dans le journal des emails. Ajoutez --reset pour repartir d'un scénario neuf sans changer les identifiants ; manage.py demo_brief --company … [--password …] régénère le PDF à tout moment. La boîte d'envoi est choisie dans cet ordre : --smtp-from "Nom entreprise", sinon la boîte éditeur (Éditeur → Réglages, si active), sinon la première boîte d'entreprise active. Si le verrou de licences est actif (LICENSE_SECRET), le seed génère automatiquement la clé du métier (valable 1 an) — le module reste actif dans l'administration sans saisie manuelle. Voir docs/deployment.md §3 ter (livraison / SaaS multi-client).

Installer QUOTELUI sur un smartphone (PWA, V2.15)

QUOTELUI est une application web installable (Progressive Web App) :

• Ouvrez l'application dans le navigateur du téléphone, puis choisissez « Ajouter à l'écran d'accueil » (Android/iOS). Un icône s'ajoute et l'app s'ouvre en plein écran comme une application native.
• Un service worker met en cache les fichiers de l'interface et affiche une page « hors-ligne » claire lorsque le réseau est absent (les données authentifiées ne sont jamais mises en cache).
• L'installation et le mode hors-ligne nécessitent HTTPS (ou localhost). Sur le réseau local en http://, le service worker n'est pas activé — utilisez la version déployée en HTTPS (§ déploiement).

2. Choisir son entreprise

Un même compte peut appartenir à plusieurs entreprises.

• En bas de la colonne de gauche (sous le menu), la liste de vos entreprises : cliquez sur une autre entreprise pour y basculer (votre rôle peut y être différent).
• Au-dessous de cette liste, le lien « Changer d'entreprise… » ouvre l'écran de bascule : vous y retrouvez vos entreprises et le bouton « Créer une entreprise » (vous en devenez l'Administrateur ; les réglages par défaut sont déjà configurés — voir §13).

Le rôle affiché dans le menu correspond à celui que vous avez dans l'entreprise sélectionnée (le rôle global ne s'applique que si aucun rôle d'entreprise n'est défini).

3. Rôles et droits

Les actions sont contrôlées côté serveur (masquer un bouton ne suffit jamais). La hiérarchie des rôles est cumulative.

Le menu s'adapte à votre rôle : un Technicien ne voit pas « Clients » ni « Devis », mais voit « Relevés », « Catalogue » et ses alertes.

4. Le menu (colonne de gauche)

En bas du menu : la liste des entreprises, votre nom et votre rôle, et le bouton de déconnexion (↪).

Sur mobile, le menu se replie ; le bouton ☰ en haut à droite l'ouvre.

5. Tableau de bord

Vue d'accueil adaptée au rôle :

• Direction / Manager : chiffre d'affaires des devis, devis en attente, acceptés/refusés, activité récente.
• Commercial : mes devis, devis à relancer (envoyés depuis plus de 30 jours), derniers clients.
• Technicien : mes chantiers, relevés à faire, relevés incomplets, photos manquantes.

Chaque bloc renvoie vers la liste filtrée qu'il annonce (§23) : « CA devis » ouvre les devis envoyés + acceptés avec le Total TTC du filtre affiché, « Montant en attente » les seuls devis envoyés, « Brouillons » tous les états de travail (brouillon, à compléter, en révision, prêt), « Expirent sous 7 j » les devis dont la validité se termine dans la semaine, « À relancer » vos devis envoyés depuis plus de 30 jours, « Relevés incomplets » les relevés sans aucun élément et « Photos manquantes » ceux sans photo — les compteurs affichés sont donc toujours les mêmes d'un côté comme de l'autre. La liste des devis affiche, quand un filtre est actif, son Total TTC ; les puces de statut se combinent avec « Mes devis » (portée commerciale).

5 bis. Statistiques — pilotage commercial (V2.7)

Statistiques dans le menu (Manager+) agrège l'activité commerciale de l'entreprise sur les 12 derniers mois :

• Chiffre d'affaires mensuel : CA HT des devis acceptés par mois (barres cliquables + totaux).
• Transformation : devis envoyés, acceptés, refusés et taux d'acceptation (part des devis qui aboutissent). Seuls comptent les devis envoyés (les brouillons ne faussent pas les ratios).
• Panier moyen : montant TTC moyen d'un devis accepté et d'une facture payée.
• Top produits : les 5 références les plus vendues (CA HT + nombre de ventes), groupées par libellé.
• Top clients : les 5 clients au plus gros CA HT.
• Par commercial : devis envoyés, acceptations et taux par auteur — pour piloter l'activité de chaque commercial.

Détails techniques : les brouillons, modes intermédiaires et devis annulés / expirés sont exclus des CA et des ratios ; les devis refusés sont comptés dans la transformation mais jamais dans le CA.

6. Recherche globale

Une seule zone de recherche interroge tous les objets : clients, contacts, chantiers, devis, produits, documents et relevés.

• Ouvrez Recherche depuis le menu.
• Tapez un mot-clé : les résultats sont regroupés par type d'objet, chacun cliquable vers sa fiche.

6 bis. Alertes (automatiques)

L'application surveille en continu et affiche un badge orange avec le nombre de rappels. Rien à configurer : les règles sont celles du cahier des charges.

Ouvrez Alertes : chaque ligne mène à la liste filtrée correspondante (devis expirés, factures en retard, factures en attente d'acquittement ou rejetées par la plateforme, stock à réapprovisionner, relevés sans photos…), qui affiche exactement le nombre annoncé — le compteur de l'alerte, le KPI du tableau de bord et la liste ont la même définition.

Un devis envoyé dont la validité est dépassée apparaît en rouge dans la liste (badge « expiré ») et sur sa fiche (bandeau « Validité dépassée ») : pour prolonger la validité, remettez-le en révision (nouvelle version) ou relancez-le tel quel (même PDF figé). La commande périodique manage.py expire_quotes (facultative, §48) aligne le statut sur EXPIRE — l'affichage est identique avant et après.

7. Clients

1. Clients → Nouveau client : type (Particulier / Professionnel / Entreprise), coordonnées, adresse de facturation (modèle Address lié en billing_address), n° TVA intracommunautaire (normalisé en majuscules) et SIRET optionnel (Customer.siret, migration customers/0002 — validé : exactement 14 chiffres).
2. Le formulaire s'adapte au type (Alpine) : raison sociale + TVA + SIRET visibles pour Professionnel/Entreprise, prénom/nom pour Particulier (les champs masqués restent dans le DOM et sont donc soumis — aucune perte de données à l'édition).
3. set_billing_address(customer, …) crée l'adresse à la demande, la met à jour sur place (pas de doublon) et la retire si tous les champs sont vides.
4. Le snapshot figé du destinataire (_snapshot_customer) emporte address / vat_number / siret : les PDF de devis et de facture affichent « TVA : … » / « SIRET : … » quand renseignés — figés à l'envoi, jamais rétro-impactés sur les versions antérieures.
5. La fiche client résume ses coordonnées et liste ses chantiers et devis.

La gestion des clients est réservée au Commercial et au-dessus.

8. Chantiers (projets)

Un chantier est un projet rattaché à un client : lieu d'intervention, dates.

1. Chantiers → Nouveau chantier : client, nom, adresse du site.
2. La fiche chantier liste les devis et les relevés associés.

9. Catalogue

Le catalogue est entièrement dynamique : chaque type de produit (fenêtre, chaudière, radiateur…) possède ses propres attributs (largeur, débit, puissance, matériau, énergie…).

• Catalogue → Nouveau produit : choisissez le type, saisissez le nom, le prix de vente HT et les attributs proposés (obligatoires signalés).
• Catalogue → Importer un catalogue (Manager+) : importez un fichier CSV fournisseur pour créer/mettre à jour des produits en masse. Colonnes reconnues : nom, reference, type, unite, prix_achat, prix_vente, ref_fournisseur, description (en-têtes tolérants aux accents et à la casse ; séparateur ; ou ,). Un modèle CSV est téléchargeable. Options : mettre à jour les produits existants (même référence), créer les types de produits manquants, et enregistrer le prix d'achat chez un fournisseur choisi. Un rapport indique les créations, mises à jour et erreurs par ligne.
• Catalogues de démonstration (un par métier) : depuis le Catalogue, chargez le pack du métier qui vous intéresse (Menuiserie, Plomberie, Chauffage, Électricité, Couverture, Carrelage, Peinture, Maçonnerie) pour découvrir l'application sans saisir vos produits : chaque pack crée quelques produits fictifs (prix indicatifs, badge « démo ») dans votre catalogue, avec leurs attributs, conditionnements et pertes. Recharger un pack met à jour ses produits de démonstration sans jamais toucher aux vôtres (rapprochement par référence DEMO-…) ; « Retirer » les archive (les devis déjà établis restent intacts). Équivalent en ligne de commande : manage.py seed_catalog_demo --company … [--module …] (ou --remove).
• Correspondance de colonnes (fichiers fournisseurs aux en-têtes inhabituels) : « Analyser et associer les colonnes » lit le fichier sans rien écrire, affiche un aperçu des premières lignes et propose chaque colonne à associer à un champ (désignation, référence, type, unité, prix d'achat/vente, conditionnement, perte, minimum, réf. fournisseur, nature, description) — la détection automatique est pré-remplie et corrigeable, les colonnes non mappées sont ignorées. « Confirmer l'import » applique la correspondance. Le bouton « Importer directement » conserve la détection automatique (fichiers déjà conformes).
• Chaque produit affiche ses attributs et son prix.

Catalogue ≠ stock : le catalogue est un référentiel d'offre (ce que vous pouvez proposer, y compris des produits fournisseurs, avec leurs prix). Il ne représente pas votre inventaire : pour suivre ce que vous détenez réellement, utilisez le Stock (§13 quater), qui ne suit que les produits que vous choisissez de suivre.

Les données de base (types, attributs, champs de relevé) sont injectées automatiquement à l'activation d'un module métier (§14 bis). Vous pouvez aussi créer vos propres types de produits sans aucune programmation.

10. Devis

10.1 Création

1. Devis → Nouveau devis. Le numéro est attribué automatiquement (DEV-2026-0001, séquence propre à l'entreprise).
2. Renseignez l'état brouillon : client, chantier éventuel, date de validité (proposée automatiquement d'après les réglages).
3. Ajoutez des lignes : soit depuis un produit du catalogue (attributs et prix repris), soit en saisie libre (libellé, prix unitaire HT).
4. chaque ligne porte sa quantité, son prix unitaire HT et son taux de TVA (choisi ligne par ligne — il est figé à l'envoi). 3 bis. Ajout guidé par métier, façon relevé : sous le bouton « Ajouter une ligne »,
5. 1. Métier : chips des modules activés (Menuiserie, Plomberie…) ;
6. 2. Type : chips des types de ce métier (Fenêtre, Parpaing…) puis, si des produits existent, chips des produits (ou « Pas au catalogue ») ;
7. 3. Caractéristiques du type : dès qu'un type est choisi, ses schémas s'affichent comme au relevé guidé (§11.2) — dimensions (H, L, Ø avec l'unité du schéma) et sous-choix (matériau, vitrage, ouverture, coloris…), pilotés par les données du catalogue ;
8. les caractéristiques du type sont repliées par défaut (bloc « Caractéristiques du type (optionnel) ») : le formulaire reste court, on les ouvre seulement si l'on veut préciser le chiffrage ;
9. les valeurs saisies sont validées par le schéma du type (choix autorisés, bornes min/max de dimensions, type de valeur) : une dimension hors limites catalogue ou un choix invalide est refusé avec un message précis — le moteur n'accepte aucune donnée invalide ;
10. bouton « Proposer un prix » : le prix, la quantité et l'unité sont recalculés côté serveur, dans cet ordre : moteur tarifaire (grille fabricant — première taille ≥ —, simulation ou API) pour les menuiseries, puis règle de pose du type (quantité déduite de la surface/dimension saisie), puis prix catalogue du produit choisi. Aucun tarif connu : message explicite, le prix reste à saisir (jamais un montant inventé). Les montants saisis ou pré-remplis acceptent la virgule française et les séparateurs de milliers (« 1 234,56 »). Chaque ligne reste modifiable ensuite (libellé, prix, quantité, remise).
11. Remises :
12. par ligne : un pourcentage ou un montant fixe (jamais les deux) ;
13. globale : pourcentage ou fixe, appliquée sur l'ensemble du devis. Les totaux (HT, TVA par taux, TTC) se recalculent en continu (arrondis à 2 décimales).
14. Actions par ligne (tableau des lignes, tant que le devis est modifiable) : Modifier (libellé, description, quantité, prix unitaire HT — saisie en place), Remise (% ou € fixe sur la ligne) et Supprimer (confirmation). Le service update_line recalcule les totaux ; la TVA figée et le produit lié restent intacts. Les mêmes opérations existent côté API (set_line_discount, remove_line).
15. Main-d'œuvre (au temps) : bloc dédié sous le tableau des lignes :
16. taux horaire (pré-rempli par Réglages → Entreprise →« taux horaire main-d'œuvre », modifiable ligne par ligne) ;
17. durée totaleoudurée par unité × nombre d'unités ;
18. majoration éventuelle (nuit, dimanche, urgence) appliquée au prix unitaire (jamais un coefficient caché dans le total) ;
19. durée minimale facturée appliquée à la quantité. La ligne produite est une ligne de devis ordinaire (prix unitaire × quantité = total HT), donc traitée comme les autres par la TVA, les remises, la facturation et l'export comptable.
20. Alerte « le tarif a changé » : tant que le devis est modifiable, si le prix d'une ligne ne correspond plus au tarif actuel (règle de pose du type, sinon prix catalogue du produit), la ligne affiche une note « Tarif actuel : 60,00 € (règle « … ») — la ligne est à 50,00 € ». C'est purement informatif : aucun montant n'est modifié automatiquement.

10.2 États et cycle de vie

Le devis suit une machine d'état stricte :

BROUILLON → A_COMPLETER → EN_REVISION → PRET → ENVOYE → ACCEPTE / REFUSE / EXPIRE
                                              ↘ (révision) → nouvelle version

Règle d'or : les états modifiables sont BROUILLON, A_COMPLETER, EN_REVISION, PRET. Dès l'envoi, le contenu est gelé (aucune modification silencieuse) ; pour le changer, repassez en EN_REVISION : une nouvelle version est créée (v1 → v2 → …), les versions précédentes restent consultables.

À l'envoi, remarque : l'email du destinataire et les coordonnées de l'entreprise sont pris dans la version figée, jamais dans les données vivantes — c'est une garantie de traçabilité.

10.3 PDF et email

Après envoi (contenu figé) :

• PDF : téléchargez le devis formaté (en-tête entreprise issue des Réglages, bloc chantier, validité, conditions, TVA, pagination).
• Email : envoyez le devis au client, PDF en pièce jointe, avec un courriel reprenant les coordonnées de l'entreprise (adresse, tél, site). Chaque envoi est journalisé (succès ou erreur).

Tant que le devis est en brouillon ou en état intermédiaire, le bouton PDF n'apparaît pas : son contenu n'est pas encore figé (§10.4). Une fois envoyé, le bouton devient disponible. Si l'URL du PDF est saisie directement sur un devis non envoyé, un message l'indique (aucune erreur serveur).

10.4 Versions

Sur la fiche du devis, l'historique des versions (v1, v2…) est consultable : chaque version montre le contenu exact envoyé à ce moment-là.

10.5 Quantitatif / liste d'achat

Bouton « Quantitatif / achat » sur la fiche du devis : le détail des quantités d'achat pour préparer les commandes fournisseurs — distinct du prix de vente.

Pour chaque ligne liée à un produit :

1. quantité théorique : la quantité de la ligne, convertie si le métier fournit une règle — aujourd'hui :
2. peinture : surface × couches ÷ rendement (m²/L) → litres ;
3. carrelage : pièces × surface de la pièce (attribut « format », ex. 60x120 → 0,72 m²/pièce) → m² ;
4. maçonnerie : surface de mur (m²) × éléments au m² (attribut nombre_au_m2, joints compris) → nombre de blocs ; ou surface × épaisseur (mm) → volume de béton (m³) pour une dalle ;
5. couverture : surface de toiture × recouvrement (attribut recouvrement, éléments/m² posés) → nombre de tuiles / ardoises. Sans la donnée métier (rendement, format, éléments/m², épaisseur, recouvrement), la quantité du devis est conservée et la raison s'affiche : aucune conversion inventée ;
6. perte / chute du produit (%) appliquée à la quantité d'achat — jamais à la quantité facturée au client ;
7. conditionnement (contenu d'un conditionnement, ex. 1,44 m² par carton, 2,5 L par pot) : le nombre de conditionnements est arrondi au supérieur (un conditionnement partiel n'est pas vendu) ;
8. minimum de facturation du produit : la ligne est facturée au minimum si la quantité est inférieure.

Kits / ensembles : un produit composé (voir fiche produit → « Composition (kit) ») est éclaté dans la liste d'achat — chaque composant apparaît avec sa quantité (× quantité du kit), ses propres pertes et conditionnements, et le kit lui-même n'est pas commandé. Une fourniture présente à la fois dans un kit et sur une ligne séparée est signalée « déjà dans un kit » pour éviter la double commande (spec §5.2). Idéal pour une salle de bain complète, un tableau électrique ou un ensemble de chauffage.

Le tableau affiche théorique / perte / avec perte / conditionnements / à acheter / facturé, puis la liste des commandes à prévoir, agrégée par produit. Les lignes sans produit (prestations libres) sont listées mais n'entraînent aucune commande. Aucun montant ni quantité n'est inventé : sans rendement renseigné, la quantité de la ligne est conservée et la raison s'affiche.

Conformité comptable : les pertes, conditionnements, kits et conversions métier ne concernent que les quantités d'achat. La quantité facturée reste celle des lignes du devis (prix unitaire × quantité), et les exports comptables (export factures, synoptique annuel, déclaration de TVA, bilan recettes/dépenses) ne contiennent que des montants facturés, ventilés par taux de TVA — jamais une quantité d'achat. Modifier un tarif produit ou un conditionnement après l'établissement d'un devis/facture ne change aucun montant déjà établi.

Ces paramètres se renseignent sur la fiche produit (formulaire de création) ou à l'import catalogue (colonnes conditionnement, unite_achat, perte, minimum). La composition d'un kit se gère sur la fiche du produit : section « Composition (kit) » → choisir un composant + sa quantité (le produit devient alors de nature composé).

10 bis. Factures (V2.1)

La facturation est le prolongement naturel d'un devis accepté.

10 bis.1 Création

Menu Factures → + Nouvelle facture :

• Depuis un devis accepté (recommandé) : choisissez le devis ; la facture reprend automatiquement client, chantier, lignes, prix, TVA et remises. Vous recevez un brouillon avec numéro FAC-ANNEE-NNNN (séquentiel par entreprise).
• Facture libre : choisissez client/chantier, puis ajoutez les lignes manuellement (mêmes règles que le devis : prix HT, quantité, TVA figée par ligne, remise ligne et remise globale en % ou en euros).

10 bis.2 États et cycle de vie

BROUILLON → PRETE → ENVOYEE → EN_RETARD → PAYEE
              ↘ (retour)              ↘
BROUILLON ⇄ PRETE                     ANNULEE (à tout moment)

Règle d'or : identique au devis. Editable uniquement en BROUILLON/PRETE. Dès ENVOYEE, le contenu est figé (PDF, totaux, TVA, destinataire). Pour la modifier, annulez et créez une nouvelle facture — c'est la garantie de traçabilité d'un document financier.

10 bis.3 PDF, email et relances

Après envoi : boutons PDF (téléchargement du document figé, mention d'échéance, numéro du devis d'origine) et Envoyer par email (PDF en pièce jointe, destinataire = la version figée, jamais le client vivant). Chaque envoi est journalisé (Emails) et tracé dans l'historique.

Le bouton PDF n'apparaît que lorsque le contenu est figé (dès ENVOYEE) : tant que la facture est en brouillon ou prête, elle n'a pas de PDF associé (même règle que le devis, §10.3).

Une facture EN_RETARD est mise en évidence (bandeau « RAPPEL » sur le PDF). La bascule ENVOYEE → EN_RETARD est automatique lorsque la date d'échéance est dépassée (commande/boucle de maintenance).

10 bis.4 Relance de paiement (V2.2.1)

Pour une facture Envoyée ou En retard, le bouton Relancer (fiche ou liste de factures) envoie au client le même PDF figé avec l'objet « Relance de paiement : FAC-… ». La date de dernière relance est affichée sur la fiche, et l'envoi est journalisé dans Emails (historique de relances).

Si la facture n'est pas EN_RETARD alors que l'échéance est passée, la commande périodique s'en charge :

À planifier quotidiennement côté serveur (cron / systemd timer). Seules les entreprises actives sont affectées ; aucun ré-envoi intempestif grâce au délai.

10 bis.5 Export comptable (V2.3)

Un point d'export réunit les documents destinés au comptable, accessible depuis Factures → Export comptable :

Règles : les factures annulées sont comptées mais exclues des montants (coches * dans le PDF) ; les montants sont en Decimal arrondis à deux décimales ; chaque ligne figeant sa TVA, une modification ultérieure d'un taux ne change pas l'historique.

Périmètre : cet écran ne montre que le chiffre d'affaires émis par l'application (factures QuoteliL). Un bandeau le rappelle et renvoie vers le bilan complet (Documents tiers → Bilan, §18 quater) qui ajoute les pièces importées et les factures fournisseurs — le calcul des factures est partagé (annual_data) : sans pièce importée, le total TTC de l'export est égal au sous-total « factures » des recettes du bilan. Sélecteurs d'année alignés sur les deux écrans (helper _export_years()), liens croisés dans les deux sens.

10 bis.6 Déclaration TVA (V2.16)

Depuis Factures → Déclaration TVA, sélectionnez une période (mois ou trimestre) pour afficher la synthèse :

• TVA collectée : total TVA des factures émises (ENVOYEE / EN_RETARD / PAYEE) sur la période, ventilée par taux.
• TVA déductible : total TVA des commandes fournisseurs reçues (CONFIRMEE / PARTIELLEMENT_RECUE / RECUE) sur la période, ventilée par taux.
• TVA nette à payer = collectée − déductible.

Les factures annulées et les commandes annulées / brouillon sont exclues. Les taux sont ceux figés sur chaque ligne au moment de l'émission (§9) — la modification ultérieure d'un taux ne change pas cet historique.

Exports : - CSV : bouton « CSV » — format comptable (;, UTF-8 avec BOM). - PDF : bouton « PDF » — document A4 synthétique avec les deux tableaux et la TVA nette en encadré.

10 bis.7 Facture électronique — plateforme de dématérialisation (V3.1)

Réglages → Facture électronique connecte QUOTELUI à la plateforme de dématérialisation (PDP) choisie par l'entreprise :

• Vous créez vous-même votre compte auprès de la plateforme (gratuit en dessous de 1 000 factures/mois), puis vous y entrez vos clés API.
• Point d'appel API (https://…), identifiant expéditeur, case activée, et soumission automatique à l'envoi (best effort : un échec est tracé mais ne bloque jamais l'envoi de la facture).
• Mode bac à sable : la plateforme dispose d'un environnement de tests. Cochez la case pour y basculer : chaque transmission y est alors figée « bac à sable » (badge orange sur la fiche facture, mention en tête de la page de réglages) — un essai ne peut jamais se faire passer pour une facture réelle. Décochez pour repartir en production ; l'historique garde l'environnement actif au moment de l'envoi, jamais le choix courant.
• Authentification — deux modes (case Authentification) :
• Clé API (en-tête Bearer) : la clé vous est remise par la plateforme. Elle est chiffrée au repos, jamais réaffichée, et la rotation est automatique (« Ajouter / remplacer » révoque l'ancienne).
• OAuth 2.1 — client credentials : vous entrez le client_id et le client_secret de votre application. Ils sont chiffrés au repos, jamais réaffichés (un champ vide les conserve). L'application obtient seule le jeton d'accès, le garde ~30 minutes puis le renouvelle automatiquement : aucune saisie quotidienne. Aucune clé API n'est nécessaire dans ce mode.
• Contrat de la plateforme (case Contrat) : ce sont les chemins que l'application appellera réellement.
• Contrat générique : GET {base}/health (test de connexion), POST {base}/invoices (soumission), GET {base}/invoices/{id} (acquittement).
• SUPER PDP (v1.beta) : POST {base}/oauth2/token (si OAuth), GET {base}/v1.beta/companies/me (test de connexion — renvoie aussi votre dénomination sociale, preuve que les identifiants sont bons), POST {base}/v1.beta/invoices avec le document XML brut, puis GET {base}/v1.beta/invoices/{id} pour l'acquittement. Saisissez l'URL de base (SUPER PDP : https://api.superpdp.tech, déjà pré-remplie) — l'application ajoute elle-même les chemins. Vous pouvez même coller une URL complète (…/oauth2/token, …/health, …/invoices, …/v1.beta) : la fin inutile est retirée automatiquement, jamais de chemin en double. En cas de 404, le message affiche l'URL exacte testéeet la liste des chemins réellement appelés : c'est presque toujours une URL de base erronée.
• Clés API / identifiants : bouton Tester la connexion — succès = la dénomination retournée par la plateforme et son identifiant de session (« … — identifiant 403834084 ») : c'est cet identifiant qui sera comparé au SIREN des factures, une clé encore liée à une autre société (démo) se repère donc ici, avant la moindre soumission ; 401/403 en mode clé = vos clés ont changé côté plateforme (rotation) ; 401/403 en mode OAuth = le client_id ou le client_secret est erroné ou révoqué.
• File d'attente de transmission : comme la soumission n'attend pas la plateforme, la page affiche l'état réel — « N factures en attente de transmission » (acquittement non reçu) et « N factures en échec » (à re-soumettre). Ces deux informations remontent aussi dans Alertes (niveau orange / rouge).
• Règles de conformité : la page affiche le pack de règles actif (profil Factur-X, annuaire, contrat d'appel), la version appliquée, son origine (livrée avec la plateforme / mise à jour le …) et, s'il en existe une plus récente, une mention « disponible » renvoyée à la prochaine mise à jour de la plateforme. Aucune commande n'y est affichée : elle ne sert rien à l'artisan. Côté opérateur (documentation docs/deployment.md §5 bis, jamais dans l'interface) : manage.py update_compliance installe le pack sans redéploiement de l'image (données seules, contrôle sha256) et manage.py check_updates annonce une nouvelle version de l'image. Hors-ligne : cache local, sinon pack intégré à l'image.

Qui pilote la connexion ? Deux options :

• L'artisan (par défaut) : il crée son compte auprès de la plateforme et gère la page Réglages → Facture électronique (ADMIN).
• L'éditeur : depuis son espace (Éditeur → Facture électronique), il configure la connexion société par société et coche « gérée par l'éditeur ». La page de l'artisan devient alors lecture seule — il garde le journal des transmissions et les alertes, seule l'éditeur modifie et teste. Un bouton « Toutes les sociétés » liste l'état de chaque connexion (prête / non prête / non configurée).
• L'accord de l'artisan est obligatoire : tant qu'il n'a pas coché « J'autorise mon éditeur à gérer ma facture électronique » sur sa page (Réglages → Facture électronique), la connexion affiche Non prête et aucune facture n'est transmise — ni automatiquement, ni manuellement. L'accord est horodaté et journalisé, et l'artisan le retire en décochant ; l'éditeur voit « accord manquant » ou « donné le … » sur sa liste de sociétés.
• L'artisan peut reprendre la main à tout moment : le bouton « Configurer moi-même ma connexion » (sa page, en mode lecture seule) débranche l'éditeur — accord retiré, changement de pilote tracé au journal d'audit — et rouvre le formulaire complet : il y saisit son propre compte PDP (URL, identifiants, clés, bac à sable). Si l'éditeur reprend ensuite la gestion depuis son espace, un nouvel accord de l'artisan est de nouveau exigé.
• Ce qui reste propre à chaque société : le SIRET et les coordonnées (case Réglages → Entreprise) — ils ne sont jamais dans un module et ne sont jamais partagés entre sociétés. Le nombre de modules activés (menuiserie, plomberie…) ne change rien à la facturation : une connexion par société, pas un champ par module.
• SIRET manquant : un avertissement s'affiche sur les deux pages, car le document partirait sans identifiant vendeur et serait rejeté par la plateforme.
• Identité publiée = SIREN : le document (BT-30) porte le SIREN à 9 chiffres déduit du SIRET de l'entreprise — c'est l'identifiant que la console SUPER PDP affiche lors de l'ajout d'une entreprise (France — SIREN), jamais le SIRET à 14 chiffres. Avant chaque soumission, l'application relève la société réellement liée aux clés API (companies/me) : en cas d'écart elle s'arrête avec un message citant les deux identifiants, sans même appeler la plateforme.
• Document = profil EN 16931 (SUPER PDP) : le bac à sable refuse tout autre identifiant de profil (BT-24) sur un dépôt XML — l'application publie urn:cen.eu:en16931:2017 et porte par la même occasion tous les contrôles français du schéma (notes légales PMT/PMD/AAB, cadre de facturation BT-23, SIREN avec schéma 0002, ventilation TVA en euros). Tout est automatique : un rapport validation_reports de la plateforme confirme is_valid avant l'envoi réel.
• Adresses de réception (annuaire Peppol) : la plateforme vérifie que l'adresse du destinataire existe dans son annuaire avant tout dépôt. L'application lit votre entrée principale (identifiant participant, format 0225:…), enregistre automatiquement le client sous votre préfixe (suffixe = son SIREN) et n'attend que quelques secondes que l'entrée devienne active. À la première facture d'un client, si la plateforme met un instant à la voir, une reprise automatique est faite (une seule) ; en cas d'échec, le refus « receiver address … does not exist » se résout en relançant Soumettre à la plateforme. Les adresses e-mail (schéma EM) ne servent plus qu'en repli si l'annuaire est injoignable.

Passer du bac à sable à la production

Le mode bac à sable et le mode production utilisent la même adresse d'API : c'est la clé (ou le couple client_id/client_secret) qui détermine l'environnement (doc SUPER PDP — « La clé API utilisée détermine si l'API est utilisée en mode production ou bac à sable »). Aucun changement d'URL, aucun redéploiement.

Avant de basculer, côté SUPER PDP (console) :

1. créer une application de production et noter ses identifiants ;
2. inscrire l'entreprise par son SIREN (vérification d'identité du représentant légal et de l'entreprise) ;
3. renseigner le régime de TVA de l'entreprise (nécessaire au calendrier de déclaration de l'e-reporting) ;
4. s'assurer que les SIREN de vos clients professionnels existent dans l'annuaire réel (un client non inscrit est refusé « destinataire inconnu de la plateforme » — il doit s'inscrire auprès du SIE, cf. FAQ SUPER PDP).

Dans l'application (Réglages → Facture électronique) : saisir les identifiants de production, décocher « Mode bac à sable », activer la connexion, puis cliquer Tester la connexion (la dénomination affichée doit être la vôtre en production). Les adresses d'annuaire deviennent alors les adresses réelles : l'adresse du destinataire est son SIREN (0225:SIREN) et l'application n'inscrit jamais de ligne d'annuaire pour un client. Les factures déjà transmises en bac à sable restent tracées comme telles (badge « bac à sable »).

Sur la fiche d'une facture (figée / envoyée) : un bloc « Facture électronique (PDP) » liste les soumissions avec le retour de la plateforme : SOUMISE / EN_ATTENTE / ACCEPTEE / MISE_A_DISPOSITION (mise à disposition chez le destinataire) / REJETEE / ECHEC, plus l'identifiant message PDP, la date de soumission, un badge « bac à sable » si la transmission a eu lieu en environnement de tests, et le détail (couleur : vert = accepté, violet = remis au destinataire, rouge = rejet/échec, ambre = en attente) avec :

• Soumettre à la plateforme — génère le document Factur-X (validé contre le schéma officiel) depuis le contenu figé, y ajoute le PDF si le contrat de la plateforme l'attend, puis envoie (capacité invoice.send) ;
• Actualiser — interroge la plateforme sur l'acquittement (capacité invoice.view).
• Statuts récupérés automatiquement : SUPER PDP ne fournit pas encore d'appels entrants (« webhooks » — annoncés en cours de développement de leur côté) ; le mécanisme officiel qu'ils documentent (chapitre « Synchronisation ») est l'interrogation périodique de GET invoice_events avec un curseur d'identifiants strictement croissants : aucun événement ne peut se perdre, aucun n'est traité deux fois. C'est la commande serveur manage.py pdp_refresh (planifiée en cron par l'opérateur — docs/deployment.md §11) qui la pilote pour toutes les sociétés prêtes ; la page de réglages affiche « Statuts récupérés le … ». Le bouton Actualiser reste disponible pour un contrôle immédiat, facture par facture.

Lire un refus de la plateforme — le message affiché indique la conduite à tenir :

• « Destinataire inconnu de la plateforme » : le client n'est pas reconnu par la plateforme. Vérifiez sa raison sociale et son SIRET sur la fiche client (faites-le enregistrer par la plateforme si besoin), puis relancez Soumettre à la plateforme. Si l'erreur persiste, vérifiez aussi le point d'appel API dans Réglages → Facture électronique.
• « Plateforme momentanément indisponible » : rien à corriger côté facture — relancez la soumission quelques instants plus tard.
• « nouvelle clé » : vos clés API ont changé côté plateforme → ajoutez-en une nouvelle (la précédente se révoque seule), puis relancez.
• « Identifiants OAuth refusés » : le client_id ou le client_secret n'est plus valable côté plateforme → corrigez-les dans Réglages → Facture électronique (le jeton est renouvelé tout seul au prochain appel).
• « La plateforme attend l'identifiant … » (contrôle avant soumission) : la société liée à vos clés API ne correspond pas au SIREN de la facture. Soit les clés appartiennent encore à une société de démonstration — créez votre application sur votre société dans la console de la plateforme (menu Clés API) puis remplacez-les ; soit le SIRET de l'entreprise est à corriger dans Réglages → Entreprise (une facture déjà figée se remplace par une facture de remplacement).
• Refus fr:213 avec des règles BR-10 / BR-11 (contrôle de conformité EN 16931, après dépôt) : la facture électronique exige l'adresse postale complète du client (adresse de facturation de sa fiche client, pays compris) — c'est la cause la plus fréquente. Complétez la fiche client, puis créez une facture de remplacement : le contenu d'une facture déjà envoyée est figé et ne se corrige pas. Les autres règles BR-… du même refus désignent une donnée obligatoire manquante dans le document ; la soumission apparaît en Rejetée (rouge) et le détail BR-… s'affiche dans le tableau des soumissions de la fiche facture (texte complet au survol).
• Le même refus en acquittement (bouton Actualiser) ne veut dire qu'une chose : le message n'est pas encore consultable — réessayez plus tard.

La colonne « retour » affiche, sous le message, la réponse telle quelle de la plateforme (plateforme : …) : c'est l'état déclaré par la plateforme, même si notre vocabulaire ne le connaît pas encore (codes métier propres au fournisseur).

API : POST /api/invoices/{pk}/electronic/ et POST /api/invoices/{pk}/electronic-status/.

10 bis.8 Factures aux particuliers (B2C) — e-reporting

La réforme 2026 n'impose la facture électronique (échange via une plateforme agréée) qu'aux opérations B2B domestiques. Les ventes à des particuliers (ou à des clients étrangers) relèvent de l'e-reporting : les données de transaction et de paiement sont transmises à l'administration.

Ce que fait la plateforme agréée pour vous (contrat SUPER PDP, article « E-reporting ») : les factures B2C sont déposées comme les factures B2B ; la plateforme ne les achemine à personne (un particulier n'a pas de plateforme) et en extrait automatiquement l'e-reporting. Deux conditions :

1. le document porte la note BAR = B2C — l'application l'ajoute automatiquement dès que le client figé n'a pas d'identifiant fiscal français exploitable (SIREN/SIRET) ;
2. les données de paiement viennent du message de cycle de vie « Encaissée » (fr:212), que l'application envoie au passage de la facture en « payée » (aucune action de votre part).

Ce que fait l'application :

• La facture est transmise (bouton Soumettre à la plateforme, soumission automatique à l'envoi, API) : pas d'exclusion, pas d'erreur — la fiche affiche simplement « Client particulier ou hors France : la facture est transmise pour l'e-reporting ».
• Cadre de facturation homogène (BT-23) : pour une facture à un particulier, la plateforme exige des biens seuls ou des services seuls — jamais une facture « mixte ». La nature vient des produits du catalogue utilisés sur les lignes (matériel = bien ; service, main-d'œuvre, forfait = service). Une facture à un particulier mêlant matériel et prestation est refusée avant l'envoi avec ce message : renseignez la nature des lignes (ou utilisez des produits du catalogue), ou établissez deux factures.
• Adresse de l'acheteur : le document porte toujours l'adresse postale du client — au minimum son pays — car le schematron français l'exige (règles BR-09/BR-10/BR-11). Renseignez l'adresse de facturation du client (fiche client) pour un document complet ; sans elle, le pays (France par défaut) est publié.
• Détection = le document figé : le client doit porter un SIREN (9 chiffres déduits de son SIRET) pour rester dans le champ B2B. Un professionnel français sans SIRET saisi est donc traité comme un particulier (note B2C) : complétez sa fiche, puis établissez une facture de remplacement (le contenu d'une facture envoyée est figé).
• Paiement déclaré : le passage en « payée » envoie le statut fr:212 (montant TTC par taux de TVA, à la date d'encaissement) ; la fiche facture l'affiche (« Encaissement déclaré à la plateforme le … »). Une panne de la plateforme ne bloque jamais l'encaissement (l'échec est tracé dans le journal et la resoumission reste possible).
• Ventes sans facture (caisse d'un salon de coiffure, par exemple) : l'export ci-dessous prépare les données ; leur transmission utilise les routes dédiées de la plateforme (b2c_transactions, b2c_payments).

bash python manage.py e_report --company 1 # mois courant python manage.py e_report --company 1 --from 2026-10-01 --to 2026-10-31 python manage.py e_report --company 1 --out /tmp/ereporting.json

Sortie JSON : transactions (jour d'émission × taux de TVA → HT, TVA, nombre de factures) + payments (jour de paiement × taux → TTC) pour les seules factures B2C émises (Envoyée / En retard / Payée — hors Annulée et hors brouillons). Montants en texte à 2 décimales (jamais de flottants), période par défaut = mois en cours, entreprises actives uniquement. - Ne pas déclarer deux fois : pour les factures B2C émises dans QUOTELUI, l'e-reporting est fait par la plateforme — n'envoyez pas en plus les données de e_report pour ces mêmes ventes (réservé aux ventes sans facture).

11. Relevés de chantier

Le relevé (métier) est le document de terrain réalisé par le technicien avant élaboration du devis. Il est cloisonné par métier : Survey.module_key (choisi à la création, parmi les modules activés) impose côté serveur les types/produits acceptés — un relevé menuiserie refuse un produit plomberie, web comme API. Les champs proposés dépendent du métier car ils viennent des schémas d'attributs du catalogue (ProductType → AttributeSchema) :

• Restreint au métier : types, produits et options listés pour le seul module du relevé ; le libellé libre n'existe plus sur un relevé cloisonné.
• Choix guidé : CHOICE → boutons radio, BOOLEAN → Oui/Non, numérique → saisie nombre, TEXT/DATE en dernier recours.
• Dimensions selon la géométrie : les attributs numériques en unité de longueur/surface montent dans le bloc compact avec libellés courts, dans l'ordre hauteur × largeur (hauteur→H, largeur→L, diametre→Ø, mm déjà posés) ; les types ronds (gouttière, fenêtre ronde) n'exposent que Ø.
• Stockage : mesures numériques → Measurement (clés canoniques, quantité du devis V2.6 intacte), reste → CustomField, produit → SurveyItem.product et SurveyItem.product_type. Obligatoires vérifiés ; l'ajout est atomique (un refus ne laisse aucun élément).

11.1 Cycle de vie

TERRAIN → VALIDE → BUREAU → EN_VERIFICATION → CLOTURE
   ↕          ↕         ↕
 retours possibles (VALIDE → TERRAIN, BUREAU → VALIDE)

Règle : seul un relevé au TERRAIN est modifiable. Les retours permettent de renvoyer un relevé en arrière sans jamais perdre son historique.

11.2 Composer un relevé (saisie guidée)

1. Relevés → Nouveau relevé : chantier, date prévue, métier du relevé (module activé ; obligatoire dès qu'un module l'est). Un relevé déjà rempli ne peut plus changer de métier.
2. Ajouter un élément, au choix :
3. Ajout rapide d'un produit du catalogue (le plus courant au terrain) : sélectionnez le produit dans « Ajouter un produit du catalogue » puis « + Ajouter le produit ». Le type est déduit du produit, les caractéristiques connues du catalogue sont reprises : aucune dimension à saisir, aucun prix à saisir — les valeurs obligatoires encore vides restent simplement « à compléter » sur la fiche de l'élément, à votre rythme. Le relevé relève, le devis chiffre ;
4. saisie guidée : type du métier (chips) → produit du catalogue (chips, pré-remplissant les attributs) ou « Pas au catalogue » → dimensions + caractéristiques guidées (les champs obligatoires du type sont alors exigés). Repère facultatif.
5. Côté terrain, reste une saisie manuelle : les dimensions (et les rares attributs TEXT). L'unité vient du schéma : jamais d'unité à taper.
6. Édition en place : sur la fiche de l'élément, chaque dimension (H, L, Ø… une par mesure du type) s'affiche pré-remplie avec son libellé court et l'unité du schéma — on corrige la valeur, Enregistrer (service update_dimensions, refus des clés inconnues, champ vide = inchangé). Aucune mesure libre sur un relevé cloisonné. Le formulaire Mesures libres (libellé + valeur + unité, unité résolue et créée à la demande, clé facultative — §11.3) reste réservé aux relevés génériques.
7. Photos (format/taille validés, minutaires) et Observations.
8. Statut TERRAIN → … → CLOTURE.

Les relevés génériques (créés sans module, data legacy ou API) gardent le comportement historique : libellé libre, aucun filtre.

La suppression est gérée en « corbeille » : un relevé supprimé reste traçable dans l'historique et restauré si besoin par l'administrateur (il garde son numéro).

11.3 La clé d'une mesure — à quoi elle sert

Chaque mesure possède un libellé (« Hauteur baie ») et une clé technique : un mot court en minuscules, sans accents ni espaces (ex. largeur, hauteur, surface).

• Saisie guidée (relevé cloisonné) : la clé est toujours celle de l'attribut du type (largeur, hauteur, diametre) — aucune saisie ; la quantité du devis (V2.6) retrouve la mesure sans ambiguïté.
• Clé laissée vide (mesure libre) : QUOTELUI la génère automatiquement depuis le libellé (« Largeur » → largeur, « Hauteur baie » → hauteur-baie). Si une telle clé existe déjà sur le même élément, la seconde reçoit un suffixe (largeur_2) — jamais d'erreur.
• Clé saisie : elle reste prioritaire et doit correspondre à un attribut du métier (ex. surface, ml, debit).

Le rôle de la clé est de relier la mesure au reste de l'application :

• Tarification : quand vous créez un devis depuis le relevé (§13 ter), la quantité de la ligne est prise dans la mesure dont la clé correspond à l'attribut de quantité du tarif (§13 bis — ex. surface pour un tarif au m², ml pour un tarif au mètre linéaire).
• Sans clé correspondante, la quantité retombe sur l'attribut du référentiel de prix, sinon 1 (prestation forfaitaire).
• Une mesure sans clé liée reste descriptive : elle apparaît sur le relevé et dans son PDF, sans influence sur la tarification.

Astuce : pour forcer la liaison avec un tarif, utilisez précisément la clé de l'attribut de quantité définie dans Réglages → Tarifs (pose) (§13 bis).

12. Recherche d'objets dans les listes

Chaque liste (devis, clients, chantiers, relevés, produits) peut être parcourue via Recherche (§6) ou directement sur les cartes du tableau de bord.

13. Réglages de l'entreprise (Admin)

Réglages (menu) permet de configurer l'entreprise, avec effet immédiat sur les nouveaux devis (l'envoi fige ces informations dans la version) :

Configuration par entreprise : chaque société conserve ses réglages. Un réglage ne modifie jamais un devis déjà envoyé (celui-ci est figé).

À noter : si l'entreprise ne possède encore aucun taux de TVA, QUOTELUI crée automatiquement les taux standards français (20 %, 10 %, 5,5 %, 2,1 %) à l'ouverture des Réglages et fixe la TVA par défaut à 20 % — cela évite le message « Chaque ligne doit figer son taux de TVA » lors de la création d'un devis depuis un relevé (§13 ter).

Réglages → Notifications (V2.13) configure un digest d'alertes par email : destinataires (séparés par des virgules) et catégories à inclure (devis, factures en retard, stock bas, relances commerciales, relevés, licences). L'envoi est déclenché par une commande périodique (voir §13 octies).

13 bis. Tarifs (pose) — référentiel de prix (V2.5)

Réglages → Tarifs (pose) (Admin) permet de constituer un référentiel de prix par type de produit : pour chaque type du catalogue (fenêtre, porte, pose…), vous enregistrez une prestation type avec son prix unitaire HT.

Quand un commercial ajoute une ligne de devis et choisit un produit du catalogue, l'application propose automatiquement :

• le libellé de la prestation (ex. « Pose fenêtre (unité) ») ;
• le prix unitaire HT du référentiel ;
• une quantité déduite d'un attribut du produit (ex. la surface en m², le pourtour en ml) si la règle la désigne — sinon quantité fixe 1 (forfait) ; même clé utilisée par les mesures de relevé (§11.3) pour quantifier une ligne de devis en issue d'un relevé ;
• l'unité affichée (m², ml, unité…).

Le tarif proposé reste modifiable : le commercial peut valider, corriger le prix ou la quantité avant l'ajout de la ligne. La proposition ne modifie jamais le devis elle-même.

Points de fonctionnement :

• Une seule règle active par type de produit ; une règle supprimée est conservée (historique) et peut être réactivée en la recréant.
• L'attribut de quantité doit être un attribut numérique (DECIMAL) du type (un choix ou un attribut d'une autre entreprise est refusé).
• Montants en Decimal uniquement (la virgule française est acceptée dans le formulaire) ; le refus d'un float reste inchangé (spec §8).

13 ter. Devis depuis un relevé (V2.6)

Un relevé de chantier peut devenir un devis en un clic :

1. Reliez chaque élément relevé à un produit du catalogue : au moment de l'ajout, ou plus tard via le sélecteur « Relier à un produit… » de la carte de l'élément (service link_item_product — produit actif de la même entreprise, type cohérent avec l'élément, métier du relevé sur un relevé cloisonné). L'élément affiche alors « · produit : … ». Un élément typé sans produit (« Pas au catalogue ») reste chiffrable via la règle du type (rule_for_product_type).
2. Une fois le relevé reçu au bureau (statut au moins VALIDE/BUREAU), un bouton vert « Devis depuis ce relevé » s'affiche en haut de la fiche.
3. QUOTELUI crée un devis BROUILLON avec :
4. le client et le chantier du relevé ;
5. une ligne par élément relevé — aucun élément n'est perdu : relié à un produit, typé (règle du type, §13 bis), ou « … (à tarifer) » à 0 € pour un élément sans produit ni tarif ; le prix se pose ensuite dans le devis (saisie manuelle, choix au catalogue ou Tarif fabricant) ;
6. le libellé et le prix depuis le référentiel de tarifs (§13 bis) si le type de produit y figure — sinon le nom et le prix de vente du produit ;
7. la quantité depuis une mesure du relevé (§11.3) dont la clé correspond à l'attribut de quantité de la règle (ex. surface en m²), sinon l'attribut du référentiel, sinon 1 ;
8. la TVA par défaut de l'entreprise (réglages §13).

Points importants :

• Sources de prix, dans l'ordre : produit relié (règle du type si présente, sinon nom/prix du produit), sinon — élément typé sans produit — règle du type (rule_for_product_type), sinon 0 € « à tarifer ». Le message de création rappelle le nombre de lignes à tarifer.
• Une dimension n'est jamais une quantité : pour une ligne « à tarifer », la quantité vaut 1 (jamais la hauteur/largeur en mm du relevé — une porte-fenêtre de 2150 mm n'est pas 2150 unités) ; seule une mesure réellement quantitative (surface en m², mètre linéaire…) peut servir de quantité. Corrigez-la au besoin avec Modifier sur la ligne du devis.
• Seul un relevé sans aucun élément est refusé. Si l'entreprise n'a aucun taux de TVA par défaut, le refus est explicite et indique le remède : Réglages → Entreprise (§9 : chaque ligne fige son taux).
• Depuis le configurateur Tarif fabricant, le bouton « ← Retour » ramène à la fiche du relevé (ou du devis) d'où il a été ouvert — on ne reste jamais coincé dans la fenêtre.
• C'est un nouveau devis à chaque clic (un devis peut avoir plusieurs versions, jamais deux fois la même offre).
• Le devis reste un brouillon éditable : vérifiez, corrigez, puis envoyez comme n'importe quel devis.

13 quater. Stock (V2.8)

Stock dans le menu permet de suivre les quantités par produit (Manager+ pour les mouvements, tous les rôles en lecture).

• Suivre un produit : la liste déroulante propose les produits du Catalogue (§9) qui ne sont pas encore suivis. Choisissez-en un, indiquez éventuellement une quantité initiale et un seuil d'alerte, puis « Activer le suivi ». Le produit n'existe pas encore ? Créez-le d'abord au Catalogue via le lien « + Créer un produit au catalogue ». Tant qu'un produit n'est pas suivi, son stock n'est pas débité et aucune alerte n'est émise.
• Mouvements : chaque ligne affiche un formulaire Entrée (réception), Sortie (consommation) ou Ajuster (correction du solde). Une sortie qui rendrait le solde négatif est refusée, sauf pour le débit automatique d'un devis. Chaque mouvement est tracé (date, type, variation, solde après, motif, auteur, devis éventuel).
• Débit automatique : à l'acceptation d'un devis, une sortie est enregistrée pour chaque ligne reliée à un produit suivi (les produits non suivis sont ignorés). Le solde peut passer négatif : un devis accepté est une commande ferme, la rupture est signalée par l'alerte stock bas.
• Ne plus suivre : désactive le suivi (suppression logique) — l'historique des mouvements est conservé et le suivi peut être réactivé plus tard.
• Alertes : un produit dont le solde est ≤ seuil déclenche une alerte « stock bas » (rouge si rupture) visible dans la page Alertes.

Dépôts et transferts (V2.14)

Le stock est organisé en dépôts (dépôt principal, atelier, camion…) :

• La page Stock affiche un sélecteur de dépôt ; toutes les entrées, sorties, ajustements et suivis portent sur le dépôt courant. Un « Dépôt principal » est créé automatiquement (débit des devis, réceptions et livraisons).
• Gérer les dépôts (Stock → « Gérer les dépôts », Manager+) : créer, renommer, définir le dépôt par défaut. Le dépôt par défaut ne peut pas être supprimé.
• Transférer du stock : déplace une quantité d'un dépôt à un autre (deux mouvements Transfert tracés). Le stock de chaque dépôt est isolé.

13 quinquies. Fournisseurs & commandes fournisseurs (V2.9)

Fournisseurs

Fournisseurs (menu) : fiches d'achat (coordonnées, conditions de règlement, délai indicatif) et tarifs d'achat par produit. La gestion est réservée aux rôles Manager+ ; les autres rôles consultent. Une fiche affiche aussi l'historique de ses commandes.

Nature du prix (spec §6) — sur chaque tarif :

• prix brut : la remise fournisseur s'y applique ;
• prix net : négocié, remise déjà incluse — aucune seconde remise n'est appliquée ;
• prix contractuel : prix ferme de contrat — aucune remise non plus.

Remises négociées — section dédiée de la fiche fournisseur : remise par famille (type de produit), par catégorie catalogue, de volume (« à partir de N unités ») ou par défaut sur la fiche. Résolution déterministe et jamais cumulée : la règle la plus spécifique gagne (remise produit → volume/famille → famille/catégorie → défaut). Les dates de validité bornent chaque règle ; une règle retirée reste traçable.

Historique & source : chaque changement de tarif (prix, nature, remise, validité) est historisé (ancien prix jamais écrasé en silence) et la source du prix peut être saisie (« fichier 2026 », « contrat cadre »…). Les lignes de commande fournisseur reprennent automatiquement le prix d'achat net résolu pour la quantité commandée.

Modules métier : une fiche peut préciser les métiers concernés (Menuiserie, Plomberie…) ; vide = le fournisseur est proposé pour tous les métiers.

Commandes fournisseurs

Commandes (menu) gère les bons de commande (BC-YYYY-NNNN) :

BROUILLON → ENVOYEE → CONFIRMEE → PARTIELLEMENT_RECUE → RECUE
                                        ANNULÉE (depuis tout état non reçu)

• Créer une commande : choisir le fournisseur (et éventuellement un chantier + une date de réception prévue).
• Ajouter des lignes : au choix libre, ou un produit du catalogue — le prix d'achat est alors proposé depuis le tarif fournisseur (sinon le prix d'achat du produit). La TVA est figée par ligne.
• Envoyer puis Confirmer (boutons d'état).
• Réceptionner : saisir les quantités reçues → les quantités reçues sont cumulées et, pour chaque produit suivi en stock, une entrée de stock est créée automatiquement (module Stock, §13 quater). Le statut bascule en Partiellement reçue puis Reçue.
• Facture fournisseur : suivi léger (n° facture, date, montant, réglée).

13 sexies. Bons de livraison client (V2.10)

Livraisons (menu) gère les bons de livraison (BL-YYYY-NNNN) — utiles pour tracer ce qui est réellement remis au client, indépendamment de la facturation.

BROUILLON → PARTIELLEMENT_LIVREE → LIVREE
                ANNULÉE (depuis BROUILLON / PARTIELLEMENT_LIVREE)

• Créer un bon : depuis un devis accepté (recommandé — copie client, chantier et lignes) ou librement (client + chantier + lignes).
• Livrer : saisir les quantités remises → elles sont cumulées et, pour chaque produit suivi en stock, une sortie de stock est créée automatiquement (§13 quater). Le statut passe en Partiellement livrée puis Livrée ; le reliquat reste visible pour une livraison ultérieure.
• PDF du bon (avec cases « Le livreur / Le client ») et envoi par email au client.
• Le bon peut être annulé tant qu'il n'est pas entièrement livré.

13 septies. Affaires & relances — CRM (V2.11)

Affaires (menu) pilote le pipeline commercial avant le devis.

• Étapes : Nouveau → Qualifié → Proposition → Négociation → Gagné / Perdu. La page Affaires affiche un tableau par étape, les indicateurs (affaires ouvertes, montant en cours, gagnées, taux de réussite) et les relances à faire.
• Créer une affaire : intitulé, client, chantier, montant estimé HT, responsable, origine (bouche-à-oreille, site, salon…), clôture prévue. Un devis peut y être rattaché.
• Activités / relances : appel, email, rendez-vous, visite ou tâche, avec échéance et assignation. Une activité à faire dont l'échéance est dépassée déclenche l'alerte « relances en retard » ; on la marque Faite ou Annulée.
• Seuls les rôles Commercial+ créent et font évoluer les affaires ; les autres consultent.

13 octies. Notifications par email (V2.13)

Réglages → Notifications (Admin) active un digest d'alertes envoyé par email : destinataires et catégories à inclure (devis, factures en retard, stock bas, relances commerciales, relevés, licences).

• Envoi : commande périodique à planifier quotidiennement. Envoie le digest à chaque entreprise dont les notifications sont activées avec au moins un destinataire et qui a des alertes en cours. Seule entreprise à la fois et mode simulation disponibles.
• Les emails partent de la boîte d'envoi de l'entreprise (§15 bis) et sont journalisés dans Emails.
• Aucune alerte pour soi-même : le digest reprend exactement les alertes de la page Alertes (§6 bis), filtrées selon les catégories activées.

13 novies. Sous-traitants (V2.17)

Sous-traitants (menu) gère les artisans externes à qui vous confiez des parties de chantier.

• Fiche sous-traitant : nom, spécialité, SIRET, assurance décennale, coordonnées. Créée/modifiée par Commercial+.
• Affectation : lien sous-traitant ↔ chantier. Périmètre de travail, coût estimé HT, dates prévues. Statut : Brouillon → Confirmée → En cours → Terminée (ou Annulée).
• Factures sous-traitant : le sous-traitant vous envoie sa facture, vous la saisissez sur l'affectation (n° facture, date, montant HT, TVA). Le coût réel est recalculé automatiquement. Suivi du paiement (réglée / en attente).
• Coût de revient : le coût réel des affectations alimente le suivi financier du chantier.

13 duodecies. Multi-devises (V2.18)

Le système supporte 6 devises : EUR (€), CHF (franc suisse), USD ($), GBP (£), CAD (dollar canadien), XOF (franc CFA).

• Devis : la devise est choisie lors de la création du devis (défaut : devise de l'entreprise). Le PDF affiche le bon symbole dans le tableau et les totaux.
• Facture : la devise est copiée depuis le devis d'origine, ou choisie librement. Le PDF et l'email affichent le symbole correct.
• Bons de livraison / Sous-traitants : champs currency disponibles.
• Taux de change : non gérés pour l'instant — chaque devise est indépendante. Un devis en CHF reste en CHF, sans conversion automatique.

Règle : la devise est un label d'affichage. Tous les calculs (restes à payer, reporting, totaux) sont dans la devise d'origine du document. Le change sera une phase ultérieure si besoin.

13 tredecies. Documents & photos de chantier (V2.19)

Chaque chantier dispose d'un espace documents & photos accessible depuis la fiche chantier.

• Documents (/chantiers/<pk>/documents/) : liste, upload (PDF, Excel, Word…), catégorie (Devis signé, Facture, PV, Assurance, Autre), suppression. Chaque document est versionné (V1 → V2 → …).
• Photos (/chantiers/<pk>/photos/) : galerie avec aperçu (thumbnails auto-générés), upload (JPEG/PNG/WebP), suppression.
• Fiche chantier : section « Documents & Photos » avec compteur et 3 dernières photos.
• Alertes : assurance décennale des sous-traitants expirant sous 30 jours (danger) ou 60 jours (warning).

Aucune migration — tout repose sur le GFK existant (Document + MediaItem).

13 quattuordecies. Planning des interventions (V3.0)

Planning dans le menu ouvre un calendrier hebdomadaire qui regroupe automatiquement tout ce qui a une date, sans rien à saisir en plus :

Fonctionnement :

• Navigation : il faut les boutons « Semaine précédente / Aujourd'hui / Semaine suivante » ; l'URL accepte ?start=AAAA-MM-JJ.
• Couleurs : chantiers (bleu), relevés (ambre), activités (indigo), livraisons (vert). Chaque carte ouvre la fiche concernée.
• Conflits : si le même technicien a 2+ interventions le même jour (chantier + relevé + RDV…), un badge ⚠ Conflit apparaît ce jour-là et la liste est détaillée en bas de page. Une alerte correspondante apparaît dans Alertes pour les 14 prochains jours.
• Techniciens : un compte TECHNICIEN ne voit que ses interventions et ses conflits (pas l'agenda des collègues).

Le planning est en lecture seule : il se remplit à partir de la date de début des chantiers (§8), de la date des relevés (§11) et des activités (§13 septies). Pour faire vivre l'agenda, renseignez ces dates au quotidien.

Aucune migration : le planning ne fait que lire des objets existants.

13 quindecies. Tarif fabricant — configurateur & grilles (menuiserie)

Le Tarif Fabricant chiffre une menuiserie selon le catalogue du fabricant, sans quitter le devis : bouton ⚡ Tarif Fabricant (menuiserie) sur la fiche d'un devis (§10) ou d'un relevé menuiserie (§11). La page s'ouvre dans une fenêtre intégrée (même site, sans perte de contexte).

• Périmètre limité aux menuiseries : le bouton n'apparaît que sur un type d'ouvrage chiffré par ce moteur (fenêtre, porte, portail…) ; il disparaît dès qu'un type d'un autre métier est sélectionné (lavabo, parpaing…), et le configurateur refuse explicitement un type hors périmètre (jamais une fenêtre par défaut à la place d'un autre ouvrage). Pour les autres métiers : Ajouter une ligne → Choisir un type → Proposer un prix (règle de pose / tarif du type).

• Ouverture sur le bon type : le configurateur s'ouvre directement sur le type menuiserie sélectionné dans le formulaire de devis.

• Choix guidés : type d'ouvrage (fenêtre, porte, porte-fenêtre, baie, portail, volet, store…), matière, vitrage, ouverture, coloris RAL, nombre de vantaux, hauteur × largeur en mm.

• Aperçu 2D / 3D : bouton de bascule 2D | 3D dans le bloc aperçu.
• 2D : schéma vectoriel proportionnel qui se met à jour en direct (dimensions, panneaux, sens d'ouverture, couleur du cadre, volets/stores en lattes, fenêtre ronde).
• 3D : modèle volumétrique générique (Three.js), aux proportions exactes H × L, avec la couleur du cadre et du vitrage, rotation 360° à la souris (maintenez + glissez). En 3D, le bouton « Photo de façade… » charge une photo du mur du client : elle s'affiche en fond derrière le modèle (curseur « Largeur de la photo » pour un calage visuel approximatif). Aperçu indicatif — la photo sert de repère, le calage exact n'est pas automatique. Le moteur 3D se télécharge au premier passage en 3D (il ne ralentit pas la vue 2D par défaut) ; si la connexion CDN est absente, le schéma 2D reste utilisable. Schéma de confort — il ne remplace pas les plans techniques.
• Fabricant / gamme : si plusieurs fabricants fournissent le même type d'ouvrage (plusieurs grilles actives pour ce type), un sélecteur « Fabricant / gamme » apparaît en haut du formulaire : le prix suit la gamme choisie. Sans choix explicite, la première grille du fabricant (ordre alphabétique) est utilisée.
• Trois modes de chiffrage (selon la configuration de l'entreprise) :
• Simulation (par défaut) : grille de coefficients intégrée — idéal pour une démonstration, aucun fichier à fournir.
• Grille du fabricant : fichier CSV du fabricant importé (voir plus bas). Si aucune grille ne couvre le type demandé, le configurateur retombe automatiquement sur la simulation.
• API fabricant (Voie B) : si le fabricant expose un service web, le configurateur lui envoie la configuration en JSON et reçoit le prix net, la référence, le délai et la garantie. Activé côté serveur par TARIF_PROVIDER=api + TARIF_API_URL (et TARIF_API_KEY pour la clé d'accès) — jamais de clé en dur dans le code.
• Résultat : prix HT, prix TTC, délai et garantie affichés, puis :
• « Insérer dans un devis » : la ligne est ajoutée au devis courant (prix, libellé, quantité — la TVA suit les réglages de l'entreprise), ou
• « Créer un devis et insérer » : quand on vient d'un relevé, un devis brouillon est créé avec le client et le chantier du relevé, puis la ligne y est posée.
• Depuis un relevé : le configurateur reprend automatiquement les attributs de l'élément sélectionné (dimensions, matière, vitrage…) et conserve le relevé courant pendant toute la saisie.

Import d'une grille fabricant — Réglages → Tarifs fabricant (Admin et Manager) :

• Versionnage du catalogue : chaque import qui change une grille crée une nouvelle version (v1 → v2 → …) et conserve l'ancien prix (historique consultable : « Derniers changements de tarifs » sur la page). Un réimport identique ne crée pas de version. Le libellé de la ligne de devis porte la version utilisée (« (grille v2) ») : un réimport ultérieur ne modifie ni le prix ni la version d'un devis déjà chiffré. Une source (« Tarif 2026 », « contrat cadre ») peut être saisie à l'import.
• Prévisualisation avant écriture : « Analyser le fichier » lit le fichier et affiche l'abaque et les plus-values sans rien enregistrer ; « Confirmer l'import » crée (ou met à jour) ensuite la grille. Un fichier invalide est refusé avec le numéro de ligne, avant tout import.
• Formats acceptés : CSV, classeur Excel (.xlsx) ou JSON — la même mise en page dans les trois cas (pour Excel, la première feuille du classeur est lue ; les cellules numériques sont acceptées telles quelles). L'ancien format .xls doit être réenregistré en .xlsx, .csv ou .json.
• Format JSON documenté (intégrations futures) : un objet {"type", "label", "cells": [{width_mm, height_mm, price_ht}], "options": [{key, label, mode, value, length_base?, included_in_base?}]} — les modes sont ceux du CSV (coef, fixe, m2, ml, percent, unite, inclus). Le modèle JSON complet est fourni dans le code (apps/pricing/services.py → GRID_JSON_SCHEMA) et une grille existante peut être ré-exportée dans ce format (grid_export_json).
• Modèle CSV à télécharger sur la page (bouton « Modèle CSV ») ; encodage UTF-8, séparateur ; (ou tabulation/virgule — détecté automatiquement).
• Format : lignes type;largeur;hauteur;prix_ht (l'en-tête est tolérant), puis les sections option;clé;libellé;mode;valeur (clé au format domaine:valeur, ex. option;matiere:alu;Aluminium;coef;1.10, option;coloris:ral 7016;Thermolaquage RAL 7016;percent;8).
• Modes d'option (§4.2) : coef (multiplicatif), fixe (montant HT), m2 (montant × surface réelle), ml (montant × longueur facturable — base perimetre par défaut, ou largeur / hauteur en 6ᵉ colonne), percent (pourcentage du prix de base de la grille — jamais l'ensemble du devis), unite (montant × quantité d'options saisie), inclus (option déjà comprise dans la case : affichée, jamais facturée — aucune double facturation).
• Calcul du prix de base : les dimensions réelles (mm) sont conservées ; sur chaque axe indépendamment, la grille retient la première taille supérieure ou égale (largeur et hauteur cherchées séparément, une correspondance exacte garde la case exacte). Exemple : 1345 × 1123 mm → case 1400 × 1200 mm. Les plus-values au m² / ml utilisent les dimensions réelles, pas la taille de la case.
• Chaîne de prix : prix brut (case + options) → remise fournisseur du fabricant (%) → prix d'achat net → frais éventuels → coût de revient → coefficient de vente de l'entreprise → prix de vente HT → TVA → TTC. Le configurateur affiche un « Détail du calcul » repliable (base, plus-values, remise, achat net, coefficient, prix de vente).
• Remise fournisseur : renseignée sur la fiche fabricant (espace Éditeur) ; elle réduit le prix d'achat de l'artisan et jamais le prix de vente.
• Coefficient de vente : Réglages → Entreprise (1,000 = prix d'achat net vendu tel quel ; 1,400 = +40 %). Distinct d'une marge cible et de la remise client (qui reste gérée par la ligne de devis).
• Taux horaire main-d'œuvre : également dans Réglages → Entreprise, il pré-remplit le bloc Main-d'œuvre des devis (§10.1).
• Hors grille = refus explicite : seulement quand aucune taille supérieure n'existe sur un axe (message précisant l'axe et le maximum disponible) ou quand la case retenue est absente de la matrice (« grille incomplète »). Aucun prix n'est jamais inventé sur une case inférieure.
• Compatibilité des options : une option peut déclarer une clé requise (requiert en 7ᵉ colonne du fichier, requires en JSON) — par exemple la motorisation ne s'applique qu'au type « volet » (…;fixe;145.00;;type:volet). Tant que la clé requise n'est pas sélectionnée, l'option est ignorée (jamais facturée à tort) et signalée comme incompatible dans le détail du calcul.
• Idempotent : réimporter le même fichier ne crée pas de doublon ; les cellules retirées du fichier sont archivées, les options restent si absentes du fichier. Les doublons (même clé d'option, même cellule) sont refusés avec le numéro de ligne.
• Simulateur fabricant : quand aucune grille n'est importée, le configurateur travaille sur une simulation explicitement affichée comme fictive (« données fictives », jamais présentée comme un tarif industriel). Il peut être désactivé par entreprise (§4.4) pour masquer le bouton et la page aux utilisateurs.

Accès : Admin et Manager (gestion des prix). Le tarif est une proposition : la ligne reste modifiable dans le devis.

14. Administration — Membres (Admin)

Administration → Membres gère les comptes de l'entreprise.

• Ajouter : saisissez nom/email + rôle ; un compte est créé avec un mot de passe (à transmettre au collaborateur).
• Changer le rôle : sélectionnez le rôle dans la liste (action immédiate) : LECTEUR / TECHNICIEN / COMMERCIAL / MANAGER / ADMIN.
• Retirer : supprime l'accès du collaborateur à cette entreprise (sans supprimer ses données historiques).
• Mot de passe : réinitialisation depuis le formulaire du membre — refusée pour les comptes de démonstration (mots de passe fixes, publiés dans la doc, §1 comptes de démo).

Chaque ajout/retrait/changement de rôle est journalisé dans l'audit.

Mode d'équipe : en mode Solo, l'entreprise n'a qu'un seul compte (l'administrateur) — le formulaire d'ajout est remplacé par un bandeau expliquant de contacter l'éditeur. Le mode se pilote depuis l'espace Éditeur (§14 quater).

14 quater. Limites de membres — espace Éditeur (V4.4)

Modes d'équipe : chaque entreprise est en mode Solo (un seul compte : l'administrateur — tous les autres rôles bloqués à 0), Standard (multi-utilisateurs, défaut) ou Personnalisé (quotas édités à la main). Le basculement se fait depuis Espace Éditeur → fiche entreprise → « Membres → », boutons « Passer en Solo » / « Passer en Standard » ; il ne supprime aucun membre existant (les ajouts sont simplement bloqués, et un dépassement éventuel reste visible). Chaque bascule est audité (PERMISSION_CHANGE, acteur = l'éditeur). Le mode est dérivé des quotas (Company.member_limits, JSON) — aucune migration, aucun champ « plan ».

Quotas par rôle : par entreprise, le nombre maximal de comptes actifs est limité par défaut à 1 ADMIN, 1 MANAGER, 1 COMMERCIAL, 3 TECHNICIEN, LECTEUR illimité (EDITEUR toujours hors quotas). La règle est appliquée côté serveur dans add_member (ajouts ET changements de rôle) — un dépassement produit un message clair, jamais une erreur 500.

• Espace Éditeur → fiche entreprise → « Membres → » (route editeur/<pk>/membres/, PUBLISHER_LICENSE_MANAGE) : boutons de mode + champ Maximum par rôle (vide = défaut, nombre = quota, case Illimité = aucun quota). Stockage : Company.member_limits (JSON, migration companies/0006), lecture via apps/companies/limits.py (membership_mode / apply_membership_mode / member_limit / check_member_limit / set_member_limits).
• Administration → Membres de l'agence affiche le mode courant, le message de dépassement et n'inscrit rien (l'utilisateur n'est pas même créé).
• Le tableau de bord éditeur signale les entreprises en Mode solo (badge).

14 bis. Administration — Modules métiers (Admin)

Administration → Modules active les spécialités de l'entreprise.

• Activer : le catalogue et les champs de relevé du métier sont injectés automatiquement (types de produits, attributs, schémas de relevé).
• Désactiver : le module disparaît de la liste, mais aucune donnée n'est supprimée — devis et relevés déjà réalisés restent intacts et exploitables.

Verrouillage par clé d'activation (installation chez un installateur)

Selon l'installation, les modules peuvent être verrouillés : seuls les métiers livrés d'office (Menuiserie) se passent de clé. Pour activer un autre métier (Plomberie, …), il faut la clé d'activation fournie par ton installateur :

• La clé est propre à l'entreprise + le module (elle ne peut pas être réutilisée ailleurs) et valable une durée fixée (généralement 1 an).
• Saisie : Administration → Modules → (module verrouillé) → champ « Clé d'activation » → Activer.
• Alertes : ~60 jours puis ~15 jours avant l'expiration, une alerte apparaît sur le tableau de bord. À l'expiration, le module se reverrouille (les données historiques restent intactes) jusqu'à une clé de renouvellement.

Côté éditeur — gérer, renouveler, révoquer (Éditeur → fiche agence → licences)

L'éditeur dispose de trois actions par module (route editeur/<pk>/licences/) :

• « Générer / renouveler » (durée 30 j → 2 ans) : enregistre la licence et active le module immédiatement — l'éditeur n'attend pas que le client saisisse la clé. La clé produite reste affichée (copier / envoyer / mailto) si le client doit l'activer lui-même. Renouveler une seconde fois remplace la date (une seule licence par module).
• « Révoquer l'activation » : coupe tout — licence retirée, module désactivé. Les données du module sont conservées (aucune suppression) : remise à zéro propre, utile pour régénérer une activation.
• « Activer / Désactiver » : bascule d'accès. Un module verrouillé ne peut pas être activé sans licence — l'éditeur est invité à générer d'abord la clé (sinon le contrôle de licences reverrouillerait le module au chargement suivant).

L'état affiché est sans ambiguïté : Actif — licence valide jusqu'au …, Actif sans licence valide (sera reverrouillé), Licence enregistrée — module inactif, Expirée le …, Pas encore de clé.

Livrer un client final (Éditeur → Livrer un client)

Après la phase de démonstration et la signature du client, l'éditeur crée son espace définitif en une passe depuis Éditeur → Livrer un client :

1. Société : raison sociale, nom commercial, SIRET (14 chiffres), email de contact affiché sur les PDF (défaut : email admin).
2. Compte administrateur : email, mot de passe (vide = généré et affiché une fois) ; si le prospect avait déjà un compte de démo, il est rattaché et son mot de passe est réinitialisé.
3. URL de connexion : y saisir l'adresse dédiée du client (ex. https://client1.quotelui.fr) — c'est le lien que recevra le client par email.
4. Modules livrés : cocher les métiers — chacun est licencié pour la durée choisie (30 j → 2 ans, défaut 1 an) et activé immédiatement ; aucune clé à transmettre.
5. Sièges : presets Solo (un seul compte) / Standard (1 admin + 1 manager + 1 commercial + 3 techniciens, lecteurs illimités) ou quotas saisis à la main par rôle.
6. Email d'accès (case cochée par défaut) : message dédié « Votre espace Quotelui est prêt » — modules, échéance, identifiants — envoyé depuis la boîte éditeur. Sans boîte configurée, la livraison réussit quand même et les identifiants s'affichent à l'écran (à transmettre vous-même).

La page de succès montre les identifiants une seule fois : notez-les avant de partir. Un lien mène ensuite aux licences de la société livrée (pour renouveler plus tard).

15. Historique (audit)

Historique (menu, Manager+) journalise toutes les opérations importantes de l'entreprise :

• création et modification (avec détail du changement)
• suppression / restauration
• changements de statut et validations
• envoi de devis et création de versions
• signature électronique d'un devis (acceptation/refus du client)
• téléchargements de PDF
• changements de permissions (membres) et de modules

Filtres et export :

• Par action : liste déroulante « Toutes les actions ».
• Par module métier : liste déroulante « Tous les modules » — sélectionnez Menuiserie ou Plomberie pour ne voir que cette activité (le module est automatiquement rattaché aux événements concernés : types de produits, produits, activation/désactivation).
• Par texte : référence ou type d'objet.
• Télécharger (CSV) : exporte toute l'histoire — ou seulement le résultat du filtre en cours (action, module, texte) — dans un fichier utilisable dans Excel / tableur.

Le journal est filtré par entreprise : rien ne fuite entre deux sociétés.

15 bis. Emails envoyés (Manager+)

Emails (menu, Manager+) montre qui a reçu quoi et quand, avec le statut de chaque envoi.

• Ce qui est tracé : date, destinataire (email du client figé dans le devis), objet, devis concerné, statut (Envoyé / Échec + erreur détaillée en rouge).
• Filtres : par destinataire/objet (texte), par statut.
• Par quelle boîte passent les emails ? Chaque entreprise peut configurer sa propre boîte dans Réglages → Options email (SMTP) (réservé à l'Admin) : serveur, port, sécurité (TLS/SSL), identifiant, mot de passe et expéditeur, avec pré-remplissage automatique pour Gmail, Outlook / Microsoft 365, OVH et Orange.

Tant que la case « Activer cette boîte » est cochée, les envois passent par cette boîte. Sinon, l'application utilise la configuration serveur (variables d'environnement EMAIL_*, ou journal console en développement).

Configuration SMTP (à défaut, configurée côté serveur)

Gmail impose « mot de passe d'application » (2 étapes l'activation requise). Sans SMTP configuré (mode développement/démo), les emails sont imprimés dans le journal du serveur et marqués « Envoyé » — rien ne part réellement.

Les emails envoyés avec le devis (PDF en pièce jointe) utilisent l'email du client figé dans la version envoyée, jamais le client mis à jour ensuite.

16 bis. Exemple complet guidé (démo multi-modules)

Parcours de bout en bout sur l'entreprise de démonstration « Artisan Démo SARL » (compte de démonstration communiqué par l'éditeur), montrant qu'un même devis cumule des cotations de plusieurs modules métier.

1. Se connecter (voir §1) depuis un ordinateur ou un téléphone (http://<IP-du-PC>:8000, même Wi-Fi, §1).
2. L'entreprise active doit être « Artisan Démo SARL » ; sinon basculez en bas du menu (§2).
3. Catalogue — Produits : ouvrez Produits (menu). Les 8 modules sont activés sur cette entreprise (Administration → Modules) ; vous y retrouvez les produits de chaque métier : fenêtres (Menuiserie), PAC (Chauffage), disjoncteurs (Électricité), tuiles (Couverture), parpaings (Maçonnerie), grès cérame (Carrelage), peinture (Peinture).
4. Devis — créer : ouvrez Devis → bouton Nouveau devis avec le chantier visé. La création reprend l'exemple prêt à l'emploi DEV-2026-0007 : 11 lignes couvrant 7 modules, chacune avec sa TVA figée (fenêtre 5,5 %, PAC et disjoncteurs 20 %, tuiles/parpaings/carrelage/peinture/main-d'œuvre 10 %), totaux HT / TVA / TTC affichés (17 580 € TTC).
5. États du devis : passez le devis de <BROUILLON> (ou A_COMPLETER) vers PRET, puis Envoyer : le contenu est figé dans une version (v1 → v2 …), le PDF est généré (bouton PDF) et envoi par email possible (Envoyer). Une fois envoyé, plus aucune ligne n'est modifiable sans créer une nouvelle version (retour EN_REVISION).

6. Relance : depuis un devis ENVOYE, le bouton Relancer renvoie le même PDF figé au même destinataire (objet « Relance : … »), journalisé dans Emails (§15 bis). la relance peut être automatisée par la commande périodique :

   Commande	Effet
   Relance automatique tout devis envoyé il y a plus de 30 jours sans réponse, sauf si relancé depuis moins de 7 jours (délais ajustables). Mode simulation disponible.

   Seules les entreprises actives sont affectées ; aucune version n'est créée (le PDF figé d'origine est renvoyé). 7. Relevé de chantier : ouvrez Relevés → RELEV-2026-0003 (statut VALIDE, workflow §11) : l'item « PAC air-eau » porte des mesures (surface 85 m²) et des champs spécifiques au métier Chauffage §15 (pièces, énergie, mode d'émission) ; l'item « Tableau existant » porte des champs Électricité (prise de terre, puissance souscrite). Même relevé, deux métiers : les champs proviennent des schémas de chaque module actif. 8. Historique : ouvrez Historique (§15) : l'envoi du devis, le changement d'état du relevé, l'activation des modules et la création des produits y sont tracés.

À retenir : rien n'est codé « métier » dans le moteur. Les modules contribuent uniquement des données (types de produits, attributs, champs de relevé). On peut donc librement mélanger Menuiserie, Plomberie, Chauffage, Électricité, Couverture, Carrelage, Peinture, Maçonnerie — sur le même devis comme sur le même relevé — et désactiver un module sans jamais perdre l'historique.

17. Conseils d'utilisation

• Relance commerciale : l'alerte « à relancer » (envoyé > 30 j) vous rappelle les devis en attente de réponse. Depuis le devis (ou sa fiche client / son chantier), le bouton Relancer renvoie au client le même PDF figé (objet « Relance : … »), journalisé dans Emails, et affiche la date de la dernière relance. Seuls les devis Envoyés sont relançables ; un devis expiré repasse d'abord par EN_REVISION (nouvelle version, nouvelle validité).
• TVA : vérifiez le taux de chaque ligne avant l'envoi ; après envoi il est figé et ne suivra plus les changements de configuration.
• Relevés : un relevé clôturé n'est plus modifiable — préférez un retour (BUREAU → VALIDE) tant que le dossier n'est pas finalisé.
• Multi-entreprises : vérifiez en haut du menu quelle entreprise est active avant d'éditer un devis.
• Sauvegarde : les données sont sauvegardées par la procédure de l'exploitant (voir docs/deployment.md) — une intervention de restauration ne dépend pas de l'application elle-même.

18. Dépannage rapide

18 bis. Signature électronique des devis (V2.2)

Lorsque vous envoyez un devis par email, un lien de signature est inclus dans le message (vert, bien visible). Le client peut :

1. Consulter le devis (résumé + PDF intégré) depuis n'importe quel appareil.
2. Accepter ou refuser en un clic — sans créer de compte.
3. La décision est immédiatement enregistrée dans QUOTELUI (statut du devis + historique audit avec date, IP et navigateur du client).

Comment ça marche :

Points importants :

• Le lien est unique et non devinable (jeton cryptographique aléatoire).
• La page est publique (pas besoin de compte QUOTELUI) mais le lien seul sert de preuve d'identité (protocole semblable aux liens de réinitialisation de mot de passe).
• Une décision est définitive : un devis accepté ne peut plus être refusé via le même lien. Pour modifier, créez une nouvelle mouture (EN_REVISION).
• Les devis non envoyés ne disposent pas de lien de signature.
• L'historique de signature est traçable dans l'audit (action SIGNATURE).

18 ter. Confidentialité & RGPD (données personnelles)

QUOTELUI est une plateforme métier : chaque entreprise utilise son propre compte et reste responsable de traitement des données qu'elle y enregistre (clients, chantiers, devis…).

Ce qui est réellement mis en œuvre (mesures techniques) :

• Connexion chiffrée (HTTPS/TLS) dès la production ;
• Mots de passe stockés de façon sécurisée (hachage Django, jamais en clair) et uniques par utilisateur ;
• Multi-entreprise : isolation stricte — chaque compte ne voit que ses propres données ;
• Historique d'audit : toute création, modification, suppression et envoi est tracé (qui, quand, quoi) ;
• Suppression « douce » : un objet supprimé reste traçable et peut être restauré par l'administrateur ;
• Journal des emails : chaque envoi est listé (destinataire, date, statut) ;
• Exports : vos données restent exportables (factures CSV, rapport annuel…).
• Les décisions de signature électronique enregistrent IP et navigateur du client.

Droits des personnes (RGPD) : accès, rectification, effacement, limitation, portabilité et opposition s'exercent auprès de l'entreprise qui traite vos données (votre artisan/client) ; l'éditeur QUOTELUI est sous-traitant et applique ces demandes transmises par l'entreprise.

Politique complète : application → « Confidentialité » (page /confidentialite/, visible dès la page de connexion, sans compte) et Mentions légales (/mentions-legales/).

18 quater. Documents tiers — import ventes & achats (bilan comptable)

Module apps.tiers — import de pièces comptables reçues des clients (recettes) et fournisseurs (dépenses), rattachement aux fiches tiers, bilan annuel harmonisé et transmission à l'expert-comptable. Aucune logique de métier particulier : module 100 % CORE (§45).

Modèle

ThirdPartyDocument — sens RECETTE/DEPENSE, type DEVIS/FACTURE (recette) ou + COMMANDE (dépense), tiers unique (client ou fournisseur, contrôle croisé), montants HT/TVA saisis → TTC calculé en Decimal (jamais de float), statut A_RAPPROCHER/RAPPROCHE, fichier rattaché via le GFK documents.Document existant (upload_document). Suppression logique (fiche et fichier). Migration tiers/0001_initial + companies/0009_companysettings_accountant_email (CompanySettings.accountant_email, email expert-comptable pré-rempli).

Services (apps/tiers/services.py)

• create_document(company, *, direction, kind, document_date, amount_ht, vat_amount, customer, supplier, file, …) — validation complète (sens/type/tiers, extension parmi ALLOWED_EXTENSIONS, 25 Mo max), création atomique fiche + fichier ; update_document, delete_document, mark_reconciled, documents_for (filtres) ;
• send_to_accountant(company, *, year, recipient, by) — envoie le bilan en CSV joint via send_email (journalisé EmailLog), horodate sent_at sur les pièces de l'année.

Bilan (apps/tiers/reporting.py, pur)

accounting_summary(company, year) : recettes = factures émises (hors annulées) + pièces de recette ; dépenses = pièces de dépense + factures fournisseurs suivies sur les commandes (supplier_invoice_*) ; net TTC, pièces à rapprocher, dernier envoi. La clé facturation embarque le résultat de annual_data (mois, TVA par taux, encaissement) — source unique avec l'écran Export comptable (§10 bis.5) : les deux affichent les mêmes chiffres par construction. Chaque ligne porte sa devise (invoice.currency / order.currency ; pièces importées = EUR, le modèle n'a pas de champ devise). bilan_csv : format comptable FR (;, BOM UTF-8, décimales à la virgule), colonnes Sens;Source;Pièce;Tiers;Date;Devise;HT;TVA;TTC;Détail.

Web (routes /documents-tiers/)

Liste (filtres sens/type/statut/année/texte), import (drag & drop + bouton Parcourir), fiche/édition, rapprochement, suppression, bilan (années, cartes recettes/dépenses/net, facturation par mois + TVA par taux + encaissement repris de l'export, CSV, envoi à l'expert-comptable ; lien croisé « Synoptique factures » ↔ l'export renvoie « Bilan complet »). Capacités : THIRDDOC_VIEW (LECTEUR+) / THIRDDOC_MANAGE (MANAGER+), même matrice web et API. Carte « Documents tiers » sur /statistiques/ ; provider pièces tiers dans la recherche globale.

API

GET/POST /api/documents-tiers/ (+ PATCH/DELETE, action rapprocher/) ; création multipart avec le champ file ; mêmes validations que les services (THIRDDOC_VIEW/THIRDDOC_MANAGE).

Envoi à l'expert-comptable

Depuis le bilan : destinataire saisi ou repris de Réglages → Email de l'expert-comptable ; objet « Bilan comptable AAAA — entreprise » ; pièce jointe bilan-comptable-AAAA.csv ; trace EmailLog (SENT/FAILED) et sent_at sur les pièces. Email de transport = boîte configurée Phase 10 / auto-gérée (§20) ; aucun envoi automatique — action explicite uniquement.

18 quater.1. Extraction automatique & doublons des documents tiers (V4.5)

Suite du module apps.tiers — aucun modèle ni migration : lecture locale d'un fichier déposé, proposition de saisie, puis rapprochement des fiches tiers en doublon. Tout reste sous contrôle de l'utilisateur (l'extraction propose, jamais n'écrit tout seul).

Extraction (apps/tiers/extracting.py, pur)

• extract_text(file) → (texte, moteur) : couche texte du PDF (pypdf, prioritaire quand elle existe) ; sinon rasterisation (pypdfium2, 5 pages max, sans dépendance système) + OCR Tesseract fra (pytesseract) ; images → OCR direct (Pillow, EXIF, 3500 px) ; .txt/.csv décodés (UTF-8/UTF-8-sig/latin-1) ; format non pris en charge (.docx…) ou échec → ExtractionError à message FR (« saisie manuelle »). Borne fichiers = _clean_file existant (25 Mo, extensions contrôlées). Le curseur fichier est réinitialisé.
• parse_text(text) → dict JSON-able sans objet métier : kind (FACTURE/DEVIS/COMMANDE — priorité à l'en-tête, une ligne « Facture n° … bon de commande » reste une facture), reference, date (FR/ISO, priorité à la date d'émission), amount_ht/vat_amount/ amount_ttc (Decimal en texte, virgule française, NBSP tolérés ; TVA déduite HT→TTC si absente ; HT+TVA≠TTC → warning), party (émetteur : nom forme juridique, SIRET, TVA FR, email, tel, rue/CP/ville)
• recipient (bloc « Facturé à ») + warnings. Aucun montant inventé : ce qui n'est pas trouvé reste vide. Robustesse mise en page réelle (retours terrain V4.5 bis) :
• un libellé et son montant sur deux lignes (« Total HT : » puis « 2450.00 € ») est lu — on retient le dernier candidat (les totaux sont en fin de document) et on refuse les lignes de tableau (plusieurs montants) ;
• TVA multi-taux : toutes les lignes « TVA (x%) » sont cumulées (13,75 + 440,00 = 453,75) ; si l'une d'elles vaut déjà la somme des autres (« Dont TVA »), elle est prise seule (pas de double compte) ;
• référence : n°/no jamais à l'intérieur d'un mot (le « no » de « l'innovation » produisait « VATION ») et valeur candidate doit contenir un chiffre → « Référence du devis : DEV-2026-0043 » est lu correctement ;
• ville avec pays (« 75001 Paris, France ») et TVA espacée (« FR 12 123456789 ») acceptées.

Tiers (apps/tiers/parties.py)

• normalize_name (NFKD→ASCII, casse, S.A.S.→SAS, formes juridiques retirées), siret_key (SIRET 14 → SIREN, TVA FR 11 → décalage 2, 9 déjà SIREN, sinon "").
• resolve_party : si l'émetteur est notre entreprise (SIREN ou nom normalisé) → le tiers est le destinataire (pièce qu'on a émise) ; si le destinataire est déjà un client connu (SIREN/nom) → pièce traitée en recette côté ce client, même si l'émetteur n'est pas reconnu comme nous (avertissement affiché, sens restant modifiable à la main) ; sinon l'émetteur. choose_direction : COMMANDE→DEPENSE, émetteur = nous ou inconnu→RECETTE, reçu→DEPENSE.
• Case « L'émetteur est ma société » (formulaire web, visible après lecture) : un clic bascule le sens en recette et rattache la pièce au destinataire (client) — pour les documents émis par soi que l'extraction n'a pas su attribuer à l'entreprise (émetteur non reconnu). Le JSON d'analyse expose issuer/recipient/ recipient_match (party_match_payload), la case restaure l'état initial en se décochant (tiers_extract.js → applyIssuerIsMe).
• match_party : correspondance côté client et fournisseur par SIREN puis nom normalisé — renvoie mixed quand l'identité existe des deux côtés (profil mixte : rattachable, jamais fusionné §45).
• create_proposed_party : création de la fiche proposée au moment de l'import (new_party=1 côté web) — capacité CUSTOMER_MANAGE (client : kind ENTREPRISE si forme juridique/SIRET, sinon PARTICULIER prénom/nom + set_billing_address) ou SUPPLIER_MANAGE (fournisseur) vérifiée côté serveur.

Doublons (apps/tiers/duplicates.py)

• duplicate_groups(company) — lecture seule : union-find par SIREN identique / même nom sur clients actifs puis fournisseurs actifs + liste mixed (identité des deux côtés).
• merge_customers / merge_suppliers — la maîtresse absorbe les dossiers FK du doublon (_meta.related_objects, filtrés par company) : pièces tiers, contacts, devis, factures, chantiers, affaires, commandes… puis soft_delete du doublon (audit SOFT_DELETE). Unicité SQL unique_supplier_price_per_product : prix déjà maîtrisé → la ligne du doublon est archivée (dropped), jamais supprimée. Capacités CUSTOMER_MANAGE/SUPPLIER_MANAGE (par by) — les montants ne sont jamais modifiés, seuls les rattachements changent.

Web (suite /documents-tiers/)

• POST /documents-tiers/analyser/ (THIRDDOC_VIEW) → JSON {engine, kind, direction, reference, date, amounts, party, match, warnings} — aucune écriture ;
• formulaire d'import : tiers_extract.js (fetch vanilla, enclenché par Alpine setFile après contrôle format/taille) remplit le DOM et dispatch change (selects x-model suivent) ; bannières statut + correspondance ; bloc « Créer ce tiers maintenant » (new_party + new_party_*) affiché si match.type=new, refermé si l'utilisateur choisit lui-même un tiers ;
• champs masqués tant que la lecture n'a pas échoué (retour terrain) : l'écran initial = zone de dépôt + lien « saisir les informations manuellement » ; tiers_extract.js émet tiers:extracted / tiers:failed sur le formulaire, Alpine bascule les drapeaux fileChosen/readOk/readFailed/partial/editDetails et x-show="detailsVisible()" ne révèle les champs détaillés (sens, type, n°, date, montants) qu'en échec/partial/édition manuelle ; en cas de lecture complète, un résumé vert (« Lu automatiquement — … ») remplace les champs avec boutons Modifier/Masquer les champs ; les sélecteurs client/fournisseur restent toujours visibles (action requise si aucun match) ; garde-fou @submit : montant HT manquant sous champs cachés → révélation + message ;
• GET /documents-tiers/doublons/ (THIRDDOC_VIEW) : groupes par section (clients / fournisseurs) + profils mixtes (jamais fusionnés) ; POST /documents-tiers/doublons/fusionner/ (THIRDDOC_MANAGE) : radio « fiche à garder » + bouton « Fusionner ce doublon » par membre (plusieurs clics pour N doublons) ;
• lien « Doublons » depuis la liste.

Dépendances : pypdf, pypdfium2, pytesseract (pyproject) + paquets système tesseract-ocr tesseract-ocr-fra (Dockerfile). Tests : tests/test_thirdparty_extraction.py (72) — parseur FR, PDF à couche texte, OCR réel skipUnless(tesseract), rattachement/directions, groupes/fusions (y c. prix en conflit), écrans + capacités + isolation.

Piège de déploiement (NAS) : en prod le static vit dans le volume static_data (nginx le sert en ro) — collectstatic est à lancer après chaque déploiement (docker-compose exec web python manage.py collectstatic --noinput, rappelé en commentaire de compose.synology.yml) : sans lui, tiers_extract.js est servi vide et l'extraction ne se déclenche jamais (constaté sur V2). Pire : une copie 0 octet reste collée par le Cache-Control: max-age=604800 de nginx sur /static/et par le cache cache-first du service worker — d'où le triple remède actuel (SW quotelui-static-v2 réseau d'abord + no-cache, ?v= sur l'URL du script, message explicite si le script d'extraction est absent au lieu d'un no-op silencieux).

18 quater.2. Workflow des documents tiers (brouillon / validation / facture / lien)

Suite du module apps/tiers — machine d'états des pièces + deux scénarios de facturation, sans toucher au core (les services factures existants sont appelés, jamais modifiés). migration tiers/0002.

Statuts

BROUILLON (Brouillon) → EN_VALIDATION (En validation) → A_RAPPROCHER (À rapprocher) → RAPPROCHE (Rapproché) ; états terminaux FACTURE (Facturé) et LIE (Lié — facture externe). Les pièces importées restent par défaut en À rapprocher (zéro rupture : comptabilisées tout de suite). Brouillon / En validation sont des états optionnels (création manuelle ou API, bouton « Envoyer pour validation »).

• send_for_validation(document) : BROUILLON|A_RAPPROCHER → EN_VALIDATION (idempotent) ;
• approve_validation(document) : EN_VALIDATION → A_RAPPROCHER (la pièce compte dans le bilan) ;
• transitions interdites sur les états terminaux (Facturé / Lié) : mark_reconciled et update_document sont refusés, message explicite.

Scénario A — « Générer une facture » (RECETTE validée uniquement)

generate_invoice_from_piece(document, by=) → crée une facture interne via create_invoice + add_line (services factures inchangés) : ligne unique (libellé = n° de pièce ou type, PU = HT de la pièce, qté 1, taux TVA déduit de la TVA de la pièce, arrondi 0,01 %), facture née en BROUILLON dans le module Factures (numéro FAC-YYYY-NNNN auto) — l'artisan la revoit puis l'envoie avec l'existant. La pièce bascule en FACTURE avec FK invoice (PROTECT) : elle sort des pièces du bilan et compte via la facture (zéro trou, zéro double compte — même total TTC). Le type de la pièce n'est pas bloquant : un devis importé depuis un autre outil peut aussi devenir une facture (utile quand le devis client sort d'une autre application et qu'il faut l'encaisser ici).

Scénario B — « Lier à une facture externe »

link_external_invoice(document, number, date, amount, source) : la facture est émise par une autre application → champs external_number/date/amount/source/linked_at, pièce en LIE. La pièce reste dans le bilan (choix produit : le lien est une simple annotation — la facture externe n'existe pas comme objet Quotelui, donc zéro double compte, bilan complet) et est dispensée du rapprochement. unlink_external_invoice(document) retire la liaison (champs effacés, retour à « À rapprocher ») en cas d'erreur de saisie. Une pièce LIE ne peut plus devenir une facture interne (jamais de deux factures pour une même opération) : déliez d'abord.

Comptabilité (reporting._piece_rows)

Entrent dans les recettes et dépenses du bilan : A_RAPPROCHER, RAPPROCHEet LIE (annotation d'une facture externe — comptée puisqu'elle n'existe pas ici) ; exclus : brouillon / en validation / FACTURE (comptée via sa facture générée). annual_data (factures émises) intact ; les cartes statistiques héritent via accounting_summary.

Écrans & API

• Fiche pièce : badges par statut (slate/ambre/indigo/violet), boutons Envoyer pour validation / Valider (compte dans le bilan) / Générer une facture (redirige vers la facture créée) / Lier à une facture externe… (formulaire n°/date/montant/application) ; sur pièce liée : « Délier la facture externe » ; bloc « Facture générée » (lien vers la facture) ou champs externes ; rapprochement visible seulement sur les statuts comptabilisés hors LIE ; liste : badge couleur aligné ;
• API : POST /api/documents-tiers/{pk}/send-validation/ · approve/ · generate-invoice/ (répond generated_invoice + generated_invoice_number) · link-external/ (number, date, amount, source) · unlink-external/ ; invoice + external_* exposés en lecture.

Tests : tests/test_tiers_workflow.py (22) — transitions, exclusions bilan, génération (taux déduit, zéro trou), refus (DEPENSE, brouillon, HT nul, déjà facturée, liaison sur terminal), édition refusée en terminal, écrans web (boutons par statut, redirection facture, 403 LECTEUR) + API bout en bout.