RAZVOJ MODULA »DAVN A BLAGAJNA« ZA ODPRTOKODNI ERP … · Razvoj modula Davčna blagajna je obsegal predvsem: prilagoditev baze podatkov, razvoj vmesnika za upravljanje modula,

Magistrsko delo Organizacija in management informacijskih sistemov

RAZVOJ MODULA »DAVČNA BLAGAJNA« ZA ODPRTOKODNI ERP SISTEM

Mentor: red. prof. dr. Robert Leskovar Kandidat: Severin Kadrijevič

Kranj, marec 2018

ZAHVALA

Zahvaljujem se mentorju red. prof. dr. Robertu Leskovarju za vso pomoč, hitro odzivnost in prave usmeritve pri izdelavi magistrskega dela, družini pa za potrpežjivost in razumevanje.

POVZETEK V magistrskem delu je predstavljen postopek izdelave modula za odprtokodni informacijski sistem, ki omogoča potrjevanje računov na Finančni upravi Republike Slovenije (FURS). Kratko so predstavljena razvojna orodja in uporabljene tehnologije: programski jezik PHP, spletni strežnik Apache, baza podatkov MYSQL, protokola TLS in SOAP, XML, HTML in CSS. Opisani so bistveni gradniki informacijskega sistema Dolibarr. Razvoj modula Davčna blagajna je obsegal predvsem: prilagoditev baze podatkov, razvoj vmesnika za upravljanje modula, prilagoditev obstoječega modula Prodajno mesto, razvoj razreda za izmenjavo podatkov s Finančno upravo v programskem jeziku PHP in testiranje delovanja. Razviti modul je bil testiran s pomočjo posebnega portala na FURS-u. Testi so pokazali pravilno delovanje. Raziskava je potrdila, da modularna zgradba informacijskega sistema Dolibarr omogoča preprosto dodajanje novih funkcij.

KLJUČNE BESEDE:

– modularnost programske opreme – odprtokodni ERP sistem – davčno potrjevanje računov – davčna blagajna – XML izmenjava podatkov

ABSTRACT The master's thesis addresses the process of creating a module for an open source information system that enables the fiscal verification of invoices by the Financial administration of the Republic of Slovenia (FURS). Briefly are presented development tools and technologies used: PHP programming language, Apache web server, MySQL database, TLS and SOAP protocol, XML, HTML and CSS. The essential elements of the Dolibarr information system are described. Development of the “Davčna blagajna” module (tax cashier) comprised mainly the following: database modification, development of module setup page, modification of the existing module Point of sale, development of PHP class that enables data exchange with the FURS and testing. Module “Davčna Blagajna” was tested on dedicated FURS portal. The tests showed the proper functioning of develoed module. The research confirmed that the modular structure of the Dolibarr information system allows us to add new features easily.

KEYWORDS:

– software modularity – open-source ERP system – fiscal verification of invoices – tax cashier – XML data exchange

KAZALO

1. UVOD ............................................................................................................. 1 2. METODOLOGIJA DELA ........................................................................................ 2

2.1. DEFINICIJA PROBLEMA ................................................................................ 2 2.2. CILJI RAZISKAVE ......................................................................................... 2 2.3. PREDPOSTAVKE IN OMEJITVE ...................................................................... 2 2.4. METODE DELA ............................................................................................. 3

3. RAZVOJNA ORODJA .............................................................................................. 4 3.1. PROGRAMSKI JEZIK PHP .............................................................................. 4 3.2. SPLETNI STREŽNIK APACHE ......................................................................... 4 3.3. BAZA PODATKOV MYSQL ............................................................................. 4 3.4. XML IN SOAP ............................................................................................... 5 3.5. HTML IN CSS ............................................................................................... 6

4. CELOVIT INFORMACIJSKI SISTEM DOLIBARR .................................................... 8 4.1. JEDRO SISTEMA IN OSNOVNI MODULI .......................................................... 9 4.2. STRUKTURA PODATKOVNE BAZE ............................................................... 12 4.3. METODOLOGIJA RAZVOJA MODULA .......................................................... 14

5. RAZVOJ MODULA DAVČNA BLAGAJNA .......................................................... 17 5.1. PRIPRAVA RAZVOJNEGA OKOLJA .............................................................. 21 5.2. PRIDOBITEV NAMENSKEGA DIGITALNEGA POTRDILA ................................. 22 5.3. PRILAGODITEV STRUKTURE PODATKOVNE BAZE ....................................... 22 5.4. RAZVOJ VMESNIKA ZA UPRAVLJANJE DAVČNE BLAGAJNE ......................... 25 5.5. POVEZOVANJE NA INFORMACIJSKI SISTEM FINANČNE UPRAVE .................. 28 5.6. ELEKTRONSKO PODPISOVANJE DOKUMENTOV XML ................................... 29 5.7. IZMENJAVA PODATKOV Z DAVČNIM ORGANOM .......................................... 31

5.7.1. PODATKI O POSLOVNEM PROSTORU ................................................... 32 5.7.2. PODATKI O IZDANEM RAČUNU............................................................ 41

5.8. GRAFIČNI VMESNIK MODULA DAVČNA BLAGAJNA ...................................... 51 5.9. IZPIS RAČUNA IN QR KODE ........................................................................ 57 5.10. TESTIRANJE DELOVANJA MODULA .............................................................. 61

6. ZAKLJUČKI ....................................................................................................... 67 LITERATURA IN VIRI ................................................................................................ 68

PRILOGE .............................................................................................................. 69 KAZALO SLIK ....................................................................................................... 70 KAZALO TABEL .................................................................................................... 70 POJMOVNIK ......................................................................................................... 70 KRATICE IN AKRONIMI ......................................................................................... 71

Univerza v Mariboru – Fakulteta za organizacijske vede Magistrsko delo

Severin Kadrijevič: Razvoj modula »Davčna blagajna« za odprtokodni ERP sistem stran 1

1. UVOD

V dobi digitalizacije in povezave razvijalcev iz vsega sveta smo priča velikemu porastu razvoja programske opreme, ki jo razvija internetna skupnost razvijalcev. Le-ti vsak po svoje pripomorejo k razvoju določene programske rešitve. Največja podjetja, ki razvijajo informacijske sisteme pod lastno blagovno znamko, so Oracle, SAP in Microsoft. Njihove programske rešitve so celovite, toda tudi drage. Da bi zmanjšali stroške razvoja, številna podjetja uporabljajo tudi odprtokodno programsko opremo bodisi kot module, bodisi kot osnovo za lastne prilagoditve. Bistveno je, da izbrana programska oprema ustreza potrebam naročnika in zagotavlja podporo večjemu številu poslovnih procesov. Seveda pa več funkcij ne pomeni tudi boljši informacijski sistem. Pri izbiri informacijskega sistema moramo biti pozorni tudi na zagotovitev vzdrževanja in razširljivost, saj rast podjetja sproži tudi potrebe po novih funkcionalnostih informacijskega sistema. Naročniki oz. kupci programske opreme pričakujejo, da informacijski sistem omogoča razširitev funkcij, namestitev dodatnih modulov, podpira vtičnike in dodatke. Zato so močni odločitveni dejavniki predvsem kakovostna tehnična dokumentacija, številčnost skupnosti razvijalcev in uporabljene tehnologije. Večina odprtokodnih informacijskih sistemov deluje kot spletna aplikacija. Lahko jih prenesemo s spleta in namestimo na svoj spletni strežnik, uporabnik pa do podatkov dostopa preko spletnega brskalnika. Za delovanje na strani uporabnika tako ni potrebna namestitev dodatne programske opreme. Obstaja več dobro zasnovanih, zmogljivih in prilagodljivih celovitih odprtokodnih informacijskih sistemov. Najbolj popularni so Odoo, ERPNext, Dolibarr in Opentaps (opensource.org, 2018). Zelo uspešen projekt je Dolibarr. Razvijalci celovitega informacijskega sistema Dolibarr so razdeljeni v dve skupini: ena razvija jedro samega sistema (angl. »core«), druga pa je usmerjena na razširitvene module. Razvijalska skupnost je tako zelo dobro razvita in organizirana, delno so grafični vmesniki prevedeni tudi v slovenščino. Pomanjkljivost za slovenska podjetja je, da ne upošteva nekaterih posebnosti slovenske zakonodaje in računovodskih standardov. Verjetno je ena izmed ključnih pomanjkljivosti nezmožnost davčnega potrjevanja računov. V magistrskem delu bomo razvili modul za odprtokodni informacijski sistem Dolibarr, ki bo omogočal potrjevanje računov na Finančni upravi Republike Slovenije. Kratko bodo predstavljena razvojna orodja in uporabljene tehnologije. Opisani bodo bistveni gradniki informacijskega sistema Dolibarr. Razvoj modula Davčna blagajna bo obsegal prilagoditev baze podatkov, razvoj vmesnika za upravljanje modula, prilagoditev obstoječega modula Prodajno mesto, razvoj razreda za izmenjavo podatkov s Finančno upravo v programskem jeziku PHP in testiranje delovanja. Na podlagi razvoja funkcij za davčno potrjevanje računov v obliki modula bomo prikazali modularno zgradbo in razširljivost odprtokodnega sistema Dolibarr.



2. METODOLOGIJA DELA

2.1. DEFINICIJA PROBLEMA V Sloveniji se je z začetkom veljave Zakona o davčnem potrjevanju računov z 2. januarjem 2016 začela uporaba davčnih blagajn. Blagajne zavezancev se morajo preko spleta povezati s centralnim informacijskim sistemom Finančne uprave Republike Slovenije. Finančna uprava Republike Slovenije pri gotovinskem poslovanju v postopku njihove izdaje v realnem času potrdi in shrani podatke o računih, kar omogoča sledljivost in učinkovitost nadzora nad izdanimi računi ter omejuje sivo ekonomijo (FURS, 2016). Celoviti informacijski sistem Dolibarr, ki ga obravnavamo v tem magistrskem delu, pa davčnega potrjevanja računov ne podpira, saj večina držav po svetu davčnih blagajn ne uporablja in tako razvijalci te funkcionalnosti še niso razvili. Informacijski sistem Dolibarr je navdušil kar nekaj uporabnikov tudi v Sloveniji, ki ta informacijski sistem že uporabljajo, vendar se nihče od razvijalcev še ni lotil razvoja te funkcije. Tako so uporabniki omejeni na uporabo že razvitih funkcij in modulov, za potrebe davčnega potrjevanja računov pa morajo uvesti drugo rešitev. Tako z uvedbo raznolikih tehnologij prihaja do fragmentacije podatkov in posledično manjše učinkovitosti informacijskega sistema.

2.2. CILJI RAZISKAVE Cilji raziskave so:

– pregledati literaturo o celovitem informacijskem sistemu Dolibarr,

– razviti modul za informacijski sistem Dolibarr za davčno potrjevanje računov,

– natančno in sistematično opisati proces razvoja modula, – testirati razviti modul.

2.3. PREDPOSTAVKE IN OMEJITVE Povezava blagajn z informacijskim sistemom FURS za izmenjavo podatkov v realnem času se mora izvesti preko interneta. Trenutno so podatki o izdanih računih shranjeni na blagajni pri zavezancu, po zakonu, ki ureja davčne blagajne, pa se morajo podatki o računu pred izdajo poslati na FURS (»on-line« sistem). Blagajna mora generirati elektronsko podpisano XML datoteko s podatki o izdanem računu in jo poslati na FURS. Informacijski sistem FURS preveri poslane podatke in pošlje blagajni posebno enkratno identifikacijsko številko računa, ki mora biti izpisana na računu (www.fu.gov.si, 2016). Pomembna lastnost informacijskega sistema Dolibarr je modularnost, ki nam omogoča razvoj dodatne funkcionalnosti sistema, neodvisno od jedra in ostalih



komponent sistema, podpira pa tudi objektno orientiran razvoj. Tako bomo pri razvoju lahko uporabili tudi že napisano programsko kodo za uporabo funkcij, ki jih sistem že uporablja. Vsa programska koda je dosegljiva na spletnih straneh dolibarr.org. Prav tako je na spletnem portalu skupnosti Dolibarr pripravljena obsežna dokumentacija za razvoj modula. Pri razvoju se bomo omejili na razvojne metodologije, ki so predlagane in dokumentirane v razvojni dokumentaciji informacijskega sistema Dolibarr. Ob upoštevanju predlagane metodologije je potrebno modul za informacijski sistem Dolibarr razvijati po točno določenem postopku, pri tem pa moramo za aktivacijo modula in pripravo razvojnega okolja nujno opraviti naslednje korake:

– pripraviti opis (t. i. deskriptor) za modul po določenih pravilih, – pripraviti drevesno strukturo map, določenih po pravilih za razvoj modula.

Za razvoj modula je na voljo predloga z datotekami, ta pa vključuje deskriptor in ostale datoteke, ki jih modul potrebuje.

2.4. METODE DELA Pri razvoju smo uporabili razvojno metodologijo, ki jo je za razvoj modula predpisala skupnost Dolibarr, vsi razvojni koraki pa so dobro dokumentirani v razvojni dokumentaciji. Za definiranje zahtev, ki jih mora izpolnjevati blagajna za davčno potrjevanje računov, pa smo uporabili razvojno dokumentacijo, ki jo je za razvijalce pripravil FURS. V začetni fazi smo najprej definirali poslovne potrebe, ki naj bi jih zagotovil razviti modul s pomočjo jezika za modeliranje UML. Testiranje pa smo izvedli s pomočjo portala FURS, ki je namenjen testiranju in pregledu poslanih podatkov o poslovnem prostoru in izdanem računu. Celotni razvoj smo podkrepili s študijem domače in tuje literature. Uporabili smo naslednja razvojna orodja in tehnologije:

– jezik za modeliranje UML, – programski jezk PHP, – podatkovno bazo MySQL, – HTML in CSS.



3. RAZVOJNA ORODJA

3.1. PROGRAMSKI JEZIK PHP PHP je odprtokodni programski jezik in je močno orodje za razvoj dinamičnih in interaktivnih spletnih vsebin. Koda se izvaja na strežniški strani, spletni strežnik pa ima to funkcijo, da interpretirano izvorno kodo pošlje brskalniku v obliki HTML kode. PHP je zelo široko uporabljan. Uporabljajo ga Facebook, Wikipedia, Yahoo in še bi lahko naštevali. Ogromno odprtokodnih projektov je razvitih v programskem jeziku PHP, bolj znani med njimi so Wordpress, Joomla in Moodle. PHP omogoča proceduralno in objektno programiranje (php.net, 2017). Slika 1 prikazuje primer uporabe PHP programskega jezika, vključenega v HTML kodo.

Slika 1: PHP v HTML kodi

3.2. SPLETNI STREŽNIK APACHE Primarna funkcija spletnega strežnika je shranjevanje, obdelava in pošiljanje spletnih strani uporabnikom. Komunikacija med odjemalcem in strežnikom temelji na protokolu HTTP, uporabniki pa do vsebin, kot so spletne strani, dostopajo preko spletnega brskalnika. Spletni strežnik Apache je med najbolj priljubljenimi spletnimi strežniki, je odprtokoden, njegova uporaba pa je brezplačna. Apache razvija in vzdržuje odprta skupnost razvijalcev (apache.org, 2018).

3.3. BAZA PODATKOV MYSQL MySQL je sistem za upravljanje z bazami podatkov in je odprtokodna implementacija relacijske baze podatkov, ki za delo s podatki uporablja jezik SQL.



MySQL deluje na principu odjemalec – strežnik. Strežnik lahko namestimo kot sistem, porazdeljen na več strežnikov. Za dostop do podatkovne baze MySQL obstaja veliko število programskih vmesnikov, zbirk ukazov in odjemalcev. Sintaksa, ki jo uporabljamo pri delu z bazo podatkov, je standardni SQL z manjšimi dodatki. MySQL uporablja ogromno spletnih strani po celem svetu in je na tem področju najbolj popularna. Najpogosteje se uporablja v kombinaciji s programskim jezikom PHP. Veliko največjih in najhitreje rastočih organizacij na svetu, kot so Facebook, Google, Adobe, Alcatel Lucent in Zappos, se zanaša na MySQL, da prihranijo čas in denar, s čimer napajajo svoje obsežne spletne strani, ključne poslovne sisteme in programsko opremo (mysql.com, 2018).

3.4. XML IN SOAP XML je okrajšava za angleški izraz »Extensible Markup Language«, slovensko pa mu rečemo razširljivi označevalni jezik. XML je preprost računalniški jezik, podoben jeziku HTML. Zahteva strogo strukturirane podatke in je zato pogosto uporabljen za opis poslovnih dokumentov (račun, naročilnica ipd.). Zaradi preprostega, človeku berljivega formata je zelo primeren za izmenjavo med različnimi sistemi in spreminja mnogo aspektov računalništva na področju komuniciranja aplikacij in strežnikov. Da se ga tudi razširiti, saj dopušča možnost, da si sami izmislimo imena oznak (ang. »tag«). Zelo je uporaben za komunikacijo, saj ima zelo preprosto in pregledno zgradbo. XML je razdeljen na 3 dele (w3.org, 2018a):

