Welkom bij weer een aflevering van Microsoft Knowledge Nuggets. Ik ben uw host, Miro Peters. Dus, dit is het scenario. U werkt in Business Central en u heeft één kleine wijziging nodig. Misschien een extra veld bij een klantrecord, een andere goedkeuringstap... ...of een regel die een order controleert voordat iemand deze boekt. Dan begint iemand overal extensies, tabellen, pagina's en codeunits... ...en plotseling klinkt dat kleine verzoek als een compleet nieuwe taal. Het is een taal, zeker, maar het hoeft niet mysterieus aan te voelen. Zie Business Central als een kantoorgebouw. Al geeft ontwikkelaars de instructies om een kamer, een formulier of een nieuwe regel... ...toe te voegen zonder gaten in het gebouw zelf te boren. Dat is de Kennis Nugget voor vandaag. Aan het einde van deze aflevering weet u wat al ontwikkeling betekent... ...waarom extensies bestaan en hoe maatwerk in Business Central past.

Waarom bedrijven Business Central aanpassen. Business Central regelt al veel dagelijkse zaken, financiën, klanten, verkooporders, voorraadfacturen... ...alles in één verbonden systeem in plaats van een stapel spreadsheets en losse tools. Voor veel bedrijven dekt die standaardopstelling het grootste deel van het werk. Maar hier is het punt. Geen enkel bedrijf werkt op precies dezelfde manier. Neem een voedseldistributeur die batchdetails nodig heeft die een ander bedrijf nooit gebruikt. Een servicebedrijf dat een speciaal goedkeuringsproces vereist voor facturering. Een winkelier die beloningsniveaus voor kortingen wil. En iemand anders die een formulier nodig heeft met eigen bewoordingen, velden en interne regels. Het bedrijf zal zijn werkwijze niet aanpassen voor één ontbrekend veld. En u wilt ook niet dat elk klein verzoek verandert in een risicovolle wijziging van het hele systeem. Dat was vroeger een groter probleem.

In oudere systemen openden ontwikkelaars de originele code en bewerkten deze direct. En dat werkte totdat de volgende update arriveerde. Dan had het bedrijf de nieuwe versie van Microsoft aan de ene kant en de eigen wijzigingen aan de andere kant. En moest iemand alles weer samenbrengen voordat de update door kon gaan. Stel u een kantoor voor waar elke huurder zonder plan nieuwe kabels door de muren trekt. Het werkt een tijdje, maar als het gebouw reparaties nodig heeft, weet niemand welke kabel van wie is. Business Central kiest een andere route. In plaats van de standaard applicatie te herschrijven, bouwen ontwikkelaars een aparte add-on die ermee verbindt, waarbij het standaard deel intact blijft terwijl de eigen wijzigingen van het bedrijf ernaast staan en werken via ondersteunde punten in het systeem. Die scheiding is van belang wanneer updates arriveren, omdat Microsoft zijn deel van het gebouw bijwerkt terwijl het maatwerk in zijn eigen ruimte blijft.

Er zijn nog steeds tests en fixes nodig. Het blijft immers software, maar van de ontwikkelaar wordt niet verwacht dat hij elke wijziging in de originele Microsoft-code kopieert en opnieuw verwerkt. Dus, wat past een bedrijf nu eigenlijk aan? Maatwerk voegt gegevens toe. Het standaard systeem slaat zaken als afleverinstructies, een interne risico scoren, een lidmaatschapsniveau of een koppeling met een extern systeem niet op. En er worden schermen toegevoegd die medewerkers in de juiste volgorde door een taak leiden. Ook worden er regels afgedwongen, zoals het blokkeren van een order als een vereist document ontbreekt. Maatwerk helpt mensen ook om handmatige stappen te vermijden. Stel je voor dat medewerkers elke vrijdag klantgegevens kopiëren van Business Central naar een andere tool, voorwaarden handmatig controleren en dan een rapport naar een manager sturen. Een goed gebouwde aanpassing houdt die informatie in Business Central, past de regel consistent toe en geeft medewerkers een knop of pagina die past bij hun dagelijkse werk.

