Extracción de pedidos al ERP, conciliación a tres bandas de albaranes y facturas, agentes comerciales que leen el histórico del socio de negocio (Business Partner) — siempre con escrituras idempotentes, validación contra catálogo y respeto a las autorizaciones de usuario (User Authorizations) de B1.
SAP Business One sostiene el inventario, el catálogo, los precios y la contabilidad de la empresa. Una IA que escriba sin entender el modelo de socios de negocio (Business Partners), artículos (Items) y documentos comerciales rompe el cierre, infla el inventario o duplica el pedido cuando hay un tiempo de espera. Cualquier cosa que pase en B1 acaba en el balance — y eso lo audita Hacienda, no un panel.
Trabajamos con la regla de leer mucho y escribir poco — y solo cuando la operación está validada contra el catálogo, las tarifas vigentes y las autorizaciones de usuario (User Authorizations) de quien la dispara. Cada escritura lleva clave de idempotencia, modo de simulación para revisar antes de confirmar, y registro auditable. La empresa de pruebas existe por algo: ahí es donde validamos el flujo antes de tocar producción.
PDF, correo o Excel del cliente — el agente extrae líneas, las cruza contra artículos (Items) y tarifa vigente del socio de negocio (Business Partner), y crea el pedido de venta (Sales Order) en B1 vía Service Layer. Lo que no encaja queda en cola para revisión, no se inventa el código.
Lee el pedido de compra, el albarán de entrada y la factura de proveedor, las cuadra a nivel de línea y cantidad, y marca las desviaciones. Solo lo que cuadra automáticamente se propone para contabilizar — el resto va al revisor con el motivo.
Lee histórico de pedidos, tarifa aplicada, plazos de pago y rotación del cliente directamente de B1, y prepara borrador de cotización con producto, precio y plazo reales. El comercial revisa y firma — el agente no fija precio fuera de regla.
Vigila niveles por artículo (Item) y almacén (Warehouse), cruza contra rotación histórica y plazo de entrega del proveedor, y propone reposición — la propuesta queda en borrador para que el responsable de compras la convierta en pedido de compra (Purchase Order) si está conforme.
Pregunta en lenguaje natural sobre ventas, márgenes, rotación o cuentas por cobrar — el agente genera la consulta, la ejecuta sobre HANA o MSSQL y devuelve la respuesta citando la SQL exacta. Si no está seguro, lo dice y no inventa el dato.
Service Layer es el camino estándar para pedidos de venta (Sales Orders), socios de negocio (Business Partners), artículos (Items) y la mayoría de documentos comerciales. Para operaciones que solo expone DI API (alguna acción heredada o personalizada por el implantador) usamos DI vía un servicio dedicado, sin mezclarlo en el mismo proceso del agente.
El agente actúa con un usuario de B1 al que vosotros aplicáis las mismas autorizaciones que a una persona — no nos saltamos permisos ni usamos un superusuario. Si el usuario no tiene permiso para crear un abono (Credit Memo), el agente tampoco. Eso lo audita el responsable del ERP, no nosotros.
Antes de escribir, el conector resuelve el CardCode del Business Partner y el ItemCode contra el catálogo real. De entrada no creamos clientes ni artículos nuevos: lo que no resuelve queda en cola para alta supervisada. Con datos maestros sucios trabajamos, pero no los limpiamos solos.
Cada escritura lleva una clave única que persistimos en un UDF del documento o en una tabla auxiliar. Si el agente reintenta por un tiempo de espera, comprobamos la clave antes de ejecutar y la operación se aplica exactamente una vez — ni pedidos duplicados ni facturas dobles.
Soportamos las dos versiones del motor — los informes semánticos cambian entre HANA y MSSQL y lo tenemos en cuenta. Cualquier nuevo flujo se prueba primero contra una empresa de pruebas que reproduzca vuestros UDFs y autorizaciones reales antes de tocar producción.
Con las dos. La capa de orquestación es la misma, lo que cambia es el dialecto de las consultas analíticas y algunos detalles del Service Layer. Si tenéis HANA exponemos también las vistas semánticas; si estáis en MSSQL trabajamos con las vistas y procedimientos equivalentes. Lo confirmamos en el descubrimiento inicial.
Cada operación de escritura lleva una clave de idempotencia única que guardamos en un UDF del documento o en una tabla externa. Antes de crear un pedido de venta (Sales Order), el conector consulta esa clave; si ya existe, devuelve el documento original sin volver a escribir. Un tiempo de espera de red no genera un pedido duplicado.
De entrada, no. Leemos vuestros UDFs si forman parte del modelo (por ejemplo, una clave externa o una marca de proceso) y solo escribimos en los UDFs que vosotros nos autoricéis explícitamente. Cualquier complemento del SDK que ya tengáis sigue funcionando — el agente actúa por encima del Service Layer, no compite con él.
Queda en una cola de revisión con el motivo: ItemCode no resuelto, CardCode desconocido, tarifa fuera de rango, cantidad incoherente. La persona responsable lo ve, decide si crear el artículo, asignar manualmente o rechazar, y el agente aprende del patrón para casos parecidos. Nunca escribimos al ERP con un código inventado.
Diseñamos soluciones con privacidad desde el inicio, control humano, trazabilidad, límites de uso, gestión de permisos y documentación. Para procesos sensibles, ayudamos a evaluar los riesgos y obligaciones aplicables bajo el RGPD y el Reglamento de IA.
Cada proyecto lo lidera personalmente uno de los socios. Si hay encaje, te respondemos en menos de 24 horas con una primera lectura concreta de tu caso — no con una demostración genérica.
