Integrar IA con SAP Business One sin tocar el núcleo

Integrar IA con SAP Business One sin tocar el núcleo significa construir una capa aparte que lee los datos de SAP con permisos limitados y escribe sólo por la interfaz oficial, Service Layer. La contabilidad, el timbrado y el inventario valuado se quedan en SAP. La IA propone; una persona aprueba; SAP valida y guarda.

Son las 8:10 de un miércoles. El director de operaciones de una distribuidora busca en SAP Business One el pedido que un cliente mandó ayer a las 5 de la tarde. Entró hoy a las 7:40. En medio hubo un correo, un Excel, una llamada para confirmar existencias y alguien que lo tecleó al llegar.

SAP no falló. Hizo lo que tenía que hacer con el dato que le llegó. El problema es todo lo que pasa antes de que el dato entre.

Este texto es para quien dirige operaciones, finanzas o sistemas y quiere ponerle IA a SAP Business One sin arriesgar el ERP. Los datos técnicos vienen de la documentación pública de SAP, con enlace al final.

Significa que SAP sigue siendo el sistema de registro y que nada de lo que se construye encima modifica su base de datos por fuera de las reglas de SAP. Si mañana apaga la capa, SAP funciona exactamente igual que hoy. Ésa es la prueba de que el núcleo no se tocó.

«Núcleo» quiere decir tres cosas: la base de datos de la compañía, la lógica con la que SAP calcula impuestos y contabiliza, y los objetos de negocio tal como SAP los define. Ninguna se altera.

Lo que se construye es una capa operativa encima del ERP que usted ya tiene: un sistema aparte, con su propia base de datos, donde vive la operación del día y donde trabaja la IA. Se conecta con SAP por dos caminos y sólo por esos dos:

• Para leer: con un usuario que sólo puede consultar, con las vistas que su área de sistemas autorice o con las consultas que la propia Service Layer permite.
• Para escribir: únicamente por Service Layer, la interfaz que SAP publica para que otros sistemas trabajen con sus objetos.

No se migra la contabilidad. No se cambia de ERP. Lo que cambia es que la operación diaria deja de vivir en correos, Excel y WhatsApp, y el dato llega a SAP una sola vez, completo y a tiempo.

¿Por qué no conviene escribir directo en las tablas de SAP?

Porque escribir directo en las tablas se salta la lógica de negocio de SAP. La guía oficial de Service Layer lo describe así: las peticiones pasan por el mismo componente que usa la DI API para acceder a los objetos de SAP, y el trabajo de fondo, como el cálculo de impuestos y la contabilización, lo hace un servidor de lógica de negocio llamado OBServer.

Dicho en corto: lo que entra por Service Layer, SAP lo trata como suyo. Lo que entra por un INSERT directo a la base puede quedar sin los cálculos, las validaciones o las autorizaciones que SAP le habría aplicado. Ése es nuestro criterio, no una frase de SAP.

Y el error no aparece el día que se escribe: aparece en el cierre o en la auditoría, cuando nadie sabe si la culpa es de SAP, del add-on o de la conexión.

Además está el soporte. Qué cubre y qué no cubre su contrato cuando alguien modifica la base por fuera lo define SAP con su partner, no nosotros. Pregúntelo por escrito antes de aceptar cualquier propuesta que escriba directo en las tablas, incluida la de un proveedor que le diga que «así es más rápido».

Por eso la regla de diseño cabe en una línea: leer se puede hacer de varias formas; escribir, sólo por la puerta oficial.

¿Por dónde se lee y por dónde se escribe en SAP Business One?

Se lee por la vía que su instalación permita y su área de sistemas autorice; se escribe por Service Layer. La guía de SAP describe Service Layer como una API de extensión para consumir los datos y servicios de SAP Business One, construida sobre HTTP y OData. Corre en un servidor web propio y se instala junto a la base de datos o en máquinas aparte.

Estas son las vías que aparecen en la documentación pública de SAP y cómo las usamos:

Dos detalles de la guía. Para trabajar con Service Layer hay que iniciar sesión con un usuario de la compañía, así que cada acción queda a nombre de alguien. Y en vistas y consultas, SAP sólo deja pasar a los usuarios con la autorización dada en su propia ventana de autorizaciones.

Qué vía de lectura le conviene no lo suponemos a distancia: se revisa con su área de sistemas.

¿Qué hace la IA en esa capa, y qué todavía no?

La IA trabaja con los datos que SAP ya tiene para contestar, proponer y avisar; no decide ni contabiliza. Todo lo que propone pasa por una persona antes de convertirse en un documento definitivo de SAP.

Contestarle al cliente con la existencia y el precio reales

Su cliente pregunta a las 9 de la noche si hay 300 piezas de un artículo y cuánto le salen. Hoy esa pregunta espera al día siguiente. Con un asistente en su página web conectado a la capa, la respuesta sale con la existencia por almacén y la lista de precios que ya tiene en SAP.

Si el cliente quiere seguir con un vendedor, el asistente lo pasa al WhatsApp de su empresa con un botón y el mensaje ya escrito.

