Kennisbank
Dubbele klanten en debiteuren na een koppeling: hoe ze ontstaan
Dubbele debiteuren ontstaan doordat de webshop een klant herkent aan een e-mailadres en het ERP aan een debiteurnummer. Vindt de koppeling geen match, dan maakt hij een nieuwe debiteur aan, ook als de klant er al in staat onder een ander e-mailadres.
Bijgewerkt op
Waar het misgaat
De webshop en het ERP gebruiken een andere sleutel voor dezelfde klant. De webshop kent een e-mailadres en een eigen klant-ID. Het ERP kent een debiteurnummer. Tussen die twee zit geen vaste relatie, en elke order waarbij de koppeling de relatie niet vindt, levert een nieuwe debiteur op.
| Situatie | Wat de koppeling ziet | Gevolg zonder matchregel |
|---|---|---|
| Gastbestelling | geen klant-ID (in WooCommerce customer_id 0), alleen een e-mailadres |
elke gastorder een nieuwe debiteur |
| Bestaande klant, ander e-mailadres | inkoop@ in het ERP, j.bakker@ in de order |
tweede debiteur voor hetzelfde bedrijf |
| Eén persoon bestelt voor twee bedrijven | zelfde e-mailadres, andere bedrijfsnaam | order op het verkeerde bedrijf |
| Drie contactpersonen bij één organisatie | drie e-mailadressen, één btw-nummer | drie debiteuren in plaats van één met drie contactpersonen |
| Andere schrijfwijze | Bakker Installatie B.V. en Bakker Installatie BV |
geen match op naam |
| De klant stond al twee keer in het ERP | twee treffers | de eerste wint, omzet verdeeld over twee debiteuren |
De laatste rij bestaat vaak al voordat de koppeling er is. Een debiteur die in 2019 handmatig is aangemaakt en in 2022 nog een keer, valt pas op als een koppeling op beide een treffer krijgt.
Reken het door voor een webshop met 400 orders per maand, waarvan 120 als gast. Zonder match op e-mailadres zijn dat 120 nieuwe debiteuren per maand en 1.440 per jaar, ook als het steeds dezelfde 80 klanten zijn. Het gevolg is geen technisch probleem maar een boekhoudkundig: openstaande posten staan verspreid, de kredietlimiet per debiteur klopt niet meer, en een klantspecifieke prijs hangt aan de oude debiteur terwijl de order op de nieuwe binnenkomt.
Matchen in een vaste volgorde
Een koppeling zoekt een debiteur in een vaste volgorde, van het meest betrouwbare kenmerk naar het minst betrouwbare.
| Stap | Zoekt op | Waarom op deze plek |
|---|---|---|
| 1 | btw-nummer of KvK-nummer van de organisatie | uniek per rechtspersoon en verandert niet |
| 2 | e-mailadres van de organisatie | algemeen adres, vaak gedeeld door een afdeling |
| 3 | e-mailadres van de contactpersoon | persoonlijk adres, wisselt bij een nieuwe medewerker |
| 4 | geen treffer: nieuwe debiteur aanmaken | pas als stap 1 tot en met 3 niets opleveren |
Vier dingen maken de volgorde betrouwbaar.
Normaliseren voor het vergelijken. NL 8123.45.678.B01 en NL812345678B01 zijn hetzelfde btw-nummer en J.Bakker@Bakker-Installatie.example met een spatie erachter is hetzelfde e-mailadres als de versie in kleine letters. De koppeling haalt punten en spaties weg en zet alles in kleine letters voordat hij zoekt.
Zoeken op het veld zoals het ERP het bewaart. In Exact Online is de debiteurcode Code een tekst van 18 tekens, aangevuld met spaties aan de voorkant. Een filter op 10432 vindt niets, een filter op 13 spaties gevolgd door 10432 wel. Een koppeling die dat mist, vindt nooit een bestaande debiteur en maakt er bij elke order een aan. Alleen Code is in de documentatie van Exact Online een unieke sleutel. Op e-mailadres en btw-nummer moet de koppeling dus zelf op dubbelen letten.
Twee treffers is geen match. Vindt een stap twee debiteuren, dan kiest de koppeling er niet zelf een. De order gaat naar een controlelijst met beide debiteurnummers erbij.
Bedrijf of persoon. Is het veld bedrijfsnaam gevuld, dan wordt het een organisatie met een contactpersoon. Is het leeg, dan een persoon. AFAS Profit kent daar twee soorten verkooprelatie voor: KnSalesRelationOrg en KnSalesRelationPer. Klanten vullen in dat veld ook n.v.t., - of particulier in. Zonder filter op die waarden staat er een organisatie met de naam "n.v.t." in het ERP.
Een koppeling die alleen aanmaakt en nooit bijwerkt, lost de helft op. Verhuist een klant en past hij zijn adres aan in de webshop, dan blijft het oude factuuradres in het ERP staan. Per veld leg je vast welk systeem leidend is: het ERP voor betaalconditie en kredietlimiet, de webshop voor het afleveradres van deze order. Hoe adressen zelf over de lijn gaan staat in adresvelden mappen.
Voor consumentenorders is er een andere route: alle orders op één verzameldebiteur, met naam en adres op de order zelf. Dan ontstaan er geen debiteuren, en zie je ook geen openstaande posten per klant.
Dubbele orders en facturen
Hetzelfde mechanisme speelt bij orders. De koppeling stuurt order 20418 naar het ERP. Het ERP boekt hem, maar het antwoord komt niet aan omdat de verbinding na 30 seconden een timeout geeft. De koppeling weet niet of de order geboekt is en probeert het opnieuw. Nu staat order 20418 er twee keer in, met twee facturen en twee keer voorraadreservering.
Er zijn twee manieren om dat te voorkomen.
Een controle op de referentie. De koppeling schrijft het webshopordernummer in een referentieveld van de order in het ERP, bij Exact Online in YourRef. Voor elke nieuwe order vraagt hij eerst of er al een order met die referentie bestaat. Dat kost één extra aanroep per order: bij 150 orders per dag 150 aanroepen, die je meetelt in de doorvoer.
Een idempotency key. De koppeling stuurt bij elke aanroep een unieke sleutel mee. Komt dezelfde sleutel een tweede keer binnen, dan geeft de API het eerste antwoord terug en boekt hij niets opnieuw.
POST /orders HTTP/1.1
Content-Type: application/json
Idempotency-Key: webshop-order-20418
Betaalprovider Mollie ondersteunt deze header en bewaart een sleutel één uur. Shopify doet hetzelfde in GraphQL met een argument bij de mutatie. Een vastgestelde standaard is het niet: het voorstel bij de IETF is als concept verlopen. Waar de API van een ERP zo'n sleutel niet kent, blijft de controle op de referentie over.
Twee dingen horen erbij. Een webhook wordt minstens één keer afgeleverd, dus soms twee keer: de koppeling herkent het tweede bericht aan het ordernummer en slaat het over. En ordernummers krijgen een voorvoegsel per kanaal, zodat order 123 uit de webshop en order 123 van een marktplaats niet als dezelfde order worden gezien.
Twee bronnen op één artikel
Dubbel bestaat ook aan de artikelkant. Twee leveranciers voeren artikel 10482 en beide sturen een voorraadbestand. Leverancier A meldt om 06:00 uur 12 stuks, leverancier B om 06:30 uur 0. Zonder regel wint de laatste ronde: de webshop toont van 06:30 tot de volgende ronde van A nul, terwijl er 12 leverbaar zijn.
| Regel | A meldt 12, B meldt 0 | A meldt 12, B meldt 5 |
|---|---|---|
| Laatste ronde wint | 0 of 12, afhankelijk van het tijdstip | 5 of 12, afhankelijk van het tijdstip |
| Eén eigenaar per artikel: A | 12 | 12 |
| Optellen | 12 | 17 |
| Voorrang: A, en B alleen als A nul meldt | 12 | 12 |
Dezelfde vraag geldt tussen je eigen voorraad en die van een leverancier. Een leveranciersbestand vult aan waar je zelf niets hebt liggen en overschrijft nooit de telling van je eigen magazijn. Hoe dat per bron wordt ingesteld staat op leveranciersvoorraad koppelen.
Wat betekent dit voor je koppeling?
Wij leggen de matchvolgorde, de regel bij twee treffers en de eigenaar per veld vast voordat de koppeling live gaat. Bij de proefronde zie je welke bestaande debiteuren een btw-nummer of e-mailadres delen, zodat je die in het ERP kunt opschonen voordat er orders op binnenkomen. Elke order krijgt een controle op de referentie, zodat een herhaalpoging geen tweede boeking oplevert. Wat niet eenduidig te matchen is, staat op een controlelijst in het dashboard.
De orderstroom als geheel staat op orders koppelen. Hoe klanten en orders passen in de koppeling met je ERP lees je in je webshop koppelen aan je ERP. Wil je weten hoe dit voor jouw debiteurenbestand uitpakt, stuur dan je systemen in.
Veelgestelde vragen
Hoe voorkom je dubbele debiteuren bij een webshopkoppeling?
Met een vaste matchvolgorde. De koppeling zoekt eerst op btw-nummer of KvK-nummer, dan op het e-mailadres van de organisatie, dan op dat van de contactpersoon. Alleen als alle stappen niets opleveren maakt hij een debiteur aan. Bij twee of meer treffers gaat de order naar een controlelijst.
Kan een koppeling bestaande dubbele debiteuren samenvoegen?
Samenvoegen is een handeling in het ERP zelf, omdat er openstaande posten en historie aan beide debiteuren hangen. Wat de koppeling wel doet is ze zichtbaar maken: bij de proefronde voor de livegang komt er een lijst van debiteuren die hetzelfde btw-nummer of e-mailadres delen.
Wat gebeurt er met gastbestellingen?
Een gastbestelling heeft geen klantaccount, alleen een e-mailadres en een adres. De koppeling matcht op e-mailadres, of boekt alle consumentenorders op één verzameldebiteur. Welke van de twee past hangt af van de vraag of je per klant openstaande posten wilt zien. Zie verzameldebiteur.
Waarom staat dezelfde order twee keer in mijn ERP?
Meestal door een herhaalpoging na een timeout. Het ERP had de order al geboekt, maar het antwoord kwam niet aan en de koppeling stuurde hem opnieuw. Een controle op het webshopordernummer in het referentieveld van het ERP, voor elke nieuwe order, voorkomt de tweede boeking.
Wat als twee leveranciers hetzelfde artikel leveren?
Dan heeft het artikel twee bronnen voor voorraad en levertijd en wint zonder regel de laatste ronde. Je kiest per artikel of per veld één eigenaar, telt de voorraden op, of geeft een leverancier voorrang en gebruikt de tweede alleen als de eerste nul meldt.
Vertel wat je nodig hebt
Vertel welke systemen je gebruikt en wat je wilt verbeteren. Je krijgt binnen één werkdag een persoonlijk antwoord. We helpen je de werkzaamheden helder te krijgen en spreken de prijs en planning af voordat je iets toezegt.
- Je weet de prijs en de doorlooptijd voordat je iets toezegt
- Wij zoeken uit welke koppeling het werk uit handen neemt
- Wij verzorgen de bouw, hosting, bewaking en het onderhoud
- Je team krijgt minder overtypwerk en minder uitzoekwerk