Modelo de factura
CierreListo recibe datos estructurados. No ofrece una operación para aceptar XML arbitrario y “solo firmarlo”: cada emisión pasa por validación, cálculo y construcción controlada.
Bloques conceptuales
Sección titulada «Bloques conceptuales»| Bloque | Contenido | Regla |
|---|---|---|
| Identidad | external_id, tipo de comprobante, fecha |
Debe representar una intención comercial única. |
| Emisor | Contribuyente asignado a la credencial | No se elige libremente en el cuerpo. |
| Receptor | Identificación, nombre y dirección aplicable | Debe cumplir las reglas del tipo e-CF. |
| Líneas | Descripción, cantidad, unidad, precio, descuentos e impuestos | Usa decimales, no coma flotante. |
| Totales | Subtotales, impuestos, descuentos y total declarado | CierreListo vuelve a calcularlos. |
| Pago | Forma, vencimiento y condiciones | Incluye solo lo exigido por el contrato. |
| Referencias | Documento modificado y motivo cuando aplique | Requeridas para notas y correcciones. |
Montos y cantidades
Sección titulada «Montos y cantidades»- Envía montos como cadenas decimales en la precisión publicada.
- No uses
numberbinario para comparar totales financieros. - No redondees cada paso de forma independiente.
- Conserva el valor comercial original para reconciliación.
- Trata una diferencia de cálculo como error de datos, no como fallo temporal.
Totales declarados
Sección titulada «Totales declarados»El cliente envía los totales que espera. CierreListo recalcula y compara:
- si son coherentes, la operación puede avanzar;
- si no son coherentes, devuelve un error de validación;
- el servidor no “arregla” silenciosamente un monto fiscal.
Tipos e-CF
Sección titulada «Tipos e-CF»Una credencial solo puede usar los tipos certificados y habilitados para su contribuyente y ambiente. Que un tipo exista en el estándar no implica que esté habilitado en el piloto.
La API pública v1 limita la creación a:
31: factura de crédito fiscal electrónica;32: factura de consumo electrónica.
Esta lista se valida también al generar los ejemplos. Si cambia el enum canónico, el build del portal falla hasta que las guías vuelvan a quedar coherentes.
Evolución del esquema
Sección titulada «Evolución del esquema»Los requests son estrictos: envía únicamente los campos publicados. Al leer respuestas, conserva campos adicionales de objetos conocidos sin dejar de validar los campos contractuales.
No ignores ni trates automáticamente como compatible:
- cambios de tipo;
- campos que pasan a ser requeridos;
- nuevas reglas fiscales;
- estados o errores desconocidos.