Module Chantiers¶

Objectif¶

Le module Chantiers pilote le cycle operationnel d'un chantier Solutravo : creation depuis une opportunite ou un document commercial, suivi kanban, lots et taches, planning, achats, acces collaborateurs, sous-traitance, documents, reception/PV, signature et suivi financier.

La reprise du module doit se faire comme un ensemble coherent. Les ecrans "Chantiers", "PV de fin de chantier", "Finances des chantiers" et "Sous-traitants des chantiers" partagent des donnees et des invariants metier. Une modification locale sur le PV, les achats ou la finance peut casser un flux voisin.

Architecture fonctionnelle¶

flowchart LR
  Router[Router.php] --> Management[ChantierManagementController]
  Router --> PV[ChantierController]
  Router --> Finance[ChantierFinanceController]
  Router --> Subcontractor[ChantierSubcontractorController]

  Management --> ManagementModel[ChantierManagementModel]
  PV --> PVModel[ChantierModel]
  Finance --> FinanceModel[ChantierFinanceModel]
  Subcontractor --> SubcontractorModel[ChantierSubcontractorModel]

  ManagementModel --> DB[(MySQL)]
  PVModel --> DB
  FinanceModel --> DB
  SubcontractorModel --> DB

  Management --> Views[Views chantier]
  PV --> Signature[Pages PV/signature]
  Finance --> FinanceView[Vue finance]
  Subcontractor --> SubcontractorView[Vue sous-traitants]

Perimetre documente¶

Cette page documente les fichiers listes dans les points d'entree ci-dessous. Avant une correction, ouvrir ces fichiers dans la branche de travail concernee et verifier l'historique git du module si le comportement observe ne correspond pas a la documentation.

Points d'entree¶

Controleurs¶

app/controllers/ChantierManagementController.php : tableau de bord principal, liste, kanban, planning, documents, achats, acces collaborateurs, rattachements devis/factures.
app/controllers/ChantierController.php : flux PV de chantier, signature presentielle ou distante, declaration de paiement liee au PV, generation PDF.
app/controllers/ChantierFinanceController.php : revenus, achats affectes, categories de depense, marges.
app/controllers/ChantierSubcontractorController.php : sous-traitants, affectations, invitations, conversations.

Modeles¶

app/models/ChantierManagementModel.php : modele central du module operationnel.
app/models/ChantierModel.php : modele du PV, signature et paiement declare.
app/models/ChantierFinanceModel.php : modele des donnees financieres chantier.
app/models/ChantierSubcontractorModel.php : modele sous-traitants, invitations et affectations.

Vues et scripts front¶

app/views/chantier-management.php
app/views/chantiers.php
app/views/chantier-finance.php
app/views/chantier-subcontractors.php
app/views/pv-chantier-signature.php
app/views/pv-chantier-client-signature.php
public/assets/js/chantier-management.js
public/assets/js/chantiers.js
public/assets/js/chantier-finance.js
public/assets/js/chantier-subcontractors.js

Routes principales¶

Les routes sont declarees dans app/core/Router.php.

Pages¶

chantiers : page de gestion principale.
chantiers/vue-globale : vue globale.
chantiers/liste : liste.
chantiers/partages : partages/acces.
chantiers/receptions : receptions et PV.
chantiers/kanban : vue kanban.
chantiers/planning : planning.
chantiers/sous-traitants : sous-traitants.
pv-chantiers : espace PV de fin de chantier.

Actions `chantier-management`¶

Lecture et sauvegarde : get, save, archive, archiveMany, access, saveAccess, updateStatus.
Kanban : moveToColumn, saveColumn, deleteColumn, deleteColumns, reorderColumns.
Lots et taches : saveLot, deleteLot, saveTask, updateTaskStatus, deleteTask.
Planning : planning, savePlanningEvent, deletePlanningEvent, markPlanningEventSeen.
Cartographie : mapboxSuggest, mapboxRetrieve, mapboxRoute.
Documents : saveDocument, deleteDocument.
Reception : createReception.
Documents commerciaux : linkDevis, unlinkDevis, linkInvoice.
Achats : assignPurchase, createPurchase, unassignPurchase.

