Module DoliSCAN pour Dolibarr doliscan-for-dolibarr

Objectif : un compte DoliSCAN relie un utilisateur Dolibarr à ses identifiants sur doliscan.fr.

Vérifications :

• Création, relecture, modification et suppression d'un compte.
• Recherche du compte par identifiant d'utilisateur.
• Recherche filtrée sur la liste des comptes.
• La contrainte d'unicité (un seul compte par utilisateur et par entité) est respectée.
• L'isolation par entité est effective.

Point de contrôle manuel : depuis la configuration du module, créer un compte pour un utilisateur, puis vérifier qu'un second compte sur la même entité est refusé.

Couverture automatique : test/phpunit/integration-dolibarr/MyAccountTest.php (9 methodes, suite integration).

Objectif : chaque transition de statut a une garde qui refuse ce qui n'a pas de sens, et un contrôle de droit.

Vérifications :

• Valider un compte déjà validé ne fait rien.
• Un compte validé peut revenir en brouillon ; un brouillon déjà en brouillon ne bouge pas.
• Un compte validé peut être annulé ; un brouillon ne peut pas être annulé.
• Un compte annulé peut être rouvert ; un compte validé ou en brouillon ne peut pas l'être.
• Les quatre transitions sont refusées sans le droit d'écriture DoliSCAN.
• Le cycle complet brouillon -> validé -> annulé -> validé fonctionne de bout en bout.

Point de contrôle manuel : dérouler ce cycle depuis la fiche du compte, avec un utilisateur qui a les droits, puis avec un utilisateur qui ne les a pas.

Couverture automatique : test/phpunit/integration-dolibarr/MyAccountWorkflowTest.php (13 methodes, suite integration).

Objectif : les clés d'API DoliSCAN étaient stockées en clair (faille de priorité 1). Elles sont désormais chiffrées à l'écriture et déchiffrées à la lecture, de façon transparente pour le code appelant.

Vérifications :

• Sur un Dolibarr qui expose le chiffrement, la clé est bien chiffrée en base à la création (préfixe dédié) et rechiffrée à chaque modification.
• La relecture, simple ou par résolution du compte de l'utilisateur, rend la clé en clair.
• Sur un hôte sans fonction de chiffrement, la valeur passe telle quelle (comportement documenté).
• Une ligne historique écrite en clair avant la bascule reste lisible.

Point de contrôle manuel : inspecter la colonne ds_api en base et vérifier qu'elle ne contient plus de jeton lisible pour les comptes créés récemment.

Couverture automatique : test/phpunit/integration-dolibarr/MyAccountApiKeyEncryptionTest.php (5 methodes, suite integration).

Objectif : quand un salarié part ou revient, la désactivation ou la réactivation de son utilisateur Dolibarr doit être répercutée sur son compte DoliSCAN.

Vérifications :

• La désactivation envoie l'identifiant au bon point d'entrée, et un refus est signalé.
• La réactivation fait de même.
• Le déclencheur désactive le compte d'un utilisateur désactivé.

Point de contrôle manuel : le serveur est simulé. Désactiver un utilisateur Dolibarr titulaire d'un compte DoliSCAN et vérifier qu'il ne peut plus se connecter à l'application mobile, puis le réactiver et vérifier qu'il le peut de nouveau.

Couverture automatique : test/phpunit/integration-dolibarr/RemoteAccountStateTest.php (5 méthodes, suite integration).

Objectif : la période de la note de frais Dolibarr doit correspondre au mois réel, quel que soit le format de date renvoyé par l'API.

Vérifications :

• Une période transmise en ISO 8601 UTC est stockée en date locale sur la note de frais (avril reste avril, et non le 31 mars).
• Le comportement est identique en heure d'hiver.
• Un second appel avec les mêmes dates ISO réutilise la note de frais existante au lieu d'en créer une seconde.

Point de contrôle manuel : après une synchronisation, ouvrir la note de frais dans Dolibarr et vérifier que la période affichée correspond au mois des dépenses, sans décalage d'un jour.

Couverture automatique : test/phpunit/integration-dolibarr/CreateNdfIsoDateTest.php (3 methodes, suite integration).

Objectif : une date de fin mal formée levait une exception non rattrapée, qui arrêtait la tâche planifiée pour tous les comptes suivants.

Vérifications :

• La resynchronisation signale la date inutilisable sans exception.
• L'import signale la date inutilisable sans exception.

Couverture automatique : test/phpunit/integration-dolibarr/BadRemoteDateTest.php (2 méthodes, suite integration).

Objectif : une date de l'API doit être lue sans qu'une valeur illisible puisse interrompre la synchronisation.

Vérifications :

• Une date utilisable donne une date.
• Une date inutilisable ne donne aucune date, sans exception.

Couverture automatique : test/phpunit/unit/RemoteDateTest.php (2 méthodes, suite unit).

Objectif : une date illisible devenait le 1er janvier 1970 : la note de frais paraissait antérieure à toute date de début et était écartée sans un mot.

Vérifications :

• La comparaison de deux dates est correcte.
• Une première ou une seconde date inutilisable est signalée comme telle.
• Une date inutilisable n'est jamais confondue avec le 1er janvier 1970.

Couverture automatique : test/phpunit/unit/CompareDatesTest.php (4 méthodes, suite unit).

Objectif : le module réagit aux événements de création, d'activation ou de désactivation et de suppression d'un utilisateur Dolibarr pour tenir à jour le compte correspondant côté doliscan.fr.

Vérifications :

• Module désactivé : aucune action.
• Création d'un utilisateur alors que la création automatique de compte est désactivée : aucune action.
• Création d'un utilisateur avec la création automatique activée : l'API est appelée.
• Activation ou désactivation d'un utilisateur sans compte DoliSCAN : aucune action.
• Événement inconnu : aucune action et aucune erreur.
• Les métadonnées du déclencheur (nom, description, version) sont correctes.

Point de contrôle manuel : activer la création automatique, créer un utilisateur Dolibarr et vérifier qu'un compte DoliSCAN apparaît.

Couverture automatique : test/phpunit/integration-dolibarr/DoliscanTriggersTest.php (6 methodes, suite integration).

Objectif : le déclencheur s'annonçait comme une démonstration en développement dans la liste des déclencheurs, et la modification d'un projet sans rapport avec DoliSCAN pouvait échouer.

Vérifications :

• Le déclencheur ne s'annonce ni comme une démonstration, ni comme en développement.
• La modification d'un projet sans copie d'origine n'échoue pas.
• Une modification qui ne change pas le code du projet ne demande pas d'envoi des projets.

Couverture automatique : test/phpunit/integration-dolibarr/TriggerMetadataTest.php (4 méthodes, suite integration).

Objectif : verrouiller le scénario de production du 27 avril 2026. Après la purge des brouillons, le réimport d'une même note de frais appelait la recherche de doublon avec des dates ISO 8601 UTC, comparées à des dates locales stockées en base. Aucune correspondance, donc création d'une note de frais PROV119 supplémentaire, l'ancienne devenant orpheline.

Vérifications :

• La recherche de doublon retrouve la note de frais quand on lui passe des dates ISO UTC représentant la même période locale.
• Idem sans microsecondes et en heure d'hiver.
• Les dates déjà locales continuent de fonctionner (pas de régression).

Point de contrôle manuel : activer la purge des brouillons, resynchroniser, et vérifier qu'aucune note de frais provisoire supplémentaire n'apparaît.

Couverture automatique : test/phpunit/integration-dolibarr/DoublonNdfIsoDateTest.php (4 methodes, suite integration).

Objectif : ne jamais créer deux fois la même facture fournisseur. Trois stratégies sont essayées dans l'ordre.

Vérifications :

• Recherche par clé d'import (identifiant de la dépense DoliSCAN) pour les factures postérieures à la date de bascule.
• Recherche par référence fournisseur "date:montant TTC" pour les factures antérieures à la bascule, et uniquement pour celles-là.
• Recherche par référence auto "date/identifiant DoliSCAN" pour une facture qu'un utilisateur aurait saisie à la main.
• La clé d'import d'une autre dépense n'est jamais retenue.
• Sans correspondance, rien n'est renvoyé ; avec correspondance, c'est bien un objet facture fournisseur complet.

Point de contrôle manuel : resynchroniser un mois déjà importé et vérifier qu'aucune facture fournisseur n'est créée en double.

Couverture automatique : test/phpunit/integration-dolibarr/DoublonFacFournisseurTest.php (8 methodes, suite integration).

Objectif : le nettoyage exigeait auparavant des dates strictement identiques. Or la dérive de fuseau produisait des orphelines décalées d'un jour, donc jamais détectées ni nettoyées. Une tolérance de plus ou moins deux jours est appliquée sur chaque date indépendamment.

Vérifications :

