Magento SAP Business One koppeling

Wat je tussen Magento en SAP Business One koppelt

Magento 2 geeft gegevens vrij via zijn REST API, SAP Business One via de Service Layer, de OData-API op poort 50000. SAP is leidend voor artikelen, voorraad per magazijn en prijzen, Magento voor de order.

Het increment_id van de Magento-order, zoals 000010482, gaat naar NumAtCard, het referentieveld van de klant. SAP geeft DocEntry en DocNum terug. De koppeling bewaart ze naast het entity_id van Magento, om later de annulering en de zending aan de juiste order te hangen. Hoe dit in een ERP-koppeling past staat op ERP koppeling met je webshop.

Welk systeem is leidend, per gegeven

Wat Magento en SAP Business One anders bewaren

Magazijnen tegenover bronnen

Per artikel en magazijn geeft SAP InStock (wat er ligt) en Committed (wat aan klanten is toegezegd). Een magazijn heeft een WarehouseCode van maximaal 8 tekens. Magento met Multi-Source Inventory heeft bronnen met een eigen source_code, en rekent de verkoopbare voorraad zelf uit: de bronnen opgeteld, min de reserveringen van orders die nog niet verzonden zijn.

Een weborder die als verkooporder in SAP staat, zit dus aan twee kanten: in Committed bij SAP en als reservering in Magento. Schrijft de koppeling InStock - Committed naar de bron, dan gaat die order er twee keer af. Hij schrijft daarom per magazijn InStock min Committed, plus de weborders die SAP al heeft toegezegd en Magento nog reserveert. In het voorbeeld: 20 - 4 + 3 = 19 voor bron 01. Magento rekent 19 + 6 - 3 = 22, gelijk aan de 22 die SAP vrij heeft. Zodra de levering in SAP is geboekt, boekt de koppeling eerst de zending in Magento en schrijft hij daarna de nieuwe aantallen. Zie voorraad over meerdere magazijnen.

Artikelcodes van 20 tekens tegenover SKU's van 64

ItemCode is in SAP de sleutel van een artikel: uniek, verplicht, maximaal 20 tekens. Een Magento-SKU mag 64 tekens zijn. Varianten van een configurable product krijgen in Magento vaak een SKU die is samengesteld uit model, kleur en maat, zoals WERKJAS-PRO-BLAUW-XL: 20 tekens, net passend; met -XXL erachter niet meer. De koppeling houdt een vertaaltabel bij van SKU naar ItemCode. Het configurable product zelf heeft geen artikel in SAP; het bestaat alleen in Magento, met kleur en maat als attributen. Elk Magento-product heeft daarnaast een attribuutset nodig, en SAP kent die niet: de koppeling legt een tabel vast van artikelgroep in SAP naar attribuutset in Magento. Zie verplichte velden die de bron niet heeft.

Prijslijsten, speciale prijzen en klantgroepen

Een relatie in SAP hangt aan één prijslijst (PriceListNum). Een Magento-klant hangt aan één klantgroep (group_id). Die twee passen op elkaar: elke prijslijst wordt een klantgroep, en de prijzen worden tier prices met sku, customer_group, quantity en price.

Speciale prijzen per relatie passen er niet direct in, want Magento Open Source kent geen prijs per klant. Een relatie met speciale prijzen krijgt een eigen klantgroep, met de prijslijst als basis en de speciale prijzen en staffels erover. Een speciale prijs met een periode is lastiger: het special_price van Magento geldt voor iedereen in een store view, en de price_from moet later liggen dan het moment van schrijven. De koppeling zet een periodeprijs daarom als tier price voor de klantgroep van die relatie op de begindatum, en haalt hem weg op de einddatum.

Annuleren zonder over SAP heen te schrijven

Een verkooporder verwijderen kan in SAP Business One niet. Een annulering in Magento wordt in SAP een POST /Orders({DocEntry})/Cancel. Sinds 10.0 FP 2102 geeft de Service Layer bij orders een ETag. De koppeling stuurt die mee in If-Match:

POST /b1s/v2/Orders(4410)/Cancel HTTP/1.1
Cookie: B1SESSION=PTRzIjYK-weN6-1Lx1; ROUTEID=.node1
If-Match: W/"356A192B7913B04C54574D18C28D46E6395428AB"

HTTP/1.1 412 Precondition Failed
{"error": {"code": "-2039", "message": "Another user or
  another operation modified data; ..."}}

Een 412 betekent dat iemand de order in SAP heeft gewijzigd sinds de koppeling hem las, bijvoorbeeld een deellevering die al is ingepakt. De koppeling annuleert dan niet, maar zet de order op de controlelijst.

De technische werkelijkheid van deze combinatie

Nagelezen op 3 oktober 2026 in de documentatie van Adobe en de handleiding Working with SAP Business One Service Layer.

Voorraad doorgerekend. 3.000 SKU's in 2 magazijnen zijn 6.000 bronregels. Uit SAP is dat met $select op ItemCode en ItemWarehouseInfoCollection 3.000 / 500 = 6 pagina's. Naar Magento zijn het met de synchrone invoerlimiet van 20 regels 6.000 / 20 = 300 verzoeken, via het bulk-endpoint 2 verzoeken van maximaal 5.000. Na de eerste ronde gaan alleen gewijzigde regels mee.

Twee kanten zonder vaste limiet. Geen van beide API's heeft een gedocumenteerd aantal verzoeken per minuut. Allebei draaien ze op een server die ook je winkel of je administratie bedient. De koppeling leest SAP buiten de piekuren van je medewerkers en Magento buiten de piekuren van je winkel, en houdt één SAP-sessie vast in plaats van per aanroep in te loggen. Het bulk-endpoint van Magento hangt aan de consumer async.operations.all; draait die niet, dan blijven bewerkingen op status 4, Open, en ziet de koppeling dat bij de controle van de status. Je eigen aantallen reken je door met doorvoer berekenen.

Wat een standaardkoppeling hier niet doet

Standaardkoppelingen voor Magento 2 en SAP Business One beschrijven hun eigen grenzen. Bij een van die koppelingen stond:

• Eén richting: orders van Magento naar SAP. Tweerichtingsverkeer alleen als maatwerk op aanvraag.
• Producten en categorieën uit SAP via een cronjob, op een vast tijdstip in plaats van bij een wijziging.
• Belastingvelden via een vaste mapping tussen Magento en SAP, ingesteld in de koppeling.

Een gebouwde koppeling schrijft de voorraad per magazijn naar de juiste bron, rekent speciale prijzen om naar klantgroepen en annuleert in SAP alleen als de order daar niet is gewijzigd.

Als het misgaat

Voordat de koppeling een order schrijft, zoekt hij of er al een order met dezelfde NumAtCard bestaat, zodat een time-out halverwege geen tweede order oplevert. Een order die blijft falen wordt met de oorspronkelijke inhoud bewaard en gaat opnieuw mee zodra de oorzaak is opgelost. Voor livegang draait de koppeling als dry run: per SKU en per bron welk aantal en welke prijs er in Magento zou komen, en per order welke regels er in SAP zouden ontstaan, zonder iets te schrijven.

Wij hosten en bewaken de koppeling en passen hem aan als Adobe of SAP een interface wijzigt. De systeemkant staat op SAP Business One koppeling, de platformkant op Magento koppeling, en alle stromen op koppelingen. Verwante combinaties: WooCommerce SAP Business One koppeling en Shopify SAP Business One koppeling. Vertel welke Magento-versie en welke SAP-versie je draait.