Laten we een fabeltje uit de wereld helpen. Je wilt niet alles aanpassen. Standaard Business Central heeft al veel processen ingebouwd. Iets veranderen alleen omdat het er anders uitziet dan een oud systeem zorgt later voor extra werk. Goed maatwerk begint dus met een duidelijke zakelijke reden. Welk probleem ervaren mensen? Wat zou er in plaats daarvan moeten gebeuren? En kan het standaardproduct het al? Wanneer het standaardproduct niet in die behoefte voorziet, komt al in beeld. Al richt zich op Business Central zelf, waarbij records op database niveau worden gelezen, toegevoegd en gewijzigd. Terwijl wordt bepaald wat er gebeurt op pagina's, in rapporten en in andere delen van de applicatie. En het berekent waarde, verplaatst gegevens en toont berichten wanneer regels tijdens processen niet worden nageleefd. Dat is veel werk voor één taal, maar al is geen algemene tool voor elk type software.

En je zou het niet kiezen om een publieke webshop, een mobiele game of een zelfstandige desktop app te bouwen. Al bestaat voor één gericht doel, het vormgeven van de gegevens en het gedrag binnen Business Central, zodat het systeem aansluit bij de werkwijze van een bedrijf. En dat is precies waar we straks naar kijken. Al en extensies, het veilige add-on model. Al staat voor Application Language. Het is de programmeertaal van Microsoft voor Business Central, en het geeft ontwikkelaars een gestructureerde manier om nieuwe bedrijfsfuncties te creëren of het gedrag van bestaande onderdelen van het systeem te wijzigen. Maar het woord extensie is net zo belangrijk als al. Een extensie is een aparte app die Business Central kan installeren. Het bevat het maatwerk van het bedrijf, terwijl de standaard Business Central applicatie onaangetast blijft. Zie je het minder als het herschrijven van een handboek en meer als het toevoegen van goedgekeurde pagina's.

Ja, pagina's die de oorspronkelijke regels volgen zonder ze te wissen. Dat klinkt misschien als een technisch detail, maar het verandert hoe maatwerk op de lange termijn blijft bestaan. Stel je voor dat een bedrijf een nieuwe kantoorruimte nodig heeft voor een speciaal team. De oude aanpak betekende een muur in het hoofdgebouw doorbreken en de structuur zelf veranderen. Het lost de behoefte van vandaag misschien op, maar toekomstig onderhoud wordt een nachtmerrie omdat het oorspronkelijke gebouw niet meer overeenkomt met de blauwdrukken. Een extensie werkt anders. Het gebouw heeft al deuren, stopcontacten en regels voor het toevoegen van ruimte. U bouwt een nieuwe kamer via die goedgekeurde verbindingen. De kamer is van het bedrijf, maar het hoofdgebouw kan nog steeds worden onderhouden zonder alle aangepaste muren af te breken. Dat is precies hoe Business Central extensies werken. De basistoepassing bevat het standaardwerk dat Microsoft levert.

Een extensie kan eigen velden, schermen, knoppen, regels, rapporten en zelfs koppelingen naar andere systemen toevoegen. Het kan reageren op bepaalde bedrijfsacties, maar doet dit via ondersteunde manieren om verbinding te maken met de standaardtoepassing. Grenzen zijn dus ingebouwd. Dat is een goede zaak. Zonder grenzen kan een klein aangepast verzoek diep doordringen in gebieden die het niet zou moeten raken. Met extensies werkt de ontwikkelaar met duidelijke objecttypes en gedefinieerde verbindingspunten, wat de code begrijpelijker maakt voor iemand die deze later moet lezen. Deze aanpak past ook perfect bij de cloudversie van Business Central. Microsoft werkt de service regelmatig bij. Een bedrijf moet zijn extensie nog steeds testen na wijzigingen, vooral als deze afhankelijk is van onderdelen van het product die zijn veranderd. Software neemt de noodzaak voor zorg nooit weg. Maar door maatwerkkode gescheiden te houden, wordt de kans verkleind dat elke update verandert in een grote herbouw van oude wijzigingen.