Actions `chantier`¶

CRUD et contexte formulaire : index, get, formContext, clientDocuments, sourceDocument, save, delete.
Signature : signaturePage, signInPerson, sendSignatureRequest, remoteSignaturePage, signRemoteClient.
Paiement declare PV : recordPayment.
PDF : pdf.

Actions finance¶

index, saveRevenue, deleteRevenue, assignPurchase, unassignPurchase, saveCategory, archiveCategory.

Actions sous-traitants¶

index, saveSubcontractor, getSubcontractor, archiveSubcontractor, saveAssignment, createAssignmentWithSubcontractor, searchCompanies, deleteAssignment, sendInvitation, startConversation, acceptInvitation, showInvitation.

Permissions et acces¶

Les permissions ne sont pas seulement decoratives : elles conditionnent l'affichage, les donnees exposees et les actions disponibles.

Module PV de fin de chantier : acces aux PV, signatures et receptions.
Module Finances des chantiers : acces aux revenus, categories, achats affectes et marges.
Module Sous-traitants des chantiers : acces aux sous-traitants et affectations.
Feature FEATURE_GERER_PV_CHANTIER : active les capacites PV. Les scripts SQL la referencent avec l'identifiant historique 46.

Le modele de gestion contient aussi des droits par collaborateur sur certaines sections chantier :

informations chantier ;
email et telephone client ;
adresse ;
taches et toutes les taches ;
planning ;
documents ;
achats ;
finance et marge ;
facturation ;
reception/PV ;
messagerie.

Point important : un utilisateur peut avoir une permission globale sans avoir acces a toutes les donnees d'un chantier partage. Inversement, un acces collaborateur ne doit pas contourner les permissions sensibles, notamment finance et marge.

Modele de donnees¶

Scripts SQL a lire avant toute modification :

app/bd/chantiers.sql
app/bd/chantiers-management.sql
app/bd/chantiers-collaborator-access.sql
app/bd/chantiers-mapbox.sql
app/bd/chantiers-payment-confirmation.sql
app/bd/chantiers-payment-declaration.sql
app/bd/chantiers-planning-operational-assignment.sql
app/bd/chantiers-subcontractor-invitations.sql
app/bd/chantiers-tpe-feature.sql
app/bd/chantiers-v1-corrections.sql

Tables a connaitre :

chantiers : entite principale.
chantier_lines : lignes du chantier ou du PV.
chantier_installers : installateurs/intervenants.
chantier_receptions : reception, reserves, signatures, paiement declare.
chantier_lots : decoupage operationnel.
chantier_tasks : taches rattachees au chantier ou aux lots.
chantier_documents : documents chantier.
chantier_planning_events : evenements planning.
chantier_access_grants : droits collaborateurs.
chantier_kanban_columns : colonnes kanban personnalisees.
chantier_expense_categories : categories financieres.
chantier_revenues : revenus chantier.
chantier_subcontractors : sous-traitants.
chantier_subcontractor_assignments : affectations de sous-traitants.
devis, factures, achats, clients, membres, societes, fournisseurs : tables reliees au module.

Plusieurs modeles verifient ou completent le schema a l'execution. Cette logique aide en reprise, mais elle ne remplace pas une migration SQL claire. Une evolution durable doit etre documentee dans app/bd/ et testee sur une base staging.

Colonnes sensibles de `chantiers`¶

Colonnes d'identite et d'isolation :

id : identifiant technique.
societe_id : cloisonnement principal. Toute requete metier doit l'utiliser ou passer par une methode qui le fait.
client_id : client rattache, nullable.
created_by_membre_id : membre createur.
responsible_membre_id : responsable operationnel.
parent_chantier_id : lien vers un chantier parent, notamment utile dans le suivi de reserves.
origin_reception_id : reception d'origine pour les suivis.

Colonnes de workflow :

