Desmitificando el desarrollo AL de Business Central: la analogía del edificio de oficinas
By Mirko Peters ·
Cuando gestionas un negocio moderno, tu sistema de planificación de recursos empresariales (ERP) está en el mismo centro de tus operaciones diarias. Plataformas como Dynamics 365 Business Centr…
Automatically translated with AI from the original post. Read the English original

Cuando diriges un negocio moderno, tu sistema de planificación de recursos empresariales está en el centro mismo de tus operaciones diarias. Plataformas como Dynamics 365 Business Central gestionan desde finanzas y gestión de clientes hasta inventario, pedidos de venta y facturas, directamente desde el primer momento. Sin embargo, los procesos de negocio reales rara vez se ajustan a un modelo único. ¿Qué ocurre cuando tu empresa necesita un paso de aprobación especializado, un campo de datos adicional, un cálculo único o una regla de negocio que no existe en la aplicación estándar? Durante mucho tiempo, personalizar un sistema ERP significaba caminar por una cuerda floja peligrosa entre conseguir la funcionalidad exacta que necesitabas y acabar atrapado en una pesadilla de fallos en las actualizaciones futuras. Hoy, gracias a los enfoques modernos de desarrollo, las cosas han cambiado por completo. En este artículo vamos a desgranar los conceptos detrás del modelo de extensiones moderno de Microsoft, explorar los componentes fundamentales del desarrollo en AL y ver por qué separar el código personalizado del núcleo de la aplicación es la clave definitiva para un ERP estable y preparado para el futuro.
Por qué las empresas personalizan sus sistemas ERP
Antes de entrar en cómo funciona el desarrollo, conviene entender por qué la personalización es necesaria. Business Central cubre una amplia gama de procesos de negocio estándar que se adaptan bien a muchas empresas tradicionales. Sin embargo, ninguna organización funciona exactamente igual que otra. Por ejemplo, un distribuidor de alimentos especializado puede necesitar un control estricto de lotes e indicadores de caducidad que van más allá del inventario básico. Una empresa de servicios regional podría necesitar un paso de aprobación interno adicional antes de que una factura pueda finalizarse. Un minorista especializado podría requerir niveles granulares de recompensas para clientes y un seguimiento de fidelización.
Estos requisitos únicos no justifican necesariamente reescribir por completo tus procesos de negocio ni abandonar tu ERP. A menudo, la empresa solo necesita que Business Central entienda un dato adicional o aplique una regla de validación interna concreta. El reto, históricamente, ha sido cómo implementar estos cambios de forma segura sin dañar la integridad subyacente del sistema.
La analogía del edificio de oficinas para las extensiones modernas
Para entender cómo funciona el desarrollo moderno sin perderse en la jerga técnica, conviene visualizar Business Central como un gran edificio de oficinas, diseñado por ingenieros profesionales. En los modelos de desarrollo de ERP más antiguos, personalizar un sistema solía parecerse a derribar muros de carga al azar, perforar nuevos huecos en forjados de hormigón y empalmar tuberías personalizadas directamente en la infraestructura principal cada vez que alguien quería una nueva sala. Aunque eso podía darte la sala que querías en el momento, hacía que mantener el edificio fuera increíblemente difícil. Cada vez que el constructor original pasaba a reparar el tejado o modernizar los cimientos, tus modificaciones personalizadas chocaban directamente con las actualizaciones, lo que provocaba conflictos costosos y estresantes.
El modelo de extensiones de Microsoft cambia esta arquitectura por completo. En la analogía del edificio de oficinas, Microsoft mantiene la estructura principal: el marco central, los protocolos de seguridad, los suministros y las oficinas estándar. Cuando tu organización necesita más espacio o funcionalidades personalizadas, no tocas la estructura interna del edificio principal. En su lugar, construyes módulos complementarios que se acoplan de forma segura a los puntos de conexión aprobados en el exterior del edificio. Tu funcionalidad personalizada se sitúa junto a la aplicación estándar como una unidad separada y autocontenida. Microsoft puede actualizar el edificio principal en cualquier momento, y tus añadidos personalizados permanecen seguros e intactos.
Comprender AL y el modelo de extensiones
AL son las siglas de Application Language. Es el lenguaje de programación especializado creado por Microsoft para desarrollar funcionalidades personalizadas específicamente para Dynamics 365 Business Central. Con AL, los desarrolladores pueden añadir, modificar y mejorar procesos de negocio, cálculos, validaciones, registros y páginas.
Lo más importante que hay que entender no es solo la sintaxis de AL en sí, sino el paradigma arquitectónico del modelo de extensiones. En versiones anteriores del producto, asociadas a menudo con el entorno de desarrollo heredado C/AL de Dynamics NAV, los desarrolladores solían modificar directamente los objetos originales de la aplicación. Aunque esto permitía una personalización profunda, creaba un acoplamiento estrecho entre el sistema base y tu código personalizado. Cada vez que Microsoft publicaba una actualización, los desarrolladores tenían que comparar y reconciliar manualmente el código fuente original con las modificaciones. El modelo de extensiones moderno de AL elimina este dolor de cabeza: tus modificaciones se empaquetan como extensiones independientes que se ejecutan junto al código estándar de la aplicación en lugar de sobrescribirlo.
Primero lo estándar, después personalizar
Que puedas personalizar Business Central no significa que siempre debas hacerlo. Cambiar un sistema solo porque su flujo de trabajo predeterminado se ve un poco distinto al de tu software anterior puede generar una carga de mantenimiento innecesaria a largo plazo. Las buenas prácticas en la administración de ERP siempre apuntan a la filosofía de «primero lo estándar, después personalizar».
Antes de escribir una sola línea de código AL, los equipos de desarrollo y los responsables de negocio deberían plantearse tres preguntas fundamentales: ¿Qué problema exacto están experimentando nuestros empleados? ¿Qué debería ocurrir en su lugar? ¿Puede Business Central estándar resolver ya esto si ajustamos el proceso de negocio? El desarrollo en AL debe reservarse para los escenarios en los que el producto estándar no cubre de verdad un requisito de negocio crítico.
Explicación de los bloques de construcción de AL
Cuando los desarrolladores crean una extensión, trabajan con componentes de programación específicos conocidos como objetos. Un objeto es una parte independiente de la aplicación diseñada para realizar una tarea concreta. Veamos los bloques de construcción principales que forman una solución en AL.
Tablas, campos y páginas
Las tablas funcionan como los archivadores digitales de Business Central y se encargan de almacenar los datos de forma segura. La tabla de clientes contiene los perfiles de cliente, la tabla de artículos almacena el inventario y las tablas transaccionales gestionan los documentos de venta. Dentro de estas tablas se encuentran los campos individuales, es decir, los atributos concretos como nombres, direcciones, números de teléfono y fechas.
Sin embargo, los datos almacenados en una tabla de base de datos no resultan muy útiles si los empleados no pueden interactuar con ellos. Aquí entran en juego las páginas. Las páginas determinan la presentación visual y las pantallas de la interfaz de usuario dentro de Business Central. Una ficha de cliente es una página diseñada para mostrar los detalles de un único registro, mientras que una página de lista muestra varios registros de un vistazo. En conjunto, las tablas almacenan los datos y las páginas se los presentan al usuario.
Extensiones de tabla y extensiones de página
¿Qué ocurre cuando Business Central estándar ya tiene casi todo lo que necesitas, pero requieres un dato adicional, como un nivel de recompensa de fidelidad personalizado para tus clientes? En lugar de crear una tabla de clientes completamente nueva que duplique los datos base existentes, un desarrollador crea una extensión de tabla. La tabla de clientes estándar permanece intacta y la extensión simplemente añade el nuevo campo junto a ella.
Por supuesto, añadir un campo a una tabla no lo hace visible automáticamente para tu personal. Para resolverlo, los desarrolladores utilizan extensiones de página. Una extensión de página inserta el nuevo campo, junto con los grupos, acciones o botones necesarios, directamente en las pantallas estándar de la interfaz de usuario de Business Central. Los empleados siguen trabajando en páginas estándar y conocidas, mientras la extensión muestra de forma transparente los datos especializados que tu negocio necesita.
Codeunits, disparadores y eventos
El almacenamiento de datos y las interfaces de usuario son fundamentales, pero las aplicaciones también necesitan lógica para calcular valores y procesar flujos de trabajo. Los codeunits proporcionan un espacio dedicado para esta lógica de negocio reutilizable. Por ejemplo, si tu nivel de recompensa de cliente determina un porcentaje de descuento concreto, ese código de cálculo puede residir en un codeunit centralizado en lugar de duplicarse de forma torpe en varias páginas e informes.
El código se ejecuta en puntos concretos del ciclo de vida de una aplicación, llamados desencadenadores (triggers). Un desencadenador se activa automáticamente cuando ocurre una acción específica, como cuando un usuario abre una página, modifica el valor de un campo o intenta registrar una factura. De forma similar, los eventos permiten que tus extensiones escuchen las notificaciones que emite la aplicación estándar. Business Central podría anunciar que un documento está a punto de registrarse, y tu extensión puede capturar ese evento al instante y ejecutar su propia lógica de validación personalizada en el momento exacto.
Conclusión: cómo mantener tu ERP preparado para las actualizaciones
Personalizar un sistema de planificación de recursos empresariales ya no tiene por qué ser una tarea arriesgada que rompa las actualizaciones. Al adoptar el modelo de extensiones moderno de Microsoft y aprovechar el potencial del desarrollo con AL, las organizaciones pueden adaptar Business Central exactamente a sus necesidades operativas, manteniendo el núcleo de la aplicación limpio y estable. Trata tu ERP como un edificio de oficinas bien diseñado: las adiciones personalizadas se conectan de forma segura al exterior en lugar de derribar la estructura interna. Así, tu negocio se mantiene ágil, eficiente y totalmente preparado para cada actualización de software futura.
Para profundizar en este tema y escuchar la opinión de expertos sobre las prácticas modernas de desarrollo, no dejes de revisar el episodio de podcast relacionado: Dynamics 365 Business Central AL Development.