BigCommerce y SAP, conectados como se debe.

Nada de este proyecto se puede dimensionar hasta responder eso, porque los tres son productos distintos con superficies de integración distintas. Quien cotice “una integración de BigCommerce con SAP” sin preguntarlo, está cotizando una suposición.

BigCommerce es el extremo fácil. Te da una API REST y GraphQL documentada, webhooks, listas de precios y grupos de clientes, y B2B Edition suma cuentas de empresa y jerarquías. Se comporta como un producto SaaS moderno porque lo es.

SAP es donde están las decisiones, y en realidad solo hay cuatro rutas:

• BAPIs y RFC. El camino clásico, y en ECC muchas veces el único que alcanza la lógica que necesitas. Síncrono, rápido, y exige una conexión RFC hacia tu paisaje, lo que es una conversación con quien manda en Basis y en el firewall.
• IDocs. Documentos asíncronos. Excelentes para el flujo de pedidos y facturas donde unos minutos de retraso están bien, y completamente equivocados para “cuánto paga este cliente por este artículo ahora mismo”. Muchas tiendas que rinden mal, rinden mal porque alguien usó IDocs para el precio.
• OData vía SAP Gateway. La superficie moderna. Estándar en S/4HANA, disponible en ECC si alguien la configura. Aquí es donde quieres estar si puedes elegir, porque es HTTP, es cacheable y cualquier desarrollador ya lo entiende.
• Middleware. SAP Integration Suite, o un iPaaS de terceros como Boomi, Celigo, Jitterbit o MuleSoft. Suma costo y un salto, y te compra reintentos, transformación, monitoreo y un lugar donde poner lógica que no pertenece a ninguno de los dos sistemas.

El default honesto para la mayoría de los builds B2B: OData o BAPI para todo lo que el comprador espera, IDoc para el flujo de documentos que puede ser asíncrono, y middleware delante para que un SAP lento no se convierta en una tienda lenta. Decidir eso temprano es casi toda la arquitectura.

Quítale los diagramas y toda tienda B2B le hace a su ERP las mismas seis preguntas. Acertar en esas seis es el proyecto. Todo lo demás es decoración.

1. Quién es este cliente. El número de cliente en SAP detrás de la cuenta con sesión iniciada, incluidos sold-to, ship-to y payer cuando difieren, que en B2B difieren de forma rutinaria.
2. Cuánto paga. Precio neto para este cliente, este material, esta cantidad, hoy. Este es el difícil y tiene su propia sección abajo.
3. Qué puede llevarse. No solo existencias en almacén. Disponibilidad comprometible, en las plantas desde las que realmente se le sirve a ese cliente.
4. Colocar el pedido. Y devolver un número de documento de ventas real de SAP, no un id de pedido de BigCommerce con la promesa de sincronizar después.
5. Dónde va. Estatus de entrega y embarque, con rastreo donde la paquetería lo devuelva.
6. Cuánto debe. Historial de facturas, partidas abiertas, posición de crédito. Esto es lo que convierte una tienda en un portal de autoservicio, y es la parte por la que los compradores realmente entran.

La número seis se subestima siempre. La mayoría de los compradores B2B no entran a tu tienda a navegar. Entran a volver a pedir algo que ya compraron y a ver cuánto deben.

Si vale la pena leer una sección de esta página, es esta.

SAP no guarda un precio para un cliente y un material que puedas simplemente consultar. Lo calcula, en el momento en que preguntas, con la técnica de condiciones: un esquema de precios hecho de clases de condición, evaluado por secuencias de acceso contra registros de condición, filtrado por fechas de validez. El precio neto de un cliente puede depender de su lista de precios, contrato, grupo de material, cantidad, escalas, promociones, recargos, flete e impuestos, resueltos en una secuencia específica que tu negocio configuró durante años.

