Diagnóstico técnico y arquitectura propuesta

Integración del flujo comercial con SAP Business One: diagnóstico, arquitectura recomendada y costos de operación, a partir de la información que compartió el equipo de Silvana.

Para: Carlos Ramírez y el equipo de TI de Silvana · De: HEYAY LABS · Junio 2026

El objetivo del piloto

Antes del stack y los costos, qué buscamos lograr. Todo lo demás existe para esto.

Qué se necesita para llegar — las 8 capacidades

El puente entre el objetivo y el stack: qué tiene que pasar, qué lo resuelve, de qué depende.

Requisitos de arranque (accesos, no código)

El proyecto se desbloquea con accesos. Estos son los que necesitaremos del lado de Silvana:

1. Base de datos de prueba disponible (es la ruta crítica hacia el 15 de agosto).
2. Definición de dos puntos que determinan la arquitectura: ¿el firewall corta todo el tráfico fuera de horario? ¿se permite sincronizar datos hacia la nube?
3. Apoyo de Tesselar (su implementador SAP): usuario de servicio, documentación de las interfaces existentes y de los UDF, y el flujo de timbrado.
4. La estructura actual del material en tránsito (hoy en Excel) para modelar la captura y el ATP.
5. Documentación y credenciales de la API de Handy.

Cómo se evaluará el piloto — las métricas

Proponemos firmar estas métricas como baseline en el arranque y medirlas al cierre:

• Horas de vendedor por semana liberadas de captura.
• Tiempo de captura por orden (de minutos a segundos).
• Porcentaje de errores de captura.
• OTIF baseline contra objetivo.
• Porcentaje de pedidos procesados sin intervención humana.

Resumen del stack propuesto

Arquitectura híbrida de servicios administrados: Vercel para la app · Fly.io para el procesamiento siempre encendido · Cloudflare para el túnel a SAP y el data lake · Supabase (Postgres) para los datos · OpenAI para la inteligencia. Cada pieza tiene una ruta de migración a AWS cuando el volumen lo exija (ver "Ruta de escalamiento").

El contexto que define el diseño

Tres datos del entorno de Silvana determinan casi todas las decisiones:

1. Volumen chico-mediano (~8,500 pedidos/mes, 5,300 SKUs, 24k precios especiales). Postgres lo maneja sin problema; no se justifica un warehouse de gran escala (Snowflake/BigQuery/Redshift) en esta etapa.
2. VPN por horarios y sin abrir la red. El acceso a SAP es el punto técnico central; la conectividad pesa más que la capacidad de cómputo.
3. El código y la arquitectura quedan en Silvana. Esto premia la simplicidad, el costo bajo y la mantenibilidad.

Criterio general: no contratar capacidad que no se necesita todavía. Se empieza simple y se escala cuando el volumen lo exija.

Decisiones de arquitectura

1. Plataforma base

Proponemos un conjunto de servicios administrados (Vercel + Cloudflare + Fly + Supabase), no la administración directa de infraestructura cruda. Ninguna pieza por sí sola cubre las necesidades distintas del proyecto: Vercel es lo más eficiente para la app; Cloudflare aporta el túnel a on-premise y un data lake sin costos de egress; Fly aporta el proceso siempre encendido que el requisito 24/7 vuelve necesario; Supabase aporta el Postgres con servicios integrados.

2. Data lake

Recomendamos Cloudflare R2 para los archivos no estructurados (audio, imagen, correos). No tiene costos de egress, que importan porque estos archivos se leen varias veces para alimentar a la IA. Es compatible con S3, por lo que la migración futura es directa.

3. Data warehouse

Recomendamos Supabase (Postgres administrado). A este volumen es una base de datos pequeña: Postgres la maneja sin problema, es un estándar conocido y mantenible, soporta JSON para los UDF de SAP, e incluye pgvector para la búsqueda semántica de SKUs. Supabase además aporta autenticación y almacenamiento integrados, lo que simplifica la webapp de captura.

Ruta de escalamiento: si el volumen crece más allá de lo que Supabase atiende cómodamente, se migra al servicio equivalente en AWS (Aurora o RDS Postgres) sin cambiar el modelo de datos.

4. Conectividad a SAP

