web-aplikacija za voĐenje financijskog raČunovodstva
TRANSCRIPT
SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
DIPLOMSKI RAD br. 1258
WEB-APLIKACIJA ZA VOĐENJE FINANCIJSKOG RAČUNOVODSTVA
Petra Domitrović
Zagreb, lipanj 2016.
Sadržaj
1. Uvod ................................................................................................................. 1
2. Poslovni procesi ............................................................................................... 3
3. Model baze podataka ..................................................................................... 12
4. Tehnologija ..................................................................................................... 21
4.1 Usporedba: Oracle Application Express, Oracle Application
Development Framework i Oracle Forms ................................................ 27
4.2 Izvještaji u Jasperu .................................................................................. 32
5. Implementacija ............................................................................................... 34
6. Iskustvo razvoja u Oracle Application Expressu ............................................. 45
7. Zaključak ........................................................................................................ 48
8. Literatura ........................................................................................................ 50
9. Sažetak .......................................................................................................... 52
1
1. Uvod
Računovodstvo je iznimno stara disciplina čiji korijeni sežu još u doba
Mezopotamije (više od 7000 g.pr.Kr.), što dokazuju pronađeni dokumenti iz tog
razdoblja s popisom troškova i prodane ili kupljene robe. Danas je fokus
računovodstva uglavnom na novcu, iako su jednostavni računovodstveni sustavi
razvijeni tisućama godina prije nego što je iskovan prvi novac (u 7. st.pr.Kr.).
U moderno doba računovodstvo podrazumijeva opisivanje, mjerenje i tumačenje
ekonomskih aktivnosti nekog poslovnog subjekta, a uključuje:
računovodstveno planiranje,
knjigovodstvo,
računovodstvenu kontrolu,
računovodstvenu analizu i
računovodstveno informiranje.
S obzirom na to da je regulatorni okvir učinio računovodstvo obaveznom
komponentom poslovanja svakog poslovnog subjekta, bez obzira na njihovu
veličinu i opseg poslovanja, došlo je do pojave računovodstva kao usluge. Tj.
pojavili su se poslovni subjekti koji svoje poslovanje temelje na obavljanju
računovodstvenih usluga za druge poslovne subjekte. Poslovni subjekti koji nude
računovodstvene usluge nazivaju se računovodstveni servisi. Klijenti
računovodstvenog servisa najčešće su mikro i mali poduzetnici1 ili obrtnici2, tako
da jedan zaposlenik servisa može biti zadužen za više od jednog klijenta.
Informatizacija računovodstvenih sustava dobrodošla je pojava, pogotovo u
računovodstvenim servisima, gdje je, osim ažurnosti i preciznosti koju zahtijeva
sama struka, potrebna dodatna urednost u radu kako bi se ostvario paralelni rad s
više klijenata bez povećanja broja pogrešaka. Od informatizacije se zahtijeva da
1 Poduzetnikom se, u okviru Zakona o računovodstvu, smatra trgovačko društvo i trgovac pojedinac određeni propisima kojima se opisuju trgovačka društva. Poduzetnici se razvrstavaju na mikro, male, srednje i velike poduzetnike prema iznosu ukupne aktive, iznosu prihoda i prosječnom broju radnika tijekom poslovne godine. (Zakon o računovodstvu, 2016.) 2 Obrtnik je, po Zakonu o obrtu, definiran kao fizička osoba koja obavlja gospodarsku djelatnost sa svrhom postizanja dohotka ili dobiti. (Zakon o obrtu, 2013.)
2
ubrza rad zaposlenika u računovodstvu, smanji vjerojatnost pogreške, te da
organizira procese i informacije u računovodstvu i za one koji se bave unosom
informacija, kao i za one koji su krajnji korisnici izvještaja koji se temelje na tim
informacijama.
Web-aplikacija za vođenje financijskog računovodstva namijenjena je
računovodstvenim servisima. Cilj je napraviti aplikaciju koja strukturirano
implementira sve poslovne procese, ali je jednostavna za rad, te, ukoliko je
moguće, automatizira unos povezanih podataka, ili barem omogućuje da se unose
na jednom mjestu.
Oracle Application Express, koji je korišten pri razvoju aplikacije, je alat za brzi
razvoj aplikacija (eng. Rapid Application Development - RAD) na temelju
postojeće baze podataka. Rezultantne aplikacije su web-aplikacije tankog klijenta.
Za pokretanje aplikacije na klijentu dovoljan je samo internet preglednik.
3
2. Poslovni procesi
S obzirom na dijelove poslovanja koje obuhvaćaju i korisnike kojima su
namijenjeni rezultati, razlikujemo tri vrste računovodstva:
financijsko računovodstvo (računovodstveni sustav koji osigurava
kvantitativne informacije potrebne za sastavljanje financijskih izvještaja za
eksterne korisnike),
upravljačko računovodstvo (računovodstveni sustav koji osigurava
kvantitativne informacije potrebne menadžerima u procesu planiranja i
kontrole), te
računovodstvo troškova (sustav koji obuhvaća dio upravljačkog
računovodstva, jer kao rezultat daje informacije potrebne za planiranje i
kontrolu, i dio financijskog računovodstva, jer utvrđuje troškove proizvoda).
(Perkušić, 2014.)
Od navedene tri vrste računovodstva, samo je financijsko računovodstvo
formalizirano i propisano zakonom, dok su preostale dvije vrste proizvoljno
definirane internim pravilnicima poslovnih subjekata.
Financijsko računovodstvo u Republici Hrvatskoj definirano je:
Zakonom o računovodstvu,
Međunarodnim računovodstvenim standardima i Međunarodnim
standardima financijskog izvješćivanja,
Hrvatskim standardima financijskog izvješćivanja i
Računovodstvenim politikama.
Na računovodstveni sustav utječu i porezni zakoni (Zakon o porezu na dobit,
Zakon o porezu na dohodak, itd.), Zakon o trgovačkim društvima, Zakon o reviziji i
drugi. (Belak, 2005.)
U Hrvatskoj postoje četiri računovodstvena sustava:
Računovodstvo poduzetnika,
Računovodstvo neprofitnih organizacija,
4
Računovodstvo proračuna i proračunskih korisnika,
Računovodstvo obrtnika i slobodnih zanimanja. (Perkušić, 2014.)
Prema Državnom zavodu za statistiku u Republici Hrvatskoj je 31. prosinca 2014.
godine bilo aktivno 142.121 trgovačko društvo, te 80.911 subjekata u obrtu i
slobodnim zanimanjima. (Priopćenje DZS, 2014.) Prema tome, daleko je
najrasprostranjeniji sustav računovodstva poduzetnika u Hrvatskoj. Tako i u
knjigovodstvenim servisima većina klijenata pripada kategoriji poduzetnika.
Prema Zakonu o računovodstvu, koji se odnosi na računovodstvo poduzetnika,
“računovodstveni poslovi su prikupljanje i obrada podataka na temelju
knjigovodstvenih isprava, priprema i vođenje poslovnih knjiga, priprema i
sastavljanje godišnjih financijskih izvješća, te prikupljanje i obrada podataka u vezi
s pripremom i sastavljanjem godišnjeg izvješća, te financijskih podataka za
statističke, porezne i druge potrebe”. (Zakon o računovodstvu, 2016.)
Knjigovodstvene isprave čine izvorni dokumenti na temelju kojih se popunjavaju
poslovne knjige, te same poslovne knjige. Među poslovne knjige ubrajamo:
dnevnik knjiženja - poslovna knjiga u koju se zapisi unose kronološki, a
bilježi sve knjigovodstvene promjene nastale u određenom razdoblju,
glavnu knjigu - sustavna evidencija svih knjigovodstvenih promjena nastalih
na financijskom položaju i uspješnosti poslovanja u određenom
izvještajnom razdoblju. Događaji se grupiraju prema vrsti, na temelju
kontnog plana.
pomoćne knjige - nadopunjuju podatke o poziciji glavne knjige; knjige
ulaznih i izlaznih računa, analitičke evidencije i sl. (Belak, 2005.)
Poslovne knjige se u računovodstvu poduzetnika vode po načelu sustava dvojnog
knjigovodstva. Dvojno knjigovodstvo je sustav vođenja poslovnih knjiga tako da se
svaka transakcija bilježi kroz minimalno dvije stavke, od kojih je uvijek barem
jedna na dugovnoj, te barem jedna na potražnoj strani. Zbroj zapisa na dugovnoj
strani uvijek mora biti jednak zbroju zapisa na potražnoj strani. Ovaj
računovodstveni sustav proizlazi iz činjenice da se svako kretanje imovine odvija u
dva smjera, tj. da pri svakom povećanju stavke imovine mora doći do smanjenja
neke druge stavke imovine ili do povećanja obveze.
5
Transakcije se najčešće u dvojnom knjigovodstvu razdvajaju na više od dvije
stavke, jer se raščlanjuju na detaljnije financijske događaje vezane uz različite šifre
konta (računa). Sve šifre konta i pripadajući financijski događaji u računovodstvu
jednog poduzetnika čine kontni (računski) plan. Takvo raščlanjivanje transakcija
na financijske događaje i vezanje uz šifre računskog plana omogućuje vrlo
detaljnu analizu poslovanja, a korisno je i za uočavanje pogrešaka pri isplatama i
uplatama. Od 1.1.2017. godine, prema Zakonu u računovodstvu, uvodi se
jedinstveni okvirni kontni plan koji će predstavljati osnovu kontnog plana svakog
poduzetnika. Do tada, svaki poduzetnik je slobodan koristiti kontni plan po
vlastitom izboru, iako postoji preporučeni kontni plan RRiF grupe (Računovodstvo,
revizija i financije, RRiF - plus d.o.o. i RRiF - Konzalting d.o.o., nakladničko-
konzultantska trgovačka društva).
Sudionici poslovnih procesa u računovodstvenom servisu su sljedeći:
klijent servisa – formalno je klijent servisa obrt ili trgovačko društvo, ali je u
praksi uvijek zastupljen fizičkom osobom u vidu vlasnika ili nekoga od
zaposlenika, koji zastupaju interese poslovnog subjekta,
računovođa – zaposlenik servisa. Jedan zaposlenik je zadužen za više od
jednog klijenta, ali je za jednog klijenta, osim u iznimnim slučajevima,
zadužen samo jedan zaposlenik,
državne službe – dio su procesa jer se za njih izrađuje većina izvještaja. Ne
sudjeluju fizički u procesu, osim u slučaju npr. financijske inspekcije.
Poslovni procesi u računovodstvenom servisu sadrže:
unos matičnih podataka novog klijenta,
unos kontnog plana za svakog klijenta,
unos vezanih subjekata (kupaca, dobavljača, banaka)
unos ili prijenos početnog stanja,
unos dokumenata u poslovne knjige,
izrada izvještaja,
završni obračun i zaključivanje poslovne godine.
Unos matičnih podataka klijenta je jednokratan proces, koji se dogodi kad novi
poduzetnik postane klijent servisa. Tada se za njega unose naziv, OIB (ili porezni
6
identifikator, npr. za strane državljane koji nemaju OIB), djelatnost, brojevi
telefona, e-mail adrese, bankovni računi i adrese (od kojih je jedna uvijek
primarna, za ispis na dokumentima). Kasnije se postojeći podaci samo
nadopunjuju i ažuriraju.
Unos kontnog plana novog klijenta također je jednokratan proces, osim ako dođe
do promjene zakona koja zahtjeva značajniju promjenu kontnog plana. Kontni plan
se određuje na temelju poslovanja klijenta, jer mora sadržavati konta (račune) za
sve vrste financijskih događaja koji se mogu dogoditi u poslovanju klijenta. Postoji
predloženi kontni plan RRiF grupe koji se može proširiti ili sažeti po potrebi svakog
klijenta.
Kontni plan je hijerarhijske strukture, koja se ostvaruje preko šifre konta. Osnovnih
10 klasa označava se brojevima od 0 do 9. Sva konta unutar neke klase na prvom
mjestu u šifri imaju broj klase, što ostavlja prostor za 10 skupina dvoznamenkaste
oznake unutar svake klase, te za 10 podskupina unutar svake od njih, itd. U praksi
se knjiži na konta koja su razrađena do najmanje 4-znamenkaste šifre, dok se
konta s 1- ili 2-znamenkastim šiframa koriste u izvještajima (npr. bilanca stanja).
Pri tome se iznosi vezani uz 4-znamenkasta konta (ili konta s više znamenaka) iz
neke skupine zbrajaju i taj zbroj čini stanje konta te skupine.
Konta mogu biti analitička, što znači da je u nekim izvještajima potrebno nad njima
provesti dodatnu analizu po vezanim subjektima. Na primjer, na konto dugovanja
prema dobavljačima se knjiže sva dugovanja, pa je pri analizi potrebno uzeti u
obzir vezu prema pojedinom dobavljaču. Kod neanalitičkih konta se u izvještaju za
taj konto prikazuje samo jedan redak s agregiranim podacima, dok se kod
analitičkih konta za svaki pojedini konto prikazuje onoliko redaka s agregiranim
podacima, koliko je različitih subjekata vezanih uz taj konto.
Unos vezanih subjekata obuhvaća unos svih kupaca, dobavljača i banaka uz
koje je vezano poslovanje dotičnog klijenta. Svaki vezani subjekt se unosi
zasebno. Više klijenata može biti povezano s istim vezanim subjektom i u tom
slučaju se vezani subjekt ne unosi dvaput, već se zapis dijeli, tj. nema svaki klijent
servisa skup „svojih“ vezanih subjekata. Vezani subjekt nekog klijenta i sam može
biti klijent istog računovodstvenog servisa. Za vezane subjekte se mogu unijeti
većinom isti matični podaci kao i za klijente servisa. Dokumenti u sustavu se po
7
potrebi (ovisno o tipu) vežu na zapise vezanih subjekata, kao i stavke glavne
knjige.
Početno stanje klijenta unosi se jednom u poslovnoj godini, obično na samom
početku godine, odmah po zaključivanju prethodne poslovne godine. Međutim, za
novog klijenta servisa se početno stanje ne može izračunati na temelju stanja u
prethodnoj godini, već se formira na temelju početnog kapitala ili, ako je klijent
novi u servisu, ali nije novi poduzetnik, na temelju bilance stanja u dosadašnjem
poslovanju. Početno stanje je vrsta temeljnice. U godini postoji maksimalno jedna
temeljnica te vrste, a sadrži po jedan zapis za svaki neanalitički konto na kojem je
knjižen neki iznos, te po jedan zapis analitičkog konta za svaki neisplaćeni račun
(ulazni ili izlazni).
Na prijelazu u sljedeću poslovnu godinu katkad se radi i parcijalni prijenos
početnog stanja iz prethodne godine i prije nego se ona službeno zaključi. Takav
postupak je potreban iz praktičnih razloga, jer poslovanje klijenta ne prestaje na
prijelazu godine, a završni obračun se najčešće ne provodi odmah, jer računovođa
ne dobije odmah sve odgovarajuće izvorne dokumente financijskih događaja koje
treba evidentirati u poslovnim knjigama poslovne godine koja je istekla. Parcijalni
prijenos početnog stanja uključuje samo prijenos analitičkih konta po svakom
neplaćenom računu za pojedine kupce i dobavljače (vezane subjekte), kako bi se
financijski događaji nove poslovne godine po potrebi mogli evidentirati. Parcijalni
prijenos se prepisuje punim prijenosom početnog stanja u trenutku kad se
završnim obračunom zaključi prethodna godina.
Unos dokumenata u poslovne knjige znači unos svakog ulaznog i izlaznog
računa, bankovnog izvoda, stanja blagajne, isplate plaća ili bilo kojeg drugog
događaja u glavnu knjigu i dnevnik knjiženja. Ulazni i izlazni računi se još unose u
pomoćne knjige ulaznih i izlaznih računa. Uz dokument su vezani podaci koji čine
zaglavlje, te niz zapisa koji raščlanjuju transakciju (ili više njih) iz dokumenta na
pojedinačna konta u glavnoj knjizi. Računi se za potrebe unosa u knjige ulaznih i
izlaznih računa raščlanjuju na različite iznose osnovica i poreza po stopama (5%,
13%, 25% poreza ili oslobođeno poreza po nekoj od ponuđenih osnova). Jedan
dokument iz kojeg proizlazi logički zaokružen skup zapisa u glavnoj knjizi općenito
se naziva temeljnica.
8
Postoje sljedeće vrste temeljnica (dokumenata):
početno stanje,
ulazni račun,
ulazni račun za stjecanje sredstava iz Europske Unije (pomoćna knjiga u
kojoj su evidentirani računi ove vrste sadrži dodatne iznose u odnosu na
„običnu“ knjigu ulaznih računa, stoga oni postoje kao zasebna vrsta
dokumenta),
izlazni račun,
bankovni izvod,
stanje blagajne,
isplata plaća,
opća temeljnica,
završni obračun.
Dokumenti se numeriraju i sortiraju unutar vrste kojoj pripadaju, ali se mogu unutar
vrste podijeliti u više knjiga, koje nemaju nikakvo dodatno logičko značenje, već
samo grupiraju dokumente radi bolje organizacije. Korisnici mogu sami dodavati
knjige za one vrste dokumenata koje podržavaju tu vrstu organizacije, a što je
promjenjivo i određuje se u dogovoru s korisnikom. Intuitivan primjer organizacije
dokumenata po knjigama su izvodi, koje je korisno razdvojiti na više knjiga ovisno
o tome iz koje su banke (jedan klijent može imati, i često ima, račune u više
banaka). Dokumentima se unutar vrste ili knjige kojoj pripadaju dodjeljuje redni
broj za tekuću poslovnu godinu.
U zaglavlju dokumenta se, osim vrste i knjige kojoj pripada, te rednog broja,
upisuju i:
datum dokumenta – za račune i izvode je to datum izdavanja, osim za
račune u slučaju kad se knjiže naknadno, nakon što je prošao rok za
predaju mjesečnog izvještaja za mjesec u kojem su nastali – tada je datum
unosa. Za sve ostale vrste dokumenata upisuje se datum unosa,
datum izdavanja i datum dospijeća računa,
broj računa – upisuje se samo za dokumente temeljene na računima, a
predstavlja identifikator samog računa koji mu je dodijelio sustav iz kojeg je
9
proizašao. Identifikator je jedinstven u sustavu koji ga je dodijelio, ali u
računovodstvenom sustavu mu je jedina uloga povezati dokument iz
sustava s izvornim računom,
veza na vezani subjekt – za izvode se unosi veza na banku koja je izdala
izvod, za račune kupac ili dobavljač koji je izdao račun ili mu je račun izdan i
slično,
valuta i tečaj prema kuni u omjeru 1:1 – najčešće će se unositi dokumenti u
kunama, tako da je pretpostavljena vrijednost za valutu HRK, a za tečaj 1,
međutim, za račun ispostavljen izvan Republike Hrvatske, unose se iznosi u
valuti računa, koji se onda preračunavaju po upisanom tečaju u kune,
ukupni iznos u upisanoj valuti i u kunama – unosi se iznos s računa ili
stanje izvoda, koje se onda preračunava u kune prema navedenom tečaju,
saldo računa u upisanoj valuti i u kunama – unosi se samo za račune, a
govori je li i u kojoj mjeri račun isplaćen. Pri unosu računa, saldo je jednak
ukupnom iznosu računa, a naknadno ubilježenim uplatama ili isplatama se
taj iznos smanjuje dok cijeli račun ne bude isplaćen. Uplate i isplate se
bilježe pri unosu bankovnog izvoda,
saldo dokumenta – podatak koji prikazuje razliku između dugovne i
potražne strane zapisa u glavnoj knjizi. Prema pravilima dvojnog
knjigovodstva, svaki događaj se opisuje s barem jednim zapisom na
dugovnoj i barem jednim zapisom na potražnoj strani. Ako postoji razlika
između zbroja na jednoj i zbroja na drugoj strani, temeljnica nije u ravnoteži
i došlo je do pogreške u knjiženju.
Za svaki račun se ukupni iznos razlaže na iznose osnovica i poreza za pomoćne
knjige ulaznih i izlaznih računa. Trenutno su u Hrvatskoj propisane 3 stope poreza
na dodanu vrijednost (PDV): 5%, 13% i 25%, a postoje i kriteriji prema kojima se
neki iznos proglašava oslobođenim poreza. Za ulazne račune bilježe se osnovice
za svaku od 3 porezne stope i iznos koji je oslobođen poreza, dok se iznos poreza
po svakoj stopi razdvaja na pretporez koji se može odbiti i pretporez koji se ne
može odbiti od ukupnog iznosa poreza koji klijent ima obavezu platiti državi po
mjesečnom obračunu. Obveza se na kraju mjeseca obračunava po izlaznim
računima, ali ti računi su nastali na temelju prodaje roba ili usluga u koje su
uključeni roba i usluge koje je poduzetnik kupio od svojih dobavljača. To znači da
10
je poduzetnik na njih već platio porez u sklopu ukupnog iznosa koji mu je naplatio
njegov dobavljač. Porez koji je već plaćen u ulaznom računu, može se odbiti od
obveze na kraju mjeseca, ako je ulazni račun izdan u svrhu poslovanja. Za ulazne
račune za stjecanje iz Europske Unije se iznosi poreza istovremeno upisuju i kao
pretporez (koji se najčešće može odbiti) i kao obveza jer dolazi do prijenosa
porezne obveze iz inozemstva. Po tome se ulazni računi za stjecanje iz EU
razlikuju od ostalih ulaznih računa i tvore zasebnu kategoriju. Za izlazne račune se
iznos razdvaja na osnovice i poreze po stopama, ali se iznos koji je oslobođen od
poreza razdvaja na kriterije po kojima je neki dio tog iznosa oslobođen od poreza
(oslobođenje za isporuke dobara unutar Europske Unije, za obavljene usluge
unutar Europske Unije, oslobođenje na temelju tuzemnog prijenosa porezne
obveze, itd.).
Uz svaki se dokument veže skup zapisa u glavnoj knjizi. Za svaki zapis se, osim
veze na dokument kojem pripada, obavezno upisuje:
šifra konta iz kontnog plana,
veza na kupca ili dobavljača, ako je riječ o analitičkom kontu,
iznos na dugovnoj ili potražnoj strani,
datum unosa.
U slučaju knjiženja uplata ili isplata s bankovnog izvoda, odabire se ulazni ili
izlazni račun koji još nije zatvoren. Može se dogoditi da račun koji se zatvara ili
djelomično zatvara uplatom ili isplatom još nije knjižen; u tom slučaju se veza na
račun dodaje naknadno. Prilikom zatvaranja ili djelomičnog zatvaranja (naplate)
računa, potrebno je ažurirati saldo računa u zaglavlju dokumenta u kojem je
knjižen dotični račun.
Iz unesenih podataka se izrađuju izvještaji koji služe računovođi za kontrolu
vlastitog rada, poduzetniku za planiranje i analizu poslovanja, te financijskim
ustanovama kojima se izvještaji moraju predavati prema zakonu (npr. Porezna
uprava, Financijska agencija i slično) za naplatu poreza, kontrolu poslovanja i
statistiku. Neke vrste izvještaja se izrađuju proizvoljan broj puta u godini (npr.
kartice kupaca i dobavljača), neki se izrađuju na mjesečnoj razini (prijave poreza),
a neki za cijelu poslovnu godinu (godišnja bilanca stanja).
11
Na kraju svake poslovne godine unosi se posebna temeljnica završnog
obračuna kojom se zatvara poslovna godina. Nakon završnog obračuna,
završavaju sve aktivnosti vezane uz tu poslovnu godinu. Svi eventualni ispravci ili
naknadni događaji moraju se knjižiti u novu poslovnu godinu. Završni obračun
obično se događa krajem kalendarske godine ili početkom sljedeće, međutim,
može se provesti u bilo kojem trenutku, ako poduzetnik prekida poslovanje ili
jednostavno prestaje biti klijent računovodstvenog servisa. Završni obračun
balansira klase konta 4 i 7, koje se ne prenose u novu poslovnu godinu, tako da
konačna bilanca cijele godine bude u ravnoteži.
Dakle, procesi u računovodstvu nisu sami po sebi složeni, ali pokrivaju široki
spektar poslovnih (financijskih) događaja, što unosi veliki broj varijacija u sustav. S
različitim dokumentima i različitim poslovnim događajima se drugačije postupa, što
otežava informatizaciju sustava. Računalni sustav mora u pravoj mjeri kontrolirati
korisnika kako bi spriječio pojavu nekonzistentnosti i nelogičnosti kroz različite
računovodstvene dokumente, ali ne smije ograničavati korisnika u radu.
Informatizaciju je još teže provesti uzme li se u obzir činjenica da procesi u
računovodstvu nisu detaljno regulirani. Zakonom se propisuju samo rezultati u
vidu dokumenata koji se predaju državnim institucijama. Zato se sva programska
rješenja za knjigovodstvo donekle međusobno razlikuju u kontekstu procesa koji
korisnik mora slijediti u radu. Nadalje, samo računovodstvo, pa tako i
informatizacija istog, podložni su komplikacijama koje dolaze kao rezultat činjenice
da se računovodstvo bavi prošlošću, tj. da događaji ulaze u poslovne knjige i
računalni sustav tek neko vrijeme nakon što su se zapravo dogodili. Vremenska
razlika posljedica je ljudskog faktora i manjka globalne informatizacije, jer se
izvorni dokumenti (računi i bankovni izvodi) još uvijek pohranjuju u papirnatom
obliku, pa tako tek naknadno, kad ih klijent sam donese, fizički dolaze u ruke
računovođi koji ih onda može evidentirati.
12
3. Model baze podataka
Prema navedenim procesima računovodstva poduzetnika u računovodstvenom
servisu nastao je model baze podataka sa slike 3.1.
Slika 3.1 Relacijski model baze podataka
Glavni entitet u bazi podataka računovodstvenog servisa je sigurno klijent servisa,
jer se na njega vežu svi ostali podaci. S obzirom da se slični podaci pohranjuju i za
13
sve vezane subjekte, dio modela u kojem se pohranjuju matični podaci poopćen je
na sve subjekte, tj. stranke. Glavna relacija u kojoj se evidentiraju osnovni podaci
o klijentima servisa, te njihovim kupcima, dobavljačima i bankama, je relacija
STRANKA. Popis atributa s napomenama nalazi se u tablici 3.1. Uz primarni ključ,
obavezni su podaci: NAZIV, KLIJENT_SERVISA, te TIP_STRANKE_ID. Također je
obavezno popuniti ili OIB ili PDV_ID, no to ograničenje je ostvareno u aplikaciji.
Tablica 3.1 Atributi relacije STRANKA
STRANKA
STRANKA_ID primarni ključ, popunjava s okidačem iz globalne sekvence
NAZIV naziv poduzeća ili osobno ime
OIB osobni identifikacijski broj, imaju ga samo građani RH
PDV_ID porezni identifikator, koristi se u slučaju kad stranka nema OIB
KLIJENT_SERVISA zastavica (D/N),označava je li stranka klijent servisa ili ne
TIP_STRANKE_ID strani ključ na relaciju TIP_STRANKE
TIP_OBVEZNIKA_ID strani ključ na relaciju TIP_OBVEZNIKA
OBVEZNIK_PDV_ID strani ključ na relaciju OBVEZNIK_PDV
SIFRA_DJELATNOSTI strani ključ na relaciju DJELATNOST
Četiri spomenuta šifarnika na koje STRANKA ima strani ključ su vrlo jednostavni:
sastoje se od 2 atributa od kojih je jedan brojčani primarni ključ, a drugi naziv.
Relacija TIP_STRANKE popisuje kojeg sve tipa može biti stranka, npr. trgovačko
društvo, obrtnik, banka, fizička osoba, itd. Relacija TIP_OBVEZNIKA sadrži podatke
o tome je li stranka obveznik poreza na dohodak ili poreza na dobit, ili nije
obveznik poreza uopće. Šifarnik OBVEZNIK_PDV sadrži opise situacija u kojima
stranka nije u sustavu PDV-a ili plaća PDV po izdanom računu ili plaća PDV po
naplaćenom računu. S obzirom da je broj zapisa u sva tri šifarnika
jednoznamenkast, a podaci se jako rijetko mijenjaju, primarni ključevi se
popunjavaju ručno. Četvrti šifarnik koji opisuje stranku je DJELATNOST. Podaci u
14
ovom šifarniku su učitani iz obrasca Financijske agencije napravljenog u formatu
.XLS. Šifra djelatnosti čini primarni ključ, jer je jedinstvena za svaku djelatnost.
Nadalje, uz stranku se po principu „zaglavlje-stavke“ vežu i matični podaci o
adresama elektroničke pošte (relacija EMAIL), poštanskim adresama (relacija
ADRESA), bankovnim računima (relacija RACUN) i telefonskim brojevima (relacija
TELEFON), te općenite tekstualne napomene (relacija NAPOMENA).
Relacija EMAIL, osim primarnog ključa EMAIL_ID i stranog ključa STRANKA_ID na
tablicu STRANKA, sadrži i obavezno polje EMAIL, u koji se upisuje adresa
elektroničke pošte, te opcionalno alfanumeričko polje OSOBA u koje se mogu upisati
podaci o kontakt-osobi.
Relacija RACUN, osim primarnog ključa RACUN_ID, sadrži alfanumeričko polje IBAN,
te dva strana ključa na relaciju STRANKA: PODUZETNIK_ID je veza na zapis stranke
kojoj pripada račun, dok je BANKA_ID veza na zapis koji opisuje banku u kojoj je
račun otvoren.
Relacija TELEFON sadrži primarni ključ TELEFON_ID, strani ključ na relaciju STRANKA,
BROJ_TELEFONA, gdje se upisuje samo broj, bez pozivnog broja, jer se pozivni broj
mreže dohvaća iz zasebne tablice POZIVNI_BROJ preko stranog ključa, a pozivni
broj države iz tablice DRZAVA, također preko stranog ključa. Za broj telefona se
također mogu navesti podaci o kontakt-osobi u polje OSOBA.
Relacija POZIVNI_BROJ sadrži podatke o pozivnom broju mreže, županije ili slično,
a relacija DRZAVA sadrži popis država koji se koristi za upotpunjavanje podataka o
telefonskim brojevima i poštanskim adresama.
Poštanske adrese bilježe se u relaciji ADRESA, koja uz primarni ključ ADRESA_ID i
strani ključ na relaciju STRANKA, sadrži i polje za unos ulice i kućnog broja
ULICA_KBR, strani ključ na relaciju NASELJE i zastavicu PRIMARNA_ADR, koja ima
vrijednost „D“ ako se radi o primarnoj adresi. Uvijek je samo jedna adresa za neku
stranku primarna, što znači da se ona ispisuje na dokumentima kad je potrebno
ispisati adresu stranke. Aplikativno je riješeno da će uvijek, bez obzira na
dodavanje, izmjene i brisanje, jedna adresa biti primarna.
15
Relacija NASELJE je šifarnik s popisom svih mjesta, inicijalno samo u Republici
Hrvatskoj, koja imaju svoj poštanski broj. Sadrži primarni ključ, poštanski broj i
naziv mjesta, te vezu prema relaciji DRZAVA.
Relacija NAPOMENA je tablica koja služi za upis dodatnih napomena i podataka koji
se ne mogu drugačije, strukturirano upisati. Sastoji se od primarnog ključa,
stranog ključa na relaciju STRANKA i teksta napomene duljine do 2000 znakova.
Za stranke koje su klijenti servisa, po „otvaranju“ poslovne godine nastaje zapis u
tablici GODINA. Tablica sadrži primarni ključ, strani ključ relaciju STRANKA, atribut
GODINA te zastavicu STATUS, koja poprima vrijednost „A“, ako je godina aktivna,
odnosno „Z“, ako je zatvorena.
Dokumenti koji se knjiže kroz poslovnu godinu spremaju se u tablicu DOKUMENT,
najveću u bazi po broju atributa. Tablica 3.2 sadrži popis atributa s objašnjenjima.
Tablica 3.2 Atributi relacije DOKUMENT
DOKUMENT
DOKUMENT_ID primarni ključ, popunjava s okidačem iz globalne sekvence
GODINA_ID strani ključ na poslovnu godinu u relaciji GODINA
SIFRA_VRSTE_DOK strani ključ na šifarnik s vrstama dokumenata
KNJIGA_ID strani ključ na relaciju KNJIGA
PODUZETNIK_ID strani ključ na relaciju STRANKA, na zapis klijenta čiji je
dokument
BROJ_DOKUMENTA redni broj dokumenta unutar vrste ili knjige
BROJ_RACUNA identifikator računa prepisan s izvornog dokumenta
STRANKA_ID drugi strani ključ na relaciju STRANKA, na zapis vezanog
subjekta
DATUM_IZDAVANJA datum izdavanja računa ili izvoda
DATUM_DOSPIJEĆA datum dospijeća računa
DATUM_DOKUMENTA datum unosa, za račune najčešće datum izdavanja zbog
kronologije
VALUTA strani ključ na relaciju VALUTA, pretpostavljena vrijednost HRK
16
TECAJ vrijednost valute iz prethodnog atributa u odnosu na kunu u
omjeru 1:1, pretpostavljena vrijednost je 1
UKUPNI_IZNOS_VAL ukupni iznos računa, stanje izvoda i slično u odabranoj valuti
UKUPNI_IZNOS ukupni iznos računa, stanje izvoda i slično preračunato u HRK
prema upisanom tečaju
SALDO_RACUNA_VAL saldo računa u odabranoj valuti
SALDO_RACUNA saldo računa preračunat u HRK prema upisanom tečaju
SALDO_DOKUMENTA saldo temeljnice u glavnoj knjizi, kontrola točnosti knjiženja
ZAKLJUCAN zastavica (D/N), utječe na mogućnost uređivanja dokumenta i
zapisa pomoćnih knjiga
Strani ključ na relaciju KNJIGA se upisuje samo ako odabrana vrsta dokumenta
podržava razvrstavanje dokumenata u knjige. Atributi BROJ_RACUNA,
DATUM_DOSPIJEĆA, SALDO_RACUNA i SALDO_RACUNA_VAL popunjavaju se samo za
račune. Atributi koji sadrže saldo računa se ne popunjavaju direktno već se
njihovo stanje održava okidačima. Saldo računa sadržava iznos neplaćenog dijela
računa, tako da se okidačima smanjuje sa svakim knjiženjem naplate u glavnu
knjigu. Zastavica ZAKLJUCAN postavlja se pri generiranju izvještaja, kako se podaci
uključeni u izvještaj ne bi mogli naknadno mijenjati. Zastavica utječe na
mogućnost uređivanja zaglavlja dokumenta u relaciji DOKUMENT, ali i mogućnost
promjene podataka u pomoćnim knjigama ulaznih i izlaznih računa.
Spomenuto je da se stanje salda računa, u proizvoljnoj valuti i u kunama, održava
okidačima. Jedan od okidača postavljen je nad relacijom DOKUMENT, a drugi nad
relacijom GLAVNA_KNJIGA. Okidač nad tablicom DOKUMENT izvodi se na svaku
naredbu INSERT ili UPDATE, ako je vrsta kojoj dokument pripada račun (može biti
ulazni račun, ulazni račun za stjecanje iz EU i izlazni račun), a postavlja, odnosno
ažurira, saldo računa (također u kunama i odabranoj valuti) ovisno o ukupnom
iznosu u poljima UKUPNI_IZNOS i UKUPNI_IZNOS_VAL. Drugi okidač, na relaciji
GLAVNA_KNJIGA, pokreće se na svaku naredbu INSERT, UPDATE ili DELETE, a provodi
ažuriranje salda računa u relaciji DOKUMENT, ako zapis u glavnoj knjizi „zatvara“,
odnosno isplaćuje neki račun, što se određuje stranim ključem prema relaciji
DOKUMENT.
17
U relaciju KNJIGA zapisuju se sve knjige koje služe za organizaciju dokumenata.
Moguće je dodati samo knjige vezane uz vrstu dokumenta koja podržava
organizaciju po knjigama. Popis atributa s objašnjenjima nalazi se u tablici 3.3.
Tablica 3.3 Atributi relacije KNJIGA
KNJIGA
KNJIGA_ID primarni ključ, popunjava s okidačem iz globalne sekvence
STRANKA_ID strani ključ na relaciju STRANKA, veza na klijenta za kojeg se
knjiga vodi
GODINA_ID strani ključ na relaciju GODINA, veza na poslovnu godinu
SIFRA_VRSTE_DOK veza na šifarnik vrsta dokumenata
NAZIV naziv knjige
KUPAC_DOBAVLJAC_ID strani ključ na relaciju STRANKA, na zapis vezanog subjekta
Strani ključ KUPAC_DOBAVLJAC_ID nije obavezan, no ako se popuni, odabrana
vrijednost će se propagirati na atribut STRANKA_ID za sve dokumente smještene u
tu knjigu.
Relacija VALUTA je šifarnik valuta s osnovne tečajne liste Hrvatske narodne banke.
VRSTA_DOKUMENTA je također šifarnik, s popisom vrsta dokumenata koji postoje u
sustavu. Za svaku vrstu sadrži i podatak o tome podržava li vrsta dodatnu podjelu
dokumenata u knjige (zastavica IMA_KNJIGE s vrijednostima D i N), što utječe na
mogućnost unosa knjiga za tu vrstu u relaciju KNJIGA.
Pomoćne knjige ulaznih i izlaznih računa ostvarene su kroz dvije relacije, od kojih
jedna, TIP_IZNOSA, predstavlja šifarnik mogućih iznosa na koje treba raspisati
jedan račun, a druga relacija, IZNOS, predstavlja vezu između šifarnika i
dokumenta u relaciji DOKUMENT. Na taj način se u bazu pohranjuju samo oni iznosi
koji su različiti od nule. Na primjer, za ulazni račun se u knjigu ulaznih računa treba
upisati ukupan iznos poreza po svim stopama, ukupan iznos računa, iznos
osnovice oslobođene od poreza, iznosi triju osnovica za tri stope poreza, te se za
svaku stopu iznos poreza treba razdijeliti između iznosa pretporeza koji se može
18
odbiti od obveze na kraju mjeseca i iznosa pretporeza koji se ne može odbiti, što
je ukupno 12 iznosa. Slično vrijedi i za izlazne račune. S obzirom na prirodu
podataka i činjenicu da najčešće računi sadrže porez obračunat po jednoj stopi,
više od pola tih iznosa će biti jednako nuli. Kroz strukturu šifarnika tipova iznosa i
vezne relacije između šifarnika i dokumenta, spremaju se samo oni iznosi koji su
različiti od nule.
Dakle, u TIP_IZNOSA se nalazi lista mogućih iznosa za svaku pomoćnu knjigu.
Struktura tablice je navedena je u tablici 3.4.
Tablica 3.4 Atributi relacije TIP_IZNOSA
TIP_IZNOSA
TIP_IZNOSA_ID primarni ključ
OPIS opis iznosa
FAKTOR služi za izračunavanje poreza na temelju osnovice i obrnuto
AKTIVNO logičko brisanje zapisa uvedeno radi mogućih promjena stopa
poreza
SIFRA_VRSTE_DOK strani ključ na vrstu dokumenta za koju se tip iznosa
popunjava
Relacija IZNOS je, kao što je već rečeno, vezna tablica između relacija TIP_IZNOSA i
DOKUMENT, pa je zato vrlo jednostavna. Sadrži primarni ključ, dva strana ključa na
relacije koje povezuje, te sam iznos.
Relacija GLAVNA_KNJIGA služi za pohranjivanje zapisa glavne knjige, te čini
okosnicu rada sustava. U kombinaciji s relacijom DOKUMENT čini odnos „zaglavlje -
stavke“. Tablica 3.5 sadrži popis atributa u relaciji, te objašnjenja.
Tablica 3.5 Atributi relacije GLAVNA_KNJIGA
GLAVNA_KNJIGA
GLAVNA_KNJIGA_ID primarni ključ, popunjava s okidačem iz globalne sekvence
19
GODINA_ID strani ključ na poslovnu godinu u relaciji GODINA
PODUZETNIK_ID strani ključ na relaciju STRANKA svojstvu klijenta servisa
KONTNI_PLAN_ID strani ključ na relaciju KONTNI_PLAN
KUPAC_DOBAVLJAC drugi strani ključ na relaciju STRANKA u svojstvu vezanog
subjekta
MASTER_DOK_ID strani ključ na relaciju DOKUMENT, veza stavki prema
zaglavlju
DOKUMENT_ID drugi strani ključ na relaciju DOKUMENT, veza uplate na račun
koji se naplaćuje
DUGUJE dugovna strana glavne knjige, iznos u kunama
POTRAZUJE potražna strana glavne knjige, iznos u kunama
DUGUJE_VAL dugovna strana glavne knjige, iznos u valuti odabranoj u
zaglavlju u relaciji DOKUMENT
POTRAZUJE_VAL potražna strana glavne knjige, iznos u valuti odabranoj u
zaglavlju u relaciji DOKUMENT
DATUM_UNOSA datum unosa zapisa u glavnu knjige, najčešće jednak datumu
dokumenta u zaglavlju
OPIS prostor za dodatni opis ili napomenu
Strani ključ na relaciju GODINA u ovoj relaciji ima dodatno značenje. Zapisi u
glavnoj knjizi smiju se mijenjati sve do zaključenja poslovne godine, pa se preko
stranog ključa prema poslovnoj godini provjerava smiju li se zapisi u glavnoj knjizi
mijenjati. Za svaki zapis dodatno vrijedi da je, između dugovne i potražne strane,
jedna uvijek jednaka nuli, a druga veća od nule. Atribut KUPAC_DOBAVLJAC, tj.
referenca na vezani subjekt, se mora popuniti ukoliko je konto identificiran
atributom KONTNI_PLAN_ID analitički, jer se dodatna analiza provodi upravo na
temelju vezanih subjekata.
Relacija KONTNI_PLAN je šifarnik koji pohranjuje verzije kontnog plana za sve
klijente servisa, te inicijalni kontni plan koji nije vezan ni uz jednog klijenta, već
služi po potrebi za inicijalizaciju ili osvježavanje kontnog plana klijenta. Popis
atributa u relaciji nalazi se u tablici 3.6.
20
Tablica 3.5 Atributi relacije KONTNI_PLAN
KONTNI_PLAN
KONTNI_PLAN_ID primarni ključ, popunjava s okidačem iz globalne sekvence
STRANKA_ID strani ključ na klijenta servisa u relaciji STRANKA
SIFRA_KONTA brojčana oznaka konta na koju se knjiži
STRANA
opcionalan atribut koji je nastao kao rezultat ideje da se konta
mogu označiti ovisno o tome na koju se stranu, dugovnu ili
potražnu, zapisuju iznosi knjiženja
OPIS_KONTA kratko objašnjenje namjene konta
ANALITIKA zastavica (D/N), označava hoće li se konto koristiti u analizi po
vezanim subjektima (kupcima i dobavljačima)
VRSTA_IZNOSA opcionalan atribut koji označava je li iznos koji se knjiži na
konto osnovica (O), porez (P) ili ukupni iznos (B – bruto)
Jedina preostala tablica je PIN, koja nije povezana ni sa jednom drugom tablicom.
Ta tablica, zapravo, ima samo jedan atribut – PIN, i uvijek je u nju spremljen samo
jedan 4-znamenkasti broj. PIN koji se sprema u tu tablicu nije tajan, niti mu je
namjena sigurnosne naravi. Ovdje je PIN broj koji će korisnik morati upisati u
aplikaciji kada će željeti nešto obrisati. Rijetke stvari koje se u računovodstvu smiju
brisati, često su ili dovoljno velike ili dovoljno važne ili oboje, da se brisanje ne
može dopustiti bez provjere. Provjera ne treba kontrolirati tko smije provoditi
brisanje, već treba provjeriti je li korisnik svjestan posljedica, pa on svoj izbor
brisanja, umjesto jednostavnim klikom na „OK“ u odgovor na pitanje „Jeste li
sigurni?“, što mnogi ljudi rade automatski, potvrđuje unosom PIN-a iz tablice PIN.
21
4. Tehnologija
Za razvoj web-aplikacije za računovodstvo odabran je alat Oracle Application
Express (APEX), koji pripada u skupinu alata za brzi razvoj aplikacija (eng. Rapid
Application Development). Arhitekturalno, aplikacije razvijene uz pomoć APEX-a
su web-aplikacije klijent – poslužitelj, i to aplikacije tankog klijenta, jer je za njihovo
pokretanje na klijentu potreban samo web-preglednik. Tijekom razvoja aplikacije,
APEX se oslanja na pozadinu aplikacije u Oracle relacijskoj bazi podataka, te se
može reći da je razvoj aplikacija temeljen na bazi podataka, tj. database driven.
Arhitektura APEX-a, koja je prikazana je na slici 4.1, logički je vrlo jednostavna, ali
postoji nekoliko mogućnosti za fizičku implementaciju. Za Web Listener, koji služi
za zaprimanje zahtijeva koji dolaze s klijenta i prevođenje tih zahtijeva u pozive
baznih procedura enginea, postoje tri opcije :
Oracle APEX Listener (drugi naziv: Oracle Rest Data Services - ORDS)
Oracle HTTP Server (Apache) + mod_plsql
Embedded PL/SQL Gateway (EPG)
Slika 4.1 Arhitektura Application Express-a (Jennings, Installation Guide, 2015.)
EPG je dio baze podataka, što znači da se u tom slučaju cijeli proces, od
zaprimanja zahtjeva s klijenta, preko izvođenja procesa, do renderiranja stranice
22
koja se šalje na klijent, događa u bazi. Baza podataka može se nalaziti lokalno, na
istom računalu na kojem se nalazi i klijentski web-preglednik, ili može biti
postavljena na poslužiteljsko računalo na koje se klijent spaja preko interneta.
Pristup se u oba slučaja jednako ostvaruje; u preglednik se upisuje URL aplikacije.
OHS je sam po sebi aplikacijski poslužitelj, a ORDS je servis koji se postavlja na
aplikacijski poslužitelj, npr. Apache Tomcat. U njihovom slučaju, moguće je
uspostaviti troslojnu arhitekturu izdvajanjem baze na zasebni poslužitelj. U slučaju
velikog broja korisnika, takvo je rješenje lakše nadograditi dodavanjem više
poslužitelja u srednji sloj koji zaprima zahtjeve klijenata. Sa sigurnosne strane,
takvo rješenje je također bolje od jednog fizičkog poslužitelja, jer omogućuje
dodavanje dodatnog sigurnosnog sloja između baze podataka i aplikacijskog
poslužitelja. Poslužitelj na kojem se nalazi baza podataka tada uopće ne treba
imati pristup vanjskoj internetskoj mreži, već za to služi aplikacijski poslužitelj.
Jedna od specifičnosti APEX-a je APEX engine koji interpretira metapodatke
spremljene u bazi podataka i u realnom vremenu renderira web-aplikaciju koja se
prikazuje na klijentu. Engine se sastoji od repozitorija metapodataka i procedura
napisanih u PL/SQL-u, koje iz metapodataka iz repozitorija stvaraju HTML stranice
koje se šalju na klijent. Aplikacija napravljena uz pomoć APEX-a zapravo je skup
metapodataka koji bez enginea nemaju smisao. Nema izvornog koda koji se
prevodi u izvršni kod i na taj se način odvaja od alata u kojem je nastao. Aplikacija
nastala uz pomoć APEX-a se mora i pokretati uz pomoć APEX-a.
Međutim, engine korišten za razvoj aplikacije u APEX-u ne mora biti jednak onome
koji će aplikaciju samo izvršavati na produkcijskoj bazi podataka. Preporučeno je
za razvoj koristiti razvojnu okolinu (eng. full development environment), ali za
testiranje i u produkciji koristiti okolinu koja služi samo za pokretanje aplikacije
(eng. runtime only environment). (Jennings, Installation Guide, 2015.) Okolina koja
samo pokreće aplikaciju, ali ne podržava razvoj, razlikuje se od razvojne okoline
po nedostatku razvojnog web sučelja, a i zato što sadrži samo one bazne pakete
koji su potrebni za pokretanje aplikacije. Jedini način administracije okoline koji
preostaje je korištenjem klijenta za pristup bazi, uz pomoć programskog sučelja
(eng. Application Programming Interface – API) u vidu baznog paketa
APEX_INSTANCE_ADMIN. (Jennings, API Reference, 2015.)
23
Sučelje za razvoj je u potpunosti web-orijentirano. U slučaju kad se APEX nalazi
na poslužitelju, za razvoj aplikacija, jednako kao ni za pokretanje aplikacija kad su
gotove, na klijentskom računalu nije potrebno imati ništa osim web-preglednika.
Razvojnom sučelju se također pristupa jednostavno URL-om.
Na slici 4.2 prikazano je razvojno web-sučelje, otvoreno na prikazu ekrana za
uređivanje stranica. U APEX-u je stranica osnovni gradivni element svake
aplikacije. Sva polja za upis, izvještaji, procesi i validacije vežu se uz stranicu i
pohranjuju u repozitorij metapodataka u bazi. Dio entiteta koji je vezan uz prikaz i
dinamično funkcioniranje stranice na klijentu postaje dio izvornog koda u HTML-u
koji se generira kad se stranica pokrene. Dio procesa i validacija, koji je zaslužan
za obradu podataka na poslužitelju, izvodi se kad se stranica „vrati“ na poslužitelj
(eng. submit).
Slika 4.2 Izgled razvojnog web sučelja u APEX-u
Sučelje za uređivanje stranica podijeljeno je u tri vertikalne regije. Lijevo
pozicionirana regija sadrži četiri kartice koje sadrže redom:
Rendering – stablastu strukturu stranice, onako kako se generira njen
izvorni HTML,
24
Dynamic Actions - popis dinamičnih akcija razvrstanih po uvjetima koji ih
pokreću (promjena vrijednosti, klik miša, postavljen fokus, izgubljen fokus,
učitavanje stranice, itd.). Dinamične akcije koriste JavaScript i AJAX pozive
kako bi mogle reagirati na akcije korisnika u pregledniku, bez slanja
stranice na poslužitelj,
Processing – stablastu strukturu procesiranja stranice na poslužitelju,
uključujući validacije, procese i grananja na druge stranice,
Page Shared Components – stablastu strukturu zajedničkih komponenti na
razini aplikacije koje stranica koristi, poput predložaka (eng. template), tema
(eng. theme), lista vrijednosti (eng. list of values – LOV) i slično.
Srednje pozicionirana regija također sadrži četiri kartice:
Grid Layout – predložak izgleda stranice gdje se može vidjeti gdje su
komponente (polja za unos, regije, gumbi...) pozicionirane na stranici u
relativnom međusobnom odnosu,
Messages – prozor u kojem se dinamički pojavljuju poruke, upozorenja ili
greške pri uređivanju stranice (npr. obavezno polje nije popunjeno pri
definiciji polja za unos),
Page Search – pretraživač svega na stranici, korisno kad stranica koja se
uređuje postane jako kompleksna, jer olakšava potragu za određenom
komponentnom stranice,
Help – dinamički nudi objašnjenja za bilo koju komponentu iz regije s desne
strane, gdje se pojavljuju svojstva pojedinih komponenti iz stabla na lijevoj
strani.
Desno pozicionirana regija sadrži svojstva trenutno odabrane komponente na
stranici. Komponente stranice se odabiru klikom na čvor koji predstavlja
komponentu u stablastoj strukturi lijevo pozicionirane regije. Svojstva koja popisuje
desno pozicionirana regija razlikuju se od komponente do komponente.
Popunjavanjem svojstava definira se izgled i ponašanje komponenata. Popunjene
vrijednosti se spremaju u metastrukturu koja služi APEX engineu za renderiranje i
procesiranje stranica.
25
Aplikacija, ili pojedinačne stranice, mogu se pokretati s različitih mjesta unutar
razvojnog sučelja, a otvaraju se u novoj kartici ili novom prozoru web-preglednika
(ovisi o ponašanju pojedinog preglednika), što omogućuje paralelan pogled na
strukturu stranice, preko razvojnog sučelja, i na stranicu u radu. Dok god traje
sjednica programera prijavljenog u razvojno sučelje, pokrenuta stranica sadržavati
će i alatnu traku koja omogućuje programeru da uključi i isključi način rada za
otklanjanje pogrešaka (eng. debug mode), pogleda stanje podataka sjednice na
poslužitelju ili jednim klikom osvježi razvojno sučelje na ekran koji pokazuje
strukturu trenutne stranice, ili ekran za uređivanje aplikacije i slično.
APEX engine transparentno održava stanje entiteta na strani poslužitelja na razini
korisničke sjednice klijenta prema APEX-u. Procesiranje podataka koje se događa
na poslužitelju, odnosno u bazi, odvija se nad stanjem entiteta u sjednici (eng.
session state), tako da treba imati na umu da se prije procesiranja eventualne
promjene podataka s klijenta trebaju poslati na poslužitelj. U tom smislu postoji
razlika između preusmjeravanja toka aplikacije s jedne stranice na drugu (eng.
redirect), kad se od poslužitelja samo zahtjeva nova stranica, i slanja trenutne
stranice na poslužitelj radi obrade i slijedno učitavanje nove stranice kad je obrada
završila (eng. submit and branch). Neki gumbi i sve poveznice u APEX-u bez
intervencije programera koriste preusmjeravanje, što može uzrokovati neočekivani
gubitak nespremljenih promjena za krajnjeg korisnika. Takve situacije se najčešće
rješavaju upotrebom JavaScripta i ugrađene funkcije apex.submit(pOptions) ili
apex.submit(pRequest).
Preusmjeravanje između stranica najčešće se radi poveznicama (eng. link), koje u
APEX-u imaju specifičnu strukturu, jer koriste tzv. sintaksu „f?p“:
f?p=App:Page:Session:Request:Debug:ClearCache:itemNames:itemValues
:PrinterFriendly
Navedena struktura nastavlja se na početak poveznice koji služi za adresiranje
poslužitelja na kojem se nalazi Web Listener, što je konstanta pri radu s APEX-
om. U poveznicama se mogu koristiti neposredne vrijednosti ili zamjenski nizovi
(eng. substitution strings), koji se zamjenjuju neposrednim vrijednostima kod
izvođenja. Zamjenski nizovi uvijek počinju znakom „&“ i završavaju točkom („.“).
Pojmovi odvojeni dvotočkama redom znače:
26
App – identifikacijski broj aplikacije,
Page – identifikacijski broj stranice koja se dohvaća,
Session – identifikacijski broj sjednice,
Request – zahtjev (može biti proizvoljan i koristiti se kao uvjet za izvođenje
procesa na stranici),
Debug – zastavica za ispis detalja za testiranje i otkrivanje pogrešaka
(vrijednosti LEVELn, gdje je n broj od 1 do 9, ili NO ili YES, što je jednako kao
LEVEL4),
ClearCache – niz zarezom odvojenih identifikatora stranica gdje treba
obrisati (postaviti na vrijednost null) stanje svih komponenti,
itemNames – niz zarezom odvojenih identifikatora polja za unos (eng. item,
kako se u APEX-u naziva pojedinačno polje za unos bilo kojeg tipa) čije se
vrijednosti postavljaju na poslužitelju gdje se sprema stanje vezano uz
sjednicu,
itemValues – niz zarezom odvojenih vrijednosti kojima će se popuniti
prethodno navedena polja – redoslijed je bitan,
PrinterFriendly – zastavica koja signalizira treba li stranicu renderirati na
način da je spremna za ispis, što znači da se komponente na stranici ne
prikazuju kao upisna polja već samo kao tekst (eng. read only mode), te se
ne prikazuju navigacijske trake i izbornici. Taj način rada se postiže ako se
zastavici dodijeli vrijednost YES, dok sve ostale vrijednosti, uključujući i
slučaj kad se ne prosljeđuje nikakva vrijednost za taj parametar, ne čine
razliku u poveznici i ponašanju aplikacije.
Na primjer, na početnu stranicu web-aplikacije za vođenje računovodstva se dolazi
poveznicom:
localhost:8081/apex/f?p=100:1
ili, s obzirom da je stranica 1 označena kao početna stranica u postavkama
aplikacije, može i:
localhost:8081/apex/f?p=100
27
gdje broj 100 predstavlja identifikacijski broj aplikacije u APEX-ovom radnom
okruženju (eng. workspace), a broj 1 predstavlja identifikacijski broj stranice u
aplikaciji.
Primjer poveznice kojom se s početne stranice dolazi na stranicu s matičnim
podacima izgleda ovako:
localhost:8081/apex/f?p=&APP_ID.:8:&SESSION.::NO::P8_STRANKA_ID:
7499
Ova poveznica, međutim, zbog zamjenskih nizova ne radi kroz web-preglednik.
Kroz aplikaciju bi ta poveznica djelovala kao zahtjev za stranicom s matičnim
podacima stranaka (stranica broj 8 u aplikaciji), a s obzirom da se postavlja
vrijednost liste vrijednosti P8_STRANKA_ID, prikazali bi se podaci točno određene
stranke s baznim identifikatorom 7499. Zamjenski nizovi se mijenjaju neposrednim
vrijednostima na poslužitelju. Kroz web-preglednik ova poveznica rezultira
pogreškom broj 400 po HTTP protokolu („bad request“).
Prosljeđivanje parametara poveznicom pruža mogućnost krajnjim korisnicima da,
mijenjanjem vrijednosti u poveznici, utječu na ponašanje aplikacije. Pristup
stranicama promjenom poveznice se ne može spriječiti, ali postavljanje vrijednosti
parametara se može spriječiti dodavanjem sigurnosne sume (eng. checksum) u
poveznicu.
4.1 Usporedba: Oracle Application Express, Oracle Application
Development Framework i Oracle Forms
Application Express je alat koji služi za brzu izradu web-aplikacija jednostavne
arhitekture na temelju postojeće baze podataka. Application Development
Framework pomaže u razvijanju web-aplikacija po paradigmi MVC (Model – View
– Controller). Razvoj se može temeljiti na bazi podataka, ali i na klasama
definiranima u Javi. Oracle Forms predstavljaju vjerojatno najpoznatiji Oracleov
alat za razvoj aplikacija temeljenih na bazi podataka, koji postoji već više od četvrt
stoljeća. Verzija 3, prva verzija s ugrađenom podrškom za PL/SQL, katkad
28
nazivana „prva prava verzija Oracle Formsa“, izdana je 1988. Trenutno su Formsi
u verziji 12, a zajednica korisnika aktivno raspravlja jesu li krenuli silaznom
putanjom i treba li ih zamijeniti s APEX-om, ADF-om ili nekim trećim rješenjem
koje nije iz Oracle svijeta.
Sva tri navedena alata imaju vjerne zagovornike: Formsi postoje već dugi niz
godina i mnoštvo programera zna vrlo dobro raditi s njima, APEX je alat za brzi
razvoj i brzo učenje, a ADF veličaju zbog njegove očite fleksibilnosti i
suvremenosti, jer je temeljen na Javi.
Oracle Forms osim velike baze korisnika naučenih na rad u tom alatu, imaju i
drugih prednosti: fleksibilan dizajn pokretan događajima (eng. event driven), te
usku povezanost s bazom podataka, jer se izrada stranica temelji na bazi
podataka. Zapravo, Formsi su nastali upravo u svrhu izrade aplikacija za unos
podataka u bazu. Ispočetka, prije nego što su dobili sadašnje ime, Formsi su bili
poslužiteljski servis za unos podataka u bazu i nisu imali grafičko sučelje. Kasnije
su prerasli u aplikaciju debelog klijenta. Moderni Formsi, tj. od verzije 6 nadalje,
imaju troslojnu arhitekturu koja uključuje bazni poslužitelj, aplikacijski poslužitelj i
(tanki) klijent. (Roy, 2016.) U verziji 6 je podrška za pokretanje Formsa na
aplikacijskom poslužitelju bila toliko spora i podložna greškama, da se u vrijeme
kad su verzije 6 i 6i bile aktualne, jako malo korisnika odlučilo koristiti novu
mogućnost, sve dok s verzijom 9 nije došao retroaktivni ispravak rada
aplikacijskog poslužitelja i za starije verzije.
Dok se klijentski sloj u slučaju APEX-a ili ADF-a može s punim pravom nazvati
tankim klijentom, u slučaju Formsa je na klijentu potrebno instalirati jednu od
ponuđene dvije konfiguracije:
web-preglednik, Java Development Kit (JDK), Java Plug-In (JPI)
Forms Standalone Launcher (FSAL), Java Runtime Environment (JRE ) ili
Java Development Kit (JDK). (Roy, 2016.)
Pri prvom uspostavljanju komunikacije između klijenta i aplikacijskog poslužitelja,
klijent dobiva Java applet koji služi za renderiranje aplikacije. Ovisno o načinu na
koji je aplikacija napravljena, moguće je da će klijent tijekom rada primiti još
appleta. Međutim, aplikacija i dalje ovisi o aplikacijskom poslužitelju jer se tamo
29
pokreću glavni procesi. Dakle, osim navedenih konfiguracija, nema instalacije
aplikacije na klijentsko računalo, pa aplikacija i dalje pripada u domenu web-
aplikacija.
Prema jeziku koji se koristi za izradu aplikacija, ADF se razlikuje od preostala dva
alata jer koristi Javu i platformu Java EE, dok APEX i Formsi koriste većinom
PL/SQL. APEX i ADF dodatno koriste JavaScript i srodne tehnologije koje su
djelomično ugrađene u sam alat, ali se mogu i dodavati. JavaScript se može
integrirati i u Formse, za unaprjeđenje korisničkog sučelja. Također, s obzirom da
koriste Javu za pokretanje, u Formsima se može razvijati i u Javi (Pluggable Java
Components, Java Beans), posebno s ciljem iskorištavanja servisno-orijentiranih
arhitektura (eng. Servis Oriented Architecture – SOA). Bitno je naglasiti da doticaj
programera s bilo kojom tehnologijom ili programskim jezikom osim PL/SQL-a nije
nužan u radu s APEX-om ili Formsima, s tim da je dio funkcionalnosti u APEX-u
interno ostvaren i ugrađen korištenjem JavaScripta, isto kao i u ADF-u, samo što
je ondje dominantna Java umjesto PL/SQL-a.
Gledajući razvojno sučelje, APEX ne zahtjeva instalaciju posebnog programa za
izradu aplikacija, već se sučelje u obliku web-aplikacije instalira sa samim APEX-
om i potreban je samo web-preglednik i točan URL za pristup. Formsi imaju svoj
Oracle Forms Developer, a ADF se može koristiti kroz Oracle JDeveloper ili kroz
Eclipse, oboje razvojne okoline za aplikacije u Javi.
Završni produkt svakog od tri alata je donekle ovisan o alatu i nakon razvoja.
Forms generiraju datoteke tipa specifičnog za platformu i prije i nakon prevođenja,
APEX pohranjuje aplikaciju u obliku metapodataka za čiju je interpretaciju
potreban APEX engine, a za aplikacije razvijene u ADF-u je potrebno imati
aplikacijski poslužitelj koji podržava Javu EE i ima instaliran ADF runtime.
Postavljanje aplikacije napravljene u APEX-u na produkcijsku okolinu ne uključuje
prevođenje aplikacije u izvršni kod, već samo izvoz i uvoz aplikacije i pratećih
objekata (baznih objekata, .CSS datoteka, .JS datoteka, itd.). (Jennings,
Application Builder User's Guide, 2015.) Međutim, kako raste kompleksnost
aplikacije, to može postati teško pratiti i vjerojatnost pogreške se povećava. U
ADF-u se aplikacija prevodi u datoteku ekstenzije .EAR (Enterprise ARchive), koju
treba postaviti na aplikacijski poslužitelj s već navedenim ADF Runtimeom.
30
Aplikacijski poslužitelj je prethodno potrebno pravilno konfigurirati. (Jew, 2012.)
Formsi zahtijevaju prevođenje izvornih datoteka specifičnih za platformu, u
specifične izvedbene datoteke, koje se, uz brojne mogućnosti podešavanja kroz
konfiguracijske datoteke, prebacuju na aplikacijski poslužitelj s instaliranim Oracle
Forms Services. (Roy, 2016.)
Krivulja učenja za svaki od alata ovisi o prijašnjem iskustvu pojedinih programera.
Netko tko se već bavio Javom ili barem objektno orijentiranim programiranjem,
vjerojatno će se brže snaći u ADF-u, nego u preostala dva alata. S druge strane,
netko tko istražuje opcije za migraciju i modernizaciju aplikacije iz Formsa,
primijetit će da je APEX po arhitekturi i odabiru programskog jezika sličniji
Formsima od ADF-a, ali da je ADF, kao što su i Formsi, nominalno dovoljno jak
alat za razvoj poslovnih sustava, dok APEX inicijalno možda nije bio zamišljen i
namijenjen za veće sustave, ali postoje uspješne komercijalne implementacije
poslovnih sustava u APEX-u. (Commercial Applications, 2016.)
U kontekstu povezanosti s drugim Oracleovim alatima i platformama, najneovisniji
je ADF. Može se koristiti kroz Eclipse, aplikacije se mogu postaviti na bilo koji
poslužitelj koji podržava Javu EE i, osim na Oracle, podržava spajanje i na druge
baze podataka. Formsi ne podržavaju direktno spajanje ni na jednu drugu bazu
podataka osim Oracleove, međutim moguće je samu bazu povezati s bazama
drugih proizvođača, te ju iskoristiti kao vezu. Isto je moguće i za APEX, jer i on
može raditi samo s podacima iz Oracleove baze. APEX je moguće instalirati samo
na Oracleovu bazu, a Formsi pripadaju cijelom stogu povezanih Oracleovih
aplikacija.
Na sljedećoj stranici nalazi se matrica usporedbe Oracle Formsa, ADF-a i APEX-a
temeljena na prethodnom tekstu.
31
Tablica 4.1 Matrica usporedbe
Forms ADF APEX
Rapid Application
Development NE DA DA
MVC paradigma NE DA NE
Razvoj temeljen na bazi
podataka DA
DA, ali ne
isključivo DA
Arhitektura 3-slojna 3-slojna 2-slojna ili
3-slojna
Tanki klijent
DA, ali zahtjeva
dodatnu
konfiguraciju
DA, samo
preglednik
DA, samo
preglednik
Programski jezik
PL/SQL,
opcionalno Java i
Web 2.0
Java,
opcionalno Web
2.0
PL/SQL,
opcionalno Web
2.0
Instalacija razvojnog sučelja DA DA
NE, razvojno
sučelje je web-
aplikacija
Ovisnost finalnog produkta o
razvojnoj tehnologiji
DA, određeni apl.
poslužitelj i baza
podataka
NE, osim ADF
Runtimea
DA, baza
podataka i
APEX engine
Postavljanje finalnog
produkta na produkcijsku
okolinu
Prevođenje
izvornog u izvršni
kod,
konfiguracijske
datoteke
Prevođenje i
postavljanje
.EAR datoteke
na poslužitelj
Izvoz i uvoz
aplikacije i
baznih objekata
Strma krivulja učenja NE NE DA
Razvoj poslovnih sustava
(enterprise applications) DA DA
Nominalno NE,
ali u praksi DA
Rad s bazama podataka
drugih proizvođača
NE, osim kroz
Oracle bazu DA
NE, osim kroz
Oracle bazu
Zadnja verzija 12.2.1.1,
lipanj 2016.
12.2.1.0.0,
listopad 2015.
5.0.3.00.03,
21. prosinca
2015
32
4.2 Izvještaji u Jasperu
Iako APEX ima mogućnost ispisivanja izvještaja u .PDF formatu, taj ispis nije
moguće dodatno uređivati. Izvještaj će se ispisati onako kako je dizajniran na
stranici web-aplikacije, što nije uvijek prikladno. Na slici 4.3 je vidljivo kako izgleda
primjer izvještaja ispisanog u APEX-u 5.0. Ako je cilj za računovodstvenu
aplikaciju izraditi izvještaje koji se trebaju moći predati državnim institucijama, a za
koje postoji čvrsto definirana forma, potrebno je pronaći alat koji će nadopuniti tu
funkcionalnost.
JasperReports Server je web-aplikacija koji služi za generiranje izvještaja u .PDF
formatu na temelju predloška napisanog u XML-u i podataka iz baze. Za
pokretanje JasperReports Server koristi platformu Apache Tomcat, a za pohranu
podataka PostgreSQL. (JasperReports Server, 2016.)
Slika 4.3 Primjer ispisa u .PDF format iz APEX-a
33
Za dizajniranje predloška u XML-u za Jasper, JRXML-u, iskorišten je Jaspersoft
Studio, alat otvorenog koda, temeljen na Eclipseu. (Jaspersoft Studio, 2016.)
S obzirom da se generirani izvještaji u .PDF formatu s JasperReports Servera
dohvaćaju preko zahtjeva HTTP GET, parametri izvještaja i pristupni podaci koji
se prenose su vidljivi u URL-u. Zato je za dohvat izvještaja kroz web-aplikaciju u
APEX-u iskorišten bazni paket koji sakrije parametre zahtjeva. (Antipa, 2011.)
Paket sadrži jednu funkciju i jednu proceduru. Funkcija ima pomoćnu ulogu
konstrukcije URL-a za dohvat izvještaja na temelju parametara s kojima je
pozvana procedura. Procedura se pozove iz APEX-a, obavi preuzimanje izvještaja
s JasperReports Servera i proslijedi ga APEX-u u web-preglednik. Na taj način se
parametri za dohvat izvještaja prosljeđuju u bazu u pozadini preko poziva
procedure, a ne otvoreno, URL-om. Proces u kojem se u APEX-u poziva
procedura mora kao točku izvođenja imati Before Header, što znači da će se
izvesti prije nego što APEX engine u bazi renderira stranicu za koju je proces
vezan, te će se dohvaćeni izvještaj također poslati na klijent skupa sa stranicom.
34
5. Implementacija
Web-aplikacija za vođenje računovodstva poduzetnika u računovodstvenom
servisu razvijena je u Oracle Application Expressu (APEX). Okolina za razvoj
uspostavljena je lokalno, na jednom računalu, na koje je instalirana baza podataka
Oracle Database 11g Release 2. APEX se od verzije 11g instalira i podešava pri
instalaciji same baze, međutim navedena verzija baze podataka dolazi s APEX-
om 3.2, dok je trenutno najnovija verzija 5.0.3 iz prosinca 2015. godine. S obzirom
da je baza podataka kompatibilna s najnovijom verzijom APEX-a, APEX je
nadograđen prije početka razvoja aplikacije.
Za početni razvoj je, radi jednostavnosti, za Web Listener odabran Embedded
PL/SQL Gateway koji se automatski konfigurira pri instalaciji baze i APEX-a.
Međutim, EPG je na kraju zamijenjen ORDS-om (Oracle REST Data Services), jer
nije preporučen za produkcijsku okolinu, već samo za razvojnu, većinom iz
sigurnosnih razloga. ORDS 3.0.0 je postavljen na aplikacijski poslužitelj Tomcat 8,
koji je došao uz instalaciju JasperReports Servera.
Nakon instalacije APEX-a prvi sljedeći korak je konfigurirati radnu okolinu (eng.
workspace) i korisnike koji se mogu prijaviti u radnu okolinu, da bi bilo moguće
započeti razvoj. Konfiguraciju radnih okolina i korisnika obavlja APEX
administrator koji pristupa posebnoj internoj radnoj okolini i ima veća prava nego
ostali korisnici. Prilikom konfiguracije radne okoline moguće je odabrati postojeću
shemu iz baze podataka ili napraviti novu u sklopu konfiguracije radne okoline.
Drugi korak, nakon uspješne prijave novog korisnika u novu radnu okolinu, je
kreirati novu aplikaciju namijenjenu pokretanju na računalu (za razliku od web-
aplikacije namijenjene mobilnim uređajima). Prilikom kreiranja nove aplikacije
definira se shema za autentikaciju korisnika aplikacije. Ponuđene su tri sheme:
autentikacija preko korisnika APEX-a, autentikacija preko baznih korisnika i shema
bez autentikacije. Odabrana je shema autentikacije preko korisnika APEX-a. To
znači da korisnike u aplikaciji definira APEX administrator kroz svoje web-sučelje
za administraciju. S obzirom na očekivani broj korisnika u sustavu, takva shema
autentikacije je sasvim prihvatljiva.
35
Nova aplikacija odmah po nastanku sadrži početnu stranicu, navigacijsku traku i
izbornik na lijevoj strani ekrana. Slijedeći poslovni proces, prvo što u aplikaciji
treba napraviti je unos klijenata.
Matični podaci klijenta u modelu baze podataka imaju 6 odnosa „zaglavlje –
stavke“ između glavne tablice STRANKA i tablica:
TELEFON,
ADRESA,
EMAIL,
RACUN,
NAPOMENA,
KONTNI_PLAN.
U APEX-u postoji ugrađeni proces koji za odnos „zaglavlje – stavke“ generira dvije
stranice: jednu s interaktivnim izvještajem za podatke u tablici na strani zaglavlja,
te drugu, koja sadrži formu za pojedinačan unos zaglavlja i tabularnu formu za
grupni unos svih stavki. Ručno bi se moglo nadograditi da stranica za unos sadrži
jednu formu za zaglavlje i šest tabularnih formi za šest skupina stavki, jer postoji i
ugrađeni proces za definiciju pojedinačne regije tabularne forme.
Međutim, APEX ima ograničenje da na jednoj stranici može postojati samo jedna
tabularna forma, zbog korištenja ugrađenih kolekcija u koje se spremaju podaci pri
prijenosu na poslužitelj. Problem leži u usklađivanju šest regija koje koriste iste
interne kolekcije. Kad bi programer imao pristup kodu koji pokreće regiju svake
tabularne forme, mogao bi promijeniti nazive kolekcija i ne bi došlo do
međusobnog prepisivanja podataka. Ali programer nema pristup kodu tabularne
forme generirane ugrađenim procesom, vjerojatno zato što se on generira pri
pokretanju stranice iz parametara kojima je definirana regija.
Ako je neophodno imati tabularne forme, preostaje jedino mogućnost njihove
ručne izrade. Takva mogućnost temelji se na postojanju baznog paketa APEX_ITEM,
koji sadrži pozive funkcija za renderiranje različitih vrsta polja za unos, i kolekcija
APEX_APPLICATION.G_Fnn(i), gdje je n znamenka od 0 do 9, a i redni broj retka u
kolekciji. Da bi se ostvarila funkcija što sličnija generiranoj tabularnoj formi, uz
pisanje kompleksnijeg SQL upita za dohvaćanje atributa za izvještaj (jer treba
36
koristiti odgovarajuću funkciju iz navedenog baznog paketa za svaki atribut), treba
napisati i proces za unos i ažuriranje redaka s obzirom na zaštitnu sumu u sklopu
optimističnog zaključavanja, te validacije, koje su nešto kompleksnije za ručno
kodiranu tabularnu formu. Međutim, ono što je najteže postići za ručno izrađenu
tabularnu formu je dodavanje novog retka na dno tablice funkcijom napisanom u
JavaScriptu. Bazično rješenje je u SELECT naredbu, kojom se biraju atributi
izvještaja, dodati uniju s praznim zapisom. Tada se na svako spremanje jedan
redak spremi u bazu, a jedan novi prazni redak se pojavi u tabularnoj formi. A za
svako spremanje treba poslati stranicu na poslužitelj i čekati da se osvježi. (Cho,
2004.)
S obzirom da navedeno rješenje nije u potpunosti zadovoljavajuće, a matični
podaci ne predstavljaju mjesto u aplikaciji gdje je apsolutno potrebno imati šest
tabularnih formi, odabrano je alternativno rješenje koje sadrži samo jednu
tabularnu formu i pet izvještaja u koje se zapisi dodaju kroz modalne prozore.
Kako se klasični izvještaj (eng. classic report) i forma za unos pojedinačnog zapisa
mogu dobiti kroz ugrađene procese, izgledaju i ponašaju se modernije, a puno ih
je lakše napraviti. Slike 5.1 i 5.2 prikazuju kako izgleda stranica za unos matičnih
podataka. Slika 5.1 prikazuje kako izgleda unos nove adrese kroz modalni prozor.
Na isti način se unose i broj telefona, bankovni račun, adresa elektroničke pošte,
te napomena.
Slika 5.1 Unos nove adrese
37
Slika 5.2 Matični podaci stranke
38
Jedina tabularna forma od 6 skupina stavki je regija za unos kontnog plana. S
obzirom da kontni plan ima više od 2 000 redaka, dodan je filter po šifri. Filter nije
ništa drugo nego item, tekstualno polje, s čijom se vrijednosti, ako nije NULL,
uspoređuju šifre kontnog plana u upitu koji definira tabularnu formu (ako je
tekstualno polje prazno, prikazuju se svi zapisi). Osvježavanje tabularne forme
pokreće se na događaj promjene vrijednosti itema, uz pomoć djelomičnog
osvježavanja stranice (eng. Partial Page Refresh – PPR) temeljenog na AJAX-u.
PPR se omogućuje za pojedine regije, a reagira na dinamičnu akciju Refresh nad
tom regijom. Da bi se zapisi osvježili, potrebno je samo AJAX pozivom ponovno
izvesti upit iz definicije regije da dohvati retke, ali s novom vrijednošću filtera, a to
je točno ono što PPR radi.
Na vrhu stranice s matičnim podacima nalazi se lista vrijednosti s popisom svih
stranaka. Na promjenu vrijednosti liste cijela stranica se osvježi kako bi sve regije
poprimile vrijednosti novoodabrane stranke. Ako se ne odabere niti jedna stranka
iz liste, već se lista ostavi prazna, sve regije, osim glavnog „zapisa – glave“,
nestanu, a „zapis – glava“ postane prazna forma za unos novog klijenta.
Na stranici s matičnim podacima dodana su dva gumba za brisanje: jedan briše
sve podatke o trenutno odabranom klijentu iz baze podataka, a drugi briše
knjigovodstvene podatke, ali matični podaci ostaju u sustavu. Oba gumba pozivaju
modalnu regiju koja od korisnika traži upis PIN-a kako bi pokazao da stvarno želi
da se podaci izbrišu.
Nakon što je ostvaren unos stranki, sljedeći zadatak je napraviti izvještaj s
popisom svih stranki, te ga povezati sa stranicom za unos matičnih podataka.
Izvještaj je stavljen na početnu stranicu, kako bi bio pri ruci čim se aplikacija
pokrene. Iskorišten je interaktivni tip izvještaja koji pruža krajnjem korisniku
mogućnost uređivanja izvještaja s obzirom na neki početni maksimalni set
podataka. Maksimalni set podataka definiran je SQL upitom na kojem se temelji
izvještaj. Korisnici mogu sakrivati ili prikazivati i mijenjati poredak stupcima u
izvještaju, filtrirati, grupirati, agregirati, dodavati stupce s izračunima po redcima,
selektivno označavati retke različitim bojama, izrađivati dijagrame i pivotirati
tablicu. Bilo koja od tih akcija može se onemogućiti uređivanjem svojstava regije
interaktivnog izvještaja. Programeri mogu uz pomoć različitih akcija složiti primarni
39
izvještaj i više alternativnih, a korisnici ih sve mogu pregledavati i dodati svoje
kombinacije. Na slici 5.3 i 5.4 se nalaze primarni i alternativni izvještaj s početne
stranice računovodstvene aplikacije.
Slika 5.3 Primarni izvještaj - klijenti servisa
Slika 5.4 Alternativni izvještaj - tip stranke
Na slici 5.3 prikazan je primarni izvještaj s popisom klijenata servisa (upotrijebljeno
je filtriranje) i prikazanim stupcem s poveznicama na unos temeljnica za svakog
40
pojedinog klijenta. Na slici 5.4 vidi se alternativni izvještaj s popisom svih stranaka,
čiji su retci obojani različitim bojama ovisno o tipu stranke. Na alternativnom
izvještaju se ne vidi stupac s poveznicama na unos temeljnica, ali u slučaju da
korisnik izmijeni izvještaj tako da prikazuje sve stranke i stupac s poveznicama, ne
bi mogao doći na unos temeljnica za stranku koja nije klijent, jer se poveznica
pojavljuje samo u retcima koji opisuju klijente servisa.
Na početnoj stranici nalazi se i gumb za promjenu PIN-a. Gumb otvara modalni
prozor koji sadrži jedno polje za upis starog PIN-a i dva polja za upis novog, za
provjeru, validacije koje provjeravaju valjanost starog PIN-a i istovjetnost novog
PIN-a u oba polja, te proces koji ažurira vrijednost PIN-a u tablici PIN.
Poveznica na unos temeljnica vodi na stranicu s interaktivnim izvještajem svih
temeljnica za jednog klijenta u odabranoj poslovnoj godini (Slika 5.5). Izvještaj je
razvrstan po vrsti temeljnice akcijom Control Break, a unutar svake grupe su
temeljnice poredane tako da neizbalansirane (pogrešne) temeljnice dođu na vrh, a
ostale ispod, poredane po knjizi kojoj pripadaju. Pogrešne temeljnice su obojane
crveno, a zbog količine zapisa koji se mogu nakupiti u jednoj poslovnoj godini,
prikazuju se samo zapisi s datumom dokumenta unutar zadnja dva mjeseca.
Slika 5.5 Popis temeljnica
41
Osim izvještaja, na istoj se stranici može otvoriti nova poslovna godina, može se
otvoriti modalni prozor za administraciju knjiga, obaviti prijenos početnog stanja,
parcijalni prijenos početnog stanja i završni obračun te otići na stranicu za novi
unos temeljnice.
Stranica za unos nove temeljnice (Slika 5.6) prilagođena je unosu svih vrsta
dokumenata, unosu u pomoćne knjige ulaznih i izlaznih računa, te unosu zapisa u
glavnu knjigu. Na formi za unos zaglavlja dokumenta navedeni su podaci koji se
ne unose za sve vrste dokumenata, pa je iskorišteno osam dinamičnih akcija da
se u različitim slučajevima prikažu ili sakriju neka polja za unos.
Slika 5.6 Stranica za unos temeljnica
42
Na primjer, nemaju sve vrste dokumenata knjige u koje se smještaju dokumenti, a
kad imaju, treba osvježiti listu vrijednosti s popisom knjiga koje pripadaju
odabranoj vrsti dokumenta. Da bi se to napravilo, iskorištene su dvije dinamične
akcije i skriveni item, koji se koristi kao zastavica – sadrži podatak ima li trenutno
odabrana vrsta dokumenta knjige ili ne. Vrijednost zastavice se osvježava
promjenom odabrane vrste dokumenta. Promjena vrijednosti zastavice pokreće
drugu dinamičnu akciju koja prikazuje i osvježava listu vrijednosti knjiga ili ju
sakriva.
U ovisnosti o vrsti dokumenta dinamičnim se akcijama prikazuju ili sakrivaju i
regije za unos u knjige ulaznih i izlaznih računa. A same regije sadrže dinamične
akcije za izračunavanje iznosa poreza na temelju osnovica i ukupnih iznosa na
temelju svih polja u regiji.
Na toj stranici je za unos vezanog subjekta u zaglavlju dokumenta iskorišten i
plugin za poboljšanu, auto-complete listu vrijednosti. Plugin je napravljen na
temelju biblioteke Select2 i omogućuje listu vrijednosti koja se dinamički filtrira po
vrijednosti za prikaz, a za odabrani zapis sprema povratnu vrijednost u bazu.
(Buytaert, 2016.) Plugin se može iskoristiti samo za samostojeće iteme na
stranici, ali ne i za stupce istog tipa prikaza u tabularnoj formi, jer APEX ne
podržava razvoj pluginova za tabularne forme.
Regija za unos glavne knjige je također tabularna forma koja se prikazuje tek
nakon što se zaglavlje dokumenta spremi. Ovisno o vrsti dokumenta potrebno je
sakriti neke stupce tabularne forme, ali se to ne može podesiti njenim ugrađenim
svojstvima jer tabularna forma, iako izgleda kao skup itema, ne funkcionira na
istom principu kao samostojeći itemi. Zato je osvježavanje stranice prilikom
spremanja zaglavlja dokumenta iskorišteno za pravilno renderiranje regije za unos
glavne knjige.
Prilikom osvježavanja stranice gleda se i je li već unesen sličan dokument, iste
vrste, s istim vezanim subjektom, te se njegovi zapisi kopiraju u glavnu knjigu
trenutnog dokumenta. Takav postupak jedan je od načina ostvarivanja sheme
knjiženja, jer se slični dokumenti slično knjiže. Još bolje, katkad klijent periodično
kupuje istu količinu iste robe od svog dobavljača, što znači da se kopiranjem
prethodnog takvog dokumenta potpuno točno popuni i novi dokument. Kopiranje
43
zapisa u ovom slučaju znači doslovan ponovni unos zapisa u tablicu
GLAVNA_KNJIGA, samo kao dio drugog dokumenta. Ukoliko je neki od zapisa višak,
korisnik će ga morati obrisati.
S obzirom da je jedna vrlo složena stranica uspjela pokriti sve slučajeve unosa
dokumenata, unos u bazu se može smatrati završenim. Preostali su samo
izvještaji.
Slika 5.7 Bilanca stanja – APEX
Za primjer će poslužiti izvještaj bilance stanja. Izvještaj napravljen u APEX-u (Slika
5.7) je sadržajno jednak .PDF izvještaju iz JasperReportsa (Slika 5.8), ali je
izvještaj u .PDF-u puno pregledniji, jer iznosi za 4-znamenkaste šifre konta
predstavljaju stavke za iznose jednoznamenkastih konta (klasa). Iako se ne vidi na
slikama, na dnu oba izvještaja se nalazi redak s ukupnom sumom svih klasa. Cilj
ovog izvještaja je provjeriti izbalansiranost – na kraju godine bi svi parovi iznosa
„duguje“/„potražuje“ trebali biti jednaki.
U izradi izvještaja s JasperReports Serverom dogodio se problem krivog prikaza
nekih hrvatskih slova. Izvor problema bio je nedostatak tih slova u fontu
instaliranom na poslužitelju. Rješenje je kroz Jaspersoft Studio dodati font u
datotekama i iz njih generirati datoteku .JAR koja će sadržavati font po želji sa
44
svim potrebnim slovima. Navedeni .JAR se treba dodati u putanju JasperReports
Servera.
Slika 5.8 Bilanca stanja - PDF/Jasper
45
6. Iskustvo razvoja u Oracle Application Expressu
Već od same instalacije vidi se da je glavni cilj autora APEX-a bila jednostavnost.
Instalacija se odvija izvođenjem .SQL skripte SQL*Plusom kroz komandnu liniju.
(SQL*Plus je alat za pristup bazama podataka Oracle kroz komandnu liniju, a
instalira se sa svakom bazom.) Samo izvođenje traje nekoliko minuta, ali se od
korisnika, jednom kad se glavna skripta pokrene, ne očekuje nikakva interakcija.
Tijekom početne konfiguracije APEX-a zahtijeva se upis porta preko kojeg će se
pristupati listeneru, te lozinke za glavnog administratora APEX-a. Za instalaciju
postoje detaljne upute s točnim naredbama koje treba upisati u SQL*Plus, tako da
nedostatak grafičkog sučelja ne predstavlja problem.
Sučelje za razvoj otvara se u web-pregledniku i instalira se zajedno s APEX-om,
što znači da će razvojno sučelje uvijek biti kompatibilno s engineom za koji se
razvija. Pokreće se jednako kao što se pokreću i aplikacije koje se razviju u APEX-
u. Ako je razvojno sučelje sporo, treba razmišljati o promjenama i optimizacijama u
arhitekturi, jer takvo ponašanje sugerira da će i razvijene aplikacije na kraju biti
isto tako spore. Zbog načina rada, generiranja HTML-a na zahtjev iz
metapodataka, stječe se dojam da brzina rada aplikacije jako ovisi o složenosti
stranica, što može biti ograničavajući faktor.
O dizajnu sučelja treba reći da je pretrpio značajne promjene izdavanjem zadnje
verzije APEX-a. Osim modernijeg izgleda, napredovala je i organizacija, koja je u
prvi plan postavila mogućnosti koje prije nisu bile tako pristupačne (bile su
skrivene po izbornicima u zaglavlju), niti tako dobro razvijene (na primjer,
pretraživanje komponenti stranice, uređivanje svojstava pojedinih komponenti). Na
stranicu za razvoj stranica dodana je prilična količina sadržaja i stranica je postala
dinamička u ponašanju, što je definitivno puno ugodnije nego u prethodnoj verziji,
kad se uređivanje svake komponente učitavalo na novoj stranici. Ta promjena
postavila je i temelje za skupno uređivanje komponenti, koje prije nije bilo moguće.
S druge strane, novija verzija sučelja se može činiti prenatrpanom, jer se sastoji
od devet regija (zapravo tri vertikalne regije, ali dvije imaju po četiri kartice), a
nema skoro nikakvih mogućnosti prilagođavanja sučelja, a kamoli promjene
46
rasporeda regija. Velika prednost novog sučelja je uređivač koda, koji možda jest
relativno rudimentaran, ali sadrži validator SQL i PL/SQL koda i može se smatrati
napretkom u odnosu na obična tekstualna polja, koja su u prijašnjim verzijama
služila za unos koda.
Što se tiče samih mogućnosti razvoja, napravljene su neke promjene u vidu
povećanog ograničenja broja itema na stranici na 200, mogućnosti dizajniranja
stranice s više interaktivnih izvještaja i slično, po čemu se vidi da se alat i dalje
razvija i napreduje. Međutim, način razvoja aplikacije ostao je isti: na istim
mjestima se može upisati isti oblik i opseg koda, samo se vizualna organizacija
donekle promijenila.
Zbog načina na koji funkcionira spremanje i prikaz stranica, jasno je da se način
definiranja stranice ne može promijeniti bez promjene načina na koji funkcionira
engine. A s obzirom da se stranica definira kroz skup svojstava, uz poneki SQL
upit ili PL/SQL blok, rezultati ne mogu biti raznovrsni i do kraja fleksibilni. Za skup
najčešćih slučajeva razvoj ide jako brzo i u kratkom vremenu i uz malo truda se
može postići željena funkcionalnost. Međutim, sve što izlazi iz tog skupa, zahtijeva
sve više truda i sve dublje znanje JavaScripta i samog APEX-a, da bi se moglo
doći do kombinacije koja radi prema zamisli programera.
Ne može se reći da je alat ograničen, jer se čini da postoji rješenje za svaku
situaciju (više ili manje kompleksno), ali se može ustvrditi da su neke
funkcionalnosti učinjene puno kompleksnijima za implementaciju, kako bi neke
druge mogle biti jednostavnije.
Za mnoge složene zahtjeve koji se ne mogu prirodno i intuitivno ostvariti kroz
ugrađene procese APEX-a, korisnici su smislili vlastita rješenja koja mimoilaze
neke ugrađene procese, a koriste neke druge u novim i složenim kombinacijama.
Vrlo često se u rješenjima složenih zahtjeva pojavljuju JavaScript i AJAX, katkad i
u velikim količinama (čitave datoteke funkcija u JavaScriptu). Katkad, međutim, ta
rješenja ostavljaju dojam hakiranja, jer neka koriste APEX-ove interne procedure
koje nisu dio API-ja. Takva rješenja su manje popularna jer ih često treba
prepravljati na prijelazu verzija, zato što ne koriste isključivo javne API-je čija
sučelja teže biti konstantna. Međutim, generalno gledano, čini se da tvorcima
APEX-a ne smeta takvo poigravanje mogućnostima alata. Naprotiv, APEX
47
podržava razvoj pluginova. Postoji relativno ograničena ponuda službenih
nadogradnji, ali se zapravo ohrabruje ljude da razvijaju svoje vlastite, do te mjere
da sami programeri – autori APEX-a, objavljuju upute za izradu. (Wolf, 2009.)
Iako je ohrabrivanje zajednice korisnika u tom smislu pozitivno, čini se pomalo
nesrazmjerno da se APEX promovira kao alat za izradu web-aplikacija u PL/SQL-
u, kad je za izradu bilo kojeg složenijeg rješenja potrebno veliko znanje
JavaScripta. Potiče se migracija aplikacija iz Oracle Formsa u APEX (čak postoje
pomoćni alati u APEX-u za potporu takvom procesu – Converting Forms to APEX,
2009.) s glavnim argumentom sličnosti ta dva alata u korištenju PL/SQL-a kao
glavnog jezika za razvoj. No, sve ukazuje na to da u APEX-u PL/SQL ne može
postići sve funkcionalnosti koje može u Formsima.
Još jedna pozitivna strana APEX-a definitivno je financijska pristupačnost – dolazi
bez dodatne naplate uz svaku Oracleovu bazu podataka. S obzirom na potražnju
za alatom, koja se čini u konstantnom porastu, pomalo je iznenađujuće da je još
uvijek tako.
Prilično negativna i neugodna strana APEX-a, jako bitna za programere, je način
traženja pogrešaka u aplikaciji. Za JavaScript se može koristiti web-preglednik i
njegove nadogradnje, ali za PL/SQL je dostupan samo APEX. Popis svih
događaja i akcija na poslužitelju pri svakom slanju bilo kakvog zahtjeva za obradu
svakako je informativan, ali je vrlo nepregledan, posebno u složenim slučajevima.
A sigurno ne pomaže fiksna maksimalna duljina jednog zapisa u tom popisu, zbog
čega se neke poruke skrate i izgubi se dio informacija.
Druga glavna negativna strana je tzv. vendor lock-in. S obzirom da je APEX
engine vezan u bazu podataka Oracle, ekstremno je mala vjerojatnost da će netko
samoinicijativno držati podatke u bazi drugog proizvođača, pogotovo kad je jedini
način povezivanja s APEX-om prenošenjem podataka u Oracleovu bazu i natrag
jer im APEX drugačije ne može pristupiti. Također, aplikacije razvijene u APEX-u
su, dakle, teško primjenjive za obradu podataka iz baze podataka bilo kojeg
drugog proizvođača osim Oraclea, a ujedno su i neraskidivo povezane s APEX
engineom.
48
7. Zaključak
Razvoj web-aplikacije za vođenje računovodstva u APEX-u složen je iz više
razloga. Za početak, treba poznavati domenu, koja nije trivijalna. Poslovni procesi
su nejasni jer su podložni varijacijama, a brojnost različitih slučajeva obrade
podataka i međuovisnosti je teško uklopiti u računalni sustav čak i kad su procesi
jasni. Važna je preciznost i brzina, a i najmanji nedostatak će korisniku kad-tad
zasmetati, jer će ga usporiti ili zbuniti u ključnom trenutku. Aplikacija u isto vrijeme
treba biti fleksibilna, jer je puno varijabilnosti, i imati puno validacija, jer ima
podjednako puno međuovisnosti.
Najbolji način za razvoj aplikacije s takvim zahtjevima je razvijati aplikaciju od
početka. Bilo kakav pokušaj imitiranja već postojećih sustava, povećava
vjerojatnost ponavljanja pogreške u dizajnu koju je netko već napravio.
Nadalje, odabir tehnologije je za neke aspekte aplikacije bio potpuno odgovarajući,
a za neke druge aspekte prilično loš. APEX se u domenu računovodstvenog
servisa uklopio jer je tehnologija tankog klijenta i ne zahtijeva jako računalo, što je
poželjno za svakog poduzetnika, jer su jača računala ujedno i skuplja. S obzirom
da u okolini radi mali broj ljudi (5 – 10 ljudi) arhitektura ne zahtijeva čak ni jako
poslužiteljsko računalo. K tome, ima odlično razvijene interaktivne izvještaje, koji bi
se sigurno pokazali vrlo korisni, jednom kad bi se korisnici naviknuli na način
korištenja. S druge strane, web-tehnologija poput APEX-a i nije najbolji izbor za
aplikaciju od koje korisnici očekuju da bude interaktivna, da reagira na svaki novi
podatak koji unesu. Teoretski je moguće napuniti stranice za unos velikim
količinama JavaScripta i AJAX-a, međutim pitanje je koliko bi se brzo takve
stranice učitavale, pogotovo s obzirom na to da APEX nema kod stranica
pripremljen ili spremljen, već na svaki zahtjev za stranicom izrađuje HTML od
metapodataka. Za unos podataka u računovodstvu bi možda bili bolji Oracle
Forms, sa svojom čvrstom povezanosti s bazom i event-driven sučeljem.
Ograničavajući faktor u razvoju ove aplikacije nije bila nemogućnost tehnologije da
ostvari očekivani rezultat, već nedostatak znanja, a bilo je premalo vremena da se
taj nedostatak nadoknadi. Zasad se APEX čini kao tehnologija u kojoj postoji
rješenje za svaki problem, samo je stvar znanja koje programer posjeduje, količine
49
koda koju je spreman (ili sposoban) napisati i broja tehnologija koje je voljan
uključiti da potpomogne APEX u izvođenju scenarija koji su daleko od onih
bazičnih, pokrivenih APEX-ovim ugrađenim procedurama.
50
8. Literatura
[1] Jennings, T.; Cho, C.; Kallman, J.; Peake, D.; Sewtz, M.; Straub, J.;
Swadener, D.; Uvarov, V.; Wolf, P.: Oracle Application Express Installation
Guide, kolovoz 2015.,
https://docs.oracle.com/cd/E59726_01/install.50/e39144/toc.htm, zadnji
pristup: 29.6.2016.
[2] Jennings, T.; Cho, C.; Farrell, H.; Hichwa, M.; Kallman, J.; Kennedy, S.;
Peake, D.; Rayner, A.; Sewtz, M.; Spadafore, S.; Synders, J.; Straub, J.;
Swadener, D.; Wolf, P.: Oracle Application Express Application Builder
User's Guide, kolovoz 2015.,
https://docs.oracle.com/cd/E59726_01/doc.50/e39147/toc.htm, zadnji pristup:
29.6.2016.
[3] Jennings, T.; Cho, C.; Farrell, H.; Hichwa, M.; Kallman, J.; Kennedy, S.;
Neumueller, C.; Raynor, A.; Sewtz, M.; Snyders, J.; Straub, J.; Swadener, D.;
Unarov, V.; Wolf, P.: Oracle Application Express API Reference, kolovoz
2015., https://docs.oracle.com/cd/E59726_01/doc.50/e39149/toc.htm, zadnji
pristup: 29.6.2016.
[4] Roy, A.; Ferrante, M.; Satyanarayana, A.; Agarwal, V.; Balachandra, S.;
Bansal, H.; Mathew, L.; Singh, O.; Amalraj, J.; Kuhn, P.; Sadeghi, R.; Syed,
N.; deLaubenfels, E.; Ronald, G.: Oracle Fusion Middleware Forms Services
Deployment Guide 12c, lipanj 2016.,
https://docs.oracle.com/middleware/12211/formsandreports/deploy-
forms/toc.htm, zadnji pristup: 29.6.2016.
[5] Jew, P.; Rekadze, L.; Sullivan-Tarazi, O.; Marathe, H.; Moore, C.: Oracle
Fusion Middleware Administrator's Guide for Oracle Application Development
Framework 11g Release 2, travanj 2012.,
https://docs.oracle.com/cd/E26098_01/admin.1112/e16179/toc.htm, zadnji
pristup: 29.6.2016.
[6] Oracle Application Express Commercial Applications,
http://www.oracle.com/technetwork/developer-tools/apex/application-
express/apex-com-commercial-apps-094049.html, zadnji pristup: 29.6.2016.
[7] Perkušić, D.: Osnove računovodstva – vježbe. Web izdanje nastavnog
materijala, ožujak 2014.,
file:///C:/Users/Toshiba/Downloads/Nastavni_materijal_Osnove_racunovodst
va_RiF.pdf, zadnji pristup: 29.6.2016.
[8] Belak, V.; Brkanić, S.; Brkanić, V.; Dremel, N.; Garić, A.; Habek, M.; Jurić, Đ.;
Markota, Lj.; Mrša, J.; Proklin, P.; Turković-Jarža L.. Računovodstvo
51
poduzetnika s primjerima knjiženja, IV. nadopunjeno i izmijenjeno izdanje,
Zagreb: RRiFplus – d.o.o. za nakladništvo i poslovne usluge, ožujak 2005.
[9] Zakon o računovodstvu, na snazi od 1.1.2016.,
http://www.zakon.hr/z/118/Zakon-o-ra%C4%8Dunovodstvu, zadnji pristup:
29.6.2016.
[10] Zakon o obrtu, na snazi od 10.12.2013., http://www.zakon.hr/z/297/Zakon-o-
obrtu, zadnji pristup: 29.6.2016.
[11] Državni zavod za statistiku, Priopćenje: Broj i struktura poslovnih subjekata u
prosincu 2014., 16.2.2016, http://www.dzs.hr/Hrv_Eng/publication/2014/11-
01-01_04_2014.htm, zadnji pristup: 29.6.2016.
[12] JasperReports Server, http://community.jaspersoft.com/project/jasperreports-
server, zadnji pristup: 29.6.2016.
[13] Jaspersoft Studio, http://community.jaspersoft.com/project/jaspersoft-studio,
zadnji pristup: 29.6.2016.
[14] Antipa, D.: APEX and JasperServer Tunnel + Plugin, 2011.,
http://damien.antipa.at/2011/11/04/apex-and-jasperserver-tunnel-plugin/,
zadnji pristup: 29.6.2016.
[15] Cho, C.B.; How-To Document: Build Tabular Forms for Multi-Row
Operations, 14.1.2004., http://www.oracle.com/technetwork/developer-
tools/apex/tabular-form-090805.html#MANUAL, zadnji pristup: 29.6.2016.
[16] Buytaert, N.; Select2 APEX Plugin, 31.5.2016.,
https://apex.oracle.com/pls/apex/f?p=64237:20, zadnji pristup: 29.6.2016.
[17] Wolf, P.: Oracle APEX 4.0: How to create a Plug-in, 21.12.2009.,
http://www.inside-oracle-apex.com/oracle-apex-4-0-how-to-create-a-plug-in/,
zadnji pristup: 29.6.2016.
[18] Converting Your Oracle Forms Applications to Application Express 3.2, 2009,
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/prod/ap
pdev/apex/apexformmigr/apexformmigr.htm, zadnji pristup: 1.7.2016.
52
9. Sažetak
Web-aplikacija za vođenje financijskog računovodstva
Financijsko računovodstvo je sveprisutna disciplina današnjeg poduzetništva, sa
svoje dvije glavne grane: knjigovodstvom i financijskim izvješćivanjem.
Knjigovodstvo se sastoji od kontinuiranog unosa velike količine podataka o
poslovanju poduzetnika, kako bi se na kraju obračunskog razdoblja ili poslovne
godine mogli generirati zakonom propisani financijski izvještaji. Mikro i malim
poduzetnicima, te obrtnicima se zbog obujma posla ne isplati imati vlastito
računovodstvo, već plaćaju računovodstvenom servisu za računovodstvo kao
uslugu. Web-aplikacija za računovodstvo poduzetnika u računovodstvenom
servisu napravljena je u Oracle Application Expressu, a za generiranje precizno
nacrtanih izvještaja u .PDF formatu korišten je JasperReports Server.
Ključne riječi: Oracle, Application, Express, APEX, računovodstvo, knjigovodstvo,
servis, izvještaj, Jasper, web.
Financial Accounting Web Application
Financial accounting is an all-present discipline among entrepreneurs today, it's
two main branches being bookkeeping and financial reporting. Bookkeeping
consists of continuous input of large quantities of data about the entrepreneur's
business makings, with a goal of filling in statutory financial reports at the end of
an interval or a business year. It is not profitable for every small entrepreneur or
craftsman to have it's own accountant, so they are prone to paying for accounting
as a service. A financial accounting web application is made with Oracle
Application Express to help provide that service, and precisely drawn reports in
PDF are generated by JasperReports Server.
Keywords: Oracle, Application, Express, APEX, accounting, bookkeeping, service,
report, Jasper, web.