Conectar SAP sin tocarlo: cómo integrar su tienda, su banco y sus socios sin dejar desarrollos que estorben

En 1 minuto

Conectar algo con SAP obliga a dos decisiones: por qué mecanismo se entra y dónde vive la lógica de cada canal. El atajo —un programa propio, acoplado a las entrañas de SAP— se siente más rápido y se paga en la siguiente actualización. SAP lo dice con sus palabras: lo que se apoya en sus interfaces liberadas es lo que mejor aguanta una actualización. Este artículo explica, en lenguaje de comité, qué puertas hay, cuándo conviene cada una y qué preguntar antes de aprobar la próxima integración.

Imagine una empresa mediana que lleva su contabilidad, su inventario y su facturación en SAP. Es ficticia, pero se parece a muchas. Un día llegan tres pedidos al área de tecnología, casi al mismo tiempo:

• Comercial quiere que la tienda en línea mande cada pedido a SAP y consulte el precio y la existencia.
• Finanzas quiere que el estado de cuenta del banco se concilie contra lo que SAP tiene por cobrar.
• Ventas quiere que un socio distribuidor pueda mandar sus pedidos desde su propio sistema.

Las tres son razonables. Y las tres tienen la misma pregunta escondida: ¿dónde va a vivir la conexión?

La respuesta rápida suele ser «dentro de SAP, como se pueda»: un programa a la medida que lea el archivo del banco, una tabla nueva para los pedidos de la tienda, un ajuste a un proceso estándar para el socio. Funciona, y funciona pronto. El costo no aparece el día que se entrega. Aparece el día que hay que actualizar SAP, y alguien descubre que cada uno de esos desarrollos hay que revisarlo, probarlo y, a veces, rehacerlo.

Este artículo es para quien dirige tecnología, finanzas u operación en una empresa que tiene SAP y necesita conectarle más cosas; el razonamiento sirve también para otros ERP de fabricante. Sostiene una idea: la conexión se hace por las puertas que el fabricante soporta, y lo que es de cada canal, por regla general, vive afuera del ERP. No es solo una preferencia de arquitectura: SAP recomienda separar lo agregado y apoyarse en sus interfaces liberadas para reducir la deuda técnica y facilitar las actualizaciones [1][2].

No es un artículo sobre si la conexión debe ser en línea o asíncrona; eso está en ¿En línea o asíncrono?. Aquí la pregunta es otra: por qué puerta se entra a SAP, y qué se queda afuera.

El costo se cobra en la siguiente actualización

SAP lleva años diciéndolo a sus clientes con un nombre: núcleo limpio (clean core). La idea es separar lo que cada empresa le agrega de lo que SAP entrega, para que una actualización no rompa lo agregado y lo agregado no rompa la actualización. Una presentación pública de consultores de SAP lo resume así: las extensiones propias no deben romper una actualización, ni las actualizaciones una extensión, y para eso se separan usando las interfaces liberadas de SAP; y las extensiones conviene evitarlas cuando se pueda (traducción libre) [2].

Su material de formación es todavía más claro con el camino viejo. Describe la forma tradicional de programar dentro de SAP como código «muy acoplado al sistema», que «podía ser problemático en una actualización» y que por eso se recomendaba «como último recurso» (traducción libre) [1]. Hoy, para SAP S/4HANA, SAP clasifica las extensiones en cuatro niveles, de la A a la D: el nivel A usa interfaces y puntos de extensión liberados y es el que da la mayor estabilidad al actualizar, sea afuera de SAP o dentro de él con las herramientas que SAP admite; y una extensión se califica por la tecnología de menor nivel que use [1].

Dicho en lenguaje de comité: cada desarrollo que se acopla a las entrañas de SAP es una deuda que se paga, con intereses, en las actualizaciones. No todos se pueden evitar. Pero cada uno debería tener una razón escrita. Y aun con todo en orden, cada actualización se prueba: lo que cambia es cuánto hay que revisar.

Las puertas que SAP ya tiene

