Context
Today the CLI hardcodes a small subset of SUNAT catalog values:
- Cat 03 (Unidades): `NIU`, `ZZ` are common. Real catalog has ~700 entries (KGM, MTR, LTR, ...).
- Cat 06 (Tipo doc identidad): 1, 4, 6, 7, 0 cover 99% of cases.
- Cat 51 (Tipo operación): `0101` Venta interna hardcoded everywhere.
- Cat 02 (Productos), Cat 09/10 (Tipo nota), Cat 20 (Motivo traslado) — partial coverage.
If a user passes an invalid `unidad`, SUNAT rejects with a cryptic 2xxx code instead of catching it client-side.
Scope
- Download SUNAT catalogs from official source (or vendor-in copies)
- `src/cpe/catalogos/` directory with one TS module per catalog
- `sunat schema cpe-catalogos` to introspect available codes
- Validation: warn (not error) on unrecognized codes — SUNAT may add new ones
- `cpe factura preview` includes a "catalog coverage report" if any field uses unknown codes
Source
- Anexo VII de RS 117-2017/SUNAT: spreadsheets at sunat.gob.pe
- Greenter has them as PHP constants (can port)
Success criteria
- 90%+ of SUNAT validation errors caught client-side before submit
- LIMITATIONS.md → "Catálogos SUNAT minimal" line removed
Why P3
Today's hardcoded subset works for typical case (factura PEN with NIU items). Edge cases bite SUNAT-side and the message is clear enough.
Context
Today the CLI hardcodes a small subset of SUNAT catalog values:
If a user passes an invalid `unidad`, SUNAT rejects with a cryptic 2xxx code instead of catching it client-side.
Scope
Source
Success criteria
Why P3
Today's hardcoded subset works for typical case (factura PEN with NIU items). Edge cases bite SUNAT-side and the message is clear enough.