Business Central AL-ontwikkeling ontmaskeren: de analogie van het kantoorgebouw

By Mirko Peters · 2026-08-27

Wanneer je een modern bedrijf runt, vormt je ERP-systeem (enterprise resource planning) het hart van je dagelijkse werkzaamheden. Platforms zoals Dynamics 365 Business Centr…

Automatically translated with AI from the original post. Read the English original

Bij het runnen van een moderne onderneming vormt je ERP-systeem het hart van de dagelijkse werkzaamheden. Platforms als Dynamics 365 Business Central regelen direct na installatie alles, van financiën en klantbeheer tot voorraad, verkooporders en facturen. Echte bedrijfsprocessen passen echter zelden in één standaardmodel. Wat gebeurt er als je bedrijf een specifieke goedkeuringsstap nodig heeft, een extra datumveld, een eigen berekening of een bedrijfsregel die niet in de standaardapplicatie zit? Lange tijd betekende het aanpassen van een ERP-systeem balanceren op een gevaarlijk koord: je kreeg de functionaliteit die je nodig had, maar je zette jezelf vast in een nachtmerrie van upgrades die misgaan. Dankzij moderne ontwikkelmethoden is dat nu fundamenteel veranderd. In deze blogpost laten we de concepten achter het moderne extensiemodel van Microsoft zien, bespreken we de belangrijkste bouwstenen van AL-ontwikkeling en kijken we waarom het scheiden van maatwerkcode en de kernapplicatie dé sleutel is tot een stabiel, toekomstbestendig ERP.

Waarom bedrijven hun ERP-systeem aanpassen

Voordat we ingaan op hoe ontwikkeling werkt, is het handig om eerst te begrijpen waarom aanpassing überhaupt nodig is. Business Central dekt een groot aantal standaardbedrijfsprocessen die veel traditionele bedrijven goed passen. Toch werkt geen enkele organisatie precies hetzelfde. Een gespecialiseerde voedingsgroothandel heeft bijvoorbeeld strikte batchtraceerbaarheid en houdbaarheidsgegevens nodig die verder gaan dan basisvoorraadbeheer. Een regionaal servicebedrijf wil misschien een extra interne goedkeuring voordat een factuur definitief wordt gemaakt. Een gespecialiseerde retailer heeft mogelijk fijnmazige klantbeloningsniveaus en loyaliteitsregistratie nodig.

Deze specifieke eisen betekenen niet automatisch dat je je bedrijfsprocessen helemaal moet herschrijven of afscheid moet nemen van je ERP. Vaak heeft het bedrijf simpelweg nodig dat Business Central één extra gegevenspunt begrijpt of één specifieke interne validatieregel afdwingt. De uitdaging was tot nu toe vooral hoe je die wijzigingen veilig doorvoert zonder de integriteit van het systeem aan te tasten.

De analogie van het kantoorgebouw voor moderne extensies

Om te begrijpen hoe moderne ontwikkeling werkt zonder je in technisch jargon te verliezen, helpt het om Business Central te zien als een groot, professioneel ontworpen kantoorgebouw. In oudere ERP-ontwikkelmodellen voelde het aanpassen van een systeem vaak alsof je willekeurig dragende muren sloopt, nieuwe gaten door betonnen vloeren boort en eigen leidingen direct in de hoofdinfrastructuur aansluit zodra iemand een nieuwe kamer wilde. Dat leverde je misschien meteen de kamer op die je wilde, maar het onderhoud van het gebouw werd er ongelooflijk moeilijk door. Telkens als de oorspronkelijke bouwer langskwam om het dak te vernieuwen of de fundering te moderniseren, botsten jouw aanpassingen direct met de updates, wat leidde tot dure en stressvolle conflicten.

Het extensiemodel van Microsoft verandert deze architectuur volledig. In de analogie van het kantoorgebouw onderhoudt Microsoft de hoofdstructuur: het kernraamwerk, de veiligheidsvoorzieningen, de nutsvoorzieningen en de standaardkantoren. Wanneer je organisatie extra ruimte of aangepaste functies nodig heeft, sleutel je niet aan het interne raamwerk van het hoofdgebouw. In plaats daarvan bouw je modulaire aanbouwen die veilig aansluiten op goedgekeurde aansluitpunten aan de buitenkant van het gebouw. Je eigen functionaliteit staat naast de standaardapplicatie als een afzonderlijk, zelfstandig onderdeel. Microsoft kan het hoofdgebouw op elk moment upgraden, en je eigen aanbouwen blijven veilig en intact.

AL en het extensiemodel begrijpen

AL staat voor Application Language. Het is de gespecialiseerde programmeertaal die Microsoft heeft ontwikkeld voor het bouwen van maatwerkfunctionaliteit voor Dynamics 365 Business Central. Met AL kunnen ontwikkelaars bedrijfsprocessen, berekeningen, validaties, records en pagina's toevoegen, wijzigen en uitbreiden.

Het belangrijkste concept om te begrijpen is niet alleen de syntaxis van AL zelf, maar vooral het architectonische paradigma van het extensiemodel. In oudere versies van het product – vaak geassocieerd met de legacy C/AL-ontwikkelomgeving in Dynamics NAV – pasten ontwikkelaars de originele applicatieobjecten vaak rechtstreeks aan. Dat bood veel aanpassingsmogelijkheden, maar het zorgde ook voor een strakke koppeling tussen het kernsysteem en je eigen code. Telkens wanneer Microsoft een update uitbracht, moesten ontwikkelaars de originele broncode handmatig vergelijken met de aanpassingen en ze opnieuw op elkaar afstemmen. Het moderne AL-extensiemodel neemt die hoofdpijn weg: je aanpassingen worden verpakt als onafhankelijke extensies die naast de standaardapplicatiecode draaien, in plaats van die code te overschrijven.