El asistente ya existe; lo que se construye a la medida es la conexión con su SAP. Para ver cómo atiende, pruebe la demo del asistente para almacenes o la del asistente para fábricas, sin dejar sus datos. Los niveles del asistente, incluido el que contesta con la existencia real y el que se conecta con su ERP, están en la página de planes.

Proponer el documento como borrador, no como hecho

La cotización que el cliente acepta, o el pedido que arma un vendedor en la capa, no entra a SAP como pedido definitivo. Entra como borrador: la guía de Service Layer incluye los borradores (Drafts) entre los objetos que expone. Quien tiene la autoridad lo revisa en SAP o en su pantalla de la capa, lo corrige si hace falta y lo convierte en documento.

Si SAP rechaza el documento, la capa recibe el motivo y lo muestra a la persona responsable. No reintenta a ciegas ni busca otra ruta para meterlo.

Avisar lo que nadie está viendo

Un pedido comprometido contra un almacén sin existencia, una entrega que lleva días sin salir, un cliente que rebasa su crédito. La capa cruza lo que SAP ya sabe y la IA redacta el aviso para quien tiene que actuar. El dato estaba en SAP; faltaba que alguien lo viera a tiempo.

Lo que todavía no hacemos

Que la IA lea los PDF y los Excel de órdenes de compra de sus clientes y arme el pedido sola: hoy no es un producto que tengamos liberado, y no se lo vamos a vender como si lo fuera. Si su caso lo necesita, se evalúa en el diagnóstico como proyecto, con su riesgo dicho en voz alta.

Tampoco contabiliza, no timbra y no aprueba nada.

¿Qué se queda en SAP y qué vive en la capa operativa?

En SAP se queda todo lo que tiene efecto contable o fiscal; en la capa vive lo que pasa antes de que ese efecto exista. La frontera se dibuja en el diagnóstico, pero en la mayoría de los casos se ve así:

La bitácora registra qué preguntó el cliente, qué propuso la IA, qué cambió la persona y qué respondió SAP. Cuando su auditor pregunte de dónde salió un documento, la respuesta está ahí y no en la memoria de alguien.

Lo que entregamos en un proyecto a la medida es suyo: el código fuente, la base de datos de la capa, los accesos y la documentación. En nuestros contratos la cesión se pacta con carácter perpetuo e irrevocable, y así lo tenemos escrito en nuestros términos. No es un consejo legal: su abogado debe revisarlo.

¿Qué tiene que preguntarle a su partner de SAP antes de arrancar?

Siete preguntas, por escrito, antes de firmar con cualquier proveedor, nosotros incluidos.

1. ¿Qué versión y qué parche tenemos, y sobre qué motor corre? SQL Server o SAP HANA cambia qué vías de lectura existen, como muestra la tabla de arriba.
2. ¿Tenemos Service Layer instalado y funcionando? Si no, ¿qué implica habilitarlo en nuestra instalación?
3. ¿Qué usuarios y qué licencias necesita una conexión externa? Eso lo define su contrato con SAP. No lo vamos a adivinar ni a opinar sobre él.
4. ¿Qué add-ons tenemos y cuáles validan documentos al guardarse? Una validación propia puede rechazar un documento que la capa considera correcto, y conviene saberlo antes.
5. ¿Qué dice nuestro soporte sobre conexiones externas y sobre modificaciones directas a la base?
6. ¿Cuándo es la próxima actualización? La capa debe entrar en el plan de pruebas de cada actualización, igual que cualquier add-on.
7. ¿Quién da de alta los campos de usuario que hagan falta? Lo correcto es que los dé de alta su partner con las herramientas estándar de SAP.

Le proponemos presentarle el diseño a su partner antes de arrancar, en la misma mesa. La capa no compite con él: no actualizamos versiones, no tocamos add-ons, no configuramos la localización mexicana ni el timbrado.

¿Cómo se arranca sin poner en riesgo el cierre de mes?

Se arranca leyendo, no escribiendo, y en un solo proceso. La escritura llega cuando la lectura ya demostró que los datos cuadran.

1. Diagnóstico operativo: dos semanas

La puerta de entrada es el Diagnóstico operativo. En dos semanas se mapea qué procesos viven hoy fuera de SAP, cuánto trabajo manual cuestan con los números de su empresa y por dónde conviene empezar. Con sistemas se revisan versión, motor y vía de lectura. Sale un plan por fases con alcance cerrado. Si el proyecto arranca en los 30 días siguientes, el diagnóstico se acredita completo al proyecto.

2. Primera fase: sólo lectura

Un proceso, una pantalla, cero escritura. Por ejemplo, las existencias comprometidas que hoy se arman a mano cada mañana. Si los números no cuadran con SAP, se corrige antes de seguir. Es la fase más aburrida y la que más protege.

3. Segunda fase: borradores

La capa empieza a escribir, pero sólo borradores. Una persona los revisa y los convierte en documento dentro de SAP. Así se mide, con documentos reales, cuántos salen bien a la primera y cuántos necesitan corrección.

