feat(policy-ocr): store the IVA A.N.A. already prints
Build and Push Images / Build jorgecuadros-api (push) Successful in 2m16s
Build and Push Images / Build jorgecuadros-web (push) Successful in 1m50s

The parser has been reading A.N.A.'s `TAX` cell since the ANA layout landed,
but `ParsedPolicy` had nowhere to put it, so the figure only ever reached a
review note and every OCR-confirmed policy was written with `tax` null — even
though the paper states it.

`TAX` now flows parser -> `extractedTax` -> `Policy.tax`, alongside the premium
fields beside it. GMX stays null: its certificate carries no premium at all, so
there is no tax on it either.

The other two cells stay out, for reasons worth keeping:

  - `LOCAL TAX` is a separate levy with no destination column, and summing it
    into `tax` would produce an IVA that no longer divides back to a rate —
    which is the whole reason to store the figure. It reads 0.00 on every
    policy seen so far; a non-zero one now raises a note saying the total will
    not reconcile, instead of quietly inflating the IVA.
  - `DISCOUNT` has no column and prints as a bare "-" when unused, which is
    what makes the row positional rather than "find six amounts".

`taxRate` is left null by confirm. A.N.A. prints the amount, not the rate, and
back-dividing it would mint a rate the document never stated; the capture form
resolves one from the line of business instead.

The review screen gains derecho de póliza next to the new IVA field. It was
already parsed and already written on confirm, but never shown — and an IVA
with no fee beside it leaves the reviewer unable to see why premium + fee + tax
equals the printed total.

The spec's assertion moved off the note and onto the field, plus a check that
the row reconciles: 298.61 + 30.00 at 8% is 26.29, totalling 354.90. That
agreement is what proves the positional mapping landed on the right cells
rather than merely on six numbers.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-18 07:38:23 -07:00
co-authored by Claude Opus 5
parent 48e01ddd21
commit 75e9f582b4
10 changed files with 128 additions and 11 deletions
+9 -8
View File
@@ -184,14 +184,15 @@ Each of these is a known, deliberate stopping point rather than a bug.
controles calculados sin campo, así que las 2,378 pólizas migradas leen
`tax` y `total` en null hasta que alguien las edite. No es recuperable: no
hay de dónde.
- **El OCR de A.N.A. lee `TAX` y `LOCAL TAX` y los tira.** El parser ya extrae
la fila `DISCOUNT | PREMIUM | POLICY FEE | TAX | LOCAL TAX | TOTAL`
(`policy-parser.ts`), pero `ParsedPolicy` no tiene campo para el impuesto,
así que la ruta OCR sigue guardando `tax` en null aunque el papel lo
imprima. Cerrarlo son: campo en `ParsedPolicy`, columna
`extractedTax` en `policy_ocr_documents`, campo en la pantalla de revisión,
y escritura en confirm. `LOCAL TAX` no tiene columna destino y habría que
decidir si suma al IVA o va aparte.
- **`LOCAL TAX` de A.N.A. no se captura.** El IVA (`TAX`) sí — se guarda desde
2026-08-18 — pero `LOCAL TAX` es un gravamen distinto sin columna destino y
**no** se suma al IVA: sumarlo daría una cifra que ya no divide de vuelta a
una tasa. Imprime 0.00 en todas las pólizas vistas hasta hoy; una distinta
de cero levanta la nota *"impuesto local N no capturado"* y significa que
`total` no cuadra contra `netPremium + policyFee + tax`.
- **`Policy.taxRate` queda en null por la ruta OCR.** A.N.A. imprime el monto
del IVA, no la tasa, y despejarla a la inversa inventaría una tasa que el
documento nunca declaró. El formulario resuelve una desde el ramo.
- **El recargo no se valida contra la forma de pago en datos migrados.** El
formulario lo deshabilita en ANUAL/CONTADO, pero
`backfill_policy_premium_breakdown.py` solo advierte cuando encuentra una
+21
View File
@@ -365,6 +365,27 @@ A.N.A.'s faces do print one — the `DISCOUNT / PREMIUM / POLICY FEE / TAX /
LOCAL TAX / TOTAL` row is on the same page — so an ANA document reaches the
review queue with `netPremium` populated and `postPremium` already ticked.
Four of those six cells are stored: `PREMIUM``netPremium`, `POLICY FEE`
`policyFee`, `TAX``tax` (`extractedTax` on the document, `Policy.tax` on
confirm), `TOTAL``total`. `DISCOUNT` and `LOCAL TAX` are reported as notes
instead:
- **`DISCOUNT`** has no column, and it prints as a bare `-` when unused, which
is what makes the row positional rather than "find six amounts".
- **`LOCAL TAX`** is a separate levy and is deliberately **not** summed into
`tax`. Folding it in would produce an IVA figure that no longer divides back
to a rate, which is the reason to store it at all. It reads 0.00 on every
A.N.A. policy seen so far; a non-zero one raises
*"impuesto local N no capturado"* and means `total` will not reconcile
against `netPremium + policyFee + tax`.
`Policy.taxRate` is left null by confirm. A.N.A. prints the IVA **amount**, not
the rate, and back-dividing one would mint a rate the document never stated —
the capture form resolves it from the line of business instead
(`PolicyType.taxRate`, see `apps/api/src/policies/premium.ts`). The figures do
agree: 298.61 + 30.00 taxed at 8% is 26.29, totalling 354.90, asserted in
`policy-parser.spec.ts`.
Deductible and loss participation are stored as **strings** (`"5%"`, `"20%"`,
`"USD 1,000"`) — they are printed as a mix of percentages, currency amounts
and free text, and normalising them would lose the distinction.