Facturar desde Odoo en Chile: módulos, certificación, CAF y alcance por flujo

¿Qué exige el SII a cualquier sistema que emita en Chile?

Una factura registrada en el ERP no es todavía un Documento Tributario Electrónico. Para que exista como DTE debe pasar por reglas que pertenecen al emisor chileno, no al asiento, la orden de venta ni la pantalla donde se digitó. El SII identifica al contribuyente autorizado, el tipo de documento, el folio, la firma, el contenido y el resultado de cada envío.

Esta base es la misma para SAP, NetSuite, Business Central, Odoo o un desarrollo propio. Lo que cambia es cuánto resuelve la localización elegida, quién opera cada pieza y dónde queda la evidencia cuando el SII acepta, observa o rechaza. El proyecto debe responder estas seis exigencias antes de hablar de automatización.

La primera prueba útil no es imprimir una factura. Es seguir un caso completo desde la transacción original hasta el estado final del DTE, su representación impresa y el intercambio con el receptor.

¿Qué le falta típicamente a un ERP extranjero para emitir un DTE?

Un ERP internacional suele resolver bien clientes, productos, impuestos, precios, contabilidad y cobranza. El vacío aparece en las responsabilidades que solo existen porque el emisor opera en Chile. Algunas ediciones ofrecen una localización propia y otras dependen de extensiones o proveedores. En todos los casos debes verificar alcance y configuración, no inferirlo por el nombre del producto.

Estas brechas no significan que el ERP sea deficiente. Significan que la localización tributaria es otro producto, con ciclo de actualización, pruebas, credenciales y soporte propios. El error caro es descubrir esa separación después de diseñar interfaces, capacitar usuarios o comprometer la fecha de salida.

• Gestión de CAF y consumo de folios separados por tipo de DTE, empresa, ambiente y, cuando corresponde, sucursal.
• Generación del timbre electrónico con la llave del CAF y firma del documento completo con certificado vigente.
• Representación impresa conforme al formato del SII, incluido el timbre PDF417 y los datos que cambian según el documento.
• Pipeline propio para boleta electrónica, con sus tipos, CAF, envío individual y tratamiento de ventas a consumidor final.
• Casilla de intercambio para enviar DTE al receptor y procesar recepciones, rechazos y decisiones comerciales sin confundirlas con el estado del SII.
• Documentos de exportación con campos, monedas, aduana, transporte y folios distintos de la factura nacional.
• Monitoreo de estados, reintentos controlados, conciliación y evidencia para saber qué ocurrió con cada folio.

No preguntes solo si la solución hace factura electrónica. Pide la lista exacta de tipos de DTE, procesos entrantes y salientes, edición, versión, módulos, terceros y exclusiones.

¿Qué tiene de particular la localización chilena de Odoo?

Odoo publica una localización fiscal para Chile y documenta módulos específicos. La base contable chilena agrega la configuración mínima; la emisión electrónica depende del módulo de facturación; exportaciones de bienes y guía de despacho tienen módulos propios; ecommerce y punto de venta agregan flujos adicionales. Instalar Chile no demuestra que toda esa cadena esté activa.

La documentación advierte que las funciones electrónicas requieren que la empresa haya completado el proceso correspondiente del Sistema de Facturación de Mercado del SII. También pide certificado, datos de resolución, ambiente y CAF. Esto define quién es el emisor: si Odoo usa directamente esas credenciales y folios, Odoo forma parte del sistema emisor y tu equipo debe operarlo como tal.

La versión importa mucho. Odoo mantiene documentación separada para versiones mayores y la localización evoluciona. Community, Enterprise, Odoo Online, Odoo.sh y una instalación propia no tienen el mismo modelo de módulos, despliegue ni soporte. Pide al partner la versión exacta, edición, repositorio de cada módulo y política de actualización. No uses una captura de Odoo 19 para cerrar alcance en Odoo 16.

Odoo además integra datos maestros y comunicación. Los contactos necesitan identificación, tipo de contribuyente, actividad y correo DTE. La empresa configura una casilla de entrada, certificado y datos SII. Por eso una migración desde otro ERP debe tratar limpieza de contactos y correo operativo como parte del proyecto, no como tareas posteriores a la emisión.

En Odoo, pide la lista de módulos instalados con versión y dependencias. El país de la compañía puede instalar una base, pero los flujos especiales siguen siendo decisiones explícitas.

¿Qué salidas existen para Odoo y cuándo conviene cada una?

Odoo puede cubrir mucho dentro de su localización, pero una empresa con personalizaciones antiguas o una edición distinta puede preferir separar la emisión. Compara alternativas sobre tu base real y conserva una regla: solo un componente debe asignar folio y emitir cada tipo de DTE.

