Cómo un POS emite un DTE al SII: qué ocurre entre el cobro y la boleta

Un DTE no es un PDF

La boleta que imprimes en papel térmico es una representación. El documento tributario de verdad es un archivo XML con una estructura fijada por el SII: encabezado con emisor y receptor, detalle de los ítems, totales, y dos piezas criptográficas que lo hacen válido. Si el XML está mal, da lo mismo que el papel se vea perfecto: el documento no existe para el SII.

Esas dos piezas criptográficas son el timbre electrónico (TED) y la firma. Son cosas distintas y se aplican en orden, y esa distinción es la que explica por qué la facturación electrónica no es simplemente "mandar los datos a una API".

Los cuatro pasos, en orden

• Armar el XML: se construye el documento con el emisor, el receptor, cada ítem y los totales calculados (neto, IVA, impuestos adicionales si corresponde). Un error de un peso en el total y el SII lo rechaza.
• Timbrar con el CAF: el timbre electrónico se genera con la llave privada que viene dentro del archivo CAF que el SII te autorizó. El timbre prueba que ese folio específico te pertenece.
• Firmar con tu certificado: la firma electrónica avanzada, hecha con el certificado digital de tu empresa, sella el documento completo, timbre incluido.
• Enviar al SII: el documento se empaqueta en un sobre (EnvioDTE) con su carátula, se firma otra vez y se envía. El SII no responde si está bueno o malo: devuelve un TrackID y hay que consultarlo después.

El recurso que se acaba: los folios CAF

El CAF es un archivo que el SII te entrega con un rango de folios autorizados para un tipo de documento. Cuando ese rango se agota, no puedes emitir más hasta pedir uno nuevo. Es el punto donde más se cae la operación de un local, porque suele pasar en la hora peak.

Un sistema serio resuelve tres cosas ahí: llevar un registro local de qué folio ya se usó, para no asignar el mismo dos veces aunque el proceso se reinicie; pedirle al SII un CAF nuevo antes de que el rango se acabe, sin que nadie tenga que entrar al portal; y anular los folios que quedaron sin usar de un rango anterior, para que la contabilidad cuadre.

Lo que pasa después de cerrar la caja

Emitir la boleta no cierra el ciclo. Si emites boletas electrónicas, el SII exige el Reporte de Consumo de Folios (RCOF): un resumen diario de todos los folios usados, anulados y saltados, que debe llegar antes de las 08:00 del día siguiente. No es opcional y no depende del volumen.

A eso se suman los libros electrónicos de compra, venta y guías, que se envían por período tributario. Si tu POS no los genera, alguien tiene que armarlos a mano o tu contador te los cobra aparte.

El SII no responde sí o no

Esta es la parte que sorprende a quien integra por primera vez: el envío es asíncrono. Recibes un TrackID y después consultas el estado, que puede ser exitoso, intermedio o rechazado. Y hay una diferencia crítica entre "el SII rechazó tu documento" y "el servidor de consulta del SII no está respondiendo".

• Exitoso: el envío fue procesado (EPR) o procesado con reparos (RPR).
• Intermedio: todavía está en validación (REC, SOK, FOK, CRT, PRD, PDR). Hay que volver a consultar, no reenviar.
• Rechazado: error de esquema XML (RSC), de firma (RFR) o de carátula (RCT). Ahí sí hay que corregir y reenviar.
• Códigos negativos, del -1 al -14: son fallas del servidor de consulta del SII, no un rechazo de tu documento. Confundirlos lleva a reenviar documentos que ya estaban buenos y a duplicar folios.

Motor propio o facturador externo

Todo lo anterior hay que implementarlo. Un software de punto de venta tiene dos caminos: construir su propio motor de DTE, o contratar a un proveedor de facturación que lo haga y consumirlo como servicio. Las dos opciones son legítimas y hay productos buenos en ambos lados, pero las consecuencias para el comercio son distintas.

Delegar en un tercero es más rápido de construir y traslada la certificación ante el SII al proveedor. A cambio, el POS queda encadenado a la disponibilidad, los precios y las condiciones de una empresa que tú no elegiste y con la que no tienes contrato. Si ese proveedor cobra por documento emitido, ese costo está adentro de lo que pagas, aunque no lo veas desglosado. Y si se cae, tu caja no emite.

Con motor propio el desarrollo es bastante más largo, incluida la certificación ante el SII, que hay que aprobar con sets de prueba para cada tipo de documento. La contrapartida es que no hay un intermediario entre tu venta y el SII, ni un tercero que pueda cambiarte las reglas.

Qué usa Devlas POS

Devlas POS emite con motor propio. La librería se llama @devlas/dte-sii, la desarrolla Devlas SpA y está publicada en npm con licencia MIT y código abierto en GitHub. No hay un facturador externo en medio: el sistema arma el XML, lo timbra con tu CAF, lo firma con tu certificado y lo envía al SII con el RUT de tu comercio.

Cubre nueve tipos de documento (factura 33, factura exenta 34, boleta afecta 39, boleta exenta 41, liquidación factura 43, factura de compra 46, guía de despacho 52, nota de débito 56 y nota de crédito 61), la gestión automática de folios, el RCOF, los libros electrónicos y la consulta de estados. Que sea código abierto significa que cualquiera puede auditar cómo se firma y se envía cada documento, en vez de tener que creernos.

Dos detalles reales del código, para dar una idea del tipo de problema que aparece en producción. El lector de códigos PDF417 del SII pierde los bytes sobre 128, así que un "Cajón" llega como "Cajnn" y el timbre no valida: por eso la librería normaliza a ASCII solo el contenido del timbre, mientras el XML y el documento impreso conservan las tildes. Y el proceso tiene que correr en horario de Chile, porque en UTC un envío hecho después de las 20:00 se declara con la fecha del día siguiente y el SII lo devuelve con "fecha no corresponde al envío".

Sigue leyendo