• Orpheline aux mêmes dates : supprimée.
• Décalage d'un jour sur la date de début, ou de deux jours sur la date de fin : supprimée (dans la fenêtre).
• Décalage de trois jours : conservée (hors fenêtre).
• Orpheline d'un autre utilisateur : conservée.
• Orpheline qui n'est pas en brouillon : conservée.
• Orpheline dans la fenêtre mais qui porte encore des lignes : conservée et signalée.

Point de contrôle manuel : la page de diagnostics ne doit plus lister d'orphelines vides après une synchronisation.

Couverture automatique : test/phpunit/integration-dolibarr/CleanupOrphanDateToleranceTest.php (7 methodes, suite integration).

Objectif : la recherche de doublon conservée pour les lignes importées avant la clé d'import comparait date, montant, type et libellé sur toute la table : deux collègues qui déjeunent au même endroit, le même jour, pour le même prix, et la ligne du second n'était pas importée.

Vérifications :

• Une ligne identique d'un autre salarié n'empêche pas l'import.
• Un vrai doublon dans la même note de frais est toujours détecté.

Couverture automatique : test/phpunit/integration-dolibarr/LegacyDedupScopeTest.php (2 méthodes, suite integration).

Objectif : transformer une dépense pro en facture fournisseur Dolibarr correctement renseignée et payée.

Vérifications :

• Le fournisseur est résolu par le mapping de slugs configuré ; un slug inconnu ne produit pas de facture orpheline.
• Les champs de la facture sont corrects : référence fournisseur, tiers, date, compte bancaire, note privée.
• La clé d'import est bien posée sur la facture créée.
• Le mode de paiement vient du fournisseur ; à défaut, il est repris du slug DoliSCAN.
• Règles carburant : ignorées si l'option est désactivée ou si le slug n'est pas du carburant ; appliquées pour un véhicule utilitaire comme pour un véhicule particulier.
• Le paiement automatique n'est pas dupliqué d'une synchronisation à l'autre ; les doublons exacts sont supprimés, les paiements réellement distincts conservés.

Point de contrôle manuel : importer une dépense pro, ouvrir la facture fournisseur créée, vérifier le tiers, le montant, le mode de règlement et le paiement associé.

Couverture automatique : test/phpunit/integration-dolibarr/CreateFactFournisseurTest.php (12 methodes, suite integration).

Objectif : la création validait et annulait une transaction qu'elle n'avait jamais ouverte : quand l'appelant en avait une, tout ce qui précédait était validé et son annulation n'annulait plus rien.

Vérifications :

• La création ne ferme pas une transaction qu'elle n'a pas ouverte.

Couverture automatique : test/phpunit/integration-dolibarr/FacFournisseurTransactionTest.php (1 méthode, suite integration).

Objectif : le lien de création des fournisseurs par défaut créait sept tiers à chaque clic, et la correspondance pointait sur le premier trouvé.

Vérifications :

• Deux appels successifs ne créent aucun doublon.
• Un tiers existant est réutilisé, même s'il n'est pas marqué fournisseur.

Couverture automatique : test/phpunit/integration-dolibarr/CreateDefaultSuppliersTest.php (2 méthodes, suite integration).

Objectif : Dolibarr 24 passe le filtre du sélecteur de comptes bancaires par le filtre de recherche universel, et refuse par défaut un lien d'action sans jeton CSRF.

Vérifications :

• Le filtre de comptes bancaires donné à Dolibarr 24 ne garde que les comptes courants.
• Le filtre SQL brut est bien rejeté par l'analyseur, ce qui justifie la conversion.
• Le bouton de récupération du jeton administrateur porte un jeton CSRF.

Point de contrôle manuel : le harnais tourne en Dolibarr 18. Sur une instance Dolibarr 24, vérifier que le sélecteur de compte bancaire de la configuration est rempli, puis utiliser le bouton de récupération du jeton administrateur.

Couverture automatique : test/phpunit/integration-dolibarr/Dolibarr24CompatTest.php (3 méthodes, suite integration).

Objectif : c'est la règle métier centrale du module. Une dépense marquée professionnelle devient une facture fournisseur ; une dépense personnelle devient une ligne de note de frais à rembourser au salarié.

Vérifications :

• La décision pro / perso est prise sur l'indicateur transmis par l'application mobile.
• Pour une dépense pro, le fournisseur est résolu depuis le mapping de slugs.
• Pour une dépense perso, une ligne de note de frais est créée avec le bon type de frais.
• Les montants total, part personnelle et part professionnelle sont suivis séparément.
• Le lien entre l'enregistrement DoliSCAN et la note de frais Dolibarr est enregistré.
• En multi-entités, l'utilisateur présent dans plusieurs entités est résolu dans la bonne.

Point de contrôle manuel : synchroniser un compte contenant une dépense pro et une dépense perso, puis vérifier qu'une facture fournisseur et une ligne de note de frais ont bien été créées, chacune pour le bon montant.

Couverture automatique : test/phpunit/integration-dolibarr/ImportNDFTest.php (10 methodes, suite integration).

Objectif : dérouler tout le pipeline hors ligne, de la charge utile DoliSCAN aux objets Dolibarr, et vérifier les routes d'API réellement appelées.

Vérifications :

• Une dépense personnelle produit une note de frais liée à l'enregistrement DoliSCAN.
• Une dépense professionnelle produit une facture fournisseur.
• Une dépense de carburant applique les règles carburant configurées.
• Les routes appelées sont bien celles attendues (PDF, détails de la note de frais).
• Une réponse de détails invalide remonte une erreur lisible, et un code 404 remonte un message dédié au lieu d'un échec silencieux.

Point de contrôle manuel : depuis la fiche d'une note de frais DoliSCAN, relancer l'import et vérifier que le justificatif PDF est bien rattaché.

Couverture automatique : test/phpunit/integration-dolibarr/ImportNDFHappyPathTest.php (6 methodes, suite integration).

Objectif : reproduire et verrouiller le bug "une nouvelle note de frais à chaque synchronisation". En production, un seul enregistrement DoliSCAN avait engendré 4 notes de frais Dolibarr parce que la détection de doublon reposait sur l'égalité stricte des dates, lesquelles dérivent entre deux synchronisations. L'ancrage correct est l'identifiant serveur.

Vérifications :

• Un second import, avec des dates volontairement décalées, réutilise la même note de frais : il n'y en a qu'une à la fin.
• Les notes de frais devenues orphelines sont détectées, et celles qui portent des lignes saisies à la main sont comptées comme telles.
• Une note de frais validée ou déjà pointée n'est jamais considérée comme orpheline.
• Le nettoyage supprime l'orpheline vide et conserve celle qui porte des lignes manuelles.
• Une ligne restée sur une orpheline en brouillon est rapatriée sur la note de frais active ; une ligne sur une orpheline validée ne bouge pas.

Point de contrôle manuel : lancer deux synchronisations de suite sur le même mois et vérifier dans la liste des notes de frais Dolibarr qu'il n'y en a toujours qu'une pour la période.

Couverture automatique : test/phpunit/integration-dolibarr/ImportNDFDedupBySidTest.php (8 methodes, suite integration).

Objectif : cas remonté en production. Un salarié fait l'aller-retour chez un client dans la journée et paie deux péages distincts du même montant (même section d'autoroute). Les deux tickets sont deux dépenses distinctes dans l'application mobile, mais une seule arrivait dans Dolibarr.

Cause : le repli de déduplication historique cherchait une ligne existante sur le quadruplet (date, montant TTC, type de frais, libellé), ce qui confond deux dépenses réellement différentes. La seconde était abandonnée en silence.

Vérifications :

• Deux dépenses distinctes de même date, même montant, même type et même libellé donnent bien DEUX lignes dans la note de frais.
• Une ligne historique sans identifiant d'import reste, elle, dédupliquée (pas de doublon sur les anciennes données).

Point de contrôle manuel : saisir deux péages identiques le même jour dans l'application mobile, synchroniser, et compter les lignes dans la note de frais Dolibarr.

Couverture automatique : test/phpunit/integration-dolibarr/AddLineNdfLegacyDedupTest.php (2 methodes, suite integration).

Objectif : corriger le symptôme "note de frais vide mais total supérieur à zéro". Quand une ligne est rapatriée d'une note de frais orpheline vers la note active, les totaux doivent être recalculés des deux côtés.

Vérifications :

• La note de frais source retombe à zéro après le départ de sa dernière ligne.
• La note de frais destination reflète immédiatement le montant de la ligne reçue.
• Une fois les lignes déplacées, l'orpheline devenue vide est supprimée par le nettoyage.
• Un cas multi-TVA déplace bien toutes les lignes.
• Un déplacement partiel interrompu se rattrape à la synchronisation suivante.

Point de contrôle manuel : dans la liste des notes de frais Dolibarr, aucune note ne doit afficher un total non nul alors qu'elle n'a aucune ligne.

Couverture automatique : test/phpunit/integration-dolibarr/MoveLineRecomputesTotalsTest.php (5 methodes, suite integration).