Misschien hoort u mensen C al noemen als ze praten over oudere Dynamics en AV-systemen. C al kwam voort uit een eerder ontwikkelingsmodel, waarbij ontwikkelaars vaak rechtstreeks de originele applicatieobjecten wijzigden. Veel bedrijven draaiden jarenlang succesvolle systemen op die manier, maar het verbond maatwerk veel nauwer met de standaardcode en updates verrijste veel vergelijkings- en reparatiewerk. Al heeft Business Central richting app-gebaseerde ontwikkeling gebracht. Dat betekent niet dat elke extensie groot of ingewikkeld is. De ene extensie voegt misschien alleen een veld toe aan een klantrecord en toont dit op een bekend scherm. Een andere bevat misschien een volledige oplossing voor een bepaald bedrijfstype met eigen records, processen, pagina's en rapporten. Beiden volgen hetzelfde basis-idee. De aangepaste app leeft naast Business Central in plaats van een herschreven versie ervan te verbergen.

U kunt ook meer dan één extensie installeren. Een bedrijf kan een extensie van een softwarepartner gebruiken voor loonadministratie, een andere voor verzending en een kleine interne extensie voor regels die alleen voor dat bedrijf relevant zijn. Business Central brengt ze samen in hetzelfde werkende systeem, zolang ze de regels van het platform volgen en niet conflicteren. Al is dus niet alleen een manier om code te schrijven. Het is de taal die ontwikkelaars gebruiken om deze add-on apps te maken, en extensies zijn de container die die wijzigingen in Business Central brengt. Dat model stelt een bedrijf in staat het systeem aan te passen, terwijl het standaard product herkenbaar en makkelijker te onderhouden blijft. Laten we nu een van deze extensies openen en naar de bouwstenen erin kijken. De belangrijkste al bouwstenen binnen een al-extensie. Ontwikkelaars werken met objecten. Een object is een benoemd onderdeel van de app met een duidelijke taak, zoals informatie opslaan, een scherm tonen, een regel uitvoeren of een document genereren.

Zodra je die taken los van elkaar ziet, voelt al veel minder als een muur van code. Laten we beginnen bij de plek waar bedrijfsinformatie leeft. Tabellen slaan gegevens op in Business Central. Zie een tabel als een digitale archiefkast voor één type record. De ene kast kan klanten bevatten, een andere artikelen en weer een andere verkooporders. Elk record is één bestand in die kast. Een klantentabel bevat één record voor elke klant. Een artikeltabel bevat één record voor elk product. Als uw bedrijf informatie nodig heeft die standaard Business Central niet opslaat, kan een extensie een eigen tabel maken, bijvoorbeeld voor beloningsniveaus, apparatuurinspecties of projectgoedkeuringen. Velden zijn de gelabelde ruimtes binnen elk record. Een klantrecord kan een naam, adres, betalingstermijn en telefoonnummer bevatten, omdat de klantentabel velden heeft voor die details. Velden kunnen tekst, datums, bedragen, ja, nee antwoorden of een keuze uit een vaste lijst bevatten.

Een veld kan ook naar een ander record verwijzen. Een klant kan bijvoorbeeld een veld voor een beloningsidee bevatten. In plaats van willekeurige teksten typen, selecteren medewerkers een beloningsniveau uit een aparte beloningstabel. Die koppeling houdt de gegevens zuiver omdat iedereen uit dezelfde bekende lijst kiest. Dus, tabellen bevatten de feiten. Maar hoe zien en werken mensen met die feiten? Pagina's. Een pagina is het scherm dat u opent in Business Central. De klantenkaart is een pagina. Een lijst met verkooporders is een pagina. Een pagina bepaalt wat gebruikers kunnen bekijken, invoeren, doorzoeken en uitvoeren. Verschillende pagina's passen bij verschillende taken. Een kaartpagina richt zich op één record tegelijk, zoals één klant of één artikel. Een lijstpagina toont veel records in rijen, wat goed werkt als u snel iets wilt scannen, filteren of vinden. Een werkbladpagina ondersteunt werkzaamheden waarbij mensen meerdere regels informatie tegelijk invoeren of verwerken.