– podatkovni (vanj shranimo podatke v neki obliki z želenimi oznakami – tagi),

– deklarativni (skrbi za to, da lahko pri dodajanju novih podatkov vidimo, kaj kakšna oznaka predstavlja),

– predstavitveni (z njim oblikujemo izpis podatkov). XML se pogosto uporablja za izmenjavo podatkov med različnimi sistemi. Primer dokumenta v XML prikazuje slika 2.



Slika 2: XML koda

SOAP (Simple Objects Access Protocol) je protokol, ki omogoča komunikacijo med ponudnikom storitev in odjemalcem. Deluje na principu klica oddaljene procedure (RPC – Remote Procedure Call), za kar uporablja sintakso XML (Extensible Markup Language). Prednosti SOAP protokola so v njegovi neodvisnosti od programskih jezikov, transportnega (prenosnega) protokola (HTTP, SMTP, FTP ali drugi), operacijskega sistema in strojne platforme (w3.org, 2018b).

3.5. HTML IN CSS HTML je označevalni jezik, ki se uporablja za izdelavo spletnih strani in predstavlja osnovo spletnega dokumenta. Z njim določimo zgradbo in semantični pomen delov dokumenta. HTML dokument lahko izdelamo in urejamo v vsakem urejevalniku besedil (kot npr. beležnici). Zapisan je v obliki elementov HTML, ki so sestavljeni iz oznak, zapisanih v posebnih oklepajih (npr. <p>) znotraj vsebine spletne strani. Oznake HTML so običajno zapisane v parih, npr. <p> in </p>, z začetno in končno oznako. Znotraj para oznak pa lahko oblikovalec spletne strani vpiše poljubno besedilo in tudi druge oznake (w3.org, 2018). CSS so predloge, predstavljene v obliki preprostega slogovnega jezika. Uporabljajo se za predstavitev spletnih strani in z njimi definiramo stil HTML oz. XHTML elementov v smislu pravil, kako naj se ti prikažejo na strani. Z njimi lahko določimo barve, velikosti znakov, poravnave, odmike, obrobe, pozicije in ostale lastnosti, prav tako pa lahko nadziramo tudi aktivnosti, ki jih uporabnik nad elementi strani izvaja (npr. prekritje povezave z miško). Predloge so bile razvite z namenom konsistentnega načina podajanja informacij o stilu spletnega dokumenta. Bistvena vloga CSS je poleg definiranja pravil predvsem ločitev strukture strani, ki jo podaja označevalni jezik skupaj z vsebino od njene predstavitve, saj tako omogočimo lažje urejanje in dodajanje stilov. S tem pridobimo na preglednosti dokumentov, ki temeljijo na HTML. Z uporabo istih predlog na množici strani pa lahko zmanjšamo tudi ponavljanje kode (Lie & Bos, 1999). Sintakso CSS lahko vključimo tudi v HTML datoteko tako, da lastnosti CSS vnesemo v HTML oznako »style«. Primer lastnosti CSS, vključenih v HTML, prikazuje slika 3.



Slika 3: CSS lastnosti vključene v HTML



4. CELOVIT INFORMACIJSKI SISTEM DOLIBARR

Dolibarr je odprtokodni informacijski sistem, primeren za mala in srednje velika podjetja, fundacije ali samostojne podjetnike. Vključuje različne funkcije za načrtovanje poslovnih virov (ERP) in upravljanje odnosov s strankami (CRM), podpira pa tudi druge funkcije za različne dejavnosti. Informacijski sistem Dolibarr je aprila 2002 pričel razvijati Rodolp Quiedeville. V tem času je Jean-Louis Bergamo začel pisati modul za upravljanje jedra sistema. Različica 1.0 je bila izdana septembra 2003, 20. aprila 2009 pa je bila ustanovljena fundacija Dolibarr in več skupin uporabnikov v več državah. Največ razvijalcev in uporabnikov izvira iz Francije, kjer je informacijski sistem Dolibarr tudi najbolj poznan. Njegova priljubljenost v Franciji se je povečala potem, ko jo je več državnih agencij prosto razdelilo ustanoviteljem novih podjetij. Uporablja se tudi v mnogih drugih državah in je preveden v več kot 50 jezikov (Wikipedia.org, 2018). Nagrade, ki jih je prejel projekt Dolibarr (Wikipedia.org, 2018):

• 1. mesto v kategoriji "Družba za upravljanje" na tekmovanju Les Trophées du Libre leta 2003,

• Sourceforge projekt tedna v marcu 2014, • Sourceforge projekt tedna v septembru 2015, • Sourceforge projekt tedna v septembru 2016.

Slika 4 prikazuje podprte funkcije odprtokodnega informacijskega sistema Dolibarr.

Slika 4: Podprte funkcije odprtokodnega informacijskega sistema Dolibarr (dolibarr.org, 2017)



Informacijski sistem Dolibarr lahko namestimo na osebni računalnik in ga uporabljamo kot samostojno aplikacijo ali pa ga namestimo na spletni strežnik. Pri spletni različici lahko do programa dostopamo preko računalniškega omrežja, s tem pa omogočimo istočasno uporabo večjega števila uporabnikov. Deluje na vseh operacijskih sistemih, prilagojen pa je tudi za uporabo na mobilnih napravah (dolibarr.org, 2017). Slika 5 prikazuje zaslon finančnega modula v odprtokodnem informacijskem sistemu Dolibarr.

Slika 5: Odprtokodni informacijski sistem Dolibarr Informacijski sistem Dolibarr je razvit v programskem jeziku PHP. Deluje z vsemi verzijami PHP in ne zahteva dodatnih modulov PHP. Uporablja bazo podatkov MySQL. Za uporabnike, ki nimajo dovolj računalniškega znanja, pa je na voljo tudi samodejni namestitveni program, ki namesti vse potrebno za uporabo programa na osebnem računalniku. Ta je na voljo za operacijske sisteme Windows, Mac in Linux. Različice se imenujejo DoliWamp za operacijski sistem Windows, DoliDeb za operacijske sisteme Debian in Ubuntu ter DoliRpm za operacijske sisteme Fedora, Redhat, Mandriva ali OpenSuse (Dolibarr.org, 2018).

4.1. JEDRO SISTEMA IN OSNOVNI MODULI Jedro informacijskega sistema Dolibarr vsebuje vse pomembne značilnosti ERP in CRM programske opreme. Sistem je modularen, zato je namestitev in uporaba



enostavna kljub velikemu številu funkcij oziroma modulov. Nekatere module, ki predstavljajo jedro oziroma standardno različico sistema, lahko enostavno omogočimo brez dodatnih namestitev in tako razširimo funcionalnosti informacijskega sistema glede na potrebe.

Standardna različica informacijskega sistema Dolibarr vključuje naslednje module (wiki.dolibarr.org, 2018a):

– vodenje prodaje, – upravljanje nabave, – upravljanje odnosov s strankami, – katalog izdelkov in storitev, – upravljanje zalog, – koledar, – upravljanje dogodkov, – upravljanje bančnih računov, – imenik, – upravljanje članov, – upravljanje plačil, – upravljanje donacij, – upravljanje ponudb, – upravljanje pogodb, – upravljanje naročil, – upravljanje dostave blaga, – prodajno mesto, – elektronsko upravljanje dokumentov, – vodenje projektov, – ankete, – generiranje PDF dokumentov, – poročanje, – čarovnik za pomoč pri izvozu/uvozu podatkov, – povezljivost LDAP.

Slika 6 prikazuje zaslon za upravljanje modulov, kjer lahko posamezen modul vključimo in prilagodimo nastavitve:



Slika 6: Zaslon za upravljanje modulov

V nastavitvah informacijskega sistema Dolibarr lahko upravljamo z moduli na način, da jih omogočimo, spreminjamo parametre in urejamo nastavitve posameznega modula, lahko pa tudi nameščamo nove module, ki razširjajo funkcionalnosti informacijskega sistema. Moduli se delijo na osnovne in eksterne. Osnovni omogočajo temeljne funkcionalnosti, eksterni pa so povsem neodvisni od jedra sistema. Razvijamo jih lahko sami, mnogo modulov je brezplačno dosegljivih na portalu Dolibarr.org, nekatere pa lahko kupimo v trgovini Dolistore, kjer razvijalci ponujajo dodatne module.

Ostale lastnosti informacijskega sistema Dolibarr: – večjezična podpora, – prijaznost do uporabnika, – možnost izbire predlog, – prilagodljivost in modularnost, – podpora za več različnih valut, – večuporabniški sistem z več nivoji dovoljenj za vsako funkcijo, – delovanje na podatkovni bazi MySQL 4.1 in novejših različicah, – delovanje v PHP 5.3 in novejših različicah.

Bistvene pomanjkljivosti informacijskega sistema Dolibarr pa so:

– možno je upravljati le eno podjetje; za upravljanje dveh različnih podjetij je potrebno sistem namestiti ločeno dvakrat ali namestiti zunanje razširitve;

– upravljanje s človeškimi viri ni popolnoma podprto;



– ne omogoča davčnega potrjevanja računov po Zakonu o davčnem potrjevanju računov (ZDavPR).

4.2. STRUKTURA PODATKOVNE BAZE Podatkovna baza informacijskega sistema Dolibarr vsebuje 148 tabel. Nekatere tabele sestavljajo jedro informacijskega sistema, mnogo pa jih pripada različnim funkcijskim modulom (tabela 1).

Ime tabele Ime tabele Ime tabele

llx accountingaccount llx categorie member llx mailing

llx accountingdebcred llx categorie product llx mailing cibles

llx accountingsystem llx categorie societe llx menu

llx accountingtransaction llx chargesociales llx notify

llx actioncomm llx commande llx notify def

llx adherent llx commande fournisseur llx paiement

llx adherent options llx commande fournisseur dispatch

llx paiement facture

llx adherent options label llx commande fournisseur log

llx paiementcharge

llx adherent type llx commande fournisseurdet

llx paiementfourn

llx bank llx commandedet llx paiementfourn facturefourn

llx bank account llx compta llx prelevement bons

llx bank categ llx compta account llx prelevement facture

llx bank class llx compta compte generaux

llx prelevement facture demande

llx bank url llx const llx prelevement lignes

llx bookmark llx contrat llx prelevement notifications

llx bordereau cheque llx contratdet llx prelevement rejet

llx boxes llx contratdet log llx product

llx boxes def llx cotisation llx product batch

llx c action trigger llx deplacement llx product fournisseur price

llx c actioncomm llx document llx product fournisseur price log

llx c availability llx document model llx product lang

llx c barcode type llx informacijski sistem Dolibarr modules

llx product lot

llx c chargesociales llx domain llx product price

llx c civilite llx don llx product stock

llx c country llx ecm directories llx projet

llx c currencies llx ecm documents llx projet task



llx c departements llx element contact llx projet task actors

llx c ecotaxe llx element element llx projet task time

llx c effectif llx entity llx propal

llx c forme juridique llx entrepot llx propaldet

llx c input method llx events llx rights def

llx c input reason llx expedition llx societe

llx c paiement llx expeditiondet llx societe adress

llx c paper format llx expeditiondet batch llx societe commerciaux

llx c payment term llx export compta llx societe log

llx c propalst llx export model llx societe prices

llx c prospectlevel llx extrafields llx societe remise

llx c regions llx facture llx societe remise except

llx c revenuestamp llx facture fourn llx societe rib

llx c shipment mode llx facture fourn det llx socpeople

llx c stcomm llx facture rec llx stock mouvement

llx c tva llx facturedet llx tva

llx c type contact llx facturedet rec llx user

llx c type fees llx fichinter llx user alert

llx c typent llx fichinterdet llx user clicktodial

llx categorie llx import model llx user entrepot

llx categorie association llx livraison llx user param

llx categorie fournisseur llx livraisondet llx user rights

llx usergroup

llx usergroup rights

llx usergroup user

Tabela 1: Seznam tabel informacijskega sistema Dolibarr (dolibarr.org, 2018a) Bistvene tabele, ki predstavljajo jedro informacijskega sistema Dolibarr so:

– llx modules – vsebuje seznam aktiviranih modulov z datumom aktiviranja in različico aktiviranega modula,

– llx facture – vsebuje podatke o izdanih računih; podrobnosti računa so v tabeli llx_facturedet,

– llx facturedet – vsebuje vrstice računov; ta tabela je povezana s tabelo llx_facture,

– llx menu – vsebuje podatke o menijih, – llx paiement – vsebuje podatke o plačilih; relacija med izdanim računom

in plačilom je določena v tabeli llx_paiement_facture, – llx product – vsebuje seznam izdelkov in storitev, – llx propal – vsebuje podatke o izdanih ponudbah, – llx propaldet – vsebuje podrobnosti o izdanih ponudbah, – llx rights def – vsebuje podatke o pravicah uporabnikov, – llx societe – vsebuje seznam tretjih oseb,



– llx user – vsebuje podatke o uporabnikih skupaj z njihovim uporabniškim imenom in geslom.

Za urejanje podatkov v bazi podatkov je za informacijski sistem Dolibarr na voljo že pripravljen razred v programskem jeziku PHP. V spodnjih štirih vrsticah so prikazane javne metode, ki se uporabljajo za vnos, posodobitev ali brisanje podatkov v tabeli (dolibarr.org, 2018c): $db->begin(); // Start transaction $db->query("My SQL request insert, update or delete"); $db->commit(); // Validate transaction or $db->rollback() // Cancel transaction

