Tööaja arvestus audiitorettevõttele: 4 vaikset viga

Olen Denys, full-stack- ja AI-insener. 2026. aasta mai ja oktoobri vahel läks audiitorettevõte üle tööriistalt, kus igaüks sai avada iga kliendi, jälgimisrakendusele, mille ehitasin ainult talle, 388 commit’i jooksul. Ettevõtte nime siin ei nimetata. See kirjutis on neile, kes ettevõtet juhivad ja selle tööriistu valivad: mida audiitorettevõte tööaja arvestuselt vajab, millised neli viga leidsin ja kuidas mis tahes jälgimisrakendust nende suhtes kontrollida.

Mida audiitorettevõte tööaja arvestuselt vajab?

Audiitorettevõte müüb tunde, seega on tööaja arvestus kirje, millel kogu äri seisab. Ettevõte, kellele ehitasin, vajas:

• Tunde kliendi, projekti ja ülesande vastu. Iga kirje kuulub ühele töövõtule, nii et tunde saab lugeda kliendi, projekti ja inimese kaupa.
• Nädalaseid tööajatabeleid kinnitamisega. Töötajad esitavad nädala, projekti admin kinnitab või lükkab iga kirje tagasi ja arvesse lähevad ainult kinnitatud tunnid.
• Meeldetuletusi. Igaüks, kelle tööajatabel on tähtajaks veel tühi, saab e-kirja. Alates 2026. aasta septembrist meenutab see ainult puuduvaid tunde ja jätab vahele inimesed, kelle võimsus on null.
• Ressursside jaotust. Kes millise töövõtu kallal lähinädalatel töötab, iga inimese võimsuse suhtes.
• Konfidentsiaalseid kliente. Omanik saab kliendi koos tema projektide, ülesannete ja ajaga piirata valitud liikmetele.
• Arhiveeri, ära kustuta. Lahkuv liige deaktiveeritakse ja anonümiseeritakse ning lõppenud projekt arhiveeritakse, nii et tööajatabelite ajalugu jääb terviklikuks.

See ei esita arveid. Projektide arvelduse liik ja tunnieelarved on oma õiguse taga ning arvete esitamine jääb ettevõtte raamatupidamissüsteemi.

Kes peaks audiitorettevõttes kelle tunde nägema?

Enne seda projekti sai igaüks ettevõttes avada iga kliendi ja kõigi tunnid. Audiitorettevõttele on see esmalt konfidentsiaalsuse probleem ja alles siis tarkvaraprobleem: mitte iga liige ei tohiks näha iga klienti ja mitte keegi ei pea nägema kolleegi nädalat, kui ta seda ei kinnita.

Ettevõtte kinnitatud ligipääsumudel näeb välja selline:

Roll	Näeb	Saab kinnitada
Töötaja	Ainult oma tunde	Mitte midagi
Projekti admin	Tiimi tunde oma projektidel	Tiimi nädalaid nendel projektidel
Omanik	Iga klienti, projekti ja inimest	Kõike
Konfidentsiaalne klient	Nähtav ainult liikmetele, kelle omanik valis	—

Omanik kujundab iga rolli märkeruutude maatriksis, valdkonnad toimingute vastu, ja iga reegel elab andmebaasis, mitte ekraanidel, nii et leht ei saa näidata seda, mida andmebaas keelab. Iga ruut testiti enne väljalaset tootmise koopia vastu; kuidas ja mida see test leidis, on kirjas artiklis Supabase RLS-i testimine.

Ühele küsimusele maatriks vastata ei suutnud ja see tuli ettevõttelt endalt. 2026. aasta juunis nägi kõige piiratuma rolliga liige ressursside jaotuse ekraanil teisi liikmeid ja nende projekte, kuigi ootas näha ainult iseennast ja ühte tiimikaaslast. Kas piiratud liige peaks nägema oma projektide inimesi? Reegel, milles kokku leppisime: jah, aga ainult ühistel projektidel, ning teiste võimsus ja puhkus on peidetud.

