Saltar al contenido
DisrupsoftDisrupsoft
General

Consultor SAP Business One: cuándo desarrollar a medida

Consultor SAP Business One: cuándo conviene un desarrollo a medida, qué herramienta usar (Service Layer, DI API, UI API) y cómo cuidar los upgrades.

Consultor SAP Business One: cuándo desarrollar a medida

El jefe de bodega pide un campo nuevo en la orden de compra. Ventas quiere que los pedidos de la tienda en línea entren solos al ERP. Finanzas necesita un aprobador más para pagos sobre cierto monto. Tres solicitudes razonables, tres caminos distintos, y el próximo upgrade de SAP Business One ya está en el calendario.

Cuando llamas a un consultor SAP Business One para un desarrollo a medida, lo primero que debería preguntarte es si hace falta construir algo. Una parte grande de lo que se pide como desarrollo se resuelve con configuración, campos de usuario o un flujo de aprobación estándar. Lo que sí requiere código conviene hacerlo con las herramientas que SAP mantiene entre versiones, porque cada feature pack vuelve a poner a prueba todo lo que agregaste encima.

Abajo van las opciones reales de desarrollo SAP B1, cuándo usar cada una y qué pedir para que tus add-ons de SAP Business One sobrevivan al próximo upgrade.

Antes de programar: lo que ya trae el estándar

Un consultor con experiencia agota estas opciones antes de cotizar horas de desarrollo:

  • Campos y tablas definidos por el usuario (UDF y UDT) para guardar datos que el estándar no contempla.
  • Objetos definidos por el usuario (UDO) cuando necesitas una entidad completa, con su propio formulario y numeración.
  • Procedimientos de aprobación y alertas configurables.
  • Búsquedas formateadas y consultas guardadas para autocompletar campos o validar datos.
  • Informes con las herramientas de reportería del producto antes de pensar en un desarrollo de impresión.

SAP documenta cómo crear campos y tablas de usuario en su portal de ayuda de SAP Business One 10.0, junto con el resto de la documentación para desarrolladores. Si el requerimiento cabe aquí, el costo de mantenerlo en cada upgrade es casi cero.

Las herramientas de desarrollo SAP B1 y cuándo usar cada una

Cuando el estándar no alcanza, hay varias vías. No son intercambiables, y una mala elección se paga en el siguiente upgrade.

HerramientaQué esÚsala paraOjo con
Service LayerAPI sobre HTTP con protocolo ODataIntegraciones nuevas: e-commerce, CRM, apps móviles, Power PlatformRevisar que el objeto que necesitas esté expuesto en tu feature pack
DI APIAPI COM que da acceso a los objetos de negocio de SAP B1Add-ons de escritorio existentes o procesos que la usan desde hace añosDesde la versión 10.0 solo se soportan add-ons de 64 bits
UI APIAPI COM que modifica la interfaz del cliente de escritorio en tiempo de ejecuciónAgregar campos, botones o validaciones en pantallas del cliente de escritorioEs la capa que más se rompe con cambios de menús y formularios
Extensiones del Web ClientAplicaciones web desplegadas con Extension ManagerNuevas experiencias para usuarios que trabajan en el navegadorUn add-on de escritorio no corre automáticamente en el Web Client
SAP Business One StudioEntorno de desarrollo basado en .NETDiseñar formularios y extensiones; reemplazó al antiguo Screen PainterRequiere un equipo que conozca el SDK

Las descripciones de DI API, UI API y Studio salen de la guía de componentes de cliente de SAP. El retiro del Screen Painter y el soporte exclusivo de 64 bits están en el documento oficial Compatibility Issues in SAP Business One 10.0.

Para casi cualquier integración nueva, el Service Layer es el punto de partida razonable. Habla HTTP, lo consume cualquier lenguaje y desde el FP 2602 permite webhooks para avisar a otros sistemas cuando ocurre algo en SAP B1, en vez de consultarlo cada pocos minutos.

Cuándo sí conviene un desarrollo a medida

Hay casos en que programar es la decisión correcta:

  • Integraciones con sistemas que tu negocio no puede soltar: tienda en línea, WMS, un sistema de terreno o la plataforma de un cliente grande.
  • Procesos propios que te diferencian y que ningún add-on del mercado cubre bien.
  • Automatizaciones que eliminan digitación repetida entre SAP B1 y otras herramientas, como aprobaciones en Teams o carga de documentos de proveedores.
  • Analítica que cruza datos del ERP con otras fuentes, algo que muchas veces se resuelve mejor fuera de SAP, en Power BI, que dentro.

