Wat is er nieuw?

De app zoekt elk veld op een vaste plaats op het blad — het ticketnummer linksboven, de omschrijving in het midden. Dat werkt zolang de bon recht en volledig op de foto staat. Een foto die een fractie schever of krapper genomen is, schuift alles mee, en dan zoekt de app op de verkeerde plek. Bij één bon liep de inhoud vier tot acht millimeter uit de pas: de omschrijving van de klant kwam leeg terug en er verscheen een verzonnen toestel met de tekst van een opschrift erin. Nu zoekt de app eerst de gedrukte opschriften op — UNIT N°, OMSCHRIJVING KLANT, TECHNICUS RAPPORT, MATERIALEN — en legt de bon daarmee terug op zijn plaats voor ze ook maar één veld leest. Getest met een bon die met opzet scheef ingescand werd: die komt er nu even goed uit als het origineel. Vindt de app te weinig opschriften, of levert het rechttrekken iets onmogelijks op, dan doet ze niets en leest ze zoals vroeger.

Vul je een bon in met een aankomst- en een vertrekuur, dan weet de app hoe lang het bezoek werkelijk duurde. De weekplanning gebruikte dat al: daar werd de bon uitgerekt tot zijn echte tijd. De dagplanning niet — die bleef de geraamde duur tonen en helemaal geen uur, zodat dezelfde bon in de week op 11:00 stond en in de dag nergens. Nu gebruiken allebei hetzelfde. Ook het dagtotaal telt voortaan wat er echt gewerkt is: een dag die uitliep, laat dat zien in plaats van netjes op de raming te blijven staan.

De volgorde van de dag werd bepaald door het berekende startuur van elke bon. Een bon waar nog geen uur van bekend was, rekende de app zo vroeg mogelijk in, en daardoor kwam die automatisch vooraan te staan en schoof alles erachter op — ook bonnen waar wél een uur van bekend was. Eén bon van 08:45 belandde zo op 10:58. Nu bepalen de uren het skelet van de dag: bonnen met een uur staan op volgorde van dat uur, en een bon zonder uur zoekt de eerste plaats waar hij niets verschuift. Past hij nog vóór je eerste afspraak, dan gaat hij daar — want wachten is geen planning. Past hij nergens tussen, dan komt hij achteraan.

Tot nu toe gaf de app zonder verbinding de foutpagina van de browser — op elke pagina, ook de dagplanning. Dat stond al die tijd anders in de documentatie, maar het klopte niet: het hulpje dat pagina's moet bewaren deed uitsluitend meldingen, en werd bovendien pas aangezet als je meldingen inschakelde. Wie dat nooit deed, had het helemaal niet. Nu wordt het meteen bij het opstarten aangemeld en bewaart het de dagplanning, de weekplanning en alles wat ze nodig hebben. In een kelder of een machinekamer opent de app dus gewoon, met de planning zoals ze het laatst opgehaald werd, en kun je blijven wisselen tussen dag en week. Werkbonnen invullen werkte al offline; dat verandert niet — wat je invult blijft in de wachtrij tot er weer bereik is.

Bewaarde pagina's hebben één berucht gebrek: ze kunnen blijven hangen, en dan zit een technieker met een oude app die je van op afstand niet meer gerepareerd krijgt. Daarom haalt de app elke pagina eerst bij de server en pas uit het geheugen als dat niet lukt. Zodra er bereik is wint de nieuwste versie dus altijd, binnen één herlading. Gegevens worden nooit bewaard op deze manier — die komen uit het geheugen van het toestel zelf, zodat er nooit twee antwoorden op dezelfde vraag kunnen bestaan.

De app verwees naar een instellingenbestand dat niet bestond, dus gaf de telefoon een foutmelding en bood hij nooit aan om Bossuyt Service op het startscherm te zetten. Dat bestand is er nu: de app opent vanaf het startscherm in volledig scherm, zonder adresbalk, met het juiste icoon en de juiste kleur.

De app onthoudt het uur waarop je een bon neerzet. Dat uur werd behandeld als een afspraak, ook als er nooit iemand voor gebeld was. Zette je de bon ervóór op een vast uur, dan bleef de volgende koppig op zijn oude uur staan: twee blokken over elkaar, de rit ernaartoe dwars door het blok van de vorige klant, en een rode arcering met "kan niet" over de hele kolom. Op woensdag zag dat eruit als een puinhoop, en dat was het ook. Nu geldt het onderscheid dat het speldje altijd al bedoelde: een afgesproken uur houdt zijn plaats, ook als het niet haalbaar is — dan hoort er juist een waarschuwing te staan, want iemand moet de klant bellen. Een uur zonder afspraak is een voorkeur en schuift op naar het eerste moment waarop je er echt kunt zijn. De dag eindigt daardoor soms later dan vroeger, maar dat is de tijd die de rit werkelijk kost.

Wisselde je van de weekplanning naar de dagplanning, dan kwam je op maandag uit — ook op een dinsdag. De weekweergave gaf altijd de eerste dag van de getoonde week mee in plaats van de dag waar je naar keek. Die maandag bleef vervolgens plakken, want hij reist mee in de adresbalk. Nu reist vandaag mee zolang vandaag in de getoonde week zit; kijk je naar een andere week, dan blijft de maandag het logische startpunt.

De weekplanning haalde elke dag rechtstreeks bij de server op en had verder geen geheugen. Viel het bereik weg — een kelder, een machinekamer — dan stonden er zeven lege kolommen, zonder één woord uitleg, alsof de week leeg gepland was. Ze leest nu eerst uit het geheugen van je toestel en gaat daarna pas naar de server. Lukt dat niet, dan blijft staan wat er stond en zegt een melding dat het de laatst opgehaalde versie is.

Bij elke synchronisatie van vandaag werd het hele geheugen leeggeveegd voordat de nieuwe bonnen erin gingen. Dat kon toen er één dag in zat, maar de weekplanning bewaart er zeven — en die werden dus telkens weggegooid. Wie zijn week opende nadat de dagplanning net gesynchroniseerd had, kreeg zes lege kolommen. Er wordt nu alleen nog vervangen waar de synchronisatie echt over gaat: die ene dag en de open pool.

Wie na twaalven 's nachts de planning opende, kreeg de vorige dag te zien — en die stond leeg, want de bonnen van vandaag hoorden bij de nieuwe dag. Verversen hielp niet. Er zaten drie oorzaken onder, alle drie dezelfde: de app rekende met de klok van de server in plaats van die van België, en die loopt 's zomers twee uur achter. Tussen middernacht en twee uur stond de ene dus nog op gisteren terwijl de andere al op vandaag stond. Daarbovenop bleef de datum uit de adresbalk — die er staat om je plaats te bewaren als je tussen dag en week wisselt — voor altijd staan, dus las elke verversing hem opnieuw. Hij wordt nu één keer gebruikt en dan opgeruimd. Ook een bon die je na middernacht invulde, kreeg de bezoekdatum van gisteren; ook dat is recht.