No puedes reimplementar eso en una tienda, y no deberías intentarlo. Cada intento al que nos han llamado a rescatar es la misma historia: alguien exportó registros de condición a listas de precios de BigCommerce, salió bien para la mayoría de los clientes, y las excepciones se volvieron un goteo silencioso de pedidos incorrectos que finanzas encontró semanas después.

El patrón correcto es preguntarle a SAP. Cotiza el carrito en SAP, ya sea con un BAPI de precios, un pedido de ventas simulado, o un servicio OData hecho para eso, y muestra lo que devuelve. Después haz ingeniería alrededor de la latencia, no alrededor de la verdad:

• Cachea agresivamente, y por cliente. Un precio es válido para ese cliente durante una ventana razonable. Cachéalo, e invalídalo con los eventos que de verdad lo cambian.
• Precio indicativo en el listado, precio exacto en el carrito. Catálogo y búsqueda pueden servir un precio cacheado o indicativo. El carrito, la cotización y el checkout tienen que ser un número vivo de SAP, porque eso es lo que se factura.
• Nunca muestres un precio que no puedas honrar. Si SAP no responde y no tienes un precio cacheado válido, dile al cliente que el precio no está disponible por ahora y deja que pida una cotización. Un ERP caído es una molestia. Un precio equivocado es una nota de crédito y una llamada.
• Sin precio, sin agregar al carrito. Si SAP no tiene precio para ese cliente y material, deshabilítalo en vez de dejar pasar un pedido que va a fallar más adelante.

Muchas de las empresas que nos hacen esta pregunta están en ECC y tienen un programa de S/4HANA en algún punto del roadmap. El instinto es esperar. Normalmente esa es la decisión equivocada, porque la tienda está ganando o perdiendo dinero ahora y el programa de S/4 se va a recorrer.

La decisión correcta es construir de forma que sobreviva a la migración:

• Pon una capa de integración en medio. La tienda le habla a tu capa; tu capa le habla a SAP. Cuando SAP cambie por debajo, reescribes un adaptador y no la tienda.
• Define primero los seis contratos en tus términos. No en los de SAP. “Obtener precio neto para cliente y material” es una idea estable. El BAPI detrás no lo es.
• Mantén los nombres de campo de SAP fuera de la tienda. Mapea en la frontera. Es lo más barato que puedes hacer hoy para que el cambio a S/4 pase sin ruido.
• Prueba los contratos contra S/4 antes de que el ERP salga a producción, no después. Longitudes de campo, tipos de documento y comportamiento de errores cambian, y la tienda suele ser el último sistema que a alguien se le ocurre probar.

Hecho así, la migración a S/4HANA toca un adaptador y una corrida de pruebas. Hecho al revés, se convierte en un segundo proyecto de tienda que no presupuestaste.

De los proyectos a los que nos han metido después de los hechos, en orden aproximado de frecuencia:

• El precio se copió en vez de preguntarse. Ya lo cubrimos arriba. Es la causa número uno de que una tienda B2B pierda dinero en silencio.
• La tienda es tan rápida como SAP. Sin capa de caché, así que cada página de producto espera a un ERP dimensionado para procesos batch y usuarios internos.
• Los pedidos se duplican. Sin llave de idempotencia al enviar, así que un reintento o un doble clic crea dos documentos de ventas, y nadie lo nota hasta que embarques lo nota.
• Nadie es dueño de la ruta de falla. SAP entra en ventana de mantenimiento y la tienda muestra un stack trace o, peor, un precio en cero.
• El stock es correcto e inútil. Se sincroniza el stock total en vez de la disponibilidad comprometible de la planta de ese cliente, así que el sitio promete lo que no puede embarcar.
• Cero observabilidad. Cuando un cliente dice que su precio está mal, nadie puede responder qué devolvió SAP en el momento en que él miró, y la investigación empieza desde cero.

Nada de esto es exótico. Todo es más barato de prevenir que de encontrar en producción, que es el argumento para hacer el diseño de la integración antes del diseño de la tienda y no después.