Facturar desde Dynamics 365 Business Central en Chile: localización de partner y DTE

¿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é significa que Chile use una localización liderada por partners?

Microsoft distingue localizaciones entregadas por Microsoft y localizaciones construidas por partners. En su tabla de disponibilidad, Chile figura disponible bajo el modelo Partner y sobre la base W1. La consecuencia práctica es simple: no existe una respuesta única basada solo en el nombre Business Central. La capacidad depende de la app de localización y, a veces, de varias extensiones publicadas por un proveedor.

El partner que implementa el ERP puede vender una localización propia, una app de Marketplace de otro editor o una integración externa. Pide nombre legal del editor, App ID, versión, países objetivo y contrato de soporte. La etiqueta para Chile en una propuesta no indica quién mantiene los cambios del SII ni qué pasará cuando Microsoft actualice la plataforma.

Business Central separa documentos de venta, documentos registrados, movimientos contables y extensiones que reaccionan a eventos. Una solución DTE puede actuar antes o después de registrar la factura. Ese momento define qué ocurre si el SII rechaza: si la contabilidad ya quedó registrada, necesitas corrección y conciliación; si se bloquea antes, debes evaluar continuidad de venta y despacho.

En SaaS, Microsoft actualiza Business Central con una cadencia que obliga a probar extensiones. En on-premises, el control de versión es mayor pero la deuda de actualización puede crecer. En ambos casos, la localización chilena y la emisión deben declarar sus versiones soportadas, política de compatibilidad y ambiente sandbox. No aceptes una extensión que solo funciona en la versión de la demo.

En Business Central, preguntar quién publica la localización es tan importante como preguntar qué hace. Ese editor será parte de tu operación tributaria.

¿Qué salidas existen para Business Central y qué riesgos trasladan?

Compara alternativas con el mismo proceso: desde sales order o invoice hasta el estado final del DTE. Una app puede verse más integrada porque agrega campos en Business Central, mientras un emisor externo puede concentrar mejor la responsabilidad tributaria. La decisión correcta depende de trazabilidad, soporte y continuidad, no de cuántas pantallas ocurren dentro del ERP.

Una app publicada en Marketplace puede tener validaciones técnicas de Microsoft, pero eso no sustituye tu verificación del alcance tributario chileno ni convierte a Microsoft en soporte de la solución del partner.

¿Cómo se aterriza el DTE en el modelo operativo de Business Central?

Parte por decidir qué documento dispara la emisión. Si el DTE nace al registrar una sales invoice, define qué pasa con facturas creadas desde órdenes, contratos, proyectos, service management o integraciones. Si nace desde una cola posterior, define ventanas de procesamiento y visibilidad. Las rutas no utilizadas en la demo suelen ser las que generan documentos sin folio al mes siguiente.

Luego separa dimensiones contables de datos tributarios. Location Code, Responsibility Center, series y compañías pueden ayudar a determinar sucursal, pero no asumas equivalencias. El partner debe mapear la entidad emisora, dirección de origen, comuna, giro y actividad con reglas explícitas. En multi-company, cada empresa chilena necesita su propio certificado, folios y autorización.

Las notas de crédito registradas deben conservar la referencia tributaria al DTE original. Revisa devoluciones, correctivas, cancelaciones y reaperturas. Business Central puede relacionar documentos operativos, pero la app debe producir las referencias que el SII exige y bloquear una corrección incoherente. Lo mismo vale para shipment y guía de despacho.

Finalmente, diseña telemetría y soporte. Business Central SaaS ofrece señales de ejecución de extensiones, pero negocio necesita una vista comprensible: pendiente, aceptado, observado, rechazado y acción requerida. El editor de la app, tu partner funcional y el emisor pueden ser tres mesas distintas. El contrato debe indicar quién toma el caso primero y cómo escala sin dejar al usuario rebotando.

• Inventaría todas las rutas que crean posted sales invoices y credit memos.
• Documenta dependencias entre apps y permisos por rol.
• Prueba multi-company, series, locations y cierres contables.
• Exige una política de compatibilidad con las actualizaciones mayores de Business Central.
• Define cómo exportar datos y continuar operando si cambias la app de localización.

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.