De teller onder je avatar rekende hoe lang het geleden was dat het ingestelde startuur voorbij was, en verder niets. Wie 's avonds om elf uur nog eens keek, las dat hij zestien uur gewerkt had; een minuut na middernacht stond er zeventien. Nu er een echte start- en eindtijd is, telt hij wat daartussen ligt, met de onbetaalde pauze eraf — want het rooster waar hij tegen afgezet wordt, heeft die er ook al af. Ben je nog niet vertrokken, dan staat er "--u--": nul zou suggereren dat er gemeten is. Tijdens de dag komt de pauze er pas af zodra de middag voorbij is, want daarvoor heb je ze nog niet genomen.

De vaste balk onderaan houdt pool en dag samen bereikbaar tijdens het slepen, en daar blijft ze dan ook — in de weekplanning. Op de dagplanning hoort de pool gewoon onderaan de lijst te staan, als deel van de dag die je afloopt. Ze staat er weer.

In de START-regel van de dagplanning staat een groen play-knopje met het geplande vertrekuur erachter, en onderaan bij EINDE een rood stopknopje. Tik erop wanneer je vertrekt en wanneer je thuis bent. Het uur wordt zwart zodra het het échte is, en de rest van de dag schuift mee: vertrek je om 07:12 in plaats van 07:00, dan staat de eerste klant ook twaalf minuten later. Een bon met een vastgezet uur blijft staan waar hij staat — dat uur is met de klant afgesproken. Vergeten te tikken kan altijd rechtgezet worden: tik op het uur en zet het met "Nu", met stapjes van een kwartier, of tik het gewoon in. Zonder bereik blijft de tik in de wachtrij staan en vertrekt hij zodra er weer verbinding is — het uur dat bewaard wordt is dat van het moment waarop je tikte, niet van het moment waarop de wachtrij leegliep.

Sinds v1.67 keert een vergeten werkbon om middernacht terug naar de pool. Die opkuis keek alleen naar de status, en een bon blijft "gepland" zolang je hem niet indient — ook al ben je er geweest. Wie zijn aankomst- en vertrekuur al ingevuld had maar de bon nog niet afgerond, zag hem dus 's nachts naar de pool verhuizen. Voortaan blijft een bon staan zodra er een uur op ingevuld is, of dat nu op de ingediende bon staat of nog in het half ingevulde scherm. Eén uur is genoeg: wie een aankomstuur heeft, is vertrokken.

Een afgewerkte bon stond op de weekplanning nog altijd op zijn geraamde duur. Een job van anderhalf uur die er drie geduurd heeft, zag er dan uit als anderhalf uur, en zo klopte het beeld van de week niet met wat er gebeurd was. Nu staat een afgewerkte bon van zijn aankomstuur tot zijn vertrekuur, op de plaats waar hij werkelijk viel. Zolang de bon nog loopt, of er maar één uur op staat, blijft de raming staan — een half ingevuld bezoek mag geen verzonnen duur op de week zetten.

De bon van Trianon noemt drie toestellen. De app las ze alle drie uit en toonde ze ook op het scherm, maar op de afgewerkte PDF verscheen er één — de toestelband had maar plaats voor één regel. Wie die bon later terugleest, miste dan twee toestellen die de technieker wel degelijk gezien heeft. Er passen er nu vier in de band; bij meer staat er "+2 meer" achter de laatste, zodat er niets stil wegvalt.

Deze keuze stond los van de bezoekdatum, en die twee konden elkaar dus tegenspreken. Wie een bon een dag eerder opende, kreeg de datum van toen te zien — en de knop stond dan op wat bij díé dag hoorde. Vandaar de indruk dat hij "altijd op weekend" stond. Nu volgt de keuze altijd de bezoekdatum. Zet je hem zelf om, voor een feestdag of nachtwerk, dan blijft die keuze staan tot je de bezoekdatum verandert — want dan gaat het over een andere dag.

Naast aankomst- en vertrekuur stonden er ook "werk start" en "werk einde". Die zeggen hetzelfde: je begint te werken wanneer je aankomt en je stopt wanneer je vertrekt. Ze stonden ook niet op het papier — de gedrukte bon kent alleen AANKOMSTUUR en VERTREKUUR. Vier velden invullen voor twee gegevens is werk zonder opbrengst, dus ze zijn weg.

Een bon die je op een vast uur zette, bleef staan waar hij stond — het uur veranderde wel, de plaats niet. Zo kon een bon van 14:00 bovenaan staan met een bon van 08:30 eronder en de pauze ertussen. De volgorde en het uur waren twee losse gegevens die elkaar nooit tegenkwamen. Voortaan bepaalt het uur de plaats: wie een uur heeft staat waar dat uur valt, en wie er geen heeft schuift eromheen met zijn onderlinge volgorde intact. Sleep je een bon vóór een vastgezette, dan komt hij daar alleen als het qua uur kan. Week en dag rekenen het uit met dezelfde functie, dus ze kunnen niet meer uit elkaar lopen.

De pauze werd altijd in het midden van de lijst gezet, en verschoof dus zodra er een bon bij kwam of wegging. Een middagpauze hoort niet op de helft van een rij maar rond de middag: ze valt nu op de eerste grens tussen twee bonnen die op of na twaalf uur ligt. Een bon onderbreken gebeurt niet. En loopt een dag vroeger leeg, dan telt de pauze toch mee — je bent pas thuis na de pauze en de rit, en daar hangt de overurenberekening aan.

De pool stond onder de tijdlijn, aan het eind van een pagina van vijftienhonderd pixels. Sinds het venster tijdens het slepen stilstaat, kon je er met een blok in je hand niet meer naartoe: nagemeten stond de eerste bon van de dag dan tweeënvijftig pixels bóven de bovenrand. Je mikte dus niet, de app koos de dichtstbijzijnde kaart. Dezelfde balk als in de weekplanning zit nu vastgeplakt onderaan, zodat pool en dag altijd samen bereikbaar zijn. Het is één en dezelfde balk in beide weergaven, zodat ze niet uit elkaar kunnen groeien.

Sleep een bon en klik meteen door naar de volgende dag, en dezelfde wijziging vertrok twee keer: de sleep maakte de wachtrij leeg, en de dagwissel deed dat ook, allebei vóór de ander klaar was. De tweede kreeg dan een conflict van de eerste, en op het scherm verscheen een weigering voor iets wat gewoon gelukt was. De wachtrij vertrekt nu één voor één. Ook de eerste sleep na het openklappen van de pool deed soms niets: de sleepmotor onthield waar de doelwitten stonden vóór de balk openschoof. Die meet nu tijdens het slepen mee.

Kwam een bon binnen met een leeg naamvak of een fout adres, dan stond dat er en bleef dat er. Het potloodje in de kop van de werkbon opent nu een scherm waar je die gegevens verbetert. De velden staan gegroepeerd naar wat een wijziging raakt, want niet alles op een bon hoort bij díé bon: het ticketnummer wel, maar de naam, het adres en het telefoonnummer deelt hij met elke andere bon van hetzelfde huis. Een merkje zegt daarom vooraf hoe ver je wijziging reikt — "alleen deze bon", of "geldt voor 4 bonnen". Aan een bon waaraan al gewerkt wordt, verandert niemand nog iets.

