Kijk in de kopie van onze boekhouding welke artikelen een verkoopprijs onder
de kostprijs hebben en zet ze in een lijst met het verschil per stuk. Niets
wijzigen.
Een koppeling met een boekhoudpakket wordt bijna altijd gebouwd voor één taak. Facturen inlezen, of artikelen aanmaken, of omzet ophalen voor een rapport. Dat lukt, de klant is blij, en daarna blijft die koppeling jaren liggen voor dat ene ding.
Dat is zonde. Het werk dat je erin stopt, zit namelijk niet in die ene taak. Het zit in de koppeling zelf: de inlog, het verversen van het token, een kopie van de gegevens in je eigen database en het omgaan met de limieten. Als dat er staat, kost de tweede toepassing een fractie van de eerste.
Wij bouwden zo'n koppeling voor een klant, voor het inlezen van leveranciersfacturen. De klant blijft anoniem en er staan hier geen prijzen of marges. Wat er wel staat, zijn de vier dingen die daarna bovenop dezelfde koppeling konden. Twee ervan draaien, twee staan klaar. Over de valkuilen van het schrijven schreven we eerder in wat de documentatie niet zegt, en over de alleen-lezen kant in je boekhouding bevragen vanuit Claude.
1. Voorraad per magazijn, zonder je limiet op te blazen
Voorraadstanden ophalen klinkt als het soort ding dat je elke paar minuten doet en waarmee je in een dag door je aanroeplimiet heen gaat. Dat hoeft niet, want er is een aparte ingang voor: de sync-variant van de voorraadstanden.
Het verschil is simpel maar belangrijk. Een gewone lijst geeft je alles, elke keer. De sync-variant geeft je alleen wat sinds een door jou meegegeven tijdstempel is gewijzigd. In de praktijk betekent dat meestal één aanroep per kwartier, ook bij duizenden artikelen. Je slaat de laatste stand op, je vraagt de volgende keer vanaf dat punt verder.
Dit is het patroon dat de rest van zo'n koppeling draagbaar maakt. De limiet is zestig aanroepen per minuut en vijfduizend per dag, en de resterende ruimte lees je uit de koppen van elk antwoord. Met gewone lijsten is dat krap. Met alleen de wijzigingen is het ruim.
2. De kassa die het magazijn bijwerkt
Een winkel met een eigen kassa en een eigen magazijn heeft een probleem dat niemand graag met de hand oplost: wat er in de winkel over de toonbank gaat, moet uit het magazijn af.
De kassa levert een weekexport. Die export is geen boekhoudtaal, dus er zit een vertaalstap tussen: per artikel het aantal, en dan één magazijnverplaatsing in de boekhouding. Eén bestand erin, één boeking eruit.
Wat deze toepassing leerzaam maakt, is de foutkant. Een artikel in de kassa-export dat niet in de boekhouding bestaat, mag de hele boeking niet laten mislukken. Wij zetten die regels apart in een lijst die iemand nakijkt. Een koppeling die bij de eerste onbekende artikelcode stopt, wordt na twee weken niet meer gebruikt.
3. Een bestelportaal dat de prijs niet zelf verzint
Zakelijke klanten die willen bestellen zonder te bellen, zijn de duidelijkste reden om een koppeling uit te breiden. Een eigen bestelportaal stuurt een verkooporder naar de boekhouding, en daar gebeurt iets fijns: de klantprijs rekent de boekhouding zelf uit.
Dat is meer waard dan het lijkt. Klantprijzen zitten in prijslijsten met staffels, en elke klant hangt aan zijn eigen lijst. Die logica wil je niet overtypen in je portaal, want dan heb je twee waarheden en loopt er één achter. Laat de boekhouding rekenen en toon in het portaal wat eruit komt.
Voor het tonen van een prijs vóór het bestellen gebruik je de prijslijsten uit je eigen kopie. Dat is het stuk dat je bij de eerste synchronisatie eenmalig ophaalt en daarna alleen bijwerkt waar iets gewijzigd is.
4. Een signaal op prijzen onder de kostprijs
De kleinste van de vier en misschien de nuttigste. Je hebt de verkoopprijzen in je kopie staan, en je hebt de gemiddelde kostprijs per artikel. Het verschil is een getal dat niemand ooit bekijkt.
Zet er een wekelijkse controle op en je ziet welke artikelen onder de kostprijs weggaan. Dat zijn bijna nooit fouten van vandaag. Het zijn prijzen die drie jaar geleden klopten.
Eén waarschuwing hierbij, uit eigen ervaring: de gemiddelde kostprijs in een boekhoudpakket is een berekend getal met aannames erin. Gratis geleverde artikelen bijvoorbeeld vertekenen hem. Gebruik zo'n lijst als vraag aan een mens, niet als conclusie.
Wat dit over de bouwwijze zegt
Alle vier gebruiken dezelfde drie lagen: een kopie van de gegevens in je eigen database, een synchronisatie die alleen wijzigingen ophaalt, en een dunne laag met de logica per toepassing. Alleen die laatste laag is nieuw per toepassing.
En alle vier zijn gebouwd met de assistent erbij, met één harde regel: de koppeling die naar de boekhouding schrijft, draait alleen in productie. De ontwikkelomgeving werkt op een kopie zonder verbinding. Een test bewaakt dat er niets naar de boekhouding geschreven kan worden vanaf een plek waar dat niet hoort. Dat is wat bouwen met een assistent op een boekhouding werkbaar maakt: niet minder snel, wel met een rem die hij niet zelf kan losdraaien.
Veelgemaakte fouten
Alles live uit de boekhouding halen. Het voelt netjes om altijd de bron te bevragen, maar je loopt binnen een dag tegen de limieten aan en je toepassing wordt traag. Werk met een kopie en synchroniseer alleen wijzigingen.
De prijslogica overnemen in je eigen applicatie. Staffels en klantprijzen zijn precies het soort regels dat ergens anders verandert zonder dat jij het hoort. Laat het boekhoudpakket rekenen.
Een koppeling bouwen die bij de eerste fout stopt. Onbekende artikelcodes, afgeronde aantallen en vreemde eenheden zijn geen uitzonderingen, het is de normale toestand. Zet ze apart en ga door.
Schrijfrechten geven omdat het makkelijker is. Een koppeling die alleen leest, kan niets slopen. Splits lezen en schrijven, geef het schrijven zo weinig rechten als het nodig heeft en laat een test bewaken dat de grens blijft staan.
Denken dat dit eenmalig werk is. Een koppeling is een dienst. Een verlopen token, een gewijzigd veld of een nieuwe administratie legt hem stil. Zet er een controle op die je waarschuwt voordat je klant dat doet.