fix(15-6b): un règlement ne vise pas le compte qu'il solde — garde serveur, lots, rapprochement, écrans (refs #474)

CHANGELOG.md

@@ -36,6 +36,8 @@ Le contenu est rédigé en français à destination des **fiduciaires, PME, ind
 
 - **La configuration d'une installation de production s'inscrit au journal d'audit ([#434](https://github.com/guycorbaz/kesh/issues/434)).** Chaque étape de l'assistant — langue, mode d'utilisation, passage en production, type d'organisation, langue comptable, coordonnées, compte bancaire (ou son omission) et finalisation — laisse une entrée *Étape d'installation franchie*, précédée de ce qu'elle a réellement changé : la société créée ou modifiée, le compte bancaire (sans jamais l'IBAN en clair), les réglages de facturation et les taux de TVA effectivement insérés. Le plan comptable livré s'inscrit en **une seule** entrée, *Plan comptable chargé*, qui liste les comptes créés. Quatre actions nouvelles sont libellées dans les quatre langues. Une étape ne laisse plus la société modifiée à moitié : la modification, la progression de l'étape et leur trace sont désormais **une seule transaction**, et l'étape est revérifiée sous verrou — deux demandes simultanées ne chargent plus le plan comptable deux fois. *Le perdant d'une telle course reçoit désormais « étape déjà franchie » au lieu d'un conflit de version.* *La version de la société (`version`, lue par le verrou optimiste de `PUT /company`) n'avance plus lorsqu'une étape ne change rien ; sur une société provisoire dont les coordonnées changent, elle avance désormais de deux.* Le peuplement de démonstration et la remise à zéro restent à tracer (même issue).
 
+- **Un règlement ne peut plus viser le compte qu'il solde ([#474](https://github.com/guycorbaz/kesh/issues/474)).** Régler une facture client par le compte débiteurs lui-même — en compte interne, ou par un compte bancaire lié à ce compte — écrivait `D 1100 / C 1100` : l'écriture s'équilibrait, le reste dû baissait, la facture pouvait passer « payée », et le grand livre ne bougeait pas. Il en allait de même d'une facture fournisseur réglée par le compte créanciers (`D 2000 / C 2000`), y compris par un lot de paiement, et d'un encaissement par rapprochement quand le compte bancaire était lié au compte débiteurs. Ces règlements sont désormais **refusés sans rien écrire** (`SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`), avec un message qui dit le remède. Les écrans de règlement ne proposent plus ces comptes, ni les comptes bancaires qui y sont liés. Une facture dont le compte créanciers est le compte de banque du lot n'entre plus dans un lot de paiement (elle apparaît parmi les refus, et le fichier pain.001 ne la porte pas) ; si le compte bancaire a été relié depuis la création du lot, la confirmation est refusée et le message dit les deux issues — relier de nouveau le compte bancaire puis confirmer, ou annuler le lot. Les comptes d'écart du même geste sont gardés de même : le compte de différences d'arrondi d'un règlement ou d'un rapprochement, et les comptes de nature, de reste d'arrondi et de TVA due d'un solde du reste ne peuvent pas être le compte débiteurs de la facture (cas d'un compte débiteurs changé de type, puis désigné dans les réglages) — un administrateur doit alors en désigner un autre dans *Paramètres → Facturation*. Les règlements de cette forme déjà enregistrés restent tels quels.
+
 - **Un compte non imputable est refusé partout où un client le désigne pour recevoir des écritures ([#427](https://github.com/guycorbaz/kesh/issues/427), [#429](https://github.com/guycorbaz/kesh/issues/429)).** Les écrans filtraient ces comptes, mais le serveur ne les contrôlait pas : un appel direct — par clé d'API ou par une intégration — pouvait rapprocher une transaction bancaire sur **9000 Bilan d'ouverture**, et fausser le résultat de l'exercice et le report à nouveau. Sont désormais refusés en `400 ACCOUNT_NOT_POSTABLE`, qui nomme le compte : le **rapprochement** manuel et ventilé, l'acceptation d'une proposition ventilée ou par règle (dans `failed[]`, sans bloquer le reste du lot) ; les **règles d'affectation** — création, changement de compte, et **réactivation** d'une règle dont le compte n'est plus imputable ; le **compte comptable d'un compte bancaire**, à la création, ou quand on le change. Une règle dont le compte est devenu non imputable — par exemple scindé en sous-comptes — **n'est plus proposée** ; la règle suivante qui correspond l'est à sa place. Les **réglages de facturation** refusent un compte non imputable **au moment où on le désigne** (créance, produit, TVA due, TVA récupérable, décompte TVA, créanciers), avec un message qui nomme le champ. ⚠️ **Limites** : un compte déjà désigné ou déjà lié, devenu non imputable après coup, reste accepté — on peut enregistrer les réglages, modifier le compte bancaire ou renommer la règle sans le changer. La validation d'une facture et la saisie (ou la complétion) d'une facture fournisseur refusent désormais un compte de réglage devenu non imputable (entrée ci-dessous) ; **restent** hors de cette garde l'avoir, le compte de produit par défaut et le compte comptable d'un compte bancaire déjà lié. L'écran des règles affichait « [object Object] » au lieu du message d'un refus : il affiche le message. Sur l'écran des comptes bancaires, un compte lié devenu non imputable s'affichait vide dans les formulaires de modification et de lien : il reste affiché.
 
 - **Un compte de réglage devenu non imputable n'est plus utilisé par les écritures automatiques ([#429](https://github.com/guycorbaz/kesh/issues/429)).** La créance et la TVA due, désignées dans *Paramètres → Facturation*, recevaient l'écriture de chaque facture validée même devenues non imputables — après la création de sous-comptes, la case *imputable* décochée ou le rôle « résultat de l'exercice » attribué —, comme les créanciers et la TVA récupérable pour chaque facture fournisseur. La **validation d'une facture** et la **saisie (ou la complétion) d'une facture fournisseur** les contrôlent désormais au moment d'écrire, et refusent avec un message qui nomme le compte, renvoie à *Paramètres → Facturation* et dit qu'un **administrateur** doit y désigner un compte imputable — la page des réglages lui est réservée. La TVA due (ou récupérable) n'est contrôlée que si la pièce en porte. L'**avoir** n'est pas soumis à ce contrôle, délibérément — une facture émise reste annulable : il crédite la créance que la facture a débitée (entrée ci-dessous, [#473](https://github.com/guycorbaz/kesh/issues/473)), et relit encore la TVA due dans les réglages du moment, ce que corrigera [#525](https://github.com/guycorbaz/kesh/issues/525). ⚠️ **Après la mise à jour, vérifiez dans *Paramètres → Facturation* que les comptes désignés sont imputables** : un compte devenu non imputable (sous-comptes créés, case *imputable* décochée…) doit y être remplacé, faute de quoi la validation des factures (ou la saisie des factures fournisseurs) est refusée. *(API : `400 ACCOUNT_NOT_POSTABLE`, `details.rejected[{accountId, accountNumber}]`, sur `POST /invoices/{id}/validate`, `POST /supplier-invoices` et `POST /imported-supplier-invoices/{id}/complete` — après tous les autres refus, exercice compris.)*

README.md

@@ -34,7 +34,7 @@
 - **Coordonnées de l'émetteur sur la facture** — téléphone, e-mail et site web figurent sous votre adresse sur le PDF, saisis une fois dans les réglages ; chaque champ est facultatif et n'occupe aucune place s'il est vide ✓
 - **Carnet de contacts structuré** — contacts **Personne** (prénom + nom) ou **Entreprise** (raison sociale), **adresse structurée** (QR-facture), et **personnes de contact** rattachées à une entreprise (interlocuteurs, à titre informatif) ✓
 - **Prévention des doublons à la saisie** — pendant que vous tapez le nom d'un nouveau contact, Kesh signale ceux qui lui ressemblent déjà (casse, accents, traits d'union et espaces indifférents), et avertit si l'**IDE** saisi appartient à une fiche existante — y compris **archivée**, cas où l'enregistrement serait refusé sans que la fiche soit visible dans le carnet. Kesh **signale, il ne bloque jamais** : deux clients peuvent légitimement porter des noms très proches ✓
-- **Règlements clients** — enregistrement d'un règlement depuis la fiche (virement, espèces ou tout autre compte), partiel ou total, avec son écriture ; liste des règlements de la facture et **annulation par contre-passation** ✓
+- **Règlements clients** — enregistrement d'un règlement depuis la fiche (virement, espèces ou un autre compte de contrepartie — jamais le compte débiteurs de la facture), partiel ou total, avec son écriture ; liste des règlements de la facture et **annulation par contre-passation** ✓
 - **Avoirs (notes de crédit)** — annulation d'une facture validée par création d'un avoir lié (séquence séparée `AV-…`), contre-passation comptable automatique (TVA comprise), PDF « Avoir » ✓
 - **Envoi de factures par e-mail** — bouton sur la facture validée : QR-facture PDF jointe, objet/message pré-remplis dans la **langue du contact** avec civilité personnalisée (modèles multilingues FR/DE/IT/EN configurables par l'admin), destinataire verrouillé sur la fiche contact, Reply-To = e-mail de la société, traçage « Envoyée le … à … » et renvoi possible ✓
 - **Import bancaire CAMT.053 + CSV multi-encodage** — parser + persistance + UI ✓, profils banque réutilisables ✓, réconciliation automatique avec score ✓, réconciliation manuelle ✓, éclatement de transaction agrégée ✓, règles d'affectation automatique ✓ et **annulation d'un rapprochement** par contre-passation ✓