Objectif : le module ajoutait autrefois une ligne technique à zéro en fin de note de frais pour forcer Dolibarr à recalculer ses totaux. Les versions actuelles de Dolibarr le font seules, et cette ligne résiduelle empêchait le nettoyage des notes de frais orphelines (qui ne supprime que celles à zéro ligne).

Vérifications :

• L'import n'ajoute plus cette ligne technique.
• Le nettoyage purge la ligne technique héritée puis supprime l'orpheline devenue vide.
• Une orpheline qui porte, en plus de la ligne technique, une ligne saisie à la main est conservée.

Point de contrôle manuel : ouvrir une note de frais importée et vérifier qu'aucune ligne "Fin de la note de frais" à 0,00 n'apparaît.

Couverture automatique : test/phpunit/integration-dolibarr/EndOfNDFLineLegacyTest.php (3 methodes, suite integration).

Objectif : la validation automatique était déclenchée juste après la création de la note de frais, donc avant l'insertion des lignes : la note était validée vide, et les lignes suivantes se heurtaient à une note déjà validée. La validation a été déplacée en fin d'import, et n'a lieu que si la période est terminée.

Vérifications :

• Aucune validation automatique sur une note de frais fraîchement créée et encore vide.
• Tant que la période n'est pas terminée, la note reste en brouillon (sinon une validation en milieu de mois bloquerait les synchronisations suivantes).
• Une fois la période close, la note est validée automatiquement.
• L'approbation automatique intervient ensuite, si elle est configurée.

Point de contrôle manuel : activer la validation automatique, synchroniser en cours de mois (la note doit rester en brouillon), puis resynchroniser après la fin du mois.

Couverture automatique : test/phpunit/integration-dolibarr/AutoValidateAfterPeriodEndTest.php (4 methodes, suite integration).

Objectif : réparer les données déjà abîmées par le bug de déduplication des dépenses identiques. L'outil détecte les lignes manquantes et les reconstruit sur une note de frais de rattrapage en brouillon.

Vérifications :

• L'analyse détecte l'unique ticket de péage manquant d'un aller-retour.
• La génération reconstruit la ligne manquante sur une note de frais de rattrapage en brouillon, en rappelant sa date d'origine dans le libellé.
• Relancer la génération ne crée pas de doublon (opération idempotente).
• Une note de frais déjà complète ne produit aucun rattrapage.

Point de contrôle manuel : lancer l'analyse de rattrapage sur un compte historique, contrôler la liste proposée avant de générer.

Couverture automatique : test/phpunit/integration-dolibarr/RattrapageTest.php (4 methodes, suite integration).

Objectif : figer ce que l'import écrit pour chaque cas de TVA, afin de pouvoir restructurer la création des lignes sans changer le résultat.

Vérifications :

• Ligne sans TVA, ligne à un seul taux, ligne dont la TVA ne couvre pas tout le ticket.
• Une ligne incohérente à plusieurs taux se replie sur une seule ligne à taux zéro.
• Un ticket à plusieurs taux garde la TVA de chaque taux.
• Carburant d'un véhicule utilitaire : HT et TVA dans le bon sens. Carburant d'un véhicule de tourisme : ligne coupée en deux.
• Chaque ligne porte la note de frais et le type de frais.

Couverture automatique : test/phpunit/integration-dolibarr/AddLineNdfCharacterizationTest.php (8 méthodes, suite integration).

Objectif : le statut était écrit à la main, sans transaction ni déclencheur : rien en aval ne savait que la note de frais était gelée.

Vérifications :

• Un statut serveur à 2 gèle la note de frais en base.
• Le gel passe par une méthode de statut.
• Un statut serveur à 1 laisse la note de frais en brouillon.

Couverture automatique : test/phpunit/integration-dolibarr/FrozenStatusTest.php (3 méthodes, suite integration).

Objectif : le plafonnement réécrit les montants qui finissent sur la note de frais, donc sur la paie du salarié, et doit répartir à nouveau la TVA sur le montant plafonné.

Vérifications :

• Une dépense sous le plafond ou égale au plafond est laissée telle quelle.
• Une dépense au-dessus du plafond est plafonnée, avec des montants cohérents entre eux.
• Le libellé indique que la dépense a été plafonnée.
• La TVA est répartie sur plusieurs taux.

Couverture automatique : test/phpunit/integration-dolibarr/MaxRebuildAmountTest.php (6 méthodes, suite integration).

Objectif : les plafonds de restauration de l'onglet des règles particulières s'appliquent aux membres des groupes listés, et à eux seuls.

Vérifications :

• Le plus bas plafond des groupes listés s'applique.
• Un groupe retiré de la liste ne plafonne plus ses membres.
• Une règle enregistrée à zéro est désactivée.

Couverture automatique : test/phpunit/integration-dolibarr/RestaurantCapTest.php (3 méthodes, suite integration).

Objectif : une dépense professionnelle sans correspondance était abandonnée avec une simple ligne de journal, et la note de frais close quand même ; une dépense personnelle devenait une ligne sans type de frais valide.

Vérifications :

• Une dépense professionnelle sans correspondance est signalée, la note reste ouverte, et la dépense est importée une fois la correspondance faite.
• Une dépense professionnelle liée à un fournisseur supprimé est signalée.
• Une dépense personnelle sans correspondance est signalée au lieu de devenir une ligne sans type.

Couverture automatique : test/phpunit/integration-dolibarr/UnmappedExpenseTypeTest.php (3 méthodes, suite integration).

Objectif : le serveur répond une liste vide pour une note de frais qui ne contient encore aucune dépense. Elle était prise pour une réponse invalide : tout le compte passait en erreur et la date de dernière synchronisation n'avançait plus.

Vérifications :

• Une liste vide ou un objet vide sont une note de frais valide, sans dépense.
• Une liste de lignes est renvoyée telle quelle, et un objet indexé est lu comme une liste de lignes.
• Un autre corps est déclaré invalide.

Couverture automatique : test/phpunit/unit/NdfDetailsParseTest.php (5 méthodes, suite unit).

Objectif : sur une installation où le réglage n'a jamais été enregistré, chaque ligne importée levait une notice de propriété indéfinie, qui inondait le journal et pouvait s'afficher au milieu de la page.

Vérifications :

• Sans le réglage carburant, l'import ne lève aucune notice et applique la valeur par défaut documentée.

Couverture automatique : test/phpunit/integration-dolibarr/MissingConfigKeyTest.php (1 méthode, suite integration).

Objectif : quand le serveur DoliSCAN invalide le jeton d'un utilisateur, la synchronisation suivante reçoit un code 401. Le module doit recréer le compte côté serveur avec la clé administrateur, récupérer le nouveau jeton et le réenregistrer, sans intervention humaine. Aucun mot de passe n'est stocké par le module, seule la clé administrateur.

Vérifications :

• Sur un 401, le jeton est renouvelé et persisté, et la synchronisation se poursuit.
• Si le renouvellement répond lui aussi 401, une erreur explicite est remontée.
• Si la nouvelle tentative après renouvellement échoue encore, une erreur explicite est remontée.

Point de contrôle manuel : un compte dont le jeton a été révoqué côté serveur doit se resynchroniser tout seul à l'exécution suivante, sans ticket de support.

Couverture automatique : test/phpunit/integration-dolibarr/TokenRenewalTest.php (3 methodes, suite integration).

Objectif : quand la clé administrateur du module est invalidée côté serveur, tous les appels de niveau administrateur répondent 401. Le module doit le signaler et proposer un chemin de récupération par courriel, sans inonder la boîte de l'administrateur.

Vérifications :

• Un premier 401 marque le jeton administrateur comme invalide et déclenche l'envoi d'un code de sécurité par le serveur.
• Un second 401 dans la fenêtre d'une heure ne renvoie pas de courriel (anti-spam).
• La saisie d'un code valide renouvelle le jeton, le persiste et lève le signalement.
• Un 401 d'authentification est bien distingué d'une erreur réseau : une panne de connexion ne marque pas le jeton comme invalide.
• Un appel administrateur réussi efface un signalement devenu obsolète, et la levée du signalement est sans effet s'il n'y en avait pas.

Point de contrôle manuel : depuis la page de configuration serveur, déclencher la récupération, relever le code reçu par courriel et le saisir.

Couverture automatique : test/phpunit/integration-dolibarr/AdminTokenRecoveryTest.php (7 methodes, suite integration).

Objectif : une horloge locale qui dérive fausse la détection d'expiration des jetons. Le module interroge l'heure du serveur et classe l'écart.

Vérifications :

• Écart nul : état correct.
• Local en avance ou en retard au-delà du seuil : état critique.
• Écart dans la bande intermédiaire : état à surveiller.
• Serveur injoignable, ou réponse illisible : état inconnu, sans erreur bloquante.

Point de contrôle manuel : la page de diagnostics doit afficher l'écart d'horloge mesuré.

Couverture automatique : test/phpunit/integration-dolibarr/ClockSkewTest.php (6 methodes, suite integration).