Es el punto técnico central. Lo desarrollamos a detalle.

El problema

El Service Layer de B1 es un servidor HTTPS dentro de la red de Silvana (https://<servidor-sap>:50000/b1s/v1), hoy alcanzable solo por VPN y restringido a horarios. La política es no abrir la red. Nuestra plataforma necesita leer (sincronizar) y escribir (crear órdenes).

La propuesta: túnel saliente

En lugar de abrir un puerto de entrada, un agente liviano corre en el equipo Windows de Silvana y establece una conexión saliente (solo salida, puerto 443) hacia nuestra plataforma, formando un canal cifrado permanente. Nadie entra a la red de Silvana; el equipo lo controla Silvana y puede apagarlo cuando lo decida.

• Recomendamos Cloudflare Tunnel (cloudflared) instalado como servicio de Windows.
• Alternativa equivalente: Tailscale / WireGuard. No recomendamos VPN site-to-site clásica (IPsec).

Dos definiciones que determinan la arquitectura

El "VPN por horarios" puede significar dos cosas, y cada una cambia el diseño:

• Escenario A — la restricción aplica solo a la VPN de personas. El firewall deja salir tráfico (443) las 24 horas; el túnel queda activo siempre y la lectura/escritura es en tiempo real.
• Escenario B — el firewall corta todo el tráfico fuera de horario. La cola asíncrona se vuelve obligatoria: el pedido se interpreta y valida en tiempo real, pero la escritura a SAP se difiere a la ventana. El cliente igual recibe su confirmación.

Operación 24/7 — qué se necesita

Como entran pedidos a cualquier hora, lo ideal es que el sistema opere 24/7. Hay que separar dos capas:

1. Recibir, interpretar, cotizar, validar crédito y dar fecha de entrega ya puede ser 24/7, porque se resuelve contra el espejo de datos en la nube, no contra SAP en vivo. El cliente siempre puede pedir y recibir confirmación.
2. Escribir la orden dentro de SAP en el momento requiere que SAP esté alcanzable. Para que sea 24/7 real se necesita: equipo, SAP, HANA y Service Layer encendidos las 24 horas; firewall que permita el túnel saliente las 24 horas (Escenario A); un usuario de servicio dedicado, independiente del horario del VPN de personas; y un worker siempre encendido que mantenga la cola.
3. Si se prefiere no tener SAP alcanzable de noche (Escenario B): el sistema igual opera 24/7 de cara al cliente; la orden solo entra a SAP cuando abre la ventana, sin que el cliente lo perciba.

Verificaciones técnicas del arranque

1. Línea de vista de red: que el equipo Windows alcance SAP (curl -k https://<sap>:50000/b1s/v1/).
2. Salida 443 permitida por el firewall (para el túnel).
3. Definición del Escenario A o B.
4. Certificado del Service Layer (suele ser autofirmado; se confía en el conector).
5. Usuario de servicio SAP y manejo de sesión (B1SESSION: renovar y reusar).
6. Límite de sesiones concurrentes (atadas a licencias): agrupar sesiones para no chocar con el add-on fiscal ni con Handy.
7. Capacidad del Service Layer 9.2/HANA 1.0: la carga inicial (5,300 SKUs + 24k precios + 1,500 clientes) se procesa por lotes y fuera de pico.
8. Latencia: se absorbe leyendo del espejo (warehouse), no consultando SAP en cada paso.
9. Resiliencia: que el agente arranque solo tras reinicio o corte de energía, con monitoreo.
10. Alcance mínimo: el túnel expone solo el host y puerto del Service Layer, no la red completa.

5. Cómputo y orquestación

El requisito 24/7 lleva a un worker siempre encendido en Fly.io, con Vercel para la app y los webhooks.

• Vercel hospeda la webapp y los webhooks de entrada (reciben el pedido y lo colocan en la cola).
• Fly.io corre el worker que procesa la cola las 24 horas: ejecuta el pipeline de IA, escribe a SAP por el túnel y reintenta cuando hay ventana.

Ruta de escalamiento: el worker puede migrarse al servicio equivalente en AWS (ECS Fargate o EC2) cuando el volumen o la estandarización en AWS lo justifiquen.

6. Inteligencia — OpenAI

Para extraer un pedido estructurado de texto, imagen y audio transcrito, usamos la familia GPT-5.4 con ruteo por dificultad:

• Por defecto — GPT-5.4 mini ($0.75 / $4.50 por millón de tokens): la mayoría de los pedidos, con visión y salidas estructuradas.
• Pedidos simples — GPT-5.4 nano ($0.20 / $1.25): el más económico.
• Pedidos difíciles — GPT-5.4 ($2.50 / $15, contexto de 1M): casos ambiguos. GPT-5.5 solo para lo excepcional.
• Imágenes: GPT-5.4 las interpreta de forma nativa.
• Audio: OpenAI reemplazó Whisper por la familia GPT-4o de transcripción; usamos gpt-4o-mini-transcribe ($0.003/min). Flujo: audio → transcripción → texto → modelo.
• Búsqueda de SKU: embeddings del catálogo (text-embedding-3-small) en pgvector, para mapear "tela azul rey, 3 rollos" al SKU correcto.

7. Webapp de captura (sustituye el Excel de tránsito)

Una aplicación interna sencilla donde operaciones captura lo que hoy no vive en SAP: embarques, material en tránsito y ETAs. Reemplaza el Excel y habilita el cálculo de promesa de entrega.

• Frontend y API: Vercel (Next.js).
• Login interno: autenticación de Supabase, con acceso para el personal de operaciones.
• Datos: el mismo Postgres del warehouse; lo capturado queda disponible de inmediato para el ATP. Una sola fuente de verdad, en lugar de un Excel paralelo.
• Adjuntos (documentos de embarque): R2.

Más adelante, esta misma plataforma puede incorporar consultas asistidas por IA sobre los datos (disponibilidad, conciliación de tránsito, detección de anomalías). No forma parte del piloto.

8. Sincronización SAP → warehouse

Recomendamos sincronización incremental por Service Layer (OData), que es la vía soportada y con precedente (las interfaces de Handy ya operan así). Para los 24k precios especiales se traen solo los cambios por fecha de modificación. Si el Service Layer 9.2 resultara corto para cargas pesadas, se evalúa la lectura directa a HANA.

Inventario completo del stack

Los servicios sin costo — por qué, y cuándo empiezan a cobrar

Modelo de costos

Supuestos

• Precios OpenAI: GPT-5.4 $2.50/$15 · mini $0.75/$4.50 · nano $0.20/$1.25 por millón (entrada/salida), con prompt caching.
• Costo por pedido interpretado ≈ $0.004–0.008 (mini, con caché); la imagen agrega tokens.
• Ruteo ~70% mini, ~20% nano, ~10% GPT-5.4. Audio en ~30% de pedidos (~1 min, $0.003/min).
• Tipo de cambio de referencia ~$18 MXN/USD.

Costos de una sola vez (setup)

• Onboarding de WhatsApp Business API (verificación con Meta): sin costo de licencia.
• Dominio: ~$10/año.
• Migración del WhatsApp actual a la API, si hoy se usa la app y no la API.

Qué determina el costo

• El costo variable está dominado por OpenAI y WhatsApp. Se controla con prompt caching, GPT-5.4 nano para pedidos simples, ruteo por dificultad y procesamiento en lote para reprocesos.
• En WhatsApp, las conversaciones iniciadas por el cliente (servicio) son en gran parte gratuitas dentro de la ventana de 24 horas; usando Meta Cloud API directo se evita el sobreprecio de un intermediario (BSP).

Ruta de escalamiento

El stack propuesto está dimensionado para el volumen actual y para entregar rápido. Cuando el crecimiento o un requisito de gobernanza lo justifiquen, cada componente administrado tiene una migración directa a AWS, sin rehacer la lógica de negocio ni el modelo de datos:

La inteligencia (OpenAI) y el túnel a SAP no cambian. La migración es por componente, según la necesidad, no un rediseño.

Puntos a confirmar y coordinar

El cuestionario inicial cubrió la integración base. Para cerrar el diseño con precisión, quedan algunos puntos que dependen del implementador (Tesselar) y de un par de terceros.

Coordinación con terceros

• Tesselar (implementador SAP). Es quien opera el Service Layer, las interfaces de Handy y el add-on fiscal. Proponemos una sesión técnica conjunta para alinear accesos, documentación de interfaces/UDF y el flujo de timbrado.
• Handy (CRM de vendedores). Confirmar acceso y documentación de su API.
• Meta (WhatsApp Business). Confirmar la titularidad de la cuenta de WhatsApp Business y si hoy se usa la app o la API.

Definiciones técnicas a confirmar

• Timbrado / CFDI. Al crear la orden en SAP, ¿el timbrado del add-on fiscal ocurre automáticamente o se dispara desde la integración? Confirmar el flujo orden → factura → timbrado.
• Series de documentos. Qué serie usan las órdenes creadas por integración.
• Procedimientos de aprobación. Las bandas de crédito (+20/+30/+60), ¿están como approval procedures en B1 o son manuales hoy?
• Unidades de medida y "corte". Manejo de rollos, metros y corte, y su conversión en OITM.
• Multimoneda. Si hay ventas en USD además de MXN.
• Alta de clientes. Si el flujo solo opera clientes existentes o también da de alta business partners por integración.
• Asignación de vendedor (SlpCode) en la orden creada.
• Interacción con Handy. Qué escribe Handy hoy en SAP, para coordinar y no duplicar.
• Devoluciones / notas de crédito. Confirmar si quedan dentro del alcance del piloto.

Riesgos y mitigaciones

1. Disponibilidad de la base de datos de prueba a tiempo — es la ruta crítica. Mitigación: definir su fecha al inicio.
2. Coordinación con Tesselar — controlan accesos, el add-on fiscal y conocen los UDF. Mitigación: involucrarlos desde la primera semana con una sesión técnica conjunta.
3. Flujo de timbrado/CFDI por confirmar — afecta el cierre del pedido. Mitigación: aclararlo con Tesselar en esa sesión.
4. Política de salida de datos a la nube — define la arquitectura. Mitigación: confirmarlo al inicio.
5. Service Layer 9.2 — versión con capacidades acotadas. Mitigación: validar las operaciones reales en las primeras semanas; alternativa por HANA + DI API.
6. Handy sin ambiente de pruebas — Mitigación: simulación de su API y pruebas de contrato; pruebas controladas contra producción.

Viabilidad y condiciones de éxito

Técnicamente, el proyecto es viable y está bien dimensionado. Nada de lo que requiere el flujo objetivo es exótico ni incierto:

• La conexión a SAP está respaldada: Service Layer habilitado, acceso indirecto licenciado, y existe precedente (las interfaces de Handy ya operan por esa vía). No se abre brecha nueva; se repite un patrón que ya funciona.
• El volumen es chico-mediano y cabe en un stack simple y de bajo costo.
• Las piezas con mayor lógica de negocio (precios especiales, crédito por bandas, promesa de entrega) son construibles con reglas claras.

El factor que determina el cumplimiento del 15 de agosto no es la tecnología, sino la velocidad con que se desbloqueen los accesos y la coordinación. El calendario de construcción es de aproximadamente nueve semanas una vez que existe acceso, por lo que el margen es ajustado. En orden de impacto, lo que asegura el éxito:

1. Accesos en tiempo: base de datos de prueba y usuario de servicio. Es la condición que vuelve seguro el compromiso de la fecha.
2. Coordinación con Tesselar desde el inicio, en especial para el flujo de timbrado y los accesos al Service Layer.
3. Definición de los dos puntos de conectividad (firewall fuera de horario; salida de datos a la nube) y de si se desea operación 24/7.
4. Un responsable interno con autoridad para resolver bloqueos del lado de Silvana.
5. Alcance del piloto y métricas baseline firmados, para que el resultado sea medible y no quede a interpretación.
6. Acceso al Excel de tránsito y a la API de Handy, que habilitan la promesa de entrega y el canal de vendedores.

En síntesis: la pregunta no es si se puede construir —sí se puede—, sino qué tan pronto se cierran estas definiciones. Si se resuelven en las próximas una o dos semanas, el 15 de agosto es sostenible; de lo contrario, ajustaríamos el alcance o el calendario de común acuerdo, sin sacrificar la calidad de lo entregado.