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.