diff --git a/CHANGELOG.fr.md b/CHANGELOG.fr.md index d8d0170..223b06d 100644 --- a/CHANGELOG.fr.md +++ b/CHANGELOG.fr.md @@ -2,6 +2,18 @@ ## [Non publié] +### Ajouté + +- Bilan : la date d'un snapshot existant peut maintenant être déplacée. Le champ date devient modifiable en mode édition — changez-la puis enregistrez, et le snapshot (avec toutes ses lignes) est déplacé à la nouvelle date dans une seule transaction atomique. Si un autre snapshot occupe déjà la date cible, le déplacement est refusé avec un message clair et rien n'est modifié (#200). + +### Modifié + +- Bilan : terminologie clarifiée. Les regroupements de comptes (Liquidités, CELI, REER, etc.) sont désormais appelés **types** de façon cohérente dans l'interface du bilan et le guide utilisateur, pour éviter la confusion avec les *catégories* de transactions (un autre module). Le type « Encaisse » devient **Liquidités** et « Fonds commun » devient **Fonds / FNB**. Le terme *snapshot* est conservé mais glosé à son premier usage (#198). + +### Corrigé + +- Bilan : le symbole (ticker) est maintenant optionnel pour les comptes d'un type coté. Un compte coté peut être créé ou modifié sans symbole — la valorisation manuelle (quantité × prix unitaire) n'en a jamais eu besoin ; un symbole n'est requis que pour utiliser le bouton de récupération automatique des prix (#199). + ## [0.9.1] - 2026-05-10 ### Ajouté diff --git a/CHANGELOG.md b/CHANGELOG.md index 3cff686..afa96ff 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,18 @@ ## [Unreleased] +### Added + +- Balance: an existing snapshot's date can now be moved. The date field is editable in edit mode — change it and save, and the snapshot (with all its lines) is moved to the new date inside a single atomic transaction. If another snapshot already occupies the target date, the move is rejected with a clear message and nothing changes (#200). + +### Changed + +- Balance: clearer terminology. Account groupings (Cash, TFSA, RRSP, etc.) are now consistently called **types** across the balance UI and user guide, to avoid confusion with transaction *categories* (a separate module). The "Cash" type is now labelled **Cash** (FR: Liquidités) and "Mutual fund" becomes **Funds / ETF** (FR: Fonds / FNB). The wording of *snapshot* is unchanged but glossed on first use (#198). + +### Fixed + +- Balance: the symbol (ticker) is now optional for accounts in a priced type. A priced account can be created or edited without a symbol — manual valuation (quantity × unit price) never needed it; a symbol is only required to use the automatic price-fetch button (#199). + ## [0.9.1] - 2026-05-10 ### Added diff --git a/docs/audit-bilan-2026-05.md b/docs/audit-bilan-2026-05.md new file mode 100644 index 0000000..8298ca1 --- /dev/null +++ b/docs/audit-bilan-2026-05.md @@ -0,0 +1,112 @@ +# Audit critique — Page Bilan (suivi du patrimoine) + +> Date : 2026-05-31 +> Méthode : revue à deux experts (CPA / planificateur financier québécois + designer produit fintech patrimoniale), sur cartographie du code réel, suivie d'une synthèse priorisée. +> Calibrage : **les deux personas en progressif** — simple par défaut (grand public, valeurs agrégées), détail par titre en option (investisseur actif). +> Dimensions retenues : **modèle de données** + **UX de saisie & suivi**. Hors-périmètre : exactitude des calculs (Modified Dietz), complétude (dividendes, multi-devise, allocation cible) — mentionnés seulement quand ils sont un prérequis. + +## Verdict + +Le socle est propre et honnête **pour le grand public en mode agrégé** : invariants SQL rigoureux (CHECK `kind`, UNIQUE date, FK RESTRICT), onboarding 2-step, starter accounts, saisie « 1 compte = 1 montant », pré-remplissage. Mais le **« progressif » est cassé en son centre**, et les deux experts pointent **la même cause unique** : le modèle est *plat* — une seule « catégorie » encode à la fois le **véhicule fiscal** (CELI, REER) et la **classe d'actif** (actions, crypto, encaisse). Tant que ces deux axes orthogonaux partagent un champ, la montée en puissance vers le détail par titre est soit impossible, soit punitive (rupture d'historique). Le mode détaillé est par ailleurs **inutilisable aujourd'hui** : re-saisie manuelle de tous les prix à chaque snapshot, price-fetch encore bloqué côté serveur. + +La cible UX (modèle *enveloppe → positions*, façon Sharesight / Kubera) et le chemin CPA (migration **additive**, pas le big-bang de l'ADR 0012) sont **le même plan vu sous deux angles**. Il existe une trajectoire à faible risque. + +## Diagnostic racine : le modèle plat + +Exemple concret : un **CELI de courtage** contenant 30 actions AAPL + 5 000 $ d'encaisse. Aujourd'hui, deux choix, tous deux faux : + +- compte `simple` sous `tfsa` → le titre, sa quantité et son rendement disparaissent ; +- compte `priced` sous `stock` → l'abri CELI disparaît du modèle (« combien dans mon CELI ? » devient insoluble). + +Conséquences en cascade : agrégation par titre cross-véhicule impossible (« combien de VFV au total, tous comptes confondus ? »), empilé « par catégorie » qui mélange enveloppes et classes d'actif, et surtout **bascule agrégé → détaillé qui casse la courbe** (le `kind` simple/priced est figé sur la catégorie, pas sur le compte). + +> Même en implémentant l'ADR 0012 tel quel, le triplet `(véhicule, composition, valeur)` garde la *composition* au niveau **classe d'actif**, pas **titre**. On déplacerait le mur sans débloquer le détail par titre individuel — l'ADR 0012 résout le mauvais grain. + +## Findings — matrice sévérité × effort + +Effort : **S** = à modèle constant · **M** = additif (colonnes/tables) · **L** = migration structurante. ✓✓ = relevé par les deux experts. + +| # | Finding | Sévérité | Effort | Persona | Source | +|---|---|---|---|---|---| +| **A** | Modèle plat fusionne véhicule fiscal × classe d'actif (**la racine**) | Structurel | M→L | Les deux | ✓✓ | +| **B** | Bascule agrégé → détaillé casse l'historique (`kind` figé sur la catégorie) | Bloquant | M→L | Les deux | ✓✓ | +| **C** | Re-saisie manuelle de **tous** les prix chaque mois (Pré-remplir laisse le prix vide) | Majeur | M | Investisseur | UX | +| **D** | PRU / coût d'acquisition absent → impossible de distinguer apport vs gain latent | Majeur | M | Investisseur | CPA (+UX) | +| **E** | Symbole = texte libre, non normalisé → aucune agrégation par titre | Majeur | M | Investisseur | CPA | +| **F** | Tableau 5 colonnes de rendement : bruit anxiogène (grand public), incomplet (investisseur) | Majeur | M | Les deux | UX | +| **G** | Empilé « par catégorie » illisible (axe bâtard véhicule/actif) | Majeur | M | Les deux | UX | +| **H** | Onboarding muet sur agrégé vs détaillé ; pas de preset investisseur | Majeur | S | Les deux | UX | +| **I** | Édition de catégorie via `window.prompt()` **écrase `i18n_key` → casse le bilingue** | Mineur *(vrai bug)* | S | Les deux | UX | +| **J** | Terminologie : « catégorie » (collision avec les transactions), « snapshot » (jargon), « encaisse »/« fonds commun » | Mineur | S | Grand public | CPA | +| **K** | Symbole obligatoire pour `priced` (friction sans bénéfice tant que price-fetch bloqué) | Mineur | S | Investisseur | UX | +| **L** | Liaison de transferts 100 % manuelle, sans suggestion par montant/libellé | Mineur | M | Investisseur | UX | +| **M** | Date de snapshot immutable (corriger = supprimer + tout re-saisir) | Mineur | S | Les deux | UX | +| **N** | Devise portée par le compte alors qu'elle est une propriété du titre (dette future) | Mineur | S | Investisseur | CPA | + +**Incohérence de données à acter (bug latent)** : `updateBalanceAccount` autorise à repointer un compte `simple` → `priced` **sans toucher les lignes de snapshot historiques** ; on se retrouve avec des lignes scalaires sous un compte désormais `priced` (`src/services/balance.service.ts:340`, classement par `category_kind` au chargement `src/hooks/useSnapshotEditor.ts:289`). + +## Détail des findings structurels et majeurs + +### A — Le modèle plat fusionne véhicule fiscal et classe d'actif (racine) + +`balance_categories` encode au même niveau le véhicule (`tfsa`, `rrsp`) et la classe d'actif (`stock`, `crypto`, `cash`, `fund`). Cas réels québécois mal représentés : actions dans un CELI ; liquidités dans un compte de courtage ; même FNB (VFV) dans REER + non-enregistré (impossible d'agréger « combien de VFV au total ») ; **CELIAPP, REEE, CRI/FERR absents** des seeds. La séparation des deux axes est le prérequis de presque tout le reste. + +### B — La bascule agrégé → détaillé casse l'historique + +Le `kind` (`simple`/`priced`) est porté par la **catégorie**, pas par le compte, et `updateBalanceCategory` interdit d'en changer (`balance.service.ts:152`). Un utilisateur qui suit « CELI = 50 000 $ » puis veut détailler ses titres doit archiver l'ancien compte et en créer un nouveau → la série temporelle se scinde, la courbe rompt, le rendement « depuis création » repart de zéro. C'est le pire moment pour perdre l'historique (l'utilisateur monte justement en sophistication). + +### C — Re-saisie manuelle de tous les prix à chaque snapshot + +Sur `/balance/snapshot`, chaque ligne `priced` demande quantité × prix unitaire à la main (`SnapshotLineRow.tsx:104-165`). Le price-fetch est premium **et** encore bloqué serveur → 100 % manuel. Pire : « Pré-remplir » copie la quantité mais **laisse le prix vide** par design (`useSnapshotEditor.ts:397-405`). Pour 10 titres, c'est 10 prix à retrouver et re-saisir chaque mois — point de bascule où l'investisseur abandonne. Levier le plus aligné privacy-first/desktop : **import CSV de cours local** (pattern Portfolio Performance), indépendant du premium ; et autoriser la saisie de la valeur directe en mode `priced` (pattern Portfolio Performance : cours OU valeur). + +### D — Coût d'acquisition (PBR / PRU) absent du modèle + +`balance_snapshot_lines` ne porte que `quantity`, `unit_price` (prix de marché) et `value`. Aucun coût d'acquisition. Au niveau du modèle, on ne peut donc pas distinguer **apport vs gain latent** pour une position — exactement ce qu'un investisseur attend du détail par titre (« j'ai mis 8 000 $, ça vaut 11 000 $, +3 000 $ latent »). Pertinence fiscale québécoise forte (PBR = base du gain en capital imposable en non-enregistré). Recommandation (angle modèle uniquement) : champ `book_cost` (ou `avg_cost_per_unit`) saisissable sur la position-titre, pré-rempli depuis le snapshot précédent. Sans lui, le détail par titre n'apporte rien de plus que l'agrégat. + +### E — Le symbole de titre n'est pas une entité normalisée + +`symbol` est un `TEXT` nullable sur `balance_accounts`, sans table de référence ni unicité. `getSnapshotTotalsByCategoryAndDate` groupe uniquement par `category.key` (`balance.service.ts:1145-1174`) — le symbole n'entre dans aucune agrégation. `AAPL`, `aapl`, `AAPL.US` sont trois titres distincts. Un compte = un seul symbole → 15 titres = 15 « comptes ». Recommandation : table `balance_securities` (`symbol` normalisé UNIQUE, `name`, `asset_type`, `currency`) référencée par la **position** (pas le compte). + +### F — Tableau à 5 colonnes de rendement mal calibré + +`BalanceAccountsTable.tsx` affiche Valeur | Δ% | 3M | 1A | Depuis création | Non-ajusté. Pour le grand public (montants agrégés, sans transferts liés) : warnings ambre ou colonnes identiques = bruit anxiogène. Pour l'investisseur : manquent quantité, prix actuel, **gain/perte $**, **% du portefeuille**. La colonne « Non-ajusté » dérive de l'horizon 1A en dur (`BalanceAccountsTable.tsx:327-329`) sans le dire. Recommandation : progressive disclosure — défaut Compte | Valeur | Δ%, rendements pliés ; colonnes titre pertinentes pour les comptes `priced`. + +### G — Empilé « par catégorie » illisible + +L'empilé (`BalanceEvolutionChart`) groupe par catégorie, qui est soit un véhicule soit une classe d'actif, jamais les deux (seed `consolidated_schema.sql:266-272`). L'histoire racontée est bâtarde : ni « répartition par classe d'actif », ni « répartition par enveloppe fiscale ». Recommandation : deux axes de groupement distincts (toggle *par enveloppe* / *par classe d'actif*), débloqués par la séparation des axes (A). + +### H — Onboarding muet sur le choix agrégé vs détaillé + +Les 4 starter accounts sont tous `simple` (`balance.service.ts:449`) ; aucun n'introduit le suivi par titre. L'investisseur actif doit deviner le chemin (catégorie `priced` → `asset_type` → symbole → snapshot : 4 écrans + notions techniques). Recommandation : question de calibrage à l'entrée (pattern Empower/Snowball : « suivez-vous des titres individuels ? ») avec deux presets (Simple / Investisseur). + +## Trajectoire recommandée (synthèse des deux experts) + +Une ligne directrice, en **trois temps additifs** — pas de big-bang, les comptes simples existants ne bougent jamais. + +**Étape 0 — Quick wins (effort S, indépendants, livrables tout de suite)** +`I` (corriger le bug i18n du renommage — prioritaire : casse une promesse FR/EN du projet), `J` (lexique : « catégorie » → « type/nature », gloser « snapshot », « encaisse »/« fonds » → « liquidités »/« fonds/FNB »), `K` (symbole optionnel), `M` (déplacer une date par `UPDATE` plutôt que delete+recreate). Aucun impact schéma structurant. + +**Étape 1 — Séparer l'axe véhicule (effort M, migration additive)** +Ajouter `balance_accounts.vehicle_type` (contrainte incluant **CELIAPP, REEE, CRI/FERR**), backfillé depuis `category.key`. Reclasser `balance_categories` en **pure classe d'actif**. → débloque « combien dans mon CELI » indépendamment de l'actif, assainit l'empilé (`G`) avec un toggle par enveloppe / par classe d'actif, et permet la progressive disclosure du tableau (`F`). Migration purement additive. + +**Étape 2 — Détail par titre sans perte d'historique (effort M→L, quand le besoin est confirmé)** +`balance_securities` (titre normalisé, devise → `N`, asset_type) + `balance_account_holdings` (positions par titre sous un compte, avec **`book_cost`** → `D`, `E`), et **migrer le `kind` de la catégorie vers le compte** → bascule « CELI agrégé → CELI détaillé » continue (`B`), avec un assistant UX « détailler ce compte en titres » qui conserve la valeur agrégée comme historique. En parallèle, traiter `C` (import CSV de cours local). + +## Recommandation sur l'ADR 0012 + +**Ne pas l'implémenter tel quel.** Le faire passer de `Proposed` à `Superseded` au profit d'un nouvel ADR « véhicule = attribut du compte + positions optionnelles par titre ». Il visait les bons groupements (`GROUP BY véhicule`, `GROUP BY classe d'actif`) mais avec une grille 2D imposée à tous et au mauvais grain (classe, pas titre). + +## Recommandation centrale + +Séparer enveloppe fiscale et classe d'actif dans le modèle, puis livrer le parcours « détailler un compte agrégé en titres » qui en découle (A → B). C'est l'unique levier qui débloque le « progressif » pour les deux personas : commencer agrégé puis détailler sans perdre l'historique ni bricoler des catégories. Tout le reste (import de prix, calibrage d'onboarding, lexique) reste cosmétique tant que ce mur central existe — mais l'Étape 0 se livre indépendamment, dès maintenant. + +## Annexe — fichiers de référence + +- Schéma : `src-tauri/src/database/balance_schema.sql` (v9), migrations v9-v11 `src-tauri/src/lib.rs`, seeds `src-tauri/src/database/consolidated_schema.sql` (l. 185-296) +- Service : `src/services/balance.service.ts` (`updateBalanceCategory` interdit le changement de `kind` l.152 ; `updateBalanceAccount` l.340 ; `STARTER_ACCOUNTS` l.449 ; agrégation par `category.key` l.1145-1174) +- Hooks : `src/hooks/useSnapshotEditor.ts` (Pré-remplir laisse le prix vide l.397), `src/hooks/useBalanceOverview.ts` +- Composants : `src/components/balance/{SnapshotLineRow,BalanceAccountsTable,BalanceEvolutionChart,AccountForm,StarterAccountsModal,BalanceOnboardingCard}.tsx` +- Pages : `src/pages/{BalancePage,AccountsPage,SnapshotEditPage}.tsx` (édition catégorie via `window.prompt` `AccountsPage.tsx:411`) +- Types : `src/shared/types/index.ts` (l. 559-704) +- ADR challengé : `docs/adr/0012-balance-two-level-model.md` ; contexte : 0008, 0010, 0011, 0013 +- Guide : `docs/guide-utilisateur.md` (l. 358-417) ; i18n : `src/i18n/locales/{fr,en}.json` clés `balance.*` diff --git a/docs/guide-utilisateur.md b/docs/guide-utilisateur.md index 5c3e9a6..04182d1 100644 --- a/docs/guide-utilisateur.md +++ b/docs/guide-utilisateur.md @@ -357,7 +357,7 @@ L'application est atomique : soit toutes les transactions cochées sont recatég ## 10. Bilan -Le **Bilan** est une vue patrimoniale : vous saisissez périodiquement un *snapshot* daté de l'ensemble de vos comptes (encaisse, REER, CELI, fonds, actions, crypto, autres), vous suivez leur évolution dans le temps, et vous calculez le **vrai rendement** de chaque compte d'investissement en liant les transferts (apports / retraits) aux comptes correspondants. +Le **Bilan** est une vue patrimoniale : vous saisissez périodiquement un *snapshot* (relevé daté de votre patrimoine) de l'ensemble de vos comptes (liquidités, REER, CELI, fonds, actions, crypto, autres), vous suivez leur évolution dans le temps, et vous calculez le **vrai rendement** de chaque compte d'investissement en liant les transferts (apports / retraits) aux comptes correspondants. Trois pages composent le module Bilan : - `/balance` — vue d'ensemble (graphique + tableau des comptes) @@ -368,11 +368,11 @@ L'entrée **Bilan** dans la barre latérale (icône portefeuille) donne accès ### Fonctionnalités -- 7 catégories standard pré-installées : Encaisse, CELI, REER, Fonds, Actions, Crypto, Autres — renommables, non-supprimables -- Création de catégories personnalisées (ex. FERR, RPDB) avec choix `simple` (montant direct) ou `priced` (quantité × prix unitaire) -- Comptes par catégorie : nom, symbole optionnel, devise (CAD au MVP), notes -- Snapshots datés avec contrainte UNIQUE par date — éditer = revenir sur la même date, jamais dupliquer -- Saisie groupée par catégorie ; pour les catégories `priced`, le `value` est calculé automatiquement (`quantity × unit_price`) +- 7 types standard pré-installés : Liquidités, CELI, REER, Fonds / FNB, Actions, Crypto, Autres — renommables, non-supprimables (un *type* regroupe des comptes de même nature ; à ne pas confondre avec les catégories de transactions) +- Création de types personnalisés (ex. FERR, RPDB) avec choix `simple` (montant direct) ou `priced` (quantité × prix unitaire) +- Comptes par type : nom, symbole optionnel (même pour les types cotés — il ne sert qu'à la récupération automatique des prix), devise (CAD au MVP), notes +- Snapshots datés avec contrainte UNIQUE par date — éditer = revenir sur la même date, jamais dupliquer ; la date d'un snapshot existant peut être déplacée (ses lignes sont conservées), tant qu'aucun autre snapshot n'occupe déjà la date cible +- Saisie groupée par type ; pour les types `priced`, le `value` est calculé automatiquement (`quantity × unit_price`) - Bouton **Pré-remplir depuis le snapshot précédent** : copie les valeurs simples + les quantités priced (vous remplissez juste les nouveaux prix) - Liaison de transactions existantes à un compte de bilan (modal avec filtres par période / catégorie / recherche, sens auto-proposé selon le signe) - Icône d'attribution dans la page Transactions pour les transactions liées à un transfert @@ -385,14 +385,14 @@ L'entrée **Bilan** dans la barre latérale (icône portefeuille) donne accès ### Comment faire -1. Allez dans `/balance/accounts` → onglet Catégories pour créer si besoin une catégorie supplémentaire (ex. "FERR" en `simple`, ou "Stocks Wealthsimple" en `priced`) -2. Allez dans l'onglet Comptes pour créer chaque compte (ex. "TFSA Tangerine" rattaché à CELI, "BTC Ledger" rattaché à Crypto avec symbole `BTC`) +1. Allez dans `/balance/accounts` → onglet Types pour créer si besoin un type supplémentaire (ex. "FERR" en `simple`, ou "Stocks Wealthsimple" en `priced`) +2. Allez dans l'onglet Comptes pour créer chaque compte (ex. "TFSA Tangerine" rattaché à CELI, "BTC Ledger" rattaché à Crypto avec symbole `BTC` — le symbole reste optionnel) 3. Cliquez **+ Nouveau snapshot** depuis `/balance` pour ouvrir `/balance/snapshot` à la date du jour 4. Remplissez les valeurs par compte (groupées par catégorie). Pour les comptes priced, saisissez la quantité et le prix unitaire — la valeur est calculée 5. Enregistrez. Le graphique sur `/balance` s'actualise immédiatement 6. Pour calculer le rendement réel d'un compte d'investissement, ouvrez le menu actions du compte → **Lier transferts** → cochez les transactions qui correspondent à des apports / retraits (un dépôt CELI, un achat d'actions, etc.). Le sens (in/out) est proposé automatiquement selon le signe de la transaction 7. Le tableau des comptes affiche maintenant les rendements Modified Dietz sur 3M / 1A / depuis création. Le rendement non-ajusté à droite vous permet de comparer "valeur du compte" et "vraie performance" -8. Pour éditer un snapshot existant, cliquez sur son point dans le graphique ou utilisez le sélecteur de date — la page s'ouvre en mode édition (la date est immutable) +8. Pour éditer un snapshot existant, cliquez sur son point dans le graphique ou utilisez le sélecteur de date — la page s'ouvre en mode édition. Vous pouvez aussi y corriger la date : changez-la puis enregistrez, le snapshot est déplacé avec ses lignes (un message s'affiche si la date cible est déjà prise par un autre snapshot) 9. Pour supprimer un snapshot, cliquez **Supprimer** dans son éditeur et re-saisissez la date pour confirmer ### Lecture des rendements multi-horizons diff --git a/src/components/balance/AccountForm.tsx b/src/components/balance/AccountForm.tsx index e27d96c..128e4c4 100644 --- a/src/components/balance/AccountForm.tsx +++ b/src/components/balance/AccountForm.tsx @@ -127,14 +127,14 @@ function AccountVariant({ const trimmedName = values.name.trim(); const trimmedSymbol = values.symbol.trim(); const nameInvalid = touched && trimmedName.length === 0; - // Priced categories require a symbol — surfaced as a validation error. - const symbolMissingForPriced = touched && isPriced && trimmedSymbol.length === 0; + // Symbol is optional even for priced categories (Issue #199). It only + // gates the price-fetch button — manual valuation (quantity × unit price) + // never needs it. So no symbol-required validation here. const handleSubmit = async (e: FormEvent) => { e.preventDefault(); setTouched(true); if (!trimmedName) return; - if (isPriced && !trimmedSymbol) return; const payload: CreateBalanceAccountInput = { balance_category_id: values.balance_category_id, @@ -233,18 +233,9 @@ function AccountVariant({ ? t("balance.account.form.symbolPlaceholderPriced") : t("balance.account.form.symbolPlaceholderSimple") } - className={`w-full px-3 py-2 rounded-lg border bg-[var(--card)] text-sm focus:outline-none focus:ring-1 focus:ring-[var(--primary)] ${ - symbolMissingForPriced - ? "border-[var(--negative)]" - : "border-[var(--border)]" - }`} + className="w-full px-3 py-2 rounded-lg border border-[var(--border)] bg-[var(--card)] text-sm focus:outline-none focus:ring-1 focus:ring-[var(--primary)]" autoComplete="off" /> - {symbolMissingForPriced && ( -

