--- title: Factura afecta (33) description: Campos, request por los 3 canales programáticos, response 202 y la tabla completa de estados SII — la referencia canónica de la familia de facturas. url: https://notta.cl/docs/emit-factura-33 related: - https://notta.cl/docs/nota-credito-61 - https://notta.cl/docs/api/dtes - https://notta.cl/docs/errors --- > Documentación de Notta en markdown. Índice completo: https://notta.cl/llms.txt — corpus entero: https://notta.cl/llms-full.txt # Factura afecta (33) El `tipo_dte` 33 es la Factura Electrónica afecta a IVA — el caso más común para SpAs, empresas de servicios profesionales y comercio B2B. Esta es la página canónica de campos de la familia de facturas: [Factura exenta (34)](/docs/factura-exenta-34), [Nota de Crédito (61)](/docs/nota-credito-61) y [Nota de Débito (56)](/docs/nota-debito-56) documentan solo sus diferencias respecto de esta página. ## Campos del request `POST /api/v1/dtes` acepta este body para tipo 33: | Campo | Tipo | Requerido | Descripción / constraint | |---|---|---|---| | `tipo_dte` | `number` | sí | `33` para factura afecta | | `rut_emisor` | `string` | sí | RUT canónico `BODY-DV` sin puntos (`76123456-0`); el DV se valida módulo 11 | | `receptor.rut` | `string` | sí | Mismo formato canónico (`11111111-1`) | | `receptor.razon_social` | `string` | sí | Mínimo 1 carácter después de trim — espacios solos rechazan | | `receptor.giro` | `string` | sí (33/34) | Giro del receptor; obligatorio y no vacío para 33 y 34 | | `receptor.direccion` | `string` | sí (33/34) | Dirección del receptor; obligatoria y no vacía para 33 y 34 | | `receptor.comuna` | `string` | sí (33/34) | Comuna del receptor; obligatoria y no vacía para 33 y 34 | | `fecha_emision` | `string` | sí | Formato `YYYY-MM-DD` | | `items` | `array` | sí | Entre 1 y 60 items | | `items[].nombre` | `string` | sí | Mínimo 1 carácter | | `items[].cantidad` | `int` | sí | Entero | | `items[].precio_unitario` | `int` | sí | Pesos CLP, sin decimales | | `items[].exento` | `boolean` | sí | La 33 admite mezclar items afectos y exentos | | `items[].monto_item` | `int` | sí | Total de la línea en CLP | | `forma_pago` | `1 \| 2 \| 3` | sí (33/34) | Forma de pago: `1` Contado, `2` Crédito, `3` Sin costo. Obligatorio para 33 y 34. La UI pre-selecciona Crédito (`2`) | | `references` | `array` | no | Máximo 40. En la 33 solo referencias comerciales (`orden_compra`, `contrato`, `hes`), sin `cod_ref` — las referencias correctivas pertenecen a [NC](/docs/nota-credito-61) y [ND](/docs/nota-debito-56) | | `monto_neto` | `int` | no | Si lo mandas, debe igualar la suma de items afectos | | `monto_exento` | `int ≥ 0` | no | Si lo mandas, debe igualar la suma de items exentos | | `iva` | `int` | no | 19% sobre el neto | | `monto_total` | `int` | no | Debe igualar `monto_neto + iva + monto_exento` | | `certificate_id` | `string` (UUID) | no | Certificado digital específico; por defecto el activo de la organización | | `sii_env` | `"cert" \| "prod"` | no | Default `"cert"` (maullin, sandbox del SII) | Los montos son opcionales porque Notta los calcula desde los items. Si los mandas y no cuadran, el endpoint responde `400` con código `validation_failed` y el detalle campo por campo en `issues[]`. ## Request Puedes emitir por los 3 canales programáticos (API, CLI, MCP) + el dashboard. El mismo request en los tres programáticos: > **Disponibilidad:** `@notta/cli` y `@notta/mcp` están en proceso de publicación en npm. El camino ejecutable hoy es curl con tu API key — el dashboard y la API cubren el flujo completo mientras tanto. #### curl ```bash curl -X POST https://app.notta.cl/api/v1/dtes \ -H "Authorization: Bearer ntt_cert_..." \ -H "X-Cert-Id: 01957a91-0b50-7000-8000-cccc00000001" \ -H "Idempotency-Key: $(uuidgen)" \ -H "Content-Type: application/json" \ -d '{ "tipo_dte": 33, "rut_emisor": "76123456-0", "receptor": { "rut": "11111111-1", "razon_social": "Cliente Ejemplo SpA", "giro": "Comercio", "direccion": "Av Siempre Viva 123", "comuna": "Santiago" }, "forma_pago": 2, "fecha_emision": "2026-05-13", "items": [{ "nombre": "Consultoría mayo 2026", "cantidad": 5, "precio_unitario": 50000, "exento": false, "monto_item": 250000 }] }' ``` El `X-Cert-Id` es el id de tu certificado (paso 1 del [quickstart](/docs) o dashboard). #### CLI ```bash notta dte emit \ --tipo 33 \ --to 11111111-1 \ --name "Cliente Ejemplo SpA" \ --giro "Comercio" \ --direccion "Av Siempre Viva 123" \ --comuna "Santiago" \ --forma-pago 2 \ --item "Consultoría mayo 2026:5:50000" \ --env cert ``` #### MCP ```ts notta_dte_emit({ tipo_dte: 33, rut_emisor: "76123456-0", receptor: { rut: "11111111-1", razon_social: "Cliente Ejemplo SpA", giro: "Comercio", direccion: "Av Siempre Viva 123", comuna: "Santiago" }, forma_pago: 2, fecha_emision: "2026-05-13", items: [{ nombre: "Consultoría mayo 2026", cantidad: 5, precio_unitario: 50000, exento: false, monto_item: 250000 }] }) ``` ## Response El endpoint responde `202 Accepted` — la emisión es asíncrona. El DTE queda `queued`, y la transición a `EPR` ocurre tras firma + envío al SII (típicamente 2-15 segundos). ```json { "id": "01957a91-0b50-7000-8000-000000000001", "status": "queued", "folio": 1234, "tipo_dte": 33, "rut_emisor": "76123456-0", "rut_receptor": "11111111-1", "monto_neto": 250000, "monto_exento": 0, "iva": 47500, "monto_total": 297500, "sii_env": "cert", "sii_status": "queued", "fecha_emision": "2026-05-13", "links": { "self": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001", "pdf": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001/pdf", "xml": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001/xml", "events": "/api/v1/dtes/01957a91-0b50-7000-8000-000000000001/events" } } ``` Para seguir el estado, consulta `links.self` con GET. Si el SII demora, fuerza una re-consulta con `POST /api/v1/dtes/{id}/refresh-status`. `links.events` apunta a un endpoint aún no habilitado — para seguir el estado usa `links.self` o `refresh-status`. ## Estados SII `status` y `sii_status` traen el mismo valor. Los posibles: | Estado | Significado | |---|---| | `queued` | Encolado, aún sin firmar | | `sending` | Firmado, enviando al SII | | `awaiting_sii` | Recibido por el SII, esperando resultado | | `SOK` | Schema validado por el SII (transitorio — el procesamiento sigue asíncrono) | | `CRT` | Carátula validada (transitorio) | | `EPR` | Envío procesado y aceptado (terminal de éxito) | | `RPR` | Aceptado con reparos a nivel de envío (revisar `sii_glosa`) | | `aceptado_con_reparos` | Documento aceptado con observaciones (revisar `sii_glosa`) | | `RFR` | Rechazado por error de firma (terminal) | | `RCT` | Rechazado por error de carátula (terminal) | | `RSC` | Rechazado por error de schema (terminal) | | `stuck` | El polling agotó reintentos sin resultado terminal — requiere revisión | ## Idempotency Todo POST exige el header `Idempotency-Key` (UUIDv7 recomendado); sin él, el endpoint responde `400` con código `idempotency_key_missing`. Si la misma key llega dos veces, retorna el resultado de la primera operación en lugar de duplicar el DTE. CLI y MCP generan keys frescas automáticamente. ## Próximos pasos - **[Nota de Crédito (61)](/docs/nota-credito-61)** — corrige o anula una factura ya aceptada por el SII. - [Referencia API de DTEs](/docs/api/dtes) — todos los endpoints de `/dtes`: list, detail, PDF, XML y refresh-status. - [Errores](/docs/errors) — el shape uniforme de error (`code`, `hint`, `next_action`) y cómo manejarlo.