De tabel slaat de informatie op. De pagina presenteert deze aan de gebruiker. Die scheiding is handig omdat u het scherm kunt wijzigen zonder de opslaglocatie van de gegevens aan te passen of dezelfde tabel op meerdere pagina's kunt hergebruiken wanneer verschillende teams andere weergave van dezelfde records nodig hebben. Wat nu als de gegevens al bij een standaard Business Central record horen. Je maakt meestal geen vervangende klantentabel aan alleen omdat je één extra veld nodig hebt. Je gebruikt een tabel extensie. Een tabel extensie voegt jouw veld toe aan de bestaande klantentabel. Het standaard klantrecord blijft waar het hoort, terwijl jouw extensie het specifieke detail van het bedrijf toevoegt naast de standaardvelden. Dat kan een beloningsidee, een afleveringsnota, een accountmanager of een veld zijn dat verbinding maakt met een ander onderdeel van het bedrijf. Maar het toevoegen van het veld aan de tabel plaatst het niet automatisch op het scherm.

Daarvoor gebruik je een pagina extensie. Een pagina extensie voegt een veld, groep of actie toe aan een bestaande pagina. Als het bedrijf wil dat personeel een beloningsniveau kiest bij het bekijken van een klant, kan de pagina extensie het beloningsideeveld op de klantenkaart plaatsen, precies waar het personeel al werkt. Dat houdt de ervaring vertrouwd. In plaats van gebruikers naar een apart aangepast scherm te sturen voor een simpel detail, voegt de extensie het detail toe aan de pagina die ze al kennen. Een pagina extensie kan ook een actie toevoegen, een knop of menuopdracht die een taak start. Bijvoorbeeld, een klantenkaart kan een beloningsactie bevatten die de beloningslijst opent. Achter het scherm heb je een plek nodig voor de bedrijfsregels. Die plek is vaak een codeunit. Een codeunit bevat al procedures, wat benoemde stukjes code zijn die een specifieke taak uitvoeren. Zie het als het backoffice team dat een taak afhandelt wanneer een pagina, rapport of ander proces om hulp vraagt.

Stel dat het beloningsniveau bepaalt welke korting voor een klant geldt. De kortingsberekening hoort in een codeunit thuis, niet op de klantenkaartpagina zelf. Dan kan een verkoopproces, een rapport of een toekomstige pagina dezelfde regel gebruiken zonder deze op verschillende plekken te kopiëren. Eén regel, één plek om deze te onderhouden. Business Central bevat ook andere objecttypen voor verschillende taken. Rapporten verzamelen gegevens en presenteren deze in een document of layout, zoals een factuur of verkooprapport. Queries stellen gerichte vragen aan gegevens, bijvoorbeeld welke klanten een bepaald artikel hebben besteld gedurende een periode. XML-ports helpen bijvoorbeeld gegevens in een gestructureerd formaat in te voeren of te verzenden, vaak wanneer een ander systeem informatie moet uitwisselen met Business Central. Breng die onderdelen samen en je kunt je een kleine klantenbeloningsextensie voorstellen.

Een beloningstabel slaat elk niveau en het bijbehorende kortingspercentage op. Beloningspagina's laten personeel die niveaus beheren. Een klanttabel-extensie voegt een beloningsidee toe aan elke klant, terwijl een pagina-extensie voor de klantenkaart dit weergeeft. Een pagina-actie opent de beloningslijst en de code-unit berekent de kortingsregel. Elk object behandelt een deel van de taak. Dat maakt de extensie makkelijker leesbaar, testbaar en aanpasbaar als de bedrijfsregel over zes maanden verandert. Maar een bedrijfsregel moet vaak op precies het juiste moment worden uitgevoerd, zoals wanneer iemand een order boekt. Dat is waar triggers en events om de hoek komen kijken. Events, triggers en bedrijfsregels. Dus, je hebt een klantbeloningsveld toegevoegd. Goed zo, dit is de echte vraag. Wanneer moet Business Central dat veld eigenlijk gebruiken? Stel je voor dat je op het punt staat een verkooporder te boeken.