Kuidas saada ligipääsumudel, millega ettevõte tõesti nõustub? Ma ei palunud kliendil seda mälu järgi kirjeldada. Saatsin küsimustiku 72 küsimusega 9 jaotuses, kus õiguste ruudustikud olid juba märgitud nii, nagu töötas tegelik süsteem 7. augustil 2026. Klient muutis selle, mis oli vale, ja iga muudetud lahter märgiti. Inimesed oskavad tegelikkust paremini parandada kui kirjeldada.

Viga 1: aruannete summad oleksid tulnud liiga väikesed

Lehel Timesheets on kogu ettevõtte vaated “See kvartal” ja “Aasta algusest”. Need laadisid kõik vahemiku ajakirjed ühe päringuga. Rakenduse taga olev andmebaasi API tagastab ühe päringu kohta kuni 1 000 rida ega tõsta viga, kui see 1 000 juures peatub. See tagastab lihtsalt esimesed 1 000.

Supabase dokumenteerib vaikeväärtuse: projektid tagastavad kuni 1 000 rida, kui piirangut API seadetes ei muudeta.

Niipea kui ettevõte ületaks vahemikus 1 000 kirjet, kukuksid liikmed ja nädalad vaatest välja ning summad tuleksid liiga väikesed ilma et miski ekraanil seda ütleks. Umbes 70 kirjega nädalas oli “Aasta algusest” vaade 2026. aasta novembri keskpaigas 1 000 kirjet ületamas. Koodiaudit 24. septembril 2026 leidis selle enne, kui see juhtus. Parandus loeb iga vahemiku lehekülg-lehekülje haaval ja iga aruande eksport lehitseb nüüd samamoodi.

Kuidas oma tööriista kontrollida: valige pikk vahemik, eksportige toorkirjed, liitke need ise kokku ja võrrelge aruande kogusummaga. Kui need erinevad, lõikab aruanne ridu.

Viga 2: “Salvestatud”, kui midagi ei salvestatud

Kui andmebaas lükkab muudatuse tagasi õiguse puudumise tõttu või sellepärast, et reegel nõuab kaheastmelist sisselogimist, võib see vastata “0 rida muudetud” ilma veata. Umbes 30 kohta rakenduses, mis kirjeid uuendavad või kustutavad, luges selle vastuse edukaks ja näitas “salvestatud”. Inimene liigub edasi. Muudatust ei toimunud.

Parandus on ebaõnnestuda suletult: kirjutamine, mis ei puutu ühtegi rida, on viga ja seda näidatakse veana ning test kontrollib nüüd, et iga kirjutamistee seda nii käsitleb.

Kuidas oma tööriista kontrollida: logige sisse liikmena, kellel pole õigust midagi muuta, proovige seda muuta ja laadige leht uuesti. Kui nägite “salvestatud” ja vana väärtus on tagasi, valetab tööriist salvestuste kohta.

Viga 3: konfidentsiaalne klient lekkis aruannete kaudu

Mõned töövõtud on teada ainult neile, kes neil töötavad. Alates 24. augustist 2026 saab omanik kliendi piirata nimetatud liikmetele. Kõik teised ei saa kliendi, tema projektide, ülesannete ega aja kohta midagi tagasi. Omanikul on ligipääs alati ja see ligipääs arvutatakse selle järgi, kellel on omaniku roll praegu, mitte ei salvestata, nii et see liigub koos rolliga.

Kliendi peitmine kliendiloendist oli lihtne osa. Lekked olid kõrvaluksed. Ülevaatus 8. septembril 2026 leidis, et:

• kolm aruandefunktsiooni ignoreerisid piirangut, sest need töötavad õigustega, mis jätavad tavalised ligipääsureeglid vahele, nii et konfidentsiaalse kliendi tunnid võisid aruannetes ilmuda;
• siltide kasutusarvud halduse siltide ülevaates lugesid konfidentsiaalse kliendi projekte ja ülesandeid, mis andis ära töövõtu olemasolu ja ligikaudse suuruse;
• veateated tegid vahet: päris, kuid peidetud kirje muutmise katse tagastas “forbidden”, väljamõeldud kirje oma “not found”, nii et igaüks sai uurida, kas konfidentsiaalne klient on olemas.