SAP no está cerrado. Tiene varios mecanismos de integración —aquí les llamamos puertas—, y cada uno sirve para algo distinto. No hace falta que el comité sepa cómo funcionan por dentro; sí conviene que sepa que existen y que pregunte por cuál se va a entrar. Cuáles están disponibles, y para qué operaciones, depende del producto y de la versión de SAP que usted tenga.

Y una puerta que no está en la lista: escribir directo en las tablas de SAP. Es tentadora porque parece la más corta, y estorba porque puede saltarse los controles con los que el proceso de negocio de SAP cuida su propia información.

La página técnica de Hábil MDW lo dice en una frase: en los ERP priorizamos las interfaces que el fabricante soporta —en SAP, por ejemplo, JCo, OData, IDoc o REST—, para no dejarle desarrollos que estorben al actualizarlo.

Qué se queda en SAP y qué se queda afuera

Entrar por la puerta correcta es la mitad. La otra mitad es decidir qué lógica vive en SAP y cuál vive afuera. Una regla útil:

• En SAP se queda lo que SAP hace bien y lo que la ley o la auditoría le piden a SAP: la contabilidad, el inventario oficial, la facturación, el cliente y el material como los conoce el ERP.
• Afuera se queda lo que es de cada canal o de cada socio: el formato del archivo de cada banco, las reglas de la tienda en línea, la traducción de lo que manda cada distribuidor, los reintentos, el rastro de qué se mandó y qué contestó SAP.

Esos reintentos y ese rastro son también los que sostienen la venta el día que el ERP no contesta; eso está en El ERP se cayó el sábado.

SAP tiene un nombre para la segunda parte: extensiones lado a lado (side-by-side), que corren fuera del ERP y se conectan a él [2]. No es la única forma limpia —SAP también admite extensiones dentro del ERP cuando el caso pide ese acoplamiento y se hacen con sus herramientas liberadas [1]—, pero para lo que es de cada canal suele ser la que mejor encaja. La ventaja para el negocio es doble. Queda menos código propio dentro del ERP, así que en cada actualización hay menos que revisar. Y un canal nuevo cambia sobre todo la capa de afuera; en SAP, cuando mucho, un dato maestro o una configuración.

Los tres pedidos, resueltos por la puerta correcta

Volvamos a la empresa ficticia.

La tienda en línea. Cada pedido entra a SAP por una interfaz publicada, con un folio único que se revisa antes de registrarlo, para que un reintento no lo duplique: eso no lo trae la interfaz, se diseña. El precio y la existencia se consultan por la misma vía, si la versión de SAP la ofrece; si la tienda los consulta muchas veces por minuto, conviene que la capa de afuera guarde una copia, con una frecuencia de actualización acordada, para no cargarle a SAP cada visita. La lógica del carrito, los cupones y los avisos al cliente se queda en la tienda o en la capa de afuera, no en SAP.

El banco. El banco manda su estado de cuenta como archivo, con su formato. La capa de afuera lo recoge, lo valida, lo traduce y hace la conciliación contra lo que SAP tiene por cobrar. A SAP le llega solo lo que tiene que registrar, por su puerta oficial. Si mañana se suma un segundo banco con otro formato, se le enseña a la capa de afuera; en SAP, a lo más, se da de alta la cuenta.

El socio distribuidor. El socio entra por una puerta con su propia identidad y sus propios permisos, manda sus pedidos con su formato, y la capa de afuera los traduce al pedido que SAP conoce. Si el socio cambia de sistema, se ajusta la traducción; SAP sigue igual.

En los tres casos, SAP hace lo que mejor hace. Cuando toque actualizarlo, se prueban las tres conexiones, pero no hay tres desarrollos propios escondidos adentro que revisar uno por uno.

Cuando la puerta que hace falta no existe