Voordat het systeem de definitieve posten aanmaakt, wil je één extra controle. Misschien heeft de klant een goedgekeurd beloningsniveau nodig voordat er korting wordt toegepast. Of misschien moet er een vereist leveringsdocument bestaan voordat de order verder kan. Je wilt die controle op het juiste moment, maar je wilt niet het volledige boekingsproces voor verkopen kopiëren naar je eigen extensie om slechts één regel toe te voegen. Dat proces regelt al veel op de achtergrond. Als je het kopieert, zit je extensie vast aan het onderhoud van al die toekomstige wijzigingen. Niet ideaal. Dus al geeft ontwikkelaars een paar manieren om code uit te voeren. Welke je kiest, hangt af van wat er moet gebeuren. Ten eerste, triggers. Een trigger is een benoemde plek binnen een al-object waar code kan worden uitgevoerd. Wanneer iemand een waarde in een tabelveld wijzigt, start de triggercode. Wanneer een pagina wordt geopend of gesloten, start de triggercode.

Rapporten, queries, XML-ports, tabellen, extensies, AO. Ze hebben allemaal deze plekken waar een ontwikkelaar regels kan toevoegen. Neem het beloningsideeveld bij een klant. Wanneer een gebruiker een beloningsniveau kiest, kan een validatietrigger worden uitgevoerd. De code controleert, is de klant geblokkeerd. Bestaat het beloningsniveau, moet een ander veld worden bijgewerkt. De controle gebeurt precies wanneer de waarde verandert, niet pas later wanneer iemand een fout ontdekt. Triggers werken goed wanneer de regel nauw verbonden is met dat object. Maar Business Central gebruikt ook events. Een event is als een kennisgeving. Een deel van de applicatie verstuurt deze wanneer er iets gebeurt. Het kan aankondigen dat een record wordt ingevoegd, dat een document op het punt staat te worden geboekt of dat een proces is voltooid. Jouw extensie kan naar die kennisgeving luisteren. De code die luistert, wordt een eventsubscriber genoemd.

Deze wacht op een specifieke, benoemde gebeurtenis. Wanneer Business Central dat event activeert, voert de subscriber zijn eigen procedure uit. Het standaard proces blijft de leiding houden. Bijvoorbeeld, wanneer Business Central begint met het boeken van een verkooporder, activeert het een event voordat het verder gaat. Uw rewards-extensie ontvangt die melding. Deze controleert het reward-idee en de kortingsregel van de klant. Vervolgens laat het het proces doorgaan of stopt het met een duidelijk bericht. Het standaard bookingsproces blijft van Business Central. Uw extensie voegt enkel een bedrijfsspecifieke regel toe op dat aansluitpunt. U hoort vaak eventnamen zoals on-before of on-after. On-before betekent dat uw code draait voordat een actie is voltooid. Dat is perfect voor een controle die de volgende stap kan voorkomen. O, zoals het stoppen van een verkooporder als aan een voorwaarde niet is voldaan.

After betekent dat de actie al heeft plaatsgevonden. U kunt daarop reageren. Maak een gerelateerd record aan, werk een notitie bij of start ander werk. De namen geven de timing aan en timing is belangrijk. Een regel die na het boeken draait kan dit niet meer voorkomen. Een regel die te vroeg draait beschikt mogelijk nog niet over de benodigde gegevens. Dus kiezen ontwikkelaars de gebeurtenis op basis van wat de bedrijfsregel moet doen en wanneer. Code kan ook worden gestart vanuit een actie. Een gebruiker klikt op een knop, zoals reward status controleren, en die actie roept een procedure aan. Code kan ook draaien wanneer het ene object het andere aanroept via een variabele. Dat klinkt technisch, maar het is eenvoudig. Het ene deel van de extensie vraagt het andere om een taak uit te voeren. Variabele helpen daarbij. Een variabele is een benoemde plek die een waarde vasthoudt terwijl de code draait.