Naast "SERVICE BON" staan voortaan kleine knopjes: de bon zoals hij binnenkwam (een PDF-symbool of een fotosymbool, naargelang wat er geüpload werd), de afgewerkte bon zodra die getekend is, en het potloodje om de gegevens recht te zetten. Wie twijfelt aan wat de app uitgelezen heeft, legt het papier er zo in twee tikken naast. Is er geen origineel, dan staat er ook geen knopje — een knop die niets opent is erger dan geen knop.

Staan er meerdere toestellen op één servicebon, dan las de app ze wel alle drie uit maar toonde ze er één. Nu staat er een rijtje met alle toestellen van de bon; het toestel waarover het verslag gaat, is aangeduid. Bij één toestel verandert er niets aan het scherm.

Een bon die via de upload binnenkwam had nog geen technieker. Gaf je hem dan een dag, dan verdween hij uit élke weergave: niet meer in de pool want hij had een datum, en op niemands dag want er stond niemand bij. Vastgesteld op een echte bon die nergens meer te vinden was. Wie een bon aanmaakt, draagt hem nu — en een bon die je op een dag zet krijgt sowieso een technieker.

Koos je een foto in plaats van een PDF, dan verscheen er een technische fout ("The source width is 0") en kwam je niet verder. De app gaf het geheugen van de afbeelding vrij vlak vóór ze de afmetingen nodig had, en las daarna nul bij nul pixels uit. Foto uploaden werkt weer.

Bij het aanduiden van de hoeken lag er standaard een kader dat acht procent naar binnen sprong. Wie zijn foto op de gsm al rechtzet en bijsnijdt, kreeg zo net de randen van de bon afgesneden en moest vier hoeken terugslepen. Het kader begint nu op de hoeken van de foto zelf; versleep ze alleen nog als het nodig is.

Op een papieren servicebon blijft het naamvak soms leeg. De app hield zo een bon tegen om iets wat er gewoon niet op stond. De naam is niet langer verplicht — het rode merkje "niet gevonden" naast het veld zegt al dat hij ontbreekt, en je kan hem zelf invullen als je hem kent. Adres en gemeente blijven wél nodig: zonder die twee kan niemand ergens naartoe rijden. In de planning staat bij zo een bon "Naam ontbreekt", zodat een leeg blok nooit als een fout in de app gelezen wordt.

Een bon naar maandag verplaatsen of er een uur op zetten lukte niet: hij sprong een week terug. De app koos het doelwit op basis van middelpunten, en omdat de zijbalken over de volle hoogte lopen ligt hun midden dertig pixels hoger dan dat van een dagkolom. Bij een blok bovenaan het rooster woog dat verschil zwaarder dan de afstand opzij, en won de balk van maandag terwijl je vinger op maandag stond. Nu beslist je vinger: een zijbalk telt alleen mee als je er werkelijk op staat.

Stond een bon op een dag die voorbij is en is er nooit aan gewerkt, dan was hij onvindbaar: de dagplanning toont vandaag, de weekplanning toont de week waar je in kijkt, en de pool toont alleen bonnen zonder dag. Zo raakte werk stil zoek. Nu zet de app zulke bonnen terug in de pool, telkens iemand de planning opent. Onderweg telt daarbij als niet-gedaan — wie gisteren vertrok maar geen afgewerkte bon heeft, heeft hem niet gedaan. Een afgewerkte, geannuleerde of op onderdelen wachtende bon blijft staan waar hij staat.

Een datum van gisteren is nooit een plan — het is een tikfout of een verkeerd gemikte sleep. Slepen naar een voorbije dag, een week terugschuiven naar een week die al om is, en het datumveld op de werkbon weigeren dat nu alle drie, met uitleg erbij. Ook de server weigert het, want de wachtrij van een telefoon die een nacht offline stond komt binnen met de datum van toen. Vandaag blijft wél toegestaan, ook als het al namiddag is. En naar de pool slepen kan altijd: dat is juist de uitweg.

Sinds het venster tijdens het slepen stilstaat, kon je de pool niet meer bereiken: die stond bovenaan de pagina en je kon er niet meer naartoe scrollen met een blok in je hand. De pool zit nu in een balkje dat onderaan het scherm blijft plakken, altijd in beeld. Tijdens het slepen licht het op en zegt het wat er gebeurt als je loslaat. Tik erop en het schuift open met de wachtende bonnen erin, die je van daaruit weer op een dag legt.

Aan de linker- en rechterkant van het weekrooster verschijnen tijdens het slepen twee smalle doorschijnende stroken. Je leest de uurkolom er gewoon doorheen, want je mikt op een uur en niet alleen op een dag; zodra een strook het doelwit is kleurt hij vol oranje. Laat je een bon erop los, dan springt hij een week terug of vooruit, naar dezelfde weekdag. Buiten het slepen zijn ze onzichtbaar, zodat ze geen plaats innemen op een telefoon.

Bovenaan een werkbon staat voortaan een datumveld, een uurveld en een vinkje om het uur vast te zetten — samen op één regel, zodat het vak klein blijft. Zo verplaats je een bon naar eender welke dag zonder hem te slepen, ook buiten de week die je op het rooster ziet. Botst het uur met de rest van die dag, dan lees je daar dezelfde melding als op het rooster: de app rekent de doeldag door met dezelfde motor, zodat de twee schermen nooit iets anders kunnen beweren. Een gestarte of afgewerkte bon toont dezelfde regel, maar uitgeschakeld, met de reden erbij: dag en uur liggen dan vast.

Je sleepte een bon naar de pool, op het scherm stond hij daar ook, maar in de database bleef hij op zijn dag staan. Bij het vrijgeven stuurde de app het volgnummer van de bonnen die bleven, terwijl de server kijkt naar het hoogste van de hele dag — inclusief de bon die net vertrok. Dat verschil viel nooit op zolang een hele dag altijd in een keer werd weggeschreven. Nu een enkele bon zijn eigen nummer kan ophogen, werd het meteen raak. De app stuurt nu het nummer van de dag zoals de server hem nog kent.

Sleepte je een werkbon naar een andere dag, dan schoven de andere bonnen van zijn oude dag mee alsof er iets veranderde — terwijl die bon daar net aan het vertrekken was. Zodra je begint te slepen klikt het uur namelijk in op het kwartier, en dat telde meteen als een vast uur op die dag. De app kijkt nu waar je vinger uitkomt: blijf je boven je eigen dag, dan rekent die mee; ga je naar een andere kolom of naar de pool, dan blijft de oude dag staan zoals hij stond.

Een melding begon met een uur — "Vertrek om 06:23" — terwijl ze over een andere dag in dezelfde week kon gaan. Zette je dan een bon vast en begon jouw dag juist later, dan leek de app te beweren dat je vroeger moest vertrekken. Elke melding begint nu met de dag in het vet, noemt de klant om wie het gaat, en zet het vertrekuur naast het ingestelde startuur zodat je het verschil ziet.

Tijdens het verschuiven van een bon kon de pagina plots opschuiven onder je vinger, precies terwijl je aan het mikken was. Twee oorzaken: de app scrollde mee om het blok onder je vinger te houden terwijl de dag zelf al meebewoog, en een botsingsmelding die tijdens het slepen verscheen duwde het hele rooster naar beneden. Het venster staat nu stil zolang je vasthoudt; de rode arcering op het rooster verschijnt wél gewoon mee, want die verandert de indeling niet. Zijwaarts vegen naar een dag buiten beeld blijft werken.