pv_kind : vaut reception par defaut ; les suivis de reserve utilisent reserve_follow_up.
status : statut operationnel/kanban.
pv_status : statut de PV/signature, distinct du statut operationnel.
archived_at : archive logique ; les listes principales filtrent archived_at IS NULL.
progress_percent, planned_start_date, planned_end_date, actual_start_date, actual_end_date : pilotage planning/progression.

Colonnes source commerciale :

source_type : source fonctionnelle, par exemple manuel ou devis selon les normalisations du modele.
source_id : identifiant du document source.
source_number : numero/reference lisible.
amount_ttc, deposit_paid_ttc, balance_due_ttc : montants issus du PV/document. Ne pas les confondre avec le paiement declare.

Colonnes adresse/carte :

site_address
site_address_formatted
site_lat
site_lng
site_place_id
site_map_provider
site_geocoded_at

Colonnes paiement PV declare :

payment_declared_amount_ttc
payment_declared_mode
payment_declared_at
payment_declared_by_membre_id

Colonnes historiques a manier avec prudence :

payment_facture_id
payment_id
payment_confirmed_at
payment_confirmed_by_membre_id

Les tests actuels imposent que recordPayment n'utilise pas payment_facture_id, payment_id, deposit_paid_ttc ni balance_due_ttc. Ces colonnes peuvent encore exister pour compatibilite ou historique, mais elles ne doivent pas etre reactives dans le flux de declaration de paiement PV.

Tables operationnelles¶

chantier_lines

Lignes simples du chantier/PV : designation, quantity, sort_order.
Suppression en cascade via chantier_id.

chantier_installers

Table pivot chantier_id / membre_id.
Sert a materialiser les installateurs lies au PV.

chantier_receptions

Une seule reception par chantier via UNIQUE KEY uk_chantier_reception_chantier.
Champs de decision : decision, reserve_text.
Signature artisan : artisan_signer_name, artisan_membre_id, artisan_signature_path, artisan_signed_at.
Signature client : client_signer_name, client_signature_path, client_signed_at.
Audit signature : signed_mode, signed_ip, signed_user_agent, signed_pdf_path.

chantier_lots et chantier_tasks

Les taches dependent d'un lot (lot_id obligatoire), pas directement du chantier.
Les deux tables portent status, sort_order, created_at, updated_at.
Supprimer un lot supprime ses taches par cascade.

chantier_planning_events

Lie un evenement au chantier et a la societe.
assigned_to est textuel ; assigned_membre_id est l'affectation operationnelle structuree.
assignment_status vaut assigned par defaut depuis la migration operationnelle.

chantier_documents

Document rattache au chantier avec type, name, url, notes.
Le code stocke une URL/chemin, pas un blob.

chantier_access_grants

Acces collaborateurs par chantier.
Sert a restreindre les sections visibles pour les collaborateurs assignes.
Le modele peut backfiller des grants existants au constructeur.

chantier_kanban_columns

Colonnes kanban par societe.
Le modele cree les colonnes par defaut, assure le schema, puis backfill les chantiers sans colonne.

Tables finance et achats¶

chantier_expense_categories

Categories par societe.
Unicite societe_id + name.
Categories par defaut inserees par migration : Materiaux, Transport, Location, Sous-traitance, Consommables, Deplacement, Autre.

chantier_revenues

Revenus et credits chantier.
kind vaut revenue par defaut, ou credit pour inverser le signe dans certains calculs.
status est utilise dans les agregats ; getPaginatedChantiers ne compte que validated, invoiced, collected.
source_type + source_id sont uniques par societe pour eviter le double rattachement d'une meme source.

achats

La migration ajoute chantier_id et expense_category_id.
chantier_id est en ON DELETE SET NULL : supprimer un chantier ne supprime pas l'achat.
Les agregats de depenses de getPaginatedChantiers additionnent achats.montant_ht quand chantier_id IS NOT NULL.

Tables sous-traitance¶

chantier_subcontractors

Fiche sous-traitant propre a une societe.
Peut pointer vers fournisseur_id, linked_societe_id, linked_membre_id.
invitation_status vaut external par defaut.

chantier_subcontractor_assignments

