Desarrollo a la medida en SAP Business One: guía para decidir bien

El desarrollo SAP Business One no empieza con una línea de código. Empieza con una pregunta: ¿qué parte de su operación realmente no cabe en el producto? En una pyme o mediana empresa mexicana, la respuesta suele ser más pequeña de lo que parece al inicio del proyecto, y entender esa diferencia es lo que separa una implementación sana de una que se vuelve cara de mantener.

Esta página recorre las cuatro capas de personalización de SAP Business One, de la más ligera a la más pesada, y explica qué se gana y qué se arriesga en cada una. También cubre el efecto sobre las actualizaciones, las buenas prácticas para mantenerse cerca del estándar y los criterios para evaluar a quien va a desarrollar.

Las cuatro capas de personalización

Conviene pensar en escalera. Se sube un peldaño solo cuando el anterior no resuelve la necesidad.

Primera capa: parametrizar bien

La mayor parte de lo que una empresa cree que necesita programar se resuelve aquí. Series de numeración por sucursal, reglas de autorización por monto o por usuario, cuentas contables por tipo de operación, condiciones de pago, listas de precios: todo eso es configuración, no desarrollo. Una implementación bien parametrizada ahorra semanas de trabajo posterior. Si quiere ver cómo se organiza el arranque del proyecto, la guía de implantación de SAP Business One detalla el orden de trabajo.

Segunda capa: campos, tablas, objetos y consultas

SAP Learning presenta, en su curso de implementación, las herramientas de personalización que el propio producto trae: campos definidos por el usuario (UDF), tablas (UDT), objetos (UDO) y valores (UDV), además de consultas SQL, alertas y flujos de aprobación. Con ellas se resuelven necesidades muy frecuentes:

• Añadir a la ficha del cliente un dato que su área comercial exige, como la ruta de reparto o el ejecutivo de cuenta.
• Crear una tabla propia para un catálogo interno que no existe en el estándar.
• Mostrar en una pantalla el resultado de una consulta, por ejemplo las facturas vencidas de un cliente mientras se captura un pedido.
• Disparar una alerta al contador o al gerente de compras cuando se cumple una condición.
• Pedir una aprobación escalonada antes de confirmar una orden de compra.

Su gran ventaja es que viven dentro del producto y siguen los mecanismos que SAP mantiene entre versiones. Su límite: no sirven para lógica compleja que cruce varios procesos o hable con sistemas externos.

Tercera capa: extensiones que ya existen

Antes de encargar un desarrollo, revise si alguien ya lo hizo. SAP indica que SAP Business One se distribuye a través de 850 partners y que existen más de 500 extensiones sectoriales y por país, según su comunicado de diciembre 2025. Para necesidades verticales (manufactura, distribución, servicios, construcción) o para integraciones comunes, es probable que haya una solución probada. Comprar una extensión suele costar menos que desarrollarla, y el mantenimiento recae en su proveedor. Los sectores donde esto más se aprovecha están descritos en la página de SAP Business One por sector.

Una extensión de catálogo no es automáticamente segura. Pregunte siempre por la versión de SAP Business One con la que es compatible, por cuánto tarda el proveedor en certificar una versión nueva y por quién da soporte cuando algo falla.

Cuarta capa: desarrollo específico

Cuando las tres capas anteriores no bastan, se programa. Aquí el producto ofrece varias interfaces, y elegir la correcta importa.

Con qué se desarrolla: SDK, DI API, Service Layer e Integration Framework

SAP Business One es, en palabras de SAP Learning, un núcleo ERP pensado para extenderse, que se enriquece con servicios de SAP Business Technology Platform, inteligencia artificial y aprendizaje automático, con plantillas de automatización accesibles mediante el Business Accelerator Hub y SAP Build. Para el trabajo de desarrollo propiamente dicho, hay cuatro piezas que debe conocer.

El SDK y la DI API

El Software Development Kit es la base histórica para escribir add-ons. La DI API permite leer y escribir objetos de negocio (pedidos, facturas, socios de negocio) respetando las reglas del producto, no insertando filas directamente en la base de datos. Esa distinción es la primera regla de oro: nunca escribir en las tablas de SAP Business One por SQL directo. Una escritura directa se salta validaciones y puede dejar la contabilidad inconsistente, algo que el contador descubre al cierre del mes.

