Facturar desde SAP Business One en Chile: lo que debes verificar antes de integrar

¿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 un proyecto con SAP Business One?

SAP documenta una localización específica para Chile. Eso es relevante porque el modelo ya contempla RUT, folios legales y reportes locales. También obliga a formular una pregunta más precisa que tiene factura electrónica: qué funciones exactas están disponibles y configuradas en tu versión, base de datos, plataforma y paquete de localización. Una pantalla chilena no prueba el envío de un DTE al SII.

Business One distingue el número interno del documento y el número de folio legal. Esa separación es útil para contabilidad y trazabilidad, pero se vuelve peligrosa si el proyecto da por hecho que asignar un folio en una factura comercial equivale a consumir un CAF autorizado. El partner debe explicar cómo se relacionan la serie interna, el tipo de documento SII, el rango autorizado y el XML final.

El marco genérico de documentos electrónicos de Business One usa configuraciones, formatos de mapeo y componentes como Electronic Document Service, Service Layer, System Landscape Directory, Electronic File Manager o Integration Framework, según el escenario. La documentación oficial advierte que el comportamiento cambia por localización. Por eso no corresponde copiar una arquitectura de México, Italia o España y asumir que describe Chile.

El proyecto también debe distinguir base SQL Server o SAP HANA, cliente clásico o Web Client, versión 9.3 o 10.0 y nivel de feature package. No porque la obligación tributaria cambie, sino porque cambian componentes disponibles, forma de administrar servicios, soporte del partner y camino de actualización. Pide evidencia en tu mismo paisaje, no capturas de otra instalación.

En Business One, ver el campo Folio Number es el comienzo de la revisión, no el final. Pide seguir un CAF real de certificación hasta un DTE procesado y conciliado.

¿Qué salidas existen para SAP Business One y qué implican?

La salida correcta depende de lo que ya compraste, del nivel de localización instalado y de quién administra Business One. Ninguna opción se evalúa solo por costo de licencia. Compara responsabilidad tributaria, cobertura documental, dependencia de infraestructura, actualización, soporte y capacidad de devolver estados al documento de origen.

No hay una salida universalmente mejor. La salida defendible es la que deja un solo emisor por tipo de DTE y una ruta clara para que Business One conozca el resultado.

¿Qué datos de SAP Business One suelen definir el alcance?

Business One organiza ventas alrededor de socios de negocio, documentos de marketing, artículos o servicios, impuestos, bodegas, sucursales y series. El DTE chileno reorganiza parte de esos datos según tipo tributario. El taller de mapeo debe revisar valores reales, no una lista genérica: RUT y razón social, giro, comuna, dirección de origen, indicadores de servicio, exenciones, referencias y transporte.

Las notas merecen un caso propio. Una nota de crédito o débito no es solo un documento con monto negativo o positivo: debe referenciar el documento correcto y expresar qué corrige. En Business One, la relación comercial y la referencia tributaria deben permanecer alineadas aunque el flujo haya nacido desde devolución, cancelación o ajuste manual.

Con sucursales y bodegas, pregunta qué dato determina la dirección de origen y si los folios se controlan centralmente o por establecimiento. Business One puede guardar varias ubicaciones, pero el diseño debe decir cuál alimenta el DTE. Lo mismo vale para Crystal Reports u otros layouts: no dejes que la impresión decida un dato que ya debió quedar cerrado en la emisión.

Finalmente registra quién es dueño de los add-ons. Muchos paisajes de Business One acumulan extensiones, consultas y automatizaciones. Antes de intervenir, inventaría cuáles crean documentos, asignan números, imprimen o escriben campos legales. Dos extensiones actuando sobre el mismo evento pueden producir una falla que no aparece en una demostración limpia.

• Lista los tipos de documento de ventas que originarán cada TipoDTE y las excepciones manuales.
• Separa serie interna, prefijo visible y folio autorizado por el SII.
• Identifica el componente que guarda CAF, certificado y estado, sin compartir esas credenciales en documentos de proyecto.
• Define cómo vuelven a Business One folio, aceptación, observación y rechazo.
• Revisa add-ons que actúan al agregar, imprimir, cancelar o copiar documentos.

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.