# Tipos de documento (/docs/emision/tipos) ## Los tipos soportados [#los-tipos-soportados] | `tipo_dte` | Documento | Los precios son | Notas | | ---------- | ---------------------------- | ------------------------- | ------------------------------------------------------ | | 33 | Factura electrónica (afecta) | netos | Cedible | | 34 | Factura no afecta o exenta | netos | Todas las líneas exentas | | 39 | Boleta electrónica (afecta) | **brutos (IVA incluido)** | Receptor opcional (`66666666-6`) | | 41 | Boleta exenta | **brutos** | Receptor opcional | | 46 | Factura de compra | netos | Tú retienes el IVA. No la emite el canal `sfg` | | 52 | Guía de despacho | netos | Requiere un bloque `dispatch`. La emiten ambos canales | | 56 | Nota de débito | netos | Requiere una referencia | | 61 | Nota de crédito | netos | Requiere una referencia | No están en la v1: exportación (110/111/112), liquidación factura (43) y boleta de honorarios (que es un régimen del SII completamente distinto). > **Las boletas viajan por otro camino, y no te enteras** > > Las boletas (39/41) usan un transporte distinto al de las facturas — REST en vez de SOAP, por lotes, > con su propio token y su propia certificación. Eso es invisible para ti: mismo endpoint, mismos > campos, mismos estados. ## Referencias [#referencias] Una referencia apunta a otro documento. La necesitan obligatoriamente las notas de crédito (61) y de débito (56), y es opcional en el resto. ```json "references": [ { "tipo_dte": 33, "folio": 412, "date": "2026-08-14", "code": 3, "reason": "Corrige montos" } ] ``` | `code` | Significado | | ------ | ------------------------------- | | `1` | Anula el documento referenciado | | `2` | Corrige texto | | `3` | Corrige montos | Las referencias a documentos que no son DTE — una orden de compra, un contrato — usan los códigos de `tipo_dte` del SII en el rango 800 y omiten `code`: ```json "references": [ { "tipo_dte": 801, "folio": "OC-99213", "date": "2026-08-01", "code": null, "reason": "Orden de compra" } ] ``` `references[].date` es opcional: si se omite, toma la `issue_date` del propio documento. `references[].folio` acepta número o string; un número se convierte a su string decimal, porque `` es `xs:string` en el esquema del SII — un folio como `OC-99213` nunca podría serlo. ## Guía de despacho (52) [#guía-de-despacho-52] Requiere un bloque `dispatch`. La emiten los dos canales: el `sfg` (Portal MIPYME) por su formulario y el `mercado` con el motor certificado, que escribe el `IndTraslado` y el bloque `Transporte` del DTE. Lo que cambia entre canales no es si puedes emitirla, sino qué campos del `dispatch` caben en cada uno — al final de esta sección. ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{ "tipo_dte": 52, "receptor": { "rut": "76543212-K", "address": { "street": "Ruta 5 Sur km 12", "comuna": "San Bernardo", "city": "Santiago" } }, "dispatch": { "transfer_type": "venta", "carrier": { "rut": "11111111-1", "plate": "KJHZ42", "driver_rut": "13456789-9", "driver_name": "Ana Rojas" }, "requester_rut": "76543212-K" }, "items": [{ "description": "Pallet de insumos", "quantity": 4, "unit_price": 120000 }] }' ``` `dispatch.transfer_type` es el `IndTraslado` del SII: dice qué clase de movimiento documenta la guía, y es obligatorio (`422 dispatch_incomplete` si falta). No hay default: el formulario del propio SII parte marcando «operación constituye venta», que es justo lo que no quieres heredar cuando estás moviendo mercadería entre tus bodegas. | `transfer_type` | `IndTraslado` | Qué es | | ---------------------- | ------------- | ------------------------------------ | | `venta` | 1 | La operación constituye venta | | `venta_por_efectuar` | 2 | Ventas por efectuar | | `consignacion` | 3 | Consignaciones | | `entrega_gratuita` | 4 | Entrega gratuita | | `traslado_interno` | 5 | Traslados internos | | `otros` | 6 | Otros traslados que no son venta | | `devolucion` | 7 | Guía de devolución | | `traslado_exportacion` | 8 | Traslado para exportación (no venta) | | `venta_exportacion` | 9 | Venta para exportación | Solo `venta` y `venta_exportacion` son ventas: en las demás la guía declara el valor de la mercadería para efectos del traslado y no genera débito fiscal. **Los dos canales se comportan distinto con los montos.** Por canal `mercado` un monto cero o simbólico es un documento legítimo y no lo rechazamos — el SII aceptó exactamente uno (guía de traslado interno en $0) el 2026-08-21. Por canal `sfg` cada línea debe ir con precio mayor que 0 y el documento debe sumar más que 0, o la petición se rechaza con `422 sfg_guia_zero_amount`: el portal valida su formulario de guía con las validaciones de la *factura*, sea cual sea la clase de traslado, y lo dice con sus propias palabras — «Precio del primer item del detalle debe ser mayor a 0 … Valor Total Factura debe igual a la suma del Monto neto + IVA y mayor que 0». Es una regla del portal, no del impuesto, y por eso aplica a un solo canal. El bloque de transporte es opcional (una guía que se lleva el propio receptor no nombra transportista). `dispatch.destination` es una dirección de entrega distinta de `receptor.address`. El canal `mercado` la acepta y la escribe en el bloque `Transporte` del DTE. El canal `sfg` la rechaza con `422 dispatch_not_available_for_channel`: el formulario de guía del portal lleva una sola dirección, así que una destinación distinta no se podría imprimir — ponla en `receptor.address`. Lleva el mismo objeto que `receptor.address` (`street` / `comuna` / `city`); el SII los limita a 70 / 20 / 20 caracteres y lo que se pase se rechaza con `400 field_too_long`, nunca se trunca. Los RUT del bloque `dispatch` — `requester_rut`, `carrier.rut`, `carrier.driver_rut` — se guardan en la forma del SII, así que `76.123.456-7` o un dígito verificador en minúscula se aceptan y se normalizan al entrar, igual que `receptor.rut`. `dispatch.dispatch_type` es el `TipoDespacho` del SII: por cuenta de quién se despacha la mercadería y a las instalaciones de quién va. Es **opcional** — a diferencia de `transfer_type` no cambia lo que el documento significa, así que una guía que no lo trae es una guía completa. | `dispatch_type` | `TipoDespacho` | Qué es | | ------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------- | | `receiver_account` | 1 | Despacho por cuenta del receptor del documento: tu cliente, o el vendedor cuando el documento es una factura de compra | | `issuer_to_customer_site` | 2 | Por cuenta del emisor, a instalaciones del cliente | | `issuer_to_other_site` | 3 | Por cuenta del emisor, a otras instalaciones (entrega en obra, la bodega de un tercero) | El canal `mercado` lo escribe en el `IdDoc/TipoDespacho` del DTE. El canal `sfg` lo rechaza con `422 dispatch_not_available_for_channel`: el formulario de guía del portal tiene un solo selector de traslado, el de la clase de movimiento, y ningún campo de `TipoDespacho`, así que el dato no se podría imprimir. > **`dispatch.dispatch_type` cambió de vocabulario** > > Antes publicaba `emisor_propio` / `emisor_arrendado` / `receptor`, que decían de quién era el > *vehículo* que movía la mercadería — una pregunta que el SII no hace y que no se podía escribir en > ningún campo del DTE, así que el campo se rechazaba en los dos canales y nunca llegó a un documento. > Se redefinió sobre la semántica del propio SII en vez de publicar un segundo campo; los tres valores > antiguos hoy son `400 invalid_field`. Para decir quién mueve la mercadería usa `dispatch.carrier`. ## Nota de crédito (61) y nota de débito (56) [#nota-de-crédito-61-y-nota-de-débito-56] Autónomas, es decir sin pasar por el endpoint de conveniencia: ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{ "tipo_dte": 61, "receptor": { "rut": "76543212-K", "giro": "Venta al por mayor de alimentos", "address": { "street": "Los Militares 5001, of. 302", "comuna": "Las Condes", "city": "Santiago" } }, "references": [{ "tipo_dte": 33, "folio": 412, "date": "2026-08-14", "code": 3, "reason": "Corrige montos" }], "items": [{ "description": "Ajuste de precio", "quantity": 1, "unit_price": 120000 }] }' ``` Si lo que quieres es anular una factura, el atajo es [`POST /v1/documents/{document_id}/credit_note`](/docs/emision/acciones#anular-un-documento). ## Factura de compra (46) [#factura-de-compra-46] Tú eres el agente retenedor. ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{ "tipo_dte": 46, "receptor": { "rut": "55555555-5", "legal_name": "Google Cloud EMEA Ltd", "foreign": true }, "items": [{ "description": "Google Ads — julio 2026", "quantity": 1, "unit_price": 1000000 }], "withholding": { "iva": "total" } }' ``` `55555555-5` es el RUT genérico del SII para proveedores extranjeros no registrados. `withholding.iva: "total"` produce IVA totalmente retenido — el débito del F29 cae en el código 39 y el crédito en el 519/520. Hoy solo `total` es emitible: es el único `` que el motor sabe declarar. Mandar `"partial"`, o un `rate` distinto de `19`, se rechaza con `422 withholding_not_supported`. La retención queda en `totals.other_taxes` como un número **negativo** (p. ej. `-1891` si el IVA retenido es `1891`) — es la única forma de que `total = net + exempt + iva + other_taxes` siga siendo cierto en un documento que retiene. La automatización que detecta estos cargos y propone el documento está en [Impuestos · Tipo 46](/docs/impuestos/tipo-46). ## Boletas (39/41) y el consumidor anónimo [#boletas-3941-y-el-consumidor-anónimo] Las boletas pueden ir sin receptor. Cuando no hay uno, el documento va al consumidor final anónimo `66666666-6` — que es un RUT válido también en producción, y solo para boletas. ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{"tipo_dte":39,"items":[{"description":"Café","quantity":2,"unit_price":2500}]}' ``` > **Trampa — En una boleta, unit_price es bruto** > > `prices_include_tax` es `true` por defecto para 39 y 41. Los `2500` del ejemplo son 2.500 pesos con > IVA incluido, no 2.500 más IVA. Si tu sistema guarda precios netos, pon > `"prices_include_tax": false` explícitamente y normalizamos. > > En una factura (33/34/56/61/46) es al revés: ``/`` del SII siempre es NETO > (`DTE_v10.xsd`: `MontoItem` es neto salvo que venga `MntBruto`, que esta API nunca manda). Si mandas > `"prices_include_tax": true` en una factura, el precio se normaliza HACIA ABAJO en la puerta: los > `items` que devolvemos, el PDF y el `` muestran el precio neto (`11990` → `10075.6303`), y > el total puede quedar un peso distinto del bruto cotizado porque todo se calcula desde el precio neto > ya redondeado.