import { Aside } from "@astrojs/starlight/components";

`POST /api/v1/ecf` no espera un calco del XML que la DGII exige. El e-CF
real tiene cerca de 137 campos de encabezado y una matriz de obligatoriedad
distinta por cada uno de los 10 tipos de comprobante, y ningún integrador
debería tener que conocer eso de memoria para emitir una factura. Por eso el
payload que recibe NovaFE es un modelo curado: le describes tu intención
comercial (quién te compró, qué le vendiste, cómo te pagó) y NovaFE arma el
e-CF conforme a partir de ahí.

Esta página explica esa división de trabajo. Los módulos siguientes cubren
cada bloque del payload campo por campo.

## Lo que arma NovaFE

Por defecto no lo mandas en el payload, porque NovaFE ya lo resuelve por su
cuenta. La excepción es la numeración, que puedes asumir tú (ver la sección
Numeración propia de [e-NCF y secuencias](/conceptos/secuencias/)):

| Campo del XML                                                          | De dónde sale                                                                                                             |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `<eNCF>`                                                               | Asignación atómica desde tu rango de secuencias autorizado. Con numeración propia, lo envías en `encf`.                   |
| `<FechaVencimientoSecuencia>`                                          | Del rango asignado. Ausente en los tipos 32 y 34, que no vencen. Con numeración propia, la envías en `sequenceExpiresOn`. |
| `<RNCEmisor>`, `<RazonSocialEmisor>`, `<NombreComercial>`              | De tu tenant.                                                                                                             |
| `<DireccionEmisor>`, `<Municipio>`, `<Provincia>`, actividad económica | De tu perfil fiscal ([Cabecera y comprador](/emision/cabecera-comprador/) explica esto).                                  |
| Todos los `<Totales>` y `<MontoItem>`                                  | Calculados a partir de tus líneas y tus ajustes.                                                                          |
| `<IndicadorNotaCredito>`                                               | La regla de los 30 días desde la fecha del comprobante que referencias.                                                   |
| `<FechaHoraFirma>`, `<Signature>`, código de seguridad, QR             | Se generan al firmar con tu certificado.                                                                                  |

## Lo que mandas tú

Comprador, líneas, forma de pago, tipo de ingreso, ajustes globales de la
Sección D, referencia a otro comprobante (para notas de crédito o débito),
montos ya convertidos si facturas en otra moneda, y datos de embarque,
transporte o paginación cuando el tipo de comprobante los admite. El detalle
de cada bloque está en los módulos siguientes:

- [Cabecera y comprador](/emision/cabecera-comprador/)
- [Pago y líneas](/emision/pago-lineas/)
- [Ajustes, referencia y moneda extranjera](/emision/ajustes-referencia-moneda/)
- [Embarque, transporte y paginación](/emision/embarque-transporte-paginacion/)

Qué campos son obligatorios depende del tipo de comprobante: eso vive en la
[matriz de obligatoriedad por tipo](/emision/tipos-soportados/).

## El escape para migraciones: `declaredTotals`

Si estás migrando desde un sistema que ya calcula sus propios totales,
puedes mandarlos igualmente en `declaredTotals` (a nivel de encabezado) y en
`lines[].declaredAmount` (a nivel de línea). NovaFE los compara contra lo
que él mismo calculó, con una tolerancia de un peso por campo en el
encabezado y por línea.

<Aside type="note" title="Nunca rechaza por esto">
  Si tus totales declarados no cuadran con los de NovaFE dentro de esa
  tolerancia, la respuesta trae un `toleranceWarning` y probablemente la DGII
  acepte el comprobante como "aceptado condicional". Nunca se rechaza el
  comprobante por esta diferencia: **los valores que calcula NovaFE son siempre
  los que van al XML**, así que el comprobante que le llega a la DGII es
  correcto de todas formas.
</Aside>

Este mecanismo existe para que una migración no se trabe reconciliando
centavos de redondeo entre dos motores de cálculo distintos, no para que
ignores los totales que NovaFE calcula.