Dit kan een getal, tekst, een datum of zelfs een business central record zijn, zoals de huidige klant. In al declareert u deze met FAR. Een rewards procedure kan bijvoorbeeld een variabele genaamd, customer, gebruiken om het huidige klantrecord vast te houden. Een andere variabele genaamd, discount percent, bevat de korting. Dit zijn geen permanente records. Het zijn slechts werkwaarden voor dat specifieke stukje code. Dit is belangrijk wat betreft de plek waar code zich bevindt. Als een regel op meerdere plaatsen gebruikt kan worden, zet deze dan in een codeunit. Op die manier kunnen de klantkaart, een verkoopproces en een rapport allemaal dezelfde kortingsprocedure aanroepen in plaats van elke eigen versie te hebben. Dat voorkomt een bekend probleem. Het ene scherm past 10% korting toe, het andere 5% en niemand weet welke regel correct is. Door gedeelde bedrijfsregels in één codeunit te houden, krijgt de extensie één bron voor die beslissing.

Triggers verwerken dus regels dicht bij een object. Events laten een extensie reageren op de processen van Business Central zelf. Codeunits houden gedeelde logica bij elkaar. Zodra die onderdelen verbonden zijn, is de volgende vraag. Waar schrijven, testen en inspecteren ontwikkelaars al deze al code? Al ontwikkeling vindt doorgaans plaats in Visual Studio Code, vaak VS Code genoemd. Dit is uw werkruimte voor het schrijven van al bestanden. Het houdt uw extensie georganiseerd. Het helpt u problemen te vinden en stuurt de voltoide app naar een Business Central omgeving om te testen. Maar VS Code op zichzelf is slechts een algemene code-editor. Het heeft de Altaal-extensie van Microsoft nodig. Die extensie leert VS Code hoe Business Central werkt. Het kan objectnamen voorstellen terwijl u typt. Het wijst op fouten voordat u publiceert. Het helpt u bij het bladeren door velden en procedures.

En het verbindt uw project met een Business Central omgeving. Dat bespaart een hoop GISwerk. Wanneer u een nieuw Al project start, kunt u het commando Algo uitvoeren in VS Code. Het maakt de basis projectmap en instellingsbestanden voor de extensienaam, uitgever, versie en welke Business Central omgeving moet worden gebruikt. Beschouw die projectmap als de werkbank van de extensie. Elk Al bestand hoort daar thuis. Eén bestand kan een tabel bevatten, een andere pagina extensie, een code-unit kan een eigen bestand hebben. Op die manier kan iemand die het project opent, het juiste onderdeel vinden zonder door één enorm document te scrollen. Wanneer de code klaar is om te testen, compileert VS Code deze tot een app-pakket. Dat is de installeerbare versie van de extensie. Business Central leest dat pakket en voegt de extensie toe aan de omgeving. Als er een veld ontbreekt, er een spelfout is of een ander probleem is dat verhindert dat de app wordt gebouwd, vertelt VS Code u dat voordat het pakket Business Central ooit bereikt.

Testen moet eerst in een sandbox gebeuren. Een sandbox is een afzonderlijke Business Central omgeving waar u wijzigingen kunt uitproberen zonder live bedrijfsactiviteiten te riskeren. U publiceert de extensie, opent de pagina's, voert testrecords in en kijkt of de regels werken zoals verwacht. Die scheiding is belangrijk. U wilt niet ontdekken dat een nieuwe validatieregel verkooporders blokkeert terwijl medewerkers proberen hun werk te doen. In een sandbox kunt u fouten maken, testgegevens verwijderen, code wijzigen en opnieuw publiceren zonder live records te beïnvloeden. Soms draait de code, maar ziet het resultaat er toch fout uit. Dat is wanneer debuggen helpt. U plaatst een breakpunt in de code, start het proces en de extensie pauzeert terwijl deze draait. Bij die pauze kunt u waarden inspecteren, zoals de huidige klant, het geselecteerde beloningsniveau of het kortingspercentage dat de procedure heeft berekend.

