Orderstatussen mappen tussen webshop, ERP en vervoerder

Drie sets statussen die niet op elkaar passen

Een order heeft in de webshop een status voor de klant, in het ERP een status voor de administratie en bij de vervoerder een status per pakket. De drie zijn door verschillende mensen ontworpen voor verschillende vragen, en daarom passen ze niet een op een. De webshop wil weten of er betaald is. Het ERP wil weten wat er geleverd en gefactureerd is. De vervoerder weet alleen waar het pakket is.

Zo ziet dat er per systeem uit, nagelezen in de documentatie van de leverancier op 3 oktober 2026:

Het grootste verschil zit tussen Shopify en WooCommerce. Shopify houdt betaling en levering in twee aparte velden bij: een order kan PAID en PARTIALLY_FULFILLED tegelijk zijn. WooCommerce heeft één veld voor alles. processing betekent volgens de documentatie van WooCommerce dat er betaald is, de voorraad is afgeboekt en de order klaarstaat om te verzenden. on-hold betekent dat de voorraad is afgeboekt maar de betaling nog bevestigd moet worden, bijvoorbeeld bij een bankoverschrijving of SEPA-incasso.

Wat de koppeling met elke status doet

Voor elke status in de bron legt de koppeling één van drie acties vast: een order aanmaken in het ERP, een bestaande order bijwerken, of niets doen. Voor WooCommerce naar Exact Online ziet een gangbare indeling er zo uit:

De tabel moet volledig zijn. Een status die er niet in staat, wordt niet geraden: de order gaat naar de controlelijst. Zo valt het op wanneer iemand een plugin installeert die een nieuwe status toevoegt.

De andere richting heeft dezelfde vraag. Exact Online kent status 20, gedeeltelijk geleverd. WooCommerce heeft standaard geen status voor een deellevering, Shopify wel: PARTIALLY_FULFILLED. Hoe een order met twee zendingen en twee trackingcodes terug naar de webshop gaat, staat in deelleveringen en track-and-trace.

Welke orders de koppeling ophaalt

Een koppeling die orders ophaalt in rondes, vraagt de webshop om orders met een bepaalde status. De voor de hand liggende vraag is "geef alle orders met status processing". In de REST API van WooCommerce ziet dat er zo uit:

GET /wp-json/wc/v3/orders?status=processing&per_page=100

Dat werkt tot een medewerker of een plugin de status verandert voordat de ronde langskomt. Een rekenvoorbeeld met een ronde elke 15 minuten:

• 09:02 order 10517 wordt betaald, status processing.
• 09:09 een medewerker zet hem op backorder, een eigen status uit een plugin, omdat één artikel ontbreekt.
• 09:15 de ronde vraagt om processing. Order 10517 staat er niet bij, en bij geen enkele latere ronde meer.

Het ERP heeft de order nooit gezien, terwijl hij betaald is. Gebeurt dit drie keer per werkdag, dan zijn dat over 22 werkdagen 66 orders die alleen in de webshop staan. Niemand merkt het tot de klant belt of de maandafsluiting niet klopt.

De robuuste vraag is anders: geef alle orders die sinds de vorige ronde zijn gewijzigd, ongeacht de status (modified_after), en beslis daarna per order wat ermee moet. Een order die al in het ERP staat wordt bijgewerkt, een nieuwe wordt aangemaakt als zijn status dat toelaat, en een onbekende status gaat naar de controlelijst. Bij webhooks geldt hetzelfde: luister naar order.updated, niet alleen naar order.created. Waarom een webhook alleen niet genoeg is, staat in wat is een webhook.

Een order die verandert nadat hij geboekt is

Een klant belt om 10 stuks terug te brengen naar 8. In Shopify past een medewerker de order aan; Shopify zet edited op waar en verstuurt de webhook orders/edited. Wat de koppeling daarna doet, hangt af van hoe ver de order in het ERP is.

De laatste regel komt uit de veldbeschrijving van SalesInvoices van Exact Online: een verwerkte factuur kan niet meer worden gewijzigd en niet worden heropend. In getallen: de order was 10 maal € 17,08 is € 170,80 exclusief btw. Na de wijziging is hij 8 maal € 17,08 is € 136,64. De koppeling maakt een creditnota van 2 maal € 17,08 is € 34,16, en de klant ziet in de administratie twee documenten die samen kloppen.

Ook bij een open order is niet alles te wijzigen. Exact Online vermeldt bij OrderedBy en InvoiceTo op de verkooporder dat die voor een bestaande order niet kunnen worden aangepast. Een klant die achteraf op een ander bedrijf besteld wil hebben, krijgt een geannuleerde order en een nieuwe. Waar dubbele klanten vandaan komen, staat in dubbele klanten en debiteuren.

Terug naar de klant: zendingen en de vervoerder

De derde set statussen komt van de vervoerder. Shopify kent per zending 11 statussen, waaronder LABEL_PRINTED, IN_TRANSIT, OUT_FOR_DELIVERY, ATTEMPTED_DELIVERY, DELIVERED en FAILURE. Vervoerders en verzendplatformen hebben elk hun eigen lijst. De koppeling vertaalt die naar de paar statussen die de klant te zien krijgt, en zet bij een mislukte bezorging een melding klaar in plaats van stil te wachten.

Twee regels voorkomen de meeste klachten. De order gaat pas naar completed of FULFILLED als de laatste zending weg is, niet bij de eerste. En een geannuleerde order in het ERP wordt pas in de webshop geannuleerd als vaststaat dat er niets is verstuurd; anders krijgt de klant een annuleringsmail voor een pakket dat al onderweg is.

Wat betekent dit voor je koppeling?

We leggen per status in elk systeem vast wat de koppeling doet: aanmaken, bijwerken of niets, en de lijst is volledig. Orders worden opgehaald op wijzigingsdatum, zodat een statuswissel tussen twee rondes geen order kost. Een order die na het boeken verandert, wordt bijgewerkt zolang dat mag en anders gecorrigeerd met een creditnota. Een onbekende status gaat naar de controlelijst. In de dry run zie je voor de orders van de afgelopen weken welke actie elke order zou krijgen.

Statussen zijn een van de velden in de orderstroom, naast debiteuren, adressen, bedragen en datums. Het overzicht staat op orders, klanten en verzending; retouren en creditnota's staan uitgewerkt op retouren en creditnota's. Stuur de lijst met statussen uit je webshop mee, dan zie je per status wat de koppeling ermee doet.