Framework modular de add-ons para SAP Business One

Problema

Las implantaciones de un ERP a medida comparten la mayor parte de la funcionalidad y se diferencian en una parte pequeña. Si cada cliente nuevo arranca copiando el código del anterior, esa parte común acaba convertida en tantas versiones distintas como clientes haya, cada una con sus propias correcciones a medias.

Solución

Este es el núcleo común del que parten todas las implantaciones. Más de 40 módulos funcionales conviven en la misma base de código: reservas de stock, ofertas, tarifas, obras, expedición, orden de carga, precio medio ponderado, gestión bancaria y trazabilidad, entre otros.

Cada módulo se activa o se desactiva por cliente. Un gestor de módulos con sus propias interfaces decide qué se carga, qué entradas de menú aparecen y qué manejadores de eventos se registran, de forma que el add-on de un cliente no arrastra pantallas de funcionalidad que no usa.

La parte de base de datos también está gobernada. La creación de procedimientos almacenados es controlada y los disparadores se validan antes de darlos por buenos: en un ERP, un objeto de base de datos mal desplegado no se nota en la pantalla, se nota en los números del cierre.

El mismo código funciona sobre SQL Server y sobre SAP HANA, que no son intercambiables ni en dialecto ni en comportamiento.

Arquitectura

Add-on del cliente (configuracion de modulos activos)
                   |
                   v
           Gestor de modulos
                   |
    +----------+---+---------+----------+
    |          |             |          |
    v          v             v          v
 Reservas   Ofertas     Expedicion    ... 40+
    |          |             |          |
    +----------+---+---------+----------+
                   |
                   v
          Capa de acceso a datos
           |                    |
           v                    v
    DI API / UI API     SQL Server / SAP HANA

Por qué está montado así

Cada módulo se activa por configuración. No hay una rama por cliente, así que cuando arreglo algo lo arreglo una vez.

Los módulos se cargan a través de una interfaz y el gestor no necesita saber qué hay dentro de cada uno.

No dejé que los procedimientos almacenados y los disparadores se crearan a mano. Un objeto mal desplegado en base de datos no lanza ninguna excepción: aparece en los números del cierre, semanas después, y para entonces nadie recuerda qué se tocó.

El soporte de SQL Server y HANA vive en la capa de acceso a datos. Si cada módulo tuviera que resolver las diferencias de dialecto, serían cuarenta sitios donde equivocarse.

Los datos van por DI API y las pantallas por UI API. Cambiar un formulario no debería obligar a tocar la lógica de negocio.

Resultado

343 clases y 71 formularios en el núcleo común, con 153 commits míos y unas 122.000 líneas aportadas desde 2025. Cada implantación nueva empieza aquí.