Business Central aanpassen: van instellingen tot eigen AL-code

Wie in Nederland een mkb-bedrijf runt op Microsoft Dynamics 365 Business Central, loopt vroeg of laat tegen hetzelfde aan: het standaardproces dekt negen van de tien handelingen, maar het tiende is precies wat uw bedrijf onderscheidt. Bij Business Central development gaat het dan niet om de vraag óf u mag aanpassen, maar op welk niveau. Die keuze bepaalt wat het later kost om bij te blijven.

Deze pagina loopt de niveaus langs: instellen, bestaande extensies, eigen ontwikkeling. Daarna komt aan bod wat dat betekent voor updates, welke werkwijze het systeem gezond houdt en waaraan u een ontwikkelaar of integrator herkent die dat vak beheerst.

De drie lagen van personalisatie in Business Central

Een goede aanpak begint onderaan. Elke laag hoger geeft meer vrijheid, maar ook meer onderhoud.

Hoe lager u blijft, hoe minder u hoeft te testen en te herstellen. Dat is geen dogma, maar een volgorde van afwegen: pas als een laag aantoonbaar tekortschiet, gaat u naar de volgende.

Eerst instellen: meer dan u denkt

Veel wensen die als ‘maatwerk’ binnenkomen, blijken instellingen te zijn. Denk aan een eigen indeling van de verkooporder, extra dimensies voor kostenplaatsen of projecten, goedkeuringsstromen voor inkoopfacturen of een andere rolcentrumindeling per afdeling.

Het Designer-hulpmiddel in de client gaat een stap verder. Daarmee ontwerpt u pagina’s door te slepen en neer te zetten: velden herschikken of toevoegen en direct een voorbeeld zien, zonder de interface te verlaten. Voor een afdeling die alleen een andere weergave nodig heeft, is dat vaak voldoende.

Een nuttige toets voor uw boekhouder of financieel manager: raakt de wens de boekingslogica of alleen de presentatie? Presentatie lost u op met instellingen. Boekingslogica vraagt om zorgvuldigheid, zeker rond de btw-aangifte en de auditfile, waarover u meer leest bij btw-aangifte en uw ERP.

Bestaande extensies: zoeken voordat u bouwt

Online breidt u Business Central uit met applicaties die u uit Microsoft Marketplace installeert. Daarnaast bestaan binnen het product pagina’s voor koppelingen en bankapps, waarmee u verbindingen met externe diensten legt, zoals het importeren van banktransacties. Voor een boekhouder die elke ochtend bankafschriften inleest, is zo’n app doorgaans een betere eerste stap dan een eigen programma.

Een voorbeeld uit de webshopwereld is de Shopify-connector. Die synchroniseert producten, voorraad, klanten, orders, verzendingen, transacties en uitbetalingen tussen Shopify en Business Central, ondersteunt meerdere webwinkels en haalt orders op uit de webshop, Shopify POS en B2B. Via de takenwachtrij (job queue) draait de synchronisatie van producten, voorraad, orders en verzendingen op de achtergrond, met gedetailleerde logging voor foutopsporing. Wat zo’n connector uit de doos doet, hoeft niemand opnieuw te bouwen. Meer over koppelingen vindt u op de pagina integraties met Business Central.

Controleer bij een app van een derde altijd drie dingen:

• of de leverancier nieuwe Business Central-versies actief volgt;
• of de app uw scenario echt dekt, zoals meerdere administraties of uw eigen verkoopkanaal;
• wie support levert als de app en uw eigen aanpassingen elkaar raken.

Welke functies al in het pakket zitten, ziet u in het overzicht van de modules van Business Central.

Eigen development: AL, Visual Studio Code en extensies

Gaat het echt om iets specifieks, dan schrijft een ontwikkelaar een extensie in AL, de ontwikkeltaal van Business Central, in Visual Studio Code. Met AL voegt u tabellen, pagina’s, codeunits en rapporten toe of wijzigt u ze, zonder de code van de basis aan te passen. Alles wordt gecompileerd tot een .app-bestand dat u op een omgeving publiceert.

Dat principe is de kern van het hele model: u past niet het fundament aan, u legt er iets overheen. Daardoor kan Microsoft de basis blijven bijwerken terwijl uw extensie zijn plek behoudt.

Typische toepassingen voor maatwerk

In Nederlandse mkb-projecten zien we vooral deze categorieën terugkomen:

