PrestaShop koppeling met ERP, boekhouding, magazijn en leveranciers

Wat is PrestaShop en wie gebruikt het?

PrestaShop is open-source webwinkelsoftware in PHP die je zelf host of laat hosten. De klantvelden siret en ape zijn Franse bedrijfsnummers die in een Nederlandse shop leeg blijven; een btw-nummer staat niet op de klant maar op het adres. Modules voegen betaalmethoden, vervoerders en eigen velden toe, en een koppeling moet die velden dan ook lezen of vullen.

Twee hoofdversies zijn in gebruik. Welke je draait, bepaalt welke API er naast de webservice bestaat.

Wat je met PrestaShop koppelt

PrestaShop is leidend voor orders en webklanten. Artikelen, prijzen en voorraad komen uit het ERP, het boekhoudpakket of het magazijnsysteem.

Een order heeft een id, dat in elk API-pad staat, en een reference die de klant ziet. Die referentie is standaard negen hoofdletters zonder cijfers, zoals XKBKNABJK, tenzij een module een eigen nummer genereert. De koppeling zet de referentie in het ERP als extern ordernummer en bewaart het id om later de status en het trackingnummer terug te boeken. Een statuswijziging is een nieuwe regel in order_histories; met sendemail=1 stuurt PrestaShop de klant de mail die bij die status hoort. Hoe de statussen van twee systemen op elkaar passen staat in orderstatussen mappen.

Hoe PrestaShop data vrijgeeft

De webservice op /api

De webservice staat standaard uit. De beheerder zet hem aan onder Geavanceerde parameters, Webservice, en maakt daar een sleutel van 32 tekens. Per resource kies je wat die sleutel mag: lezen, aanmaken, wijzigen, verwijderen. De sleutel gaat als gebruikersnaam mee in een Basic-authenticatiekop, met een leeg wachtwoord. Er is geen token dat verloopt; wie de sleutel heeft, heeft toegang tot hij wordt ingetrokken.

Het adres /api werkt alleen als URL rewriting aanstaat. Op Apache doet .htaccess dat, en dan moet mod_rewrite aanstaan en de VirtualHost AllowOverride All hebben. Een shop waar de beheerkant werkt maar /api een 404 geeft, zit bijna altijd hier vast.

XML erin, JSON eruit

Een PUT met een record dat met een beperkte veldlijst is opgehaald, faalt: PrestaShop valideert het als een nieuw record. De koppeling schrijft daarom met PATCH. Zo ziet een voorraadwijziging eruit:

PATCH /api/stock_availables/2210 HTTP/1.1
Authorization: Basic VUNDTExROU4yQVJTSFdDWExUNzRLVUtTU0szNEJGS1g6
Content-Type: application/xml

<prestashop>
  <stock_available>
    <id>2210</id>
    <quantity>16</quantity>
  </stock_available>
</prestashop>

Geen limiet, geen meldingen, geen batch

PrestaShop documenteert geen limiet op de webservice. De grens is de server waarop je shop draait. De documentatie beschrijft ook geen batchverzoek en geen melding bij een nieuwe order: elke wijziging is een eigen aanroep, en orders haalt de koppeling op met een filter op date_add sinds de vorige ronde.

De rekensom voor een volledige voorraadronde van 9.000 combinaties. Lezen gaat in pagina's: met limit van 1.000 zijn dat 9 aanroepen. Schrijven gaat per regel: 9.000 aanroepen. Neem je 0,25 seconde per aanroep aan, dan is dat 9.000 x 0,25 = 2.250 seconden, 37,5 minuten. De koppeling vergelijkt daarom eerst en schrijft alleen de regels die echt veranderd zijn; op een gewone dag zijn dat er tientallen. Je eigen aantallen reken je door met doorvoer berekenen.

De Admin API van PrestaShop 9