Kõik kolm rakendavad nüüd sama kontrolli kui põhitabelid ja peidetud kirje näeb välja täpselt nagu puuduv. Projekti või kirje viimine konfidentsiaalsest kliendist välja vajab samuti omanikku või eraldi õigust ning iga selline liigutus logitakse.

Kuidas oma tööriista kontrollida: piirake üks klient ühele inimesele. Seejärel käivitage kellegi teisena iga aruanne, vaadake iga arvu ja filtrit, otsige kliendi nime ja avage otselink ühele tema projektile. Jälgi ei tohiks leiduda, veateatest ka mitte.

Viga 4: tagasilükkamise sai hilisema kinnitusega peita

Nädalal võib olla kirjeid mitmel projektil, seega kinnitab seda mitu inimest. Kui üks projekti admin lükkas kirje tagasi ja teine kinnitas hiljem oma osa, võis hilisem kinnitus kogu nädala lahendada ja tagasilükkamise varjata. Kirjete liigutamine ülesannete vahel või nädala uuesti avamine võis seda samamoodi peita.

24. septembril 2026 muudeti kinnitusloogikat nii, et nädal jääb tagasi lükatuks seni, kuni vähemalt üks tagasi lükatud kirje on elus, ja projekti admin saab tagasi lükatud kirje arhiveerida ainult siis, kui ta lükkas selle ise tagasi. Andmebaasi sond käivitab nüüd iga sellise juhu ja igaüks peab näitama PASS.

Kuidas oma tööriista kontrollida: kasutage ühel nädalal kahte kinnitajat. Lükake üks kirje esimesena tagasi, kinnitage kõik muu teisena ja vaadake, mis olekusse nädal jääb.

Osta või ehita audiitorettevõtte tööaja arvestus?

Osta esmalt. Toggl, BigTime, ZenWorkflow ja sarnased tööriistad katavad juba taimerid, nädalased kinnitused ja kliendiarveldused ning nendega saab alustada juba sel nädalal. Kohandatud jälgimisrakendus on mõistlik, kui ettevõttel on reeglid, mida tooted väljendada ei suuda, näiteks konfidentsiaalsed kliendid, kes on nähtavad ainult nimetatud liikmetele, nädala kinnitamine mitme projekti admini poolt või rollid, mida omanik tahab ruut-ruudu haaval kujundada.

Kumma tee te ka ei vali, neli ülalolevat kontrolli võtavad ühe pärastlõuna ja ütlevad rohkem kui funktsioonide nimekiri. Igal tootelehel seisab “detailsed õigused”. Vähesed näitavad, mis juhtub, kui ruudu märke eemaldate.

Selle aruande piirid

• Üks ettevõte. Ligipääsumudel, umbes 70 kirje maht nädalas ja küsimustik on ühest ettevõttest.
• Viga 1 tabati enne, kui see käivitus. Novembri keskpaiga kuupäev on projektsioon ettevõtte kirjete tempost, mitte mõõdetud juhtum.
• Arveldust pole. Jälgimisrakendus hoiab tunde, arvelduse liiki ja tunnieelarveid, kuid ei esita klientidele arveid, seega ei saa ma midagi öelda tunnist arveni voogude kohta.

Siinsed ligipääsureeglid on Postgresi reataseme turve. Kaks auku, mida rollimaatriks ei püüa, on kirjutatud eraldi: kasutaja, kes kuulub kahte organisatsiooni ja IF, mis jätab NULLi puhul kontrolli vahele. Ehitus ise on audiitorfirma ajaarvestuse juhtumis ja seda laadi töö kuulub sisetööriistade ja töölaudade alla.