A veces no hay una interfaz publicada para lo que se necesita, sobre todo en versiones anteriores de SAP. Eso no obliga a meterse dentro de SAP a la primera. El propio SAP publica una guía para ese caso: envolver una función clásica —su ejemplo es una BAPI que crea solicitudes de compra— en una interfaz propia, pequeña y documentada, que se libera para que el desarrollo nuevo la use; la función de abajo sigue siendo clásica, y SAP la clasifica en el nivel B [1][6]. El mismo grupo de tutoriales muestra después cómo cambiar ese envoltorio por la interfaz liberada que SAP publicó para ese proceso [6]. Sus preguntas frecuentes agregan una advertencia útil: juntar muchas funciones clásicas en un solo envoltorio dificulta retirarlo después, cuando SAP publique la interfaz de alguna de ellas, y mezcla responsabilidades (traducción libre) [7].

En lenguaje de comité: si hace falta entrar por una puerta que no es la de primer nivel, se hace a propósito, en un solo lugar, con un nombre y un dueño, y revisando en cada versión si SAP ya ofrece una alternativa liberada.

Los riesgos, en lenguaje de negocio

Cinco preguntas para su próximo comité

1. ¿Cuántos desarrollos propios tiene su empresa dentro de SAP para conectar otros sistemas, y quién los conoce? Si nadie puede contestar con una lista, ése es el primer hallazgo.
2. En la última actualización de SAP, ¿cuántos de esos desarrollos hubo que revisar o rehacer, y cuánto tiempo costó?
3. Para la próxima integración que se va a aprobar, ¿por qué puerta de SAP va a entrar? Pida que se diga por escrito: interfaz publicada, función remota, documento de intercambio o archivo —y qué proceso de SAP lo recibe—, y por qué.
4. ¿Algo escribe directo en las tablas de SAP? Si la respuesta es «creo que no», vale la pena comprobarlo.
5. Si mañana se suma un banco o un socio nuevo, ¿qué hay que cambiar en SAP? Un dato maestro o una configuración es normal. Si la respuesta es «un programa nuevo», es probable que la lógica de cada canal esté viviendo en el lugar equivocado.

Si varias respuestas son «no lo sé», tómelo como señal para hacer el inventario antes de aprobar la siguiente integración.

Por dónde empezar esta semana

Haga el inventario de las conexiones de SAP. Una hoja, una fila por conexión, con cinco columnas:

• ¿Qué sistema se conecta: tienda, banco, socio, otro?
• ¿Por qué puerta entra: interfaz publicada, función remota, documento de intercambio, archivo o directo a tablas?
• ¿La lógica de ese canal vive dentro de SAP o afuera?
• ¿Quién la mantiene, y está documentada?
• ¿Se rompió o hubo que revisarla en la última actualización?

La hoja que resulte muestra, con hechos, qué conexiones dependen de código propio dentro de SAP y ayuda a decidir por dónde conviene empezar a sacar lógica. Sirve con cualquier herramienta, o sin ninguna.

Qué hace Hábil

En Hábil construimos a la medida la integración entre SAP —o el ERP que usted tenga— y lo que lo rodea: la tienda, los bancos, los socios y los canales. Lo hacemos entrando por las puertas que el fabricante soporta y dejando afuera lo que es de cada canal.

Si su inventario muestra conexiones que dependen de desarrollos propios dentro de SAP, la propuesta está en Hábil MDW. Se conecta a su ERP y a sus canales por las vías que cada uno ya tiene, convierte lo que llega a un mismo lenguaje y deja registrado qué pasó, cuándo y quién lo hizo. En los ERP priorizamos las interfaces que el fabricante soporta, para no dejarle desarrollos que estorben al actualizarlo. Bancos, tiendas, agentes y distribuidores se conectan con su propia identidad y sus propios permisos. El alcance, las puertas que se usan y el orden en que se saca lógica de SAP se revisan con su caso.

La conversación puede empezar con su inventario, aunque sea a medias: qué se conecta, por dónde entra y qué se rompió en la última actualización. Con eso revisamos juntos por dónde conviene empezar. Escríbanos por WhatsApp; para proteger su información, no comparta por ese medio datos de sus sistemas ni de sus clientes: acordaremos en la conversación el canal para el caso.

Pida su primera conversación, sin costo.

Consultadas el 12 de noviembre de 2026. Cada referencia lleva su confianza: alta (fuente primaria leída).