Stond je in de dagplanning op dinsdag en koos je de weekplanning, dan kreeg je toch de week van vandaag te zien. Nu opent de week op de dag waar je stond, en omgekeerd opent de dagplanning op de week die je bekeek.

Zet je in de weekplanning een uur vast als afspraak met de klant, dan zag je dat in de dagplanning nergens terug — daar stond hetzelfde oranje uurtje als bij een berekend uur. Nu staat een afgesproken uur in het rood naast de klantnaam, met dezelfde betekenis als in de week: hier is iets beloofd.

Verschuif een bon en de hele dag beweegt mee onder je vinger: de rijtijden verspringen, de vertrektijd schuift op, de volgorde herschikt zich, en botst het ergens dan verschijnt de rode arcering meteen. Tot nu toe zag je pas na het loslaten wat je gedaan had — je sleepte dus eigenlijk blind. Wat op het scherm staat terwijl je vasthoudt, is nu precies wat er bewaard wordt als je loslaat.

Stond er rode arcering over een werkbon, dan gebeurde er niets als je hem probeerde te verplaatsen: hij sprong terug alsof je niets gedaan had. Juist die bon is degene die de melding je vraagt te verzetten. De arcering droeg intern dezelfde naam als de bon eronder, waardoor het slepen aan het verkeerde ding vasthing. Zat er sinds v1.61 in.

Onderaan elk blok in de weekweergave zit een handvat. Sleep het naar beneden en de job duurt langer, naar boven en hij duurt korter — op het kwartier, en alles wat erachter komt schuift meteen mee. Het is dezelfde geschatte duur die je ook op de kaart kunt intypen, dus er staat niets dubbel: dit is een tweede manier om er aan te komen, met je vinger in plaats van met een getal.

Het speldje was een aparte knop naast het uur, en daardoor bleef er van een kolom van 62 px te weinig over: "08:39" liep over het speldje heen. Het uur is nu zélf de knop. Tik op het groene bolletje en het wordt rood — dit uur is afgesproken met de klant. Het kruisje rechtsboven haalt een uur weer weg, zodat het weer berekend wordt.

Stond een job op 08:39 en markeerde je hem als afspraak, dan sprong hij naar 08:45. Slepen klikt in op het kwartier omdat dat helpt mikken, maar markeren is iets anders: je zegt dat het uur dat er staat afgesproken is. Dan hoort er niets te verschuiven.

De rode arcering over een onmogelijk stuk droeg haar uitleg alleen in een tooltip, en op een telefoon bestaat die niet. Nu staat het er gewoon op.

Sleep een werkbon in de weekweergave omhoog of omlaag en hij staat op dat uur — op het kwartier. Vanaf dat uur wordt de rest teruggerekend: hoe laat je moet vertrekken, en hoeveel rijden er tussen de klanten zit die daardoor naast elkaar komen te staan. Tot nu toe berekende de app elk uur zelf; dit is het eerste uur dat ze onthoudt.

Het uurtje links op elk blok is groen zolang het berekend wordt, en rood zodra het vastligt. Met het speldje zeg je dat dat uur met de klant afgesproken is. Dat verandert niets aan hoe de bon zich laat verslepen — dat blijft even vrij — het is een bericht aan wie de planning leest: een groen uur mag je verzetten als het beter uitkomt, een rood uur heeft iemand beloofd. Het kruisje rechtsonder haalt een uur weer weg.

Zet je een bon op een uur waarop je er onmogelijk kunt zijn, dan komt er rode arcering over precies dat stuk en blijft die staan. De app schuift niets vanzelf op: dat is geprobeerd en het maakte vrij plaatsen onmogelijk — elke bon werd naar de vorige toe gezogen en gleed weg onder je vinger. De melding noemt de drie uitwegen: de vorige job inkorten, deze later zetten, of het vaste uur weghalen.

Sleep je een bon naar een andere dag of terug naar de pool, dan laat hij zijn uur los en wordt het weer berekend. Negen uur op dinsdag is niet negen uur op woensdag: de rit ernaartoe vertrekt van een andere plaats in een andere dag.

Zeven dagen naast elkaar, van 06:30 tot 18:00, met de werkbonnen getekend op schaal van hun duur — zoals in een agenda. De open pool staat eronder, en je sleept een bon van de pool naar een dag, van een dag terug naar de pool, of van de ene dag naar de andere. Te vinden via "Week" in de datumbalk.

De dagweergave toont nu bij elke werkbon hoe laat je er bent. Dat uur wordt berekend en nergens bewaard: het ingestelde vertrekuur plus de rijtijd is de aankomst, en zo verder van job naar job. Loopt iets uit, dan schuift de rest vanzelf mee, en een bon naar de pool slepen laat zijn uur gewoon verdwijnen. Dag en week rekenen met dezelfde motor, dus ze kunnen nooit een ander uur tonen.

Stond er niets ingepland, dan vulde de app de dag met verzonnen werkbonnen. Dat was ooit bedoeld als demo, maar met twee weergaven werd het een echte fout: de laatste bon van een dag slepen maakte die dag leeg, waarna hij zich meteen weer vulde met verzinsels — je wijziging leek terug te springen. In de weekweergave stonden lege dagen vol met bonnen die niet bestaan.

Een bon van de ene dag naar de andere slepen is niet één wijziging maar twee: de oude dag geeft hem vrij, de nieuwe neemt hem op. Die twee overschreven elkaar in de wachtrij, waardoor de server alleen over de nieuwe dag te horen kreeg. Ze blijven nu allebei bewaard en vertrekken in de juiste volgorde.

De planning van vandaag werd uit een cache gelezen die niet op datum keek. Een bon die je in de weekweergave op donderdag zette, kon daardoor in de planning van vandaag opduiken — en zonder netwerk bleef hij daar staan.

De rijtijden waren verzonnen. Ze werden berekend uit de nummers van de twee werkbonnen, niet uit hun adressen — vandaar dat twee jobs bij dezelfde klant toch tien tot veertig minuten rijden kregen. Nu wordt de echte afstand tussen de twee adressen gemeten, met een snelheid die meeschaalt: traag door de bebouwde kom, vlot over de snelweg. Twee bonnen op hetzelfde adres geven voortaan nul minuten, zoals het hoort.

Bij elke verschuiving werden de rijtijden opnieuw opgevraagd. Dat was niet alleen traag, het verbruikte ook de dagelijkse limiet van de routedienst — die halverwege de dag op kon zijn. De rijtijden worden nu een week onthouden, en in één keer voor alle combinaties van je stops. Je kan dus zoveel schuiven als je wil zonder dat er iets herladen wordt.

Ontbreekt het adres van een werkbon, dan staat er "? min · adres ontbreekt" in plaats van een getal. Onderaan de dag zie je hoeveel ritten er zo onbekend zijn. Dat is eerlijker dan een dagtotaal dat stiekem te laag uitvalt, en het wijst je meteen aan welke bon een adres mist.

De rit tussen het atelier in Kuurne en thuis in Kontich begint en eindigt bijna elke dag. Een berekening kwam daar op 1u41 uit; in het echt is het 1u30. Die is nu vastgelegd op de gekende waarde, zodat je dag niet twee keer per dag tien minuten te lang lijkt.

