--- title: "Darbo laiko apskaita audito įmonei: 4 tylios klaidos" description: "Kurdamas darbo laiko apskaitą audito įmonei radau keturias nematomas klaidas: mažesnės sumos, netikri išsaugojimai, nutekėjęs klientas, paslėpti atmetimai." url: "https://madsalt.tech/lt/blog/time-tracking-for-audit-firms/" author: "Denys Zaichenko" language: "lt" published: 2026-10-19 --- # Darbo laiko apskaita audito įmonei: 4 tylios klaidos Trumpai Darbo laiko apskaita audito įmonėje nėra apie laikmatį. Ji apie du dalykus: kas gali matyti kurio kliento valandas ir ar ataskaitų sumos teisingos. Kurdamas įrankį vienai audito įmonei radau keturias klaidas, kurių nerodė joks ekranas: ataskaitų sumas, kurios tyliai išeitų per mažos, apie 30 veiksmų, kurie rodė „išsaugota“, nors nieko neišsaugojo, konfidencialų klientą, kurio egzistavimas nutekėjo per ataskaitas ir žymių skaičius, ir atmestą įrašą, kurį galėjo paslėpti vėlesnis patvirtinimas. Kiekvieną iš jų bet kuriame įrankyje, pirktame ar sukurtame, galima patikrinti per kelias minutes. Esu Denys, full-stack ir AI inžinierius. 2026 m. gegužės–spalio mėnesiais viena audito įmonė perėjo nuo įrankio, kuriame kiekvienas galėjo atidaryti kiekvieną klientą, prie darbo laiko apskaitos, kurią jai sukūriau per 388 commit. Įmonės čia nenurodau. Šis tekstas skirtas žmonėms, kurie vadovauja įmonei ir renkasi jos įrankius: ko audito įmonei reikia iš darbo laiko apskaitos, keturios rastos klaidos ir kaip bet kurį įrankį patikrinti dėl jų. ## Ko audito įmonei reikia iš darbo laiko apskaitos? Audito įmonė parduoda valandas, todėl darbo laiko apskaita yra įrašas, ant kurio stovi visas verslas. Įmonei, kuriai kūriau, reikėjo: - **Valandų pagal klientą, projektą ir užduotį.** Kiekvienas įrašas priklauso vienam užsakymui, todėl valandas galima skaityti pagal klientą, projektą ir asmenį. - **Savaitės darbo laiko žiniaraščių su patvirtinimu.** Darbuotojai pateikia savaitę, projekto administratorius kiekvieną įrašą patvirtina arba atmeta, o skaičiuojamos tik patvirtintos valandos. - **Priminimų.** Kas prieš terminą vis dar turi tuščią žiniaraštį, gauna el. laišką. Nuo 2026 m. rugsėjo jis primena tik apie trūkstamas valandas ir praleidžia žmones, kurių pajėgumas lygus nuliui. - **Išteklių planavimo.** Kas artimiausiomis savaitėmis dirbs prie kurio užsakymo, atsižvelgiant į kiekvieno žmogaus pajėgumą. - **Konfidencialių klientų.** Savininkas gali apriboti klientą kartu su jo projektais, užduotimis ir laiku pasirinktiems nariams. - **Archyvuoti, niekada netrinti.** Išeinantis narys deaktyvuojamas ir anonimizuojamas, baigtas projektas archyvuojamas, todėl žiniaraščių istorija lieka nepaliesta. Sąskaitų jis neišrašo. Projektų atsiskaitymo būdas ir valandų biudžetai yra už atskiro leidimo, o sąskaitos faktūros lieka įmonės apskaitos sistemoje. ![Savaitės valandos nuo įrašo iki ataskaitos. Valandos patenka į ataskaitas tik projekto administratoriui jas patvirtinus. Patvirtinta savaitė: Darbuotojas → Savaitė pateikta → Proj. admin. → Patvirtinta → Ataskaitos; Atmestas įrašas: Darbuotojas → Savaitė pateikta → Proj. admin. → Grąžinta su priežastimi.](https://madsalt.tech/charts/lt/time-tracking-for-audit-firms-week.svg) *1 pav. Savaitės darbo laiko žiniaraščio eiga audito įmonės įrankyje. Atmestas įrašas grįžta jį įvedusiam asmeniui.* ## Kas audito įmonėje turi matyti kieno valandas? Prieš šį projektą kiekvienas įmonėje galėjo atidaryti kiekvieną klientą ir visų valandas. Audito įmonei tai pirmiausia konfidencialumo problema ir tik paskui programinė: ne kiekvienas narys turi matyti kiekvieną klientą, o kolegos savaitės niekam nereikia matyti, jei jos netvirtina. Prieigos modelis, kurį įmonė patvirtino, atrodo taip: | Rolė | Mato | Gali tvirtinti | | ------------------------- | ------------------------------------------- | ---------------------------------------- | | Darbuotojas | Tik savo valandas | Nieko | | Projekto administratorius | Komandos valandas savo projektuose | Savo komandos savaites tuose projektuose | | Savininkas | Kiekvieną klientą, projektą ir asmenį | Viską | | Konfidencialus klientas | Matomas tik savininko pasirinktiems nariams | — | ![Kas mato kieno valandas. Prieigos modelis, kurį įmonė patvirtino. Jį užtikrina duomenų bazė, o ne ekranas. Darbuotojas: Darbuotojas → Tik savo valandas; Projekto admin.: Projekto admin. → Komanda savo projektuose → Tvirtina jų savaites; Savininkas: Savininkas → Visi klientai ir asmenys; Konfidencialus klientas: Apribotas klientas → Tik pasirinkti nariai.](https://madsalt.tech/charts/lt/time-tracking-for-audit-firms-roles.svg) *2 pav. Numatytosios rolės audito įmonės įrankyje. Savininkas gali keisti kiekvieną rolę leidimų matricoje.* Savininkas formuoja kiekvieną rolę varnelių matricoje, sritis prieš veiksmą, o kiekviena taisyklė gyvena duomenų bazėje, ne ekranuose, todėl puslapis negali parodyti to, ko duomenų bazė neleidžia. Kiekvienas langelis prieš išleidimą buvo išbandytas produkcijos kopijoje; kaip ir ką tas testas rado, aprašyta straipsnyje [kaip testuoti Supabase RLS](https://madsalt.tech/lt/blog/how-to-test-supabase-rls/). Vieną klausimą, į kurį matrica negalėjo atsakyti, atnešė pati įmonė. 2026 m. birželį narys su labiausiai apribota role išteklių planavimo ekrane matė kitus narius ir jų projektus, nors tikėjosi matyti tik save ir vieną kolegą. Ar apribotas narys turi matyti žmones savo projektuose? Taisyklė, dėl kurios susitarėme: taip, tik bendruose projektuose, o kitų žmonių pajėgumas ir laisvos dienos paslėpti. Kaip prieiti prie prieigos modelio, su kuriuo įmonė tikrai sutinka? Neprašiau kliento jo aprašyti iš atminties. Išsiunčiau klausimyną su 72 klausimais 9 skyriuose, o leidimų lenteles jau užpildžiau taip, kaip gyva sistema veikė 2026 m. rugpjūčio 7 d. Klientas pataisė, kas buvo netiesa, ir kiekviena pakeista ląstelė buvo pažymėta. Žmonės geriau taiso tikrovę, nei ją aprašo. ## 1 klaida: ataskaitų sumos būtų išėjusios per mažos Puslapyje „Darbo laiko žiniaraščiai“ yra visos įmonės rodiniai „Šis ketvirtis“ ir „Metų pradžia iki šiol“. Jie vienu užklausimu įkeldavo visus laiko įrašus intervale. Duomenų bazės API, esanti už programos, vienu užklausimu grąžina daugiausia 1 000 eilučių, o sustojusi ties 1 000 klaidos nekelia. Ji tiesiog grąžina pirmąsias 1 000. Supabase dokumentuoja numatytąją reikšmę: [projektai grąžina daugiausia 1 000 eilučių](https://supabase.com/docs/reference/javascript/select), jei riba nepakeičiama API nustatymuose. Todėl kai tik įmonė intervale viršytų 1 000 įrašų, nariai ir savaitės iškristų iš rodinio, o sumos išeitų per mažos, ir ekrane nieko apie tai nesakytų. Esant maždaug 70 įrašų per savaitę, metų pradžios rodinys 1 000 įrašų turėjo viršyti maždaug 2026 m. lapkričio viduryje. Kodo auditas 2026 m. rugsėjo 24 d. tai rado, kol dar nebuvo nutikę. Pataisa skaito kiekvieną intervalą puslapis po puslapio, ir kiekvienas ataskaitų eksportas dabar skirstomas puslapiais taip pat. **Kaip patikrinti savo įrankį:** pasirinkite ilgą laikotarpį, eksportuokite neapdorotus įrašus, patys juos susumuokite ir palyginkite su ataskaitos suma. Jei jos skiriasi, ataskaita apkarpo eilutes. ## 2 klaida: „Išsaugota“, nors nieko neišsaugota Kai duomenų bazė atmeta pakeitimą dėl leidimo arba todėl, kad taisyklei reikia dviejų veiksnių prisijungimo, ji gali atsakyti „pakeista 0 eilučių“ be jokios klaidos. Apie 30 vietų programoje, kurios atnaujina ar trina įrašus, šį atsakymą skaitė kaip sėkmę ir rodė „išsaugota“. Žmogus eina toliau. Pakeitimas niekada neįvyko. Pataisa yra nesėkmė saugiąja kryptimi: įrašymas, kuris neliečia nė vienos eilutės, yra klaida ir rodomas kaip klaida, o testas dabar tikrina, kad taip jį traktuoja kiekvienas įrašymo kelias. **Kaip patikrinti savo įrankį:** prisijunkite kaip narys be teisės ko nors redaguoti, pabandykite tai redaguoti ir perkraukite puslapį. Jei matėte „išsaugota“, o sugrįžo sena reikšmė, įrankis meluoja apie išsaugojimą. ## 3 klaida: konfidencialus klientas nutekėjo per ataskaitas Kai kuriuos užsakymus žino tik juose dirbantys žmonės. Nuo 2026 m. rugpjūčio 24 d. savininkas gali apriboti klientą nurodytiems nariams. Visi kiti apie tą klientą, jo projektus, užduotis ar laiką negauna nieko. Savininkas prieigą turi visada, ir ji apskaičiuojama pagal tai, kas šiandien turi savininko rolę, o ne saugoma, todėl pasikeičia kartu su role. Paslėpti klientą kliento sąraše buvo lengva. Nutekėjimai buvo pro šonines duris. 2026 m. rugsėjo 8 d. peržiūra nustatė, kad: - **trys ataskaitų funkcijos apribojimo nepaisė**, nes veikia su teisėmis, kurios apeina įprastas prieigos taisykles, todėl konfidencialaus kliento valandos galėjo atsirasti ataskaitose; - **žymių naudojimo skaičiai** žymių administravimo apžvalgoje skaičiavo konfidencialaus kliento projektus ir užduotis, taip išduodami, kad užsakymas egzistuoja ir maždaug kokio jis dydžio; - **klaidų pranešimai skyrėsi**: bandymas pakeisti tikrą, bet paslėptą įrašą grąžino „forbidden“, o bandymas pakeisti išgalvotą grąžino „not found“, todėl bet kas galėjo tikrinti, ar konfidencialus klientas egzistuoja. Visos trys dabar taiko tą pačią patikrą kaip pagrindinės lentelės, o paslėptas įrašas atrodo lygiai taip pat kaip neegzistuojantis. Projekto ar įrašo perkėlimui nuo konfidencialaus kliento taip pat reikia savininko arba atskiro leidimo, ir kiekvienas toks perkėlimas registruojamas. **Kaip patikrinti savo įrankį:** apribokite vieną klientą vienam žmogui. Tada kaip kas nors kitas paleiskite kiekvieną ataskaitą, peržiūrėkite kiekvieną skaičių ir filtrą, ieškokite kliento pavadinimo ir atidarykite tiesioginę nuorodą į vieną jo projektą. Pėdsakų neturėtumėte rasti jokių, net klaidos pranešime. ## 4 klaida: atmetimą galėjo paslėpti vėlesnis patvirtinimas Savaitė gali turėti įrašų keliuose projektuose, todėl ją tvirtina keli žmonės. Jei vienas projekto administratorius atmetė įrašą, o kitas vėliau patvirtino savo dalį, vėlesnis patvirtinimas galėjo uždaryti visą savaitę ir uždengti atmetimą. Taip pat jį galėjo paslėpti įrašų perkėlimas tarp užduočių ar savaitės atidarymas iš naujo. 2026 m. rugsėjo 24 d. patvirtinimo logika pasikeitė taip, kad savaitė lieka atmesta, kol egzistuoja bent vienas gyvas atmestas įrašas, o projekto administratorius gali archyvuoti atmestą įrašą tik tada, jei jį atmetė pats. Duomenų bazės zondas dabar paleidžia kiekvieną iš šių atvejų, ir kiekvienas turi baigtis PASS. **Kaip patikrinti savo įrankį:** naudokite du tvirtintojus vienai savaitei. Kaip pirmasis atmeskite vieną įrašą, kaip antrasis patvirtinkite visa kita ir pažiūrėkite, kokios būsenos savaitė baigiasi. ## Pirkti ar kurti darbo laiko apskaitą audito įmonei? Pirmiausia pirkite. Toggl, BigTime, ZenWorkflow ir panašūs įrankiai jau apima laikmačius, savaitės patvirtinimus ir sąskaitų klientams išrašymą, ir su jais galite pradėti jau šią savaitę. Savo įrankis prasmingas, kai įmonė turi taisyklių, kurių produktai neišreiškia, pavyzdžiui, konfidencialius klientus, matomus tik nurodytiems nariams, savaitės tvirtinimą keliais projektų administratoriais arba roles, kurias savininkas nori formuoti langelis po langelio. Kad ir kuriuo keliu eitumėte, aukščiau aprašytos keturios patikros užima popietę ir pasako daugiau nei funkcijų sąrašas. Kiekvienas produkto puslapis žada „detalius leidimus“. Retas parodo, kas nutinka nuėmus varnelę. ## Šios ataskaitos ribos - **Viena įmonė.** Prieigos modelis, maždaug 70 įrašų per savaitę apimtis ir klausimynas yra iš vienos įmonės. - **1 klaida buvo pagauta, kol dar nesuveikė.** Lapkričio vidurio data yra prognozė pagal įmonės įrašų tempą, o ne išmatuotas incidentas. - **Jokių sąskaitų.** Įrankis laiko valandas, atsiskaitymo būdą ir valandų biudžetus, bet klientų neapskaito sąskaitomis, todėl negaliu pasakyti nieko apie srautus nuo laiko iki sąskaitos. Prieigos taisyklės čia yra Postgres row-level security. Dvi spragos, kurių rolių matrica nepagauna, aprašytos atskirai: [vartotojas, priklausantis dviem organizacijoms](https://madsalt.tech/lt/notes/supabase-rls-user-in-two-organizations/) ir [IF, kuris esant NULL praleidžia patikrą](https://madsalt.tech/lt/notes/plpgsql-if-not-null-fails-open/). Pati kūrimo eiga aprašyta [audito įmonės darbo laiko apskaitos atvejyje](https://madsalt.tech/lt/work/audit-firm-time-tracking/), o tokio pobūdžio darbas patenka į [vidinius įrankius ir skydelius](https://madsalt.tech/lt/services/internal-tools-dashboards/). Renkatės ar kuriate darbo laiko apskaitą savo įmonei? Mielai palyginsiu patirtį dėl prieigos taisyklių ir patvirtinimų. Be pardavimo. [Susisiekti](https://madsalt.tech/lt/#contact)