Objectif : pour un document qu'il ne peut pas produire, le serveur DoliSCAN renvoie une image de remplacement avec un code 200. Elle était enregistrée sous le nom .pdf demandé et plus jamais retéléchargée, puisque toutes les procédures sautent un justificatif dont le fichier existe.

Vérifications :

• Une image reçue à la place d'un PDF n'est ni écrite ni enregistrée dans la GED.
• Un vrai PDF est écrit puis enregistré, et n'est pas retéléchargé ensuite.
• Une image de remplacement déjà enregistrée est remplacée par le vrai PDF, y compris lors de l'import d'une ligne.
• Un document absent du serveur est signalé comme tel.

Point de contrôle manuel : le serveur est simulé. Sur un compte réel dont un justificatif n'est pas encore prêt, synchroniser et vérifier qu'aucun faux PDF n'est joint, puis resynchroniser une fois le justificatif prêt et vérifier que le vrai PDF est joint.

Couverture automatique : test/phpunit/integration-dolibarr/PlaceholderReceiptTest.php (6 méthodes, suite integration).

Objectif : à partir de Dolibarr 20, la recherche dans la GED passe par le filtre de recherche universel. La parenthèse du dossier d'une note de frais brouillon, (PROVn), invalidait tout le filtre : le justificatif passait pour absent et son second enregistrement échouait.

Vérifications :

• Le justificatif d'une note de frais brouillon est trouvé, sans confusion avec les autres dossiers brouillons.
• Un justificatif est trouvé par son seul code, ou par son code et sa facture fournisseur.
• La recherche exacte ignore un fragment de nom.
• Le cœur refuse bien une parenthèse dans une valeur du filtre, ce qui justifie le contournement.

Point de contrôle manuel : le harnais tourne en Dolibarr 18, avec le même analyseur de filtre que la 20. Sur une instance Dolibarr 20 ou plus, importer une note de frais restée en brouillon, resynchroniser ses justificatifs, et vérifier qu'aucune erreur n'apparaît et que chaque justificatif n'est présent qu'une fois.

Couverture automatique : test/phpunit/integration-dolibarr/EcmFilesUsfFilterTest.php (6 méthodes, suite integration).

Objectif : avec la correspondance multi-société, un salarié a volontairement un identifiant DoliSCAN différent dans chaque société. L'adresse des justificatifs était construite avec son courriel Dolibarr, et chaque téléchargement échouait sans message utile.

Vérifications :

• L'identifiant du compte est utilisé, et non le courriel Dolibarr.
• Sans compte, le courriel sert de repli.
• L'adresse de téléchargement porte l'identifiant du compte.

Point de contrôle manuel : le serveur est simulé. Sur une instance multi-société, pour un salarié dont l'identifiant DoliSCAN diffère de son courriel Dolibarr, synchroniser et vérifier que ses justificatifs sont téléchargés.

Couverture automatique : test/phpunit/integration-dolibarr/JustificatifUrlLoginTest.php (3 méthodes, suite integration).

Objectif : un disque plein, un montage en lecture seule ou un mauvais propriétaire ne produisaient ni fichier, ni journal, ni erreur : l'import annonçait un succès et la note de frais restait sans justificatif.

Vérifications :

• Une destination accessible reçoit le contenu, même vide.
• Un dossier inaccessible est signalé comme un échec.
• Un fichier non inscriptible est signalé comme un échec.

Couverture automatique : test/phpunit/unit/WriteFileTest.php (4 méthodes, suite unit).

Objectif : un justificatif auquel le serveur DoliSCAN répond 404 était redemandé à chaque passage de la tâche planifiée, sans fin. Le délai avant la demande suivante double à chaque 404, sans jamais devenir un abandon définitif, car l'application mobile peut envoyer le justificatif en retard.

Vérifications :

• Le délai vaut 1, 2, 4, 8, 16 jours, puis 30 jours au plus.
• Un premier 404 est enregistré avec la date de la demande suivante ; un nouveau 404 garde la date du premier et double le délai.
• Un justificatif sans 404 enregistré est toujours demandé ; un autre ne l'est qu'une fois son délai écoulé, sans retenir les autres justificatifs.
• Les justificatifs que personne n'a demandés depuis 90 jours sont oubliés.
• Une valeur enregistrée illisible repart d'une liste vide.
• L'espacement est inactif tant que la tâche planifiée ne l'active pas.

Couverture automatique : test/phpunit/unit/ReceiptRetryScheduleTest.php (10 méthodes, suite unit).

Objectif : la resynchronisation des brouillons et l'import des notes encore ouvertes redemandaient chaque jour un justificatif auquel le serveur répond 404. La tâche planifiée attend désormais son délai, tandis qu'une personne qui synchronise depuis une page obtient toujours une nouvelle demande.

Vérifications :

• Pendant la tâche planifiée, un justificatif qui vient de répondre 404 n'est pas redemandé avant son délai, et le rapport donne la date de la prochaine demande automatique.
• Depuis une page, le justificatif est redemandé à chaque fois, et chaque 404 compte.
• Une fois le délai écoulé, la tâche planifiée redemande le justificatif ; reçu enfin, il est écrit et ses 404 passés sont oubliés.
• De bout en bout, deux passages de la tâche planifiée sur un brouillon ne demandent le justificatif manquant qu'une fois, l'espacement ne reste pas actif après le passage, et la resynchronisation de la note depuis sa fiche le redemande tout de suite.

Point de contrôle manuel : le serveur est simulé. Sur un compte réel dont un justificatif est absent du serveur, vérifier dans le rapport de la tâche planifiée la date de la prochaine demande automatique, puis que la resynchronisation de la note depuis sa fiche redemande le justificatif.

Couverture automatique : test/phpunit/integration-dolibarr/UnavailableReceiptRetryTest.php (4 méthodes, suite integration).

Objectif : pour une personne qui travaille dans deux sociétés, aucune recherche lancée dans une société ne doit aboutir sur une ligne de l'autre : sinon les lignes d'une société sont rattachées à la note de frais ou à la facture de l'autre.

Vérifications :

• La recherche de doublon de note de frais ignore l'autre entité, trouve dans l'entité courante et la préfère quand les deux existent.
• La recherche de doublon de facture fournisseur, par clé d'import comme par référence automatique, fait de même.
• La purge des brouillons reste dans l'entité courante.
• Les factures fournisseur liées ne remontent que celles de l'entité courante.
• Une note de frais close dans une autre entité ne bloque pas la synchronisation de celle-ci, et un brouillon d'une autre entité n'est pas modifié.
• Un objet d'une autre entité est refusé ; un objet d'entité inconnue est refusé en multi-société, mais reste accessible sur une installation à une seule société.

Couverture automatique : test/phpunit/integration-dolibarr/MultiEntityIsolationTest.php (14 méthodes, suite integration).

Objectif : la synchronisation a longtemps enregistré les notes de frais DoliSCAN de toutes les sociétés dans l'entité 1, si bien que la liste restait vide dans les autres. La page de diagnostics les remet dans leur entité et nettoie les copies, sans jamais toucher à ce que la comptabilité détient.

Vérifications :

• Une ligne liée à une note de frais Dolibarr prend son entité ; une ligne non liée prend celle de l'unique compte du salarié ; avec plusieurs comptes, elle est laissée en place et signalée.
• Une ligne déjà dans son entité, ou déjà recréée dans son entité, n'est pas déplacée, et une seconde exécution ne change rien.
• Parmi les copies, celle liée à une note de frais Dolibarr est gardée et transmet son lien ; le nettoyage automatique supprime les autres.
• Deux notes de frais validées pour une même note sont laissées à l'arbitrage d'une personne.
• Une note de frais brouillon déjà passée en comptabilité, payée ou portant une ligne ventilée, une facture fournisseur brouillon tenue par la comptabilité et un document invérifiable ne sont jamais supprimés.
• La ligne réparée apparaît dans la liste de son entité, et le filtre par utilisateur ne propose que les titulaires de compte de l'entité.
• Le partage de multi-société est lu par entité, et rien n'est partagé tant qu'il est désactivé.

Couverture automatique : test/phpunit/integration-dolibarr/MyNdfEntityRepairTest.php (28 méthodes, suite integration).

Objectif : la page de correspondance multi-société déplace un compte, et son jeton, vers une autre société : une erreur confierait les notes de frais d'un salarié à la mauvaise société.

Vérifications :

• Un compte peut être déplacé vers une entité où le salarié n'a pas encore de compte.
• Le déplacement est refusé quand un compte existe déjà (un seul compte par salarié et par entité).
• Supprimer une correspondance ne retire que celle de la société visée.
• La page est réservée au super administrateur.

Point de contrôle manuel : les requêtes de la page sont rejouées, pas la page elle-même. Sur une instance multi-société, déplacer un compte depuis la page de correspondance, puis vérifier qu'il apparaît dans la liste des comptes de la société d'arrivée et plus dans celle de départ.

