# Module Bons de Sortie de Caisse — ICAVI Gestion Le module est intégré à l'ERP Laravel existant. Il utilise le schéma de la base actuelle et ajoute uniquement ses propres tables via des migrations. ## Règles métier intégrées - Un employé crée uniquement un bon à son propre nom. Le bénéficiaire n'est jamais choisi depuis le formulaire côté serveur. - Seul le bénéficiaire peut modifier ou annuler son bon, et uniquement avant le premier règlement (`En attente`). Raymond ne peut pas annuler un bon. - Raymond est le seul utilisateur autorisé à enregistrer les remises de caisse et à signer. Le signataire est configurable par `CASH_VOUCHER_SIGNER_USER_ID` et vaut `4` par défaut pour la base actuelle. - Chaque remise est conservée dans un historique immuable avec montant remis, montant retourné immédiatement, montant réellement imputé au bon, nouvelle restitution éventuelle et restitution reçue ultérieurement. - Un motif est obligatoire dès que le montant demandé reste totalement ou partiellement impayé. - Un paiement supérieur au montant demandé crée une restitution à recevoir du bénéficiaire. Le bon ne peut pas être signé tant que cette restitution n'est pas soldée. - Exemple : demande de 2 000 XAF, remise de 5 000 XAF, retour immédiat de 0 XAF => bon en `Restitution à recevoir` avec 3 000 XAF dus au boss. Lorsque les 3 000 XAF sont rendus plus tard, on enregistre cette restitution puis le bon peut être signé. - Le bouton de signature signifie une attestation interne de la remise physique : Raymond confirme qu'il a remis la somme nécessaire et, le cas échéant, reçu la restitution. - Après signature, le bon devient financierement immuable, est archivé dans la GED sous le dossier de l'employé, et son PDF est généré avec la signature et le cachet existants du site. - La zone `Réservé à la comptabilité` du formulaire imprimé reste strictement vide et non éditable. ## Format imprimé Le rendu A4 reprend la structure du bon papier fourni : logo ICAVI SECURE, date, montant, numéro du bon, montant en lettres, motif, bénéficiaire, tableau comptable, zone réservée à la comptabilité et blocs Direction / Caisse / Bénéficiaire. La signature et le cachet réutilisent exactement les assets déjà présents dans le projet : - `public/assets/images/Signature de Mr Raymond T..png` - `public/assets/images/Cachet ICAVI SECURE.png` Ils apparaissent dans l'impression uniquement après la signature effective du bon afin de ne jamais pré-signer un document en attente. ## Base de données actuelle Utiliser le dump SQL fourni avec la livraison comme source de vérité. Importer cette base **avant** d'exécuter les nouvelles migrations du module. Les migrations du module sont : - `2026_09_14_000001_create_cash_vouchers_tables.php` - `2026_09_14_000002_create_notifications_table.php` - `2026_09_14_000003_upgrade_cash_voucher_restitution.php` Le module ne remplace pas les migrations existantes et ne modifie pas les anciennes tables métier. ## Installation locale Windows Depuis le dossier du projet : ```bat composer install copy .env.example .env php artisan key:generate ``` Dans `.env`, renseigner votre connexion MySQL locale vers la base importée. La base du SQL fourni s'appelle `icaviss3`. Puis : ```bat php artisan migrate php artisan storage:link php artisan optimize:clear php artisan serve ``` Ouvrir ensuite : `http://127.0.0.1:8000/bons-sortie-caisse` Aucune installation NPM n'est nécessaire pour ce projet actuel : le front existant utilise ses assets CSS/JS statiques. ## Archivage PDF automatique Le PDF signé est généré par Chrome/Chromium en mode headless puis envoyé dans la GED existante. Chrome/Chromium doit donc être installé sur le poste qui exécute Laravel. Le module détecte automatiquement les chemins Windows courants. Pour forcer un chemin précis : ```env CASH_VOUCHER_CHROME_PATH=C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe ``` En cas d'absence de Chrome/Chromium, le paiement et la signature restent enregistrés ; le bon n'est pas annulé. L'application affiche une alerte pour permettre de finaliser l'archivage après installation/configuration du navigateur. ## Parcours fonctionnel **Employé** → Nouveau bon → En attente → Raymond reçoit la notification → Remise physique → Raymond saisit la remise réelle → règlement total, partiel, non payé ou avec restitution → confirmation/signature uniquement lorsque le rapprochement est correct → PDF signé → GED / dossier de l'employé. **Employé après création :** modification/annulation uniquement tant qu'aucun règlement n'a commencé. **Commercial / administrateur :** consultation globale, recherche, filtre par employé, mois et année, suivi des bons payés et totaux par employé. ## Vérifications réalisées dans la livraison - Syntaxe PHP contrôlée sur le code PHP du projet. - Routes `cash-vouchers.*` présentes et résolues. - La logique de remboursement partiel et de restitution ultérieure est stockée dans une table séparée d'événements de paiement. - Les archives GED des bons signés sont protégées contre modification, mise à la corbeille, restauration ou suppression définitive via les actions GED standards. > Remarque : la commande `php artisan view:cache` sur l'environnement de build fourni peut nécessiter l'extension PHP DOM/XML. Ce point vient de l'environnement PHP de validation et non du module Bons de Sortie de Caisse ; l'environnement local PHP utilisé par l'ERP doit avoir les extensions PHP habituelles de Laravel activées. ## Corrections de livraison - Les montants sont saisis en francs CFA entiers afin d’éviter toute différence entre la valeur enregistrée et la valeur imprimée. - La vue d’impression ne lance plus `window.print()` au chargement. Cela évite d’interférer avec la génération PDF headless ; le bouton **Imprimer** reste disponible en impression manuelle. - Le formulaire imprimé reste sur la structure du modèle papier fourni. Le suivi détaillé du règlement (reste à payer, restitution, motifs, historique) reste dans l’interface de gestion. - La signature et le cachet existants du site n’apparaissent sur le bon qu’après la signature effective de Raymond. > **Note de merge 2026-09 :** le schéma de restitution est conservé, mais la validation métier finale du workflow doit être testée sur une base et des données réelles avant d'affirmer qu'une restitution partielle couvre tous les cas opérationnels.