De knop op de werkbon had een algemeen navigatiepijltje. Nu staat het echte Waze-logo er, in de eigen kleur, zodat je in één oogopslag ziet wat de knop doet.

Een job uit de open pool kan je nu in je dagplanning slepen, en een job uit je planning terug naar de pool als de dag niet meer volstaat. Terugleggen maakt de toewijzing niet ongedaan — de bon blijft van jou, hij heeft alleen geen dag meer. Slepen werkt ook zonder bereik: alles gaat eerst naar het toestel en vertrekt zodra je weer online bent, hoe vaak je ondertussen ook geschoven hebt.

Werk en rijtijd worden opgeteld en vergeleken met je uurrooster: 8u30 van maandag tot donderdag, 6u00 op vrijdag, telkens met een halfuur onbetaalde pauze eraf. Loopt de dag over, dan verschijnt er een rode regel met hoeveel te veel. Ze houdt je niet tegen — soms moet een dag gewoon vol — ze zorgt er alleen voor dat het niet per ongeluk gebeurt. Zolang de rijtijden nog berekend worden staat er "ongeveer", want dan is het een schatting en geen zekerheid.

De duurtijd op een werkbon stond vast vanaf het aanmaken. Nu tik je erop en vul je zelf in hoelang je denkt bezig te zijn. Leeg laten mag ook. Dat is nodig geworden nu de planning waarschuwt dat je dag overloopt: een getal waar je op afgerekend wordt, moet je ook kunnen rechtzetten.

Startlocatie en startuur sprongen soms terug naar de standaardwaarde. De oorzaak lag niet bij het bewaren zelf maar bij wat er gebeurde als het één keer mislukte: dan werden álle instellingen gewist in plaats van alleen de mislukte wijziging. Op een toestel waarvan de opslag volloopt met bonfoto's gebeurt dat vroeg of laat. Een mislukte poging verliest nu hoogstens die ene wijziging.

Het urenoverzicht in je instellingen rekende met 7u45 per dag, elke dag. Dat klopte met geen enkele dag: het zijn er 8u30 van maandag tot donderdag en 6u00 op vrijdag. Op vrijdagmiddag beweerde het dus dat je nog bijna twee uur voor de boeg had terwijl je klaar was. Het leest nu hetzelfde rooster als de planning.

Een werkbon moest tot nu toe altijd een geplande datum hebben, ook als er nog geen dag voor gekozen was. Een ingescande bon kreeg daarom de datum van vandaag opgeplakt — een dag die niemand gekozen had. Geen datum is nu een geldig antwoord, en het is precies wat een bon in de open pool houdt.

Een werkbon had geen geschatte duur, en de dagplanning telt die duurtijden op. Een bon zonder schatting telde dus voor niets mee: zet er vijf in een dag en de planning beweert dat je dag leeg is. Nieuwe werkbonnen krijgen nu standaard 1u30 — niet juist voor elke job, maar zichtbaar op de planning in plaats van onzichtbaar. Bestaande werkbonnen houden hun lege schatting.

In v1.56 werden klantnummer, naam, adres en gemeente verplicht gemaakt. Dat is teruggedraaid: een bon die maar half leesbaar is, moet je toch kwijt kunnen. De knop blijft gedempt zolang er iets ontbreekt, zodat je het ziet, maar hij houdt je niet meer tegen. Elk veld blijft altijd zelf aanpasbaar.

Bovenaan de werkbon staat nu "Originele bon bekijken". Elk veld eronder is een lezing van dat blad, dus als een straat of een naam verkeerd staat, is dat de plek waar het antwoord staat.

Eén knop op de werkbon opent Waze. Er wordt gezocht op de naam van de locatie mét het adres erbij, en de coördinaten gaan mee als vangnet. Kent Waze het bedrijf, dan land je aan de ingang die het bedrijf gebruikt; kent hij het niet, dan blijft de kaartspeld over. Is er niets om op te varen, dan verschijnt de knop niet.

Op bonnen waar boven het adres al een gemeente stond, hield de lezer daar op en bleef de straat leeg — "Prins Boudewijnlaan 20" ontbrak terwijl ze op de bon stond. Er wordt nu doorgelezen tot de straat gevonden is.

Na het toevoegen sprong de app naar de open pool, maar de bon stond er niet. De app bewaarde de daggegevens vijf minuten en toonde die oude lijst. Na het toevoegen wordt ze nu ververst.

Koos je "pdf opladen", dan vroeg de telefoon alsnog camera óf foto. Er zijn nu drie aparte knoppen — foto maken, foto kiezen, pdf kiezen — die elk meteen het juiste scherm van je toestel openen.

Weigerde de server de bon, dan bleef die uitleg soms bij een veld hangen dat je niet in beeld had, en leek de knop simpelweg niets te doen. Alle meldingen verschijnen nu bij de knop waar je op duwt.

Op bonnen waar het adres bóven zijn eigen opschrift staat, bleef het veld leeg en kwam de straat in het contactvak terecht. Dat is rechtgezet — en de gemeente wordt nu ook herkend als de bon zowel de straat als de plaats in hoofdletters drukt.

Klikken op "Zet in de open pool" met een leeg verplicht veld deed niets, zonder uit te leggen waarom. Klantnummer, naam, adres en gemeente zeggen nu zelf dat ze ingevuld moeten worden, zoals ticketnummer en omschrijving dat al deden.

De scan las "NAPELSTRAAT" waar "Napelsstraat" stond — een straat die niet bestaat en die geen kaart terugvindt. De straat wordt nu opgezocht bij de postcode die op de bon staat, en enkel overgenomen als die postcode klopt. Een aangepaste straat krijgt het label "aangepast", zodat je ze altijd zelf kan nakijken.

Kon de scan de naam niet lezen, dan wordt gekeken welk bedrijf op dat adres gekend is. Straat, huisnummer én postcode moeten alle drie kloppen voor er iets wordt voorgesteld — de buurman invullen is erger dan het veld leeg laten. Zo'n naam krijgt het label "voorstel": ze stond niet op de bon.

De coördinaten van een locatie werden pas opgezocht wanneer je een dagroute berekende. Dat gebeurt nu bij het aanmaken, één keer in plaats van telkens opnieuw. Lukt het niet, dan verandert er niets: de route zoekt ze alsnog op.

Je belandde op de werkbon die je net zelf had ingevuld en moest terug om te zien of ze goed aangekomen was. Nu spring je meteen naar de open pool.

Het letterje van de kolom plakte aan het klantnummer wanneer de spatie wegviel: "L 6950" werd "L6950", een klant die niet bestaat. En de leverdatum uit het vakje ernaast belandde achter de toestelomschrijving. Beide zijn opgelost.

Open je een bon, dan sta jij er al in. Daarnaast kan je collega's aantikken die meegewerkt hebben — ook wie niet vooraf toegewezen was, want wie meegaat om een friteuse te lichten moet je kunnen noteren zonder eerst de planning aan te passen. Alle namen komen op de TECHNICUS-regel van de PDF en het aantal personen volgt vanzelf.