• Sector- of procesvelden: extra gegevens op artikel, klant of project die in de branche gewoon zijn, maar niet in de standaard zitten.
• Rapporten en documenten: een offerte, pakbon of factuurlay-out die past bij uw huisstijl en bij wat uw afnemers verwachten.
• Goedkeuringslogica: een eigen regel voor wie welke inkoop mag vrijgeven, bijvoorbeeld per vestiging of per provincie.
• Koppelingen: een verbinding met een vervoerder, een brancheplatform of een intern pakket via een eigen API.
• Automatisering: een taak die ’s nachts via de takenwachtrij draait en stamgegevens bijwerkt.

Voor e-factureren geldt dezelfde volgorde. Controleer eerst wat standaard of via een app beschikbaar is voordat u een eigen oplossing bouwt; de achtergrond staat bij e-factureren en Peppol in uw ERP.

API’s en koppelingen: de harde randen

Business Central biedt een REST-API (v2.0) om het ERP te verbinden met andere software. Online staan de API’s standaard aan. Let op één beperking: aan een standaard-API kunt u geen velden toevoegen. Wilt u een extra veld uitwisselen, dan kopieert u de AL-code en bouwt u een eigen, aangepaste API.

Daarnaast gelden grenzen op aanroepen. De limieten voor OData V4 worden per gebruiker toegepast: vijf gelijktijdige aanvragen, honderd verbindingen en een glijdend venster van 6 000 aanvragen per 5 minuten. Daarboven antwoordt de dienst met HTTP-code 429. Microsoft raadt aan om API’s of OData te gebruiken in plaats van SOAP, dat op termijn wordt afgeschaft. Een webshop die elke seconde voorraad opvraagt, loopt hier dus tegenaan, tenzij de ontwerper rekening houdt met die grenzen.

Verder kunt u een Business Central-omgeving koppelen aan een Power Platform-omgeving van hetzelfde type, productie of sandbox. Die koppeling is exclusief en dient als standaarddoel voor integraties met Power Platform en andere Dynamics 365-producten. Het is een detail dat vaak pas bij het ontwerp van automatiseringen opduikt.

Wat doet maatwerk met uw updates?

Dit is de vraag die de meeste eigenaren en financieel directeuren eigenlijk willen stellen. Het eerlijke antwoord: een extensie die uitbreidt in plaats van wijzigt, is ontworpen om updates te overleven, maar dat is geen garantie. Als Microsoft iets in de basis aanpast waar uw code van afhangt, moet uw extensie mee.

Wat de kans op problemen klein houdt:

1. Blijf bij uitbreiden. Gebruik de aanhaakpunten die het platform biedt en vermijd constructies die op interne details leunen.
2. Houd de hoeveelheid eigen code klein. Elke regel is een regel om te testen, te documenteren en te beheren.
3. Test in een sandbox vóór de productieomgeving. Sandbox-omgevingen zijn bedoeld voor ontwikkeling: het debugpunt staat standaard open, u publiceert vanuit Visual Studio Code, en uitgaande HTTP-aanroepen van extensies zijn er geblokkeerd tot u ze per extensie toestaat. Dat laatste voorkomt dat een testomgeving per ongeluk met uw echte webshop of vervoerder praat.
4. Plan een testronde bij elke nieuwe versie. Wie dat achterwege laat, ontdekt een gebroken functie pas tijdens de maandafsluiting.

Meer over versies en wat daarbij komt kijken leest u op versies en edities van Business Central. Draait uw omgeving bij Microsoft in de cloud, dan staat de context op de pagina Business Central in de cloud.

Bonnetjes en prijskaartjes: wat maatwerk kost

Maatwerk heeft twee kostenposten die vaak ontbreken in de offerte: de bouw en het bezit. Bouwen is een eenmalige inspanning; bezitten betekent testen bij elke nieuwe versie, documentatie bijhouden en kennis behouden als de ontwikkelaar vertrekt. Een voorstel dat alleen de eerste post noemt, is onvolledig.

Voor de licentiekant geeft Microsoft in de Amerikaanse prijslijst als referentie: Essentials 80 USD per gebruiker per maand, Premium 110 USD en Team Members 8 USD, jaarlijks gefactureerd. Microsoft zegt zelf dat de getoonde prijzen kunnen afwijken per valuta, land en regionale variant; de uiteindelijke prijs ziet u bij het afrekenen. Zie voor de Nederlandse situatie de prijzen van Business Central. Maatwerk komt daar bovenop en hoort een eigen, apart benoemde post te zijn.

