Programi za knjigovodstvo – ispravljanje i brisanje unetih podataka
Za temu današnjeg članka odabrao sam da sa vama podelim svoja razmišljanja o jednoj nezaobilaznoj temi u vezi programa za knjigovodstvo, a to je: mogućnost ispravljanja i brisanja unetih podataka.
Programska rešenja implementirana u programima za knjigovodstvo variraju od potpune zabrane do potpune dozvole ispravljanja, što samo svedoči o tome koliko je ovaj aspekt programa za knjigovodstvo bitan i autorima i korisnicima.
Ja lično razlikujem četiri različita pristupa ovom pitanju koja su upravo predmet ovog članka.
1. Sve po zakonu
Član 8. Zakona o računovodstvu i reviziji je jedini član koji definiše šta računovodstveni programi moraju da ispune da bi bili u skladu sa zakonom
“Pravno lice i preduzetnik koji vrši obradu podataka na računaru dužan je da koristi standardni računovodstveni softver koji omogućava funkcionisanje sistema internih računovodstvenih kontrola i onemogućava brisanje proknjiženih poslovnih promena.”
Dakle, po Zakonu, jedan je jedini atribut koji knjigovodstveni program treba da ispuni, a to je da onemogući brisanje i izmenu podataka. Ako se zakon tako eksplicitno odnosi ka tome, postavlja se pitanje smislenosti dalje diskusije na ovu temu jer izgleda očigledno da brisanja/izmeni ne sme biti, zar ne?
Za većinu firmi zastupljenih na našim prostorima duži niz godina, diskusija je zaista tim članom i završena:
“Brisanja i ispravki nema i zbog zakona i zbog samih korisnika.”
Na Lidder sajtu postoji odličan tekst pod nazivom Brisanje podataka je obavezna mogućnost… u zonskoj B ligi. koje na maestralan način predstavlja argumente u korist ovog stava, a koji se, grubo svedeno, svode na to da je jedini pravi ozbiljan profesionalni pristup koji je u najboljem interesu i autora i samog korisnika pristup koji ne dozvoljava nikakvo brisanje/izmenu podataka jer se na taj način postiže integritet podataka uz poštovanje svih propisa. Da ne dužim o voj grupi više, kliknite na link gore i pročitajte tekst, ja vas čekam ovde dok ne završite….
2. Može sve
Za razliku od stava većine velikih programa, mnoštvo malih programa na našem tržištu nude “brisanje, otknjižavanje, odčekiranje, menjanje, reknjiženje, ponovna potvrda”. Drugim rečima, brisanje i izmena podataka su potpuno dozvoljeni,
Autori programa iz ove grupacije baziraju tu odluku na sledećim principima:
-
Svaki potencijalni korisnik im traži da prepravi pogrešno unete podatke – “bez toga ti nema prodaje garant”
-
Program se prodaje samo lično poznatim ljudima – “ako ste sami, vi ukucajte ovu šifru, a ako dođu štrumfovi vi dodajte 01 na kraju i sve će biti u redu”
-
Ne postoji standard ni sertifikaciono telo – “ko će ikad i kako da kontroliše to”
-
Korisnicima integritet podataka nije od primarnog značaja jer imaju sveske, teftere, knjige i sl. gde olovkom upisuju “stvarno stanje”, te im je OK papazjanija od podataka u programu – “to ionako knjigovođa moj ima kod sebe ispravljeno”
Sad vi garant očekujete bezrezervnu osudu i ograđivanje od ovakvih korisnika, programera i programa.
I čekate i čekate…
Uzalud čekate – neću biti ovde potpuni licemer pa da se pravim da za svojih 15-tak godina profesionalnog programiranja nikad nisam radio takve stvari. Kada ste mali programer koji tek počinje radeći programe za “svoj komšiluk” ne možete sebi da priuštite gnušanje nad tim zahtevima kao što veliki programi mogu iz prostog razloga što nemate stotine korisnika već 4 od čijih para sastavljate kraj sa krajem svakog meseca. Realno, baš to što ste voljni da udovoljavate tim nebuloznim zahtevima korisnika je njega i nagnalo da dođe do vaših vrata i rizikuje sa vašim neproverenim programom.
(Hvala Dinkiću za PDV i fiskalne kase jer verujem da nema više toliko ovakvih zahteva od strane korisnika.)
Razumem i te korisnike koji to traže, jer time što im program postavlja prestroga ograničenja sputava se njihova produktivnost. Svakome se desi da tek kad odštampa fakturu preda kupcu na potpis, taj korisnik primeti da je na njoj pogrešna stavka i slični scenariji. Stornirati celu fakturu pa unositi ponovo može da bude jako naporno. Stornirati deo fakture u cilju korigovanja pogrešnih stavki takođe može biti naporno. Sve što korisnik želi od svog programa je da mu omogući da sa što manje utrošenog vremena i rad obavi to što je naumio, a previše rigidan program definitvno može da bude smetnja u tome.
Da li to znači da sam idejno pobornik ove “može sve” grupe?
Apsolutno ne!
Posle svih ovih godina shvatio sam da je dati korisniku program koji može sve identično davanju napunjenog pištolja detetu – pre ili kasnije će neminovno doći do scene iz Taličnog Toma sa metkom slučajno ispaljenim u sopstveno stopalo. Papazjanija se pre ili kasnije se obije o glavu svima.
3. Može sve (dok je sve po zakonu)
Treća grupa programa pristupa ovom problemu brisanja/izmene podataka u knjigovodstvenim programima na kreativan način pokušavajući da zauzme srednji put između ova dva rešenja i omogući korisniku – “zakonsko brisanje”.
Logika ovih programa za knjigovodstvo se uglavnom bazira na tome da je u pomenutom članu 8. Zakona o računovodstvu eksplicitno navedeno da treba onemogućiti brisanje “proknjiženih poslovnih promena”. Po toj logici, sve dok određeni dokument nije proknjižen, zakon dozvoljava brisanje/ispravke unetih podataka.
Postavlja se naravno pitanje, koliki je maksimalni zakonom propisani vremenski period u kome je dozvoljeno neproknjižiti poslovnu promenu.
Sudeći po članu 11 istog Zakona o Računovodstvu radi se o maksimalno 4 dana: 3 dana za dostavu dokumenata na osnovu kojih se knjiži računovodstvu i jedan dan za samo knjiženje tako dostavljenih dokumenata. U eri računara ova odredba je po meni apsolutno nebulozna odredba, ali to je zasebna priča…
Elem, na osnovu navedenog tumačenja programi iz ove grupe sve unete dokumente smatraju “nelikvidiranim” i dok su u tom stanju korisnik može da ih menja koliko god želi. Unutar programa obično postoji deo koji likvidira dokumente pojedinačno/grupno, ad hoc/u intervalima, automatski/ručno.. Jednom likvidirani dokument je nemoguće menjati.
Suštinski vrednosni predlog ovog rešenja je dakle:
-
autor programa i korisnik ne krše zakon
-
korisnik može da menja dokumente
-
korisnik sam određuje vremenski interval u kome mu je potrebno da dokumenta budu u otključanom stanju.
-
podela posla između korisnika i knjigovođe gde dokument likvidira knjigovođa vršeći finalnu proveru unetih podataka
Zvuči savršeno, zar ne? Da li to znači da sam ja u “može sve dok je po zakonu” grupi?
Na žalost, ne.
Iako je ovo je rešenje po meni mnogo bolje od prethodna dva, rezultuje sa nekoliko novih problema.
Prvi problem se sastoji u tome kako program tretira podatke nelikvidiranog dokumenta.
Uzmimo za primer neku prodavnicu koja na stanju ima 2 Milka čokolade po prodajnoj ceni od 10 dinara. Ukucava se nova prijemnica na kojoj je jedna stavka koja ima 5 Milka čokoladi po nabavnoj ceni od 11 dinara. Prijemnica nije likvidirana nego se likvidira na kraju dana od strane knjigovođe.Dolazi kupac koji želi da kupi 3 čokolade.
Da li dozvoliti prodaju količine koja uključuje i količine sa nelikvidirane prijemnice? Kako odraditi nivelaciju Milka čokoladi na novu cenu koja reflektuje novu nabavnu cenu kada ulazni dokument još nije likvidiran? Na koju količinu se niveliše?
Sumirano: vremenski disparitet materijalnog i finansijskog stanja može da rezultuje problemima po korisnika – još jedan pištolj dat detetu.
Drugi manje bitan problem se svodi na to da dodatni korak likvidiranja može korisnicima koje to ne zanima da bude na teretu. Takođe, šta ako se zaboravi da se likvidira u toku ta 4 dana?
Po mom mišljenju, ovo rešenje je realno primenljivo, ali suboptimalno po krajnjeg korisnika jer unosi određenu dozu komplikovanja poslovnih procesa.
4. Advokat
Da budem odmah iskren i kažem da iako sam ja lično odabrao ovaj pristup problemu brisanja nisam video nijedan program koji ga implementira.
Implementaciono govoreći, moje rešenje naginje rešenjima iz prve grupe u smislu da se striktno drži zakona bez “rastezanja članova” bez korišćenja zakonski dozvoljenih štosova za “odloženo vremensko zaključavanje” dokumenta. Korisnik se na taj način lišava negativnih nuspojava dispariteta materijalnog i finansijskog.
A šta je sa korisnikom? Zar se nisam gore izjasnio da ih razumem u želji da imaju produktivno okruženje?
Zar ja sam na svom blogu nisam mnogo puta rekao da mi je interes korisnika uvek na prvom mestu?
Naravno da mi je stalo do korisnika.
Ovo što sam gore naveo se odnosi na implementacionu suštinu, ali se ne odnosi na percipiranu formu koju korisnik sreće. Da pojasnim malo ovaj stav na prostom primeru.
Korisnik-prodavac unese račun sa 10 Milka čokoladi (izgleda da mi je pao šećer kad mi se samo čokolade motaju po glavi 
) i klikne na Snimi dugme. Istog momenta kada je račun snimljen on je i likvidiran i snimljen. Balans finansijskog i materijalnog je samim tim uvek očuvan.
Kupac se požali i kaže da je hteo 12, a ne 10 čokoladi.
Korisnik-prodavac otvori račun i ISPRAVI količinu sa 10 na 12 komada. Što se korisnika-prodavca tiče, njegov program ima “neograničenu” mogućnost direktnog ispravljanja.
Ispod haube, moj program kreira odgovarajuće vezane korektivne dokumente koji materijalno i finansijsko stanje koriguju na željene vrednosti. Kada korisnik sledeći put otvori pomenuti račun, program je u stanju da pronađe originalni i korektivne vezane dokumente i opet prikazuje korisniku samo “krajnje stanje”.
Da li korisnik vidi te vezane dokumente?
U većini slučajeva ne iz prostog razloga što ih većinu njih u većini slučajeva to uopšte ne zanima to.
Onima koje to zanima (npr. knjigovođa) naravno se ponudi detaljan uvid u sve vezane dokumente “kakvi jesu”.
Kao što advokat pomaže svom klijentu poštovanje kompleksnog zakona, tako i moj program pomaže korisniku da u potpunosti ispoštuje zakon bez negativnih posledica po njegovu produktivnost i efikasnost rada.
Zaključak
Pre nego što zaključam za promene ovaj post da sumiram iznešeno…
Izneo sam podelu programa za knjigovodstvo po kriterijumu tretiranja brisanja/izmene podataka. Ta klasifikacija je obuhvatila rešenja koja se striktno drže zakona sa ili bez korisničke fasade, ne obaziru na zakon i rešenja koja elastično tumače zakon. Kao i uvek, ne tvrdim da je ta klasifikacija univerzalno tačna i slično, samo je odraz mojih ličnih shvatanja koja sam želeo da podelim sa vama.
Da li se slažete sa mojim izborom Advokat pristupa kao najboljeg? Da li sam propustio da spomenem neku grupu? Kojoj grupi pripada program koji trenutno koristite?
30. oktobra 1974-e u Zairu se odigrao jedan od najboljih boks mečeva između aktuelnog svetskog šampiona Džordža Formena i Muhamed Alija – “
Tradicionalno u segmentu poslovnih (eng. enterprise) aplikacija vlada nepisano pravilo “Features sell” što grubo prevedeno označava da je uspešnost prodaje poslovnog softvera direktno proporcionalno broju dodatnih osobina i funkcija koje on ima u poređenju sa konkurentskim programima.
Najveći problem u pravljenju poslovnih aplikacija je u tome da ih prave programeri, a ne sami korisnici. Kada to kažem naravno da ne mislim da su programeri glupe i nesposobne individue, naprotiv spadaju u društveni vrh po tom pitanju. Ono na šta mislim je da su po definiciji programeri ljudi tehničke edukacije ili bar “skloni tehnici” i kao takvi fokusirani na implementacino–tehničke aspekte programa.
Borgovi su rasa u 
Moj prvi koncert Rolling Stons-a je bio 2005-e gde moram da priznam sam otišao bez da sam ih ikad slušao, kao i na more drugih koncerta – “nemam pametnija posla”. Otiso u 3 popodne, 90+ hiljada ljudi stoje na letnjem suncu već i slušaju neku UK bend koji ono OK svira pa neka češka slavna grupa i tako sve do 9 sati uveče kada se nebo smrči najednom, krene strašno da seva i žestok pljusak se sruči na stadion. Kiša pada 10-tak minuta, grmi i dalje, niko iz publike ni makac. Samo spontani huk kreće:“Rollingstones! Rollingstones!”, svetla se gase, prvi rifovi Satisfaction-a kreću, svetla se pale, Jegger sa bendom izlazi van zastora i svi sviraju pesmu na kiši namerno. Publika u delirijumu, a koncert ni 5 minuta nije trajao.
