Laat niet iedere WooCommerce-order automatisch doorstromen naar ERP en logistiek. Definieer vooraf welke statussen, verkoopkanalen, betaalwijzen, ordertypen en kenmerken een workflow mogen starten, en leg bij iedere afwijzing vast welke regel van toepassing was. Een expliciet gefilterde order is gezond; een stil verdwenen order is dat niet.
Waarom “alles synchroniseren” riskant is
Een webshop bevat meer dan normale betaalde verkooporders. Denk aan testorders, handmatig ingevoerde correcties, mislukte betalingen, concepten, abonnementstermijnen, nul-euro naleveringen en orders die door een ander proces worden afgehandeld. Als één generieke koppeling ze allemaal als nieuwe omzet behandelt, ontstaan fouten die pas in administratie of magazijn zichtbaar worden.
Filters horen daarom vóór de eerste externe schrijfhandeling. Ze moeten werken met de actuele, gevalideerde order en niet met een losse webhookregel. De uitkomst krijgt een herkenbare status zoals verwerkt, gefilterd of aandacht nodig. Zo kun je later uitleggen waarom order 7319 geen AFAS-order werd, zonder logregels te hoeven reconstrueren.
Maak per proces een filterkaart
| Vraag | Voorbeeldregel | Bij twijfel |
|---|---|---|
| Is de status geschikt? | Alleen betaald of expliciet vrijgegeven | Niet schrijven; zet apart |
| Hoort het verkoopkanaal erbij? | Alleen winkel NL, niet de testshop | Controleer werkruimte en winkel-ID |
| Is dit een financieel normale order? | Nalevering met nulwaarde volgt eigen route | Classificeer het ordertype |
| Welke fulfilment geldt? | Post, eigen bezorging of afhalen | Onbekende methode blokkeren |
| Zijn verplichte gegevens compleet? | Debiteur, adres en orderregels valide | Maak een herstelbare taak |
Gebruik één filterkaart per workflow, niet één ondoorzichtige verzameling uitzonderingen voor het hele landschap. De stroom naar AFAS kan andere toegangseisen hebben dan de stroom naar een vervoerder. Bekijk bij WooCommerce en AFAS koppelen waarom bron- en doelregels per bedrijfsobject moeten worden vastgelegd.
Fictief voorbeeld: proefbestelling wordt geen omzet
Fictief voorbeeld: meubelwebshop Kader & Kurk gebruikt een verborgen betaalmethode voor interne showroomtests. Een medewerker plaatst order 11204 om een nieuwe bezorgoptie te controleren. De order krijgt wel de status “in behandeling”, maar het kenmerk “interne proef” en de specifieke betaalmethode sluiten hem uit van de financiële workflow.
De gebeurtenis blijft zichtbaar als “gefilterd: interne proefbestelling”. De logistieke test kan desgewenst in een afzonderlijke sandboxroute doorgaan, zonder een verkoopboeking in AFAS of een echte zending te maken. Wanneer een normale klantorder met dezelfde verzendmethode binnenkomt maar een postcode mist, is dat geen filtergeval: die order voldoet inhoudelijk aan de scope maar is incompleet. Hij gaat naar “aandacht nodig”, met een taak om het adres te herstellen. Het verschil tussen buiten scope en herstelbaar fout is operationeel essentieel.
Controleer filters als productregels
Documenteer bij iedere regel de eigenaar, reden en verwachte levensduur. Een tijdelijke blokkade voor één campagne mag niet ongemerkt een permanente bedrijfsregel worden. Test positieve én negatieve voorbeelden: een order die door moet, een die gefilterd moet worden en een die naar handmatige aandacht moet. Laat operations de omschrijvingen beoordelen; “predicate false” is technisch correct maar helpt niemand.
- Kan een medewerker de filterreden vanuit de order vinden?
- Kun je gefilterde orders per winkel en reden tellen?
- Is opnieuw beoordelen mogelijk nadat de bronorder is gecorrigeerd?
- Zijn financiële en logistieke filters afzonderlijk getest?
- Is voorkomen dat herverwerking eerder gefilterde nevenacties alsnog dubbel uitvoert?
Connect kan zulke regels per configureerbare stroom toepassen. Uitzonderingen die inhoudelijke beoordeling vragen horen in Desk, met de ordercontext en duidelijke vervolgactie erbij.
Een goede periodieke controle begint niet met de code, maar met een export van filteruitkomsten. Rangschik redenen op aantal en financiële of operationele impact. Een plotselinge groei van “onbekende verzendmethode” wijst bijvoorbeeld eerder op een gewijzigde webshopconfiguratie dan op slechte orders. Neem vervolgens een steekproef uit iedere categorie en laat een proceseigenaar bevestigen dat de route klopt. Meet apart hoeveel gefilterde orders later opnieuw worden aangeboden; een hoog aandeel kan betekenen dat een tijdelijke bronstatus te vroeg als definitieve uitsluiting wordt gebruikt. Versiebeheer de regels en noteer per wijziging welke voorbeeldorders als regressietest dienen. Zo worden filters geen verborgen verzameling if-statements, maar een controleerbaar contract tussen verkoop, administratie en fulfilment.
Wil je jouw ordertypen en uitzonderingen vertalen naar een filterkaart? Plan een procesinventarisatie met Yindle.