Een betrouwbare WooCommerce-AFAS-koppeling begint met één simpele afspraak: voor elk gegeven is precies één systeem leidend. Een data-eigenaarsmatrix maakt die afspraak zichtbaar. Daarin leg je per object vast waar het ontstaat, waar het mag worden gewijzigd en welke systemen alleen een kopie ontvangen.
Zonder die matrix ontstaat gemakkelijk een stille strijd tussen systemen. Een klant wijzigt een adres in de webshop, een medewerker past het in AFAS aan en de volgende synchronisatie zet één van beide versies terug. Technisch lijkt alles actief, maar niemand weet nog welke waarde klopt.
Wat is data-eigenaarschap?
De eigenaar van een gegeven is het systeem dat de gezaghebbende versie beheert. Dat hoeft niet het systeem te zijn waarin een gebruiker het gegeven als eerste invoert. Een bezorgadres kan in WooCommerce worden ingevuld, vervolgens worden gevalideerd en daarna als onderdeel van de order naar AFAS gaan. Het orderadres blijft dan een momentopname, terwijl het algemene klantadres elders kan worden beheerd.
Maak daarom onderscheid tussen begrippen die op elkaar lijken:
- klantprofiel: de actuele algemene gegevens van de klant;
- debiteur: de administratieve relatie inclusief voorwaarden;
- orderadres: het adres dat voor één bestelling gold;
- bezorgstop: de operationele bestemming voor planning;
- factuuradres: de juridische of financiële momentopname.
Als de integratie al deze adressen als één veld behandelt, zijn correcties en historie nauwelijks betrouwbaar te houden.
Bouw de matrix per bedrijfsobject
Gebruik voor ieder relevant object minimaal de volgende kolommen: bedrijfsbetekenis, eigenaar, invoerpunt, toegestane wijzigingen, ontvangers, unieke sleutel, synchronisatiemoment en herstelprocedure. Begin met de objecten die direct invloed hebben op levering of geld.
| Object | Mogelijke eigenaar | Belangrijkste afspraak |
|---|---|---|
| Webshoporder | WooCommerce bij aankoop | AFAS ontvangt een herkenbare administratieve representatie |
| Debiteur | AFAS | Nieuwe webshopklant eerst matchen met bestaande relaties |
| Artikelidentiteit | AFAS, PIM of afgesproken catalogus | SKU en AFAS-code ondubbelzinnig mappen |
| Voorraad | AFAS of fulfilmentsysteem | Definieer verkoopbare voorraad en relevante magazijnen |
| Betaling | Betaalprovider voor transactie-uitkomst | Administratie ontvangt een gecontroleerde verwerking |
| Bezorgstatus | Vervoerder of routeplatform | Vertaal technische statussen naar klantbetekenis |
Dit zijn mogelijke keuzes, geen verplicht model. De essentie is dat de organisatie ze expliciet maakt. Noteer ook wie intern eigenaar is van de afspraak. Anders wordt een technisch team verantwoordelijk gemaakt voor een bedrijfsbesluit dat nooit genomen is.
Voorkom symmetrische synchronisatie
“Alles twee kanten op” klinkt flexibel, maar creëert meer conflictregels dan waarde. Kies liever een duidelijke richting per doel. Voorraad stroomt bijvoorbeeld van AFAS naar WooCommerce. Een nieuwe bestelling stroomt van WooCommerce naar AFAS. De orderstatus kan daarna weer terugstromen, maar is een ander gegeven met een andere eigenaar.
Voor gegevens die echt in meerdere systemen bewerkt mogen worden, heb je een conflictstrategie nodig. Mogelijkheden zijn een tijdstempel, veldniveau-eigenaarschap of een expliciete reviewtaak. Een simpele regel als “de laatste wijziging wint” is gevaarlijk wanneer systeemklokken, vertraagde berichten of bulkcorrecties meespelen.
Leg identiteit los van zichtbare labels vast
Gebruik stabiele sleutels om objecten te herkennen. Een productnaam, verzendmethode of klantnaam kan wijzigen en is daarom geen geschikte technische identiteit. Een SKU kan bruikbaar zijn als de organisatie garandeert dat deze uniek en stabiel blijft; anders is aanvullende mapping nodig.
Hetzelfde geldt voor verzendmethoden. Match niet op een vertaalde tekst die een klant in checkout ziet, maar op een exacte methodecode. Anders kan een kleine tekstwijziging onbedoeld een afhaalorder als bezorgorder behandelen.
Test de matrix met uitzonderingen
Een matrix is pas bruikbaar als zij ook lastige situaties oplost. Loop ten minste deze scenario’s door:
- Een bekende klant bestelt met een nieuw bezorgadres.
- Een onbekende klant lijkt sterk op een bestaande AFAS-relatie.
- Een SKU ontbreekt of verwijst naar meerdere artikelen.
- Voorraad verandert terwijl een klant afrekent.
- Een order wordt gewijzigd nadat deze al naar AFAS is verstuurd.
- Een systeem accepteert een wijziging, maar de bevestiging komt niet terug.
Voor iedere situatie moet duidelijk zijn welk systeem beslist, welke informatie wordt bewaard en wie een uitzondering afhandelt. Dat levert ook de eisen op voor monitoring en een beheerinterface.
In webshop en ERP betrouwbaar koppelen werken we deze procesbenadering verder uit. De concrete WooCommerce-AFAS-stroom staat op WooCommerce en AFAS koppelen. Yindle Connect vormt de beheersbare laag tussen de betrokken systemen.
Drie governancevragen die techniek niet kan beslissen
Wie mag een gegeven corrigeren?
Wijs naast een systeemeigenaar ook een proceseigenaar aan. Een integratie kan afdwingen dat AFAS leidend is voor kredietvoorwaarden, maar bepaalt niet welke medewerker zo’n voorwaarde mag aanpassen. Noteer per kritisch veld wie mag corrigeren, waar dat gebeurt en hoe ontvangers de wijziging krijgen.
Hoe lang moet historie beschikbaar blijven?
Voor een actuele voorraadwaarde is meestal de laatste bevestigde stand belangrijk; voor een orderadres moet juist aantoonbaar blijven wat bij aankoop gold. Bepaal per object of je alleen actuele toestand, een wijzigingshistorie of een complete momentopname nodig hebt. Dat voorkomt zowel te weinig bewijs als onnodige kopieën van persoonsgegevens.
Wat gebeurt er bij een tijdelijke bronfout?
Leg vast of een doel de laatst bekende waarde mag blijven tonen, de functie moet blokkeren of een handmatige taak ontstaat. Bij producttekst is enige vertraging vaak acceptabel; bij voorraad, betaling of een leverbelofte kan dezelfde keuze onverantwoord zijn. Voeg die toleranties als kolom aan de matrix toe.
Onderhoud de matrix als productdocument
Herzie de afspraken wanneer een nieuw magazijn, verkoopkanaal, betaalproces of klanttype wordt toegevoegd. Laat bij iedere relevante wijziging controleren of identiteit, richting en bewaarbeleid nog kloppen. Een gedateerde matrix is gevaarlijker dan geen matrix, omdat ontwikkelaars en gebruikers erop vertrouwen dat de beschreven autoriteit nog geldt.
Van matrix naar uitvoerbare afspraken
Laat de matrix goedkeuren door e-commerce, administratie, logistiek en klantenservice. Zij kijken ieder naar een ander gevolg van dezelfde data. Vertaal de definitieve keuzes daarna naar mappings, validaties, rechten, eventfilters en herstelstappen. Bewaar de matrix als onderdeel van de functionele documentatie en pas haar aan wanneer het proces verandert.
Wil je de eigenaarschapstwisten uit een bestaande koppeling halen? Plan een korte procesinventarisatie met Yindle. We maken de gegevensstromen en uitzonderingen eerst zichtbaar en bepalen daarna welke automatisering passend is.