Eerst standaard, dan aanpassen

Omdat je Business Central kunt aanpassen, betekent dat nog niet dat je het ook altijd moet doen. Een systeem wijzigen alleen omdat de standaardworkflow er net iets anders uitziet dan je oude software, kan onnodig veel onderhoudslast op de lange termijn veroorzaken. Best practices in ERP-beheer gaan altijd uit van de filosofie ‘eerst standaard, dan aanpassen’.

Voordat je ook maar één regel AL-code schrijft, moeten ontwikkelteams en business-leiders drie fundamentele vragen stellen: welk precies probleem ervaren onze medewerkers? Wat zou er in plaats daarvan moeten gebeuren? Kan standaard Business Central dit al oplossen als we ons bedrijfsproces aanpassen? AL-ontwikkeling moet worden voorbehouden aan situaties waarin het standaardproduct echt tekortschiet voor een kritieke zakelijke eis.

Belangrijkste AL-bouwstenen uitgelegd

Wanneer ontwikkelaars een extensie bouwen, werken ze met specifieke programmeeronderdelen die objecten worden genoemd. Een object is een afzonderlijk onderdeel van de applicatie dat is ontworpen om een bepaalde taak uit te voeren. Laten we de belangrijkste bouwstenen van een AL-oplossing eens bekijken.

Tabellen, velden en pagina’s

Tabellen fungeren als de digitale archiefkasten van Business Central en zijn verantwoordelijk voor het veilig opslaan van gegevens. De klantentabel bevat klantprofielen, de artikeltabel slaat voorraad op en transactietabellen verwerken verkoopdocumenten. Binnen deze tabellen staan afzonderlijke velden – de specifieke kenmerken zoals namen, adressen, telefoonnummers en datums.

Gegevens in een databasetabel zijn echter weinig nuttig als medewerkers er niet mee kunnen werken. Hier komen pagina’s om de hoek kijken. Pagina’s bepalen de visuele weergave en de gebruikersschermen binnen Business Central. Een klantkaart is een pagina die de details van één record toont, terwijl een lijstpagina meerdere records in één oogopslag weergeeft. Samen slaan tabellen de gegevens op, en tonen pagina’s ze aan de gebruiker.

Tabeluitbreidingen en paginauitbreidingen

Wat als standaard Business Central vrijwel alles biedt wat je nodig hebt, maar je één extra gegevenspunt mist, zoals een eigen loyaliteitsniveau voor je klanten? In plaats van een volledig nieuwe klantentabel te bouwen die bestaande kerngegevens dupliceert, maakt een ontwikkelaar een tabeluitbreiding. De standaard klantentabel blijft ongewijzigd, en de extensie voegt simpelweg het nieuwe veld ernaast toe.

Een veld aan een tabel toevoegen betekent natuurlijk nog niet dat je medewerkers het zien. Daarvoor gebruiken ontwikkelaars paginauitbreidingen. Een paginauitbreiding voegt het nieuwe veld, samen met eventuele benodigde groepen, acties of knoppen, rechtstreeks toe aan de standaard gebruikersschermen van Business Central. Medewerkers blijven werken in vertrouwde, standaard pagina’s, terwijl de extensie naadloos de gespecialiseerde gegevens toont die je bedrijf nodig heeft.

Codeunits, triggers en events

Gegevensopslag en gebruikersinterfaces zijn cruciaal, maar applicaties hebben ook logica nodig om waarden te berekenen en workflows te verwerken. Codeunits bieden een vaste plek voor deze herbruikbare bedrijfslogica. Als je loyaliteitsniveau bijvoorbeeld een specifiek kortingspercentage bepaalt, kan die berekeningscode in één gecentraliseerde codeunit staan, in plaats van ongemakkelijk gedupliceerd te worden over meerdere pagina’s en rapporten.

Code wordt uitgevoerd op specifieke momenten in de levenscyclus van een applicatie, de zogenaamde triggers. Een trigger wordt automatisch geactiveerd wanneer een bepaalde actie plaatsvindt, bijvoorbeeld wanneer een gebruiker een pagina opent, een veldwaarde wijzigt of probeert een factuur te boeken. Events werken op vergelijkbare wijze: hiermee kan je extensie luisteren naar meldingen die de standaardapplicatie uitzendt. Business Central kan bijvoorbeeld aankondigen dat een document op het punt staat geboekt te worden, en je extensie kan direct op dat event reageren en op precies het juiste moment de eigen validatielogica uitvoeren.

Conclusie: je ERP klaarhouden voor upgrades

Een enterprise resource planning-systeem aanpassen hoeft niet langer een riskante onderneming te zijn die upgrades laat mislukken. Door het moderne extensiemodel van Microsoft te omarmen en de kracht van AL-ontwikkeling te benutten, kunnen organisaties Business Central precies afstemmen op hun unieke operationele behoeften, terwijl de kernapplicatie volledig schoon en stabiel blijft. Zie je ERP als een goed ontworpen kantoorgebouw: aanpassingen worden veilig aan de buitenkant gekoppeld in plaats van de interne structuur af te breken. Zo blijft je bedrijf wendbaar, efficiënt en volledig voorbereid op elke toekomstige softwareupdate.

Wil je dieper ingaan op dit onderwerp en expertinzichten horen over moderne ontwikkelpraktijken? Bekijk dan zeker de bijbehorende podcastaflevering: Dynamics 365 Business Central AL Development.