Bij het aanmaken van een werkbon kan je een melding meegeven, zoals "klant eerst bellen op 0477/93 15 70" of "kan enkel op voormiddag". Ze verschijnt als een rood uitroepteken in de lijst — tik erop voor de tekst — en staat bovenaan de werkbon, als eerste wat je ziet. Ze komt bewust niet op de PDF: dat is het document dat de klant tekent.

Wie de melding schreef ziet de knoppen om ze aan te passen of te verwijderen; iemand anders leest ze alleen. De server controleert dat ook zelf, niet enkel de knop.

Een werkbon die op papier of als PDF binnenkomt kan nu geüpload worden via de cameraknop in de dagweergave. Bij een foto zet je de vier hoeken van het blad; de bon wordt rechtgetrokken en uitgelezen. Je krijgt de velden naast de bon te zien en corrigeert ze voor de werkorder in de open pool komt. Uitlezen gebeurt op onze eigen server — er gaat geen klantgegeven naar een externe dienst.

Een veld dat uit zijn eigen vak van de bon komt is stil; een veld dat elders teruggevonden is krijgt "nakijken" en een veld dat nergens stond "niet gevonden". OCR verwisselt een 0 en een O zonder te twijfelen, en juist bij een klantnummer als K04647 is dat stil en duur.

Nu er papieren bonnen bij komen, vulde de pool sneller dan hij getoond werd en kon een nieuwe bon onzichtbaar blijven achter oudere. Tijdelijk verhoogd tot tien, tot kantoor de volledige pool kan zien en zelf kan bepalen welke werkorders een technieker te zien krijgt.

Verstuurt de telefoon dezelfde upload twee keer, of tik je twee keer op bevestigen, dan komt er één werkorder. Zonder verbinding blijft de bon lokaal bewaard tot je weer online bent, en een bestaand ticketnummer verwijst naar de bestaande werkbon.

Zestien van de zeventien klanten hebben nog geen klantnummer. De wizard stuurde dan het interne id als nummer, de server vond niets en maakte een tweede kopie van dezelfde klant. Een bestaande klant, locatie of toestel wordt nu op id gekozen, en enkel een echt nieuwe wordt aangemaakt.

Drie problemen met het lokale concept: typen tijdens het laden werd overschreven, het concept kwam terug na het afsluiten van de bon, en een onaangeraakt formulier bewaarde zichzelf al. Wat de technieker typt wint nu altijd.

Werd een klant- of locatieveld geweigerd, dan verscheen er niets en werd de knop gewoon opnieuw actief. Elke foutmelding is nu zichtbaar, en "Ticket bestaat al" is nu een echte link naar de bestaande werkbon.

Na het afsluiten bleef de knop actief; een tweede tik maakte stil een tweede bon (-02).

Enkel de eerste regel werd afgedrukt, op precies de lijst die de klant tekent. Lange omschrijvingen lopen nu door binnen de rij, de vervolgpagina heeft kolomtitels, en "dringend" blijft staan.

De doorlopende kaderlijnen links en rechts ontbraken, het blok met materialen en bezoekgegevens stond ongeveer 20 mm te laag, het technicus-rapport had vijf lijnen in plaats van drie, en de lijn onderaan stond onder de bankgegevens in plaats van erboven. Opgemeten op de ingescande bon en gecorrigeerd.

CONTACT en Tel & GSM staan nu met het label boven de waarde, net als de rest van het klantenblok en net als op papier.

De werkbon volgt nu de papieren Service Bon: ticket- en bonnummer, klantnummer L/F, contact, sluitingsdag, unit/leverdatum/garantie, technicus rapport, materialen, bezoekdatum, aankomst- en vertrekuur, week/weekend, aantal ritten en personen, opmerkingen en handtekening.

De wizard onder "+" op het dagoverzicht zoekt echte klanten, locaties en toestellen, laat nieuwe aanmaken en sluit af met een ticketstap. Een toestel is niet meer verplicht bij aanmaak — de technieker kiest het ter plaatse.

POST /api/erp/work-orders neemt een ticket aan in Service Bon-formaat. Het bestaande GET-export geeft nu ook ticketnummer en alle bonvelden terug.

De gegenereerde PDF heeft dezelfde indeling, tweetalige labels, logo en bankgegevens als de papieren Service Bon, en kan later opnieuw gegenereerd worden.

Elke wijziging wordt lokaal (IndexedDB) opgeslagen; na een refresh of een lege batterij staat alles nog ingevuld.

Het afsluiten van een werkbon met een kapotte onderdelenlijst geeft nu een foutmelding in plaats van stil niets op te slaan.

Een werkorder zonder gekend toestel viel uit de magazijnwachtrij en uit het dagoverzicht. Beide lijsten tonen die jobs nu wel.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

Bij een opvolgbon krijgt het magazijn nu eerst een taak "Onderdelen klaarzetten". Pas als het magazijn die afvinkt, wordt de taak "Onderdelen laden in bus" actief voor de technieker. Zo is het duidelijk wie wat doet en kan de technieker niet per ongeluk bevestigen dat hij onderdelen heeft voor het magazijn ze heeft klaargelegd.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

TODO — beschrijving invullen.