In plaats van te raden waarom een regel faalde, kunt u precies zien wat de code heeft ontvangen. Ontwikkelteams gebruiken ook Git om een geschiedenis van hun werk bij te houden. Git legt wijzigingen in de projectbestanden in de loop van de tijd vast. Als iemand een regel wijzigt en een probleem veroorzaakt, kan het teamversies vergelijken, zien wat er is veranderd en zo nodig terugdraaien. Het helpt ook wanneer meer dan één ontwikkelaar aan dezelfde extensie werkt. Voor een beginner is het beste pad om klein te beginnen. Leer eerst de weg in Business Central en maak daarna één tabel en één pagina. Breed daarna een standaardpagina uit, voeg een eenvoudige bedrijfsregel toe en leer hoe events en installatiegegevens in het project passen. Laten we vervolgens die onderdelen verbinden via een kleine add-on die een bedrijf echt zou kunnen gebruiken. Een eenvoudig voorbeeld, het bouwen van een add-on voor klantenbeloningen.

Hoe ziet een echte al-extensie er eigenlijk uit? Laten we in een eenvoudig voorbeeld duiken. Stel je voor dat je bedrijf beloningsniveaus voor klanten wil, elk met zijn eigen korting. Je begint met het maken van een beloningstabel. Zie het als een digitale archiefkast waarin elk bestand een idee, een omschrijving en een kortingspercentage bevat. Goud krijgt bijvoorbeeld 10% korting. Je personeel moet die niveaus kunnen beheren zonder technische tools aan te raken. Dus voeg je twee pagina's toe, een beloningslijstpagina om alle niveaus te zien en een beloningskaartpagina om er een te bewerken of aan te maken. Ze kunnen een nieuw niveau toevoegen, een percentage aanpassen of bekijken wat er is, zonder enige ontwikkelomgeving te openen. Vervolgens breed je de klantentabel uit met een nieuw veld genaamd beloningsidee. Dat veld koppelt elke klant aan één beloningsrecord en je plaatst dat veld direct op de klantenkaartpagina waar medewerkers al klantgegevens beheren.

Daarna voeg je een beloningsactie toe zodat ze de beloningslijst direct vanaf diezelfde kaart kunnen openen. De kortingsregel zelf bevindt zich in een codeunit. Wanneer een ander proces de korting van een klant nodig heeft, roept het die codeunit aan in plaats van het telkens opnieuw te berekenen op elke pagina. Dat is efficiënt. Een installatiecodeunit voegt standaard beloningsniveaus toe de eerste keer dat je extensie wordt geïnstalleerd. En een event subscriber controleert het gekozen beloningsniveau tijdens een verkoopproces en past de regel van je bedrijf op precies het juiste moment toe. Dat is één kleine extensie, maar let op wat deze bevat. Datatabellen, gebruikerschermen, navigatieacties, instellingslogica en bedrijfsregels die allemaal samenwerken. Dat is de ware kracht van al. All right. Conclusie, je startpunt voor alontwikkeling. Dus, dit is de belangrijkste lay. Met alontwikkeling kun je de specifieke functies die je bedrijf nodig heeft toevoegen aan Business Central zonder de kernapplicatie aan te passen.

En je hoeft niet alles tegelijk te bouwen. Begin met één veld, één pagina extensie en één duidelijke regel. Dat is je eerste bouwsteen. Als je deze kennis nugget nuttig vond, abonneer je dan op je favoriete podcast platform en deel hem met iemand die net begint met Business Central ontwikkeling. Doe de volgende keer weer mee, wanneer we een nieuw puzzelstukje toevoegen. Ik ben Marco Peters en dit was weer een aflevering van Microsoft Knowledge Nuggets op M365FM.