Darba laika uzskaite revīzijas uzņēmumam: 4 klusas kļūdas

Es esmu Denys, full-stack un AI inženieris. Laikā no 2026. gada maija līdz oktobrim revīzijas uzņēmums pārgāja no rīka, kurā ikviens varēja atvērt katru klientu, uz uzskaites lietotni, ko es izveidoju tikai tam, 388 commit laikā. Uzņēmuma nosaukums šeit nav minēts. Šis raksts ir cilvēkiem, kas vada uzņēmumu un izvēlas tā rīkus: ko revīzijas uzņēmumam vajag no darba laika uzskaites, kuras četras kļūdas atradu un kā jebkuru uzskaites rīku pārbaudīt to ziņā.

Ko revīzijas uzņēmumam vajag no darba laika uzskaites?

Revīzijas uzņēmums pārdod stundas, tāpēc darba laika uzskaite ir ieraksts, uz kura balstās viss bizness. Uzņēmumam, kuram es veidoju rīku, vajadzēja:

• Stundas pret klientu, projektu un uzdevumu. Katrs ieraksts pieder vienam darbam, tāpēc stundas var nolasīt pa klientiem, projektiem un cilvēkiem.
• Nedēļas darba laika lapas ar apstiprināšanu. Darbinieki iesniedz nedēļu, projekta admins apstiprina vai noraida katru ierakstu, un skaitās tikai apstiprinātās stundas.
• Atgādinājumus. Ikviens, kura darba laika lapa termiņā vēl ir tukša, saņem e-pastu. Kopš 2026. gada septembra tas atgādina tikai par trūkstošajām stundām un izlaiž cilvēkus ar nulles kapacitāti.
• Resursu plānošanu. Kurš ar kuru darbu nodarbosies tuvākajās nedēļās, salīdzinot ar katra cilvēka kapacitāti.
• Konfidenciālus klientus. Īpašnieks var ierobežot klientu ar tā projektiem, uzdevumiem un laiku uz izvēlētiem dalībniekiem.
• Arhivē, nedzēs. Aizejošs dalībnieks tiek deaktivizēts un anonimizēts, un pabeigts projekts tiek arhivēts, tāpēc darba laika lapu vēsture paliek vesela.

Tas neizraksta rēķinus. Projektu norēķinu veids un stundu budžeti ir aiz savas atļaujas, un rēķinu izrakstīšana paliek uzņēmuma grāmatvedības sistēmā.

Kam revīzijas uzņēmumā vajadzētu redzēt kāda stundas?

Pirms šī projekta ikviens uzņēmumā varēja atvērt katru klientu un visu stundas. Revīzijas uzņēmumam tā vispirms ir konfidencialitātes problēma un tikai tad programmatūras problēma: ne katram dalībniekam jāredz katrs klients, un nevienam nav jāredz kolēģa nedēļa, ja vien viņš to neapstiprina.

Uzņēmuma apstiprinātais piekļuves modelis izskatās šādi:

Loma	Redz	Var apstiprināt
Darbinieks	Tikai savas stundas	Neko
Projekta admins	Komandas stundas savos projektos	Komandas nedēļas šajos projektos
Īpašnieks	Katru klientu, projektu un cilvēku	Visu
Konfidenciāls klients	Redzams tikai dalībniekiem, ko izvēlējies īpašnieks	—

Īpašnieks veido katru lomu ķeksīšu matricā, jomas pret darbībām, un katrs noteikums dzīvo datubāzē, nevis ekrānos, tāpēc lapa nevar parādīt to, ko datubāze noraida. Katra rūtiņa pirms izlaides tika testēta pret produkcijas kopiju; kā un ko šis tests atrada, ir aprakstīts rakstā kā testēt Supabase RLS.

Uz vienu jautājumu matrica atbildēt nespēja, un tas nāca no paša uzņēmuma. 2026. gada jūnijā dalībnieks ar visierobežotāko lomu resursu plānošanas ekrānā redzēja citus dalībniekus un viņu projektus, lai gan gaidīja redzēt tikai sevi un vienu komandas biedru. Vai ierobežotam dalībniekam vajadzētu redzēt cilvēkus no sava projekta? Noteikums, ko izvēlējāmies: jā, bet tikai kopīgos projektos, un citu cilvēku kapacitāte un atvaļinājumi ir paslēpti.

