# Spécifications fonctionnelles détaillées — Walk The Line Management **Version fonctionnelle documentée : V15.3** **Application : Symfony 7.4 / PHP 8.2+** ## 1. Objet et principes directeurs Walk The Line Management est un back-office associatif multi-projets destiné à centraliser le cycle de vie commercial, administratif, technique, documentaire et financier de plusieurs projets artistiques gérés par une même association. L'application applique quatre niveaux de données : 1. **Association** : identité légale, utilisateurs, comptabilité, comptes financiers, conventions, facturation, documents transversaux. 2. **Projet artistique** : identité visuelle légère, tarifs, frais, prospections, dates, technique, plans de scène, préparation du site public. 3. **Données partagées** : lieux et contacts réutilisables par tous les projets. 4. **Documents historiques** : PDF générés et pièces comptables conservés de manière immuable ou versionnée selon leur nature. Principes UX : - rendre le projet actif visible à tout moment ; - privilégier les wizards, modales et actions rapides ; - automatiser les classements calculables ; - éviter les doubles saisies et réuploads ; - rendre les écrans utilisables par un non-informaticien ; - conserver l'historique plutôt que remplacer silencieusement les objets déjà utilisés. --- ## 2. Utilisateurs, rôles et sécurité ### 2.1 Hiérarchie - `ROLE_USER` : rôle de base ; - `ROLE_PRESSE` : accès presse, hérite de `ROLE_USER` ; - `ROLE_ADMIN` : accès au back-office, hérite de `ROLE_PRESSE` ; - `User.isSuperAdmin` : drapeau additionnel pour les opérations sensibles. ### 2.2 Super administrateur Le super administrateur peut notamment : - gérer les utilisateurs ; - créer et administrer les projets artistiques ; - supprimer certaines données opérationnelles lorsque les règles métier l'autorisent ; - utiliser la maintenance ; - importer/exporter les lieux et contacts ; - réinitialiser les données de démonstration. Les contrôles sont réalisés côté serveur et non uniquement par masquage des boutons. --- ## 3. Architecture multi-projets ### 3.1 Entité `ArtisticProject` Un projet artistique représente un groupe, spectacle ou projet solo géré par l'association. Données principales : - code ; - nom ; - slug ; - statut `DRAFT`, `ACTIVE`, `ARCHIVED` ; - couleur principale ; - couleur secondaire ; - identité documentaire ; - paramètres du futur site public ; - informations de complétude. ### 3.2 Projet actif Un service de contexte conserve le projet actif pour la navigation du back-office. Le projet actif est : - affiché en permanence dans la barre latérale ; - rappelé dans l'en-tête des pages contextualisées ; - identifié par ses couleurs ; - modifiable par le sélecteur `Changer de projet`. ### 3.3 Données propres au projet Sont notamment contextualisés : - prospections ; - dates de concert ; - tarifs ; - frais annexes ; - profils techniques ; - paramètres techniques ; - patch audio ; - matériel ; - intentions / effets ; - accueil technique ; - blocs rédactionnels ; - éléments scéniques spécifiques ; - plans de scène ; - fiches techniques ; - documents propres au projet ; - configuration publique. ### 3.4 Données communes Restent communes à l'association : - lieux ; - contacts ; - utilisateurs ; - modèles de convention ; - numérotation des devis/factures ; - comptabilité ; - comptes financiers ; - bibliothèque documentaire transversale. --- ## 4. Création d'un projet artistique La création est réservée au super administrateur et suit un wizard long mais guidé. ### 4.1 Préambule Une page introductive explique les informations à préparer : identité, logos, couleurs, tarifs, frais, technique, patch, matériel, accueil, éléments scéniques, plans et site public. ### 4.2 Brouillon et reprise Le projet est créé en statut `DRAFT`. Le wizard : - sauvegarde la progression ; - peut être interrompu ; - peut être repris ultérieurement ; - permet de revenir sur les étapes déjà visitées. ### 4.3 Préremplissage Pour réduire la saisie initiale, certaines configurations peuvent être reprises comme base depuis le projet de référence, puis deviennent indépendantes du projet source. ### 4.4 Complétude Le système expose trois états : - **Prêt pour la prospection** ; - **Prêt pour la production** ; - **Prêt pour le site public**. La complétude n'empêche pas nécessairement l'usage partiel du projet : un projet peut commencer sa prospection avant que son site public soit terminé. --- ## 5. Référentiel des lieux et contacts ### 5.1 `Venue` Un lieu est durable et partagé entre tous les projets. Informations principales : - nom / raison sociale ; - type ; - adresse ; - ville / CP / pays ; - jauge ; - budget indicatif ; - SIRET / TVA ; - e-mail de facturation ; - site ; - notes administratives ; - statut ; - identifiant externe. Statuts : `ACTIVE`, `CLOSED`, `ARCHIVED`. ### 5.2 `VenueContact` Un lieu possède plusieurs contacts : - identité / fonction ; - type de contact ; - e-mail ; - téléphone ; - principal ou secondaire ; - notes ; - identifiant externe. La sélection des contacts d'une prospection est filtrée par lieu et le contact principal peut être présélectionné automatiquement. --- ## 6. Prospection ### 6.1 Entité centrale `Prospection` représente une campagne commerciale propre à un projet artistique et à un lieu. ### 6.2 Wizard de création Trois étapes : 1. **Lieu** : lieu + priorité ; 2. **Contact** : contact ciblé + canal + premier contact ; 3. **Suivi** : statut, relances, tarif proposé, accueil, chapeau, notes. Les contacts sont chargés dynamiquement au passage de l'étape 1 à l'étape 2. ### 6.3 Historique et responsabilité `ProspectionEvent` conserve les événements et l'utilisateur associé lorsque disponible. Responsabilités suivies : créateur, premier contact, relances, proposition, décision, date réalisée, etc. ### 6.4 Prochaine action `ProspectionScheduleService` calcule automatiquement la prochaine action à partir des dates et règles configurées. ### 6.5 Suggestions `ProspectionSuggestionService` calcule les lieux à prospecter/recontacter à partir de l'historique, du délai d'inactivité, du budget et des contacts. --- ## 7. Dates de concert ### 7.1 `ConcertDate` Une date confirmée est distincte de la prospection et rattachée au projet. Données : - lieu ; - date et horaires ; - titre / description publics ; - affiche ; - billetterie / réservation / lien externe ; - visibilité ; - publication différée ; - complet ; - mise en avant ; - annulation ; - report ; - slug. ### 7.2 Historique de report `ConcertDateHistory` conserve ancienne date, nouvelle date, motif, date du changement et utilisateur. ### 7.3 Préparation du site public Les repositories distinguent dates publiées à venir et archives. Le futur frontend est résolu par domaine/projet via `ArtisticProjectDomain`, tout en restant libre graphiquement. --- ## 8. Tarification et frais annexes Les tarifs et frais annexes sont propres au projet actif. Le simulateur calcule les composantes suivantes : - formule / cible ; - trajet / stationnement ; - repas / nuit artiste et accompagnateur ; - techniciens supplémentaires ; - options ; - autres frais ; - remise commerciale. Les paramètres sont éditables dans le back-office. --- ## 9. Devis et factures ### 9.1 `CommercialDocument` Deux types principaux : - devis ; - facture. Numérotation annuelle indépendante : - `D-AA-XXXX` ; - `F-AA-XXXX`. La numérotation reste commune à l'association. ### 9.2 Génération PDF Les PDF : - utilisent les données figées du document ; - intègrent l'identité documentaire du projet ; - restent immuables une fois générés ; - sont stockés via `Document` / `DocumentContent`. ### 9.3 Conversion devis → facture Une facture est générée à partir d'un devis existant. À sa création : - le PDF est figé ; - le document est automatiquement référencé dans la GED comptable ; - aucun réupload manuel n'est nécessaire. --- ## 10. Paiements et statut des factures ### 10.1 `Payment` Un paiement est lié à une facture et contient notamment : - date ; - montant ; - compte financier ; - moyen de paiement ; - référence ; - notes ; - exercice et période comptables. Une facture peut recevoir plusieurs paiements. ### 10.2 Statut calculé Le statut est dérivé du total encaissé : - **À encaisser** ; - **Partiellement payée** ; - **Payée**. ### 10.3 Accès rapides L'enregistrement d'un paiement est possible depuis : - la fiche facture ; - `Devis & factures` ; - la liste des prospections si une vraie facture existe ; - le dashboard projet ; - le dashboard comptable. ### 10.4 Correction Un paiement peut être modifié ou supprimé. Le statut de facture et le classement comptable sont recalculés. Un contrôle empêche de dépasser le total TTC de la facture. --- ## 11. Conventions Les `ConventionTemplate` sont communs à l'association. Une `Convention` : - est liée à une prospection ; - est générée à partir d'un devis précis ; - conserve son modèle/version ; - produit un PDF immuable ; - peut être supprimée uniquement dans les cas autorisés. La mini-GED des conventions regroupe devis, facture, convention et fiches techniques liés au dossier. --- ## 12. Module technique multi-projet ### 12.1 Référentiels Sont gérés par projet : - `TechnicalGeneralSetting` ; - `TechnicalProfile` ; - patch audio ; - matériel ; - effets / intentions ; - accueil technique ; - blocs rédactionnels ; - modèles de fiches techniques. ### 12.2 Wizard de fiche technique Trois modes : 1. utiliser une fiche existante ; 2. personnaliser un modèle ; 3. créer une fiche spécifique. Le wizard reste dans la modale de prospection. ### 12.3 Cycle de vie Une fiche non envoyée peut être supprimée selon son origine. Une fiche envoyée est automatiquement validée et devient protégée. --- ## 13. Plans de scène et éléments scéniques ### 13.1 `StagePlan` Un plan est propre au projet et versionné. L'unicité porte sur le projet, le code et la version afin que plusieurs groupes puissent réutiliser le même code logique. ### 13.2 `StageElementType` / affectation projet Deux catégories d'éléments : - éléments système réutilisables ; - éléments spécifiques à un projet. L'affectation d'un élément système à un projet enrichit sa palette sans supprimer les éléments historiques déjà disponibles. ### 13.3 Éditeur Fonctions : - drag & drop ; - grille ; - numéros sur le plan ; - légende séparée ; - renommage ; - duplication ; - rotation ; - agrandissement/réduction ; - suppression ; - raccourcis clavier. Les layouts historiques Walk The Line sont conservés. --- ## 14. Stockage documentaire / GED générale ### 14.1 `Document` Métadonnées : - code ; - version ; - type ; - nom ; - nom original ; - MIME ; - extension ; - taille ; - checksum ; - dates ; - auteur ; - état ; - description ; - droits public/presse/admin ; - `documentContentId`. ### 14.2 `DocumentContent` Stockage BLOB séparé afin d'éviter de charger les contenus binaires dans les listes. ### 14.3 Immutabilité et versionnage - devis, factures, conventions et fiches spécifiques générées sont immuables ; - documents ordinaires : versionnage possible ; - pièce comptable : pas de nouvelle version depuis la bibliothèque globale ; une nouvelle pièce distincte doit être ajoutée. --- ## 15. Architecture comptable Le module comptable est global à l'association. Entités principales : - `AccountingYear` ; - `AccountingPeriod` ; - `FinancialAccount` ; - `Expense` ; - `ExpenseCategory` ; - recette exceptionnelle ; - `Payment` ; - `PaymentMethod` ; - `MerchSale` ; - `ExternalContract` ; - `VatRegimePeriod` ; - `AccountingDocumentLink`. Objectif : simplifier la tenue et la préparation des éléments comptables sans transformer le logiciel en ERP complet. --- ## 16. Exercices et périodes automatiques ### 16.1 Génération `AccountingCalendarManager` garantit la présence des exercices/périodes nécessaires sans intervention manuelle. Le système peut créer : - exercice courant ; - exercice suivant ; - périodes comprises dans les dates réelles de l'exercice. ### 16.2 Début comptable de l'association Le premier exercice est tronqué à la date de début comptable. Exemple : - début comptable : 01/10/2026 ; - premier exercice : 01/10/2026 → 31/12/2026 ; - périodes attendues : octobre, novembre, décembre uniquement. --- ## 17. Comptes financiers `FinancialAccount` représente : - compte bancaire ; - prestataire de paiement tel que SumUp ; - caisse ; - autre compte financier. Informations : - nom ; - type ; - fournisseur/prestataire ; - IBAN éventuel ; - date d'ouverture ; - date de fermeture ; - actif ; - attente ou non d'un relevé mensuel. Un relevé ne peut être considéré manquant avant l'ouverture du compte. --- ## 18. Dépenses / prestations ### 18.1 `Expense` Informations : - date ; - fournisseur/prestataire ; - libellé ; - catégorie ; - projet nullable ; - HT ; - taux de TVA ; - TVA ; - TVA déductible ; - TTC ; - compte financier ; - moyen de paiement ; - date de paiement ; - notes ; - auteur ; - exercice/période. ### 18.2 Saisie L'interface accepte une saisie orientée HT ou TTC et recalcule les montants complémentaires. ### 18.3 Justificatif obligatoire Toute nouvelle dépense doit recevoir un justificatif. Le document : - est stocké dans `Document` / `DocumentContent` ; - est lié via `AccountingDocumentLink` ; - est classé automatiquement dans l'exercice, le mois et la catégorie GED ; - n'est pas dupliqué. Les anciennes dépenses sans pièce peuvent être régularisées via `Ajouter justificatif`. ### 18.4 Modification La dépense est éditable en modale. Un changement de date, projet ou compte réaligne le classement documentaire. --- ## 19. Recettes ### 19.1 Paiements de factures Les recettes commerciales sont dérivées des paiements réels et non uniquement des factures émises. ### 19.2 Recettes exceptionnelles Saisie manuelle pour : - dons ; - cotisations ; - subventions ; - remboursements ; - autres recettes. Elles peuvent être affectées à un projet ou rester communes à l'association. --- ## 20. Vente merchandising `MerchSale` enregistre un récapitulatif simple de vente : - date ; - projet ; - libellé ; - TTC ; - TVA comprise ; - HT dérivé ; - compte financier ; - moyen de paiement ; - frais prestataire ; - notes. Les frais SumUp/prestataire sont comptabilisés séparément comme sortie afin de conserver : - recette brute ; - frais de transaction ; - montant net. La gestion détaillée des stocks est préparée mais n'est pas imposée dans la V15. --- ## 21. Contrats / sous-traitance `ExternalContract` conserve : - objet ; - prestataire ; - début / fin ; - projet nullable ; - HT / TVA / TTC ; - statut ; - notes. Lors de la création ou plus tard, il est possible d'ajouter : - contrat ; - devis prestataire ; - facture prestataire ; - autre pièce. Ces documents sont automatiquement envoyés dans la GED comptable dans la catégorie appropriée. --- ## 22. GED comptable ### 22.1 Principe `AccountingDocumentLink` associe un document existant à : - exercice ; - période ; - type comptable ; - projet ou compte ; - source métier. Il ne duplique pas le BLOB. ### 22.2 Classement automatique Arborescence logique : - année ; - mois ; - catégorie. Catégories visibles : - factures émises ; - justificatifs dépenses ; - relevés bancaires / SumUp ; - factures fournisseurs ; - devis prestataires ; - contrats / sous-traitance ; - assurances / échéanciers ; - TVA / déclarations ; - autres pièces. ### 22.3 Vue arbre La GED utilise : - dossiers repliables ; - compteurs ; - `Tout déplier` ; - `Tout replier` ; - recherche instantanée. --- ## 23. TVA ### 23.1 Historisation `VatRegimePeriod` mémorise : - date de début ; - date de fin nullable ; - régime ; - fréquence. Le régime peut donc évoluer sans réécrire l'historique. ### 23.2 Assistant TVA L'écran TVA calcule pour une période : - TVA collectée estimée ; - TVA déductible ; - solde indicatif. Les périodes antérieures à l'assujettissement ne sont pas traitées comme déclarations manquantes. L'assistant prépare les chiffres ; il ne constitue pas une télédéclaration officielle. --- ## 24. Tableau de bord comptable La page `Comptabilité` expose : - recettes encaissées ; - dépenses ; - résultat de trésorerie ; - factures à encaisser ; - derniers mouvements ; - raccourcis vers GED, contrats, vente merch., comptes et TVA. Les factures non payées ou partiellement payées peuvent recevoir un paiement sans quitter le dashboard. --- ## 25. Identité visuelle Chaque projet dispose d'une mini-thématisation : - couleur principale ; - couleur secondaire ; - logos/identité documentaire. Utilisations : - repérage du projet actif ; - états actifs du menu ; - accents dans le back-office ; - PDF. Cette configuration ne pilote pas le frontend public. --- ## 26. Futurs sites publics multi-domaines `ArtisticProjectDomain` prépare la résolution : `nom de domaine → projet artistique → frontend`. Chaque projet pourra utiliser : - structure Twig indépendante ; - CSS/JS indépendants ; - navigation différente ; - identité graphique totalement différente. Les données publiques restent issues du même back-office. --- ## 27. Gestion des accès utilisateurs et matrice de permissions ### 27.1 Administration des comptes La page `Administration → Utilisateurs` est réservée aux super administrateurs. Fonctions : - création d'un compte ; - modification nom/e-mail ; - réinitialisation du mot de passe ; - activation/désactivation ; - promotion/retrait super administrateur ; - affectation à un ou plusieurs projets artistiques ; - affectation à un ou plusieurs groupes fonctionnels. Les comptes historiques ne sont pas supprimés lorsqu'ils ont participé à des opérations : ils sont désactivés afin de conserver les références d'audit. ### 27.2 Affectation aux projets `User` possède une relation ManyToMany vers `ArtisticProject`. Règles : - super administrateur : tous les projets ; - utilisateur normal : uniquement les projets affectés ; - le sélecteur de projet est filtré par ces affectations ; - un utilisateur possédant des permissions propres aux projets doit disposer d'au moins un projet ; - les contrôles serveur interdisent l'accès direct à un objet appartenant à un projet non autorisé ; - les documents spécifiques à un projet suivent la même règle. ### 27.3 Groupes fonctionnels Le système utilise `UserGroup` et `UserGroupPermission`. Groupes système créés par la migration : - Administrateur projet ; - Prospecteur ; - Technique ; - Trésorier ; - Lecture seule. Le super administrateur peut créer d'autres groupes. Un utilisateur peut appartenir à plusieurs groupes : le niveau effectif pour une fonction est alors le niveau maximum accordé par l'un de ses groupes actifs. ### 27.4 Matrice de permissions L'écran `Administration → Groupes & permissions` affiche une matrice à double entrée : - lignes : fonctions métier ; - colonnes : groupes utilisateurs. Chaque cellule est cliquable et fait évoluer le niveau jusqu'au maximum autorisé par la fonction : - `NONE = 0` : Aucun ; - `READ = 1` : Lecture ; - `WRITE = 2` : Lecture / écriture ; - `DELETE = 3` : Lecture / écriture / suppression. `WRITE` implique `READ`. `DELETE` implique `WRITE` et `READ`. Certaines fonctions ont un niveau maximal inférieur à `DELETE` lorsqu'une suppression n'a pas de sens fonctionnel. ### 27.5 Catalogue fonctionnel Le catalogue couvre notamment : - Dashboard et À traiter ; - Prospections ; - Lieux & contacts ; - Devis ; - Factures ; - Paiements ; - Simulateur ; - Dates ; - Fiches techniques ; - Plans de scène ; - Tarifs ; - Frais ; - Configuration technique ; - Éléments scéniques ; - Conventions ; - Documents ; - Comptabilité ; - Vente merch. ; - Recettes exceptionnelles ; - Dépenses ; - Contrats / sous-traitance ; - GED comptable ; - TVA ; - paramétrages associatifs/commerciaux/comptables et référentiels. ### 27.6 Effets des permissions Les permissions pilotent simultanément : - visibilité du menu ; - boutons d'action ; - tableaux de bord ; - formulaires d'écriture ; - accès direct aux routes ; - accès aux documents sensibles. Exemple : si le groupe Prospecteur a `Factures = Aucun`, ses utilisateurs : - ne voient pas les factures dans `Devis & factures` ; - ne peuvent pas convertir un devis en facture ; - ne voient pas les factures à encaisser sur le dashboard ; - ne peuvent pas ouvrir directement une facture par URL ; - ne voient pas les actions d'encaissement liées aux factures. La permission `Paiements` est indépendante de `Factures` et contrôle la création, correction et suppression des paiements. ### 27.7 Super administrateur `User.isSuperAdmin` court-circuite la matrice : - toutes les permissions ; - tous les projets ; - gestion des utilisateurs ; - gestion des groupes et de la matrice ; - gestion des projets ; - maintenance. Les groupes système restent configurables dans la matrice mais ne peuvent pas être supprimés. ### 27.8 Accès sans permission back-office Un compte authentifié ne possédant aucune permission fonctionnelle de back-office n'accède pas à `/admin`. Après connexion, il est redirigé vers la page de login avec un message explicite indiquant que son compte ne dispose pas des droits nécessaires. Un compte presse reste orienté vers l'espace presse. ### 27.9 Règles métier prioritaires La matrice ne contourne jamais les règles d'intégrité métier. Par exemple, un niveau `Suppression` ne permet pas de supprimer un document historique déclaré immuable ou un objet dont le cycle de vie interdit la suppression. --- ## 28. Maintenance et import/export ### 28.1 Import/export lieux et contacts XLSX avec identifiants externes stables et prévisualisation avant import. Rapprochement : - lieux : externalId, SIRET, identité métier ; - contacts : externalId, e-mail, téléphone, identité + lieu. ### 28.2 Reset de démonstration Réservé au super administrateur et protégé par CSRF + saisie `RESET`. Les données de configuration essentielles sont conservées selon `DemoResetService`. --- ## 29. Contraintes d'intégrité 1. Un lieu n'est jamais dupliqué pour un nouveau projet. 2. Les objets générés officiellement sont figés. 3. Les pièces comptables ne sont pas remplacées par versionnage. 4. Les BLOBs ne sont pas chargés dans les listes. 5. Les suppressions destructrices sont limitées. 6. Les changements financiers conservent leur rattachement temporel. 7. Les filtres de projet sont appliqués à toutes les données spécifiques. 8. Les objets communs restent disponibles quel que soit le projet actif. 9. Le schéma Doctrine doit rester strictement aligné avec les migrations. 10. `doctrine:schema:update --force` n'est pas utilisé en production. --- ## 30. Technologies et exploitation - PHP 8.2+ ; - Symfony 7.4 ; - Doctrine ORM + Migrations ; - Twig ; - Bootstrap ; - DataTables ; - Select2 ; - Chart.js ; - MariaDB/MySQL compatible ; - `symfony/mime` ; - `ZipArchive` pour XLSX ; - stockage BLOB séparé ; - Docker Desktop supporté pour le développement ; - fichiers texte livrés en CRLF. --- ## 31. Règles de conception futures Toute évolution doit : - rester accessible à un utilisateur non technique ; - automatiser le classement lorsqu'il est déductible ; - préserver le multi-projet ; - préserver le caractère commun de la comptabilité associative ; - éviter la ressaisie d'un document déjà généré ; - historiser les changements de régime et de période ; - garder une distinction nette entre gestion interne et sites publics.