Business Central Magento koppeling: je ERP en webshop op één lijn

Business Central online heeft een standaard REST API op basis van OData v4, met endpoints per bedrijf voor onder meer items, customers, salesOrders, salesInvoices, salesCreditMemos en vendors. Voor online omgevingen staan die API's standaard aan. Authenticatie loopt via OAuth met Microsoft Entra ID. Volgens de documentatie van Microsoft worden web service access keys (basic authentication) in Business Central online niet meer ondersteund. Een oude koppeling die nog op gebruikersnaam en sleutel draait, moet dus om.

Voor koppelingen gebruiken we service-to-service authenticatie: een app-registratie in Entra ID met eigen rechten in Business Central. Zo hangt de koppeling niet aan het account van een medewerker die vertrekt, en geef je de koppeling alleen de rechten die nodig zijn.

Belangrijk om vooraf te weten: de standaard API v2.0 kun je niet uitbreiden met extra velden. Heb je eigen velden in Business Central, zoals een webshopomschrijving, een merk of een B2B-prijsgroep, dan is een custom API-pagina in AL nodig. Dat is een kleine extensie in Business Central zelf. Die afweging maken we per veld, want elk extra stuk AL-code moet ook mee bij BC-updates.

Business Central online kent operationele limieten. Microsoft noemt per gebruiker maximaal 6.000 OData-verzoeken in een glijdend venster van vijf minuten, vijf gelijktijdig verwerkte verzoeken, maximaal 20.000 records per pagina, 100 operaties per batch-verzoek en een time-out van acht minuten per verzoek. Wie dat overschrijdt, krijgt een HTTP 429 terug. Voor een catalogus met tienduizenden artikelen of een import van klantprijzen betekent dat: werken met delta's op basis van lastModifiedDateTime, batches gebruiken en een wachtrij met retry-logica bouwen. Niet elke nacht de hele catalogus opnieuw ophalen.

Business Central ondersteunt webhooks voor onder meer items, customers, salesOrders en salesInvoices. Een subscription verloopt na drie dagen en moet actief verlengd worden. Notificaties komen met een vertraging van standaard 30 seconden, en bij meer dan 1.000 wijzigingen in dat venster stuurt BC één collection-melding in plaats van losse meldingen. Je middleware moet dus beide kunnen verwerken. Webhooks zijn handig voor voorraad en artikelwijzigingen, maar we bouwen altijd een periodieke controle als vangnet, omdat een gemiste melding anders niemand opvalt.

Bij Dynamics NAV on-premise ligt het anders. Recentere NAV-versies bieden OData- en SOAP-webservices die je per pagina of codeunit publiceert. Oudere versies hebben soms alleen SOAP. Microsoft heeft aangegeven SOAP in Business Central op termijn uit te faseren, dus bij een nieuwe koppeling kiezen we waar het kan voor OData of de API. Draai je nog op NAV 2018 of ouder, dan raden we aan de koppeling zo te bouwen dat de NAV-kant later vervangen kan worden door de BC API, zonder de Magento-kant opnieuw te bouwen.

De meeste Business Central Magento koppelingen die we zien zijn B2B. En daar zit de lastigste vraag: hoe krijg je de prijs die een klant in Business Central heeft, ook in de webshop? Business Central kan prijzen en kortingen vastleggen per klant, per klantprijsgroep, per artikel of artikelcategorie, met staffels en ingangsdatums. Afhankelijk van je BC-versie en instellingen werk je met de oudere verkoopprijzen en verkoopregelkortingen, of met de nieuwere prijslijsten. Dat bepaalt welke tabellen we moeten uitlezen.

In Magento Open Source heb je klantgroepen, tier prices en catalogusprijsregels. Adobe Commerce voegt daar met de B2B-module bedrijfsaccounts, shared catalogs en offerteaanvragen aan toe. Een groothandel met een handvol prijsgroepen kan die prima mappen op Magento-klantgroepen. Een groothandel met per klant afwijkende nettoprijzen op duizenden artikelen niet: dan exporteer je al snel miljoenen prijsregels, die je ook nog moet indexeren.

Daarom kiezen we per situatie tussen twee modellen. Bij beperkte prijsvariatie synchroniseren we prijzen vooraf naar Magento, zodat de shop snel blijft en niet afhankelijk is van BC. Bij veel klantspecifieke prijzen berekenen we de prijs in een eigen prijsservice of cache in de middleware, gevoed vanuit Business Central, en vraagt Magento die op voor de ingelogde klant. Rechtstreeks voor elke productpagina Business Central bevragen doen we niet: dat loopt tegen de limieten van de API aan en maakt je webshop zo traag als je ERP.

Hetzelfde geldt voor kredietlimieten, betalingscondities en op rekening bestellen. Die liggen vast in Business Central en moeten in Magento zichtbaar zijn bij het afrekenen. Vaak koppelen we ook openstaande facturen en orderhistorie uit BC, zodat de klant in zijn account ziet wat hij ook telefonisch zou opvragen. Dat scheelt je binnendienst direct werk.

Veel bedrijven die zoeken op een Magento 2 Navision koppeling zitten op een oudere NAV-versie en weten dat de overstap naar Business Central eraan komt. Partnerbronnen noemen voor NAV 2018 het einde van extended support in januari 2028. Controleer dat bij je ERP-partner of op de lifecycle-pagina van Microsoft. Extended support betekent alleen nog security-updates, geen nieuwe functies.

Wachten met koppelen tot de ERP-migratie klaar is, kost je in de tussentijd handwerk en fouten. Nu een koppeling bouwen die straks weggegooid wordt, kost geld. Onze aanpak: we leggen de Magento-kant en de businesslogica in middleware vast, en houden de ERP-kant een dunne adapter. Gaat NAV over naar Business Central, dan vervangen we alleen die adapter van SOAP of OData naar API v2.0. Mappings, prijslogica, foutafhandeling en monitoring blijven staan.

Draai je nog op Magento 1 of een verouderde Magento 2-versie, dan nemen we de koppeling mee in de migratie. Twee migraties tegelijk vraagt goede planning, maar voorkomt dat je een koppeling twee keer bouwt.