El Service Layer

El Service Layer es una API de extensión REST basada en HTTP y OData, con intercambio en JSON. Según el documento de SAP de julio de 2026, acepta OData v3 en /b1s/v1/$metadata y OData v4 en /b1s/v2/$metadata. Funciona sobre SUSE Linux Enterprise y sobre Microsoft Windows (desde la 10.0 PL01), usa el servidor Apache como balanceador de carga, puede desplegarse en modo integrado o distribuido y comparte con la DI API las mismas definiciones de objetos gracias al componente DI Core. SAP Learning añade que implementa los esquemas de autenticación Basic y OAuth y que busca facilitar el desarrollo de aplicaciones web y móviles.

En la práctica, el Service Layer es la vía natural para una tienda en línea que consulta existencias, una aplicación móvil de vendedores en ruta o un portal de clientes. Quien construye sobre REST puede además separar su aplicación del servidor de SAP, lo que simplifica las pruebas y las actualizaciones. Para escenarios de conexión con otros sistemas, la página de integraciones de SAP Business One amplía el panorama.

El Integration Framework

SAP lo presenta como parte integral de SAP Business One, utilizable tanto en instalación propia como en la nube. Sirve de entorno de desarrollo y ejecución de escenarios de integración: tableros, aplicaciones móviles, nómina externalizada, solicitud de cotización automatizada, servicios web y aplicaciones SAP y de otros fabricantes. Es la opción razonable cuando el objetivo es mover información entre sistemas, no agregar pantallas.

¿Hay que pagar por las herramientas?

Según la guía de licencias de SAP, las licencias de usuario incluyen automáticamente, sin solicitud aparte, el SDK en su versión de implementación, las SDK Tools, los SAP AddOns, la licencia de compatibilidad para add-ons y el Workflow, cada uno con 99 999 usuarios. Es decir, la herramienta no es el costo: el costo es la mano de obra. El panorama de costos completo está en la página de precios de SAP Business One.

Módulos a la medida: ejemplos realistas para una empresa mexicana

Un módulo sobre medida rara vez es una pantalla nueva. Lo habitual es una combinación de dato adicional, regla de validación y reporte. Algunos casos que aparecen en empresas del país:

• Comisiones de vendedores con reglas propias por línea de producto, cliente o cobranza efectiva, calculadas al cobrarse la factura y no al emitirse.
• Conciliación de cobranza que cruza los complementos de pago del CFDI con los cobros registrados, para que el contador no lo haga a mano al cierre. Para el marco fiscal, consulte la guía de CFDI y ERP.
• Portal de proveedores donde el proveedor consulta el estatus de sus facturas y órdenes de compra sin llamar a cuentas por pagar.
• Captura en piso para registrar producción o merma desde una tableta, con validación contra la orden de fabricación.
• Etiquetado y embarques con formatos exigidos por un cliente grande o por la cadena de autoservicio a la que usted surte.

En cada uno, la pregunta de fondo es la misma: ¿este proceso me diferencia de mis competidores, o solo estoy imitando cómo lo hacía el sistema anterior? Si es lo segundo, lo más barato suele ser cambiar el proceso y no el sistema. La página sobre SAP Business One en México explica qué cubre la localización mexicana, para no programar lo que ya viene resuelto.

Impacto en las actualizaciones

Cada personalización es una promesa de mantenimiento. Lo que usted programa hoy debe seguir funcionando cuando cambie de versión, y eso no es automático.

Los puntos de fricción más comunes:

1. Add-ons que dependen de comportamientos internos que cambian entre versiones.
2. Formularios o informes modificados que se pisan al actualizar.
3. Integraciones que usan una versión antigua de la interfaz (por ejemplo, una versión de OData que deja de recomendarse).
4. Extensiones de terceros que no están certificadas todavía para la versión nueva.
5. Personalizaciones sin documentación, donde nadie recuerda por qué existen.

La mitigación es un hábito, no una herramienta: entorno de pruebas separado de producción, una lista de personalizaciones con su responsable, y una prueba de regresión antes de cada actualización. La página de versiones y ediciones de SAP Business One ayuda a planear el calendario, y la de soporte y mantenimiento describe qué debe cubrir un contrato posterior a la salida en vivo.