Affectation d'un sous-traitant a un chantier.
Porte les montants prevus/reels, les dates prevues et les droits de section.
Les colonnes access_* de cette table ne couvrent pas access_all_tasks, present dans les acces collaborateurs du modele. Ne pas aligner ces deux mecanismes sans verifier le besoin produit.

Statuts et constantes metier¶

Statuts kanban par defaut :

a_planifier
planifie
en_cours
a_receptionner
reserves_a_lever
termine
annule

Priorites connues :

low
normal
high
urgent

Les libelles peuvent etre affiches differemment dans l'interface, mais les identifiants ci-dessus sont les valeurs techniques attendues par le backend. Eviter de renommer ces valeurs sans migration complete des donnees existantes.

Statuts PV observes dans le code¶

Les tests et le code referencent notamment :

draft
pending_client_signature
signed
signed_with_reserve
closed

recordPayment refuse la declaration si pv_status est deja dans signed, signed_with_reserve ou closed. Cette condition protege contre une declaration concurrente apres signature.

Flux : creation et edition chantier¶

Le flux de creation peut partir d'un formulaire chantier, d'un devis, d'une facture ou d'un contexte commercial deja connu.

Points a verifier dans le code avant modification :

filtrage systematique par societe_id ;
rattachement client ;
reprise des lignes du document source ;
initialisation des statuts ;
creation eventuelle de lots, taches ou donnees planning ;
controles sur les droits d'acces et les permissions module.

Une erreur classique consiste a creer un chantier visible globalement mais incomplet pour les vues detaillees. Apres modification du flux de sauvegarde, tester au minimum la liste, la fiche, le kanban, le planning et le PV.

Lecture liste et filtrage¶

ChantierManagementModel::getPaginatedChantiers applique les contraintes suivantes :

pagination bornee entre 1 et 100 elements par page ;
ch.societe_id = activeSocieteId ;
ch.archived_at IS NULL ;
exclusion des suivis de reserve : COALESCE(ch.pv_kind, 'reception') <> 'reserve_follow_up' ;
recherche sur reference, title, client_name, site_address ;
filtre status seulement si la colonne kanban existe ;
filtre responsible_membre_id ;
restriction supplementaire si l'utilisateur courant est un collaborateur assigne.

La liste enrichit chaque ligne avec :

client ;
responsable ;
colonne kanban ;
revenu realise ;
nombre de revenus ;
depense realisee.

Si l'utilisateur est restreint a des chantiers assignes, le modele charge le grant courant, ajoute les champs shared_access_*, pose is_restricted_collaborator = 1, force can_manage = 0 et sanitize la ligne. C'est une barriere de confidentialite importante : ne pas la contourner en ajoutant une requete parallele cote controleur.

Sauvegarde PV historique¶

ChantierModel::save protege explicitement plusieurs cas :

en edition, le chantier doit exister ;
un PV deja signe ne peut plus etre modifie ;
le client est obligatoire et doit appartenir a la societe active ;
une source de type facture est refusee pour le PV historique avec le message invitant a rattacher un devis ou a utiliser la saisie manuelle.

Cette distinction est importante parce que le module de gestion chantier accepte des rattachements plus larges, alors que le flux PV historique reste plus strict.

Flux : kanban, lots et taches¶

Le kanban est gere par ChantierManagementController et ChantierManagementModel.

Le module supporte :

deplacement d'un chantier entre colonnes ;
creation, edition, suppression et reordonnancement de colonnes ;
lots de chantier ;
taches rattachees a un chantier ou a un lot ;
changement de statut des taches ;
suppression de taches et de lots.

La suppression d'une colonne, d'un lot ou d'une tache doit toujours etre analysee avec les relations existantes. Avant de supprimer physiquement une donnee, verifier si l'interface attend un archivage, une reaffectation ou une suppression en cascade.

Colonnes kanban¶

Le modele execute au constructeur :

ensureKanbanSchema;
ensureDefaultKanbanColumns;
backfillKanbanColumns;
backfillCollaboratorAccessGrants.

Cela signifie que le module peut modifier ou completer la base au chargement. En reprise, ne pas se contenter de tester une base deja chaude : tester aussi une base fraiche ou partiellement migree pour verifier que les migrations SQL et les ensure runtime racontent la meme histoire.

