Kasafstemming voor restaurants
Een uur afstemming per exploitatiedag, verdwenen.
Sector : Horeca — Twee Brusselse restaurants
De context
Elke exploitatiedag moeten de kasrapporten worden afgestemd op de boekhoudkundige samenvatting: Z-nummer, omzet inclusief btw, btw-uitsplitsing, en het detail van de betalingen in cash, met kaart en per overschrijving.
Het probleem
Een uur per exploitatiedag om cijfers van het ene document in het andere over te typen. Het voegt niets toe, en het is precies het soort taak waar een verschoven rij onopgemerkt blijft tot de jaarrekening.
Wat er gebouwd is
Twee tools, bewust verschillend, omdat de twee restaurants niet hetzelfde materiaal aanleveren. Het eerste heeft alleen gescande thermische kastickets: de pdf's worden gelezen door een visiemodel, en de opgehaalde bedragen voeden drie werkboeken. Het tweede beschikt over digitale exports: alles wordt in de browser verwerkt, zodat er geen enkel boekhoudkundig gegeven het toestel verlaat.
Wat het verandert
De herinvoer verdwijnt. Cellen die al ingevuld zijn worden nooit overschreven, en verschillen worden gesignaleerd in plaats van stil gecorrigeerd — we schaffen de herinvoer af, niet de waakzaamheid.
Hoe het werkt
De eerste tool is een Flask-toepassing: pdf's omgezet naar beelden van 300 dpi, gelezen door Claude als OCR, resultaten weggeschreven naar de werkboeken met openpyxl. De tweede is een React-toepassing die volledig in de browser draait: XLSX-exports gelezen met exceljs, en chirurgische bewerking van het doelbestand — alleen de beoogde cellen worden in de XML van het blad gewijzigd, zodat formules en opmaak intact blijven.
Wat dit bij u zou kunnen geven
Dezelfde redenering geldt overal waar twee systemen met elkaar zouden moeten praten en dat niet doen: kassa en boekhouding, planning en loon, bestellingen en voorraad. En de les is het onthouden waard: we kiezen de technologie naargelang het materiaal dat u aanlevert. Als uw gegevens al digitaal zijn, is er geen reden om een model te betalen om ze opnieuw te lezen.