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
4 changes: 2 additions & 2 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ Le contenu est rédigé en français à destination des **fiduciaires, PME, ind

- **Une ligne vide de `.env` vaut une ligne absente, pour toutes les variables ([#550](https://github.com/guycorbaz/kesh/issues/550)).** Kesh lit désormais toute sa configuration par une seule fonction : une variable vide ou faite d'espaces prend son défaut (ou, si elle est obligatoire, fait refuser le démarrage comme si elle manquait), sauf `KESH_LOG_FILE_PATH` sous Docker, dont le vide désactive toujours le journal fichier alors que son absence laisse le compose poser son défaut (hors Docker, vide et absente le désactivent toutes deux). Les valeurs sont débarrassées de leurs espaces de tête et de fin : `KESH_COOKIE_SECURE=" true "`, refusé jusqu'ici, est accepté ; `KESH_PORT=" 8080"` est lu au lieu de retomber sur 80. ⚠️ **`KESH_JWT_SECRET`** : un espace de tête ou de fin cesse de faire partie du secret — un secret de 32 octets dont un bord est un espace fait désormais **refuser le démarrage** (trop court), et un secret ainsi modifié **déconnecte** les utilisateurs (les jetons émis ne sont plus valides). **Hors Docker seulement** : `RUST_LOG=""` ne laissait passer que les erreurs et vaut désormais `info` ; `KESH_HOST=""` faisait échouer le démarrage et vaut désormais `127.0.0.1` — sous Docker, ces deux cas n'existaient pas, les compose fournis remplaçant déjà le vide (`${RUST_LOG:-info}`, `${KESH_HOST:-0.0.0.0}` ou le littéral `0.0.0.0`).

- **Une écriture se modifie tant que son exercice est ouvert ([#532](https://github.com/guycorbaz/kesh/issues/532)).** Depuis la v0.12.0, toute écriture était figée dès son enregistrement : une inversion de débit et de crédit — sur les soldes de départ, par exemple — ne se corrigeait que par trois écritures (l'erreur, son inverse, la bonne), et les comptes touchés cessaient d'être complétables. La fiche d'une écriture offre désormais **Modifier** : date, journal, libellé et lignes se corrigent là où ils sont, **tant que l'exercice de l'écriture est ouvert, qu'aucun exercice postérieur n'est clôturé** (le bilan, cumulatif, la reprend — garde posée sur la modification et la suppression : la saisie, la contre-passation, les règlements, la dévalidation et le complément des soldes de départ ne la portent pas encore, [#543](https://github.com/guycorbaz/kesh/issues/543)), **et que sa date n'est pas dans la période verrouillée** — l'ancienne comme la nouvelle. Le numéro ne change jamais, la date reste dans l'exercice de l'écriture. **Chaque modification est tracée** au journal d'audit, avec l'état avant et après, lignes comprises, et l'auteur — utilisateur ou clé d'API. **Ce qui reste figé, et se corrige comme avant** : l'écriture d'une pièce (facture, avoir, facture fournisseur, règlement ou solde, rapprochement bancaire — depuis sa pièce), une écriture contre-passée ou une contre-passation, le **paiement d'une facture fournisseur annulée** (une sortie de banque réelle, qui se contre-passe), et toute écriture d'un exercice clos ou d'une période verrouillée (par contre-passation). Les mêmes contrôles qu'à la saisie s'appliquent, **à toutes les lignes, y compris celles qu'on ne touche pas** : un compte archivé ou devenu non imputable doit être remplacé. L'écriture d'ouverture et les compléments de soldes de départ se modifient comme les autres ; retirer la ligne d'un compte le rend de nouveau complétable. ⚠️ **Changement de contrat pour une intégration par clé d'API** : `PUT /api/v1/journal-entries/{id}` ne rend plus jamais `409 ENTRY_IS_POSTED` ; il prend un corps `{ entryDate, journal, description, lines, version }` et rend `200`, ou un refus nommé — `FISCAL_YEAR_CLOSED`, **`LATER_FISCAL_YEAR_CLOSED`** (nouveau, `400`), `ENTRY_IS_REVERSED`, `IS_A_REVERSAL`, le code de la pièce, **`DETACHED_SUPPLIER_SETTLEMENT`** (nouveau, `409`), `OPTIMISTIC_LOCK_CONFLICT`, `DATE_OUTSIDE_FISCAL_YEAR`, `INACTIVE_OR_INVALID_ACCOUNTS`, `ACCOUNT_NOT_POSTABLE` (comme la saisie), `PERIOD_LOCKED`. `GET /journal-entries/{id}` porte `modifiable`, `modificationBlockedBy` et `modificationBlockedLabel`. Détail : `docs/api-external.md`, « Modifier une écriture ».
- **Une écriture se modifie tant que son exercice est ouvert ([#532](https://github.com/guycorbaz/kesh/issues/532)).** Depuis la v0.12.0, toute écriture était figée dès son enregistrement : une inversion de débit et de crédit — sur les soldes de départ, par exemple — ne se corrigeait que par trois écritures (l'erreur, son inverse, la bonne), et les comptes touchés cessaient d'être complétables. La fiche d'une écriture offre désormais **Modifier** : date, journal, libellé et lignes se corrigent là où ils sont, **tant que l'exercice de l'écriture est ouvert, qu'aucun exercice postérieur n'est clôturé** (le bilan, cumulatif, la reprend — et, depuis cette version, plus aucune écriture ne s'enregistre dans un tel exercice, ci-dessous, [#543](https://github.com/guycorbaz/kesh/issues/543)), **et que sa date n'est pas dans la période verrouillée** — l'ancienne comme la nouvelle. Le numéro ne change jamais, la date reste dans l'exercice de l'écriture. **Chaque modification est tracée** au journal d'audit, avec l'état avant et après, lignes comprises, et l'auteur — utilisateur ou clé d'API. **Ce qui reste figé, et se corrige comme avant** : l'écriture d'une pièce (facture, avoir, facture fournisseur, règlement ou solde, rapprochement bancaire — depuis sa pièce), une écriture contre-passée ou une contre-passation, le **paiement d'une facture fournisseur annulée** (une sortie de banque réelle, qui se contre-passe), et toute écriture d'un exercice clos ou d'une période verrouillée (par contre-passation). Les mêmes contrôles qu'à la saisie s'appliquent, **à toutes les lignes, y compris celles qu'on ne touche pas** : un compte archivé ou devenu non imputable doit être remplacé. L'écriture d'ouverture et les compléments de soldes de départ se modifient comme les autres ; retirer la ligne d'un compte le rend de nouveau complétable. ⚠️ **Changement de contrat pour une intégration par clé d'API** : `PUT /api/v1/journal-entries/{id}` ne rend plus jamais `409 ENTRY_IS_POSTED` ; il prend un corps `{ entryDate, journal, description, lines, version }` et rend `200`, ou un refus nommé — `FISCAL_YEAR_CLOSED`, **`LATER_FISCAL_YEAR_CLOSED`** (nouveau, `400`), `ENTRY_IS_REVERSED`, `IS_A_REVERSAL`, le code de la pièce, **`DETACHED_SUPPLIER_SETTLEMENT`** (nouveau, `409`), `OPTIMISTIC_LOCK_CONFLICT`, `DATE_OUTSIDE_FISCAL_YEAR`, `INACTIVE_OR_INVALID_ACCOUNTS`, `ACCOUNT_NOT_POSTABLE` (comme la saisie), `PERIOD_LOCKED`. `GET /journal-entries/{id}` porte `modifiable`, `modificationBlockedBy` et `modificationBlockedLabel`. Détail : `docs/api-external.md`, « Modifier une écriture ».

- **Une écriture se supprime dans le même cadre ([#532](https://github.com/guycorbaz/kesh/issues/532)).** La fiche offre **Supprimer** à côté de **Modifier**, aux mêmes conditions — exercice ouvert, aucun exercice postérieur clôturé, aucune pièce, ni contre-passée ni contre-passation, pas le paiement d'une facture fournisseur annulée, date hors de la période verrouillée — : une écriture saisie par erreur disparaît sans écriture inverse. Une confirmation le rappelle : **le numéro n'est jamais réattribué** — la suppression laisse un trou dans la numérotation —, et **la suppression est inscrite au journal d'audit** avec le contenu complet de l'écriture et son auteur, utilisateur ou clé d'API. L'écriture d'ouverture se supprime aussi : seule écriture de la société, sa suppression rouvre la génération des soldes de départ (la nouvelle ouverture reçoit le numéro suivant, pas le 1) ; parmi d'autres écritures, ses comptes sans autre mouvement redeviennent complétables. La fiche dit désormais qu'une écriture a été **modifiée**, et son lien **Historique** ouvre le journal d'audit filtré sur elle (rôles Administrateur et Comptable). ⚠️ **Changement de contrat pour une intégration par clé d'API** : `DELETE /api/v1/journal-entries/{id}` rend `204`, ou les refus nommés du `PUT` (sans ceux du corps) ; le code **`ENTRY_IS_POSTED` est retiré** — plus aucune route ne le rend. Détail : `docs/api-external.md`, « Supprimer une écriture ».

Expand All @@ -32,7 +32,7 @@ Le contenu est rédigé en français à destination des **fiduciaires, PME, ind

### Corrigé

- **Les exercices se clôturent dans l'ordre : un bilan clos ne change plus en silence ([#543](https://github.com/guycorbaz/kesh/issues/543)).** Le bilan est cumulatif depuis l'origine : toute écriture d'un exercice figure dans le bilan des suivants. Or on pouvait clôturer un exercice en laissant ouvert un exercice antérieur — ou créer un exercice antérieur à un exercice clôturé —, puis écrire dans cet exercice ouvert : le bilan clos changeait sans que rien ne le signale. **La clôture est désormais refusée tant qu'un exercice antérieur est ouvert** : à l'écran, le bouton **Clôturer** est désactivé et son infobulle nomme l'exercice à clôturer d'abord. **La création d'un exercice est refusée** si un exercice postérieur est déjà clôturé. Avec la réouverture, qui allait déjà du plus récent vers l'ancien, aucun exercice ouvert ne peut plus précéder un exercice clôturé **à partir d'une installation saine**. Le refus de modifier ou de supprimer une écriture sous un exercice postérieur clos dit maintenant comment s'en sortir — rouvrir les exercices clôturés **en commençant par le plus récent**, et non celui qu'il nomme, que la réouverture refuserait. ⚠️ Une installation mise à jour ou une sauvegarde restaurée peut porter cet état, hérité d'une version antérieure : il se résorbe en clôturant le plus ancien exercice ouvert.
- **Les exercices se clôturent dans l'ordre : un bilan clos ne change plus en silence ([#543](https://github.com/guycorbaz/kesh/issues/543)).** Le bilan est cumulatif depuis l'origine : toute écriture d'un exercice figure dans le bilan des suivants. Or on pouvait clôturer un exercice en laissant ouvert un exercice antérieur — ou créer un exercice antérieur à un exercice clôturé —, puis écrire dans cet exercice ouvert : le bilan clos changeait sans que rien ne le signale. **La clôture est désormais refusée tant qu'un exercice antérieur est ouvert** : à l'écran, le bouton **Clôturer** est désactivé et son infobulle nomme l'exercice à clôturer d'abord. **La création d'un exercice est refusée** si un exercice postérieur est déjà clôturé. Avec la réouverture, qui allait déjà du plus récent vers l'ancien, aucun exercice ouvert ne peut plus précéder un exercice clôturé **à partir d'une installation saine**. Le refus de modifier ou de supprimer une écriture sous un exercice postérieur clos dit maintenant comment s'en sortir — rouvrir les exercices clôturés **en commençant par le plus récent**, et non celui qu'il nomme, que la réouverture refuserait. ⚠️ Une installation mise à jour ou une sauvegarde restaurée peut porter cet état, hérité d'une version antérieure. **Plus rien ne s'enregistre alors dans l'exercice ouvert concerné** : ni saisie, ni validation, règlement, solde ou dévalidation d'une facture, ni avoir, facture fournisseur, paiement, lot de paiement, soldes de départ ou rapprochement — chacun de ces gestes changerait le bilan clos ; le refus nomme l'exercice clôturé. Une contre-passation — et donc toute annulation, qui en porte une — est datée **du jour** : elle reste possible, et n'est refusée que si l'exercice du jour est lui-même suivi d'un exercice clôturé. **L'écran *Exercices comptables* signale l'état** par un bandeau, visible de tous les rôles, qui dit comment rétablir l'ordre : clôturer l'exercice ouvert le plus ancien si ses comptes sont arrêtés, puis les suivants ; sinon, faire rouvrir les exercices clôturés **en commençant par le plus récent**. L'import accepte toujours une telle sauvegarde. ⚠️ **Limites** : l'écran des soldes de départ et les annulations de règlement ou de rapprochement annoncent le geste possible et le refus ne vient qu'au clic ([#568](https://github.com/guycorbaz/kesh/issues/568)). *(API : `400 LATER_FISCAL_YEAR_CLOSED` sur toute route qui écrit au journal, `details.fiscalYearId` / `fiscalYearName` ; dans `failed[]` de `POST /reconciliation/accept`, sans bloquer le reste du lot. Le message de ce refus couvre désormais la saisie.)*

- **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).

Expand Down
Loading
Loading