Les actions de colonnes exposees par le controleur sont :

creation/mise a jour : saveColumn;
suppression simple : deleteColumn;
suppression multiple : deleteColumns;
reordonnancement : reorderColumns;
deplacement chantier : moveToColumn.

Avant de supprimer une colonne, verifier la strategie exacte du modele : reaffectation des chantiers, archivage de colonne, ou refus si la colonne contient encore des chantiers.

Flux : planning et carte¶

Le planning s'appuie sur chantier_planning_events.

Fonctions associees :

lecture du planning ;
creation et mise a jour d'evenement ;
suppression d'evenement ;
marquage "vu" ;
suggestion, recuperation et itineraire Mapbox.

Mapbox est une dependance externe : ne pas exposer de cle dans la documentation publique. Pour reprendre le module, chercher les variables d'environnement ou la configuration applicative deja en place au lieu de hardcoder une cle dans le code.

Affectation planning¶

chantier_planning_events contient deux notions :

assigned_to : texte libre historique ;
assigned_membre_id : relation structuree vers un membre.

La migration chantiers-planning-operational-assignment.sql ajoute aussi assignment_status et l'index idx_chantier_planning_events_assignee. Les vues operationnelles peuvent donc filtrer un planning par membre assigne. Tester le cas ou assigned_to est rempli mais assigned_membre_id est nul : c'est un etat possible sur donnees anciennes.

Flux : documents, achats, devis et factures¶

Le module fait le pont entre le suivi operationnel et les documents commerciaux.

Fonctions importantes :

ajout/suppression de documents chantier ;
rattachement et detachement de devis ;
rattachement de factures ;
affectation d'achats existants ;
creation d'achat depuis un chantier ;
retrait d'une affectation achat.

Le risque principal est de melanger les notions suivantes :

document commercial client : devis/facture ;
achat fournisseur : table achats ;
document chantier : table chantier_documents ;
revenu chantier : table chantier_revenues ;
paiement declare dans un PV : donnees de reception, sans effet comptable facture.

Rattachements commerciaux¶

Le controleur de gestion expose trois familles d'actions a ne pas confondre :

linkDevis / unlinkDevis : relation devis vers chantier.
linkInvoice : rattachement facture.
assignPurchase / createPurchase / unassignPurchase : achat fournisseur.

Le modele financier utilise chantier_revenues pour representer les revenus chantier. Les factures/devis peuvent donc etre source d'un revenu, mais une ligne de revenu chantier n'est pas automatiquement une facture, et un achat chantier n'est pas automatiquement un document Pennylane.

Flux : finances chantier¶

Le module finance permet de suivre revenus, achats affectes, categories et marges. Il doit rester strictement cloisonne par societe et par permission.

Regles de reprise :

masquer les montants et marges aux utilisateurs non autorises ;
ne pas recalculer la comptabilite facture depuis un simple changement de categorie chantier ;
ne pas assimiler une declaration de paiement PV a un paiement comptable ;
verifier les totaux HT/TTC et les arrondis si des montants sont modifies ;
tester les cas sans achat, sans revenu, avec plusieurs achats et avec achat retire.

Calculs a surveiller¶

Dans la liste chantier, le revenu realise est calcule depuis chantier_revenues :

kind = credit est soustrait ;
les autres kind sont ajoutes ;
seuls les statuts validated, invoiced, collected comptent.

La depense realisee est calculee depuis achats.montant_ht. Si le modele des achats evolue vers plusieurs montants HT/TTC, categories multiples ou devises, cette requete devra etre revue.

Les permissions finance et marge sont separees dans les grants :

access_finance
access_margin
access_billing
access_purchases

Ne pas afficher une marge simplement parce que l'utilisateur peut voir les achats.

Flux : reception, PV et signature¶

Le PV de chantier est gere par ChantierController et ChantierModel.

Flux principal :

