fix(billing): the cash receipt book is not a second ledger

EFECTIVO is a journal, not a ledger. The office writes a numbered paper
receipt for money handed over the counter and then posts that same receipt
to the utilities ledger as reference `C<folio>`. Legacy summed the ledger
alone — ledger_repository.php reads `datosfreak`, materialized from DATOS2
only — but the migration flattened both tables into one `transactions`
table, so every balance counted each counter payment twice.

Confirmed against the live legacy database rather than inferred: of the 297
receipts written in 2026, 296 carry a matching DATOS2 posting. Six of them
post converted to pesos under a mistyped folio, which is why matching pairs
on folio and amount found fewer duplicates than exist — and why this
excludes the whole journal instead of a list of confirmed pairs. Only folio
13536 (CL 717, $400 USD) has no posting anywhere; that one wants a human.

The database qualifier is load-bearing. `SEGUROS 16_be` keeps its own table
also called EFECTIVO, and that one is the insurance line's only ledger —
nothing posts it anywhere else. Excluding by table name alone would erase
55,444.95 USD and 63,957.78 MXN across 102 customers, 99 of whom have no
other rows at all. Extending the qualified rule to the statement and the
customer file also gives those 99 back a statement that is not empty.

The same queries were missing the archive window the statement already had,
so the worklist and the book also counted a closed year twice for customers
floored inside an archive.

Measured on production, utilities MXN: NUMid 6 and 173 unchanged to the
cent, 501 unchanged at -10,874.33 (still the portal's number), 10 drops
2,362.20 -> -1,137.80 (exactly the 3,500.00 duplicate), 295 drops
14,377.46 -> 4,377.46 — which is what his statement already said. The
worklist and the statement now agree, which is the point.

Left alone deliberately: the movement browser, which is inventory rather
than balance and should still show what was captured; and stats()'s
outstanding rows, which turn on a client decision that is still open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

apps/api/src/customers/customers.service.ts

@@ -5,21 +5,10 @@ import { CreateCustomerDto } from "./create-customer.dto";
 import { UpdateCustomerDto } from "./update-customer.dto";
 import {
   BALANCE_FORWARD_TYPE,
+  notCashJournal,
   PERIOD_TABLE_PREFIX,
-  STATEMENT_EXCLUDED_SOURCE_TABLES,
 } from "../billing/billing.service";
 
-/**
- * Keeps imported prior periods out of a query, NULL-safely.
- *
- * A closed year is imported as its own tagged copy of that year's ledger
- * (`datos2@2025`) and the BALANCE FORWARD rows above it already contain every
- * peso of it. Anything summing a customer's history has to leave the archives
- * out or it counts each closed year twice — see the floor comment below.
- *
- * `NULL NOT LIKE '...'` is NULL rather than true, so app-captured rows (which
- * carry no legacySourceTable) need the null branch spelled out or they vanish.
- */
 /**
  * Keeps an imported prior period out of the *current* period, NULL-safely.
  *
@@ -225,19 +214,7 @@ export class CustomersService {
         // The floor alone does not settle the archives: a customer floored by
         // an archive clears it with every row of that archive, and the rows
         // archives spill into the following January clear any floor.
-        AND: [
-          archiveIsHistory(yearStart),
-          {
-            OR: [
-              { legacySourceTable: null },
-              {
-                legacySourceTable: {
-                  notIn: [...STATEMENT_EXCLUDED_SOURCE_TABLES],
-                },
-              },
-            ],
-          },
-        ],
+        AND: [archiveIsHistory(yearStart), notCashJournal()],
       },
       _sum: { amount: true },
       _count: { _all: true },