Rapprocher une écriture bancaire en un clic

1. Pourquoi cette page existe

Le même rapprochement, sans les sauts d'écran

L'outil historique (Banq_ReleveBq.php) impose de sélectionner un relevé, ouvrir une fenêtre de rapprochement, envoyer une sélection, revenir, valider l'import GL séparément... Pour une grosse écriture ça passe, mais pour rapprocher une dépense de quelques euros (un parking, un péage) contre son ticket, ce parcours coûte beaucoup plus de clics que la difficulté réelle du rapprochement. Cette page fait la même chose — le même tampon, les mêmes écritures comptables générées — mais sur un seul écran, avec un solde qui se recalcule en direct au fil des clics.

2. Les 3 pavés, comment lire l'écran

Le pavé gauche affiche un montant unique par écriture (au lieu de deux colonnes Débit/Crédit) : un débit — une dépense — s'affiche en rouge, pour repérer les sorties d'argent d'un coup d'œil. La colonne Libellé s'élargit automatiquement pour occuper toute la place disponible du pavé (une poignée permet de la réajuster manuellement si besoin).

3. Le flux pas à pas

1. Cliquer sur une écriture bancaire (pavé gauche) — elle se met en surbrillance, et le "Solde à rapprocher" (pavé bas droite) prend sa valeur de départ.
2. Filtrer le pavé du haut pour retrouver la ou les factures concernées (par annonceur, code facture, journal...).
3. Cliquer sur chaque facture à rapprocher — elle bascule du pavé du haut vers le pavé du bas, et son montant se défalque du solde à rapprocher. Recommencer jusqu'à ce que le solde affiche 0,00 € (il passe alors en vert).
4. Astuce — sous-total du pavé du haut : avant même de cliquer facture par facture, un sous-total des lignes actuellement filtrées s'affiche à côté du compteur. Il passe en vert dès que la somme des factures filtrées correspond exactement à ce qu'il reste à rapprocher — un bon filtre (ex. un code facture) suffit alors à confirmer visuellement le bon rapprochement avant de cliquer.
5. Cliquer "Clôturer l'écriture" (actif uniquement quand le solde est à zéro) — un clic suffit, aucune confirmation supplémentaire ne s'affiche.

4. Ce que fait le bouton "Clôturer"

Trois opérations comptables en un seul clic

Historiquement, rapprocher une écriture bancaire nécessitait de déposer les factures dans un tampon, PUIS d'aller valider séparément l'import des écritures GL. Ici, un seul clic sur "Clôturer" enchaîne :

1. Dépôt des factures sélectionnées dans le tampon de rapprochement.
2. Génération des écritures comptables de contrepartie (la ligne banque et les lignes de règlement) et passage de l'écriture bancaire à l'état "clôturée" — elle disparaît alors du pavé gauche.
3. Lettrage immédiat : la facture d'origine et son écriture de règlement se soldant à zéro sur le même compte, elles sont automatiquement marquées comme lettrées — pas besoin de repasser par la page Lettrage séparément.

4bis. Solder un écart (arrondi, trop perçu / trop versé)

Quand les factures sélectionnées ne suffisent pas à ramener le solde à zéro

Un lien « + Ajuster l'écart », sous la liste des factures sélectionnées, ouvre un petit pavé à 4 lignes (un compte à choisir + un montant chacune). Un bouton « Ajouter » unique transforme les lignes remplies en entrées dans le pavé de sélection, au même titre qu'une facture cliquée — même tableau, même calcul de solde, retirables en cliquant dessus. Le formulaire se vide ensuite : on peut ainsi cumuler autant de lignes d'ajustement que nécessaire (pas 4 au maximum — ex. deux clients différents sur la même écriture). Dès qu'un compte est choisi sur une ligne, le montant nécessaire pour ramener le solde courant à zéro est pré-rempli automatiquement (modifiable).

Les recherches "Compte de résultat" / "Compte de bilan" sont filtrées séparément (TPCG.TYPE_BILAN) — chacune ne propose que les comptes de sa catégorie. La ligne "Compte de résultat" propose en plus un axe analytique (par défaut "FRAIS GENERAUX") — absent sur "Compte de bilan", qui n'en a pas besoin. Les lignes "Compte client"/"Compte fournisseur" proposent quant à elles un centralisateur (par défaut 411000000 / 401000000 — modifiable s'il existe plusieurs centralisateurs pour le cas traité, ex. clients échange).

5. Ce que cette page ne fait pas (encore)

Pour les cas suivants, l'outil historique Banq_ReleveBq.php reste disponible et doit être utilisé :

6. Glossaire

Solde à rapprocher

La différence, mise à jour en direct, entre le montant de l'écriture bancaire et la somme des factures déjà sélectionnées. Doit atteindre 0,00 € pour pouvoir clôturer.

Tampon (RapproBancaire)

La zone d'attente où sont déposées les factures rapprochées d'une écriture bancaire, avant génération des écritures comptables définitives.

Lettrage

Le fait de marquer une facture et son règlement comme définitivement "réglés l'un par l'autre" — ils se soldent à zéro sur le même compte.

Écriture clôturée

Une écriture bancaire dont le rapprochement est terminé : elle disparaît du pavé gauche (elle n'apparaît que tant qu'elle est en attente).

1. Vue d'ensemble du flux

Même esprit que Analyse_CA.php / EtatFi_BalGene.php : volontairement sans C_DataGrid/phpGrid, tableaux HTML simples alimentés en JSON, rendus et filtrés en JavaScript pur — page légère, pas de grille lourde.

2. Les requêtes sources (ajax=data)

ajax/Banq_Rappro_Express_ajax.php (action data) charge en un seul aller-retour la liste des relevés, la liste des banques actives (filtre) et le pool de factures — pas de pagination, pas de requête par filtre (tout est déjà en mémoire côté client).

