Extensión AL o configuración en Business Central
¿Configurar o desarrollar? Criterios, ejemplos en AL y una guía de decisión para elegir la mejor opción en Business Central y ahorrar costes.
Cuando una empresa nos pide "adaptar Business Central", la primera pregunta que hacemos no es qué código escribir, sino si hace falta escribirlo. Una extensión AL bien justificada ahorra horas cada día; una extensión innecesaria añade coste de mantenimiento en cada actualización. Esta guía le ayuda a decidir.
Primero, agote la configuración estándar
Business Central ofrece mucho sin una sola línea de AL. Antes de plantear desarrollo, compruebe si estas opciones cubren la necesidad:
Campos personalizados mediante la personalización de páginas (Personalizar) y la opción de mostrar campos ocultos de la tabla.
Flujos de trabajo de aprobación (Workflows) para pedidos, facturas, gastos o cambios de datos maestros.
Dimensiones y valores de dimensión para analizar ventas, compras o proyectos sin tocar tablas.
Plantillas de configuración y plantillas de cliente, proveedor o artículo para acelerar altas.
Power Automate y Power BI, que resuelven integraciones y análisis habituales sin extender la aplicación.
Diseños de informes de Word y Excel que Business Central ya permite asignar por documento.
La regla práctica: si la necesidad se resuelve con configuración, configure. Es reversible, la entiende el usuario clave y no depende de un desarrollador.
Señales de que necesita una extensión AL
Hay situaciones donde la configuración llega a su límite. Estas son las más frecuentes en proyectos reales.
1. Datos que el estándar no almacena
Si necesita guardar, por ejemplo, un "Margen %" objetivo en la ficha de proyecto o una clasificación propia en el cliente, hace falta ampliar la tabla. En AL se resuelve con una extensión de tabla y de página:
tableextension 50100 "Job Margin Ext" extends Job
{
fields
{
field(50100; "Margen %"; Decimal)
{
Caption = 'Margen %';
DecimalPlaces = 0 : 2;
}
}
}
Con una extensión de página, ese campo aparece en la ficha del proyecto. Es un cambio pequeño, pero imposible de lograr solo con configuración.
2. Reglas de negocio propias
Validaciones que dependen de varios datos, por ejemplo impedir registrar un pedido de venta si el cliente supera cierto riesgo y el descuento supera un umbral. En AL se programa suscribiéndose a eventos del estándar, sin modificar el código base:
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforePostSalesDoc', '', false, false)]
local procedure ValidarDescuento(var SalesHeader: Record "Sales Header")
begin
// Lógica propia de validación
end;
El uso de eventos es la clave de la compatibilidad: su lógica convive con las actualizaciones de Microsoft.
3. Informes y documentos que el estándar no cubre
Informes de contratación, margen comercial o comisiones requieren combinar tablas y cálculos. Aquí se desarrolla un informe con un dataset AL y un diseño RDLC o Word. Si solo cambia el aspecto de un documento existente (factura, oferta), muchas veces basta un diseño Word sin tocar el dataset.
4. Integraciones con otros sistemas
Conectar con una tienda online, un transportista o un sistema de fichaje exige consumir o publicar servicios web. Puede apoyarse en las API estándar de Business Central, pero si el sistema externo necesita un formato propio, se desarrolla una API personalizada (page de tipo API) o una codeunit que llame al servicio externo.
5. Automatización de procesos repetitivos
Tareas por lotes, generación masiva de documentos o cálculos periódicos se programan como codeunits ejecutadas desde la cola de proyectos. Si su equipo repite la misma secuencia de clics cada semana, probablemente merezca automatizarse.
Criterios para decidir con números
Antes de aprobar un desarrollo, haga tres preguntas:
Frecuencia: ¿cuántas veces al mes se usa? Una tarea mensual de 20 minutos rara vez justifica código; una diaria de 15 minutos sí.
Alternativa estándar: ¿existe un campo, flujo de trabajo o extensión de AppSource que lo haga razonablemente bien? Un 80 % cubierto por el estándar suele ser mejor que un 100 % a medida.
Coste de mantenimiento: cada extensión debe probarse en las dos actualizaciones mayores anuales de Business Central. Si el desarrollo es pequeño y está bien hecho con eventos, ese coste es bajo.
Una comparación orientativa:
Aprobar pedidos por importe: flujo de trabajo estándar; extensión AL solo si la regla depende de datos propios.
Analizar ventas por zona: dimensiones; no hace falta extensión.
Campo nuevo en ficha de proyecto: no es posible configurando; extensión de tabla y página.
Informe de comisiones: parcial con Excel o Power BI; informe con dataset propio.
Integración con terceros: Power Automate en casos simples; API o codeunit a medida.
Buenas prácticas para que la extensión no se convierta en un problema
Si finalmente necesita desarrollo, estas pautas reducen riesgos:
Use extensiones, nunca modificaciones del código base. Es el único modelo soportado en Business Central online.
Prefiera eventos y tablas/páginas de extensión frente a sustituir lógica estándar.
Nombre los objetos con su rango de identificadores asignado y un prefijo propio, para evitar conflictos con otras extensiones.
Mantenga el código en control de versiones y pruebe cada versión en un sandbox antes de pasar a producción.
Documente qué hace cada objeto: dentro de dos años alguien, quizá usted, lo agradecerá.
Un ejemplo de decisión
Imaginemos una empresa de servicios (caso hipotético) que quiere ver el margen previsto en cada proyecto y recibir un aviso cuando baje de un umbral. El flujo de trabajo no basta porque el estándar no tiene ese campo; se resuelve con una extensión de tabla, un campo en la ficha y una validación por evento. Todo en una extensión pequeña, fácil de actualizar. Es un ejemplo ilustrativo, no un cliente real, de cómo se reparte el trabajo entre configuración y código.
¿Configurar o desarrollar? Lo revisamos juntos
Si duda entre ambas vías, en una reunión de 30 minutos podemos revisar su necesidad concreta y decirle con franqueza si basta con configurar o si compensa una extensión AL. Reserve una reunión aquí o escríbanos a info@ijgconsulting.com.tableextension 50100 "Job Margin Ext" extends Job
{
fields
{
field(50100; "Margen %"; Decimal)
{
Caption = 'Margen %';
DecimalPlaces = 0 : 2;
}
}
}[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforePostSalesDoc', '', false, false)]
local procedure ValidarDescuento(var SalesHeader: Record "Sales Header")
begin
// Lógica propia de validación
end;