- {t("balance.account.form.symbolRequiredForPriced")} -

- )}
@@ -275,12 +266,7 @@ function AccountVariant({
diff --git a/src/services/balance.service.test.ts b/src/services/balance.service.test.ts index 5b0fd83..76e10ab 100644 --- a/src/services/balance.service.test.ts +++ b/src/services/balance.service.test.ts @@ -354,6 +354,33 @@ describe("createBalanceAccount", () => { const params = mockExecute.mock.calls[0][1] as unknown[]; expect(params).toEqual([1, "Encaisse Wealthsimple", null, "CAD", null]); }); + + it("allows a priced-category account WITHOUT a symbol (Issue #199)", async () => { + // Symbol is optional even for priced categories — manual valuation + // (quantity × unit price) never needs it; only the price-fetch button does. + mockSelect.mockResolvedValueOnce([ + { + id: 3, + key: "stock", + i18n_key: "balance.category.stock", + kind: "priced", + sort_order: 50, + is_active: 1, + is_seed: 1, + asset_type: "stock", + }, + ]); + mockExecute.mockResolvedValueOnce({ lastInsertId: 9, rowsAffected: 1 }); + const id = await createBalanceAccount({ + balance_category_id: 3, + name: "Portefeuille Wealthsimple", + // no symbol provided + }); + expect(id).toBe(9); + const params = mockExecute.mock.calls[0][1] as unknown[]; + // symbol param (3rd) is null — insert succeeds, no validation thrown. + expect(params[2]).toBeNull(); + }); }); describe("updateBalanceAccount", () => { @@ -1054,6 +1081,77 @@ describe("saveSnapshotAtomic — edit mode", () => { "COMMIT" ); }); + + it("moves the snapshot date in-txn and preserves the existing lines (Issue #200)", async () => { + // In edit mode with moveToDate set: BEGIN → collision SELECT (free) → + // UPDATE date → DELETE lines → INSERT line → UPDATE updated_at → COMMIT. + mockSelect.mockResolvedValueOnce([]); // collision check → target date free + mockExecute + .mockResolvedValueOnce({ rowsAffected: 0 }) // BEGIN + .mockResolvedValueOnce({ rowsAffected: 1 }) // UPDATE snapshot_date + .mockResolvedValueOnce({ rowsAffected: 0 }) // DELETE lines + .mockResolvedValueOnce({ lastInsertId: 100, rowsAffected: 1 }) // INSERT line (preserved) + .mockResolvedValueOnce({ rowsAffected: 1 }) // UPDATE updated_at + .mockResolvedValueOnce({ rowsAffected: 0 }); // COMMIT + + const res = await saveSnapshotAtomic({ + existingSnapshotId: 5, + snapshot_date: "2026-04-15", + moveToDate: "2026-05-20", + lines: [{ account_id: 1, value: 1234 }], + }); + + expect(res.snapshotId).toBe(5); + // Collision SELECT excludes the moved snapshot's own id. + const clashParams = mockSelect.mock.calls[0][1] as unknown[]; + expect(clashParams).toEqual(["2026-05-20", 5]); + // First execute is BEGIN, then the date UPDATE happens before the lines. + expect(mockExecute.mock.calls[0][0]).toBe("BEGIN"); + expect(mockExecute.mock.calls[1][0]).toContain("SET snapshot_date = $1"); + expect(mockExecute.mock.calls[1][1]).toEqual(["2026-05-20", 5]); + // Lines are still rewritten (preserved): DELETE then INSERT. + expect(mockExecute.mock.calls[2][0]).toContain( + "DELETE FROM balance_snapshot_lines" + ); + expect(mockExecute.mock.calls[3][0]).toContain( + "INSERT INTO balance_snapshot_lines" + ); + // Commits, never rolls back. + expect(mockExecute.mock.calls[mockExecute.mock.calls.length - 1][0]).toBe( + "COMMIT" + ); + expect( + mockExecute.mock.calls.some((c: unknown[]) => c[0] === "ROLLBACK") + ).toBe(false); + }); + + it("rolls back and throws snapshot_date_exists when moveToDate collides with another snapshot (Issue #200)", async () => { + mockSelect.mockResolvedValueOnce([{ id: 42 }]); // collision: another snapshot at the target + mockExecute + .mockResolvedValueOnce({ rowsAffected: 0 }) // BEGIN + .mockResolvedValueOnce({ rowsAffected: 0 }); // ROLLBACK + + await expect( + saveSnapshotAtomic({ + existingSnapshotId: 5, + snapshot_date: "2026-04-15", + moveToDate: "2026-05-20", + lines: [{ account_id: 1, value: 1234 }], + }) + ).rejects.toMatchObject({ code: "snapshot_date_exists" }); + + // BEGIN ran, then ROLLBACK — no date UPDATE, no line writes committed. + expect(mockExecute.mock.calls[0][0]).toBe("BEGIN"); + expect(mockExecute.mock.calls[1][0]).toBe("ROLLBACK"); + expect( + mockExecute.mock.calls.some((c: unknown[]) => + String(c[0]).includes("SET snapshot_date") + ) + ).toBe(false); + expect( + mockExecute.mock.calls.some((c: unknown[]) => c[0] === "COMMIT") + ).toBe(false); + }); }); // ----------------------------------------------------------------------------- diff --git a/src/services/balance.service.ts b/src/services/balance.service.ts index 6401ef0..1ad803e 100644 --- a/src/services/balance.service.ts +++ b/src/services/balance.service.ts @@ -42,6 +42,7 @@ export type BalanceErrorCode = | "asset_type_invalid" | "snapshot_date_required" | "snapshot_date_taken" + | "snapshot_date_exists" | "snapshot_not_found" | "snapshot_value_invalid" | "snapshot_priced_unsupported" @@ -935,12 +936,21 @@ export async function upsertSnapshotLines( * If ROLLBACK itself fails (e.g. transaction never opened), that error is * swallowed and the original is preserved — the caller never sees a * misleading rollback error. + * + * Edit-mode date move (Issue #200): pass `moveToDate` with the snapshot's + * NEW date when the user changed it in edit mode. The date move + line + * rewrite happen in the same transaction, so a collision on `moveToDate` + * (another snapshot already there) rolls the whole save back and surfaces + * `snapshot_date_exists`. Passing `moveToDate` in new mode is ignored — the + * date is taken from `snapshot_date` on INSERT there. */ export async function saveSnapshotAtomic(input: { existingSnapshotId: number | null; snapshot_date: string; notes?: string | null; lines: SnapshotLineInput[]; + /** New date for an edit-mode move; omit when the date is unchanged. */ + moveToDate?: string | null; }): Promise<{ snapshotId: number }> { // Validate every line ahead of time so the transaction never opens for // a doomed save. Mirrors `upsertSnapshotLines` invariants. @@ -957,6 +967,29 @@ export async function saveSnapshotAtomic(input: { let snapshotId: number; if (input.existingSnapshotId !== null) { snapshotId = input.existingSnapshotId; + // Edit-mode date move (#200): if a new date was requested, re-check the + // UNIQUE constraint in-txn and update `snapshot_date`. Done before the + // line rewrite so a collision rolls the entire save back. + if (input.moveToDate != null) { + const moveTo = normalizeSnapshotDate(input.moveToDate); + const clash = await db.select>( + `SELECT id FROM balance_snapshots + WHERE snapshot_date = $1 AND id <> $2`, + [moveTo, snapshotId] + ); + if (clash.length > 0) { + throw new BalanceServiceError( + "snapshot_date_exists", + `Another snapshot already exists at ${moveTo}` + ); + } + await db.execute( + `UPDATE balance_snapshots + SET snapshot_date = $1, updated_at = CURRENT_TIMESTAMP + WHERE id = $2`, + [moveTo, snapshotId] + ); + } } else { const date = normalizeSnapshotDate(input.snapshot_date); // Date collision check inside the transaction so a concurrent