Al elegir un concepto del catálogo, la partida ya heredaba sus claves del SAT, pero eso
pasaba en silencio dentro del backend: en pantalla los tres selects se quedaban en
"Selecciona…" aunque el concepto los tuviera configurados, y no había forma de ver qué
impuesto iba a aplicar antes de guardar.
Backend:
- unit_amount se hereda del unit_price del concepto. Estaba prellenado SOLO por el
formulario web, así que cualquier otro cliente de la API tenía que teclearlo. Requiere
que unit_amount sea opcional en InvoiceItemCreate: con el default 0 de InvoiceItemBase
siempre llegaba valor y el service no podía distinguir "no lo capturó" de "capturó 0".
Un 0 explícito se respeta — una partida de cortesía es una decisión, no un campo vacío.
Frontend:
- Al elegir el concepto se copian precio y las tres claves del SAT a los campos, para que
se vean antes de guardar. Elegir una partida genérica las limpia, en vez de arrastrar las
del concepto anterior a algo que no las tiene.
- Se muestra el impuesto que se aplicará, resuelto con la misma precedencia del backend:
el del concepto si lo define, el % de la factura si no, y "no causa impuesto" cuando el
objeto de impuesto no es 02.
Lo que se cambie en el formulario sigue mandando sobre el catálogo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Jair Cedillo
5a62c31d93