Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,20 +24,24 @@ Le contenu est rédigé en français à destination des **fiduciaires, PME, ind

- **Un compte non imputable est refusé sous son vrai nom ([#429](https://github.com/guycorbaz/kesh/issues/429), [#427](https://github.com/guycorbaz/kesh/issues/427)).** Saisir une écriture sur un compte de regroupement, sur le compte de résultat de l'exercice ou sur un compte de clôture était refusé avec le message « Un ou plusieurs comptes sont archivés ou invalides » — faux pour ce motif : on cherchait un compte archivé qui ne l'était pas. Le refus le dit désormais, et **nomme le ou les comptes** : « Le compte 9000 n’est pas imputable (compte de regroupement, de résultat ou de clôture) : choisissez un compte imputable. » Sont concernés la saisie manuelle d'une écriture, l'écriture d'ouverture (soldes de départ), le règlement d'une facture client sur un compte interne, la saisie et la complétion d'une facture fournisseur importée (compte de charge), et le règlement d'une facture fournisseur sur un compte interne. Un compte inconnu, archivé ou d'une autre société garde l'ancien refus. ⚠️ **Changement visible d'une intégration par clé d'API** : ces routes répondent désormais `400 ACCOUNT_NOT_POSTABLE`, avec `details.rejected[{accountId, accountNumber}]`, au lieu de `400 INACTIVE_OR_INVALID_ACCOUNTS`. Sur une facture fournisseur, une ligne de forme invalide (quantité, prix ou taux de TVA) est désormais signalée avant un défaut de compte d'une ligne précédente.

- **Un avoir refusé pour un compte archivé nomme le compte ([#473](https://github.com/guycorbaz/kesh/issues/473), [#523](https://github.com/guycorbaz/kesh/issues/523)).** Quand le compte débiteurs ou le compte d'arrondi que la facture a mouvementés, ou le compte de TVA due des réglages, a été archivé, l'avoir est refusé avec le message « Impossible d'émettre l'avoir — compte(s) archivé(s) : 1100. Réactivez le ou les comptes concernés. ». Il était refusé par « Un ou plusieurs comptes sont archivés ou invalides », sans nom, ou — pour l'arrondi — par un renvoi aux réglages qui ne réglait rien. Ce contrôle se fait **avant** celui de l'exercice. ⚠️ **Changement visible d'une intégration par clé d'API** (`POST /api/v1/credit-notes`) : ce refus est désormais `400 ACCOUNT_ARCHIVED`, avec `details.rejected[{accountId, accountNumber}]` — le code de la contre-passation —, au lieu de `400 INACTIVE_OR_INVALID_ACCOUNTS` ou de `ROUNDING_ACCOUNT_NOT_CONFIGURED` ; un compte de produit archivé garde `CREDIT_NOTE_REVENUE_ACCOUNT_ARCHIVED`, qui nomme la ligne — deux codes possibles, un même libellé « Impossible d'émettre l'avoir ». Un réglage débiteurs vide ne rend plus `CONFIGURATION_REQUIRED`.

- **Les opérations rejouées après un interblocage sont journalisées en avertissement.** Chaque opération rejouée est désormais journalisée par le serveur au niveau *avertissement*, avec le nom de l'opération (`operation`) et le numéro de la tentative ; un rejeu épuisé (interblocage encore à la dernière tentative) l'est au niveau *erreur*, avec le nom de l'opération et le nombre de tentatives.

### Corrigé

- **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 : il relit encore la créance et la TVA due dans les réglages du moment, ce que corrigeront [#473](https://github.com/guycorbaz/kesh/issues/473) et [#525](https://github.com/guycorbaz/kesh/issues/525) — une facture émise reste annulable. ⚠️ **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.)*
- **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.)*

- **Enregistrer les réglages de facturation n'efface plus le compte créanciers ([#521](https://github.com/guycorbaz/kesh/issues/521)).** L'écran *Paramètres → Facturation* n'envoyait pas ce compte (il l'affiche et l'envoie désormais, voir *Ajouté*), et chaque enregistrement le vidait : la saisie d'une facture fournisseur échouait ensuite en « configuration requise ». Absent du corps, il est désormais **préservé** ; à `null`, effacé. *(API : `defaultPayableAccountId` dans `PUT /company/invoice-settings`.)*

- **Les refus d'une acceptation par lot s'affichent en clair ([#492](https://github.com/guycorbaz/kesh/issues/492)).** Dans *Mensuel → Réconciliation*, une transaction refusée par *Accepter* ou *Rejeter* était listée sous *Échecs partiels* par un identifiant interne (« TX #42 ») et un code technique (`ROUNDING_ACCOUNT_NOT_CONFIGURED`, `PERIOD_LOCKED`…). Chaque refus est désormais désigné par la date, le montant et la contrepartie de la transaction, et son motif est rédigé dans la langue de l'installation — un compte non imputable y est nommé par son numéro. Le bilan du lot reste affiché même quand le lot a vidé la liste, ce qui le masquait jusqu'ici.

- **Le manuel décrit le rapprochement tel que l'écran le fait ([#481](https://github.com/guycorbaz/kesh/issues/481), [#519](https://github.com/guycorbaz/kesh/issues/519)).** Il annonçait un bouton *Modifier*, des boutons *Accepter* et *Rejeter* par ligne, une acceptation par lot « atomique », un rapprochement manuel et un éclatement qui régleraient des factures, et des règles d'affectation qui créeraient des écritures en brouillon dès l'import : rien de cela n'existe. Il dit maintenant ce que fait l'écran — une candidate par transaction, l'acceptation qui traite chaque ligne pour elle-même, l'affectation manuelle et l'éclatement vers des comptes de charges et de produits, en une écriture, des règles qui proposent sans jamais écrire —, et ce qu'il ne fait pas : une transaction rejetée ne se rapproche plus depuis l'interface ([#526](https://github.com/guycorbaz/kesh/issues/526)), une facture de score faible passe devant une règle ([#527](https://github.com/guycorbaz/kesh/issues/527)), et un paiement reçu plus de 30 jours après la date de la facture n'est pas proposé ; il se règle depuis la fiche de la facture ([#529](https://github.com/guycorbaz/kesh/issues/529)).

- **L'avoir crédite le compte débiteurs que la facture a débité, et contre-passe l'arrondi sur le compte qu'elle a mouvementé ([#473](https://github.com/guycorbaz/kesh/issues/473), [#523](https://github.com/guycorbaz/kesh/issues/523)).** L'avoir relisait le compte débiteurs et le compte de différences d'arrondi **dans les réglages du moment**. Si l'un d'eux avait été changé dans *Paramètres → Facturation* entre la validation de la facture et l'avoir, l'avoir créditait le nouveau compte : l'ancien gardait le débit de la facture, qui passait « annulée » et sortait de la balance âgée — la créance restait au grand livre sans plus apparaître nulle part ; de même, au centime, pour l'arrondi. Les deux comptes se lisent désormais **sur l'écriture de la facture**, comme le faisaient déjà le règlement, le solde du reste et l'encaissement par rapprochement : ils reviennent à zéro, comme le promet le manuel. Un réglage débiteurs ou d'arrondi vidé depuis n'empêche plus d'émettre l'avoir. **Limite connue** : la TVA de l'avoir est encore contre-passée sur le compte de TVA due désigné au moment de l'avoir ([#525](https://github.com/guycorbaz/kesh/issues/525)).

- **Une opération qui croise un rapprochement bancaire ne finit plus en erreur interne ([#463](https://github.com/guycorbaz/kesh/issues/463), [#491](https://github.com/guycorbaz/kesh/issues/491), [#536](https://github.com/guycorbaz/kesh/issues/536)).** Un règlement client, l'annulation d'un règlement client, la validation d'une facture, la saisie d'une facture fournisseur et l'enregistrement des réglages de facturation qui croisent une autre opération (un rapprochement bancaire, notamment) ne finissent plus en erreur interne : le serveur rejoue l'opération, comme il le faisait déjà pour l'acceptation d'un rapprochement. Il en va de même de toutes les opérations courantes qui écrivent au journal — hors la restauration d'une sauvegarde et l'effacement des données de démonstration. Seul un interblocage répété trois fois de suite rend encore une erreur ; rien n'est alors écrit et l'opération peut être relancée telle quelle.
- **Les manuels ne prétendent plus que la numérotation des factures se fait dans une transaction `SERIALIZABLE` ([#484](https://github.com/guycorbaz/kesh/issues/484)).** Ils décrivent le verrou du compteur, la contrainte d'unicité et le rejeu.

Expand Down
Loading
Loading