Kā iegūt piekļuves modeli, ar kuru uzņēmums tiešām piekrīt? Es neprasīju klientam to aprakstīt no atmiņas. Nosūtīju anketu ar 72 jautājumiem 9 sadaļās, kurā atļauju režģi jau bija atzīmēti tā, kā strādāja dzīvā sistēma 2026. gada 7. augustā. Klients izlaboja to, kas bija nepareizi, un katra mainītā rūtiņa tika atzīmēta. Cilvēki labāk labo realitāti, nekā to apraksta.

1. kļūda: atskaišu kopsummas iznāktu pārāk mazas

Lapā Timesheets ir visa uzņēmuma skati “Šis ceturksnis” un “Gads līdz šim”. Tie ielādēja visus laika ierakstus periodā vienā pieprasījumā. Lietotnes aizmugurē esošā datubāzes API atgriež ne vairāk kā 1000 rindu uz pieprasījumu, un, kad tā apstājas pie 1000, tā neizmet kļūdu. Tā vienkārši atgriež pirmās 1000.

Supabase dokumentē noklusējumu: projekti atgriež ne vairāk kā 1000 rindu, ja ierobežojums API iestatījumos netiek mainīts.

Tiklīdz uzņēmums periodā pārsniegtu 1000 ierakstu, dalībnieki un nedēļas izkristu no skata, un kopsummas iznāktu pārāk mazas, un nekas ekrānā to neteiktu. Pie aptuveni 70 ierakstiem nedēļā skats “Gads līdz šim” 2026. gada novembra vidū pārsniegtu 1000 ierakstu. Koda audits 2026. gada 24. septembrī to atrada, pirms tas notika. Labojums nolasa katru periodu pa lapām, un katrs atskaites eksports tagad lapo tāpat.

Kā pārbaudīt savu rīku: izvēlieties garu periodu, eksportējiet neapstrādātos ierakstus, saskaitiet tos paši un salīdziniet ar atskaites kopsummu. Ja tās atšķiras, atskaite nogriež rindas.

2. kļūda: “Saglabāts”, kad nekas netika saglabāts

Kad datubāze noraida izmaiņu atļaujas dēļ vai tāpēc, ka noteikums prasa divfaktoru pieteikšanos, tā var atbildēt “0 rindu mainītas” bez kļūdas. Apmēram 30 vietas lietotnē, kas atjaunina vai dzēš ierakstus, lasīja šo atbildi kā veiksmi un rādīja “saglabāts”. Cilvēks dodas tālāk. Izmaiņas nenotika.

Labojums ir atteikties slēgti: ieraksts, kas neskar nevienu rindu, ir kļūda un tiek rādīts kā kļūda, un tests tagad pārbauda, ka katrs ierakstīšanas ceļš to tā apstrādā.

Kā pārbaudīt savu rīku: piesakieties kā dalībnieks bez tiesībām kaut ko rediģēt, mēģiniet to rediģēt un pārlādējiet lapu. Ja redzējāt “saglabāts” un vecā vērtība ir atpakaļ, rīks melo par saglabāšanu.

3. kļūda: konfidenciāls klients noplūda caur atskaitēm

Daži darbi ir zināmi tikai tiem, kas pie tiem strādā. Kopš 2026. gada 24. augusta īpašnieks var ierobežot klientu uz nosauktiem dalībniekiem. Visi pārējie par šo klientu, tā projektiem, uzdevumiem vai laiku nesaņem neko. Īpašniekam piekļuve ir vienmēr, un šī piekļuve tiek aprēķināta no tā, kam īpašnieka loma ir tagad, nevis saglabāta, tāpēc tā pārvietojas kopā ar lomu.

Klienta paslēpšana no klientu saraksta bija vieglā daļa. Noplūdes bija blakus durvīs. Pārskats 2026. gada 8. septembrī atklāja, ka:

• trīs atskaišu funkcijas ignorēja ierobežojumu, jo tās darbojas ar tiesībām, kas apiet parastos piekļuves noteikumus, tāpēc konfidenciāla klienta stundas varēja parādīties atskaitēs;
• birku lietojuma skaiti administrēšanas birku pārskatā ieskaitīja konfidenciālā klienta projektus un uzdevumus, kas atklāja, ka darbs pastāv, un aptuveni cik liels tas ir;
• kļūdu ziņojumi atšķīra gadījumus: mēģinājums mainīt īstu, bet paslēptu ierakstu atgrieza “forbidden”, mēģinājums mainīt izdomātu atgrieza “not found”, tāpēc ikviens varēja noskaidrot, vai konfidenciāls klients pastāv.