creation du chantier ou rattachement a un document source ;
preparation des donnees de reception ;
signature interne ou presentielle selon le contexte ;
envoi eventuel de demande de signature client ;
signature distante via page publique controlee ;
generation/consultation PDF ;
declaration de paiement liee au PV, si applicable.

Invariants importants :

une signature ne doit pas rendre modifiable un PV qui doit rester auditable ;
les reserves doivent rester visibles et exploitables apres signature ;
la signature client distante doit etre controlee par un jeton ou un contexte securise ;
les actions publiques ne doivent pas exposer d'autres chantiers de la societe ;
la signature business/interne reste requise avant certains envois client selon le workflow teste.

Reception depuis gestion chantier¶

ChantierManagementController::createReception delegue a ChantierManagementModel::createReception. Le test chantier_reception_workflow_test.php verifie que :

la creation depuis chantier est presentee comme un brouillon ;
le statut pending_client_signature est visible cote JS ;
le panneau PV exploite chantier.reserve_follow_ups ;
le modele enrichit les chantiers avec appendPvWorkflowContext ;
les suivis de reserves sont recuperes via getReserveFollowUps ;
l'envoi client passe par pv-chantier/send-signature-request ;
la signature entreprise reste obligatoire avant l'envoi client ;
la signature client reste obligatoire pour une signature sur place.

Ces assertions sont textuelles, mais elles capturent une intention produit : le PV n'est pas un simple bouton "signer", il a un etat de brouillon, un mode de signature distante et un mecanisme de reserves.

Paiement declare dans le PV¶

La declaration de paiement du PV est volontairement isolee de la comptabilite facture. Les tests existants protegent cette regle.

Ce que le flux doit faire :

enregistrer le montant declare sur les donnees chantier/reception ;
permettre la signature finale quand les conditions sont remplies ;
eviter les doubles soumissions cote front et cote backend.

Ce que le flux ne doit pas faire automatiquement :

creer une ligne de paiement comptable ;
modifier l'etat de paiement d'une facture ;
recalculer deposit_paid_ttc, balance_due_ttc ou des champs equivalents ;
appeler des methodes de rapprochement facture sans intention explicite.

Avant toute evolution, relire tests/chantier_payment_accounting_isolation_test.php et tests/pv_signature_payment_submission_test.php.

Garde-fous verifies par test¶

tests/chantier_payment_accounting_isolation_test.php extrait directement les methodes du modele et verifie que :

le schema contient payment_declared_amount_ttc ;
recordPayment ecrit payment_declared_amount_ttc ;
recordPayment ecrit payment_declared_at ;
recordPayment passe par normalizeDeclaredPaymentAmount ;
recordPayment contient la condition pv_status NOT IN ('signed', 'signed_with_reserve', 'closed') ;
recordPayment verifie mysqli_stmt_affected_rows apres mise a jour conditionnelle ;
recordPayment ne contient pas resolvePaymentFactureId, insertPayment, refreshFacturePaymentState, payment_facture_id, payment_id, deposit_paid_ttc, balance_due_ttc ;
markPaymentAlreadyHandled et signRemoteClient ne modifient pas deposit_paid_ttc ni balance_due_ttc.

Si un futur besoin produit demande de convertir une declaration PV en paiement comptable, le faire dans un flux explicite, nomme et teste separement. Ne pas reutiliser silencieusement recordPayment.

Flux : sous-traitants¶

Le module sous-traitants couvre :

fiche sous-traitant ;
recherche de societes ;
affectation sur chantier ;
creation d'affectation avec un nouveau sous-traitant ;
invitation ;
acceptation d'invitation ;
demarrage d'une conversation ;
archivage.

Les affectations croisent les modules Chantiers et Messagerie. Une invitation acceptee peut donc avoir des effets sur les droits d'acces, la visibilite des donnees et la conversation associee.

Acces sous-traitants vs acces collaborateurs¶

Deux mecanismes coexistent :

les grants collaborateurs geres par chantier_access_grants et les colonnes ACCESS_COLUMNS du modele ;
les droits d'affectation sous-traitant portes directement par chantier_subcontractor_assignments.