Couverture automatique : test/phpunit/integration-dolibarr/MulticompanyMappingActionsTest.php (4 méthodes, suite integration).

Objectif : l'envoi des projets transmet au serveur DoliSCAN la liste des identifiants des salariés qui y ont accès. En multi-société, les adresses des salariés de toutes les autres sociétés partaient avec le numéro d'immatriculation de la société courante.

Vérifications :

• Seuls les identifiants DoliSCAN de l'entité courante sont envoyés avec ses projets.
• Une entité sans compte n'envoie aucun identifiant.
• Les projets clos sont envoyés comme terminés quand l'option est active, et ne sont pas envoyés sinon.

Point de contrôle manuel : le serveur est simulé. Après un envoi des projets, vérifier dans l'application mobile d'un salarié que les projets de sa société sont proposés, et pas ceux d'une autre société.

Couverture automatique : test/phpunit/integration-dolibarr/PushProjectsEntityTest.php (4 méthodes, suite integration).

Objectif : pour une personne qui travaille dans deux sociétés, la resynchronisation retraitait dans la société courante les notes de frais de l'autre, fichiers et entrées de la GED compris, avec les identifiants du premier compte trouvé.

Vérifications :

• Seules les notes de frais de l'entité courante sont retraitées.
• Le compte DoliSCAN utilisé est celui de l'entité courante.

Couverture automatique : test/phpunit/integration-dolibarr/ResyncAllDocumentsEntityTest.php (2 méthodes, suite integration).

Objectif : la constante DOLISCAN_UPDATE_1_7_10 date le passage de la recherche de doublon à la clé d'import. Elle était écrite et lue dans l'entité 0 : en multi-société, une seule société décidait du comportement de toutes les autres.

Vérifications :

• La recherche de doublon de facture fournisseur l'écrit dans l'entité courante.
• La recherche de doublon de ligne de note de frais la lit dans l'entité courante.

Couverture automatique : test/phpunit/integration-dolibarr/UpdateConstEntityTest.php (2 méthodes, suite integration).

Objectif : attraper la classe de bug qui a frappé la production le 27 avril 2026 : une erreur fatale de type sur une page de configuration, parce qu'une constante inexistante sur une installation neuve était transmise à une fonction au typage strict. Aucun test ne chargeait alors les pages d'administration de bout en bout.

Chaque page est chargée dans un processus PHP réel et doit terminer sans erreur fatale, sans exception non rattrapée, sans conflit de typage et sans avertissement émis par un fichier du module.

Vérifications :

• Les huit pages de configuration (générale, banque, professionnel, personnel, serveur, divers, carburant, règles personnalisées) se chargent sur une configuration vierge.
• La page de diagnostics, la page "à propos" et la page de correspondance multi-sociétés aussi.
• La page de diagnostics se charge également avec une note de frais existante, et liste les droits des titulaires de comptes DoliSCAN.
• Les pages banque, professionnel et personnel se chargent avec des slugs configurés.
• Elles survivent à un mapping cassé en base, sans erreur fatale.

Point de contrôle manuel : sur une installation neuve, ouvrir successivement chaque page de configuration du module.

Couverture automatique : test/phpunit/integration-dolibarr/AdminPagesSmokeTest.php (19 methodes, suite integration).

Objectif : le formulaire de retour utilisait l'adresse saisie comme expéditeur : le serveur envoyait au nom d'un domaine qui ne l'y autorise pas, et le message était rejeté ou classé en indésirable sans que personne ne le sache.

Vérifications :

• L'expéditeur est l'adresse configurée de l'installation.
• L'adresse saisie devient l'adresse de réponse.
• L'ancien assistant d'envoi a disparu, et le paramètre est passé à la position attendue par le cœur.

Point de contrôle manuel : l'acheminement réel n'est pas testé. Envoyer un retour depuis la page À propos, vérifier qu'il arrive en boîte de réception, et qu'une réponse part vers l'adresse saisie.

Couverture automatique : test/phpunit/integration-dolibarr/FeedbackMailSenderTest.php (4 méthodes, suite integration).

Objectif : la page de configuration du carburant reposait sur une copie d'une fonction du cœur dont la requête était cassée dès qu'un fournisseur était passé.

Vérifications :

• Les produits achetables sont listés, indexés par identifiant.
• Les produits qui ne peuvent pas être achetés sont exclus.
• La liste se limite à l'entité courante.
• Un catalogue vide est toléré.

Couverture automatique : test/phpunit/integration-dolibarr/ProductSelectListTest.php (4 méthodes, suite integration).

Objectif : les libellés des champs étaient en français brut et les statuts portaient des entités HTML, affichées littéralement et intraduisibles.

Vérifications :

• Aucun libellé ne porte d'entité HTML.
• Chaque valeur de statut est une clé de traduction.
• Les libellés propres à DoliSCAN sont traduits.

Couverture automatique : test/phpunit/integration-dolibarr/FieldLabelsTest.php (3 méthodes, suite integration).

Objectif : l'onglet Info lisait des colonnes absentes des tables : le créateur n'était jamais affiché et chaque appel levait une notice.

Vérifications :

• Le créateur d'un compte est résolu sans notice.
• Le créateur d'une note de frais est résolu sans notice.

Couverture automatique : test/phpunit/integration-dolibarr/ObjectInfoTest.php (2 méthodes, suite integration).

Objectif : appliquer au descripteur du module les règles communes à tous les modules de l'équipe.

Vérifications :

• Un seul descripteur, nommé d'après sa classe, avec une identité complète.
• Les droits utilisés par le code sont déclarés.
• Les versions minimales de PHP et de Dolibarr et l'adresse de dernière version sont renseignées.
• Les parties déclarées correspondent aux fichiers, et les fichiers déclarés existent.
• La règle de numérotation des droits est désactivée exprès : renuméroter changerait les droits déjà accordés sur les bases installées.

Couverture automatique : test/phpunit/integration-dolibarr/ModuleDescriptorTest.php (9 méthodes héritées du paquet cap-rel/dolibarr-module-tests, règles descriptor.*, suite integration).

Objectif : vérifier sur un vrai Dolibarr que l'activation du module installe tout ce qu'il déclare.

Vérifications :

• L'activation active le module sans aucun avertissement venu du module.
• Chaque table déclarée existe, chaque droit déclaré est enregistré une seule fois.
• La version installée est enregistrée.
• Le module se réactive proprement après une désactivation.

Couverture automatique : test/phpunit/integration-dolibarr/ModuleInitTest.php (7 méthodes héritées du paquet cap-rel/dolibarr-module-tests, règles module-init.*, suite integration).

Objectif : le paquet livré doit passer la validation de la DoliStore.

Vérifications :

• Aucun fichier livré ne contrevient à la règle d'inclusion de main.inc.php, ni n'inclut le module par DOL_DOCUMENT_ROOT.
• L'archive est nommée d'après le module.
• Les pages chargent Dolibarr par le fichier de configuration prévu.

Couverture automatique : test/phpunit/unit/DolistorePackagingRulesTest.php (5 méthodes héritées du paquet cap-rel/dolibarr-module-tests, règles dolistore.*, suite unit).

Objectif : appliquer au code livré les conventions communes à tous les modules de l'équipe.

Vérifications :

• Les fichiers du module sont chargés par dol_include_once().
• Aucun caractère invisible.
• Aucun appel à une fonction du cœur qui n'existe pas.
• Aucune sortie de débogage.

Couverture automatique : test/phpunit/unit/SourceConventionsTest.php (5 méthodes héritées du paquet cap-rel/dolibarr-module-tests, règles source.*, suite unit).

Objectif : l'archive embarquait tous les fichiers Markdown de la racine, notes internes et listes de travail comprises.

Vérifications :

• La documentation est livrée, les notes internes ne le sont pas.
• Aucun joker sur les fichiers Markdown, et chaque fichier Markdown de la racine est explicitement livré ou écarté.
• L'archive réellement construite porte tout ce dont le module a besoin.

Couverture automatique : test/phpunit/unit/BuildZipContentTest.php (5 méthodes, suite unit).

Objectif : les dossiers de l'archive étaient stockés en 0777, accessibles en écriture à tout compte du serveur après décompression, et les fichiers prenaient le masque de celui qui construisait l'archive, parfois illisibles pour le serveur web.

Vérifications :

• L'archive, construite pour de vrai sous le masque le plus restrictif, porte des dossiers en 755 et des fichiers en 644, et reste elle-même lisible par tous.

Couverture automatique : test/phpunit/unit/BuildZipPermissionsTest.php (1 méthode, suite unit).

Objectif : chaque synchronisation cherche une note de frais par sa clé d'import, et les diagnostics font une jointure sur le lien vers la note de frais Dolibarr : sans index, deux parcours complets de table qui grandissent avec l'historique.

Vérifications :

