feat(policy-ocr): store the IVA A.N.A. already prints
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:
+9
-8
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user