En estos casos la pregunta pasa a ser dónde vive el desarrollo. Una regla práctica: mientras menos código corra dentro del cliente de SAP, menos se rompe en cada upgrade. Una integración por Service Layer o un flujo en Power Automate queda fuera del ERP y solo depende de la API. Un add-on de UI API vive dentro de cada pantalla que toca.

Cuándo no

También hay señales claras de que el desarrollo es mala idea:

  • El requerimiento repite algo que el estándar ya hace, pero "a la manera de siempre". Ahí conviene ajustar el proceso antes que el sistema.
  • Existe un add-on de un proveedor reconocido que hace lo mismo y se mantiene con cada versión.
  • La solución propuesta escribe directo en las tablas de SAP con SQL o triggers. Esa vía se salta la lógica de negocio del ERP y es una fuente conocida de datos inconsistentes. Para escribir datos están el DI API y el Service Layer.
  • Nadie va a mantener el código. Un desarrollo sin fuentes entregadas ni documentación se convierte en el obstáculo del próximo upgrade.

Upgrades: donde los desarrollos muestran lo que valen

SAP entrega la innovación de la versión 10.0 en feature packs acumulativos, que según su página de upgrades incluyen funciones nuevas, correcciones, parches de seguridad y cambios legales. Quedarse varios feature packs atrás tiene costo. La versión 10.0 tiene mantenimiento principal hasta el 31 de diciembre de 2028, según la estrategia de mantención de SAP, con la versión 11 en el horizonte.

Cada salto pone a prueba lo que agregaste. SAP advierte en su documento de compatibilidad que los add-ons que dependen de la estructura de la base de datos pueden tener problemas adicionales. Antes de cualquier upgrade, pide a tu partner:

  1. Un inventario de add-ons, integraciones, UDO y procedimientos almacenados, con su dueño.
  2. Pruebas en una copia de la base, con el feature pack y parche exactos de destino.
  3. Confirmación de compatibilidad de cada add-on de terceros con esa versión.
  4. Para add-ons propios, recompilar y probar la instalación, el arranque y los flujos principales, no solo que "abra".
  5. Revisar el archivo de registro (ARD) de cada add-on si quieres que el cliente lo actualice en modo silencioso, como indica la guía de administración de SAP.

Si tu contrato de soporte no dice quién hace este trabajo, revisa qué debe incluir tu contrato de soporte SAP Business One antes de la próxima renovación.

Qué pedirle a un consultor SAP Business One antes de aprobar un desarrollo

Una propuesta seria responde estas preguntas por escrito:

  • ¿Se probó resolverlo con configuración, UDF o UDO? ¿Por qué no alcanzó?
  • ¿Qué herramienta se usará (Service Layer, DI API, UI API, Web Client) y por qué esa?
  • ¿El desarrollo escribe datos por las APIs de SAP o toca la base de datos directamente?
  • ¿Quién es dueño del código fuente y dónde se entrega?
  • ¿Qué documentación queda y quién la actualiza?
  • ¿Cuántas horas estima para revisarlo en cada feature pack?

Si la respuesta a la última pregunta es "cero", desconfía. Todo desarrollo tiene un costo de mantención, y es mejor conocerlo desde el principio.

Preguntas frecuentes

¿Qué conviene más para integrar SAP Business One: Service Layer o DI API?

Para integraciones nuevas, normalmente el Service Layer, porque funciona sobre HTTP y lo consume cualquier plataforma. El DI API sigue siendo válido para add-ons existentes o cuando necesitas un objeto que el Service Layer no expone en tu versión.

¿Mis add-ons dejan de funcionar con cada feature pack?

No necesariamente, pero hay que probarlos siempre. Los que más riesgo tienen son los que modifican la interfaz de escritorio o dependen de la estructura interna de la base de datos.

¿Puedo usar Power Platform con SAP Business One?

Sí. Power Apps, Power Automate y Power BI pueden trabajar con datos de SAP B1, normalmente a través del Service Layer con un conector personalizado o una capa de integración. Es una buena forma de agregar aprobaciones, formularios o tableros sin meter código dentro del ERP.

Conversemos sobre tu próximo desarrollo

En Disrupsoft trabajamos con empresas que ya usan SAP Business One: integraciones con Service Layer y DI API, extensiones con Power Apps y Power Automate, analítica en Power BI, migraciones y upgrades, y soporte correctivo y evolutivo. Si tienes una lista de requerimientos y no sabes cuáles necesitan código, partimos por revisarla contigo. Conoce más en nuestra página de servicios SAP.

SAP Business OneERPDesarrollo de SoftwareIntegracionesPartner SAP

← Ver más artículos