Integración e-commerce ↔ ERP

SAP Business One
↔ Tienda Crema

Cómo se conectan la tienda online y el ERP del club: qué datos viajan, en qué dirección y con qué frecuencia. SAP es el maestro de catálogo, precios y stock; Shopify manda en la experiencia de compra.

Service Layer · REST/OData Shopify Admin API Middleware EQAPLA v0.1 — borrador para TI
Vista general

Arquitectura de la integración

Un middleware intermedio orquesta las dos plataformas: mantiene la sesión con SAP, encola y reintenta, y deja trazabilidad de cada transacción. Ningún sistema escribe directo sobre el otro.

flowchart LR subgraph ERP["SAP BUSINESS ONE — MAESTRO"] SAP["Catálogo · Precios · Stock
Pedidos · Facturación"] end subgraph MID["MIDDLEWARE EQAPLA"] MW["Orquestador
sesión · colas · reintentos · logs"] end subgraph STORE["SHOPIFY — TIENDA CREMA"] SH["Contenido · Carrito
Checkout · Pagos"] end SAP -->|"Service Layer · REST/OData"| MW MW -->|"Admin API"| SH SH -->|"Webhooks orders/paid"| MW MW -->|"Pedido de venta"| SAP
Flujo 2

Precios

02

Precios

SAP → Shopify

La lista de precios de SAP aplicable a la tienda actualiza el precio de cada variante en Shopify. A confirmar con TI si el precio de SAP ya incluye IGV.

sequenceDiagram participant SAP as SAP B1 participant MW as Middleware participant SH as Shopify MW->>SAP: Lee lista de precios de la tienda SAP-->>MW: Precio por artículo MW->>MW: Ajusta IGV si aplica MW->>SH: Actualiza variant.price
Flujo 3 · Crítico

Sincronización de stock

El requisito clave de TI. Doble objetivo: no vender lo que no hay (evitar sobreventa) y que SAP quede como registro único del inventario. Es un flujo bidireccional.

Disponible en tienda = InStock (SAP) − Reservado/Comprometido − Buffer de seguridad
03

Stock

Bidireccional

Refresco periódico SAP→Shopify, descuento en tiempo real por venta, y una reconciliación nocturna que alerta pero no autocorrige.

sequenceDiagram participant SAP as SAP B1 participant MW as Middleware participant SH as Shopify Note over SAP,SH: 3a · Refresco de disponibilidad (cada N min) MW->>SAP: GET Items con cambio de stock SAP-->>MW: InStock por almacén MW->>MW: Disponible = InStock − Reservado − Buffer MW->>SH: Actualiza inventory_level Note over SAP,SH: 3b · Venta en tiempo real SH->>MW: webhook orders/paid MW->>SAP: Crea pedido de venta (descuenta stock) MW->>SAP: Refresco inmediato del SKU vendido MW->>SH: Actualiza disponible (anti-oversell) Note over SAP,SH: 3d · Reconciliación nocturna MW->>SAP: Lee stock total MW->>SH: Compara y ALERTA diferencias
Decisión con TI  ¿La tienda vende de un almacén dedicado a e-commerce o del mismo almacén que la tienda física? Un almacén apartado para online reduce drásticamente el riesgo de sobreventa. Definir también la frescura esperada (real-time vs cada 5/15 min) — cambia arquitectura y costo.
Flujo 4 · Pedidos

Pedidos relacionados a SAP

Todos los pedidos que tocan el ERP: el estándar, el personalizado (arma tu camiseta) y el post-compra/logística. Los tres nacen en Shopify y se materializan como documentos en SAP.

4A

Pedido estándar

Shopify → SAP · tiempo real

Al pagar, un webhook crea la orden de venta en SAP con el cliente (DNI/RUC) y las líneas de personalización (estampado, parche). Luego el ciclo en SAP: orden de venta → orden de despacho → entrega. Al entregarse se emite la boleta o factura según lo que el cliente pidió, y el middleware la refleja en la tienda. Idempotente: si el webhook se repite, no se duplica el pedido.

sequenceDiagram participant C as Cliente participant SH as Shopify participant MW as Middleware participant SAP as SAP B1 C->>SH: Paga (elige boleta o factura: DNI/RUC) SH->>MW: webhook orders/paid MW->>MW: ¿order.id ya procesado? (idempotencia) MW->>SAP: Resuelve / crea BusinessPartner (DNI/RUC) MW->>SAP: Crea Orden de venta (+ servicios EST- / PARCHE-) SAP-->>MW: DocEntry Note over SAP: Genera Orden de despacho (entrega) SAP->>SAP: Pedido entregado SAP->>SAP: Emite Boleta o Factura (según lo pedido) SAP-->>MW: Comprobante CPE emitido MW->>SH: Actualiza estado + adjunta comprobante MW->>SH: Actualiza inventario del SKU
Flujo · por confirmar  Facturación electrónica SUNAT: se emite desde SAP al entregarse el pedido — boleta (DNI) o factura (RUC) según lo que el cliente solicitó. Lo coordina Ángel Pinto (por confirmar accesos/mecanismo).
4B

Pedido personalizado · "Arma tu camiseta"

Shopify → SAP · producción

El pedido incluye SKUs de servicio por la personalización (estampado del dorsal, parche de liga). En SAP se agregan como líneas del pedido y disparan una orden de producción antes del despacho (+2 días).

sequenceDiagram participant C as Cliente participant SH as Shopify participant MW as Middleware participant SAP as SAP B1 C->>SH: Arma camiseta (dorsal + parche) y paga SH->>MW: orders/paid con line item properties MW->>SAP: Orden de venta: camiseta + EST-nombre + PARCHE-liga SAP->>SAP: Genera orden de producción (estampado) SAP->>SAP: Despacho tras producción (+2 días) MW->>SH: Estado "en producción" al cliente
Dato  Los cargos de personalización deben existir como artículos de servicio en SAP (EST-*, PARCHE-*) — si no, hay que darlos de alta. Estos pedidos no admiten devolución.
4C

Post-compra · despacho y logística

SAP → PITS → Shopify

Cuando SAP marca el pedido como despachado, el middleware gestiona la guía y el tracking con PITS y devuelve el estado a la cuenta del cliente en Shopify.

sequenceDiagram participant SAP as SAP B1 participant MW as Middleware participant PITS as PITS participant SH as Shopify SAP->>MW: Pedido despachado (DeliveryNote) MW->>PITS: Genera guía + solicita tracking PITS-->>MW: Nº de guía + tracking MW->>SH: Fulfillment + tracking en la cuenta del cliente
Pedidos a TI · lo que nos tienen que pasar

Lo que necesitamos de la U

Para construir el middleware hace falta que TI/el partner SAP nos entregue esto. Hoy nada está en mano todavía — la acción por cada fila es confirmar que su responsable sabe que debe pasárnoslo. Detalle en sap-solicitud-accesos-middleware.md.

Qué necesitamos¿Necesario?¿Lo tenemos?Qué falta / responsable
1 · Acceso al Service Layer
URL + puerto, alcance por red y certificado TLS		 Indispensable No Que sea alcanzable desde nuestro server (VPN / whitelist). TI / infra
2 · Credenciales SAP
usuario/clave + CompanyDB del torneo pruebas		 Indispensable No Que la U entregue las credenciales del ambiente. TI / admin SAP
3 · Entorno de pruebas
acceso al ambiente "torneo pruebas"		 Necesario No Confirmar acceso y que tenga datos representativos. TI
4 · Modelo de datos
SKUs, precios, almacenes, artículos de servicio		 Necesario (mapeo) No Se dijo que lo pueden pasar → confirmar el responsable
5 · Facturación electrónica
emisión de boleta/factura desde SAP		 Necesario (comprobante) No Confirmar mecanismo/accesos. Ángel Pinto
6 · Operación y contactos
frescura de stock, contacto del partner		 Informativo — No bloquea el arranque
Para arrancar  Lo indispensable es el Bloque 1 + 2 (acceso al Service Layer + credenciales del torneo pruebas). Con eso el dev de Node conecta y empieza; el resto se cierra en paralelo.
Reglas de oro

Principios técnicos que sostienen todo

1

SKU = clave de cruce

El ItemCode de SAP debe ser idéntico al SKU de Shopify. Es la precondición de toda la integración.

2

Sesión reutilizable

La sesión de SAP expira a los ~30 min. Se mantiene un pool con re-login perezoso — nunca autenticar por request.

3

Nada se pierde

Colas con reintentos y backoff. Si el Service Layer cae, las transacciones se recuperan; no se pierden en silencio.

4

Acceso seguro

El Service Layer casi nunca está expuesto a internet. Resolver el acceso (VPN / whitelist) es prerrequisito bloqueante.