Que Odoo sea extensible no convierte el cumplimiento en un ajuste pequeño. Trata cualquier personalización del DTE como software regulatorio con pruebas y mantenimiento propios.

¿Qué flujos de Odoo debes probar por separado?

La factura creada desde Ventas puede tomar datos distintos de una factura manual en Contabilidad. Prueba ambos caminos, impuestos afectos y exentos, anticipos, redondeos, monedas y referencias. El tipo de contribuyente del contacto influye en el documento, así que un dato maestro incompleto puede producir la clase equivocada aunque la orden esté bien.

Boleta no es una factura con cliente genérico. Odoo documenta CAF propios, contacto de consumidor final y un flujo de estado. Para ecommerce, el comprador puede elegir documento y completar campos fiscales; para POS, la experiencia y las devoluciones son distintas. Define qué canal es dueño de la venta y evita que una integración cree otro documento contable por la misma transacción.

Guía de despacho se relaciona con Inventario. Determina qué transferencias o entregas la generan, cuándo se conoce transporte y si luego se referencia desde la factura. Una guía tributaria no debe nacer automáticamente de todo movimiento interno. Incluye anulaciones y entregas parciales en la prueba.

La exportación documentada por Odoo se enfoca en bienes e incorpora información aduanera. Si vendes servicios, emites notas de exportación o tienes operaciones mixtas, pregunta por cada código. No interpretes la presencia de un módulo de exportación como cobertura universal. La misma disciplina aplica a la recepción: configura casilla DTE y separa recepción técnica de validación de vendor bills.

• Factura desde Ventas y factura manual desde Contabilidad.
• Boleta desde ecommerce, punto de venta y registro manual, con consumidor final y cliente identificado.
• Nota de crédito total y parcial con referencia correcta.
• Guía desde entrega parcial, traslado que no corresponde emitir y facturación posterior.
• Exportación de bienes con moneda, aduana y representación impresa.
• Documento recibido por casilla, creación de vendor bill y respuesta correspondiente.

La pregunta que define el proyecto: ¿quién es el emisor ante el SII y dónde viven los folios?

El dueño de la transacción y el emisor tributario pueden ser sistemas distintos. Tu ERP puede conservar la orden, el despacho, la factura comercial y el asiento, mientras otra solución toma responsabilidad por construir, foliar, timbrar, firmar y seguir el DTE. También es posible que una localización del propio ERP haga todo dentro de su ecosistema. Las dos arquitecturas pueden funcionar, pero sus responsabilidades no se pueden mezclar.

La decisión debe quedar escrita para cada tipo de documento. Si dos componentes creen que asignan el folio, aparecen duplicidades o saltos. Si ninguno lo hace, la operación se contabiliza sin DTE. Si un sistema consulta estados y otro reintenta, una respuesta incierta puede terminar en duplicado. Y si la representación impresa se arma antes de conocer el folio definitivo, el PDF deja de ser evidencia confiable.

Por eso la pregunta completa es operacional: qué componente solicita o carga los CAF, cuál reserva el siguiente folio, cuándo se considera consumido, quién firma, quién envía, quién consulta, quién informa el resultado al ERP y quién atiende una caída. La respuesta debe incluir producción, certificación, renovaciones y contingencia.

Si tu partner no puede dibujar el flujo de un folio desde el CAF hasta el estado final, todavía no hay un diseño de facturación electrónica: hay una promesa comercial.

¿Cómo se prueba el proyecto antes de ponerlo en producción?

Una demostración feliz con una factura afecta no cubre el riesgo real. La matriz de pruebas debe cruzar tipos de documento, impuestos, sucursales, monedas, referencias, clientes nacionales y extranjeros, caídas y respuestas. Incluye una nota de crédito que corrija una factura, una guía que luego se facture, una boleta, un folio agotado, un certificado próximo a vencer y un rechazo por dato maestro.

La salida también necesita conciliación. Para una muestra completa, compara transacción del ERP, tipo y folio, XML firmado, envío, resultado del SII, representación impresa y entrega al receptor. Ninguna fila debe quedar solo como enviada. Define además cómo se repara un dato sin reutilizar indebidamente el folio y cómo vuelve el resultado al usuario que originó la venta.

Finalmente prueba la operación sin el consultor presente. El equipo interno debe saber dónde mirar un rechazo, quién renueva el certificado, cómo se cargan nuevos folios, qué canal atiende cada componente y qué información entregar al soporte sin compartir certificados ni datos sensibles. Eso separa una integración demostrable de una operación sostenible.

El criterio de salida no es que el XML se haya generado. Es que negocio, contabilidad y soporte puedan seguir cada documento hasta su desenlace sin reconstruir la historia a mano.