Relevés à rapprocher

Pool de factures disponibles

Exclusion complémentaire volontairement simple : NOT EXISTS RapproBancaire retire du pool toute facture déjà présente — même partiellement — dans le tampon d'un autre relevé (pas de calcul de solde restant, cf. §6 limites).

3. Calcul du solde et du sous-total (JS)

Tout le calcul se fait côté client, sans aller-retour serveur, à chaque clic :

currentReleve.ECART vient tel quel de la base (déjà maintenu par MySQL, cf. §4) : partir de cette valeur plutôt que de recalculer DEBIT - CREDIT gère automatiquement le cas — rare — d'un relevé déjà partiellement travaillé via l'ancien outil.

4. La clôture en un clic (closeReleve)

ajax=close (POST, idReleve + ids[]) délègue tout le traitement à \BanqRapproExpress\closeReleve() dans sql/Rappro_Express.php — l'endpoint AJAX ne fait que parser la requête et traduire le résultat en JSON.

Phase 1 — validation seule (aucune écriture en base)

1. Relit ETAT/ECART du relevé depuis la base — refuse si déjà clôturé (ETAT=1).
2. Relit les factures sélectionnées fraîches depuis la base (jamais les montants envoyés par le client) — exclut celles déjà lettrées ou déjà déposées dans le tampon par quelqu'un d'autre entretemps ; si le nombre de lignes trouvées ne correspond pas au nombre demandé, refuse.
3. Recalcule l'écart final (ECART actuel + somme des montants relus) et refuse si |écart| > 0.005.

Phase 2 — mutation (uniquement si la phase 1 est passée)

1. Dépôt tampon : INSERT INTO RapproBancaire ... SELECT ... FROM GL WHERE ID_GL IN (...) (même requête que Banq_RapproBanq.php v1, étendue à une liste d'ID_GL) + recalcul MONTANT_RAPPRO/ECART + renumérotation NUM_LIGNE (row_number émulé en SQL) + GL.PRELETTRAGE=1.
2. Écritures GL de contrepartie : reprise à l'identique du bloc SQL de ajax/rappro_actions.php (action import_gl) — dupliqué volontairement dans sql/Rappro_Express.php pour ne pas toucher au flux existant de Banq_ReleveBq.php. Supprime d'éventuelles écritures GL déjà générées pour ce relevé (journal banque, TTypeJournal=3, période non close), puis réinsère la ligne banque et les lignes de règlement (UNION), et passe ReleveBanque.ETAT=1.
3. Lettrage immédiat : reprise à l'identique du script etats_financiers/sql/lettrage.php. Regroupe tous les GL.PRELETTRAGE=1 de la base par (TYPE_TIERS, COMPTE) dans Lettrage_Tampon ; les comptes dont la somme tombe exactement à zéro sont marqués IS_LETTRAGE=1 (+ CODE_LETTRAGE, DATE_LETTRAGE) et repassent PRELETTRAGE=0 ; les autres restent en attente (PRELETTRAGE=1).

Aucune transaction SQL explicite (même convention que le reste de l'application — voir executeSqlQueries() dans functions.php, exécution séquentielle statement par statement). La phase 1 étant strictement en lecture, un refus à cette étape ne laisse jamais la base dans un état intermédiaire.

4bis. Lignes d'ajustement (validateAdjustments)

closeReleve($db, $idReleve, $ids, $adjustments) accepte un 4e paramètre optionnel — une liste (pas de limite fixe) de lignes complémentaires, accumulées côté page (bouton "Ajouter" du pavé d'ajustement) et envoyées en un seul champ POST adjustments encodé JSON (json_decode(..., true) côté ajax=close) — pas de slots nommés fixes.

validateAdjustments($db, $rawList)

Fonction pure de validation (aucune écriture), appelée en tout début de closeReleve(), avant même la lecture de ReleveBanque. Pour chaque ligne de la liste dont le montant est non nul (> 0,0001 en valeur absolue — une ligne à montant vide est simplement ignorée), relit la référence depuis la base — jamais les libellés envoyés par le client — et construit un item normalisé. Une ligne malformée (compte/client/fournisseur/centralisateur/axe introuvable, ou incohérence bilan/CdR) fait échouer toute la validation, sans insertion partielle.

La somme des montants validés (sum) s'ajoute à la somme des factures pour le calcul de l'écart final (§4, phase 1).

Insertion du tampon (phase 2)

Chaque item validé génère un INSERT INTO RapproBancaire (...) VALUES (...) direct (pas de SELECT ... FROM GL, il n'y a pas de facture source) — même modèle que rappro_actions.php action add_manual : ID_GL=0, CODE_FACTURE et NUMERO_PIECE laissés NULL, ID_STATUTRGLT=1, NUM_LIGNE=0 (renuméroté avec toutes les autres lignes du relevé par le même bloc SQL de renumérotation que les lignes facture). Ces INSERT sont concaténés avant le bloc de recalcul/renumérotation/génération GL.

Génération GL — CASE d'axe injecté

Juste avant d'assembler $sqlClose, closeReleve() construit une table $axe0Overrides[COMPTE] = ID_AXE0 à partir des seuls items compte_resultat de cette clôture, puis :

$axe0Sql remplace tel quel le CASE ... AS ID_AXE0 statique dans le SELECT de contrepartie (2e branche du UNION) — le reste du bloc de génération GL est identique, ligne pour ligne, à avant l'ajout du pavé d'ajustement. Sans aucun ajustement "compte de résultat" dans la clôture en cours, $axe0Sql vaut exactement la règle historique : zéro changement de comportement pour le cas courant.

5. Tables impliquées

6. Limites et points d'attention

7. Fichiers concernés