Buenas prácticas: estándar primero, documentar, probar

Quedarse en el estándar el mayor tiempo posible

Cada desarrollo agregado es una pieza más que probar, actualizar y explicar al siguiente responsable de sistemas. Una regla sencilla: si una necesidad la tienen otras empresas de su giro, probablemente el producto o una extensión ya la cubre. Reserve el desarrollo para lo que de verdad es suyo.

Documentar como si fuera a irse el autor

Para cada personalización, un documento breve con: qué hace, por qué existe, quién la pidió, qué objetos toca, qué interfaz usa y cómo se prueba. Si el desarrollador se va, o si cambia de integrador, ese documento vale más que el código. Un proyecto sin documentación queda atado a una sola persona, y es una de las causas que se repiten en los errores de un proyecto ERP.

Probar en tres niveles

• Prueba técnica, del desarrollador: funciona con datos de ejemplo.
• Prueba funcional, del usuario clave: funciona con sus datos reales y su forma de trabajar.
• Prueba de regresión, antes de cada actualización: lo nuevo no rompió lo anterior.

Las pruebas se hacen en un entorno que no sea producción. Si su servidor está alojado por un tercero, revise qué opciones ofrece la página de alojamiento en la nube para tener un entorno de pruebas.

Pedir el código y los accesos

Aclare por escrito de quién es el código, dónde se guarda y quién puede modificarlo. Un add-on cuyo código solo existe en la computadora de un freelance es un riesgo operativo.

Cómo evaluar a un desarrollador o a un integrador de SAP Business One

Hay dos perfiles distintos y conviene no mezclarlos: el integrador que lleva el proyecto completo y el desarrollador especializado al que se le encarga una pieza. En ambos casos, las preguntas útiles son concretas.

Preguntas sobre experiencia

• ¿Puede explicarme, sin nombrar al cliente, un proyecto parecido al mío de principio a fin?
• ¿Qué interfaz eligió (DI API, Service Layer, Integration Framework) y por qué?
• ¿Qué personalizó y qué dejó en estándar?

Preguntas sobre método

• ¿Cómo documenta y dónde entrega esa documentación?
• ¿Cómo separa desarrollo, pruebas y producción?
• ¿Qué pasa con mi desarrollo cuando salga una versión nueva y quién lo adapta?

Preguntas sobre el contrato

• ¿De quién es el código fuente?
• ¿Cómo se cobra una corrección de un defecto frente a una mejora?
• ¿Qué cobertura de soporte existe después de la entrega?

Señales de alerta: promesas de que «todo se puede hacer» sin revisar antes la operación; propuestas que saltan directo a programar; escritura directa en la base de datos; ausencia total de documentación; y ninguna pregunta sobre su contabilidad, su cierre o sus obligaciones con el SAT. Un buen perfil hace preguntas incómodas sobre su proceso antes de cotizar.

Para un criterio más amplio de selección, vea la guía de cómo elegir un integrador de ERP y la página específica de integradores de SAP Business One.

Lista de verificación antes de aprobar un desarrollo

1. ¿Se intentó resolver con parámetros, campos de usuario, consultas o alertas?
2. ¿Se buscó una extensión ya existente y se comparó contra el costo de desarrollar?
3. ¿Se eligió la interfaz adecuada (DI API, Service Layer o Integration Framework) y está justificada?
4. ¿Está definido quién mantiene el desarrollo y cómo se actualiza con cada versión?
5. ¿Hay documentación, entorno de pruebas y criterios de aceptación escritos?
6. ¿El código y los accesos son suyos?

Si responde «sí» a todo, el desarrollo es una inversión controlada. Si responde «no» a varias, el riesgo es que la personalización se convierta en una deuda que cada actualización encarece.

Si quiere que un integrador SAP Business One revise su caso y le diga qué conviene parametrizar, comprar o programar, puede solicitar una mesa de revisión a través del servicio gratuito de mise en relación de Integrador ERP. Nosotros no desarrollamos ni implementamos: lo ponemos en contacto con un integrador adecuado a su proyecto y a su estado.

Los nombres de software mencionados son marcas de sus respectivos editores y se citan únicamente a título informativo. Este sitio es independiente y no está afiliado a ningún editor.