• La clé d'import est indexée.
• Le lien vers la note de frais Dolibarr est indexé.
• Le fichier des clés ne contient que des index et des contraintes, les scripts de mise à jour que des ALTER.

Couverture automatique : test/phpunit/unit/SchemaIndexesTest.php (4 méthodes, suite unit).

Objectif : deux causes racines corrigées. D'une part le droit d'écriture sur les notes de frais DoliSCAN n'était pas déclaré alors que quatre méthodes le vérifiaient : le contrôle répondait non à tout le monde, administrateurs compris, et la validation échouait systématiquement. D'autre part les droits n'étaient jamais chargés sur les utilisateurs construits par le module (la simple relecture d'un utilisateur laisse ses droits vides).

Vérifications :

• Le descripteur du module déclare bien le droit d'écriture sur les notes de frais.
• Les identifiants de droits déclarés sont uniques et le catalogue interne correspond au descripteur.
• Un changement de statut refusé hors contexte système porte une explication en clair, pas seulement un code.
• En contexte système, la validation aboutit même si le titulaire du compte n'a aucun droit DoliSCAN, et un import complet valide bien sa note de frais.
• Une fois le contexte système refermé, le changement de statut est de nouveau refusé.
• Le chargement d'un utilisateur avec ses droits les renseigne réellement, et renvoie vide sur un utilisateur inconnu.
• Les droits absents de la table des permissions sont détectés (cas d'une mise à jour qui ajoute un droit sans réactivation du module).

Point de contrôle manuel : après une mise à jour du module, ouvrir la page de diagnostics ; si des permissions manquent, utiliser le bouton de réinstallation des permissions.

Couverture automatique : test/phpunit/integration-dolibarr/PermissionsSystemContextTest.php (13 methodes, suite integration).

Objectif : un salarié qui ne détient que les droits DoliSCAN sur ses propres données ne doit ni voir ni modifier ce qui appartient à un collègue, même en devinant l'identifiant dans l'adresse. Un bouton masqué ne suffit pas : le serveur doit répondre 403, sans aucune donnée du collègue.

Vérifications :

• La fiche, l'onglet justificatifs, l'import, la resynchronisation, la validation et la suppression de la note de frais d'un collègue sont refusés ; le propriétaire garde l'accès aux siennes.
• Les listes des notes de frais et des comptes ne montrent que ce qui appartient au salarié et à l'entité courante, et le filtre par utilisateur ne propose que lui.
• Les actions de masse (import, validation) refusent une note de frais d'un collègue glissée dans la sélection, et restent possibles sur les siennes.
• La synchronisation de tous les comptes est refusée à un salarié.
• Aucune page ne rend en clair le jeton d'un compte ni le jeton administrateur.
• La création et la suppression d'un compte distant, le test de connexion et les synchronisations exigent un jeton CSRF, et les liens d'action en portent un.
• Une date de début invalide n'est pas enregistrée.
• Les réparations de la page de diagnostics ramènent dans la liste les notes de frais rangées dans la mauvaise entité.

Couverture automatique : test/phpunit/http/PagesAccessControlHttpTest.php (49 méthodes, suite http, serveur PHP éphémère).

Objectif : quand un responsable importe la note de frais d'un collègue, la note de frais Dolibarr doit être créée au nom du collègue, jamais au nom de la personne qui a cliqué.

Vérifications :

• Le propriétaire de la note de frais est retrouvé, avec ses droits chargés.
• Sans propriétaire, ou si son utilisateur n'existe plus, aucun utilisateur n'est désigné : l'import ne se rabat pas sur l'utilisateur connecté.

Couverture automatique : test/phpunit/integration-dolibarr/ImportUserForTest.php (4 méthodes, suite integration).

Objectif : les trois pages de maintenance lisent les factures, les utilisateurs et les comptes DoliSCAN de toutes les sociétés : en multi-société, l'administrateur d'une seule société ne doit pas y accéder.

Vérifications :

• Aucune des trois pages ne se contente du drapeau administrateur.
• Toutes passent par le contrôle du super administrateur.
• Aucune n'affiche l'erreur SQL brute.
• Sans multi-société, un administrateur garde l'accès.

Couverture automatique : test/phpunit/integration-dolibarr/MaintenancePagesGuardTest.php (4 méthodes, suite integration).

Objectif : en multi-société, l'administrateur d'une société ne doit pas pouvoir déplacer dans sa société le compte DoliSCAN d'un salarié d'une autre société, puis importer ses notes de frais.

Vérifications :

• Un utilisateur simple n'est jamais super administrateur.
• En multi-société, l'administrateur d'une entité ne l'est pas ; celui de l'entité 0 l'est.
• Sans multi-société, tout administrateur l'est.
• Une valeur qui n'est pas un utilisateur est refusée.

Couverture automatique : test/phpunit/integration-dolibarr/SuperAdminGuardTest.php (5 méthodes, suite integration).

Objectif : le message qui signale un droit manquant doit envoyer l'administrateur là où il peut l'accorder. En mode transverse, l'onglet Permissions d'un utilisateur est en lecture seule hors de l'entité principale, et les droits dans une société viennent des groupes de l'utilisateur dans cette société.

Vérifications :

• Hors mode transverse, le message indique l'onglet Permissions de l'utilisateur.
• En mode transverse, il nomme le groupe de l'utilisateur dans la société, et tous ses groupes s'il en a plusieurs.
• En mode transverse, un salarié sans groupe dans la société est signalé comme tel.

Point de contrôle manuel : le mode transverse est simulé. Sur une instance multi-société en mode transverse, retirer un droit DoliSCAN à un salarié, lancer la synchronisation, suivre l'indication du message et vérifier que la page atteinte permet d'accorder le droit.

Couverture automatique : test/phpunit/integration-dolibarr/PermsTransverseModeTest.php (4 méthodes, suite integration).

Objectif : une entrée de menu visible de tous menait à une page qui répond 403 sans le bon droit.

Vérifications :

• Le module déclare des entrées de menu.
• Aucune n'est visible de tous, chacune dépend d'un droit DoliSCAN.
• Aucun titre n'est écrit en français brut, et chaque titre a sa traduction française.

Couverture automatique : test/phpunit/integration-dolibarr/MenuDeclarationTest.php (5 méthodes, suite integration).

Objectif : un salarié qui ne paie qu'avec ses propres moyens ne reçoit jamais de facture fournisseur de l'import : l'audit des droits (page de diagnostics, rapport de la tâche planifiée) ne doit pas lui réclamer ce droit.

Vérifications :

• Un salarié aux seules dépenses personnelles n'est pas considéré comme payeur professionnel.
• Un montant professionnel sur une note de frais DoliSCAN de l'entité le rend payeur professionnel ; celui d'une autre entité est ignoré.
• Une carte professionnelle déclarée par l'administrateur suffit, sans aucun historique.
• L'audit ne réclame le droit de facture fournisseur qu'aux payeurs professionnels.

Couverture automatique : test/phpunit/integration-dolibarr/UserUsesProPaymentTest.php (5 méthodes, suite integration).

Objectif : ce jeton permet de créer, désactiver et supprimer tous les comptes distants de la société. Il était stocké en clair alors que les jetons des salariés étaient déjà chiffrés.

Vérifications :

• Le jeton stocké n'est pas en clair, et sa relecture redonne le jeton d'origine.
• Un ancien jeton stocké en clair reste lisible.
• Un jeton vide reste vide.
• L'en-tête des appels à l'API porte le jeton déchiffré.

Couverture automatique : test/phpunit/integration-dolibarr/AdminApiKeyStorageTest.php (5 méthodes, suite integration).

Objectif : les pages de correspondance affichent les identifiants DoliSCAN des comptes et les libellés de types de frais téléchargés depuis l'API : les deux arrivaient tels quels dans le HTML.

Vérifications :

• Aucune page n'insère un libellé sans l'échapper.
• La page des banques échappe l'identifiant du compte.
• La correspondance bancaire par utilisateur n'enregistre que des entiers.

Couverture automatique : test/phpunit/integration-dolibarr/AdminPagesEscapingTest.php (3 méthodes, suite integration).

Objectif : de bout en bout, un libellé saisi dans l'application mobile ne doit jamais parvenir sous forme de balise au navigateur de l'administrateur.

Vérifications :

• La description d'une ligne carburant ne porte aucune balise venue des valeurs distantes.
• Le rapport d'import échappe le libellé distant.

Couverture automatique : test/phpunit/integration-dolibarr/HostileRemoteLabelTest.php (2 méthodes, suite integration).

Objectif : libellés, dates, champs du véhicule et noms de fichier viennent de ce que le salarié a saisi dans l'application. Insérés tels quels dans les rapports d'import et la description des lignes, ils permettaient une injection de script stockée.

Vérifications :

• Les chevrons sont neutralisés, les accents restent lisibles, une valeur vide reste vide.
• Le paragraphe du véhicule échappe chaque champ, garde les valeurs lisibles et tolère des champs absents.

Couverture automatique : test/phpunit/unit/EscapeRemoteHtmlTest.php (6 méthodes, suite unit).

Objectif : le nom de fichier est saisi dans l'application mobile et renvoyé par un serveur dont l'adresse est un réglage libre : il ne doit jamais permettre d'écrire hors du dossier de la note de frais ou de la facture fournisseur.

Vérifications :

• Une destination hors du dossier de sortie est refusée.
• L'écriture dans le dossier de sortie fonctionne toujours.
• La resynchronisation garde dans le dossier de la note de frais un nom de fichier qui tente d'en sortir.

Couverture automatique : test/phpunit/integration-dolibarr/PathTraversalGuardTest.php (3 méthodes, suite integration).

Objectif : un nom de fichier venu de l'API doit pouvoir être utilisé sans risque dans un chemin de destination.

Vérifications :

• Un nom sûr est produit à partir du nom distant.
• Une valeur nulle est acceptée.
• Aucun séparateur de chemin ne subsiste dans le résultat.

Couverture automatique : test/phpunit/unit/RemoteFileNameTest.php (3 méthodes, suite unit).

Objectif : identifiants, sid et noms de fichier étaient insérés tels quels dans le chemin des adresses de l'API : une barre oblique, un espace ou un point d'interrogation changeait le point d'entrée appelé ou tronquait le chemin.

Vérifications :

• Chaque segment est encodé, sauf l'arobase, légale dans un chemin et attendue par le serveur.
• Aucune valeur ne peut sortir de sa position dans le chemin.
• Une valeur nulle est traitée comme vide.

Couverture automatique : test/phpunit/unit/UrlSegmentTest.php (3 méthodes, suite unit).

Objectif : un salarié pouvait faire exécuter une formule dans le tableur du comptable en nommant une dépense =HYPERLINK(...) dans l'application mobile.

Vérifications :

• Une cellule commençant par =, +, - ou @ est neutralisée.
• Les valeurs inoffensives sont laissées telles quelles.
• Les nombres gardent leur type.

Couverture automatique : test/phpunit/unit/CsvFormulaTest.php (3 méthodes, suite unit).

Objectif : les réponses de création de compte portent un jeton neuf ; les journaliser telles quelles l'écrivait en clair dans dolibarr.log, ce qui annulait le chiffrement en base.

Vérifications :

• Le jeton d'un objet est masqué, y compris dans un corps HTTP décodé et dans une structure profondément imbriquée.
• Toutes les graphies de clés secrètes sont couvertes.
• Un JWT dans une chaîne libre est masqué sans indice de clé.
• Une charge sans secret reste intacte ; valeur nulle et scalaires sont rendus.
• Une structure cyclique est coupée au lieu de boucler.

Couverture automatique : test/phpunit/unit/RedactSecretsTest.php (8 méthodes, suite unit).

Objectif : la page de configuration affichait le jeton DoliSCAN principal en entier : il doit rester reconnaissable sans être utilisable depuis une capture d'écran.

Vérifications :

• Le jeton est rendu masqué.
• Jamais plus de quatre caractères ne sont visibles.

Couverture automatique : test/phpunit/unit/MaskApiKeyTest.php (2 méthodes, suite unit).

Objectif : trois sondes appelaient bl.cap-rel.fr, en dur, à chaque erreur réseau du module, sans moyen de les couper ; la détection de l'adresse IP publique se rabattait sur un tiers en HTTP, sans délai d'attente.

Vérifications :

• L'adresse par défaut est en HTTPS et peut être remplacée par un réglage.
• Les sondes peuvent être désactivées, et aucune n'est alors envoyée.
• La détection de l'adresse IP utilise l'adresse configurée, et un échec renvoie une valeur vide sans autre appel.

Couverture automatique : test/phpunit/integration-dolibarr/SideChannelTest.php (6 méthodes, suite integration).

Objectif : en ligne de commande, l'adresse de l'appelant n'existe pas : la tâche planifiée levait un avertissement à chaque calcul du jeton. L'algorithme reste inchangé, le serveur décode exactement ce format.

Vérifications :

• Le jeton est calculé à partir de l'adresse de l'appelant.
• Sans adresse distante, une clé nulle est utilisée sans aucune notice.

Couverture automatique : test/phpunit/integration-dolibarr/BlacklistTokenTest.php (2 méthodes, suite integration).

Objectif : c'est le coeur de la synchronisation DoliSCAN vers Dolibarr. La synchronisation de compte récupère la liste des notes de frais du serveur, puis chaque note est traitée : téléchargement du PDF, puis import complet.

Vérifications :

• Une adresse de messagerie interdite fait sortir immédiatement.
• Une liste de notes de frais vide est gérée sans erreur.
• L'appel à l'API porte bien la plage de dates attendue.
• Les notes antérieures à la date de début configurée sur l'utilisateur sont ignorées.
• Une note déjà validée et définitive n'est pas retraitée.
• Une note provisoire voit son PDF retéléchargé.
• Une note en brouillon déclenche le téléchargement du PDF puis l'import complet.

Point de contrôle manuel : lancer une synchronisation manuelle depuis la page d'accueil du module et suivre le compte rendu affiché.

Couverture automatique : test/phpunit/integration-dolibarr/MyDoliSCANSyncTest.php (7 methodes, suite integration).

Objectif : point d'entrée appelé par l'ordonnanceur de Dolibarr. Il commence par vérifier la connexion administrateur, puis parcourt les comptes, et enregistre un compte rendu consultable.

Vérifications :

• Si le contrôle préalable échoue (serveur vide ou injoignable), la tâche renvoie -1, écrit un compte rendu à l'étape "préalable" et ne touche à aucun compte.
• Le contrôle préalable interroge bien la route de test de l'API.
• La date de dernière synchronisation n'est mise à jour que si tous les comptes ont été synchronisés sans erreur.
• Le verrou de 23 heures empêche une seconde synchronisation trop rapprochée.

Point de contrôle manuel : dans Dolibarr, ouvrir la tâche planifiée DoliSCAN, la lancer manuellement, puis consulter le compte rendu sur la page de configuration.

Couverture automatique : test/phpunit/integration-dolibarr/MyDoliSCANCronTest.php (6 methodes, suite integration).

Objectif : prévenir visiblement l'utilisateur quand l'ordonnanceur Dolibarr a cessé de déclencher la synchronisation, cause fréquente de tickets de support.

Vérifications :

• Aucune alerte si le module n'a pas de tâche planifiée déclarée.
• Une tâche active dont la prochaine exécution est dans le passé est signalée en retard.
• Une tâche désactivée est signalée.
• Une prochaine exécution dans le futur, ou un nombre maximal d'exécutions déjà atteint, ne déclenchent pas d'alerte.
• Le bandeau est bien émis en cas de retard, et reste silencieux quand la tâche est à l'heure.

Point de contrôle manuel : désactiver la tâche planifiée DoliSCAN et recharger une page du module ; le bandeau doit apparaître.

Couverture automatique : test/phpunit/integration-dolibarr/CronStatusWarningTest.php (7 methodes, suite integration).

Objectif : la référence visible dans la liste des notes de frais DoliSCAN suit le format historique "DOLISCAN-XX20260301" (initiales de l'utilisateur, puis date locale sans tirets). Le passage aux dates ISO l'avait transformée en chaîne illisible du type "20260331T22_00_00.000000Z".

Vérifications :

• Après une synchronisation avec des dates ISO, la référence respecte le format historique, en heure d'été comme en heure d'hiver.
• La note de frais Dolibarr porte bien la date locale.
• Deux synchronisations sur le même identifiant serveur ne laissent qu'une seule note de frais.

Point de contrôle manuel : ouvrir la liste des notes de frais DoliSCAN et contrôler la colonne référence.

Couverture automatique : test/phpunit/integration-dolibarr/SyncNdfRefFormatTest.php (4 methodes, suite integration).

Objectif : récupérer les justificatifs absents de la gestion documentaire pour une note de frais donnée.

Vérifications :

• Sans identifiant d'utilisateur, aucune action et aucun appel réseau.
• Un utilisateur sans compte DoliSCAN renvoie un échec et trace un avertissement.
• Avec une charge utile valide et une gestion documentaire vide, les fichiers manquants sont détectés et les routes de téléchargement du PDF, des détails et des images sont appelées.

Point de contrôle manuel : supprimer un justificatif dans la gestion documentaire, relancer la resynchronisation des documents et vérifier qu'il revient.

Couverture automatique : test/phpunit/integration-dolibarr/ResyncAllDocumentsNDFTest.php (3 methodes, suite integration).

Objectif : incident de production. Une ligne de dépense dont le nom de fichier était vide produisait un critère de recherche vide, qui atteignait la gestion documentaire sous la forme "nom de fichier LIKE %%" et correspondait donc à TOUTES les lignes. Les boucles suivantes supprimaient les orphelines et réécrivaient les autres, déclenchant les événements de modification de fichier sur tous les modules installés : 5578 mises à jour et 39041 appels de déclencheurs pour une seule exécution.

Vérifications :

• Une ligne dont le nom de fichier est vide ou sans extension est ignorée, sans jamais toucher la table de la gestion documentaire.
• Le nombre de lignes de la gestion documentaire est strictement stable d'une resynchronisation à l'autre.

Point de contrôle manuel : lancer une resynchronisation complète et contrôler dans les journaux qu'aucune vague d'écritures documentaires n'est déclenchée.

Couverture automatique : test/phpunit/integration-dolibarr/ResyncEmptyFileNameGuardTest.php (2 methodes, suite integration).

Objectif : une erreur passagère de la base (table verrouillée, migration en cours) transformait toute l'exécution de la tâche planifiée en erreur fatale au lieu d'un échec signalé.

Vérifications :

• Une erreur sur la recherche des notes de frais est signalée.
• Une erreur sur la liste des comptes est signalée.

Couverture automatique : test/phpunit/integration-dolibarr/FetchAllFailureGuardTest.php (2 méthodes, suite integration).

Objectif : le résultat de l'import était jeté : un compte en échec comptait comme réussi, la date de dernière synchronisation avançait et le rapport ne montrait rien. Une société entière pouvait cesser d'importer sans un seul avertissement.

Vérifications :

• Un import en échec fait échouer la synchronisation du compte, et l'échec est nommé dans les erreurs.
• Une synchronisation réussie reste réussie.
• Une note de frais sans dépense laisse le compte en bon état.

Couverture automatique : test/phpunit/integration-dolibarr/SyncAccountReportsImportFailureTest.php (4 méthodes, suite integration).

Objectif : chaque appel à l'API était suivi d'une seconde d'attente : une société de deux cents notes de frais passait plus de dix minutes de la tâche planifiée à dormir. L'attente n'a plus lieu que sur un code 429.

Vérifications :

• Aucune attente après une réussite, une erreur simple ou une réponse inutilisable.
• Attente par défaut sur un code 429.
• L'en-tête Retry-After est respecté et plafonné ; une valeur non numérique donne l'attente par défaut.

Couverture automatique : test/phpunit/unit/ThrottleTest.php (7 méthodes, suite unit).

Objectif : la progression s'écrivait directement sur la sortie, y compris depuis la tâche planifiée, au milieu du flux d'un autre appelant.

Vérifications :

• Le texte est toujours retourné, pour rejoindre le résultat de synchronisation.
• Rien n'est affiché par défaut.
• La progression s'affiche quand une page le demande, et s'arrête quand la demande est retirée.

Couverture automatique : test/phpunit/unit/ProgressStreamTest.php (4 méthodes, suite unit).

Objectif : la liste des types professionnels était téléchargée une seule fois, si bien qu'un type ajouté sur le serveur n'apparaissait jamais ; la liste des types personnels était vidée quand le serveur était injoignable.

Vérifications :

• Une liste contenant un nouveau type remplace la liste en cache.
• Un serveur injoignable laisse la liste en cache intacte.

Point de contrôle manuel : le serveur est simulé. Lorsqu'un type de frais est ajouté sur le serveur DoliSCAN, ouvrir l'onglet de configuration correspondant et vérifier qu'il y apparaît.

Couverture automatique : test/phpunit/integration-dolibarr/ServerListRefreshTest.php (2 méthodes, suite integration).

Objectif : une clé ajoutée en français seulement s'affiche sous son propre nom dans toutes les autres langues.

Vérifications :

• Chaque clé existe dans chaque langue livrée, et aucune langue ne définit une clé absente de la référence.
• Chaque clé demandée par le code est traduite.
• Les clés sont en ASCII et ne sont pas définies deux fois dans un même fichier.
• Aucune valeur n'est entourée de guillemets littéraux, chaque % littéral est doublé.
• Aucune ponctuation interdite n'apparaît dans les fichiers de langue.

Couverture automatique : test/phpunit/unit/LangKeysConsistencyTest.php (8 méthodes, suite unit).

Objectif : appliquer aux fichiers de langue du module les règles communes à tous les modules de l'équipe.

Vérifications :

• Les fichiers de langue sont présents, en lignes clé=valeur, dans le bon encodage, sans clé en double.
• Chaque langue a toutes les clés, avec les mêmes marqueurs de substitution que la référence.
• La ponctuation est en ASCII.
• Les clés utilisées par le code sont définies.

Couverture automatique : test/phpunit/unit/LangFilesTest.php (9 méthodes héritées du paquet cap-rel/dolibarr-module-tests, règles lang.*, suite unit).

Objectif : une phrase française écrite directement dans la page ne peut pas être traduite : les utilisateurs des autres langues la lisent en français et les traducteurs ne la voient jamais.

Vérifications :

• Toute chaîne accentuée des pages qui servent une interface passe par la couche de traduction ; seuls les journaux en sont dispensés.

Couverture automatique : test/phpunit/unit/FrenchStringsAreTranslatedTest.php (1 méthode, suite unit).

Objectif : les modèles de numérotation chargeaient des fichiers de langue que le module ne livre pas : leurs messages d'erreur s'affichaient sous forme de clés de traduction.

Vérifications :

• La liste des fichiers de langue livrés n'est pas vide.
• Les deux classes ne chargent qu'un fichier de langue livré.
• Le modèle de numérotation produit toujours une référence.

Couverture automatique : test/phpunit/integration-dolibarr/LangDomainTest.php (3 méthodes, suite integration).

Objectif : quand un justificatif porte plusieurs taux de TVA, la somme des TTC recalculés taux par taux peut s'écarter d'un ou deux centimes du TTC du ticket. L'écart est absorbé sur la dernière ligne de TVA pour que le total importé dans Dolibarr corresponde exactement au ticket, condition du rapprochement bancaire.

Vérifications :

• Le calcul d'une ligne de TVA est exact à 20 %, à 5,5 % et à taux nul (HT = TTC).
• Sans écart, la correction ne modifie rien.
• Un écart de +1 ou -1 centime est absorbé et le total du ticket est restauré à l'exact.
• La ligne corrigée reste cohérente en interne (HT + TVA = TTC).
• L'insertion Dolibarr basée sur le TTC préserve la correction, là où l'insertion basée sur le HT peut la réintroduire.
• Scénario complet restaurant à deux taux, puis cas à trois taux.

Point de contrôle manuel : importer un ticket de restaurant avec TVA 10 % et 20 %, ouvrir la facture fournisseur générée et vérifier que le TTC est identique au centime près au montant du ticket.

Couverture automatique : test/phpunit/unit/VatRoundingTest.php (12 methodes, suite unit).

Objectif : empêcher l'accumulation d'erreurs d'arrondi de corrompre la comptabilité de TVA. La fonction parcourt toutes les lignes d'une note de frais et recalcule HT et TVA à partir du TTC et du taux dès que l'écart dépasse 0,20.

Vérifications :

• Sans identifiant d'utilisateur, la fonction sort immédiatement sans rien modifier.
• Une ligne cohérente n'est pas touchée.
• Une ligne incohérente voit son HT et sa TVA recalculés depuis le TTC.
• Un écart faible, sous le seuil, est conservé tel quel.
• Dans une note de frais mixte, seules les lignes incohérentes sont corrigées.
• La fonction renvoie un rapport HTML exploitable.

Point de contrôle manuel : depuis la fiche d'une note de frais DoliSCAN, lancer la vérification TVA et contrôler le rapport affiché.

Couverture automatique : test/phpunit/integration-dolibarr/CheckAndCorrectVATNDFTest.php (6 methodes, suite integration).

Objectif : avant correction, la branche carburant des véhicules utilitaires inversait HT et TVA (un ticket de 60 EUR à 20 % enregistré avec 10 de HT et 50 de TVA). Le total était juste, seule la déclaration de TVA le montrait. La page de diagnostics liste ces lignes et corrige celles des brouillons.

Vérifications :

• Une ligne inversée est listée ; une ligne correcte, à taux zéro, ou dont le total ne tombe pas juste ne l'est pas.
• Une ligne d'une note de frais validée est listée avec son statut, et sa correction est refusée.
• La correction d'une ligne brouillon échange les deux montants et met à jour le total de la note de frais.
• La correction d'une ligne qui n'est pas inversée est refusée.
• Seules les lignes de l'entité courante sont listées.

Couverture automatique : test/phpunit/integration-dolibarr/InvertedVatLinesTest.php (10 méthodes, suite integration).

Objectif : un ticket portant un montant de TVA à un taux nul provoquait une division par zéro, qui arrêtait l'import de toute la note de frais.

Vérifications :

• Un montant à taux nul ou négatif est écarté, les taux utilisables voisins sont conservés.
• Le calcul de TVA survit à un taux nul en entrée, et fonctionne toujours sur une entrée propre.

Couverture automatique : test/phpunit/unit/ZeroVatRateTest.php (5 méthodes, suite unit).