Het centrale werkbonformulier was uitgegroeid tot bijna 1.500 regels code — te groot om nog overzichtelijk te onderhouden. Het is nu opgesplitst in vier afzonderlijke bestanden: Section (gedeelde wrapper), PartsSection (onderdelen), PhotoUploadSection (foto's) en TaskManager (activiteiten). De hoofdcomponent beheert enkel nog de globale formulierstatus. Werking verandert niet.

Wanneer een technieker zijn dagroute herschikt, werden meerdere database-updates los na elkaar uitgevoerd. Als er eentje mislukte, bleef de database in een inconsistente staat. Alle updates (volgorde per werkbon + planningsversie ophogen) zitten nu in één transactie: slaagt één update niet, dan worden ze allemaal teruggedraaid.

De velden voor onderdelen en opvolgacties werden als tekststring in de database bewaard, ook al zijn het eigenlijk JSON-objecten. Ze zijn nu omgezet naar het echte JSONB-type in PostgreSQL. Voordeel: PostgreSQL begrijpt de structuur, en de app hoeft niet meer handmatig te parsen via JSON.parse.

Als het uploaden of verwijderen van een foto mislukte tijdens de achtergrond-sync, stopte de volledige sync voor die werkbon. De sync gaat nu gewoon verder met de volgende foto. Andere kritische operaties (zoals volgorde-updates) stoppen nog wel bij een fout, omdat de volgorde daar wél belangrijk is.

De API die een werkbon afslaat parste de onderdelen en opvolgacties direct via JSON.parse, zonder foutafhandeling. Als de offline-sync een beschadigde waarde doorstuurde, crashte het endpoint met een 500-fout en kon de technieker zijn werkbon niet opslaan. JSON.parse zit nu in een try-catch: bij ongeldige JSON wordt null opgeslagen in plaats van te crashen.

Na de JSONB-migratie behandelde TypeScript de vier nieuwe kolommen als het type unknown, waardoor je properties niet meer rechtstreeks kon benaderen zonder extra casting. Alle JSONB-kolommen zijn nu voorzien van een .$type<>()-override in het Drizzle-schema, zodat TypeScript weet dat het PdfPart[]- of PdfFollowUp[]-objecten zijn.

Als een technieker een lege dagplanning had en toch een volgorde-update stuurde, genereerde de query inArray(workOrders.id, []) — een lege IN-lijst die ongeldige SQL oplevert in sommige versies van Drizzle. De update wordt nu overgeslagen als de lijst leeg is.

Wanneer een opvolgbon aangemaakt wordt, krijgt de werkbon automatisch twee taken: "Onderdelen laden in bus" voor de technieker (bevestigt dat de onderdelen in de bestelwagen zitten) en "Opvolgbon inplannen" voor de planning. De laak-taak wordt direct gekoppeld aan de lead-technieker van de originele werkbon. Als de planning een andere technieker toewijst via het nieuwe toewijsscherm, schuift de taak automatisch mee naar die persoon.

De planning kan een technieker koppelen aan een opvolgbon nog vóór er een datum vastligt. Zolang er geen geplande datum is, blijft de werkbon zichtbaar in de open pool: elke technieker (ook de toegewezen persoon) kan ze oppikken zodra hij/zij tijd heeft. Pas wanneer de planning een concrete datum koppelt, verdwijnt de bon uit de open pool en verschijnt ze in de dagplanning van de betrokken technieker.

De app synchroniseerde vroeger slechts één keer per dag, waardoor nieuw aangemaakte opvolgbonnen pas de volgende ochtend verschenen in de open pool. De cache vervalt nu elke 5 minuten, zodat een technieker een nieuwe bon ziet zonder de app opnieuw op te starten.

Opvolgbonnen met status "aangemaakt" werden niet getoond in de open pool omdat de query alleen werkbonnen zonder toewijzing ophaalde. De open pool toont nu alle werkbonnen met status "aangemaakt" (ongeacht toewijzing) — de status is de enige bepalende factor.

Het script dat het versienummer ophoogde las per ongeluk het eerste `version:`-veld in het bestand in plaats van de `CURRENT_RELEASE_VERSION`-constante. Hierdoor bleef het badge na meerdere deploys hetzelfde getal tonen. Het script leest nu de correcte constante en increment altijd het actieve versienummer.

`make staging-up` verhoogt nu automatisch het versienummer, commit alle gewijzigde bestanden en plaatst een TO-DO-blok in `STAGING-TODO.md` met de gewijzigde bestanden, een herinnering om de changenotes in te vullen en een reminder om nieuwe lessen toe te voegen. Zo is er altijd een traceerbare link tussen een deploy en de bijhorende wijzigingen.

De nieuwe pagina `/magazijn` toont alle openstaande `order_part`-taken gegroepeerd per werkorder. De magazijnier ziet klant, site, toestel en elk afzonderlijk onderdeel met artikelcode en aantal. Twee acties: "Besteld ✓" zet een onderdeel van "Te bestellen" naar "Besteld", "Ontvangen ✓" sluit het af als ontvangen. Ontvangen onderdelen verdwijnen niet maar verschuiven naar een inklapbare "Vandaag ontvangen"-sectie onderaan.

Zodra alle onderdelen van een bestelling ontvangen zijn (status "Alle ontvangen"), activeert de knop "Nieuwe Opvolgbon" in de bestellingskaart. Eén klik maakt automatisch een nieuwe werkbon aan voor dezelfde klant, site en toestel — met de bestelde onderdelen al ingevuld als verbruikte onderdelen. Beide werkbonnen krijgen een tijdlijn-event: de originele toont "opvolgbon aangemaakt", de nieuwe toont "aangemaakt als opvolging van…".

De inklapbare bestellingskaart op de werkbon toont alle `order_part`-taken gegroepeerd per type (stock aanvullen vs. bestellen bij leverancier). In de uitgevouwen actiebalk staan twee knoppen: "Print PDF" genereert meteen een bestelblad met artikelcodes, beschrijvingen, merk en leverancier. "Nieuwe Opvolgbon" wordt actief zodra alle onderdelen ontvangen zijn.

Een Makefile bundelt de veelgebruikte stagingcommando's. `make staging-up` zorgt altijd dat `--env-file .env.staging.local` meegegeven wordt. Zo is het niet meer mogelijk om de app te bouwen met lege databasewachtwoorden of ontbrekende API-sleutels.

De "Ontvangen ✓"-knop gaf een databasefout omdat het veld `completedBy` een foreign key is naar de `technicians`-tabel. Strings zoals `'warehouse'` of `'erp'` zijn geen geldige technicien-IDs. Opgelost door `completedBy` op `null` te zetten wanneer er geen echte technicien-ID beschikbaar is.

Op de werkbon staat nu een aparte fotozone waar de technieker een foto kan nemen met de camera of een bestaande foto uit de galerij kan kiezen.

Nieuwe werkbonfoto’s worden eerst lokaal opgeslagen in IndexedDB. Daardoor gaan ze niet verloren als de technieker offline werkt of tijdelijk geen bereik heeft.

Elke foto toont nu een kleine statusbadge: wacht op upload, mislukt of succesvol geupload. Zo ziet de technieker meteen wat al veilig op de server staat.

Open activiteiten staan nu in het avatar- en instellingenmenu met een teller, en linken rechtstreeks naar de juiste werkbon. In de activiteitenlog kan je activiteiten compacter bekijken, aanmaken en beheren.

Startuur, startlocatie en thuisadres gebruiken nu gedeelde settings in plaats van losse lokale staten. Daardoor blijven avatar, planning en routeberekening beter op elkaar afgestemd.

Adresinvoer zoals "Lintsesteenweg 25 in Kontich" wordt nu robuuster genormaliseerd voor zowel de zoekbalk als de route-geocoder. Daardoor blijven zoekresultaten en dynamische reistijden beter werken bij vrije invoer.

Elke keer dat je op "PDF Genereren & Opslaan" klikt, wordt een nieuw werkbon-record aangemaakt in de database. Zo wordt niets meer overschreven en is de volledige geschiedenis van alle ingevulde werkbonnen per toestel bewaard.

De PDF-link in de historiek werkt nu correct. De bestanden worden bewaard op de server en opgediend via een beveiligde API-route — ook in de standalone Docker-build.

Naast omschrijving, onderdelen, start- en eindtijd worden nu ook de opvolgacties bewaard als onderdeel van de werkbon in de database.

Elke INSERT, UPDATE en DELETE op alle tabellen (werkorders, klanten, sites, toestellen, techniekers, toewijzingen, documenten) wordt automatisch gelogd via PostgreSQL-triggers. De auditlog bevat de volledige oude en nieuwe rij als JSON, tijdstip en wie de wijziging maakte.

Naast de omschrijving en onderdelen worden nu ook werkStart en werkEinde als tijdstempel opgeslagen bij het afwerken van een werkbon. Zo is de volledige tijdregistratie traceerbaar per job.

De API-routes stellen een sessievariabele in (app.current_user) voor elke databasetransactie. De trigger leest deze variabele en slaat het technician-id of "admin" op in de log — zonder dat de logtabel zelf aangepast hoeft te worden.

Op elke werkbon staat nu een inklapbare toestelkaart met merk, model, serienummer en installatiedatum. Daaronder staan vier iconen: elektrisch schema, onderdelenlijst, servicehandleiding en historiek. De drie documenten zijn gekoppeld aan het toesteltype (brand + model), de historiek aan het serienummer.

Het historiekicoon toont een badge met het aantal eerdere afgewerkte jobs voor dat specifieke toestel. Klik erop om de lijst uit te klappen met datum, type en melding van elke vorige interventie. De huidige job wordt automatisch uitgesloten.

Twee nieuwe API-routes: GET /api/devices/documents haalt de 3 bestandspaden op per brand+model, POST /api/devices/documents uploadt een PDF. GET /api/devices/[id]/history geeft de afgewerkte werkorders terug voor een specifiek toestel.

Winterhalter PT-L (Rustoord Ennea) heeft nu 3 historische jobs en staat vandaag opnieuw ingepland als dringende storing. De open pool bevat 2 extra jobs: Electrolux SkyLine Pro 20GN (WZC Helianthus) en Rational iCombi Pro 6-1/1 (Hotel Scheldezicht).

De staging database bevat nu een veel grotere en realistischer dataset, met extra klanten, sites en toestellen. Daardoor kunnen we de volgende versies testen op meerdere toestellen per klant zonder eerst opnieuw basisdata te moeten uitvinden.

De klanten die vandaag al in de planning zitten zijn bewust het sterkst uitgebreid. Dat maakt het mogelijk om in de volgende versie extra opdrachten op dezelfde site voor een ander toestel te simuleren.

Voor de belangrijkste bestaande klanten en toestellen zijn oudere afgewerkte werkorders toegevoegd in de database. Die zijn nog niet in de huidige UI zichtbaar, maar vormen wel het fundament voor de toestelgeschiedenis die we in de volgende versie willen tonen.

De service-app heeft nu een echte serverdatalaag met PostgreSQL + Drizzle voor techniekers, klanten, sites, toestellen, werkorders en toewijzingen. De mock-structuur is vertaald naar relationele tabellen zodat staging niet meer alleen op losse demo-arrays hoeft te draaien.

De ontbrekende route `GET /api/sync/today` is toegevoegd. Die levert nu geplande jobs en open pool-items uit de serverlaag, met dezelfde cap van max. 6 geplande en 4 open interventies voor offline gebruik.

Het homescreen haalt de planning nu eerst uit IndexedDB en synchroniseert vervolgens met de server als de dag nog niet vers is. Daardoor krijgt de offline flow eindelijk een echte read-path in plaats van vaste mock imports.

De werkbonpagina zoekt een interventie eerst lokaal in de offline cache en valt daarna terug op een echte API-route per interventie. Rechtstreekse navigatie naar een job hangt daardoor niet meer af van `lib/mock-data.ts`.

De Docker-envs zijn opgesplitst zodat de app-container `db` gebruikt en host-tools zoals Drizzle/seed lokaal via `localhost` kunnen werken. Dat maakt `db:push` en `db:seed` voorspelbaar zodra de target Postgres draait.

Je kan nu een vrij adres intypen als start- of eindlocatie van je route. Het systeem zoekt automatisch de GPS-coördinaten op via Nominatim (OpenStreetMap) — geen vaste lijst meer nodig.

Bij elke wijziging (ander adres, volgorde, pauze verplaatst) wordt de route automatisch opnieuw berekend. Een debounce van 350 ms zorgt dat het niet bij elke toetsaanslag vuurt.

De app wacht nu op een nauwkeurige GPS-fix (< 50 m) in plaats van de eerste beschikbare schatting. Je ziet de nauwkeurigheid live aftellen (bv. "±120 m → ±18 m") terwijl de GPS verbeert. Na 20 seconden toont de app de best beschikbare positie.

"Aankomst" is verwijderd. De eerste knop heet nu "Start werk" en zet de status meteen op Bezig. Na registratie kan je de tijd nog aanpassen door erop te tikken — de native tijd-picker opent.

3 prioriteitsniveaus in plaats van 4: Laag, Gemiddeld en Hoog. De knoppen staan als een segmented control boven het datumveld, dat kleiner en rechts uitlijnt voor een nettere look.

De route-timeline toont nu echte rijtijden en afstanden berekend via OpenRouteService. De dag wordt live herberekend na elke drag & drop. Zonder API key valt het systeem terug op mock-waarden.

Elke site heeft nu lat/lon coördinaten (via Nominatim/OpenStreetMap). Het depot, klanten en nieuwe locaties zijn correct gepositioneerd in Oost-Vlaanderen.

Nieuwe adressen kunnen automatisch omgezet worden naar GPS-coördinaten via de gratis Nominatim API (OpenStreetMap). Geen API key nodig.

Twee nieuwe klanten toegevoegd: Frituur 't Pleintje (Lokeren) en Brasserie De Klok (Dendermonde). De dag bevat nu 6 geplande jobs met een route van ~148 km door Oost-Vlaanderen.

De middagpauze wordt niet meer als verplaatsing geteld. Reistijd gaat van de job vóór de pauze naar de job erna — je blijft ter plaatse.

De Planning-sectie is geen lijst meer maar een verticale route: Start → rijtijd → job → rijtijd → job → pauze → rijtijd → job → einde. Elke rijtijd wordt apart getoond, zodat je meteen ziet hoe je dag eruitziet.

Bovenaan de timeline kan je je vertrekpunt kiezen. Met één vinkje zeg je "einde = start" als je terug naar het depot rijdt, of je kiest een ander eindadres (bv. je thuis).

Er staat automatisch een pauze van 30 minuten middenin de dag. Sleep hem naar boven of beneden om hem op een andere plaats in je route te zetten.

Je ziet in één oogopslag hoeveel jobs je hebt, hoeveel werkuren er staan en hoeveel je in totaal zal moeten rijden. De cijfers worden live herberekend bij elke drag & drop.

Scrollen op mobiel werkt weer vlot. Slepen start alleen vanaf de ⋮⋮ handle aan de linkerkant van een kaart, met een korte hold van 250 ms zodat een snelle scroll nooit per ongeluk een drag wordt.

De dag is nu opgesplitst in twee lijsten: "Planning" (door de dispatcher ingepland, in volgorde) en "Open pool" (flexibele jobs die je zelf kan oppikken als je tijd over hebt).

Sleep een geplande job via de handle links om de volgorde aan te passen aan je route. De nieuwe volgorde wordt later ook naar de server gesynchroniseerd zodat de dispatcher ziet hoe je de dag afwerkt.

Onderaan rechts zie je nu welke versie actief is. Op staging staat er "STAGING · v1.5" in oranje, op productie enkel het versienummer. Zo weet je altijd op welke omgeving je zit.

Het dagoverzicht toont nu 4 geplande jobs + 2 jobs in de open pool, zodat je de nieuwe layout en drag & drop kan testen.

Interventies worden nu in IndexedDB bewaard (4 stores: interventions, werkbonnen, pendingWrites, dayMeta). Acties die je offline doet worden in een pending-queue gezet en automatisch verstuurd zodra je terug online bent.

Een provider-agnostische routing-laag (IRoutingService) haalt rijtijden en afstanden op. Fase 1 gebruikt OpenRouteService (gratis); fase 2 zal TomTom gebruiken voor file-bewuste rijtijden — de business-logic verandert niet mee.