4 Commits

Include renames

Author	SHA1	Message	Date
rmancinasandClaude Opus 5	aa5867c8ea	fix(statements): an archive is history below the year start, not nothing ... c6feae9 excluded imported periods from the current period outright. That is right for the rows an archive spills into the following January — those already sit inside the next year's BALANCE FORWARD, which is the sum of the whole archive, so counting them again would double-book them and file a closed year's row as current. It is wrong for everything below the year start. Those rows are what `opening` exists for, and for a customer whose newest BALANCE FORWARD lives *inside* an archive they are the only carry there is: the corte skipped NUMid 295 in 2026, so his floor is the archive's own January 1 and excluding it dropped his entire 2025 closing balance. His statement read 3,592.00 against a true 4,377.46. So the rule is a window, not an exclusion: an archive row counts below the year start and never at or above it. Applied identically to statement(), the edo-cuenta-datos report and the customer-file card, which have to agree. Spelled as a positive OR rather than NOT(tag AND date). `NOT (col LIKE '...' AND ...)` is NULL for a row with no legacySourceTable, so the negated form would have silently dropped every app-captured movement — the same NULL trap the source-table exclusion was already fixed for. Verified against prod, which now carries datos2@2025: exactly one customer is affected and the book moves by his 785.46. NUMid 501 is unchanged at -10,874.33 and still matches the portal; 6 and 173 are unchanged to the cent; the two customers whose archives spill into January 2026 still keep those rows out of the current period. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 17:29:08 -07:00
rmancinasandClaude Opus 5	c6feae9522	fix(customers): the customer file's balances are the statement's balances ... The /clientes/:id ledger card is titled "Estado de cuenta" and links straight to the statement, but its per-line tiles came from a groupBy with `voidedAt: null` and nothing else — no balance floor, no source exclusion, no outstanding rule. It was a raw lifetime sum, double-counting the pre-cutover history that each BALANCE FORWARD row already absorbs, and the card said so in its own footnote rather than being fixed. Importing prior periods turned that from wrong into badly wrong. Every closed year is now also held as its own tagged copy, so an unfloored sum adds each one a second time on top of the opening balance that contains it. NUMid 501 read -7,119.29 before the archives landed and -15,270.59 after, against a true -10,715.29 — the gap being exactly the 2024 and 2025 closing balances. The tiles now take the same three rules the statement takes, and agree with it for all 600 customers sampled. Two places needed the archives excluded explicitly, because the balance floor does not do it: - A customer whose newest BALANCE FORWARD lives inside an archive floors at that archive's own January 1, so every row of it clears the floor. One customer, 28 rows. - The archives are not cleanly bounded. datos2@2024 carries rows dated 2022, 2023, 2025 and one in 2026; datos2@2025 two more. Those clear any floor and land in the current year next to the live ledger's own copy of them. That second point is a defect in 93f8171, not only in this card: statement() and the edo-cuenta-datos report were both filtering the current period by source and date without excluding the period tags, so four customers on the dev book would have read a closed year's rows as current. Both are fixed here. The portal already had it right. The year's movement list on the card keeps showing every non-archive row, as before — it is a list of what happened, not a balance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 16:19:06 -07:00
rmancinasandClaude Opus 5	93f817158e	feat(statements): a year selector, reading each closed year from its archive ... The statement has been pinned to the calendar year in progress since bc74905. Now that prior years are imported, the year becomes a choice: the current one still reads the live ledger, and any earlier one reads that year's archive. A period is selected by its `datos2@YYYY` tag, not by a date range. That is how legacy addressed it — one table per closed year, `SELECT ... FROM `2025`` — and the distinction is load-bearing: the archives carry rows dated a day or two into the following January, so a date window would file them under the wrong year in one direction and drop them in the other. Two things the archive branch must not inherit: - The balance floor. It exists to stop a later opening balance double-counting the history it summarizes; for a period view that history is precisely what is being asked for, so applying it would return nothing at all. - The cash-source exclusion. It reproduces legacy's DATOS2-only datosfreak, and an archive is DATOS2 rows already. No fold into an opening balance either — the archive holds its own Jan-1 BALANCE FORWARD row, which is the carry, listed exactly as legacy listed it. The current period stays deliberately open-ended at the top. A period is a table in legacy, not a date range, so whatever the office filed in it belongs to it, including the future-dated rows the live ledger carries out to 2028. Bounding it would hide them from every view. `availableYears` reports the periods a customer actually has, so the picker never offers a year that would render empty — "you had no activity in 2019" is a different claim from "2019 was never imported", and only one of them is true. The selector hides itself entirely for a customer with a single period, and a year outside the list is a 404 rather than a silent fall back to the current one. The same period rule lands on the printable twin (edo-cuenta-datos gains a "Periodo (año)" parameter) and on the portal, where fetchLedgerRowsPlatform was also filtering by date with no source exclusion at all — so period=2025 would have returned the archive rows on top of that year's EFECTIVO receipts, counting every prior-year payment twice. The portal's allowlist is now built per data source and validated at the point of use: DreamHost holds the current year plus one archive table, the platform holds however many were imported, and fetchLedgerRowsLegacy interpolates the period as a table name, so a platform-only year must not reach it — including on the fallback path when the platform is unreachable. Left alone: the /clientes/:id ledger card still shows the current year. It reads transactionYear off the customers endpoint rather than the statement, it is a summary that links to the full statement, and giving it its own year state would duplicate the page it links to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 15:48:25 -07:00
rmancinasandClaude Opus 5	d173c9e9a0	fix(billing): stop double-counting history a BALANCE FORWARD already carries ... BALANCE FORWARD rows are not movements. Access materialized one per customer per year, dated Jan 1, holding the closing balance of everything before it — that is what let the portal keep each year in its own table and still show a correct running balance from one year's rows. The platform imported those rows AND the real pre-cutover history they summarize, and every balance aggregate summed the lot. NUMid 501 read -10,469.29 on the receivables worklist against -14,065.29 on the customer's own statement and on the legacy portal; the gap was two cash receipts from 2009 and 2012 that the 2026 opening balance had already absorbed. The scale settles what it is: summed the old way the whole book came to +20,605,447.86 MXN — the office owing its customers 20.6 million pesos. Floored, it is -56,855.90. A receivables ledger cannot be 20M in credit. Adds BALANCE_FLOOR_JOIN + NOT_SUPERSEDED and applies them to balances() (page and count queries, which must agree), to stats()'s per-currency and per-domain figures, and to the owing/in-credit split. The four stats() aggregates moved from Prisma groupBy to raw SQL because groupBy cannot express a per-customer floor. statement() takes the same floor as a scalar, which is also what stops FEE ANUAL and fee15 leaking in. Those are not in STATEMENT_EXCLUDED_SOURCE_TABLES — that list reproduces legacy's DATOS2-only `datosfreak` — and they were putting 2,092 pre-cutover fee rows across 1,062 customers into the statement, skewing it by -5,129,764 against the number those customers have been quoted for years. Dating rather than source is the right test: a fee row *after* the opening balance is a real charge and still counts. movements() is deliberately left alone. It is a browser over captured rows — "how much water did we capture in April" — and staff need the historical rows visible, so it keeps totalling everything, the same asymmetry NOT_OUTSTANDING already has. stats() now separates the two questions it was mixing: movements, ledgerCustomers, crossLineCustomers and the date range stay unfloored inventory; everything under byCurrency/byDomain is a balance and is floored. BillingService had no tests. Adds 13 covering the floor's failure modes — it fails silently, so MIN-vs-MAX, `>` vs `>=`, the NULL branch for customers with no opening balance, and the join/predicate alias pairing are each pinned, plus the 501 arithmetic as a regression. Verified through the real service against the live ledger: balances() and statement() both return -14,065.29 for 501, matching the portal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 00:34:53 -07:00