Cómo lograr que cada cobro facture solo en SAP Business One

La promesa suena simple: que cada cobro de tu sistema aparezca facturado en SAP Business One sin que nadie digite nada. Y la parte que todos miran —llamar a la API— es la fácil. Lo que hunde estos proyectos es otra cosa: un cobro no es un objeto en SAP, es una cadena, y si un eslabón falta, el ERP te devuelve un 200 igual mientras tu contabilidad deja de cuadrar. Esta es la guía de esa cadena, escrita desde haberla puesto en producción para un club de +50,000 asociados.

Las tres puertas de entrada a SAP B1

Service Layer es la interfaz moderna: REST sobre OData, HTTP y JSON. DI API es la capa antigua, basada en COM y más pesada de operar. B1if es el framework de integración de SAP. Para un sistema web nuevo, el Service Layer es casi siempre el punto de partida correcto.

El dato que ahorra discusiones: DI API y Service Layer comparten el mismo núcleo de datos, así que los objetos y sus propiedades son idénticos en ambos. Elegir uno u otro no cambia el modelo de negocio que tienes que respetar; cambia el transporte. La documentación de objetos que encuentres para DI API te sigue sirviendo para entender qué campos existen.

El Service Layer sigue el protocolo OData —versiones 3 y 4, con la 4 como principal en las versiones recientes— y eso trae una consecuencia práctica: es cómodo para crear y leer documentos, pero no está pensado para consultas SQL complejas ni para envolver varias operaciones en una transacción como harías en una base de datos. Ese límite condiciona el diseño, y conviene conocerlo antes y no durante.

Lo que de verdad cuesta: un cobro es una cadena

Facturar un cobro en SAP exige tres piezas encadenadas: socio de negocio, factura y pago aplicado a esa factura. Crear la factura sin aplicar el pago es el error más común — y el más silencioso, porque no falla nada.

El tercer eslabón es el que se olvida, y su síntoma tarda semanas en aparecer: contabilidad reporta que los clientes deben plata que ya pagaron, mientras en el banco el dinero está. Nadie mira la integración porque “funciona” — las facturas se están creando. El problema es que crear el pago no es aplicarlo: son dos cosas distintas y solo la segunda cierra la deuda.

La trampa: HTTP 200 no significa que la contabilidad cuadre

El Service Layer valida la forma del documento, no la coherencia de tu proceso. Puedes crear una factura perfectamente válida contra el cliente equivocado, con la serie equivocada o sin su pago aplicado, y recibir un 200 en los tres casos.

Por eso la verificación no puede ser “la API respondió bien”. Tiene que ser un cuadre: lo que cobró tu pasarela contra lo que quedó facturado y aplicado en SAP, por período. Es el mismo principio que aplicamos al integrar Culqi y Niubiz: la fuente de verdad operativa es tu sistema, y el cierre lo da la conciliación, no el código de respuesta.

En Perú, la factura no termina en SAP

La localización peruana de SAP B1 cubre el IGV, el plan contable y los libros electrónicos, pero el comprobante recién existe cuando SUNAT devuelve su CDR. Ese viaje —de SAP al OSE, del OSE a SUNAT y de vuelta— es parte de tu integración, aunque lo opere un add-on.

Esto cambia el diseño de tu máquina de estados. Una factura creada en SAP no es una factura entregada al cliente: puede ser rechazada. Tu sistema necesita un estado intermedio —emitida, pendiente de CDR— y algo que reaccione cuando la respuesta llega o cuando no llega. Escribimos aparte sobre cómo funciona la facturación electrónica de SUNAT y el papel del CDR.

Consecuencia práctica para el alcance: pregunta desde el día uno qué add-on de facturación electrónica usa el cliente y cómo se dispara. No es lo mismo que la emisión salga automática al crear el documento que dependa de un proceso programado — y eso decide si tu cliente recibe su comprobante en segundos o al día siguiente.

El Service Layer no orquesta por ti

La documentación es explícita en algo que se subestima: el Service Layer no constituye una integración completa por sí solo. La autenticación, las sesiones, los timeouts, los duplicados, los reintentos, los logs y las alertas los tiene que manejar tu solución.

Dos detalles que muerden en producción. El primero: las sesiones expiran, así que tu cliente HTTP necesita renovarlas solo, no fallar. El segundo, y el que más cuesta: los reintentos duplican documentos. Si tu proceso reintenta una factura porque no recibió respuesta —cuando en realidad sí se creó— acabas con dos comprobantes por una venta, y en un sistema con numeración fiscal eso no se borra: se anula, con nota de crédito.

La defensa es la misma de siempre: guardar en tu base la referencia del documento creado en SAP antes de dar el reintento por seguro, y consultar antes de volver a crear. Es exactamente el patrón de idempotencia que usamos en las pasarelas, aplicado al ERP.

Errores comunes al integrar pagos con SAP B1

Ninguno de los que más duelen es un error de código: son decisiones de modelo que nadie tomó al inicio.

Cómo lo hacemos

Integramos cobros con SAP Business One en producción: en el sistema de matrículas de un club de +50,000 asociados, cada matrícula factura sola en SAP B1 — con la cadena completa y el cuadre resuelto.

Conocemos las dos puntas del problema: la pasarela que cobra y el ERP que factura. Lo hicimos para el Club de Regatas Lima, donde además había que sostenerlo el día pico de matrícula. Si tu operación cobra por un lado y factura por otro, hablemos.

En resumen

Integrar pagos con SAP Business One no se gana en la llamada a la API: se gana en respetar el modelo. Cada cobro necesita su socio de negocio, su factura y su pago aplicado contra esa factura — y el eslabón que se olvida es el tercero, cuyo síntoma tarda semanas en aparecer. Suma que el Service Layer no orquesta por ti (sesiones, reintentos y duplicados son tuyos) y que en Perú el comprobante recién existe con el CDR de SUNAT. Modelada la cadena y montado el cuadre por período, la promesa se cumple sola: cada cobro, facturado, sin que nadie digite nada.