Ils se ressemblent, mais ne sont pas identiques. Par exemple, access_all_tasks existe dans le modele de grants collaborateurs, alors que l'affectation sous-traitant expose access_tasks sans access_all_tasks. Toute factorisation doit donc commencer par une matrice de compatibilite, pas par un renommage mecanique.

Schemas runtime vs migrations SQL¶

Le module contient beaucoup de logique ensure* et backfill*. C'est utile en production pour absorber des donnees anciennes, mais c'est aussi un risque documentaire : un developpeur peut croire que le schema est entierement porte par app/bd.

Regle de reprise :

quand une colonne est utilisee par le code, chercher d'abord la migration SQL ;
si elle est creee seulement par une methode ensure*, documenter l'ecart ;
si la migration SQL et le runtime divergent, corriger la migration avant de livrer une installation neuve ;
ne pas ajouter une nouvelle colonne uniquement dans un ensure* sans script SQL.

Integrations internes¶

Devis et factures : source de creation ou de rattachement.
Achats fournisseurs : depenses operationnelles.
Messagerie : conversations avec sous-traitants ou collaborateurs.
Clients : donnees de contact et signature.
Membres/collaborateurs : acces et attribution.
Pennylane : indirectement via factures/avoirs et etats commerciaux, mais le paiement declare PV ne doit pas declencher de synchronisation comptable.

Bugs et zones signalees¶

A confirmer en environnement staging avant correction :

incoherences possibles entre donnees chantier, facture et avoir lorsque le chantier est rattache a des documents commerciaux modifies ensuite ;
confusion possible entre paiement declare au PV et paiement facture ;
comportements a verifier sur les documents commerciaux archives ou modifies apres rattachement.

Pour qualifier un bug, relever :

identifiant chantier ;
societe ;
document source ;
facture/devis/avoir rattache ;
statut kanban ;
statut de reception/PV ;
utilisateur et permissions ;
action exacte effectuee ;
etat attendu et etat observe.

Tests existants¶

tests/chantier_payment_accounting_isolation_test.php : verifie que le paiement PV ne touche pas la comptabilite facture.
tests/chantier_reception_workflow_test.php : couvre le workflow reception/signature/reserves.
tests/pv_signature_payment_submission_test.php : couvre la sauvegarde paiement avant signature et la prevention des doubles soumissions.

Tests recommandes avant livraison¶

Creation chantier depuis formulaire vierge.
Creation chantier depuis devis.
Rattachement puis detachement devis.
Rattachement facture.
Creation achat depuis chantier puis retrait.
Vue finance avec et sans permission.
Creation lot, tache, changement statut, suppression.
Deplacement kanban et reordonnancement colonnes.
Planning : creation, modification, suppression.
Acces collaborateur avec droits limites.
Invitation sous-traitant et acceptation.
Creation PV, reserves, signature interne, signature client distante.
Declaration de paiement PV sans changement d'etat facture.

Commandes utiles¶

php tests/chantier_payment_accounting_isolation_test.php
php tests/chantier_reception_workflow_test.php
php tests/pv_signature_payment_submission_test.php

Adapter les commandes si l'environnement local utilise un lanceur de tests different.

Checklist de reprise¶

Lire les quatre controleurs avant de modifier un flux.
Verifier les migrations SQL disponibles dans app/bd/.
Identifier les permissions necessaires pour reproduire le cas.
Tester avec au moins deux societes pour valider l'isolation societe_id.
Tester un utilisateur sans permission finance.
Tester un chantier avec documents commerciaux rattaches.
Tester un PV signe pour eviter les regressions d'auditabilite.
Verifier que les exports/PDF ne revelent pas des donnees masquees dans l'interface.

Questions ouvertes¶

Faut-il consolider les anciens ecrans chantiers.php et les vues chantier-management.php ou conserver les deux surfaces ?
Quelle est la regle produit exacte entre chantier termine, PV signe et facture soldee ?
Les documents commerciaux archives doivent-ils rester rattachables en lecture seule ou etre totalement exclus des nouveaux rattachements ?
Les colonnes kanban personnalisees doivent-elles etre globales a la societe ou propres a chaque utilisateur ?