4. Tercera fase: lo que ya demostró que funciona

Sólo los flujos que salieron bien pasan a una aprobación más corta. Los que siguen fallando se quedan como borradores o vuelven a ser manuales, y ésa también es una buena decisión. Nada de esto se hace en semana de cierre: el calendario se pacta con finanzas.

Si quiere ver sistemas de este tipo antes de hablar con nadie, hay aplicaciones demo navegables y casos publicados en el sitio. El detalle está en la página de la capa operativa para SAP Business One, Intelisis, Aspel y Contpaq.

¿Cuándo no conviene construir encima de SAP Business One?

No conviene cuando el dolor está dentro de SAP y no antes de él. Construir encima resuelve la operación que vive fuera del ERP; no arregla un ERP mal configurado. Cuatro casos en los que le diríamos que no, o que todavía no:

• El problema es contable. Si las pólizas salen mal o el inventario contable no cuadra por cómo está configurado SAP, eso lo arregla su partner, no una capa.
• El maestro de artículos está sucio. Si el mismo artículo existe con tres códigos, la IA va a marcar la ambigüedad una y otra vez, pero no la va a resolver. Limpiar datos maestros es un trabajo aparte, y conviene hacerlo primero.
• Nadie puede ser dueño del proceso. Sin una persona con nombre que apruebe borradores y decida excepciones, la capa se vuelve otro sistema que nadie revisa.
• La migración de ERP ya está en marcha. Una capa bien hecha sobrevive al cambio, pero conviene esperar a que termine.

Si todavía está en la duda entre cambiar de ERP o construir encima, lea cómo decide un director de operaciones entre migrar el ERP o poner una capa encima: ahí están los seis criterios y la aritmética del caso, con supuestos a la vista.

Si lo que necesita es otra cosa, como un CRM o un agente de IA a la medida, la puerta es la misma; el catálogo está en servicios.

Vuelva a la escena del principio. El pedido que llegó a las 5 de la tarde podría estar en SAP como borrador a las 5:10, con la existencia confirmada y esperando la firma de quien decide. SAP seguiría siendo el mismo. Lo que cambia es todo lo que pasa antes. Si quiere saber cuánto le cuesta hoy ese «antes», empiece por el Diagnóstico operativo de la capa operativa.

Preguntas frecuentes

¿Funciona con SAP Business One sobre HANA y sobre SQL Server?

Sí, pero no igual. Service Layer existe para las dos versiones. Algunas vías de lectura cambian: las vistas SQL expuestas aplican sólo a SQL Server y el Semantic Layer sólo a HANA, según la guía de SAP. Qué vía conviene se confirma en el diagnóstico con su área de sistemas.

¿Pierdo el soporte de SAP o de mi partner por conectar una capa?

La capa evita justo la práctica más riesgosa, que es escribir directo en las tablas. Todo documento entra por Service Layer y pasa por la lógica de SAP. Aun así, las condiciones de soporte las define su contrato. Lo correcto es presentarle el diseño a su partner antes de arrancar, y lo hacemos con usted.

¿Qué pasa cuando actualice la versión de SAP Business One?

La escritura depende de la interfaz publicada por SAP y no de estructuras internas. Las lecturas sí dependen de tablas y campos, así que deben volver a probarse. Recomendamos meter la capa en el plan de pruebas de cada actualización, como cualquier add-on.

¿Y si la IA se equivoca?

Va a pasar. Por eso nada entra a SAP como documento definitivo sin que una persona lo apruebe, y lo que no empata con su catálogo se marca en vez de adivinarse. La bitácora guarda qué propuso la IA y qué corrigió la persona, y con eso se decide qué flujos conviene acortar y cuáles no.

¿La IA puede leer los PDF que mandan mis clientes?

Hoy no es un producto que tengamos liberado. Si su operación lo necesita, se evalúa en el diagnóstico como proyecto a la medida, con sus límites dichos antes de empezar. No se lo prometemos en un post.

De dónde sale cada número de este post

• Todo dato técnico de SAP (Service Layer sobre HTTP y OData; el mismo componente de acceso que la DI API; la lógica de impuestos y contabilización en OBServer; consultas SQL desde la versión 10.0 FP 2011 con lista de tablas permitidas; vistas SQL sólo en SQL Server; Semantic Layer sólo en HANA; borradores entre los objetos expuestos; inicio de sesión con usuario de la compañía): SAP, «Working with SAP Business One Service Layer», guía pública, versión 1.29 del 27 de julio de 2026. Consultada el 6 de octubre de 2026.
• Diagnóstico operativo de dos semanas, acreditable al proyecto si arranca en 30 días: condiciones publicadas por iAmanos en su página de precios, vigentes en octubre de 2026.
• Siete preguntas, cuatro fases y cuatro casos en los que no conviene: criterio de iAmanos, no un estudio.
• Cesión perpetua e irrevocable del código: términos publicados en iamanos.com, cotejados el 20 de septiembre de 2026.
• Sin porcentajes de ahorro ni casos con nombre, a propósito: eso se mide en el diagnóstico con sus números.