Bonnetje voor uzelf: bepaal wat u écht nodig hebt

Gebruik deze volgorde als gespreksleidraad met uw ontwikkelaar of integrator:

1. Beschrijf het probleem, niet de oplossing. ‘Onze monteurs moeten onderweg uren registreren’ is een betere start dan ‘bouw ons een extra pagina’.
2. Vraag naar de standaardroute. Welke instelling, welke app, welke bestaande functie dekt dit gedeeltelijk?
3. Splits ‘moet’ van ‘fijn’. Alleen wat een wettelijke verplichting of een kernproces raakt, rechtvaardigt eigen code.
4. Leg de eigenaar vast. Wie beheert de extensie over een paar jaar: de leverancier, uw IT of een externe partij?
5. Spreek de testaanpak af. Wie test, in welke omgeving en wanneer?

Hoe beoordeelt u een Business Central-ontwikkelaar of integrator?

Een goede partij herkent u aan haar manier van werken, niet aan enthousiasme voor uw wensenlijst. Let op deze punten:

• Zij vraagt eerst naar uw proces. Een gesprek met de boekhouder, de magazijnbeheerder en de verkoop, vóór er een regel code wordt voorgesteld.
• Zij kiest eerst voor instellingen en bestaande apps. Maatwerk is dan de uitzondering met een motivatie.
• Zij werkt in een sandbox en kan uitleggen hoe wijzigingen van daar naar productie gaan.
• Zij documenteert: wat de extensie doet, waarom hij bestaat en welke instellingen erbij horen.
• Zij kan aantonen dat eerdere extensies versiewissels hebben doorstaan, zonder dat u de naam van een klant hoeft te kennen om dat te geloven.
• Zij noemt de beperkingen zelf, zoals die rond API’s en aanroeplimieten, en niet pas als u erom vraagt.
• Zij regelt overdracht: u krijgt toegang tot de broncode en de documentatie, zodat u niet vastzit.

Een rode vlag is een voorstel zonder tests, zonder omschrijving van het eindresultaat of met uitsluitend de bouwkosten. Meer houvast bij de selectie vindt u op de pagina over het kiezen van een Business Central-integrator en in de algemene gids een ERP-integrator kiezen.

Maatwerk in een lopend project of na overname

Soms erft u maatwerk in plaats van dat u het laat bouwen: na een wisseling van leverancier, een overname of een vertrokken ontwikkelaar. Dan is het zinvol om eerst te inventariseren wat er draait, wat gedocumenteerd is en wat bij de volgende versie risico loopt. Zo’n inventarisatie heet een audit; hoe die werkt, staat bij audit en projectovername. Wilt u daarna een nieuwe fase starten, dan sluit de pagina over de implementatie van Business Central daar op aan. Voor het lopende beheer is de pagina over support en onderhoud de logische vervolgstap.

Praktische richtlijnen om het systeem gezond te houden

• Blijf zo dicht mogelijk bij de standaard. Elke afwijking is een verplichting voor de toekomst.
• Documenteer elke extensie in gewone taal: doel, eigenaar, afhankelijkheden.
• Test in een sandbox, ook voor ogenschijnlijk kleine wijzigingen.
• Houd een overzicht van uw extensies en apps, zodat u weet wat er bij een versiewissel moet worden gecontroleerd.
• Beoordeel maatwerk periodiek: bestaat er inmiddels een standaardfunctie of app die het overbodig maakt?
• Betrek uw accountant of boekhouder zodra een aanpassing boekingen, btw of rapportages raakt.

Ligt uw bedrijf in Noord-Brabant, Zuid-Holland of Overijssel, dan maakt de afstand tot de ontwikkelaar weinig uit: Business Central development gebeurt grotendeels op afstand, maar voor het inventariseren van uw proces is een bezoek ter plaatse waardevol. Meer over de Nederlandse context leest u op de pagina Business Central in Nederland.

Wilt u een passende partij vinden?

Wij ontwikkelen niet zelf en zijn niet gelieerd aan Microsoft: wij brengen u in contact met een erkende integrator die bij uw project past. Beschrijf uw situatie in het formulier en wij koppelen u aan een partij met aantoonbare ervaring in aanpassingen op Business Central. Dat is gratis en vrijblijvend.

De genoemde softwarenamen zijn handelsmerken van hun respectievelijke eigenaren en worden uitsluitend ter informatie vermeld. Deze site is onafhankelijk en niet verbonden aan een softwareleverancier.