evaluación para SAP S/4HANA en Chile
Facturar desde SAP S/4HANA en Chile: alcance real de Document and Reporting Compliance
SAP documenta procesos chilenos en Document and Reporting Compliance, pero el alcance depende de tu edición, release, activación, integración y tipos de documento. El eDocument Cockpit no resuelve por sí solo quién custodia los folios ni quién responde por el envío completo. Cierra esas decisiones antes del blueprint.
Revisado el · 2691 palabras
Esta guía no afirma que Simplo tenga un conector para SAP S/4HANA ni una relación con SAP. Sirve para separar lo que ofrece tu paisaje SAP de lo que todavía necesita un responsable tributario y operativo.
¿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.
| Exigencia | Qué significa en la operación |
|---|---|
| Certificado digital y firmantes autorizados | La empresa debe estar habilitada y trabajar con un certificado vigente. El proyecto necesita responsables para instalarlo, renovarlo, revocarlo y decidir quién puede usarlo. La firma del documento completo se genera con ese certificado y no se reemplaza con una aprobación interna del ERP. |
| CAF y folios por tipo de DTE | El SII autoriza rangos separados para factura, factura exenta, guía, notas, boleta y documentos de exportación. Cada rango incluye el Código de Autorización de Folios. El número interno de la transacción no sustituye el folio tributario y una misma secuencia no se comparte entre tipos. |
| Timbre electrónico y firma del DTE | Hay dos operaciones distintas que suelen confundirse. El timbre usa los datos y la llave del CAF; después el documento completo se firma con el certificado digital vigente. Que el PDF tenga una imagen o que la factura esté contabilizada no demuestra que ambas firmas sean válidas. |
| XML en el formato exacto | El SII publica esquemas, orden de campos, largos, dominios y reglas condicionales. No basta exportar cualquier XML. El tipo de DTE determina qué encabezado, detalle, totales, referencias y datos especiales deben aparecer, y una diferencia mínima puede detener el documento antes de revisar el negocio. |
| Respuestas y estados hasta el documento | La recepción técnica de un archivo no equivale a la aceptación de cada DTE. Debes conservar el identificador de seguimiento, consultar el procesamiento y aterrizar el resultado por documento. Si el ERP solo muestra enviado, el equipo todavía no sabe si la factura quedó aceptada, observada o rechazada. |
| Intercambio con la contraparte | Además del envío al SII, el emisor debe entregar el DTE al receptor y poder recibir respuestas en la casilla registrada. La recepción del sobre, la recepción de cada documento y la decisión comercial son eventos diferentes. El proyecto necesita correo operativo, responsables y trazabilidad. |
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é cambia cuando el ERP es SAP S/4HANA?
En S/4HANA la conversación no debe reducirse a si SAP soporta Chile. SAP publica Document and Reporting Compliance para crear, procesar y monitorear documentos electrónicos, y su documentación incluye escenarios chilenos. La pregunta de compra es qué proceso está disponible y activado en tu producto concreto: Cloud Public Edition, Cloud Private Edition u on-premise, con su release y nivel de soporte.
La transacción de origen puede nacer en Sales and Distribution o en Finance y transformarse en un eDocument. Esa transformación introduce un segundo ciclo de vida. Un billing document contabilizado puede tener un eDocument creado, enviado, rechazado o pendiente. El diseño debe decidir qué estado ve ventas, qué estado bloquea despacho o cobranza y qué equipo resuelve errores de contenido frente a errores de integración.
SAP también documenta que la comunicación chilena requiere escenarios de integración y paquetes de SAP Document and Reporting Compliance: Electronic Documents for Chile. Según el paisaje, intervienen SAP Integration Suite o SAP Cloud Integration y un sistema externo o proveedor de servicio. Tener el cockpit visible no demuestra que esa comunicación esté desplegada, autenticada ni operada.
Las ampliaciones son otro punto propio de S/4HANA. El XML puede tomar datos de múltiples objetos, mapeos y extensiones. Si hoy un campo chileno vive en una ampliación, debes comprobar cómo llega al eDocument y qué ocurre durante upgrades. Un desarrollo que modifica el XML sin gobierno puede dejar de funcionar aunque la factura comercial siga contabilizando normalmente.
| Capa de S/4HANA | Qué debes validar para Chile |
|---|---|
| Documento fuente | Qué billing document o asiento origina cada TipoDTE y en qué momento se crea el eDocument. |
| eDocument | Qué proceso chileno, tipo, estado y acción se usa para factura, nota, guía y boleta. |
| Mapeo XML | Qué valores estándar o ampliados llenan giro, indicadores, referencias, transporte, moneda y exportación. |
| Integración | Qué paquete, tenant, runtime y sistema externo realizan comunicación y firma, y quién monitorea cada salto. |
| Estado de negocio | Cómo aceptación, observación o rechazo vuelven al documento fuente y a los equipos que cobran o despachan. |
| Archivo y evidencia | Dónde quedan XML firmado, respuesta, representación impresa, log funcional y relación con el documento SAP. |
En S/4HANA no basta con marcar el scope item. Exige una prueba que cruce documento fuente, eDocument, integración, SII y retorno de estado.
¿Qué salidas existen para S/4HANA y cuáles son sus consecuencias?
La decisión suele aparecer durante un programa mayor de implementación o migración. Conviene separarla del resto del template global: la salida tributaria chilena tiene dependencias, responsables y fechas propias. Evalúa cada alternativa con el mismo set de documentos y el mismo volumen para que la comparación no favorezca una demo más vistosa.
| Salida posible | Consecuencia operativa |
|---|---|
| Activar la capacidad chilena de SAP Document and Reporting Compliance | Mantiene eDocuments y monitoreo cerca del core, pero requiere confirmar licencia, release, scope, integración, firma, proveedor externo y documentos soportados. También agrega operación de Integration Suite y gobierno de contenidos de SAP. |
| Usar una solución del implementador o un proveedor del ecosistema SAP | Puede acelerar mapeos y soporte funcional, pero debes separar qué es estándar SAP, qué es extensión del partner y qué ejecuta un tercero. Pide responsables, propiedad de desarrollos, compatibilidad con upgrades y evidencia del alcance chileno. |
| Mantener S/4HANA como sistema de registro y usar un emisor externo | Reduce la responsabilidad tributaria dentro del core, pero exige un contrato claro de datos y estados a nivel de proceso, no necesariamente técnico en la etapa comercial. Debes definir conciliación, contingencia y cómo evitar emisiones paralelas. |
| Construir una solución propia alrededor de eDocuments o documentos fuente | Ofrece control y puede ajustarse al template global, pero hereda mantenimiento de formatos SII, certificados, CAF, estados, intercambio y extensiones. También debe sobrevivir upgrades de S/4HANA y de la capa de integración. |
Si una propuesta dice estándar, pide que marque cada pieza como estándar SAP, configuración, extensión, contenido de integración o servicio de un tercero. Esa tabla evita sorpresas después del diseño.
¿Qué debe quedar en el blueprint de S/4HANA?
El blueprint debe empezar por una matriz de procesos, no por una lista de interfaces. Para cada sociedad y centro relevante, identifica el proceso comercial, documento fuente, tipo de DTE, momento de emisión, responsable de folios, tratamiento de rechazo y vínculo con contabilidad. Incluye ventas de servicios, anticipos, notas, entregas gratuitas, exportaciones y casos intercompany si existen.
Luego define los datos maestros chilenos. Razón social, RUT, giro, comuna, actividad, dirección de origen, datos del receptor y códigos tributarios no siempre tienen un campo estándar único en el template global. Decide el sistema maestro, validaciones de entrada y reglas para valores faltantes. No escondas la brecha en una transformación que nadie funcional puede revisar.
La operación del cockpit necesita roles. Un error de mapeo corresponde al equipo funcional; una caída de integración, a plataforma; un certificado vencido, al custodio definido; un folio agotado, al administrador tributario; una venta mal creada, al proceso de origen. Si todos ven una cola pero nadie tiene SLA interno, el monitoreo solo centraliza el atasco.
Por último, alinea transporte y releases. Document and Reporting Compliance, Integration Suite, notas SAP, certificados y extensiones pueden tener calendarios diferentes. El plan de paso a producción debe congelar versiones compatibles, repetir certificación cuando corresponda y dejar un procedimiento de rollback que no reutilice folios ni pierda estados ya recibidos.
- Documenta sociedad, proceso, documento fuente y TipoDTE en una sola matriz.
- Asigna dueño funcional y técnico a cada estado y error del eDocument.
- Separa contenido estándar, mapeo, BAdI o extensión y transformación externa.
- Incluye monitoreo de Integration Suite además del eDocument Cockpit.
- Define qué evidencia se conserva y cómo se consulta desde el documento fuente.
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.
| Decisión | Consecuencia que debe quedar cerrada |
|---|---|
| Sistema emisor | Un solo responsable construye el DTE y responde por su estado tributario. El ERP no debe emitir en paralelo el mismo tipo y rango. |
| Custodia de folios | Los CAF se cargan y consumen en un lugar definido, con alertas y trazabilidad. Los números internos del ERP se relacionan con el folio, pero no se confunden con él. |
| Momento de contabilización | Se define si el asiento ocurre antes, durante o después de la aceptación y qué se hace con un rechazo. La conciliación no puede depender de revisar correos a mano. |
| Dueño de la contingencia | Alguien debe distinguir caída técnica, rechazo de esquema, dato maestro incorrecto, folio agotado y certificado vencido. Cada caso requiere una acción distinta. |
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.
¿Qué preguntarle a tu partner de SAP S/4HANA antes de firmar?
Copia este checklist en la minuta de evaluación. Pide respuestas por escrito y evidencia para los puntos que cambian precio, plazo o responsabilidad.
- ¿La propuesta cubre S/4HANA Cloud Public, Private u on-premise y qué release exacto está en alcance?
- ¿Qué licencia y activación de SAP Document and Reporting Compliance necesita Chile en nuestro paisaje?
- ¿Qué documento fuente crea el eDocument para cada proceso y en qué momento?
- ¿Qué tipos de DTE chilenos están soportados y probados uno por uno, incluidas boleta, guía, notas y exportación?
- ¿Qué paquete de Integration Suite o Cloud Integration se despliega y quién lo opera?
- ¿La comunicación termina directamente en el SII o interviene un proveedor de servicio? ¿Quién responde por cada tramo?
- ¿Dónde viven CAF, folios y certificado, y qué componente aplica cada firma?
- ¿Qué mapeos estándar y extensiones llenan los campos chilenos del XML?
- ¿Cómo vuelve el estado final al billing document o asiento y qué proceso queda bloqueado ante rechazo?
- ¿Cómo se procesan documentos recibidos e intercambio con clientes, aparte del envío al SII?
- ¿Qué notas SAP, dependencias y pruebas se repiten en cada upgrade o transporte?
- ¿Puedes demostrar factura, nota, guía o boleta, rechazo, consulta de estado, contingencia y conciliación en un ambiente equivalente al nuestro?
Preguntas frecuentes
¿SAP S/4HANA soporta documentos electrónicos para Chile?
SAP publica procesos chilenos dentro de Document and Reporting Compliance, incluidos escenarios de eDocument y eBoleta. Debes verificar disponibilidad y alcance en tu edición, release, licencias y configuración. La existencia de documentación general no prueba que tu paisaje esté listo para emitir.
¿El eDocument Cockpit se conecta solo con el SII?
No conviene asumirlo. SAP documenta escenarios de integración para Chile mediante SAP Integration Suite o Cloud Integration y comunicación con sistemas externos o proveedores. El proyecto debe identificar la ruta completa, la firma y quién monitorea cada tramo.
¿Simplo tiene un conector para SAP S/4HANA?
Esta página no promete un conector, contenido certificado por SAP ni relación comercial con SAP. Cuéntanos tu edición, release, documentos y arquitectura actual. Con eso se puede evaluar una salida sin vender una integración que todavía no está demostrada.
¿Qué diferencia hay entre el documento SAP y el DTE?
El documento fuente registra la operación en ventas o finanzas. El eDocument representa el ciclo de cumplimiento y el DTE es el documento tributario firmado y foliado que procesa el SII. Deben estar relacionados, pero sus estados no son equivalentes.
Fuentes oficiales
Revisa la documentación de tu versión y contrato. Los vendors pueden cambiar alcance, nombres y requisitos entre releases.