Visas trīs tagad piemēro to pašu pārbaudi kā galvenās tabulas, un paslēpts ieraksts izskatās tieši kā neesošs. Projekta vai ieraksta pārvietošanai prom no konfidenciāla klienta arī vajadzīgs īpašnieks vai atsevišķa atļauja, un katra šāda pārvietošana tiek reģistrēta.

Kā pārbaudīt savu rīku: ierobežojiet vienu klientu uz vienu cilvēku. Pēc tam kā kāds cits palaidiet katru atskaiti, apskatiet katru skaitli un filtru, meklējiet klienta nosaukumu un atveriet tiešo saiti uz vienu no tā projektiem. Pēdām nevajadzētu būt nekur, arī kļūdas ziņojumā.

4. kļūda: noraidījumu varēja paslēpt vēlāks apstiprinājums

Nedēļā var būt ieraksti vairākos projektos, tāpēc to apstiprina vairāki cilvēki. Ja viens projekta admins noraidīja ierakstu un cits vēlāk apstiprināja savu daļu, vēlākais apstiprinājums varēja izšķirt visu nedēļu un nomaskēt noraidījumu. Ierakstu pārvietošana starp uzdevumiem vai nedēļas atkārtota atvēršana to varēja paslēpt tāpat.

2026. gada 24. septembrī apstiprināšanas loģika tika mainīta tā, ka nedēļa paliek noraidīta, kamēr kaut viens noraidīts ieraksts ir spēkā, un projekta admins var arhivēt noraidītu ierakstu tikai tad, ja noraidīja to pats. Datubāzes zonde tagad palaiž katru no šiem gadījumiem, un katram jābūt PASS.

Kā pārbaudīt savu rīku: izmantojiet divus apstiprinātājus vienai nedēļai. Pirmais noraida vienu ierakstu, otrais apstiprina visu pārējo, un paskatieties, kādā stāvoklī nedēļa nonāk.

Pirkt vai veidot darba laika uzskaiti revīzijas uzņēmumam?

Vispirms pērciet. Toggl, BigTime, ZenWorkflow un līdzīgi rīki jau sedz taimerus, nedēļas apstiprinājumus un klientu norēķinus, un ar tiem var sākt jau šonedēļ. Pielāgots uzskaites rīks ir pamatots, kad uzņēmumam ir noteikumi, ko produkti nespēj izteikt, piemēram, konfidenciāli klienti, kas redzami tikai nosauktiem dalībniekiem, nedēļas apstiprināšana ar vairākiem projektu adminiem vai lomas, ko īpašnieks vēlas veidot rūtiņu pa rūtiņai.

Kuru ceļu izvēlētos, četras iepriekšminētās pārbaudes aizņem pēcpusdienu un pasaka vairāk nekā funkciju saraksts. Katrā produkta lapā rakstīts “detalizētas atļaujas”. Maz kur parāda, kas notiek, kad noņem ķeksīti.

Šī ziņojuma ierobežojumi

• Viens uzņēmums. Piekļuves modelis, apmēram 70 ierakstu apjoms nedēļā un anketa ir no viena uzņēmuma.
• 1. kļūda tika notverta, pirms tā iedarbojās. Novembra vidus datums ir prognoze, balstīta uz uzņēmuma ierakstu tempu, nevis izmērīts gadījums.
• Nav rēķinu izrakstīšanas. Uzskaites rīks glabā stundas, norēķinu veidu un stundu budžetus, bet neizraksta rēķinus klientiem, tāpēc par ceļu no stundām līdz rēķinam man nav ko teikt.

Šeit minētie piekļuves noteikumi ir Postgres rindu līmeņa drošība. Divas bedres, ko lomu matrica neuztver, aprakstītas atsevišķi: lietotājs, kas pieder divām organizācijām un IF, kas ar NULL izlaiž pārbaudi. Pats izstrādes process ir revīzijas uzņēmuma darba laika uzskaites gadījumā, un šāds darbs ietilpst iekšējos rīkos un informācijas paneļos.