Koppelingen
Herleidbaarheid: bij elk verschil terugzien waar het vandaan kwam
Bij elke waarde die de koppeling schrijft, zie je terug wanneer hij binnenkwam, uit welk systeem en met welke regel hij is berekend. Een vraag van een klant of je accountant over één order of één voorraadstand beantwoord je in de log, zonder twee systemen naast elkaar te leggen.
Een eindstand zegt niet hoe hij is ontstaan
Artikel 10482 staat in de webshop op 86 stuks. In het magazijn liggen er 100. Of dat klopt, is aan de eindstand niet te zien: 86 kan het goede getal zijn, of het resultaat van een gemiste mutatie. Wat je nodig hebt is de weg ernaartoe: welke waarden kwamen binnen, welke regel is toegepast en wanneer.
Bij een paar honderd artikelen kun je dat nog navragen. Een voorraadstroom over 15.000 artikelen die elk uur draait, leest 360.000 records per dag. Wijzigen er per ronde 312, dan zijn dat 7.488 wijzigingen per dag en ruim 220.000 per maand. Zonder log is één verkeerde waarde daarin niet terug te vinden, en is de vraag "waarom stond dit artikel dinsdag op 0?" niet te beantwoorden.
Hoe werkt het?
De log heeft drie niveaus, plus de invoer bij elke wijziging.
- Run. Elke ronde van een stroom: begin, einde, en de tellingen gelezen, gewijzigd, overgeslagen en afgekeurd.
- Bericht. Elk record in die ronde, met een status.
- Veldwijziging. Per veld de oude en de nieuwe waarde, de bron en de regel die is toegepast, met de bronwaarden waaruit de nieuwe waarde is berekend.
De wijziging van artikel 10482 staat er zo in:
{
"run": "voorraad-2026-10-03T10:00",
"artikel": "10482",
"veld": "voorraad",
"oud": 94,
"nieuw": 86,
"bron": "Exact Online, magazijn Zwolle",
"invoer": {"fysiek": 100, "gereserveerd": 12, "veiligheidsvoorraad": 2},
"regel": "fysiek - gereserveerd - veiligheidsvoorraad",
"geschreven": "2026-10-03T10:00:41+02:00"
}
De vraag van de klant is daarmee beantwoord: 100 min 12 gereserveerd voor open orders min 2 veiligheidsvoorraad is 86. In de vorige ronde stonden er 4 gereserveerd, en 100 min 4 min 2 was 94. Het verschil van 8 zijn nieuwe orders, en die staan in de log van de orderstroom. Hoe beschikbare voorraad wordt berekend staat in welke voorraad toon je in je webshop.
Vijf statussen per bericht
| Status | Betekenis | Wat er daarna gebeurt |
|---|---|---|
| verwerkt | geschreven en bevestigd door het ontvangende systeem | niets |
| overgeslagen | geen wijziging, of het record staat op de uitsluitingslijst | niets; de reden staat erbij |
| afgekeurd | geweigerd met een 400 of 422 |
naar de foutenlijst met inhoud en reden |
| wachtend | in de wachtrij, bijvoorbeeld na een 429 of 503 |
nieuwe poging met oplopende pauzes |
| onbekend | time-out zonder antwoord | eerst zoeken of het record al bestaat, dan pas opnieuw |
De vijfde status bestaat omdat een time-out niet betekent dat het mislukt is. Exact Online kan de order hebben aangemaakt terwijl het antwoord onderweg verloren ging. De koppeling zoekt daarom eerst op het webshopnummer in Description en maakt pas een order als die niet bestaat. Hoe een storing verder verloopt staat in wat gebeurt er als een koppeling uitvalt.
Wie heeft dit veranderd?
De log van de koppeling toont wat de koppeling heeft gedaan. De systemen zelf houden bij wie er iets heeft gewijzigd, elk op hun eigen manier:
| Systeem | Wat het zelf bijhoudt | Wat er niet in staat |
|---|---|---|
| Exact Online | Created, CreatorFullName, Modified, ModifierFullName op onder meer de verkooporder |
de vorige waarde van een veld |
| Shopify | gebeurtenissen met appTitle, attributeToApp en message |
de invoer waaruit een waarde is berekend |
| WooCommerce | ordernotities met author en added_by_user |
een historie van productvelden in de REST API |
| Picqer | voorraadhistorie met old_stock, stock_change, new_stock, change_type en gebruiker |
wat de webshop met die voorraad deed |
Velden nagelezen op 3 oktober 2026 in de documentatie van Exact Online, Shopify, WooCommerce en Picqer.
Die velden zijn alleen bruikbaar als de koppeling een eigen gebruiker heeft. Draait hij onder het account van een medewerker, dan staat bij elke order van de webshop diens naam als maker. Een handmatige correctie en een automatische wijziging zijn dan niet meer van elkaar te onderscheiden.
Wat er stil misgaat
Een handmatige waarde wordt overschreven. Iemand zet een actieprijs met de hand in de webshop, de volgende prijsronde zet de prijs uit het ERP terug. In de log staat bij die run: prijs van 9,95 naar 12,50, bron ERP. Daarmee is de oorzaak gevonden, en de oplossing is een uitsluiting of een override. Zie dry run en goedkeuring.
Een record wordt overgeslagen zonder reden. Een artikel met een lege EAN valt af op een regel, en de run meldt 14.999 verwerkt in plaats van 15.000. Zonder reden per bericht is dat ene artikel niet te vinden. Met reden staat er: overgeslagen, EAN leeg.
De log en de administratie verwijzen niet naar elkaar. Een boeking zonder webshopnummer is in de administratie niet terug te leiden naar een order. Je administratie bewaar je volgens de Belastingdienst 7 jaar, en voor de verkoopadministratie en het grootboek is geen kortere termijn af te spreken (nagelezen op 3 oktober 2026). De log van een voorraadstroom bewaar je korter. Het webshopnummer staat daarom in de boeking zelf, zodat een accountant elke boeking terugvindt bij de order.
Wat je ermee regelt
- Per run een overzicht. Gelezen, gewijzigd, overgeslagen en afgekeurd, met een link naar elk bericht.
- Per waarde de herkomst. Oude en nieuwe waarde, bron, regel en de bronwaarden.
- Zoeken op één record. Op ordernummer, artikelnummer of debiteur: alles wat de koppeling ermee heeft gedaan, op volgorde.
- Opnieuw aanbieden. Een afgekeurd bericht na herstel opnieuw verwerken, met beide pogingen in de log.
- Een eigen gebruiker per systeem. Wijzigingen van de koppeling zijn in elk systeem herkenbaar.
De log hoort bij de monitoring: de monitoring meldt dat er iets mis is, de log laat zien wat. De stromen zelf staan op koppelingen, met de details per stroom op voorraad en orders, klanten en verzending.
Wat een standaardkoppeling hier niet doet
De documentatie van standaardkoppelingen en koppelplatformen beschrijft een log per run of per bericht: gelukt, overgeslagen of mislukt, met de oorzaak bij een fout. Een veld met de oude en de nieuwe waarde en de invoer waaruit een waarde is berekend, komen in die beschrijvingen niet voor. Bij een mislukt bericht zie je de fout, bij een gelukt bericht alleen dat het gelukt is.
Voor artikel 10482 betekent dat: de log meldt om 10:00 "verwerkt", en de vraag waarom het 86 is en niet 100 gaat terug naar het magazijn en het ERP.
In een koppeling op jouw systemen is de log onderdeel van de bouw. In het dashboard zoek je op een ordernummer of artikelnummer en zie je per stap wat er is gebeurd. Vertel welke systemen je koppelt.
Veelgestelde vragen
Hoe lang blijft de log bewaard?
Dat leg je per stroom vast. Voor voorraad, waar elk uur duizenden regels langskomen, is een paar maanden meestal genoeg. Voor orders en facturen is de log het bewijs van wat er in de administratie is gezet. Het ordernummer van de webshop staat daarom ook in de boeking zelf, zodat die verwijzing even lang blijft als de administratie.
Kan ik zien wie een waarde met de hand heeft veranderd?
In de log van de koppeling staat wat de koppeling heeft gedaan. Een handmatige wijziging staat in het systeem waar hij is gedaan: Exact Online toont ModifierFullName, Picqer de gebruiker bij elke voorraadmutatie. Omdat de koppeling een eigen gebruiker heeft, zie je in die systemen ook welke wijzigingen van de koppeling kwamen en welke niet.
Staan er persoonsgegevens in de log?
Zo min mogelijk. Een order staat in de log met ordernummer, debiteurnummer, regels en bedragen. Naam, adres en e-mailadres worden gemaskeerd, want die staan al in de webshop en het ERP. Wie bij de log kan, regel je per login.
Kan een afgekeurd bericht vanuit de log opnieuw worden verwerkt?
Ja. Een afgekeurd bericht staat er met de oorspronkelijke inhoud en de reden. Is de oorzaak verholpen, bijvoorbeeld een artikel dat in het ERP is aangemaakt, dan wordt hetzelfde bericht opnieuw aangeboden. De log toont daarna beide pogingen.
Wat is het verschil met de dry run?
De dry run laat vooraf zien wat de koppeling zou veranderen. De audit trail laat achteraf zien wat hij heeft veranderd. Ze gebruiken dezelfde vorm: per record de oude waarde, de nieuwe waarde en de regel.
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