PrestaShop 9 heeft een tweede API op /admin-api, gebouwd op API Platform. Die werkt met OAuth2 via client_credentials, JSON in beide richtingen en scopes per resource, zoals product_read. Het client secret wordt één keer getoond, het token verloopt na de levensduur die je bij de client instelt (in het voorbeeld van PrestaShop 3.600 seconden), en in productie is HTTPS verplicht. De resources komen uit de module ps_apiresources. Op 3 oktober 2026 stonden daar producten, combinaties, klanten en adressen in, maar geen orders en geen voorraad.

Waar het bij PrestaShop op vastloopt

Beschikbare voorraad tegenover fysieke voorraad

In de database bewaart PrestaShop per product of combinatie drie getallen: physical_quantity, reserved_quantity en quantity. Gereserveerd is wat in orders staat met een status die nog niet als verzonden telt. quantity is wat er te koop is, en het fysieke aantal rekent PrestaShop uit als quantity plus gereserveerd. De webservice geeft alleen quantity.

De rekensom: het ERP heeft 20 stuks, en 4 daarvan staan in een weborder die het ERP nog niet heeft verwerkt. Schrijft de koppeling 20 in quantity, dan maakt PrestaShop het fysieke aantal 24 en verkoopt hij er 20, terwijl er 16 vrij zijn. De koppeling schrijft dus de ERP-voorraad min de weborders die nog niet in het ERP staan: 20 - 4 = 16. Is de order wel verwerkt en meldt het ERP al 16 vrij, dan trekt de koppeling niets meer af. Het veld quantity is een geheel getal; een ERP dat in 2,5 meter rekent, wordt per verkoopeenheid omgerekend. Zie welke voorraad toon je in je webshop.

Combinaties en referenties

Een variant is in PrestaShop een combinatie onder één product, met een eigen reference van maximaal 64 tekens en een eigen ean13. Een product zonder combinaties heeft zijn referentie op het product zelf. Het veld quantity op een product is in de webservice alleen-lezen: voorraad gaat altijd via stock_availables, met id_product en id_product_attribute als sleutel. De koppeling bouwt dus een vertaaltabel van artikelnummer naar die twee ID's en houdt hem bij als er een combinatie bijkomt. Een artikelnummer dat in PrestaShop twee keer voorkomt, komt op een controlelijst. Meer op varianten.

Adres en btw

Een adres heeft address1 en address2, elk 128 tekens, en een postcode van 12. Een huisnummerveld is er niet. Een ERP met straat, huisnummer en toevoeging als drie velden krijgt een gesplitst adres; wat niet te splitsen is, gaat naar de controlelijst. Het btw-nummer staat op het adres (vat_number), niet op de klant. Zie adresvelden mappen.

Een orderregel geeft de prijs met en zonder btw (unit_price_tax_incl, unit_price_tax_excl) en een id_tax_rules_group, maar geen percentage. De koppeling legt een tabel vast van belastingregelgroep naar btw-code in het ERP en controleert per regel of het bedrag past.

Multistore

Met multistore aan krijgt elke aanroep een id_shop of id_group_shop. Een winkelgroep met share_stock deelt één voorraadregel per combinatie. De koppeling schrijft dan per groep, niet per winkel, anders overschrijven twee winkels elkaars aantal.

Systemen die we aan PrestaShop koppelen

De koppeling wordt gebouwd op jouw PrestaShop, jouw modules en het systeem erachter. Wat er aan de systeemkant speelt staat per systeem op een eigen pagina: Exact Online koppeling, AFAS webshop koppeling, SnelStart koppeling, Business Central koppeling en Picqer koppeling. Andere platformen: WooCommerce koppeling en Magento koppeling. Alle stromen staan op koppelingen.

Wij bouwen de koppeling voor een vaste prijs en hosten, draaien en bewaken hem daarna voor een vast bedrag per maand. Voor livegang draait hij als dry run: je ziet per combinatie welk aantal en welke prijs er in PrestaShop zou komen, zonder dat er iets wijzigt. Vertel welke PrestaShop-versie je draait en welk systeem erachter staat.