Branje podatkov iz tabele lahko izvedemo na način, kot je prikazano na spodnjem primeru (dolibarr.org, 2018c): $resql=$db->query("My select request"); if ($resql) { $num = $db->num_rows($resql); $i = 0; if ($num) { while ($i < $num) { $obj = $db->fetch_object($resql); if ($obj) { // You can use here results print $obj->field1; print $obj->field2; } $i++; } } }

4.3. METODOLOGIJA RAZVOJA MODULA Pri razvoju informacijskega sistema se pogosto srečujemo z vprašanjem, katere tehnologije uporabiti, da bo aplikacija razvita v kar najkrajšem času, s čim nižjimi stroški ter pozneje razširljiva. Dobra lastnost celovitega informacijskega sistema Dolibarr je modularnost. Uporabniška dokumentacija podrobno opisuje delovanje sistema, jedro in glavne module. Na voljo pa je tudi razvojna dokumentacija. Ta podrobno opisuje razvojne pristope, ki naj bi jih uporabili razvijalci za razvoj lastnega modula. Programska koda je objektno orientirana, kar nam omogoča ponovno uporabo že pripravljenih funkcij. Že vrsto let poznamo orodja, ki omogočajo generiranje kode in skript na podlagi konceptualnih podatkovnih modelov. S standardizacijo jezika za vizualno modeliranje programske opreme (UML) ter razvojem vedno zmogljivejših orodij za generiranje kode je tudi ta pristop k razvoju informacijskih sistemov dobil nov zagon (Damjan Vavpotič, Marko Bajec, 2006).



Tudi skupnost Dolibarr je predvidela razvojno metodologijo MDA (Model Driven Arhitecture). V razvojni dokumentaciji je na kratko predstavljen pristop MDA, ki se lahko uporabi za razvoj modula (Dolibarr.org, 2017). Osnovno vodilo razvoja programske opreme na podlagi modulov je, da se razvijalci posvetijo predvsem funkcionalnosti sistema oziroma določijo njegove bistvene funkcije, namesto da v programskem jeziku opisujejo tehnološke podrobnosti njegovega delovanja. Razvijalci opišejo funkcionalnosti na abstraktnem nivoju, v veliki meri z uporabo vizualnih modelov sistema. Osnovna zahteva za te abstraktne modele je, da so splošni, kar pomeni, da so neodvisni od uporabljene platforme in tehnologije, ali z drugimi besedami, da opisujejo izključno funkcionalne zahteve (Damjan Vavpotič, Marko Bajec, 2006). Vsekakor ima razvojna metodologija MDA ogromno dobrih lastnosti, vendar pa je ta pristop za razvoj modula v informacijskem sistemu Dolibarr slabo dokumentiran. Očitno ta metodologija ni bila deležna večjega uspeha, saj so za razvoj modula na voljo še drugi razvojni pristopi, ki zagotavljajo učinkovit in kakovosten razvoj (wiki.dolibarr.org, 2018b). Poleg razvojne metodologije MDA je za razvoj modula v informacijskem sistemu Dolibarr dokumentiran tudi drugi razvojni pristop, pri katerem razvijalec sledi razvojnim korakom. V dokumentaciji za razvoj modula so zelo podrobno opisana pravila za razvoj modula, globalne spremenljivke in razredi, dosegljiva pa je tudi predloga z datotekami, ki služi kot osnova za razvoj modula. Predstavljeni so tudi primeri dobrih praks (dolibarr.org, 2018c). Dokumentacija za razvoj modula opisuje naslednje korake (dolibarr.org, 2018c):

– priprava deskriptorja za modul, – priprava drevesne strukture map in datotek (obvezno), – priprava tabel podatkovne baze SQL (neobvezno), – priprava skript SQL za generiranje tabel ob aktivaciji modula, – ureditev navigacijskih elementov na straneh modula, – priprava novih zaslonov v PHP, obrazcev za vnos podatkov, – dodajanje polj v obstoječe obrazce, – ureditev dostopa do baze podatkov, – priprava strani za upravljanje nastavitev modula (neobvezno), – priprava strani za urejanje parametrov modula, – vnos povezave do modula v menije, – testiranje modula.

Podrobnejša navodila za razvoj različnih elementov informacijskega sistema Dolibarr so na voljo v obširni dokumentaciji za razvijalce (dolibarr.org, 2018b) in se nanašajo na:

– pravila kodiranja in najboljše prakse, – razvojno organiziranost in orodja, – seznam modulov, – pravila za razvoj novega modula in predloge za grafični vmesnik, – razvoj ukaznih skript,



– tehnični deli sistema Dolibarr, – drevesno strukturo map, – poslovne objekte, – menijski sistem, – sistem zavihkov, – sistem za upravljanje oblike in predlog, – sistem za upravljanje z dovoljenji, – sistem za upravljanje jezikov, – upravljanje napak, – sistem sprožilcev, – sistem konstant in spremenljivk, – spletne storitve, – upravljanje z datotekami in dokumenti, – številčne module, – predloge dokumentov in izdelava dokumentov, – dodatna polja, – druge notranje funkcije, – masovni uvoz in izvoz podatkov, – vmesnike in povezave z drugimi programi.



5. RAZVOJ MODULA DAVČNA BLAGAJNA

Pred pričetkom razvoja modula za davčno potrjevanje računov smo preučiti Zakon o davčnem potrjevanju računov in tehnične specifikacije s podrobnostmi o uporabljeni tehnologiji in tehničnih zahtevah FURS-a. Za namene davčnega potrjevanja računov morajo zavezanci imeti blagajne, skladne z Zakonom o davčnem postopku. Ta določa, da zavezanec za davek ne sme imeti ali uporabljati računalniškega programa ali elektronske naprave, ki omogoča brisanje, prilagajanje, popravljanje, razveljavljanje, nadomeščanje, dodajanje, skrivanje ali kakršnokoli drugo spreminjanje kateregakoli zapisa. Program oziroma naprava mora biti taka, da omogoča sledenje vseh sprememb. Poleg tega pa mora omogočati tudi elektronsko podpisovanje z namenskim digitalnim potrdilom. Slika 7 prikazuje pogoje, ki jih mora zavezanec za obvezno uporabo ZdavPR izpolnjevati.

Slika 7: Zavezanec po Zakonu o davčnem potrjevanju računov (FURS, 2015) Računov za negotovinska plačila ni treba potrjevati, račune za gotovinska pa. Da je račun plačan z gotovino, se šteje, če je plačan na katerikoli način, ki ni neposredno nakazilo na transakcijski račun. Primeri, pri katerih je obvezno potrjevanje računov, ker gre za plačilo z gotovino, so (pisrs.si, 2018b):

– plačilo z bankovci in kovanci, ki so v obtoku kot plačilno sredstvo, – plačilo s kreditno kartico, razen če je opravljeno preko ponudnika plačilnih

storitev (na primer bank, hranilnic, pošte, sistema PayPal), – plačilo vrednostnega bona za konkretno blago ali storitev,



– plačilo z Moneto, – plačilo s poslovno kartico zavezanca, – plačilo blaga po povzetju z gotovino poštarju ali s poštno nakaznico.

Pred začetkom potrjevanja računov mora zavezanec:

– zagotoviti blagajniški program za izdajanje računov (blagajna) z zanesljivo internetno povezavo z davčnim organom;

– popisati poslovne prostore; – pridobiti namensko digitalno potrdilo; – sprejeti interni akt, v katerem bo določil pravila za dodeljevanje

zaporednih številk računov (tudi zavezanci, ki uporabljajo VKR); ta se ne pošilja na FURS, v primeru nadzora pa ga je potrebno pokazati;

– na vseh prodajnih mestih objaviti obvestilo o obveznosti izdaje računa v predpisani obliki.

Pri razvoju modula za davčno potrjevanje računov po Zakonu o davčnem potrjevanju računov (ZDavPR) smo se oprli na tehnično specifikacijo, ki jo je za razvijalce pripravil FURS. Dosegljiva je na naslovu http://www.datoteke.fu.gov.si/dpr/index.html in vsebuje vse potrebne tehnične podatke za razvoj davčne blagajne, vključno s shemami in nekaterimi primeri kode, testnim okoljem in spletnim vmesnikom za preverjanje poslanih podatkov o poslovnih prostorih in izdanih računih (fu.gov.si, 2018). Pred pričetkom razvoja programske kode smo pripravili UML diagram primerov uporabe. Diagram na sliki 8 prikazuje:

– blagajnik se mora pred uporabo modula Davčna blagajna prijaviti, nato lahko izda račun ali pregleda seznam plačil za izdane račune za določen dan,

– prijava v blagajno vključuje izbiro poslovnega prostora in elektronske naprave,

– sistemski administrator lahko ureja nastavite modula, vpiše davčno številko uporabnikov, registrira poslovne prostore,

– prijava v blagajno je del jedra informacijskega sistema Dolibarr, – modul Davčna blagajna vključuje funkcije za izbiro poslovnega prostora in

elektronske naprave, pripravo XML podatkov o izdanem računu, upravljanje nastavitev modula, vpis davčnih številk uporabnikov in pripravo XML podatkov o poslovnem prostoru,

– modul Davčna blagajna prejema podatke o registraciji poslovnega prostora in izdanem računu od informacijskega sistema FURS.

http://www.datoteke.fu.gov.si/dpr/index.html



Slika 8: UML diagram primerov uporabe modula Davčna blagajna

Modul je bil razvit za informacijski sistem Dolibarr različica 6.0.4., ki je bila najnovejša različica v času razvoja. Izdana je bila dne 5. 12. 2017. Izvorne datoteke so dosegljive na spletnih straneh sourceforge.net, na naslovu https://sourceforge.net/projects/informacijski sistem Dolibarr . Kot je zapisano v dokumentaciji, moramo za razvoj modula v informacijski sistem Dolibarr na lokacijo, kjer so shranjeni moduli, najprej namestiti predlogo, ki vključuje drevesno strukturo map in datoteke, potrebne za pravilno delovanje modula. Organiziranost map in njihove vloge (dolibarr.org, 2018c):

– davcnablagajna/build – vsebuje datoteke za gradnjo paketa, – davcnablagajna/core/modules – vsebuje deskriptor modula, datoteko

modDavcnablagajna.class – davcnablagajna/core/triggers – vsebuje sprožilce modula, – davcnablagajna/admin –vsebuje strani za upravljanje modula, – davcnablagajna/class – vsebuje razrede modula, – davcnablagajna/css – vsebuje datoteke CSS modula, – davcnablagajna/docs – vsebuje dokumente modula, – davcnablagajna/img – vsebuje slike, ki jih uporablja modul, – davcnablagajna/langs/xx_XX – vsebuje jezikovne pakete, – davcnablagajna/lib – vsebuje knjižnice, ki jih uporablja modul, – davcnablagajna/scripts – vsebuje orodja za ukazno vrstico in skripte,

https://sourceforge.net/projects/dolibarr



– davcnablagajna/sql – vsebuje skripte SQL, ki jih modul uporablja za dodajanje tabel ali indeksov,

– davcnablagajna/themes/mytheme – za upravljanje teme modula, – davcnablagajna – vsebuje PHP strani modula.

V naslednjem koraku je potrebno pripraviti deskriptor (to je datoteka) za modul Davčna blagajna. To storimo tako, da spremenimo ime datoteke modMyModule.class.php, ki je deskriptor modula. Ime datoteke mora vsebovati ime modula. Ta se mora začeti s pripono "mod" in končati s končnico .class.php. Deskriptor datoteko smo tako poimenovali modDavcnaBlagajna.class.php. Nato moramo urediti zapise v datoteki po naslednjih korakih (dolibarr.org, 2018c):

– zamenjamo vse zapise »modMyModule« z vrednostjo, ki ustreza imenu našega modula. Za modul Davčna blagajna smo te vrednosti zamenjali z »modDavcnaBlagajna«;

– spremenimo vrednost konstante $this-> numero = 100000 v številko, ki označuje ID našega modula. Da se izognemo konfliktom zaradi podvojevanja številke z drugimi moduli, lahko na strani s seznamom že rezerviranih ID številk preverimo, katere so že v uporabi. Določili smo vrednost 500000;

– spremenimo vse druge spremenljivke, določene v konstruktorju. Ko smo opravili vse te korake, je deskriptor za naš modul pripravljen. Nastavitve modula so urejene do te stopnje, da lahko modul aktiviramo na straneh za upravljanje modulov. Slika 9 prikazuje zaslon za upravljanje modulov in nameščene module, vključno z modulom Davčna blagajna, ki ga lahko aktiviramo.

Slika 9: Aktivacija modula Davčna blagajna



5.1. PRIPRAVA RAZVOJNEGA OKOLJA Informacijski sistem Dolibarr, različico 6.0.4., smo namestili na lokalni strežnik WAMP, ki vključuje spletni strežnik Apache, bazo podatkov MySQL in strežnik PHP. Za pripravo tabel baze podatkov smo uporabili orodje MySQL Workbench. Kot glavno orodje za pripravo programske kode pa smo uporabljali PHP Storm IDE. Različice uporabljenih strežnikov v razvojnem okolju: WAMP: 3.0.6 Apache spletni strežnik: 2.4.23 PHP strežnik: 7.0.10 MySQL strežnik: 5.7.14 Slika 10 prikazuje podatke iz strežnika WAMP.

Slika 10: Nastavitve strežnika WAMP



5.2. PRIDOBITEV NAMENSKEGA DIGITALNEGA POTRDILA Namensko digitalno potrdilo je posebna vrsta digitalnega potrdila, ki ga zavezanec lahko uporablja le za izmenjavo podatkov o računih in o poslovnih prostorih s FURS-om. Zavezanec ga pridobi tako, da odda vlogo z oznako DPR-PridobitevDP prek portala eDavki, potrdilo pa nato prevzame prek portala za prevzem namenskih digitalnih potrdil. Potrdilo je za zavezance brezplačno in velja 5 let. Druga digitalna potrdila se za potrjevanje računov ne uporabljajo. Digitalno potrdilo ima naziv DavPotRac, na njem pa so podatki o davčni številki in imenu zavezanca, namen uporabe in zaporedna številka potrdila. Digitalno potrdilo služi za identifikacijo uporabnika v elektronskem poslovanju. Za elektronsko poslovanje s Finančno upravo Republike Slovenije je nujna uporaba digitalnega potrdila in zasebnega ključa, ki v elektronskem poslovanju nadomeščata osebno legitimacijo in omogočata varno komunikacijsko povezavo prek spleta. Za potrebe davčne blagajne mora zavezanec pridobiti vsaj eno namensko digitalno potrdilo – testno ali produkcijsko, glede na okolje, na katero se ima namen povezati (edavki.durs.si, 2017). FURS za razvijalce izda namensko digitalno potrdilo za testno okolje, ki ga je moč uporabljati le za razvojne namene v testnem okolju, v produkcijskem okolju pa takšno digitalno potrdilo ne deluje. Podatki o lastniku testnega potrdila so fiktivni. FURS smo zaprosili za izdajo testnega digitalnega potrdila, ki smo ga po nekaj dneh prejeli po e-pošti v formatu P12, skupaj s pripadajočim geslom.

5.3. PRILAGODITEV STRUKTURE PODATKOVNE BAZE Za potrebe modula Davčna blagajna smo pripravili tabele, v katerih se shranjujejo podatki o poslovnih prostorih, elektronskih napravah in izdanih računih. Za ta namen smo ustvarili tri table, in sicer:

– llx_davcnablagajna_businesspremise – vsebuje podatke o poslovnih prostorih,

– llx_davcnablagajna_electronicdevice – vsebuje podatke o elektronskih napravah,

– llx_davcnablagajna_invoicerequestdata – vsebuje podatke o izdanih računih.

Pripravili smo ukazno skripto SQL in jo shranili v datoteko llx_davcnablagajna.sql za kreiranje tabel v bazi podatkov informacijskega sistema Dolibarr Skript, ki se izvede ob aktivaciji modula Davčna blagajna. Slika 11 prikazuje tabele modula Davčna blagajna in pripadajoče lastnosti.



Slika 11: Tabele modula Davčna blagajna

Glede na to, da moramo ob izdaji davčno potrjenega računa na FURS poslati tudi podatke o operaterju, je potrebno v bazo podatkov zapisati tudi podatke o operaterju oziroma blagajniku. Zakon o davčnem potrjevanju računov zahteva, da se vpiše davčna številka fizične osebe (operaterja), ki izda račun z uporabo elektronske naprave za izdajanje računov. Pri dodajanju operaterjev je potrebno vnesti oznako operaterja, ime in priimek ter davčno številko, če ima ta oseba slovensko davčno številko. Informacijski sistem Dolibarr že vsebuje tabelo llx_user, ki je namenjena shranjevanju podatkov o uporabnikih. V tabelo se zapisujejo podatki, kot je ime in priimek uporabnika, za potrebe davčne blagajne pa je potrebno zapisati še podatek o davčni številki uporabnika. Zato smo v obstoječo tabelo llx_user dodali polje TaxNumber. SQL ukaz za dodajanje polja »TaxNumber« ob aktivaciji modula Davčna blagajna je naslednji: ALTER TABLE `llx_user` ADD `TaxNumber` INT(8) NOT NULL AFTER `model_pdf`;

Ukaz smo dodali v datoteko llx_davcnablagajna.sql, ta pa se nahaja v mapi davcnablagajna/sql, kjer je shranjena celotna SQL sintaksa za kreiranje tabel modula Davčna blagajna. Po dodanem polju tabela llx_user izgleda, kot prikazuje tabela 2.

IME VRSTA NULL PRIVZETO

rowid int(11) Ne Brez

datec datetime Da NULL

tms timestamp Ne CURRENT_TIMESTAMP

fk_user_creat int(11) Da NULL



fk_user_modif int(11) Da NULL

login varchar(50) Ne Brez

entity int(11) Ne 1

ref_ext varchar(50) Da NULL

ref_int varchar(50) Da NULL

employee smallint(6) Da 1

fk_establishment int(11) Da 0

pass varchar(128) Da NULL

pass_crypted varchar(128) Da NULL

pass_temp varchar(128) Da NULL

api_key varchar(128) Da NULL

civility varchar(6) Da NULL

lastname varchar(50) Da NULL

firstname varchar(50) Da NULL

job varchar(128) Da NULL

skype varchar(255) Da NULL

office_phone varchar(20) Da NULL

office_fax varchar(20) Da NULL

user_mobile varchar(20) Da NULL

email varchar(255) Da NULL

signature text Da NULL

admin smallint(6) Da 0

webcal_login varchar(25) Da NULL

module_comm smallint(6) Da 1

module_compta smallint(6) Da 1

fk_soc int(11) Da NULL

fk_socpeople int(11) Da NULL

fk_member int(11) Da NULL

note text Da NULL

datelastlogin datetime Da NULL

datepreviouslogin datetime Da NULL

egroupware_id int(11) Da NULL

ldap_sid varchar(255) Da NULL

openid varchar(255) Da NULL

statut tinyint(4) Da 1

photo varchar(255) Da NULL

lang varchar(6) Da NULL

fk_user int(11) Da NULL

thm double(24,8) Da NULL

address varchar(255) Da NULL

zip varchar(25) Da NULL



town varchar(50) Da NULL

fk_state int(11) Da 0

fk_country int(11) Da 0

color varchar(6) Da NULL

accountancy_code varchar(32) Da NULL

barcode varchar(255) Da NULL

fk_barcode_type int(11) Da 0

nb_holiday int(11) Da 0

salary double(24,8) Da NULL

tjm double(24,8) Da NULL

salaryextra double(24,8) Da NULL

weeklyhours double(16,8) Da NULL

gender varchar(10) Da NULL

note_public text Da NULL

dateemployment datetime Da NULL

import_key varchar(14) Da NULL

model_pdf varchar(255) Da NULL

TaxNumber int(8) Da NULL

Tabela 2: Lastnosti tabele llx_user

5.4. RAZVOJ VMESNIKA ZA UPRAVLJANJE DAVČNE BLAGAJNE Za upravljanje modula Davčna blagajna smo razvili vmesnik za upravljanje nastavitev. Ta vsebuje splošne informacije o modulu, pregled nastavitev in obrazce za vnos podatkov o davčni blagajni, kot so podatki o poslovnem prostoru, elektronski napravi in davčni številki operaterjev. Pripravili pa smo tudi funkcijo za prenos namenskega digitalnega potrdila na strežnik. Vmesnik za upravljanje nastavitev modula Davčna blagajna vsebuje zavihke:

– nastavitve – globalne nastavitve modula in opis komponent, vključno s funkcijo za prenos namenskega digitalnega potrdila na strežnik in pregledom nastavitev modula Davčna blagajna;

– o programu – splošen opis modula in njegove funkcije; – poslovni prostor – obrazec za vnos in urejanje poslovnih prostorov; – elektronska naprava – obrazec za vnos in urejanje elektronskih naprav; – blagajnik – obrazec za vnos in urejanje davčnih številk blagajnikov.

V tej fazi lahko v sistem vnesemo testne podatke o poslovnem prostoru in elektronski napravi ter namestimo namensko digitalno potrdilo na strežnik. Slika 12 prikazuje zaslon vmesnika za upravljanje nastavitev modula Davčna blagajna s podatki o nameščenem digitalnem potrdilu.



Slika 12: Vmesnik za upravljanje nastavitev modula Davčna blagajna Slika 13 prikazuje obrazec za vnos podatkov o elektronski napravi.



Slika 13: Obrazec za vnos podatkov o elektronski napravi Obrazec na sliki 14 omogoča vnos podatkov o poslovnem prostoru.

Slika 14: Obrazec za vnos podatkov o poslovnem prostoru Za vnos davčnih številk blagajnikov smo pripravili obrazec Blagajniki. Ta prebere podatke o uporabniških računih iz informacijskega sistema Dolibarr, ki se nahajajo v tabeli llx_user. S pomočjo obrazca lahko vpišemo oziroma posodobimo davčne številke blagajnikov. Privzeta vrednost za davčno številko blagajnikov, ki še



nimajo vnesene davčne številke je 0. V primeru, da uporabnik nima vnesene davčne številke, mu sistem prepreči prijavo v modul Davčna blagajna, saj je po Zakonu o davčnem potrjevanju računov davčna številka blagajnika obvezen podatek za izdajo računa. Obrazec za vnos davčne številke blagajnika prikazuje slika 15.

Slika 15: Obrazec za vnos davčnih številk blagajnikov

5.5. POVEZOVANJE NA INFORMACIJSKI SISTEM FINANČNE UPRAVE Za vzpostavitev varne seje z informacijskim sistemom Finančne uprave se uporablja dvosmerni protokol TLS. Za avtentifikacijo in vzpostavitev TLS seje pa odjemalec uporabi namensko digitalno potrdilo. Omogočena je uporaba TLS protokola verzij 1.0, 1.1 in 1.2. Verziji TLS 1.0 in 1.1 bosta omogočeni do 30. 6. 2018, saj zaradi varnosti FURS priporoča uporabo TLS protokola verzije 1.2 oziroma čimprejšnji prehod na to verzijo. Informacijski sistem Finančne uprave ima za razvijalce pripravljeno testno okolje, ki je bilo uporabljeno tudi v tej raziskavi. Naslovi za povezovanje na informacijski sistem Finančne uprave:

– naslov za pošiljanje podatkov o računih v XML obliki: https://blagajne-test.fu.gov.si:9002/v1/cash_registers,

– naslov za pošiljanje podatkov o poslovnih prostorih v XML obliki: https://blagajne-test.fu.gov.si:9002/v1/cash_registers.

https://blagajne-test.fu.gov.si:9002/v1/cash_registers

https://blagajne-test.fu.gov.si:9002/v1/cash_registers



5.6. ELEKTRONSKO PODPISOVANJE DOKUMENTOV XML Pred pošiljanjem sporočil XML na strežnike FURS je potrebno dokument XML digitalno podpisati s pripadajočim digitalnim potrdilom, da zagotovimo nespremenjenost vsebine. Za podpis XML se uporablja način podpisovanja »XML enveloped signature«, podpis pa se nahaja znotraj podpisanega elementa. Podpis je definiran s shemo http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd, vsebina sheme pa je prikazana na sliki 22 (FURS, 2016).

Slika 16: XSD shema za digitalno podpisovanje XML sporočil (FURS, 2016) Za namen digitalnega podpisovanja sporočil smo uporabili knjižnico PHP xmlseclibs in pripravili metodo signDocument() za podpisovanje poslanih sporočil tipa račun in poslovni prostor. Omenjeno funkcijo opisuje spodnja programska koda: public function signDocument() { if(strlen($this->contentToSignIdentifier) == 0) return;

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd



// pridobi vsebino xml sporočila $doc = new DOMDocument('1.0', 'UTF-8'); $doc->loadXML($this->xmlMessage); $xpath = new DOMXPath($doc); $nodeset = $xpath->query("//$this->contentToSignIdentifier")->item(0); // Podpiši XML dokument $objXMLSecDSig = new XMLSecurityDSig(''); $objXMLSecDSig->setCanonicalMethod(XMLSecurityDSig::C14N); $objXMLSecDSig->addReference($nodeset, XMLSecurityDSig::SHA256, array('http://www.w3.org/2000/09/xmldsig#enveloped-signature'), array('id_name' => 'Id', 'uri' => $this->msgIdentifier, 'overwrite' => false) ); openssl_pkcs12_read(file_get_contents($this->myCertificatePathP12), $raw, $this->CertPasswordP12); $objKey = new XMLSecurityKey(XMLSecurityKey::RSA_SHA256, array('type' => 'private')); $objKey->loadKey($raw['pkey']); $objXMLSecDSig->sign($objKey, $nodeset); $objXMLSecDSig->add509Cert($raw['cert'], true, false, array('issuerSerial' => true, 'subjectName' => true, 'issuerCertificate' => false) ); $this->xmlMessage = $doc->saveXML(); }

Primer podpisanega XML sporočila:

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:fu="http://www.fu.gov.si/" xmlns:xd="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <fu:InvoiceRequest Id="pfxd56416b5-2852-bc94-c103-d8a74d7d1707"> <fu:Header> <fu:MessageID>04915051-bb3b-4737-a34b-7c2224d505cf</fu:MessageID> <fu:DateTime>2018-01-31T20:05:35</fu:DateTime> </fu:Header> <fu:Invoice> <fu:TaxNumber>10374540</fu:TaxNumber> <fu:IssueDateTime>2018-01-31T20:05:35</fu:IssueDateTime> <fu:NumberingStructure>C</fu:NumberingStructure> <fu:InvoiceIdentifier> <fu:BusinessPremiseID>TRGLJ36</fu:BusinessPremiseID> <fu:ElectronicDeviceID>BLAG14</fu:ElectronicDeviceID> <fu:InvoiceNumber>18258</fu:InvoiceNumber> </fu:InvoiceIdentifier> <fu:InvoiceAmount>32.79</fu:InvoiceAmount> <fu:PaymentAmount>32.79</fu:PaymentAmount> <fu:TaxesPerSeller> <fu:VAT> <fu:TaxRate>22</fu:TaxRate> <fu:TaxableAmount>26.88</fu:TaxableAmount> <fu:TaxAmount>5.91</fu:TaxAmount>



</fu:VAT> </fu:TaxesPerSeller> <fu:OperatorTaxNumber>31362346</fu:OperatorTaxNumber> <fu:ProtectedID>15ebf5b7b4acc81af861e4984ab8b04a</fu:ProtectedID> </fu:Invoice> <xd:Signature> <xd:SignedInfo><xd:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <xd:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <xd:Reference URI="#pfxd56416b5-2852-bc94-c103-d8a74d7d1707"><xd:Transforms><xd:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></xd:Transforms><xd:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><xd:DigestValue>Mw8d5eXfXMjdmW/EqPvZ9/iTQzTSuddxMDlqAVUITqw=</xd:DigestValue></xd:Reference></xd:SignedInfo><xd:SignatureValue>doTmMmaR2bnKsKcDMNAZEWMtdc10cdlkwAl2AtkALkNF8dsqFlzhy8WXbuaP5Kd48vlPOK112z+QZXDonxhwcQovPxEeEwrXF2xND6m1Qx62F81HEMsEDi2BGCB95GIPPxCLSeTtr0SEUdSiPGUbpGd7ajG0rIBIgDnQE9liET+hiMWH1IYAg/Ab8wS1XR97FOC6RSsI8HSv6Z8CAZWFWwt17fO4RBiVrQxnUDFz8F2SNruLf5wPSi/f4aS4JWKbUwpgjGZ59QM03slC6x6D0LW9U20hU2LGK9OIHZmukLPr/B2IIRJHQEvsiTM0hXDj7QJo25NoXgmPK5cyXDL9DA==</xd:SignatureValue> <xd:KeyInfo><xd:X509Data><xd:X509SubjectName>CN=TESTNO PODJETJE 1202,serialNumber=1,OU=10374540,OU=DavPotRacTEST,O=state-institutions,C=SI</xd:X509SubjectName><xd:X509IssuerSerial><xd:X509IssuerName>CN=Tax CA Test,O=state-institutions,C=SI</xd:X509IssuerName><xd:X509SerialNumber>5576990314605509902</xd:X509SerialNumber></xd:X509IssuerSerial></xd:X509Data></xd:KeyInfo></xd:Signature></fu:InvoiceRequest> </soapenv:Body> </soapenv:Envelope>

5.7. IZMENJAVA PODATKOV Z DAVČNIM ORGANOM Za izmenjavo podatkov z informacijskim sistemom Finančne uprave se uporablja SOAP protokol. Davčni zavezanci so na davčni organ Finančne uprave dolžni poslati dva tipa sporočil: podatke o izdanem računu in podatke o poslovnem prostoru. Pred pošiljanjem podatkov je potrebno XML dokument s podatki še digitalno podpisati. Za komunikacijo smo uporabili funkcijo CURL. PHP koda za izmenjavo podatkov z informacijskim sistemom Finančne uprave pa je naslednja: $conn = curl_init(); $settings = array( CURLOPT_URL => $this->fursServerUrl, CURLOPT_FRESH_CONNECT => true, CURLOPT_CONNECTTIMEOUT_MS => 3000, CURLOPT_TIMEOUT_MS => 3000, CURLOPT_RETURNTRANSFER => true, CURLOPT_POST => 1, CURLOPT_HTTPHEADER => $this->urlPostHeader, CURLOPT_POSTFIELDS => $this->xmlMessage, CURLOPT_SSL_VERIFYHOST => 2, CURLOPT_SSL_VERIFYPEER => true,



CURLOPT_SSLCERT => $this->myCertificatePathPem, CURLOPT_SSLCERTPASSWD => $this->CertPassword, CURLOPT_CAINFO => $this->fursCertificatePath ); curl_setopt_array($conn, $settings); curl_close($conn);

5.7.1. PODATKI O POSLOVNEM PROSTORU

Pred začetkom izdajanja računov z davčno blagajno mora zavezanec FURS-u posredovati podatke o vseh poslovnih prostorih, v katerih bo izdajal gotovinske račune. Kot poslovni prostor zavezanca se šteje vsak nepremičen ali premičen prostor, v katerem se izdajajo računi. Premičen prostor je vsak premičen objekt ali elektronska naprava za izdajo računov. Za dejavnosti, ki se opravljajo na terenu, zavezanec za izvajanje postopka potrjevanja računov samostojno določi potrebo po ločenem vodenju premičnega poslovnega prostora. Oznaka poslovnega prostora je lahko sestavljena iz črk ali številk, vendar je na ravni zavezanca enkratna. Poleg tega mora vsak zavezanec, ki je dolžan potrjevati gotovinske račune, pred izdajo prvega računa FURS-u sporočiti naslednje podatke o vsakem posameznem poslovnem prostoru, v katerem bo izdajal račune (FURS, 2016):

– davčno številko, – oznako poslovnega prostora, – identifikacijsko oznako stavbe ali dela stavbe, kjer je poslovni prostor,

kakor je določeno v registru nepremičnin (številka katastrske občine, številka stavbe in številka dela stavbe), kadar se izdajajo računi v nepremičnem poslovnem prostoru,

– naslov poslovnega prostora, če se izdaja račune v nepremičnem poslovnem prostoru,

– vrsto poslovnega prostora, če se izdaja račune v premičnem poslovnem prostoru,

– podatke o proizvajalcu ali vzdrževalcu programske opreme za izdajanje računov,

– datum začetka veljavnosti sporočenih podatkov. Podatke je potrebno poslati preko vzpostavljene elektronske povezave, podpisane z namenskim digitalnim potrdilom, in to pred prvim pošiljanjem podatkov o računu za namene potrditve računa. Podatke, podpisane z namenskim digitalnim potrdilom in poslane preko elektronske povezave, FURS preveri in zavezancu nemudoma pošlje potrdilo o prejemu. Če podatki niso ustrezni, je potrebno napake odpraviti in podatke ponovno poslati v potrditev. Diagram na sliki 17 opisuje proces izdaje sporočila s podatki o poslovnem prostoru.



Slika 17: Proces izdaje sporočila s podatki o poslovnem prostoru (FURS, 2016) V tabeli 3 so zapisani vsi elementi XML in njihove lastnosti, ki so po večini obvezne sestavine podatkov o poslovnem prostoru.

Ime elementa

Uporaba/opis elementa

Obvezen podatek

Tip podatka

Zaloga vrednosti

XML element

+ Identifikator sporočila

Enkratni identifikator sporočila. Vsako sporočilo mora imeti enkratno identifikacijsko oznako. Enako velja tudi pri

Da/Yes Text Min36, Max36

BusinessPremiseRequest/Header/MessageID



pošiljanju sporočila, ki se zaradi napake pošilja ponovno.

+ Datum in čas pošiljanja

Datum in čas pošiljanja sporočila.LLLL-MM-DDTUU:MM:SS / YYYY-MM-DDTHH:MM:SS

Da/Yes Date Time

LLLL-MM-DDTUU:MM:SS

BusinessPremiseRequest/Header/DateTime

+ Davčna številka

Davčna številka zavezanca, ki izdaja račune

DA/Yes Text Min8, Max8

BusinessPremiseRequest/BusinessPremise/TaxNumber

+ Oznaka poslovnega prostora

Vpiše se oznaka poslovnega prostora v katerem zavezanec izdaja račune pri gotovinskem poslovanju. Oznaka je lahko sestavljena iz številk in črk. Oznaka mora biti enaka kot tista, ki je navedena na računih.Oznaka je enkratna na nivoju zavezanca.

DA/Yes Text Min1, Max20

BusinessPremiseRequest/BusinessPremise/BusinessPremiseID

+ Identifikacijski podatki o poslovnem prostoru

Vpišejo se podatki o nepremičnem ali premičnem poslovnem prostoru.

DA/Yes

BusinessPremiseRequest/BusinessPremise/BPIdentifier

++ Nepremični poslovni prostor

Vpišejo se podatki o nepremičnem poslovnem prostoru, če zavezanec izdaja račune v nepremičnem poslovnem prostoru.

DA, če zavezanec izdaja račune v nepremičnem poslovnem prostoru

BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP

+++ Identifikacijska oznaka nepremičnine

Vpiše se identifikacijska oznaka stavbe oziroma dela stavbe, kjer se nahaja poslovni prostor, kot je določena v registru nepremičnin. Oznaka se vpiše, če zavezanec izdaja račune v

DA/YES

BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/PropertyID



nepremičnem poslovnem prostoru. - Številka katastrske občine - Številka stavbe, Številka dela stavbe. Podatki se vpisujejo ločeno.

++++ Številka katastrske občine

DA/YES Number

Številk/Numbers: max 4

BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/PropertyID/CadastralNumber

++++ Številka stavbe

DA/YES Number


BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/PropertyID/BuildingNumber

++++ Številka dela stavbe

DA/YES Number


BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/PropertyID/BuildingSectionNumber

+++ Naslov poslovnega prostora

Vpiše se naslov poslovnega prostora, če zavezanec izdaja račune v nepremičnem poslovnem prostoru. Naslov sestavljajo ulica in hišna številka, dodatek k hišni številki, naselje, pošta in poštna številka.

DA/YES

BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/Address

++++ Ulica

DA/YES Text Min1, Max100

BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/Address/Street

++++ Hišna številka


BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/Addres



s/HouseNumber

++++ Dodatek k hišni številki

DA, če obstaja / YES if it exists

Text Min1, Max10

BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/Address/HouseNumberAdditional

++++ Naselje


BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/Address/Community

++++ Pošta


BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/Address/BusinessPremise/City

++++ Poštna številka


BusinessPremiseRequest/BusinessPremise/BPIdentifier/RealEstateBP/Address/BusinessPremise/PostalCode

+ Datum začetka veljavnosti podatkov

Datum začetka veljavnosti podatkov o poslovnem prostoru, ki se posredujejo. Podatek se vpiše v obliki: LLLL-MM-DD / YYYY-MM-DD

DA/YES Date

BusinessPremiseRequest/BusinessPremise/ValidityDate

+ Proizvajalec ali vzdrževalec programske opreme

Vpiše se podatek o proizvajalcu ali vzdrževalcu programske opreme za izdajanje računov. Vpiše se eden od podatkov - Davčna številka pravne ali fizične osebe - proizvajalca ali vzdrževalca programske opreme s

DA/YES

BusinessPremiseRequest/BusinessPremise/SoftwareSupplier/



sedežem v Sloveniji in - naziv in naslov proizvajalca ali vzdrževalca programske opreme, ki nima sedeža v Sloveniji

++ Davčna številka proizvajalca ali vzdrževalca programske opreme

Vpiše se davčna številka pravne ali fizične osebe – proizvajalca ali vzdrževalca programske opreme s sedežem v Sloveniji.

DA, če ima proizvajalec ali vzdrževalec sedež v Sloveniji

Text Min8, Max8

BusinessPremiseRequest/BusinessPremise/SoftwareSupplier/TaxNumber

Tabela 3: Elementi XML za podatke o poslovnem prostoru (FURS, 2016)

Podatke o poslovnem prostoru smo v podatkovno bazo že vnesli na straneh vmesnika za upravljanje Davčne blagajne. Obrazec vsebuje vnosna polja za vpis vseh podatkov, ki so zahtevani za registracijo poslovnega prostora. Podatke o poslovnem prostoru pošlje modul davčna blagajna takoj, ko so vneseni podatki o poslovnem prostoru. Na strežniku pa mora biti predhodno nameščeno tudi namensko digitalno potrdilo. Za izmenjavo podatkov o poslovnem prostoru se izvede naslednja koda: require_once '../Class/DavcnaBlagajna.class.php'; ini_set('display_errors', true); $BusinessID = $_POST['BusinessPremiseID']; print '<h4 style="color: limegreen">Poslovni prostor '.$BusinessID.' je bil uspešno registriran.</h4>'; print "</tr>"; print '</td>'; //Veljavnost $BusinessValidityDate = date("Y-m-d"); $config_business = array('businessID' => $BusinessID, 'businessValidityDate' => $BusinessValidityDate,); $davcnab = new DavcneBlagajne; $davcnab->__construct(); $davcnab->companyTaxNum = ltrim($conf->global->MAIN_INFO_TVAINTRA, 'SI'); $davcnab->CertPassword = file_get_contents('C:\wamp64\www\dolibarr\htdocs\custom\davcnablagajna\include\certpass.txt'); $davcnab->CertPasswordP12 = file_get_contents('C:\wamp64\www\dolibarr\htdocs\custom\davcnablagajna\include\certpass.txt'); $davcnab->data = $config_business; //ustvari sporočilo s podatki o poslovnem prosotru $davcnab->createBusinessMsg(); //pošlji podatke na FURS $davcnab->postXML2Furs();



var_dump($davcnab->getFURSResponse()); $simp = $davcnab->getFURSResponse(); $s = simplexml_load_string($simp); $s->saveXML('../include/fursXML/FursBusinessResponse.xml');

Informacijo o stanju registracije poslovnega prostora in izpolnjenih pogojih za izdajo računov pridobimo na straneh za upravljanje nastavitev modula Davčna blagajna, kjer je na voljo hitri pregled nastavitev. Izpišejo se tudi podatki o digitalnem potrdilu, kot je namen uporabe digitalnega potrdila, davčna številka lastnika, serijska številka in datum veljavnosti digitalnega potrdila. Tako se lahko izognemo poteku potrdila in še pravočasno pridobimo novo digitalno potrdilo. Slika 18 prikazuje hitri pregled nastavitev davčne blagajne, ko pogoji za izdajo računov in uporabo modula Davčna blagajna še niso izpolnjeni.



Slika 18: Hitri pregled nastavitev, ko pogoji za uporabo modula niso izpolnjeni



Slika 19 prikazuje hitri pregled nastavitev davčne blagajne, ko so izpolnjeni vsi pogoji za izdajo davčno potrjenih računov in uporabo modula Davčna blagajna. Takrat se pogoji obarvajo z zeleno barvo, na dnu strani pa se pojavi napis »Blagajna je pripravljena za uporabo«.

Slika 19: hitri pregled nastavitev, ko so vsi pogoji za uporabo modula izpolnjeni Koda, ki preveri izpolnjene pogoje za uporabo modula Davčna blagajna in izpiše stanje: print '<h2>Hitri pregled nastavitev davčne blagajne:</h2>'; $CertFileExist = file_exists('../include/certs/cert.p12'); if($CertFileExist){ print '<a style="color: limegreen">Digitalno potrdilo je nameščeno.</a><br>'; $cert_store = file_get_contents("../include/certs/cert.p12");



$f = file_get_contents("../include/certpass.txt"); $Certpass = $f; if (openssl_pkcs12_read($cert_store, $cert_info, $Certpass)) { // print_r($cert_info); $certdata= openssl_x509_parse($cert_info['cert']); print '<a style="color: blue">Podatki o nameščenem digitalnem potrdilu: </a>'; print_r($certdata['name']); print '<br>'; print '<a style="color: blue">Veljavnost do: </a>'; print date("d. m. Y", $certdata['validTo_time_t']); $CertTax = $certdata['name']; } else { print '<p style="color: red;">'.'Napaka v digitalnem potrdilu. Preverite ustreznost digitalnega potrdila in gesla.'.'</p>'; } } else{ print '<a style="color: red">Digitalno potrdilo še ni nameščeno.</a><br>'; } $stat1sql=$db->query("SELECT * FROM llx_davcnablagajna_businesspremise"); if ($stat1sql) { $num1 = $db->num_rows($resql); $i = 0; if ($num1 < 1){ print '<a style="color: red">Podatki o poslovnem prostoru še niso vnešeni.</a><br>' ;} if ($num1 > 0){ print '<br><br><a style="color: limegreen">Podatki o poslovnem prostoru so vnešeni.</a><br>' ;} } $stat2sql=$db->query("SELECT * FROM llx_davcnablagajna_electronicdevice"); if ($stat2sql) { $num2 = $db->num_rows($resql); if ($num2 < 1) { print '<a style="color: red"> Podatki o elektronski napravi še niso vnešeni.</a><br>' ;} if ($num2 > 0) { print '<a style="color: limegreen"> Podatki o elektronski napravi so vnešeni.</a><br>' ;} } if ($CertFileExist == true && $num1 > 0 && $num2 > 0) { print '<h3 style="color: limegreen"> Blagajna je pripravljena za uporabo.</h3><br>'; } else { print '<h3 style="color: red"> Davčna blagajna še ni pripravljena za uporabo.</h3><br>';}

5.7.2. PODATKI O IZDANEM RAČUNU

Poleg običajnih podatkov o izdanem računu, ki so določeni v 82. členu ZDDV, mora izdani račun zaradi davčnega potrjevanja vsebovati še (pisrs.si, 2018b):

– čas izdaje računa (uro in minute); – oznako fizične osebe, ki izda račun; – enkratno identifikacijsko oznako računa; – zaščitno oznako izdajatelja računa.



Na vsakem računu je obvezna številka računa, ki mora biti sestavljena iz treh delov:

– oznake poslovnega prostora, v katerem je izdan račun, – oznake blagajne, s katero je izdan račun, in – zaporedne številke računa.

Podatke o izdanem računu je potrebno poslati preko vzpostavljene elektronske povezave, podpisane z namenskim digitalnim potrdilom. Podatke, podpisane z namenskim digitalnim potrdilom in poslane prek elektronske povezave, FURS preveri in poslanim podatkom o posameznem računu dodeli EOR (to je oznaka, ki se programsko ustvarja v FURS-ovem informacijskem sistemu in je obvezni del računa, ki ga kupec prejme) in jo pošlje zavezancu kot potrdilo o prejemu poslanih podatkov o izdanem računu. Enkratna identifikacijska oznaka računa (EOR) se ustvarja v FURS-ovem informacijskem sistemu na podlagi določenega niza podatkov in je potrdilo, da je bil izdani račun prijavljen davčnemu organu. Če podatki niso ustrezni, pa v odgovor pošlje kodo napake. Diagram na sliki 20 opisuje proces izdaje računa.



Slika 20: Proces izdaje računa (FURS, 2016) V tabeli 4 so zapisani vsi elementi XML in njihove lastnosti, ki so po večini obvezni podatki ob pošiljanju podatkov o izdanem računu.



Ime elementa

Uporaba/opis elementa Obvezen podatek

Tip podatka

Zaloga vrednosti

XML element

+ Identifikator sporočila

Enkratni identifikator sporočila. Vsako sporočilo mora imeti enkratno identifikacijsko oznako. Enako velja tudi pri pošiljanju sporočila, ki se zaradi napake pošilja ponovno.

Da/Yes Text Min36, Max36

BusinessPremiseRequest/Header/MessageID

+ Datum in čas pošiljanja

Datum in čas pošiljanja sporočila. LLLL-MM-DDTUU:MM:SS / YYYY-MM-DDTHH:MM:SS

Da/Yes Date Time

LLLL-MM-DDTUU:MM:SS

BusinessPremiseRequest/Header/DateTime

+ Račun – elektronska naprava

Vpišejo se podatki o računu, ki je izdan z uporabo elektronske naprave.

DA, če je račun izdan preko elektronske naprave

InvoiceRequest /Invoice

++ Davčna številka

Vpiše se davčna številka zavezanca, ki je izdal račun.

DA Text Min8, Max8

InvoiceRequest /Invoice/TaxNu mber

++Datum in čas izdaje računa

Vpiše se datum in čas izdaje računa, ki je naveden na računu. Podatek se vpiše v formatu LLLL-MMDDTUU:MM:SS

DA Date Time

InvoiceRequest /Invoice/IssueD ateTime

++ Način dodelitve številke računa

Vpiše se oznaka načina dodeljevanja številk računom: C – centralno na nivoju poslovnega prostora B – po posamezni elektronski napravi (blagajna). Oznaka pojasnjuje, na kakšen način se računom dodeljujejo številke. Številke računov se lahko dodeljujejo centralno na nivoju poslovnega prostora ali posamično na elektronski napravi za izdajanje računov.

DA Text Min1, Max1

InvoiceRequest /Invoice/Numbe ringStructure

++ Številka računa

Vpiše se številka izdanega računa. Vpiše se tudi številka dokumenta, ki spreminja prvotni račun

DA

InvoiceRequest /Invoice/Invoice



(dobropis, storno …) v primeru izvajanja postopka potrjevanja naknadne spremembe podatkov na računu, ki spreminja prvoten račun in se nanj nedvoumno nanaša. Številka računa je sestavljena iz treh delov: – oznaka poslovnega prostora, – oznaka elektronske naprave za izdajanje računa, – zaporedna številka računa. Številka računa se na računu navede v naslednji obliki: oznaka poslovnega prostora-oznaka elektronske naprave-zaporedna številka računa Primer: TRGOVINA1BLAG2-1234 Podatki se vpisujejo ločeno.

Identifier

+++ Oznaka poslovnega prostora

Vsebuje lahko samo črke in številke 0-9, a-z, A-Z.

DA Text Min1, Max20

InvoiceRequest /Invoice/Invoice Identifier/Busin essPremiseID

+++ Oznaka elektronske naprave

Vsebuje lahko samo črke in številke

DA Text Min1, Max20

InvoiceRequest /Invoice/Invoice Identifier/Electr onicDeviceID

+++ Zaporedna številka računa

Vsebuje lahko samo številke 0-9. Niso dovoljene vodilne ničle.

DA Text Min1, Max20

InvoiceRequest /Invoice/Invoice Identifier/Invoic eNumber

++ Vrednost računa

Vpiše se znesek računa za plačilo. Decimalno ločilo je pika.

DA

Decimal number

Številk:14 Decimalk:2

InvoiceRequest/Invoice/InvoiceAmount



++ Vrednost za plačilo

Decimalno ločilo je pika. DA/YES

Decimal number

Številk:14 Decimalk:2

InvoiceRequest /Invoice/Payme ntAmount

++ Vrednost osnove po davkih in dajatvah, po davčnih zavezancih

Vpiše se vrednost osnov po vrsti davka ali dajatve, razdeljeno po davčnih stopnjah, in pripadajoči davek ali dajatev, vrednost dobav na podlagi posebnih ureditev, dobav, pri katerih je plačnik DDV kupec blaga ali naročnik storitve, oproščenih dobav in neobdavčljivih dobav, ločeno po davčnih številkah davčnih zavezancev. Vpišejo se podatki o DDV. Podatek se posreduje le, če račun vsebuje znesek obračunanega DDV. Podatek je sestavljen iz davčne stopnje, davčne osnove in zneska davka. Za davčne stopnje lahko obstaja seznam davčnih stopenj pri davčnemu organu.

DA Text

InvoiceRequest /Invoice/TaxesP erSeller

+++ DDV Davek na dodano vrednost. DA, če obstaja davek

Deci mal Num ber

Številk max 5 Decimalk max 2

InvoiceRequest /Invoice/TaxesP erSeller/VAT

++++ Davčna stopnja

Vrednost davčne stopnje. Decimalno ločilo je pika.

DA, če obstaja davek

Deci mal Num ber

Številk max 5 Decimalk max 2

InvoiceRequest /Invoice/TaxesP erSeller/VAT/Ta xRate

++++ Davčna osnova

Znesek davčne osnove (po zmanjšanju za popuste). Decimalno ločilo je pika.


Deci mal Num ber

Številkmax 5 Decimalk max 2

InvoiceRequest /Invoice/TaxesP erSeller/VAT/Ta xableAmount



++++ Davek

Znesek davka. Decimalno ločilo je pika.


Deci mal Num ber

Številkmax 5 Decimalk max 2

InvoiceRequest /Invoice/TaxesP erSeller/VAT/Ta xAmount

++ Davčna številka osebe (operaterja) na elektronski napravi

Vpiše še davčna številka fizične osebe (operaterja), ki izda račun z uporabo elektronske naprave za izdajanje računov. V primeru izdaje računa preko samopostrežnih elektronskih naprav oziroma ko se račun izda brez prisotnosti fizične osebe, se vpiše davčna številka zavezanca. Če oseba nima slovenske davčne številke, se podatek ne vpisuje.

DA, če ima oseba slovensko davčno številko

Text Min8, Max8

InvoiceRequest /Invoice/Operat orTaxNumber

++ Zaščitna oznaka izdajatelja računa

Vpiše se zaščitna oznaka izdajatelja računa. Zaščitna oznaka je sestavljena iz 32 znakov v heksadecimalnem formatu: 8202f0f963e37a2258b034cf8ae7bbc1

DA Text Min32, Max32

InvoiceRequest /Invoice/Protect edID

Tabela 4: Elementi XML za podatke o izdanem računu (FURS, 2016)

Eden izmed obveznih elementov, ki vsebuje podatke o izdanem računu, je tudi zaščitna oznaka izdajatelja računa (ZOI). ZOI je alfanumeričen zapis, ki ga mora izračunati izdajatelj računa. Prav tako ga mora izpisati na računu in sporočiti na Finančno upravo v sporočilu računa. Namen oznake je generiranje enolične oznake, ki jo lahko ponovno generira samo izdajatelj računa. Uporablja se tudi za preverjanje pristnosti računa preko spletnega servisa. V tem primeru se uporabi kombinacija ZOI in davčna številka izdajatelja računa (FURS, 2016). Da zagotovimo enoličnost ZOI kode, moramo izračunati alfanumerični zapis, ki ga sestavlja davčna številka, datum in čas izdaje računa, zaporedna številka računa, oznaka poslovnega prostora, oznaka elektronske naprave izdajatelja računa in znesek računa. Za zagotovitev pristnosti izdajatelja pa se uporablja elektronski podpis z namenskim digitalnim potrdilom, izdanem s strani MJU za namen davčnega potrjevanja računov.

Pri vnosu skupnega zneska se uporablja decimalna pika (321.45). Za elektronski podpis smo uporabili algoritem RSA-SHA256 za zgoščevanje. Algoritem MD5 hash pa vrne kot rezultat 32znakovni zapis v šestnajstiškem formatu.



Za izračun ZOI smo razredu DavcneBlagajne dodali metodo generateZOI(): public function generateZOI() { $businessID = $this->data['businessID']; $newIssueDateTime = date("d.m.Y H:i:s", strtotime($this->data['IssueDateTime'])); $signData = $this->companyTaxNum.$newIssueDateTime.$this->data['InvoiceNumber'].$businessID.$this->data['ElectronicDeviceID'].$this->data['InvoiceAmount']; $key = openssl_pkey_get_private('file://'.$this->myCertificatePathPem, $this->CertPassword); openssl_sign($signData, $signature, $key, OPENSSL_ALGO_SHA256); openssl_free_key($key); return md5($signature); }

Davčno potrjevanje računa se izvede ob pritisku na gumb Potrdi račun. Pri tem se izvede priprava XML dokumenta z vsemi pripadajočimi spremenljivkami, podatke sistem digitalno podpiše in pošlje na FURS-ove strežnike. V primeru, da v trenutku pošiljanja ni povezave s strežniki FURS-a in odgovora na naše sporočilo ni, sistem sporoči napako. V primeru uspešne potrditve računa pa se podatki o izdanem računu vpišejo v tabelo llx_davcnablagajna_invoicerequestdata. Programska koda za vse omenjene funkcije je naslednja: DOL_DOCUMENT_ROOT.'/custom/davcnablagajna/class/davcnablagajna.class.php'; ini_set('display_errors', true); //Ime elektronske naprave $BusinessID = $_SESSION['BusinessPremise']; $ElectronicDeviceID = $_SESSION['ElectronicDevice']; //Veljavnost $BusinessValidityDate = '2200-01-01'; $CurrentUser = $_SESSION['uname']; $resql=$db->query("SELECT * FROM llx_user WHERE login = '$CurrentUser'"); $obj = $db->fetch_object($resql); $TaxNumber = $obj->TaxNumber; $invoice->date = str_replace(' ', 'T', date('Y-m-d H:i:s')); $db->begin(); $resql=$db->query("select * from llx_davcnablagajna_invoicerequestdata where BusinessPremiseID = '$BusinessID' and ElectronicDeviceID = '$ElectronicDeviceID'"); $db->commit(); $obj = $db->num_rows($resql); if ($obj == null) { $InvoiceNum = '1'; } else{ $InvoiceNum = ++$obj; } $config_invoice = array( 'BusinessPremiseID' => $BusinessID, 'businessValidityDate' => $BusinessValidityDate, 'InvoiceNumber' => $InvoiceNum, 'ElectronicDeviceID' => $ElectronicDeviceID, 'InvoiceAmount' => $invoice->total_ttc, 'OperatorTaxNumber' => $TaxNumber, 'IssueDateTime' => $invoice->date, 'vat_amount' => $invoice->total_tva, 'InvoiceNetAmount' => $invoice->total_ht, 'TaxRate' => $vat_rate ); $davcnab = new DavcneBlagajne;



$davcnab->__construct(); $davcnab->companyTaxNum = ltrim($conf->global->MAIN_INFO_TVAINTRA, 'SI'); $davcnab->CertPassword = file_get_contents(DOL_DOCUMENT_ROOT.'/custom/davcnablagajna/include/certpass.txt'); $davcnab->CertPasswordP12 = file_get_contents(DOL_DOCUMENT_ROOT.'/custom/davcnablagajna/include/certpass.txt'); $davcnab->data = $config_invoice; $davcnab->createInvoiceMsg(); //post xml message to furs $davcnab->postXML2Furs(); $db->begin(); // Start transaction $InvNo = $davcnab->data['BusinessPremiseID'].'-'.$davcnab->data['ElectronicDeviceID'].'-'.$davcnab->data['InvoiceNumber']; $Pno = $davcnab->zoi; $MsgId = $davcnab->messageID; $EOR = $davcnab->eor; $davcnab->generateQR(); $db->query("INSERT INTO llx_davcnablagajna_invoicerequestdata (InvoiceNumber, ProtectedID, OperatorTaxNumber, BusinessPremiseID, ElectronicDeviceID, MessageID, UniqueInvoiceID) VALUES ('$InvNo', '$Pno', '$TaxNumber', '$BusinessID', '$ElectronicDeviceID', '$MsgId', '$EOR')"); $db->commit(); $FursResponse = $davcnab->getFURSResponse(); $FursResponseExists = simplexml_load_string($FursResponse); if ($FursResponseExists == null) { exit('NAPAKA! Trenutno izdaja gotovinskih računov ni možna. Poskusite ponovno kasneje. Očitno je težava s povezavo do FURS strežnikov. Preverite internetno povezavo.'); } $FursResponseExists->saveXML(DOL_DOCUMENT_ROOT.'/custom/davcnablagajna/include/fursXML/FursInvoiceResponse.xml'); $davcnab->echoXML(); if($davcnab->returnUUID() == null) { exit('NAPAKA!'); }

Pri tem se generirajo podatki XML, ki jih modul pošlje informacijskemu sistemu Finančne uprave. Primer XML s podatki o izdanem računu: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:fu="http://www.fu.gov.si/" xmlns:xd="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <fu:InvoiceRequest Id="pfxd56416b5-2852-bc94-c103-d8a74d7d1707"> <fu:Header> <fu:MessageID>04915051-bb3b-4737-a34b-7c2224d505cf</fu:MessageID> <fu:DateTime>2018-01-31T20:05:35</fu:DateTime> </fu:Header> <fu:Invoice> <fu:TaxNumber>10374540</fu:TaxNumber> <fu:IssueDateTime>2018-01-31T20:05:35</fu:IssueDateTime> <fu:NumberingStructure>C</fu:NumberingStructure> <fu:InvoiceIdentifier>



<fu:BusinessPremiseID>TRGLJ36</fu:BusinessPremiseID> <fu:ElectronicDeviceID>BLAG14</fu:ElectronicDeviceID> <fu:InvoiceNumber>18258</fu:InvoiceNumber> </fu:InvoiceIdentifier> <fu:InvoiceAmount>32.79</fu:InvoiceAmount> <fu:PaymentAmount>32.79</fu:PaymentAmount> <fu:TaxesPerSeller> <fu:VAT> <fu:TaxRate>22</fu:TaxRate> <fu:TaxableAmount>26.88</fu:TaxableAmount> <fu:TaxAmount>5.91</fu:TaxAmount> </fu:VAT> </fu:TaxesPerSeller> <fu:OperatorTaxNumber>31362346</fu:OperatorTaxNumber> <fu:ProtectedID>15ebf5b7b4acc81af861e4984ab8b04a</fu:ProtectedID> </fu:Invoice> <xd:Signature> <xd:SignedInfo><xd:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <xd:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <xd:Reference URI="#pfxd56416b5-2852-bc94-c103-d8a74d7d1707"><xd:Transforms><xd:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></xd:Transforms><xd:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><xd:DigestValue>Mw8d5eXfXMjdmW/EqPvZ9/iTQzTSuddxMDlqAVUITqw=</xd:DigestValue></xd:Reference></xd:SignedInfo><xd:SignatureValue>doTmMmaR2bnKsKcDMNAZEWMtdc10cdlkwAl2AtkALkNF8dsqFlzhy8WXbuaP5Kd48vlPOK112z+QZXDonxhwcQovPxEeEwrXF2xND6m1Qx62F81HEMsEDi2BGCB95GIPPxCLSeTtr0SEUdSiPGUbpGd7ajG0rIBIgDnQE9liET+hiMWH1IYAg/Ab8wS1XR97FOC6RSsI8HSv6Z8CAZWFWwt17fO4RBiVrQxnUDFz8F2SNruLf5wPSi/f4aS4JWKbUwpgjGZ59QM03slC6x6D0LW9U20hU2LGK9OIHZmukLPr/B2IIRJHQEvsiTM0hXDj7QJo25NoXgmPK5cyXDL9DA==</xd:SignatureValue> <xd:KeyInfo><xd:X509Data><xd:X509SubjectName>CN=TESTNO PODJETJE 1202,serialNumber=1,OU=10374540,OU=DavPotRacTEST,O=state-institutions,C=SI</xd:X509SubjectName><xd:X509IssuerSerial><xd:X509IssuerName>CN=Tax CA Test,O=state-institutions,C=SI</xd:X509IssuerName><xd:X509SerialNumber>5576990314605509902</xd:X509SerialNumber></xd:X509IssuerSerial></xd:X509Data></xd:KeyInfo></xd:Signature></fu:InvoiceRequest> </soapenv:Body> </soapenv:Envelope>

Spodnji zapis predstavlja odgovor informacijskega sistema Finančne uprave na naše poslane podatke o izdanem računu. Če je bilo pošiljanje podatkov o izdanem računu uspešno, nam FURS v XML zapisu posreduje podatke o enkratni oznaki računa (EOR). V nasprotnem primeru FURS izpiše številko napake, EOR kode pa ne posreduje. <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:fu="http://www.fu.gov.si/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><fu:InvoiceResponse



Id="data"><fu:Header><fu:MessageID>54370ed6-8a9b-4817-a61f-0f008a9e76db</fu:MessageID><fu:DateTime>2018-02-04T15:59:18</fu:DateTime> </fu:Header><fu:UniqueInvoiceID>6f586327-d0c5-4cc0-afae-a26b54a00f7a</fu:UniqueInvoiceID> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#data"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>AqT0aVRz/qQai/m43OAWOHIhvP6fDnE4xw6Kj8lYsZo=</DigestValue></Reference></SignedInfo><SignatureValue>YnBSScFSZA3cekBOcGcAQggYO1LC5VH0iLzNlsmxW8x63b9fJkXuajkzasMIua7xn5JY7hwIA2He8oC4VrhWbB1YNyWexEewaJRfe2cErlAoSqMWM279DoAPh9D83T30rg+K8vHOEMSS7CfEdj9E2It/quDmV2q69Q85z4XLS7eESY/65cGw9Q0UBNr32rMNb4iSH7rfKQVrzEu8gtTFSbShPLRkr8RZF28bOpyUJH1JfYQv2AON2U4QWcx97cvTYgPI780IdlJtYgVlme4Fn6NEDUMKU8B0M1//zVgpL5bdFwpiUoNgtZHvzOAMFm+Ddk/yEohO+34rMc+xjomGrg==</SignatureValue><KeyInfo><X509Data><X509SubjectName>CN=FURS, OID.2.5.4.5=1, OU=77695771, U=DavPotRacTEST, O=state-institutions, C=SI</X509SubjectName> <X509IssuerSerial><X509IssuerName>CN=Tax CA Test,O=state-institutions,C=SI</X509IssuerName><X509SerialNumber>4723074879886330622</X509SerialNumber></X509IssuerSerial><X509Certificate>MIIFXjCCA0agAwIBAgIIQYu7lE8yCv4wDQYJKoZIhvcNAQELBQAwQDELMAkGA1UEBhMCU0kxGzAZBgNVBAoMEnN0YXRlLWluc3RpdHV0aW9uczEUMBIGA1UEAwwLVGF4IENBIFRlc3QwHhcNMTUwODA0MTMxMjQ3WhcNMjAwODA0MTMxMjQ3WjBwMQswCQYDVQQGEwJTSTEbMBkGA1UECgwSc3RhdGUtaW5zdGl0dXRpb25zMRYwFAYDVQQLDA1EYXZQb3RSYWNURVNUMREwDwYDVQQLDAg3NzY5NTc3MTEKMAgGA1UEBRMBMTENMAsGA1UEAwwERlVSUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIf8jVOE1Je+Jqbs+I+LMK3/OUJ/Zj1GbAfdWst/grzKKEh93oeIACEvqrJuOZy0qb05NWJ0ra8J4a7DL4UM7Hzc9Os8TgkT5A7Dh85wlAXgOKk4GDi6lHliHmaHlaq0ymP2KAvTo3yenmWVcIniQYgbziDGXbHLtMfHphtqXDh38rFhFESE8m453mLtzNUOBD7JQbRZ2k5XcJtoFOXdwUIwif9KzRm/u7E3TqEVvuVQ7kucli5zHoDC6EiF6i/BqAUcNuNYmTBTFlxSZnUjOiWgij+DOvFHw36c /Hfgg==</X509Certificate></X509Data><KeyValue><RSAKeyValue><Modulus>h/yNU4TUl74mpuz4j4swrf85Qn9mPUZsB91ay3+CvMooSH3eh4gAIS+qsm45nLSpvTk1YnStrwnhrsOAvhQzsfNz06zxOCRPkDsOHznCUBeA4qTgYOLqUeWIeZoeVqrTKY/YoC9OjfJ6eZZVwieJBiBvOIMZdscu0x8emG2pcOHfysWEURITybjneYu3M1Q4EPslBtFnaTldwm2gU5d3BQjCJ/0rNGb+7sTdOoRW+5VDuS5yWLnMegMLoSIXqL8GoBRw241iZMFMWXFJmdSM6JaCKP4M68UfDfpy7gi2tZ5cvwkchnLyC/EY0w8kWTj8SLT04Z4yCUhTEW1W2IrAZQ==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue></KeyInfo></Signature></fu:InvoiceResponse> </soapenv:Body> </soapenv:Envelope>

5.8. GRAFIČNI VMESNIK MODULA DAVČNA BLAGAJNA Informacijski sistem Dolibarr že vključuje modul Prodajalne, ki vsebuje vse ključne sestavine blagajne. Zato teh funkcij ne bomo ponovno razvijali, ampak bomo za namen davčne blagajne uporabili že razvito programsko kodo in jo nadgradili s funkcijami davčne blagajne. Na prijavno stran modula smo vgradili polja za izbor poslovnega prostora in elektronske naprave. Vgrajena pa je tudi zaščita, ki uporabniku sporoči, da izdaja gotovinskih računov ni možna, saj poslovni prostor in elektronska naprava še nista registrirana. Omenjene funkcije izvede naslednja koda:



print "<tr>"; print '<td class="label1">Elektronska naprava</td>'; print '<td>'; $resql=$db->query("SELECT * FROM llx_davcnablagajna_electronicdevice"); if ($resql) { print '<select name="ElectronicDevice">'; $num = $db->num_rows($resql); $i = 0; if ($num) { while ($i < $num) { $obj = $db->fetch_object($resql); if ($obj) { print "<option value=".$obj->Name.">".$obj->Name."</option>"; } $i++; } } print ' <option name="Name"> </option> </select>'; if ($num < 1) { print '<a style="color: red"> Podatki o elektronski napravi še niso vnešeni.</a>' ;} } print "<tr>"; print '<td class="label1">Poslovni prostor</td>'; print '<td>'; $resql=$db->query("SELECT * FROM llx_davcnablagajna_businesspremise"); if ($resql) { print '<select name="BusinessPremise">'; $num = $db->num_rows($resql); $i = 0; if ($num) { while ($i < $num) { $obj = $db->fetch_object($resql); if ($obj) { // You can use here results print "<option value=".$obj->BusinessPremiseID.">".$obj->BusinessPremiseID."</option>"; } $i++; }} print ' <option name="Name"> </option> </select>'; if ($num < 1){ print '<a style="color: red">Podatki o poslovnem prostoru še niso vnešeni.</a>' ;}}

Slika 21 prikazuje prijavno okno v modul Davčna blagajna, kjer pred prijavo izberemo elektronsko napravo in poslovni prostor.



Slika 21: Prijavno okno za modul Davčna blagajna Pripravili smo tudi PHP kodo, ki prepreči prijavo v blagajno uporabniku, ki nima vpisane davčne številke v tabeli llx_user in tako ni določen za blagajnika. $CurrentUser = $_SESSION['uname']; print $CurrentUser; $resql=$db->query("SELECT * FROM llx_user WHERE login = '$CurrentUser'"); $obj = $db->fetch_object($resql); $TaxNumber = $obj->TaxNumber; // Če uporabnik nima vpisane davčne številke se pojavi sporočilo if (empty($TaxNumber)) { print '<p style="color: red" >Uporabnik '.$_SESSION['uname'].' nima vpisane davčne številke. Uporaba blagajne ni možna.</p>'; }

Ko se prijavimo, se v zgornjem desnem kotu pojavi podatek o poslovnem prostoru in elektronski napravi. Slika 22 prikazuje glavni zaslon modula Davčne blagajne.



Slika 22: Modul Davčna blagajna PHP koda, ki izpiše podatke o poslovnem prostoru in elektronski napravi: print '<a style="color: red"> Poslovni prostor:<a/>'; print $_SESSION['BusinessPremise'].'<br>';



print '<a style="color: red">Elektronska naprava:<a/>'; print $_SESSION['ElectronicDevice'];

Slika 23 prikazuje zaslon, kjer blagajnik potrdi račun.

Slika 23: Zaslon za potrditev računa Ob pritisku na gumb Potrdi račun se za namen davčnega potrjevanja računa aktivira naslednja PHP koda, ki kreira nov objekt razreda DavcneBlagajne in določi vednosti lastnostim tega razreda. require_once DOL_DOCUMENT_ROOT.'/custom/davcnablagajna/class/davcnablagajna.class.php'; ini_set('display_errors', true); //Izber ime elektronske naprave $resql=$db->query("SELECT * FROM llx_davcnablagajna_businesspremise"); $obj = $db->fetch_object($resql); $BusinessID = $obj->BusinessPremiseID;



$resql=$db->query("SELECT * FROM llx_davcnablagajna_electronicdevice"); $obj = $db->fetch_object($resql); $ElectronicDeviceID = $obj->Name; //Veljavnost $BusinessValidityDate = '2200-01-01'; //Trenutno prijavljen operater $CurrentUser = $_SESSION['uname']; $resql=$db->query("SELECT * FROM llx_user WHERE login = '$CurrentUser'"); $obj = $db->fetch_object($resql); //Davčna številka operaterja $TaxNumber = $obj->TaxNumber; $invoice->date = str_replace(' ', 'T', date('Y-m-d H:i:s')); //Pripravi številko računa $InvoiceNoInt = $invoice->ref; preg_match_all('!\d+!', $InvoiceNoInt, $InvoiceNoIntConv); $InvoiceNoIntConvImp = implode(' ', $InvoiceNoIntConv[0]); $InvoiceNoInt = str_replace(' ', '', $InvoiceNoIntConvImp); //Podatki o računu – lastnosti razreda DavcneBlagajne $config_invoice = array( 'BusinessPremiseID' => $BusinessID, 'businessValidityDate' => $BusinessValidityDate, 'InvoiceNumber' => $InvoiceNoInt, 'ElectronicDeviceID' => $ElectronicDeviceID, // ."'":"null"), 'InvoiceAmount' => $invoice->total_ttc, 'OperatorTaxNumber' => $TaxNumber, 'IssueDateTime' => $invoice->date, 'vat_amount' => $invoice->total_tva, 'InvoiceNetAmount' => $invoice->total_ht, 'TaxRate' => $vat_rate ); $davcnab = new DavcneBlagajne; $davcnab->__construct(); $davcnab->companyTaxNum = ltrim($conf->global->MAIN_INFO_TVAINTRA, 'SI'); //Podatki o digitalnem potrdilu $davcnab->CertPassword = file_get_contents(DOL_DOCUMENT_ROOT.'\custom\davcnablagajna\include\certpass.txt'); $davcnab->CertPasswordP12 = file_get_contents(DOL_DOCUMENT_ROOT.'\custom\davcnablagajna\include\certpass.txt'); $davcnab->data = $config_invoice; $davcnab->createInvoiceMsg(); //pošlji xml sporočilo na FURS $davcnab->postXML2Furs(); $davcnab->generateQR();

Slka 24 prikazuje razred DavcneBlagajne, njegove lastnosti in metode.



Slika 24: Razred DavcneBlagajne, lastnosti in metode Deklaracija razreda DavcneBlagajne je priložena v prilogi 1.

5.9. IZPIS RAČUNA IN QR KODE Davčno potrjen račun mora biti izpisan tako, da vsebuje ZOI, EOR in QR kodo na način, kot ga opisuje 5. člen šestega odstavka Pravilnika o izvajanju Zakona o davčnem potrjevanju računov (pisrs.si, 2018a): »Zaščitna oznaka izdajatelja računa se na računu navede v tekstovni obliki (32 znakov v šestnajstiškem zapisu) in v obliki QR kode, kode PDF 417 ali več črtnih kod tipa Code 128 v skladu s tehničnimi navodili, objavljenimi na portalu eDavki. Kodi QR in PDF 417 morata biti skladni s standardom ISO/IEC 15415. Koda Code 128 mora biti skladna s standardom ISO/IEC 15416. Koda se navede pod tekstovno obliko zaščitne oznake izdajatelja računa.«



Vse tri predvidene kode vsebujejo zapis v dolžini 60 numeričnih mest, ki je sestavljen iz 4 delov (FURS, 2016):

– ZOI iz šestnajstiškega zapisa pretvorjen v desetiški zapis (dolžina 39); če je desetiški zapis manjši od 39 znakov, se doda ustrezno število vodilnih ničel,

– davčna številka zavezanca (8 mest),

– datum in čas izdaje računa v obliki LLMMDDUUMMSS (12 mest),

– kontrolni znak, izračunan kot vsota vseh številk po modulu 10 (vsoto vseh števk delimo z 10, ostanek je kontrolna številka).

QR koda je sestavljena iz 25 x 25 modulov z ravnijo odprave napak »M«. Posamezen modul mora biti natisnjen z ločljivostjo vsaj 4 x 4 pik in minimalna velikost natisnjene QR kode mora biti vsaj 12 mm x 12 mm. QR koda mora biti obdana s prazno obrobo v velikosti vsaj 4 x velikost modula in minimalna velikost prazne obrobe mora biti vsaj 2 mm. Izpisana QR koda ne sme vsebovati slike ali logotipa. Za generiranje QR kode smo uporabili knjižnico phpqrcode, ki je dosegljiva na portalu sourceforge.net, na naslovu http://phpqrcode.sourceforge.net/. PHP QR Code je odprtokodna (LGPL) knjižnica za generiranje QR kode, dvodimenzionalne črtne kode. Zgrajena je na osnovi knjižnice libqrencode C, nudi API za ustvarjanje slik črtne kode QR Code (PNG, JPEG). Izvede se zgolj v PHP, brez zunanjih odvisnosti (phpqrcode.sourceforge.net, 2018).

PHP koda funkcije qenerateQR() za generiranje QR kode pa je naslednja: public function generateQR() { // generate only in case of invoice declaration if(!isset($this->data['IssueDateTime'])) return; $zoiDecimal = $this->md52dec($this->zoi); //v primeru, da je zapis krajši od 39 znakov dodaj 0 $zeros2Add = 39 - strlen($zoiDecimal); for($i = 0; $i < $zeros2Add; $i++) $zoiDecimal = '0'.$zoiDecimal; // izračun vrednosti datuma $tmpNum = explode('T', $this->data['IssueDateTime']); $tmpDate = explode('-', $tmpNum[0]); $dateTimeNumber = substr($tmpDate[0], 2); $dateTimeNumber .= $tmpDate[1]; $dateTimeNumber .= $tmpDate[2]; $dateTimeNumber .= $tmpNum[1]; $dateTimeNumber = str_replace(':', '', $dateTimeNumber); // izračunaj kontrolno številko $qrCode = $zoiDecimal.$this->companyTaxNum.$dateTimeNumber; $controlChar = array_sum(str_split($qrCode)) % 10; // pridobi QR kodo $qrCode = $qrCode.$controlChar; QRcode::png($qrCode, $this->qrDirPath.$this->data['InvoiceNumber'].'.png'); }

http://phpqrcode.sourceforge.net/



Za oblikovanje končnega izpisa računa se uporablja datoteka htdocs/cashdesk/tpl/ticket.tpl.php, kamor smo vpisali tudi kodo, ki na računu izpiše ID za DDV, davčno številko, datum, številko računa, podatke o prodajalcu, EOR, ZOI in QR kodo. <?php print dol_nl2br(dol_format_address($mysoc)); ?><br> <br> <?php echo 'ID za DDV:'.$conf->global->MAIN_INFO_TVAINTRA; ?> <br> <?php echo 'Davčna številka:'.ltrim($conf->global->MAIN_INFO_TVAINTRA, 'SI'); ?> </h6> <h6 class=""><?php $db->begin(); $resql=$db->query("select * from llx_davcnablagajna_invoicerequestdata order by id desc limit 1"); $db->commit(); $obj = $db->fetch_object($resql); $dateTime = $obj->DateTime; $DateTimeFormated = date("d. m. Y.", strtotime($dateTime)); $InvoiceNum = $obj->InvoiceNumber; print 'Datum: '.$DateTimeFormated.'<br>'; print 'Številka računa:'.$InvoiceNum;

$ProtectedID = $obj->ProtectedID; $EOR = $obj->UniqueInvoiceID; $EORno = $obj->InvoiceNumber; print 'Prodajalec: '.$_SESSION['firstname'].' '.$_SESSION['lastname'].'<br>'.'<br>'; print 'EOR:'.$EOR; print '<br>'; print 'ZOI:'.$ProtectedID; <h6/> <div class="Image"> <img src="<?php print '../custom/davcnablagajna/lib/QR/'.$EORno.'.png';?>" alt="QR code"> <h4>Vklopi razum, zahtevaj račun!</h4> ?>

V modul Davčna blagajna smo vgradili še varovalko, ki v primeru, da izgubimo povezavo do strežnikov FURS-a in tako ne pridobimo odgovora na poslane podatke o izdanem računu, izpiše napako »NAPAKA! Trenutno izdaja gotovinskih računov ni možna. Poskusite ponovno kasneje. Očitno je težava s povezavo do FURS strežnikov. Preverite internetno povezavo.« Koda, ki izvede omenjeno funkcijo, je naslednja: $FursResponse = $davcnab->getFURSResponse(); $FursResponseExists = simplexml_load_string($FursResponse); if ($FursResponseExists == null) { exit('NAPAKA! Trenutno izdaja gotovinskih računov ni možna. Poskusite ponovno kasneje. Očitno je težava s povezavo do FURS strežnikov. Preverite internetno povezavo.'); } $FursResponseExists->saveXML(DOL_DOCUMENT_ROOT.'/custom/davcnablagajna/include/fursXML/FursInvoiceResponse.xml');



$davcnab->echoXML(); if($davcnab->returnUUID() == null) { exit('NAPAKA!'); }

Slika 25 prikazuje davčno potrjeni račun, izdan preko modula Davčna blagajna (podatki so izmišljeni).

Slika 25: Davčno potrjen račun, izdan preko modula Davčna blagajna Ob uspešno potrjenem računu se v tabelo llx_davcnablagajna_invoicerequestdata vpišejo podatki o davčno potrjenem računu. Ker osnovne podatke o računih informacijski sistem Dolibarr shranjuje že v tabelo lllx_facture, v tej tabeli shranjujemo le preostale podatke o potrjenem računu. Ostale podatke o računu, kot so vrstice računa in zneski, pa lahko pridobimo iz tabele llx_facture, na katero se lahko za vsak račun sklicujemo po številki računa. Ta je za vsak račun edinstvena.



PHP koda za vpis podatkov o davčno potrjenem računu v bazo podatkov: $InvNo = $davcnab->data['InvoiceNumber']; $Pno = $davcnab->zoi; $MsgId = $davcnab->messageID; $EOR = $davcnab->eor; $db->query("INSERT INTO llx_davcnablagajna_invoicerequestdata (InvoiceNumber, ProtectedID, OperatorTaxNumber, BusinessPremiseID, ElectronicDeviceID, MessageID, UniqueInvoiceID, Informacijski sistem DolibarrInoviceNo) VALUES ('$InvNo', '$Pno', '$TaxNumber', '$BusinessID', '$ElectronicDeviceID', '$MsgId', '$EOR', '$invoice->ref')"); $db->commit();

5.10. TESTIRANJE DELOVANJA MODULA Delovanje modula Davčna blagajna smo testirali na testnih strežnikih FURS-a. V času testiranja ni prišlo do napak pri davčnem potrjevanju računov. Testirali smo vse funkcije, ki smo jih za ta modul razvili, vključno z zaščitami, ki uporabniku blagajne preprečujejo izdajo računa v primeru napake pri potrjevanju računa s strani FURS-a. FURS priporoča, da šele po minimalno dveh dnevih neprekinjenega in stabilnega delovanja v testnem okolju zavezanec preide na produkcijsko okolje. V primeru, da so vsi poslani podatki o poslovnem prostoru oziroma izdanem računu skladni s shemo XML, nam FURS pošlje pozitiven odgovor. V primeru poslanih podatkov o poslovnem prostoru v odgovor prejmemo sporočilo tipa poslovni prostor, v primeru pošiljanja podatkov o računu pa v odgovoru prejmemo sporočilo tipa račun in EOR kodo. Odgovora na sporočilo tipa račun prikazuje spodnji XML dokument: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:fu="http://www.fu.gov.si/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><fu:InvoiceResponse Id="data"><fu:Header><fu:MessageID>a7ef2a88-4b5d-4ef2-8e49-e1891acb5014</fu:MessageID><fu:DateTime>2018-02-08T21:20:26</fu:DateTime> </fu:Header><fu:UniqueInvoiceID>74f137e3-168a-427d-80c3-893204a58fb2</fu:UniqueInvoiceID> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#data"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>ePPlk9FVpFK5xQSdxHs+nsyXhN3WUFyywE36NBSiJmk=</DigestValue></Reference></SignedInfo><SignatureValue>PDufDfpEJOe26Sf3RN2XxkJHCZha+ytNyx0WlxikY8UbszRgX77VaiPNtEVbZSbejR+MwX+5ZhPQ8wUxr/4BPgb+6V2wPVPguvEzm/F2lqTUVQMtzH+vN/NsLyoGMVbOPKZu1sBD0rQVw



HtQix95fK16MLe8vfFvAMJfZPK47q+lcuP9eOVp5i6OHU2tVMKSZFBnxoOG0zePYY92ySduf05uSoPToDzAx9iSZiv8UN9huInnTFz3NPocLV7uqvUg161XwrpyTiK5NJSA7nD95xwAHDcX2/Z9/2rMlg5dX3EHMZ8YIzqxDHCNY42s9YR8he1dAselsnZSA4524Kj7Dg==</SignatureValue><KeyInfo><X509Data><X509SubjectName>CN=FURS, OID.2.5.4.5=1, OU=77695771, OU=DavPotRacTEST, O=state-institutions, C=SI</X509SubjectName><X509IssuerSerial><X509IssuerName>CN=Tax CA Test,O=state-institutions,C=SI</X509IssuerName><X509SerialNumber>4723074879886330622</X509SerialNumber></X509IssuerSerial><X509Certificate>MIIFXjCCA0agAwIBAgIIQYu7lE8yCv4wDQYJKoZIhvcNAQELBQAwQDELMAkGA1UEBhMCU0kxGzAZ BgNVBAoMEnN0YXRlLWluc3RpdHV0aW9uczEUMBIGA1UEAwwLVGF4IENBIFRlc3QwHhcNMTUwODA0MTMxMjQ3WhcNMjAwODA0MTMxMjQ3WjBwMQswCQYDVQQGEwJTSTEbMBkGA1UECgwSc3RhdGUtaW5zdGl0dXRpb25zMRYwFAYDVQQLDA1EYXZQb3RSYWNURVNUMREwDwYDVQQLDAg3NzY5NTc3MTEKMAgGA1UEBRMBMTENMAsGA1UEAwwERlVSUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIf8jVOE1Je+Jqbs+I+LMK3/OUJ/Zj1GbAfdWst/grzKKEh93oeIACEvqrJuOZy0qb05NWJ0ra8J4a7DgL4UM7Hzc9Os8TgkT5A7Dh85wlAXgOKk4GDi6lHliHmaHlaq0ymP2KAvTo3yenmWVcIniQYgbziDGXbHLtMfHphtqXDh38rFhFESE8m453mLtzNUOBD7JQbRZ2k5XcJtoFOXdwUIwif9KzRm/u7E3TqEVvuVQ7kucli5zHoDC6EiF6i/BqAUcNuNYmTBTFlxSZnUjOiWgij+DOvFHw36cu4ItrWeXL8JHIZy8gvxGNMPJFk4/Ei09OGeMglIUxFtVtiKwGUCAwEAAaOCASowggEmMHAGCCsGAQUFBwEBBGQwYjA0BggrBgEFBQcwAoYoaHR0cDovL2NhLXRlc3QuZ292LnNpL2NlcnQvVGF4Q0FUZXN0LmNydDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AtdGF4Y2EtdGVzdC5nb3Yuc2kvMB0GA1UdDgQWBBQUVWsPgf2GcmPAg/v/uYMbIFC+yDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFDPNWvsJR8cB5jYoJvWBfLeONfeyMBoGA1UdIAQTMBEwDwYNKwYBBAGChG+PXwcVATA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY2EtdGVzdC5nb3Yuc2kvY3JsL1RheENBVGVzdC5jcmwwDgYDVR0PAQH/BAQDAgeAMA0GCSqGSIb3DQEBCwUAA4ICAQBDONBas74WUY8JSOO0/zlSrk2xWHIB7jpQsyfyAGrfYUwmA684eWuBqEfpOBx1FlmYyT2iURFmwGApXTNfBN6rZyY0LHW6R5N/g0bifsRJZgZBh+SijguOtl+yujeNBqmAikwpfSUxSyQwuGGOw29LC2n/f5kPaM5cRiXAZx3jkROxTAAHYNjc2//+j8xBU5foA8Z2YG/utI3mqy//FAtd 1TKmpUmCdMKQ1A7jZlGz8FdB38TPg8OAUfnVQPGgXJJ3sMpk7JXRPRGHHenlRfnOXyuKLa62TsG+JTaJ+HEUIEAPI5Gm0usWDsaSZ7oGyD0dPngSEvIT3/8KbYge4bxE0Eb20dnz6/6/HZo4gBqT3OZMCu3rzBUlae+/1ALDhGnqOUZEygAljKgqUn/o5K0QrWCHysusmTgefJHNxXPXQgkL0KOcjkNoojSnidaiLW35XoB7QKWObjK8EgJvsHir18f82e3AP3tJkBgHu3UD0y/A20Nb4fujWcE337dAHwsVA+DPujN8IanDDNhRnFPutiuc4Y6GMnHSplfJBqDHtUTNmucrnIT/R0KbPDDs6q/DDICyYnxtgdypwVDkNHIEYr8U+Q1yIWxsqKp6Kk6/NkAKiiXhFz+XHZx+vaKZ90F7yW+dV5F/zALaXLFuw2Z1maxmQFit7S47Usm2e/Hfgg==</X509Certificate></X509Data><KeyValue><RSAKeyValue><Modulus>h/yNU4TUl74mpuz4j4swrf85Qn9mPUZsB91ay3+CvMooSH3eh4gAIS+qsm45nLSpvTk1YnStrwnhrsOAvhQzsfNz06zxOCRPkDsOHznCUBeA4qTgYOLqUeWIeZoeVqrTKY/YoC9OjfJ6eZZVwieJBiBvOIMZdscu0x8emG2pcOHfysWEURITybjneYu3M1Q4EPslBtFnaTldwm2gU5d3BQjCJ/0rNGb+7sTdOoRW+5VDuS5yWLnMegMLoSIXqL8GoBRw241iZMFMWXFJmdSM6JaCKP4M68UfDfpy7gi2tZ5cvwkchnLyC/EY0w8kWTj8SLT04Z4yCUhTEW1W2IrAZQ==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue></KeyInfo></Signature></fu:InvoiceResponse></soapenv:Body> </soapenv:Envelope>

Kadar poslani podatki niso ustrezni, pa v odgovor na naše poslano sporočilo prejmemo šifro napake. Seznam napak z opisom prikazuje slika 26.



Slika 26: Šifrant napak (FURS, 2016)



Za namen testiranja pri razvoju programske opreme je FURS za razvijalce pripravil spletno aplikacijo, kjer je možno preveriti zapise o registriranih poslovnih prostorih in davčno potrjenih računih. Tako smo se tudi mi poslužili te možnosti. Spletna aplikacija za preverjanje podatkov o registriranem poslovnem prostoru je dosegljiva na spletni povezavi: https://blagajne-test.fu.gov.si:9002/cash_registers/ui/check_premise/index.html Na sliki 27 so izpisani podatki o poslovnem prostoru z oznako TRGLJ36, testnega podjetja z davčno številko 10374540, ki jih hrani FURS. Ta zapis dokazuje registracijo poslovnega prostora.

Opis Indeks Vrednost

FURS datum sprejema sporočila

30.01.2018 19:14

Identifikator sporočila P_1.0 e76d3dd1-ad1f-47c0-ada8-1d4d04f2002f

Datum in čas pošiljanja P_2.0 30.01.2018 19:14

Davčna številka P_3.0 10374540

Oznaka poslovnega prostora

P_4.0 TRGLJ36

Premični poslovni prostor P_5.2 C

Datum začetka veljavnosti podatkov

P_6.0 30.01.2018

Vzdrževalec št.1: Davčna številka vzdrževalca programske opreme

P_8.1 31362346

Slika 27: Podatki o registriranem poslovnem prostoru iz informacijskega sistema

Finančne uprave Spletna aplikacija za preverjanje davčno potrjenih računov je dosegljiva na spletni povezavi: https://blagajne-test.fu.gov.si:9002/cash_registers/ui/check_invoice/index.html Za izpis podatkov o potrjenem računu je potrebno v spletni obrazec vpisati EOR kodo ali ZOI kodo in davčno številko.

https://blagajne-test.fu.gov.si:9002/cash_registers/ui/check_premise/index.html

https://blagajne-test.fu.gov.si:9002/cash_registers/ui/check_premise/index.html

https://blagajne-test.fu.gov.si:9002/cash_registers/ui/check_invoice/index.html



Na sliki 28 so izpisani podatki o računu, ki smo ga izdali preko modula Davčna blagajna. FURS hrani račun pod številko 18258, izdan je bil v poslovnem prostoru TRGLJ36 z elektronsko napravo BLAG14.

Opis Indeks Vrednost

FURS datum sprejema sporočila

31.01.2018 20:05

Identifikator sporočila R_1.0 04915051-bb3b-4737-a34b-7c2224d505cf

Datum in čas pošiljanja

R_2.0 31.01.2018 20:05

EOR c5e3a798-c451-4c74-bb68-a2639bc6181c

Davčna številka zavezanca

R_3.1 10374540

Datum in čas izdaje računa

R_3.2 31.01.2018 20:05

Vrednost računa R_3.6 32.79

Vrednost za plačilo R_3.8 32.79

Davčna številka operaterja

R_3.10 31362346

Operater nima slovenske davčne številke

R_3.11 NE

Oznaka poslovnega prostora

R_3.4.1 TRGLJ36

Oznaka elektronske naprave

R_3.4.2 BLAG14

Zaporedna številka računa

R_3.4.3 18258

Zaščitna oznaka izdajatelja računa

R_3.12 15ebf5b7b4acc81af861e4984ab8b04a

Način dodelitve številke računa

R_3.3 C



Oznaka naknadnega posredovanja računa

R_3.13 NE

Davek št.1: Davčna številka davčnega zavezanca

R_3.9.1 10374540

Davek št.1: Davčna stopnja št.1: Davčna stopnja

R_3.9.2.1 22

Davek št.1: Davčna stopnja št.1: Davčna osnova

R_3.9.2.2 26.88

Davek št.1: Davčna stopnja št.1: Davek

R_3.9.2.3 5.91

Slika 28: Podatki o davčno potrjenem računu



6. ZAKLJUČKI

Modul Davčna blagajna je pripravljen za uporabo in implementacijo v celovitem informacijskem sistemu Dolibarr. Osnovni namen magistrske naloge je bil dosežen, saj lahko na podlagi razvitega modula informacijski sistem Dolibarr uporabljamo tudi kot davčno blagajno po Zakonu o davčnem potrjevanju računov. Modul je bil razvit za informacijski sistem Dolibarr verzije 6.0.4., ki je bila najnovejša različica v času razvoja modula, modul pa naj bi deloval tudi na novejših različicah. Delovanja na novejših različicah zaradi časovnih omejitev nismo testirali. Modul Davčna blagajna smo preverili v testnem okolju in na testnih strežnikih FURS-a, kar zagotavlja delovanje tudi v produkcijskem okolju, saj v primeru implementacije modula v produkcijsko okolje le-to ne bo vplivalo na delovanje modula, ampak se bodo spremenili le parametri o strežnikih za pošiljanje podatkov o poslovnem prostoru in davčno potrjenem računu. Prav tako so za produkcijsko okolje s strani FURS izdana druga namenska digitalna potrdila, ki imajo enako strukturo. Razlika je v tem, da le-ta vsebujejo podatke o obstoječih pravnih subjektih. Pred izdajo računov po zakonu o davčnem potrjevanju računov morajo zavezanci, ki uporabljajo večje število poslovnih prostorov in elektronskih naprav, v skladu s šestim odstavkom 5. člena Zakona o davčnem potrjevanju računov – ZDavPR (Uradni list RS, št. 57/15) sprejeti interni akt o popisu poslovnih prostorov, dodelitvi oznak poslovnim prostorom in pravilih za dodeljevanje zaporednih številk računov. Primer internega akta o popisu poslovnih prostorov, dodelitvi oznak poslovnim prostorom in pravilih za dodeljevanje zaporednih številk računov je opisan v prilogi 2. Skozi razvojne faze se nam je porodilo kar nekaj idej, kako bi kakovost razvitega modula še povečali, jih implementirali v izvorno kodo in tako modul še dodatno oplemenitili. Te funkcionalnosti so predvsem kontrola vseh pogojev, ki morajo biti izpolnjeni, da lahko pričnemo z uporabo davčne blagajne, in pa varovala, ki preprečujejo izdajo računov v primeru napak pri povezavi s strežniki FURS ali manjkajočih podatkih o operaterju, poslovnem prostoru in elektronski napravi. Modul Davčna blagajna bi bilo vsekakor smiselno še dodatno razvijati in izpopolniti, predvsem v smeri varoval pred izdajo računov v primeru raznih napako oziroma izpadov, operaterjem bi lahko omejili izdajanje računov le na določen poslovni prostor oziroma elektronsko napravo. Boljša rešitev pa bi bila zaklep poslovnega prostora glede na IP naslov, s katerega se uporabnik povezuje na strežnik informacijskega sistema Dolibarr. Tako bi izključili možnost človeške napake pri izdaji računov. V razviti različici modula Davčna blagajna uporabnik lahko hipotetično izbere napačno blagajno in prične izdajati račune v poslovnem prostoru, v katerem ta blagajna ni registrirana, s tem pa bi prišlo do kršitve Zakona o davčnem potrjevanju računov.



LITERATURA IN VIRI

apache.org. (2018). Welcome to The Apache Software Foundation! Pridobljeno 16.

marec 2018, od https://www.apache.org/ Damjan Vavpotič, Marko Bajec, M. K. (2006). Vpliv MDA na proces razvoja

programske opreme. Elektronski vestnik, (Mdd). DAVČNO POTRJEVANJE RAČUNOV - Tehnične specifikacije (2018). Pridobljeno 4.

marec 2018., od http://www.datoteke.fu.gov.si/dpr/index.html dolibarr.org. (2017). Dolibarr Open Source ERP CRM software - for small, medium

and large business. Pridobljeno 17. januar 2017, od https://www.dolibarr.org/

dolibarr.org. (2018a). Category:Table SQL - Dolibarr Open Source ERP CRM Wiki. Pridobljeno 4. marec 2018, od https://wiki.dolibarr.org/index.php/Category:Table_SQL

dolibarr.org. (2018b). Developer documentation - Dolibarr Open Source ERP CRM Wiki. Pridobljeno 4. marec 2018, od https://wiki.dolibarr.org/index.php/Developer_documentation

dolibarr.org. (2018c). Module development - Dolibarr Open Source ERP CRM Wiki. Pridobljeno 4. marec 2018, od https://wiki.dolibarr.org/index.php/Module_development

Dolibarr.org. (2017). UML2Dolibarr - Build a module using MDA - Dolibarr Open Source ERP CRM Wiki. Pridobljeno 19. januar 2017, od https://wiki.dolibarr.org/index.php/UML2Dolibarr_-_Build_a_module_using_MDA

Dolibarr.org. (2018). User documentation - Dolibarr Open Source ERP CRM Wiki. Pridobljeno 11. marec 2018, od https://wiki.dolibarr.org/index.php/User_documentation

edavki.durs.si. (2017). eDavki - Pogosta vprašanja. Pridobljeno 17. januar 2017, od https://edavki.durs.si/OpenPortal/Pages/Faq/FaqPreview.aspx?id=695

FURS. (2016). Davčno potrjevanje računov / Fiscal verification of invoices. Lie, H. W., & Bos, B. (1999). Cascading style sheets : designing for the Web.

Addison-Wesley. Pridobljeno od https://www.w3.org/Style/CSS/ mysql.com. (2018). MySQL :: Why MySQL? Pridobljeno 16. marec 2018, od

https://www.mysql.com/why-mysql/ opensource.org. (2018). Top 4 open source ERP systems | Opensource.com.

Pridobljeno 16. marec 2018., od https://opensource.com/resources/top-4-open-source-erp-systems

php.net. (2017). PHP: Hypertext Preprocessor. Pridobljeno 17. januar 2017, od http://php.net/

phpqrcode.sourceforge.net. (2018). PHP QR Code - QR code generator, an LGPL PHP library. Pridobljeno 4. marec 2018., od http://phpqrcode.sourceforge.net/

pisrs.si. (2018a). Pravilnik o izvajanju Zakona o davčnem potrjevanju računov. Pridobljeno 4. marec 2018, od http://www.pisrs.si/Pis.web/pregledPredpisa?id=PRAV12531

pisrs.si. (2018b). Zakon o davčnem potrjevanju računov (ZDavPR). Pridobljeno 18. marec 2018, od http://www.pisrs.si/Pis.web/pregledPredpisa?id=ZAKO7195

w3.org. (2018). Extensible Markup Language (XML). Pridobljeno 16. marec 2018, od https://www.w3.org/XML/



w3.org. (2018). Simple Object Access Protocol (SOAP) 1.1. Pridobljeno 16. marec 2018, od https://www.w3.org/TR/2000/NOTE-SOAP-20000508/

w3.org. (2018). W3C HTML. Pridobljeno 16. marec 2018, od https://www.w3.org/html/

wiki.dolibarr.org. (2018a). Category:List of Modules - Dolibarr Open Source ERP CRM Wiki. Pridobljeno 4. marec 2018, od https://wiki.dolibarr.org/index.php/Category:List_of_Modules

wiki.dolibarr.org. (2018b). UML2Dolibarr - Build a module using MDA - Dolibarr Open Source ERP CRM Wiki. Pridobljeno 4. marec 2018, od https://wiki.dolibarr.org/index.php/UML2Dolibarr_-_Build_a_module_using_MDA

Wikipedia.org. (2018). Dolibarr. Pridobljeno 4. marec 2018, od https://en.wikipedia.org/wiki/Dolibarr

www.fu.gov.si. (2016). DAVČNO POTRJEVANJE RAČUNOV - Tehnične specifikacije. Pridobljeno 3. december 2016, od http://www.datoteke.fu.gov.si/dpr/index.html

PRILOGE Priloga 1: Deklaracija razreda DavcneBlagajne Priloga 2: Interni_akt_-_primer_3 – primer internega akta o popisu poslovnih prostorov, dodelitvi oznak poslovnim prostorom in pravilih za dodeljevanje zaporednih številk računov.



KAZALO SLIK Slika 1: PHP v HTML kodi .......................................................................................... 4 Slika 2: XML koda ..................................................................................................... 6 Slika 3: CSS lastnosti vključene v HTML ................................................................... 7 Slika 4: Podprte funkcije odprtokodnega informacijskega sistema Dolibarr (dolibarr.org, 2017) .................................................................................................. 8 Slika 5: Odprtokodni informacijski sistem Dolibarr .................................................. 9 Slika 6: Zaslon za upravljanje modulov .................................................................. 11 Slika 7: Zavezanec po Zakonu o davčnem potrjevanju računov (FURS, 2015) ........ 17 Slika 8: UML diagram primerov uporabe modula Davčna blagajna ......................... 19 Slika 9: Aktivacija modula Davčna blagajna ........................................................... 20 Slika 10: Nastavitve strežnika WAMP ...................................................................... 21 Slika 11: Tabele modula Davčna blagajna .............................................................. 23 Slika 12: Vmesnik za upravljanje nastavitev modula Davčna blagajna .................. 26 Slika 13: Obrazec za vnos podatkov o elektronski napravi ..................................... 27 Slika 14: Obrazec za vnos podatkov o poslovnem prostoru .................................... 27 Slika 15: Obrazec za vnos davčnih številk blagajnikov ........................................... 28 Slika 16: XSD shema za digitalno podpisovanje XML sporočil (FURS, 2016) ............ 29 Slika 17: Proces izdaje sporočila s podatki o poslovnem prostoru (FURS, 2016) .... 33 Slika 18: Hitri pregled nastavitev, ko pogoji za uporabo modula niso izpolnjeni ... 39 Slika 19: hitri pregled nastavitev, ko so vsi pogoji za uporabo modula izpolnjeni . 40 Slika 20: Proces izdaje računa (FURS, 2016) .......................................................... 43 Slika 21: Prijavno okno za modul Davčna blagajna ................................................ 53 Slika 22: Modul Davčna blagajna ............................................................................ 54 Slika 23: Zaslon za potrditev računa ...................................................................... 55 Slika 24: Razred DavcneBlagajne, lastnosti in metode........................................... 57 Slika 25: Davčno potrjen račun, izdan preko modula Davčna blagajna .................. 60 Slika 26: Šifrant napak (FURS, 2016) ...................................................................... 63 Slika 27: Podatki o registriranem poslovnem prostoru iz informacijskega sistema Finančne uprave ..................................................................................................... 64 Slika 28: Podatki o davčno potrjenem računu ........................................................ 66

KAZALO TABEL Tabela 1: Seznam tabel informacijskega sistema Dolibarr (dolibarr.org, 2018a) ... 13 Tabela 2: Lastnosti tabele llx_user ........................................................................ 25 Tabela 3: Elementi XML za podatke o poslovnem prostoru (FURS, 2016) ............... 37 Tabela 4: Elementi XML za podatke o izdanem računu (FURS, 2016) ..................... 47

POJMOVNIK QR koda – je matrična oz. dvodimenzionalna črtna koda, ki jo je za potrebe avtomobilskega proizvajalca Toyota leta 1994 razvila njegova podružnica Denso-Wave. Beseda QR je kratica za angleški besedi »Quick Response«, kar pomeni »hiter odziv«.



P12 – V kriptografiji PKCS # 12 definira arhivsko obliko datoteke za shranjevanje številnih objektov kriptografije kot ene datoteke. Ponavadi se uporablja za združevanje zasebnega ključa s svojim certifikatom X.509 ali za združevanje vseh članov verige zaupanja. TLS – je protokol, namenjen zagotavljanju integritete zasebnosti in podatkov med dvema komunikacijskima računalniškima aplikacijama.

KRATICE IN AKRONIMI PHP – Hypertext Preprocessor, personal home page. HTML – Hyper Text Markup Language HTTP – Hypertext Transfer Protocol CSS – Cascading Style Sheets XML – Hypertext Markup Language MDA – Model driven arhitecture ISFU – Informacijski sistem Finančne uprave EOR – Enkratna identifikacijska oznaka računa ZOI – Zaščitna oznaka izdajatelja računa FURS – Finančna uprava Republike Slovenije ZDavPR – Zakonu o davčnem potrjevanju računov IP – internet porotokol MJU – Ministrstvo za javno upravo PDF – Portable Document Format LDAP – Lightweight Directory Access Protocol PIM – Platform Independent Model IDE – Integrated Development Enviroment

RAZVOJ MODULA »DAVN A BLAGAJNA« ZA ODPRTOKODNI ERP … · Razvoj modula Davčna blagajna je obsegal predvsem: prilagoditev baze podatkov, razvoj vmesnika za upravljanje modula,

Documents