Univerza v Ljubljani
Fakulteta za računalništvo in informatiko
Gal Lindič
Razširitev poslovne aplikacije z
možnostjo izdaje eRačuna po standardu eSlog 2.0
DIPLOMSKO DELO
VISOKOŠOLSKI STROKOVNI ŠTUDIJSKI PROGRAM PRVE STOPNJE
RAČUNALNIŠTVO IN INFORMATIKA
Mentor : doc. dr. Rok Rupnik
Ljubljana, 2021
Copyright. Rezultati diplomske naloge so intelektualna lastnina avtorja in matične fakultete Univerze v Ljubljani. Za objavo in koriščenje rezul- tatov diplomske naloge je potrebno pisno privoljenje avtorja, fakultete ter mentorja.
Kandidat: Gal Lindič
Naslov: Razširitev poslovne aplikacije z možnostjo izdaje eRačuna po stan- dardu eSlog 2.0
Vrsta naloge: Diplomska naloga na visokošolskem programu prve stopnje Računalništvo in informatika
Mentor: doc. dr. Rok Rupnik
Opis:
Analizirajte obstoječo poslovno aplikacijo in trenutni način izdajanja raču- nov. Nato analizirajte možnosti izdajanja in pošiljanja elektronskih računov strankam. Nato izdajanje in pošiljanje elektronskih računov kot dodaten modul poslovne aplikacije implementirajte na podlagi standarda eSlog 2.0 in uporabo EBA dokumentnega sistema.
Rad bi se zahvalil mentorju doc. dr. Roku Rupniku za strokovno svetovanje, potrpežljivost in spodbudo pri nastajanju diplomskega dela. Iskrena hvala tudi staršem za vso podporo in vsem ostalim, ki ste mi vsa ta leta stali ob strani.
Kazalo
Povzetek Abstract
1 Uvod 1
1.1 Predstavitev problema . . . 1
1.2 Predstavitev obstoječega sistema . . . 2
1.3 Cilj diplome . . . 2
1.4 Pregled sorodnih primerov . . . 2
1.5 Struktura diplome . . . 3
2 Orodja in tehnologije 5 2.1 Informacijski sistem . . . 5
2.2 Podatkovna baza . . . 5
2.3 EBA . . . 6
2.3.1 EBA-Developer . . . 6
2.3.2 EBA-tiskalnik . . . 6
2.4 API . . . 7
2.5 XML . . . 8
2.6 SOAP . . . 9
2.7 WSDL . . . 10
3 ePoslovanje 13 3.1 Razvoj ePoslovanja . . . 14
3.2 Vrste elektronskega poslovanja . . . 15
3.3 eDokument . . . 16
3.4 eRačun . . . 17
3.4.1 Prednosti in slabosti . . . 18
3.5 Glavni procesi poslovanja z eRačuni . . . 18
3.5.1 Kreiranje eDokumenta in elektronski podpis . . . 19
3.5.2 Pošiljanje in izmenjava eDokumenta . . . 19
3.5.3 Prejem in obdelava eDokumenta . . . 20
3.5.4 Arhiviranje eDokumenta . . . 20
4 Analiza 21 4.1 Podatkovni model . . . 21
4.2 Diagram primerov uporabe . . . 22
5 Proces izdaje eRačunov 25 5.1 Načrtovanje . . . 25
5.2 Zasnovani procesi . . . 25
5.2.1 Obstoječ sistem za izdajo eRačunov . . . 25
5.2.2 Prvotno zasnovan model . . . 27
5.2.3 Nadgradnja zasnovanega modela . . . 29
5.2.4 Nadgradnja modela z neodvisnim modulom . . . 32
5.3 Predstavitev implementiranega procesa . . . 32
6 Sklep 37 6.1 Ideje za nadaljnji razvoj . . . 37
Seznam uporabljenih kratic
kratica angleško slovensko
API application programming in- terface
vmesnik za namensko progra- miranje
B2B business to business medpodjetniško poslovanje B2C business to customer poslovanje med podjetjem in
potrošnikom
B2G business to government poslovanje med vladami CRUD create, read, update and delete ustvarjanje, branje, posoda-
bljanje in brisanje
ERP enterprise resource planning upravljanje podjetniških virov HTTP hypertext transfer protocol protokol za prenos hiperteksta HTTPS hypertext transfer protocol se-
cure
varen protokol za prenos hiper- teksta
PDF portable document format prenosna oblika dokumenta
P2P peer to peer mreženje
RIP electronic data interchange računalniška izmenjava podat- kov
RPC remote procedure call Klic oddaljene procedure SMTP simple mail transfer protocol protokol za prenos elektronske
pošte
SOAP simple object access protocoly protokol za izmenjavo podat- kov
SQL structured query language strukturirani povpraševalni je- zik
UJP public payments ddministra- tion
uprava republike Slovenije za javna plačila
UML unified modelling language poenoteni jezik modeliranja WSDL web services description langu-
age
vmesnik za definicijo spletnih storitev
XML extensible markup language razširljivi označevalni jezik
Povzetek
Naslov: Razširitev poslovne aplikacije z možnostjo izdaje eRačuna po stan- dardu eSlog 2.0
Avtor: Gal Lindič
V diplomskem delu smo raziskovali problem izdaje računov in slabosti, ki so prisotne, če se ne uporablja elektronskega poslovanja. Analizirali smo trenutni proces izdaje računov, ki ga uporablja podjetje, nato pa smo na podlagi tega začeli z zasnovo novega. Pri načrtovanju smo izdelali diagrame primerov uporabe, kjer smo lahko preučevali, kako bi potekala interakcija osebe s procesom. Po uspešni analizi smo začeli z implementacijo, po koncu pa smo naredili analizo novega procesa in preučili, če zadovolji potrebe ali ne.
V primeru neuspešne analize smo na novo načrtovali nadgradnjo procesa in ponovili postopek. Po večih nadgradnjah smo imeli končni proces, ki rešuje vse pomanjkljivosti prejšnjega, je avtomatiziran in dolgoročen.
Ključne besede: elektronsko poslovanje, avtomatizacija procesa.
Abstract
Title: Diploma thesis sample Author: Gal Lindič
In this thesis, we investigated invoicing and the disadvantages that were present if e-commerce is not used. We have analyzed current issuance pro- cess used by the company, and then based on the information gathered, we conceived a new one. When designing it, we made use of use case diagrams, where we could predict how people would interect with said process. After a successful analysis, we started with the implementation, and after the end of it, we analyzed new procedure if it met the needs. In case of unsuccess- ful analysis we the re-planned the whole process upgrade and repeated said steps. After several upgrades, we had a final process that resolves missing deficiency on the previous one, is automated and built for long-term use.
Keywords: electronic commerce, automating the process.
Poglavje 1 Uvod
V sodobnem svetu vse vedno bolj temelji na digitalizaciji. Ta korak v sodob- nejše in modernejše procese nam omogočajo računalniški sistemi in globalna omrežja, brez katerih si prihodnosti sploh ne bi mogli predstavljati. Upora- bljamo jih za komunikacijo, igranje iger, krajšanje časa, brskanje po spletu, iskanje poti in še za marsikaj drugega. Ti sistemi pa niso namenjeni samo vsakdanji rabi, ampak omogočajo tudi lažje poslovanje ustanovam. Dandanes si lahko partnerji med seboj izmenjujejo informacije po zanesljivi elektronski poti v obliki strukturiranih elektronskih dokumentov. Ena od takšnih oblik je tudi ePoslovanje in uporaba eRačuna.
1.1 Predstavitev problema
S klasičnim načinom izvajanja poslovanja se dandanes ukvarja veliko usta- nov, posameznikov in podjetij. Poleg vseh novosti, ki jih je prinesela takšna oblika poslovanja, pa se pojavljajo tudi slabosti, večinoma neekološke - za vsak izdan račun je potrebno uporabiti papir in črnilo za tiskanje. Takšno poslovanje v današnjem času, ko imamo vedno več avtomatizacije in digita- lizacije, predstavlja potrato časa. Slaba plat vsega tega pa je, da se večkrat ti računi po tiskanju še skenirajo in shranijo v elektronski obliki. S takšnim procesom je narejen korak naprej in dva nazaj. Podjetja se torej dandanes
1
2 Gal Lindič srečujejo s pomanjkljivostmi slabo definiranega procesa izdaje računov in hkrati nezaupljivostjo do nove tehnologije.
1.2 Predstavitev obstoječega sistema
Podjetje ima ERP-sistem, v katerem imajo izdelane obrazce za interno po- slovanje. Trenutno nima zasnovanega procesa izdaje eRačunov. Za izdelavo le-tega uporabljajo tudi starejšo različico standarda eSLOG 1.6, ki je od 1.
10. 2020 ukinjena. Njihova izdelava in izdaja eRačunov je naslednja: oseba prepiše podatke o fakturi (račun) iz obrazca ERP v Excelovo preglednico, kjer so spisani makroji, ki po standardu eSLOG 1.6. zgenerirajo XML-datoteko s podatki eRačuna. Za tem oseba še ročno zgenerira PDF-vizualizacijo računa in jo skupaj s prej omenjenim XML-dokumentom pošlje.
1.3 Cilj diplome
Zaradi prej opisanih težav smo se v okviru diplomskega dela odločili izde- lati nov sistem za izdajo eRačunov, ki bo deloval po najnovejšem standardu eSLOG 2.0. Iz obstoječega sistema se bodo ohranili ERP-obrazci, ki jih bomo nadgradili in ustvarili povezavo na sistem za izdelavo eRačunov, na koncu se bo pa še uporabil EBA dokumentni sistem za izdajo eRačuna.
1.4 Pregled sorodnih primerov
Na področju eRačunov lahko najdemo več standardov. V Sloveniji je eSLOG najbolj razširjen standard in je tudi formalno predpisan za pošiljanje eRaču- nov proračunskim uporabnikom. Eden od najbolj prepoznavnih standardov za izmenjavo elektronskih podatkov pa je EDIFACT, ki se uporablja za izme- njavo elektronskih podatkov za administracijo, trgovino in promet. V sklopu diplomskega dela se je za implementacijo procesa izdaje eRačunov izbral standard eSLOG 2.0, ki je tudi trenutno najnovejša različica standarda.
Diplomska naloga 3
1.5 Struktura diplome
Diplomsko delo je razdeljeno na štiri večja poglavja: Orodja in tehnologije, ePoslovanje, Analiza in Proces izdaje eRačuna. V prvem so opisana upo- rabljena razvojna okolja, podatkovna baza in razna orodja, ki smo se jih posluževali pri izdelavi. Poleg tega so opisane tudi tehnologije, ki smo jih potrebovali za implementacijo. V drugem delu smo predstavili, kaj je ePoslo- vanje, kako deluje in kaj je eRačun. V tretjem poglavju analiziramo trenutni proces izdaje eRačuna v podjetju in kakšne so možnosti nadgradnje, nare- dimo pa tudi analizo, kako bo nov proces izboljšal delovanje. V tem poglavju so tudi predstavljeni podatkovni modeli in diagrami primerov uporabe za- snovanega procesa izdaje. V zadnjem poglavju bolj detajlno osvetlimo, kako deluje trenutni proces izdaje, nato pa predstavimo vsako nadgradnjo le-tega, njegove slabosti/pomanjkljivosti in kaj je posamezna nadgradnja prinesla.
4 Gal Lindič
Poglavje 2
Orodja in tehnologije
V tem poglavju bomo predstavili orodja in tehnologije, uporabljene za razvoj sistema. Vsako izmed naštetih orodij na kratko opišemo, tehnologije pa za lažje razumevanje prikažemo še s primeri delovanja.
2.1 Informacijski sistem
Podjetje uporavlja informacijski sistem Krmar. To je 32-bitni IS, ki ima svoje lastno razvojno okolje SE, ki je bilo razvito do stopnje, ki omogoča izdelavo vsakovrstnih aplikacij. Zgradba Krmarja je modularna in omogoča izdelavo programov, ki se kasneje uporabljajo v več modulih (komerciala, finance, računovodstvo itd.). Ima arhitekturo odjemalec - strežnik, kjer vsak opravi svoj del posla, ima pa tudi nekaj lastnosti trinivojskih sistemov, saj nekaj obdelav in programov izvaja tudi aplikacijski strežnik.
2.2 Podatkovna baza
Podjetje uporablja podatkovno bazo Microsoft SQL Server.To je sistem za upravljanje relacijskih baz, ki ga je razvil Microsoft. Uporabljajo različico 2008, ki je še edina, ki jo podpira Krmar IS.
5
6 Gal Lindič
2.3 EBA
EBA DMS je napredni dokumentni sistem, ki omogoča brezpapirno poslo- vanje v podjetjih, ustanovah in administrativnih službah. Omogoča preje- manje dokumentov iz različnih virov: po epošti in preko ostalih programov ter aplikacij v podjetju. Številni procesi v podjetjih so definirani s pravili in postopki. EBA omogoča uporabo obstoječih pravil in postopkov, s čimer lahko optimiziramo in avtomatiziramo celotne procese obdelave dokumentov.
EBA ne podpira samo RIP, je programska rešitev, ki omogoča B2B-izmenjavo podatkov [2].
2.3.1 EBA-Developer
Dokumentni sistem EBA DMS ima razvito svoje lastno razvojno okolje za razvoj dodatnih funkcionalnosti. To razvojno okolje omogoča dodaten razvoj specifičnih funkcionalnosti sistema, s katerimi se povečuje fleksibilnost EBA- sistema, saj lahko vsak razvijalec razvije dodatne module, ne da bi posegal v jedro sistema. Namen tega je, da lahko razvijalci sami razvijejo funkcionalno- sti, ki pokrivajo njihove specifične potrebe. Razvojno okolje EBA-Developer omogoča razvoj teh programskih modulov, za razvoj pa uporablja JavaScript programski jezik. Razviti moduli se imenujejo vtičniki, ki jih lahko nato vključimo v delovanje sistema ali pa jih po želji izključimo [3].
2.3.2 EBA-tiskalnik
EBA DMS ima že integrirane rešitve z določenimi ERP-sistemi, ki omogočajo direkten prenos dokumentov v sistem. Kaj pa pri ERP-sistemih, ki tega nimajo? Tukaj nastopi EBA-printer. Je navidezni tiskalnik, preko katerega lahko v ERP-sistemu virtualno natisnemo dokument, katerega nato zajame EBA DMS. Omogoča zajemanje poljubnih tipov dokumentov, iz poljubnih programov. [Slika 2.1].
Diplomska naloga 7
Slika 2.1: Primer delovanja navideznega tiskalnika. Vir [4].
2.4 API
Aplikacijska programska oprema (API) je programski posrednik, ki omogoča komunikacijo med dvema ali več aplikacijami. Na API lahko gledamo kot na programski vmesnik, ki definira, kako poteka interakcija med večimi pro- gramskimi posredniki. Definira, kakšne klice lahko izvede aplikacija, kako jih naredi, kakšen format mora biti uporabljen, kako poteka izmenjava podat- kov itd. API-ji so lahko prilagojeni za specifične komponente ali pa so na- črtovani po industrijskih standardih, ki omogočajo množično uporabo večih sistemov [1]. Za lažjo predstavo delovanja API-ja si oglejmo naslednji primer [Slika 2.2]. Ko uporabljate aplikacijo na mobilnem telefonu, se aplikacija po- veže s spletom in pošlje podatke na strežnik. Strežnik nato pridobi podatke, jih interpretira, izvede potrebne akcije in jih pošlje nazaj na telefon. Apli- kacija na telefonu nato interpretira podatke in jih predstavi v berljivi obliki.
Za objasnitev zgornjega primera si oglejmo primer iz vsakdanjega življenja.
Predstavljajmo si, da sedimo v restavraciji in imamo pred sabo meni. V
8 Gal Lindič
Slika 2.2: Primer delovanja API-ja.
tem primeru je kuhinja sistem, ki pripravi naročilo. Kar manjka, je ključna povezava, preko katere lahko komuniciramo s kuhinjo. Tukaj pride do potrebe po natakarju oziroma API-ju. Natakar je samo vmesni člen, ki skrbi za prenos naročila do kuhinje in nato prenos hrane nazaj do nas.
2.5 XML
Je univerzalni jezik, ki se uporablja za shranjevanje informacij in podatkov.
Postaja osnova za RIP, saj zagotavlja univerzalen prenos podatkov in podpira vse vrste poslovnih procesov. Jezik sam ne naredi ničesar, samo vsebuje podatke, ki jih lahko pošljemo, prejmemo, arhiviramo ali pa prikažemo [11].
Sestavljen je iz:
• elementov, ki imajo začetno (<element>) in končno značko (</ele- ment>). XML-standard ne vsebuje vnaprej določenih značk, lahko jih poljubno poimenujemo, med njimi pa lahko podamo poljubno vsebino;
• atributov, ki jih podamo določenim elementom. Ti atributi morajo biti v narekovajih (atribut="...") in dodatno opišejo posamezne elemente.
Diplomska naloga 9 XML-dokument vedno vsebuje korenski element, ostali elementi znotraj tega pa so navadno hierarhično strukturirani. Navadno imajo dokumenti v prvi vrstici deklaracijo XML-dokumenta, ki pove, za katero verzijo XML-ja gre.
2.6 SOAP
SOAP je komunikacijski protokol, ustvarjen leta 1998. Dandanes se veči- noma uporablja kot vmesni člen pri spletnih storitvah (API) ali pa za prenos podatkov preko HTTP/HTTPS-protokola. Za razliko od ostalih komuni- kacijskih protokolov SOAP podpira samo XML-format, sledi pa določenim standardom izdelave sporočila in kriptiranja, zaradi česar je ta protokol tudi varnejši. Ena glavnih lastnosti SOAP API-ja je, da skoraj vedno uporablja WSDL-dokument [Sekcija 2.7], ki ima opisane smernice, kako komunicirati s spletno storitvijo [8]. Preden se je začel SOAP uporabljati, je veliko sple- tnih storitev uporabljalo RPC-način komunikacije [9]. To je bil najenostav- nejši način komunikacije, vendar je imel veliko omejitev. Predpostavimo, da imamo strežnik, ki gosti spletno storitev, ki ponuja dve funkciji:
• PridobiZaposlene - pridobi podatke o vseh zaposlenih osebah.
• NastaviZasposlene - nastavi podatke o zaposlenih osebah.
V tipičnem RPC-načinu komunikacije bi klient klical eno od funkcij v zahtevi in zraven poslal potrebne parametre na strežnik, strežnik bi mu pa odgovoril.
Spodnji model oblike komunikacije [Slike 2.3] ima nekaj resnih omejitev:
Slika 2.3: Primer RPC-komunikacije s spletno storitvijo. Vir: [9].
10 Gal Lindič
• Ni jezikovno neodvisna - storitev na strežniku je spisana v določenem programskem jeziku in klici na strežnik s strani klienta bi morali biti narejeni v enakem jeziku.
• Ni standardni protokol - ko je ustvarjen klic na storitev, se ta ne izvede preko standardnega protokola (HTTP), kar predstavlja problem, saj so skoraj vse komunikacije preko spleta izvedene preko njega.
• Požarni zid - ker RPC ni standardni protokol, se morajo ob klicu odpreti nova vrata za komunikacijo s strežnikom. Navadno so požarni zidi blokirali takšno vrsto prometa.
Za obhod zgoraj navedenih omejitev uporablja SOAP spodaj naveden model oblike komunikacije [Slika 2.4].
Slika 2.4: Primer SOAP-komunikacije s spletno storitvijo. Vir: [9].
1. Klient pretvori klic v SOAP-sporočilo in ga pošlje na strežnik preko HTTP-protokola. Ta proces enkapsulacije podatkov v SOAP-sporočilo se imenuje Marshalling.
2. Strežnik dekapsulira sporočilo in glede na zahtevo odgovori klientu na- zaj v obliki SOAP-sporočila. Ta proces dekapsulacije zahteve klienta se imenuje Demarshalling.
2.7 WSDL
WSDL je standardni format za opis spletne storitve [10]. Večinoma se upo- rablja v kombinaciji s SOAP-storitvijo in XML-shemo. Klient, ki se poveže
Diplomska naloga 11 na spletno storitev, lahko prebere WSDL-dokument in določi, katere funkci- onalnosti omogoča storitev. Klient lahko nato uporabi SOAP, da kliče eno od funkcionalnosti, navedenih v WSDL-dokumentu [Slika 2.5].
Slika 2.5: Primer SOAP-komunikacije z uporabo WSDL-ja.
12 Gal Lindič
Poglavje 3
ePoslovanje
Elektronsko poslovanje (ePoslovanje) se osredotoča na digitalizacijo poslov- nanja z izmenjavo informacij med poslovnimi partnerji. Torej ePoslovanje ni nič drugega kot izvajanje poslovnih transakcij s pomočjo računalniških sistemov in omrežij. Seveda pa implementacija ni tako preprosta. Potrebno je poznati novejše trende razvoja, poznati delovanje samega koncepta ter poznati ekonomiko in finance. Takšno obliko poslovanja lahko zasledimo v bančništvu, zavarovalništvu, spletnih trgovinah, tržništvu itd.
Povzamemo lahko, da je informacijski sistem najpomembnejši dejavnik po- slovanja. V ekonomiji pomen informatike neprestano narašča, informacijski sistemi pa so eden od najpomembnejših faktorjev poslovanja v podjetjih [16].
ePoslovanje je širši pojem, ki zajema več oblik poslovanja. Sem štejemo eRa- čune, eDobavnice, eNaročilnice in več splošnih oblik poslovanja, ki zahtevajo elektronska omrežja. V okviru diplomskega dela smo razvijali avtomatizacijo za eRačunsko obliko ePoslovanja.
13
14 Gal Lindič
3.1 Razvoj ePoslovanja
Začetke elektronskega poslovanja je povzročil razvoj računalniških omrežij, interneta in standardov za računalniško izmenjavo podatkov, katerih začetki segajo v leto 1968. Računalniška tehnologija je bila na začetku namenjena samo računalniškim strokovnjakom in znanstvenikom, z leti pa je postajala vse bolj uporabna, sčasoma pa nepogrešljiva tudi za preprostega človeka. Ta- krat se še ni vedelo, s kakšno hitrostjo bo razvoj informacijske tehnologije in telekomunikacij vplival na poslovanje. V sedemdesetih letih se je pojavil prvi elektronski proces finančnih prenosov med bankami preko varnih omrežij, kar je spremenilo način poslovanja finančnega trga. V osemdesetih letih je zami- sel elektronskega poslovanja napredovala in je bila nadomestitev papirnatih poslovnih listin (naročila, računi itd.), omrežne storitve pa so še vedno bile premalo razširjene med navadnimi uporabniki. Največji razvoj je elektronsko poslovanje doživelo po letu 1996 [Slika 3.1], ko je postala tehnologija interneta javno dostopna. S prihodom svetovnega spleta se je poslovanje pocenilo, ta oblika poslovanja pa je bila omogočena tudi majhnim podjetjem, ki so lahko uspešno tekmovala z velikimi mednarodnimi podjetji. Internet je znižal stro- ške komunikacije, odprl je nove načine poslovanja, povečal učinkovitost in zagotovil, da je ekonomija postala globalna [18].
Da je sploh prišlo do elektronskega poslovanja, smo poleg omrežij potrebovali še standard za računalniško izmenjavo podatkov (RIP). Na začetku je omo- gočanje RIP zahtevalo veliko finančnih sredstev, zato je bilo dostopno samo večjim podjetjem. RIP je postala osnova za hitro in učinkovito izmenjavo informacij med informacijskimi sistemi. Z uporabo standardnih sporočil in dokumentov pa omogoča skupen jezik med informacijskimi sistemi različnih organizacij kjerkoli po svetu, kar omogoča komunikacijo med katerimkoli kup- cem in dobaviteljem na svetu [7]. Definiran je kot P2P-izmenjava poslovnih informacij v standardnem in strukturiranem formatu. Organizacije se vedno bolj nagibajo k elektronski izmenjavi podatkov, da izboljšajo učinkovitost poslovnega procesa in komunikacije z uporabo elektronskega poslovanja [6].
Diplomska naloga 15
Slika 3.1: Rast uporabe ePoslovanja. Vir: [13].
3.2 Vrste elektronskega poslovanja
Pri elektronskem poslovanju poznamo tri glavne skupine udeležencev - pod- jetja, potrošniki in državna uprava. Glede na izmenjavo podatkov med ude- leženci ločimo naslednje (osnovne) vrste poslovanja [17]:
• B2B (Business to Bussines) - med podjetji,
• B2C (Business to Customer) - med podjetji in potrošniki,
• B2G (Business to Government) - med podjetji in državno upravo.
B2B-poslovanje deluje na principu prodaje izdelkov ali storitev drugim pod- jetjem, ne pa neposredno potrošnikom. Ena izmed glavnih prednosti so nizki stroški poslovanja in manjša možnost napak, saj se na vsakem koraku izo- gibamo prenosu dokumentov iz elektronske v papirnato obliko, kar je pro- ces, ki vključuje napake, je časovno potraten in povzroča dodaten strošek [19]. B2C-model poslovanja deluje tako, da potrošnik kupi izdelek oziroma storitev preko internetnega medija od podjetja. Takšna oblika poslovanja
16 Gal Lindič zajema veliko hitro razvijajočih se novih področji, ki v večini temeljijo na uporabi interneta [14]. Primer B2C-oblike poslovanja je elektronsko bančni- štvo za fizične osebe, spletne trgovine itd. [15]. Pri B2G gre za interakcije med državno upravo in gospodarskimi podjetji. Za to vrsto ePoslovanja so najznačilnejše aplikacije, ki omogočajo prijavo in plačevanje DDV-ja, sodelo- vanje pri javnih naročilih ipd. [20]. Pri vseh treh oblikah ePoslovanja lahko najdemo eRačune, v okviru diplomskega dela smo se pa poslužili B2B-oblike.
3.3 eDokument
Dokument, ki je bil izdelan v elektronski obliki, se imenuje elektronski doku- ment, skrajšano eDokument. V sodobnem poslovanju se vedno bolj upora- bljajo elektronski dokumenti, omogočajo pa enako uporabnost in berljivost kot papirni dokumenti. Ker spada izmenjava eDokumentov v elektronsko po- slovanje, se uporablja RIP-standard za izmenjavo podatkov. S takšno obliko izmenjave podatkov si zagotovimo, da izmenjava ne poteka preko nezaneslji- vih medijev, ki prinašajo dodaten strošek (tiskanje, pošta itd.).
Prednosti uporabe elektronskih dokumentov:
• lahko jih preglejuje in ureja več oseb na več napravah hkrati,
• omogočajo avtomatično obdelavo podatkov.
Slabosti uporabe elektronskih dokumentov:
• oteženo zagotavljanje avtentičnosti (zaradi množičnega spreminjanja in reproduciranja),
• mnogo formatov pisanja dokumentov (prejemnik morda ne bo mogel prikazati vsebine dokumenta).
Predstavljeni slabosti se da relativno lahko rešiti. Zagotavljanje avtentičnosti lahko rešimo z uporabo digitalnega podpisa, ki ni več veljaven, če se vsebina
Diplomska naloga 17 dokumenta spremeni. Ker obstaja mnogo formatov dokumentov, je rešitev tega standardizacija oblike eDokumentov, tipično z uporabo PDF- ali pa XML-formata.
3.4 eRačun
eRačun je elektronska oblika običajnega papirnega računa, ki je poslana po elektronski poti. Je račun, katerega definira standard, in je skladen z zakon- skimi predpisi. Enakovredno zamenjuje račun v papirni obliki, ki je izsta- vljen za opravljeno storitev ali izstavljeno blago. Potrebuje točno predpisan standard, ki opisuje struktro dokumenta in pomen posameznih vsebin. Vsak eRačun mora biti izdan po predpisih, ki jih opredeljuje Zakon o elektronskem poslovanju in elektronskem podpisu (ZEPEP). Po zakonu je predpisano, da je elektronska oblika enakovredna pisni, če so podatki v elektronski obliki ustrezni in primerni za kasnejšo uporabo. Če dokument izpolnjuje pogoje za priznavanje elektronske oblike, je naslednje relevantno vprašanje dokazova- nje pristnosti pospisnika. Pri elektronskem poslovanju se to naredi z uporabo elektronskega podpisa, ki ga ureja omenjeni ZEPEP [12].
Slika 3.2: Primer XML-dokumenta eRačuna.
Poleg XML-oblike zapisa podatkov računa [Slika 3.2] se zahteva še priložena
18 Gal Lindič PDF-vizualizacija, predvsem zaradi lažje berljivosti podatkov. Ta dva doku- menta na koncu skupaj tvorita eRačun.
3.4.1 Prednosti in slabosti
Prehod iz tradicionalnega poslovanja ima veliko prednosti. Te so vidne predvsem pri zmanjševanju stroškov tiskanja, hitrosti in enostavni uporabi.
Glavna izmed prednosti je predvsem cena. Namesto da se porablja papir, kartuše in poštnina, se vse izvede elektronsko. S tem prihranimo čas, poveča pa se tudi ekološka učinkovitost podjetja. Z uvedbo eRačunov lahko podjetje doseže [21]:
• prednost pred konkurenco,
• znižanje stroškov (stroški tiskanja, poštnih storitev, pisarniškega mate- riala itd.),
• poslovne priložnosti, ki jih pridobi, če ima uvedene eRačune,
• učinkovitejše poslovanje.
Slabosti eRačunov se kažejo predvsem pri starejših zaposlenih, saj se lahko pojavi nezaupljivost do tehnologije. Ker so to elektronski dokumenti, se lahko uničijo, zato je eden izmed pomembnejših dejavnikov uvedba e-arhiva.
Slabost je tudi, če podjetje nima urejenega procesa od prejema računa do likvidacije ter hrambe, saj v tem primeru nima urejene elektronske likvidacije računa in mora vsak prejeti račun še natisniti na papir. Ena od slabosti je tudi, da nekatera majhna in srednje velika podjetja nimajo stredstev za uvedbo eRačunov.
3.5 Glavni procesi poslovanja z eRačuni
Vsak proces ePoslovanja sledi točno določenemu postopku, ki omogoča lažjo izmenjavo, skladnost z zakonodajo, varnost in verodostojnost. Priporočeno
Diplomska naloga 19 je, da so izpolnjeni vsi koraki [Slika 3.3], da bo eRačun skladen s predpisi in standardom, ki ga določa eSLOG [5].
Slika 3.3: Avtomatiziran proces ePoslovanja z eRačuni. Vir: [5]
3.5.1 Kreiranje eDokumenta in elektronski podpis
eRačun ali kakšno drugo obliko eDokumenta lahko kreiramo v podprtih pro- gramskih rešitvah ali pa v namenskih orodjih, kot je npr. Excel. Kreiran eDokument je v XML-obliki, kateri mora obvezno biti digitalno podpisan, da je zagotovljena avtentičnost dokumenta. Zraven moram biti priložena tudi PDF-vizualizacija za lažji pregled vsebine dokumenta. Vizualizacija se lahko pripravi znotraj rešitve za kreiranje eDokumenta ali pa se uporabijo razna spletna orodja. Za preverjanje ustreznosti XML-strukture (verifikacija dokumenta) se uporablja eSLOG-standard poslovnih pravil.
3.5.2 Pošiljanje in izmenjava eDokumenta
Pred pošiljanjem je potrebno eDokument pripraviti na izvoz. Opremi se ga z ovojnico, ki vsebuje podatke naslavljanja. Podobno kot pri kuvertah
20 Gal Lindič s papirnimi dokumenti. Kreiranje ovojnice in izmenjavo običajno izvajajo ponudniki ePoti/eIzmenjave, ki zagotavljajo zanesljivost, verodostojnost in varno dostavo (enako kot zagotavlja Pošta pri izmenjavi papirnatih doku- mentov). Odsvetovano je, da se eDokumenti izmenjavajo preko e-pošte, saj to ni najbolj varno in zanesljivo. Torej, če uporabljamo ponudnike ePoti, se eDokument pošlje preko njihove storitve za izmenjavo, do ustreznega preje- mnika.
3.5.3 Prejem in obdelava eDokumenta
Prejemnik prejme eRačun ali kakšno drugo obliko eDokumenta preko svojega ponudnika ePoti na vnaprej dogovorjen način. Če je format prejetega doku- menta v obliki, ki je prejemnik ne podpira, ga mora konvertirati s posebnimi orodji. Čedalje več poslovnih informacijskih sistemov podpira poleg eRačuna tudi druge eDokumente, kot so eNaročila, eDobavnice itd. Podjetje izvede obdelavo dokumenta skladno s svojimi postopki.
3.5.4 Arhiviranje eDokumenta
Po zakonu je potrebno kopije izdanih in prejetih računov hraniti deset let po poteku leta, na katero se računi nanašajo. V primeru, da se račun na- naša na nepremičnine, ga je potrebno hraniti 20 let. Hranimo jih v eSLOG XML-obliki, zraven pa hranimo še vizualizacijo računa v PDF-obliki. Poleg samega računa se morajo hraniti tudi podatki, ki jamčijo prisotnost izvora in celovitost vsebine.
Poglavje 4 Analiza
Najprej smo analizirali pomanjkljivosti obstoječega sistema in razmišljali, kako jih lahko odpravimo. Ugotovili smo, da je sistem časovno potraten, neproduktiven, predvsem pa naporen. Na podlagi te analize smo postopoma začeli načrtovati nov proces izdaje eRačunov, pomagali pa smo si z uporabo preprostih diagramov poteka, ki prikazujejo, kako so razni moduli in elementi med seboj povezani. Ker je iz samega diagrama poteka težko predvideti, kako bo oseba uporabljala sistem in kakšne možnosti ima, smo uporabili diagram primerov uporabe. Z njim smo ugotovili, kako se bo uporabnik srečal z novim sistemom, kaj mu sistem dopušča, zraven pa kako deluje celoten sis- tem. Glavni cilj novega sistema je čim večja avtomatizacija, ki bi uporabniku zmanjšala porabljen čas pri izdaji eRačunov, zraven pa bi povečala produk- tivnost. Poleg tega smo tudi želeli, da ni preveč zapleten, saj bi s tem oseba porabila dodaten čas.
4.1 Podatkovni model
Pri dodajanju polj podatkovnima modeloma smo morali biti še posebej pre- vidni, saj nismo želeli, da pride do redundance podatkov oziroma kakšnega drugega problema. Ker želimo, da je ERP-obrazec povezan z novim sistemom izdaje eRačunov, smo morali spremeniti nekaj starih tabel ERP-obrazcev, saj
21
22 Gal Lindič niso zajemale vseh potrebnih podatkov. Nekaj sprememb smo kasneje tudi prilagajali, saj smo pri načrtovanju procesa nadgrajevali modele glede na po- trebe. Uredili smo tabelo - Partnerji [Tabela 4.1]. Ker želimo, da se računi izdajo partnerjem podjetja preko različnih protokolov izmenjave, smo dodali polje, ki shranjuje, preko katerega protokola se bo račun izdal posameznemu partnerju. Ker imamo na voljo protokole, ki zahtevajo e-naslov, smo dodali še eno polje, ki ga shrani v primeru, da se za partnerja uporabi protokol, ki ga zahteva.
Ime polja Opis Primer vnosa
PaEIzmenjavaProtokol Protokol, preko kate- rega bo potekala izme- njava eDokumenta za partnerja
Email, BizBox, UJP
PaEIzmenjavaENaslov E-naslov partnerja v primeru, da ga proto- kol izmenjave zahteva
prejemanje@partner.si
Tabela 4.1: Dodana polja tabeli partnerjev
4.2 Diagram primerov uporabe
UML oziroma Poenoteni jezik modeliranja je splošni, razvojni jezik za mode- liranje na področju programskega inženiringa, katerega namen je zagotoviti standardni način vizualizacije zasnove sistema. Za potrebe načrtovanja izdaje eRačunov smo uporabili diagram primerov uporabe. Najprej smo zasnovali diagram za ERP-sistem, kjer so opisane funkcionalnosti, ki jih uporabnik lahko uporablja v zvezi z eRačuni [Slika 4.1].
ERP ponuja splošne možnosti pregleda posameznih modelov, kot tudi ureja- nje, brisanje in dodajanje (CRUD). Za te funkcionalnosti se mora uporabnik
Diplomska naloga 23
Slika 4.1: Primer diagrama primerov uporabe ERP-sistema za potrebe izdaje eRačuna.
avtenticirati, drugače so mu zavrnjene. Za lažje pregledovanje si lahko po- maga z iskanjem po najnovejših vnosih ali pa z vnosom parametrov (npr.
ID-fakture). Uporabnik lahko posamezno fakturo izvozi, kar vključuje gene- riranje PDF-ja in tiskanje le-tega preko EBA-tiskalnika (več o tem kasneje).
Izdelali smo še en diagram primerov uporabe, in sicer za funkcionalnosti, ki jih ponuja dokumentni sistem EBA pri izdaji eRačunov [Slika 4.2].
Vsi uporabniki EBA-sistema imajo svojo virtualno pisarno, kjer se naha- jajo vsi njihovi eDokumenti. Seveda se mora uporabnik predhodno avten- ticirati, sicer mu je dostop zavrnjen. V pisarni lahko išče med dokumenti, kronološko, z uporabo parametrov ali pa po stanju, v katerem so trenutno
24 Gal Lindič
Slika 4.2: Primer diagrama primerov uporabe EBA-sistema za potrebe izdaje eRačuna.
dokumenti (Odpremljen, Uvožen, Pripravljen ...). V pisarni si lahko ogle- damo posamezni dokument, ki vsebuje PDF-vizualizacijo, podatke o vsebini, prejemniku/pošiljatelju, protokol, preko katerega bo izmenjan, in možnost odpreme dokumenta, da lahko uporabnik po želji izda eRačun prejemniku.
Poglavje 5
Proces izdaje eRačunov
5.1 Načrtovanje
Ko smo z ekipo načrtovali nov proces izdaje, smo imeli v mislih predvsem robustnost, saj ne želimo, da uporabnik naleti na napako, kar bi pomenilo, da se eRačun ni izdal oziroma se ni pravilno izdal ali pa se je izdal v nepravilni obliki. Seveda je potrebno nekje začeti in nato nadgrajevati stvari tekom dela, saj vsega ni mogoče predvideti. Ključna pri vsakem dobrem načrtovanju programskih rešitev je skalabilnost, na kar smo bili pozorni tudi sami.
5.2 Zasnovani procesi
Pri zasnovi in implementaciji modela izdaje računov je prišlo do več nadgra- denj, predvsem zaradi slabosti oziroma pomanjkljivosti predhodnih modelov.
Vse modele smo predhodno načrtovali z uporabo diagramov, po implemen- taciji pa smo naredili analizo in ugotavljali, ali je potrebna nadgradnja ali je rešitev v skladu z zastavljenimi cilji.
5.2.1 Obstoječ sistem za izdajo eRačunov
Obstoječ sistem podjetja za izdajo eRačunov [Poglavje 1.2] se poslužuje pre- prostega modela [Slika 5.1]. Zaposlena oseba najprej vpiše podatke o računu
25
26 Gal Lindič v ERP, iz katerega se podatki shranijo v bazo.
Slika 5.1: Obstoječ sistem za izdajo eRačunov.
Naslednja stvar, ki jo mora storiti, je, da vnese iste podatke v Excelovo pre- glednico, katera ima spisan makro v Visual Basic programskem jeziku, ki na podlagi vnešenih podatkov zgradi veljaven XML-dokument računa. Makro tudi upošteva pravila strukture eRačuna, katere zahteva standard eSLOG.
Naslednja stvar, ki jo mora opraviti zaposlena oseba, je, da iz ERP-a izvozi PDF-vizualizacijo obravnavanega računa. XML- in PDF-dokument sedaj tvorita veljaven eRačun. Model je preprost, zaradi česar ima več slabosti:
• neprilagodljivost na spremembe strukture eRačuna,
• težko berljiva koda makrojev, kjer je vse "trdo kodirano"(vse značke so statično definirane),
• neproduktiven,
• časovno potraten.
Poleg zgoraj naštetih slabosti pa ima model tudi nekaj pomanjkljivosti. Ni avtomatiziran v celoti, saj mora oseba večkrat vpisovati identične podatke, prav tako pa ročno generirati PDF-vizualizacijo računa. Model tudi ne pod- pira izmenjave dokumentov, kar pomeni, da mora zaposlena oseba tudi ročno poslati eRačun.
Diplomska naloga 27
5.2.2 Prvotno zasnovan model
S slabostmi trenutnega modela [Slika 5.1] v mislih je bil zasnovan naprednješi model [Slika 5.2], ki je odpravil nekaj pomanjkljivosti in slabosti prejšnjega.
Slika 5.2: Prvotno zasnovan proces izdaje.
Hitro lahko opazimo, da pri tem modelu uporabnik ne zapravlja časa z dvoj- nim vnašanjem podatkov. Vnese podatke o računu v ERP, kjer se shranijo v bazo, nato pa lahko izvozi račun iz informacijskega sistema. Z izvozom se avtomatsko ustvari PDF-vizualizacija, ki se shrani na vnaprej določeno mesto, istočasno pa se zažene javanski program, ki prejme potrebne podatke o računu. eSLOG 2.0 ima točno določeno hierarhijo značk, ki mora biti veljavna za vsak generiran XML-dokument. Na spletu smo sneli datoteko, ki opisuje hierarhijo posamezne značke, njen opis in ID, ki ji je dodeljen v eSLOG-standardu [Tabela 5.1]. Za nekatere vsebine eRačuna je potrebno ustvariti več značk, kjer predstavljajo posamezne značke vsebino, nekatere pa "fraze", ki morajo biti vsebovane. Podatki, ki jih prejme program, so v tekstovni obliki, formatirani so pa v slogu BT-x -> vsebina, ki je zahtevana za posamezen ID.
Glede na hierarhijo značk nato program zgradi drevesno strukturo, ki je ve- ljavna za opisan standard. Vsako vozlišče in list drevesa vsebuje ime značke, ID, vsebino (če je zahtevana) in atribute (če so navedeni). [Slika 5.3].
Ko je zgrajeno drevo za celoten račun, se naredi tako imenovani Preorder
28 Gal Lindič
ID BT eSlog 2.0 XML hierarhija značk
BT-1 Številka računa /Invoice/M_INVOIC/S_BGM/C_C106/D_1004 BT-2 Datum izdaje /Invoice/M_INVOIC/S_DTM/C_C507/D_2005=’137’
/Invoice/M_INVOIC/S_DTM/C_C507/D_2380
BT-3 Tip Računa /Invoice/M_INVOIC/S_BGM/C_C002/D_1001 Tabela 5.1: Primer pravil strukture in opisa posameznih značk.
Slika 5.3: Primer drevesne strukture za Tabelo 5.1.
obhod drevesa. Zanj je značilno, da gre najprej v globino vozlišč, dokler ne pride do lista, nato pa se vrača nazaj in zopet gre v globino [Slika 5.4]. Med obhodom se začnejo generirati XML-značke, ki imajo enako hierarhijo kot pa v drevesni strukturi. Po končanem obhodu je ustvarjena XML-datoteka, ki vsebuje podatke o računu.
Ker lahko pride pri ustvarjanju datoteke do napake, se pravilnost ustvar-
Diplomska naloga 29
Slika 5.4: Primer Preorder obhoda drevesne strukture.
jenega XML-dokumenta validira na podlagi XSD-datoteke, ki ima opisano pravilno strukturo. Če je validacija uspešna, se poleg PDF-datoteke shrani še XML in skupaj tvorita pravilen eRačun. Ta model je že naredil korak naprej napram prejšnjemu, ima pa še vedno dve slabosti:
• delno podpira posodobitve pravil strukture, saj jo moramo, v primeru nove, ročno sneti s spleta,
• v primeru nepravilne generacije XML-datoteke je potrebno iskati na- pake v kodi, kar zaustavi celoten proces izdaje.
Poleg zgoraj naštetih slabosti pa ima model še eno pomanjkljivost. Kakor prejšnji tudi ta model ne podpira izmenjave dokumentov, kar pomeni, da mora oseba ročno poslati eRačun.
5.2.3 Nadgradnja zasnovanega modela
Na podlagi slabosti predhodnega modela se je zasnoval nov [Slika 5.5] z upo- rabo EBA-dokumentnega sistema. Perftech Krmar je starejši informacijski sistem in ne ponuja integracije z EBA-programskim okoljem, kot jo ponujajo novejši sistemi. Zaradi tega je bilo potrebno povezavo med njima prilagoditi.
EBA ima na voljo navidezni tiskalnik, preko katerega lahko zajame doku- mente. Potrebno ga je bilo samo namestiti, nato pa se preko ERP-a generira
30 Gal Lindič PDF-račun in "natisne"preko navideznega tiskalnika. V EBA-programu je nameščen vtičnik, katerega smo sprogramirali za potrebe izdaje eRačunov.
Slika 5.5: Nadgradnja zasnovanega procesa izdaje.
Vtičnik [Slika 5.6] zajame PDF, ki je poslan preko tiskalnika, in iz njega izlu- šči številko računa. Naredi SQL-poizvedbo in iz podatkovne baze prejme po- datke o računu. EBA omogoča kreiranje poljubnih dokumentov, ki vsebujejo podatke v tekstovni obliki, PDF-vizualizacijo, podatke o prejemniku/pošiljatelju in protokol, preko katerega bo dokument poslan. Takšne vrste dokumenti so lahko večih tipov, v našem primeru je ta tip račun. Generiranje XML- datoteke eRačuna deluje na podobnem principu kot pri prejšnjem modelu [Slika 5.2]. EBA ima shranjeno interno tabelo, preko katere se podatki nato mapirajo v XML-značke, podobno kot pri [Tabela 5.1], vendar ima drugače poimenovane posamezne elemente. Preko vtičnika se ustvari prazen doku- ment, na katerega se dodajajo posamezne vsebine računa pod imeni, ki jih določa EBA. Ta tabela se tudi posodablja z vsako različico glede na trenuten standard eSLOG.
Poleg same vsebine se dokumentu priloži še zajet PDF, ki predstavlja vizua- lizacijo računa. Ker pa želimo dokument pošiljati, mu je potrebno nastaviti tudi podatke o prejemniku in pošiljatelju, kot tudi protokol, preko katerega bo nato izdan. EBA podpira več protokolov za izmenjavo podatkov, kot so
Diplomska naloga 31
Slika 5.6: Delovanje EBA-vtičnika.
Email, UJP, BizBox, Print in ostale, katerih pa podjetje ne bo uporabljalo.
Vsak protokol ima definirana svoja pravila in podatke (e-pošta pošiljate- lja/prejemnika, davčna številka, Swift koda itd.), ki morajo biti prisotni, da se izvrši izmenjava. Poseben protokol je BizBox, ki ga omogoča podjetje ZZI, ki je ponudnik ePoti/eIzmenjave (Poglavje 3.5.2). Platforma BizBox po- nuja širok nabor storitev in rešitev za brezpapirno poslovanje med partnerji.
Združuje nabor funkcij za izmenjavo vseh vrst dokumentov in uporabnikom omogoča digitalizacijo in avtomatizacijo poslovnih procesov za enostavnejše poslovanje z različnimi partnerji. Prednost tega protokola je, da se eRačun preko ponudnika ePoti (ZZI) pošlje v eNabiralnik prejemnika, ki pa je sin- hroniziran z EBA-okoljem. Tako zasnovan model je avtomatiziran tako, kot je bilo zaželjeno. NI nam treba skrbeti za nadgradnje eSLOG-standarda, saj za vse poskrbi EBA. Ima pa eno pomanjkljivost - kakor je model zasnovan, ne moramo vedeti, ali je prejemnik uporabnik storitev BizBox.
32 Gal Lindič
5.2.4 Nadgradnja modela z neodvisnim modulom
Za rešitev pomanjkljivosti zgoraj opisanega modela [Slika 5.5] smo zasnovali nov modul, ki deluje neodvisno od procesa izdaje računov [Slika 5.7]. Za delo- vanje uporablja zunanjo storitev, ki jo ponuja ustvarjalec platforme BizBox, podjetje ZZI. Ta API uporablja SOAP-obliko komunikacije (Poglavje 2.6), zraven pa WSDL za določitev endpointov oziroma končnih točk.
Slika 5.7: Nadgradnja modela izdaje eRačunov z neodvisnim modulom.
Preko te storitve smo lahko izvedeli, kateri poslovni partnerji so uporabniki platforme BizBox. Napisali smo PHP-skripto, ki iz baze prejme podatke o partnerjih, nato pa pošlje zahtevo na storitev, ta pa vrne, kateri partnerji uporabljajo njihovo platformo. Ti podatki se nato sprocesirajo in se upora- bljajočim partnerjem nastavi protokol izdaje v bazi na BizBox (Tabela 4.1).
Ta skripta se izvede enkrat dnevno preko CRON-del, zato lahko vsak dan na novo poizvemo, kateri izmed partnerjev postane uporabnik ZZI-platforme.
5.3 Predstavitev implementiranega procesa
Sedaj pa si oglejmo, kako izgleda interakcija z implementiranim procesom izdaje eRačunov. Če se sprehodimo po korakih, predstavljenih na Sliki 5.2, se vse začne z vnosom podatkov računa v ERP-sistem podjetja [Slika 5.8].
Obrazec je sedaj shranjen v internem sistemu podjetja in ga lahko izdamo partnerjem oz. drugim pravnim osebam. Ker ni direktne povezave ERP z
Diplomska naloga 33
Slika 5.8: Vnos podatkov računa v ERP-obrazec.
EBA-sistemom, moramo najprej zgenerirati PDF računa, ki ga nato nati- snemo preko navideznega tiskalnika EBA [Slika 5.9].
Slika 5.9: Tiskanje PDF-računa preko EBA-tiskalnika.
Če si ogledamo Sliko 5.5, lahko vidimo, kako deluje vtičnik v EBA-sistemu.
Ves čas posluša na vratih za tiskalnik in ker smo sprožili tiskanje PDF, bo ta dokument prejel in ga obdelal. Najprej bo dobil številko računa, nato pa se
34 Gal Lindič povezal na podatkovno bazo, kjer bo dobil podatke o računu, ki smo jih pred- hodno vnesli v sistem. Zgeneriral bo eDokument, mu priložil prejeti PDF, ga napolnil s podatki, nastavil pravilne protokole in pošiljatelja/prejemnika. Ob koncu, če je eDokument pravilno zgeneriral, se shrani v pisarno v EBA-okolju [Slika 5.10]. Račun lahko sedaj izdamo nastavljenemu prejemniku preko na- stavljenega protokola. Za primer imamo nastavljen SMTP-protokol, kjer se preko izdajatelja ePoti pošlje XML in PDF računa, nato pa pride v e-poštni nabiralnik naslovnika [Slika 5.11].
Slika 5.10: eDokument računa v EBA-pisarni.
Diplomska naloga 35
Slika 5.11: Izdan eRačun prejemniku preko SMTP-protokola.
36 Gal Lindič
Poglavje 6 Sklep
V okviru tega diplomskega dela smo se dobro spoznali z razvojnim okoljem EBA, kot tudi s samim konceptom ePoslovanja in eRačunov. Spoznali smo, da je trenuten standard eSLOG 2.0 dobro definiran, vendar je kompleksen (nejasno poimenovanje značke, kompleksna struktura). Implementacija pro- cesa izdaje eRačunov je potekala gladko in smo z njo tudi dosegli cilj, ki smo si ga zadali. Naredili smo konkretno analizo problema in se reševanja lotili po korakih. Prišli smo na več točk, kjer smo bili primorani stvar še nadgraditi, saj proces ni v celoti ustrezal pogojem, hkrati pa ni bil skalabi- len. Končni model je izpolnil vse zastavljene cilje, je skalabilen, robusten, ni kompleksen, hkrati pa je produktiven in je omogočil podjetju korak naprej v svetu elektronskega poslovanja.
6.1 Ideje za nadaljnji razvoj
V podjetju želijo, da bi se poslovna aplikacija razširila z možnostjo prejema- nja eRačunov in bi bil zasnovan posebej proces za to. S tem bi imeli pokrito celotno področje eRačunov, zaradi skalabilnosti trenutnega procesa izdaje bi se lahko usmerili še na ostale tipe eDokumentov - eNaročilnica, eDobavnica itd.
37
38 Gal Lindič
Literatura in viri
[1] What is an api. URL https://www.mulesoft.com/resources/api/
what-is-an-api.
[2] Eba dms, . URL https://ebadms.com.
[3] Eba integracija, . URL https://ebadms.com/help/integracija.htm. [4] Eba tiskalnik, . URL https://www.eba.si/old/index.php?option=
com_content&view=article&id=70&Itemid=77.
[5] eposlovanje. URL https://www.epos.si/eposlovanje.
[6] What is edi (electronic data interchange), . URL https://datatrans- inc.com/what-is-edi/.
[7] Kako deluje elektronsko poslovanje, . URLhttp://www.panteongroup.
si/elektronsko-poslovanje/kako-deluje.aspx.
[8] Soap - simple object access protocol, . URL https:
//searchapparchitecture.techtarget.com/definition/SOAP- Simple-Object-Access-Protocol.
[9] What is soap protocol, . URL https://www.guru99.com/soap- simple-object-access-protocol.html.
[10] What is wsdl. URL https://www.guru99.com/wsdl-web-services- description-language.html.
[11] Kaj je xml. URLhttps://www.w3schools.com/xml/xml_whatis.asp. 39
40 Gal Lindič [12] Zakon o elektronskem poslovanju in elektronskem podpisu. URL http:
//www.pisrs.si/Pis.web/pregledPredpisa?id=ZAKO1973.
[13] Jerman Blažič B. Elektronsko poslovanje na internetu. Gospodarski vestnik, 2001.
[14] Irwin Brown and Ruwanga Jayakody. B2c e-commerce success: A test and validation of a revised conceptual model. The Electronic Journal Information Systems Evaluation, 11(3):167–184, 2008.
[15] Miro Gradišar, Jurij Jaklič, and Tomaž Turk. Osnove poslovne infor- matike. page 143, 2005.
[16] Miro Gradišar, Jurij Jaklič, and Tomaž Turk. Osnove poslovne infor- matike. page 8, 2005.
[17] Miro Gradišar, Jurij Jaklič, and Tomaž Turk. Osnove poslovne infor- matike. page 140, 2005.
[18] Zdenko Potočar Janja Razgoršek. Elektronsko poslovanje. pages 12–13, 2009.
[19] David Lucking-Reiley and Daniel F Spulber. Business-to-business elec- tronic commerce. Journal of Economic Perspectives, 15(1):55–56, 2001.
[20] Franci Nahtigal. Elektronsko poslovanje. page 16, 2010.
[21] Mojca Osojnik, Ariana Grobelnik, Samo Grčman, Andreja Ivartnik- Kanduč, Zdenka Konda, Iztok Kunšek, Dušan Zupančič, Aleš Dobnikar, Aljoša Domjan, and Slavko in ostali Cimprič. Skrivnosti elektronskega poslovanja: priročnik za mala in srednja podjetja. Gospodarska zbornica Slovenije, 2002.
