| Kontrola knjižb na decimalna mesta (dovoljeno največ 2 decimalni mesti) |
Bodisi zaradi napake v delovanju programa v preteklih buildih bodisi zaradi uporabniških postopkov so lahko med knjižbami tudi takšne, ki so zapisane na več kot dve decimalni mesti. Takšne knjižbe se nato lahko npr. pojavijo med kandidati za obračun tečajnih razlik, obračunane tečajne razlike pa so tako majhne, da obračun pokaže vrednost 0,00. Kontrola omogoča tudi samodejno popravljanje takšnih knjižb. |
| Kontrola zneska v Debit ali Kredit – označimo tiste, kjer sta Debit in Kredit hkrati nič |
Odsotnost te kontrole v preteklih buildih in različicah programa Pantheon (npr. 5.0) je omogočila, da se med knjižbami lahko nahajajo tudi take, kjer je debet in kredit hkrati 0). Takšne knjižbe moramo ročno popraviti (zbrisati ali pa vnesti debit oz. kredit). |
| Kontrola razlike med zneski debit/kredit in deviznimi debit/kredit zneski v primeru primarne valute |
Zaradi napake v programu ali uporabniških postopkih so lahko nastale knjižbe, kjer sta debet in valutni debet ali kredit in valutni kredit enaka, tečaj pa različen od 1. Zaradi takšnih knjižb lahko pride do napačnega preračuna odprtih saldakontnih knjižb na otvoritveno temeljnico! Kontola omogoča samodejno popravljanje takšnih knjižb. |
| Kontrola na nesaldirane konte |
Kontola poišče knjižbe, ki bi morale glede na nastavitev konta v scenariju oz. kontnem načrtu saldirane (debet – kredit = 0) oz. je v scenariju oz. kontnem načrtu označeno, da mora imeti konto obvezno saldo 0. |
| Kontrola referenčne integritete |
Kontrola preveri, ali obstajajo v kontnem načrtu konto, protikonto, subjekt, oddelek, stroškovni nosilec in valuta, ki so na pozicijah temeljnice, torej če imamo npr. v šifrantu stroškovnih nosilcev stroškovni nosilec, ki je na temeljnici itd. Kontrola omogoča tudi samo dejno popravljanje.
Kontrola referenčne integritete (orodje za to je v Administratorski konzoli) omogoča, da program resnično pravilno deluje ter da vsi obračuni in pregledi zajamejo res prave podatke. Opozarja uporabnika, da niso vzpostavljene vse relacije v podatkovni bazi, ki omogočajo pravilno delovanje programa.
|
| Kontrola ali obstajajo tečajne razlike |
Mnogo uporabnikov tečajne razlike knjiži »sumarno« ročno. Pri tem kot vezo na knjižbe vnašajo ponavadi neko interno oznako. Kontrola ob zaključku leta ali pa avtomatsko knjiženje tečajnih razlik v programu pa kljub ročno poknjiženim tečajnim razlikam takšne knjižbe še vedno prikazuje med kandidati za obračun tečajnih razlik. Pravilno ročno knjiženje tečajnih razlik bo na voljo v prihodnjih buildih, zato je zaenkrat potrebno avtomatsko obračunati tečajne razlike. In tudi ko bo dokončno omogočeno ročno knjiženje tečajnih razlik, bo pri tem potreno upoštevati ujemanje konta, subjekta, valute, primarne valute in veznega dokumenta, da bodo tečajne razlike pravino poknjižene. |
| Kontrola zneska v Debit ali Kredit |
Podobna kotrola, kot je kontrola 2. Tukaj moramo ročno popraviti knjižbe, kjer je hkrati debet in kredit različen od 0. |
| Kontrola zneska v Debit/Kredit vs devizni Debit/Kredit |
Označimo tiste kjer je Debit različen od nič in devizni kredit različen od nič in obratno
Podobna kontrola kot 2 in 7. Potrebno je ročno popraviti knjižbe.
|
| Kontrola datuma zapadlosti pove ali je kompenzacija zaključena ali ne |
Pri knjižbah nepotrjenih kompenzacij je datum zapadlosti prazen. Nepotrjene kompenzacije je pred zaključkom leta potrebno zbrisati in jih narediti ponovno po narejenem zaključku leta. |
| Kontrola presledkov (nepotrebnih) na koncu stolpcev |
Podatkovna baza, program in uporabniški postopki so omogočali (omogočajo) da se poleg podatka zapisujejo tudi presledki, ki mu sledijo. To povzroča anomalije pri zbiranju in prikazovanju podatkov, npr. nepotrebne razmike pri izpisu konto kartice itd. Kontrola omogoča tudi samodejno brisanje teh odvečnih presledkov.
Ob kreiranju zaključka leta se avtomatsko kreira tudi dokument za naslednji zaključek leta, ki ima datum od 1.1. tekočega leta do 31.12. tekočega leta. Kontrole lahko izkoristimo za kontrolo podatkov tekočega leta, ne da bi naredili zaključek leta. Možnost avtomatskega popravljanja napak nam tudi pri tekočem letu omogoča popravek napak.
|
| Kontrola ali obstaja konto v scenariju – knjižba obstaja |
Morda uporabnik nov dokument za zaključek leta odpre predhodno, v vrsti dokumentov ima pa označeno, da scenarij ni usklajen s kontnim načrtom. Nato v kontni načrt vnese nov konto in ga uporabi pri knjiženju. Ob izdelavi zaključka leta ta konto ni v scenariju in ta kontrola na to opozori. Konto je v scenarij možno vnesti s klikom na gumb Pripravi scenarij-scenarij uskladi s kontnim načrtom. Ker s ponovno pripravo scenarija ponastavite trenutne nastavitve scenarije glede na nastavitve v kontnem planu, je priporočljivo nov konto dodati v scenarij preko zavihka Napake, kjer lahko z dvoklikom na kljukico v trenutno nastavljen scenarij dodate samo novi konto. |
| Kontrola ali obstaja tečaj na 31.12. v primeru deviznih knjižb |
Zaradi obračuna tečajnih razlik za odprte postavke je potrebno, da so v šifrant vneseni tečaji na Datum do za vse različne valute deviznih knjižb. Tečaje je potrebno vnesti ročno ali prenesti z interneta. |
| Kontrola konta s skladnostjo oznak saldakontni konto med kontnim načrtom in AK |
Večina uporabnikov ima v AK vnešene konte dobaviteljev in kupcev, v kontnem načrtu in scenariju pa, da ne gre za saldakonto in da subjekt ni obvezen podatek. Zaradi tega se lahko zgodi, da se bo knjižba na zaključno in otvoritveno temeljnico zapisala v sumarnem znesku in ne po subjektih in veznih dokumentih. Zaradi tega zapiranje odprtih postavk v naslednjem poslovnem letu ne bo možno. Ta kontrola na to opozori in tako omogoči, da ročno popravimo nastavitve v kontnem načrtu oz. scenariju. |
| Kontrola knjižb, če je morda kateri od ključev narobe ali pomanjkljivo zapisan |
Program najde “čudne” zapise, npr. 10- -000001, ipd. Te zapisi v programu niso vidni (niso upoštevani pri izpisih bruto bilanc, odprtih postavk itd.), nastali so verjetno zaradi napake. |
| Kontrola knjižb, ki niso vključene v zaključek leta. V prvi zaključek leta morajo biti vključene vse knjižbe od začetka poslovanja oz. uvedbe EUR |
Če uporabnik dela že od pred leta 2007, mora biti prvi zaključek za več let skupaj (2007 – 2011, če gre za prvi zaključek leta). |
| 16. Kontrola vnosa tečajev za primarno valuto. Tečaji za primarno valuto morajo biti vnešeni v tečajno listo |
Vnešeni morajo biti tečaji za EUR na 1.1.2007 = 1. |
| 17. Kontrola knjižb, pri katerih je valuta prazna. Zaradi takšnih knjižb lahko nastaopijo težave pri določenih izpisih. |
Kontrola nastala zaradi napake v programu, ko je nekaterim nekatere knjižbe zapisalo s prazno vrednostjo valute. |
| Kontrola knjižb, kjer je znesek v primarni valuti pomnoženo/deljeno s tečajem različen od devizne knjižbe |
Program preračune zneske v primarni valuti glede na vneseni tečaj v devizno valuto. V primeru nepravilne vrednosti v devizni valuti javi napako. knjižbe je možno avtomatsko popraviti |
| 21. Kontrola preveri, ali so v tečajno listo vnešeni tečaji s tečajem 0. Zaradi takšnih tečajev zaključek leta morda ne bo narejen pravilno |
Kontrola preveri, če je v tečajnico vnešen tečaj z vrednostjo 0. Če je za valuto vnešen tečaj 0, zaključek leta ne bo narejen pravilno. |