lokalizirana podpora procesu izdaje e …ariba network: sourcing, procurement, & finance,...

Diplomsko delo visokošolskega strokovnega študija Informatika v organizaciji in managementu

LOKALIZIRANA PODPORA PROCESU IZDAJE E-RAČUNA V REPUBLIKI SLOVENIJI Z ERP

SISTEMOM SAP

Mentor: doc. dr. Borut Werber Kandidat: Slavko Ovčina

Kranj, september 2016

ZAHVALA Posebej se zahvaljujem mentorju doc. dr. Borutu Werberju za mentorstvo, strokovne nasvete in čas pri izdelavi diplomske naloge. Za pomoč in informacije se zahvaljujem vsem svojim sodelavcem iz podjetja S&T, d. d. in podjetju SAP, d. o. o. Zahvala velja moji celotni družini, ki mi je med pripravo diplomskega dela in celotnim študijem stala ob strani ter nudila podporo. Zahvaljujem se tudi lektorici Urški Jaušovec Kolar, ki je lektorirala mojo diplomsko nalogo.

POVZETEK

Cilj naloge je bil uspešno izdelati lokalizirano rešitev za podporo izdaji e-računov v Republiki Sloveniji za programsko opremo SAP ERP proizvajalca SAP AG. Namen je zagotoviti ustrezno okolje za vse uporabnike SAP ERP sistema v Republiki Sloveniji, ki bi omogočalo uvedbo e-poslovanja in pripomoglo k optimizaciji procesov in resursov. Za razvoj rešitve za pošiljanje e-računov iz sistema SAP ERP smo uporabili SAP-ovo razvojno okolje SAP Netweaver ABAP Workbench. Gre za razvojno okolje, ki omogoča izdelavo programov, poročil, integracije na druge sisteme itd. Rezultat naloge je standardizirana rešitev za izdajo e-računov iz sistema SAP ERP. Rešitev je koncipirana tako, da omogoča nadaljnji razvoj na področju e-poslovanja, saj omogoča integracijo na različne DMS sisteme in prilagajanje procesom posameznih uporabnikov SAP ERP sistema.

KLJUČNE BESEDE: – SAP ERP, – e-račun, – SAP Netweaver ABAP Workbench, – e-poslovanje.

ABSTRACT The goal of the thesis was to successfully create a localized solution for support of issuing e-invoices in the Republic of Slovenia for SAP ERP software of the SAP AG manufacturer. The purpose is to provide a suitable environment for all users of the SAP ERP system in the Republic of Slovenia, which would allow the introduction of e-business and contribute to the optimization of the processes and resources. For the development of solution for sending e-invoices from the SAP ERP system, we used the SAP´s development environment SAP NetWeaver ABAP Workbench. This is a development environment that enables production of programs, reports, integration to other systems etc. The result of the thesis is a standardized solution for issuing e-invoices from the SAP ERP system. The solution is conceived so as to allow further development in the field of e-business, since it enables the integration of the different DMS systems and the adaptation to the process of individual users of the SAP ERP system.

KEY WORDS:

- SAP ERP, - E-invoices, - SAP Netweaver ABAP Workbench, - E-business.

KAZALO 1 UVOD ................................................................................................................. 1

1.1 PREDSTAVITEV PROBLEMA .......................................................................... 1 1.2 PREDSTAVITEV OKOLJA .............................................................................. 1 1.3 PREDPOSTAVKE IN OMEJITVE ...................................................................... 4 1.4 METODE DELA ............................................................................................. 5

2 OSNOVE ............................................................................................................. 8 2.1 SAP ERP, modul Prodaja in DISTRIBUCIJA .................................................. 8 2.2 SAP TEHNOLOŠKA PLATFORMA »sap netweaver« ....................................... 9 2.3 PRAVNE PODLAGE IN REGULATIVE, KI UREJAJO POSLOVANJE Z E-RAČUNI14

3 OBSTOJEČE STANJE ......................................................................................... 18 3.1 POSNETEK STANJA .................................................................................... 18 3.2 KRITIČNA ANALIZA .................................................................................... 22

4 PRENOVA ......................................................................................................... 23 4.1 EDOCUMENT FRAMEWORK ........................................................................ 23 4.2 RAZVOJ UPORABNIŠKIH IZHODOV IN BADI ................................................ 27

5 ZAKLJUČKI ....................................................................................................... 36 5.1 OCENA UČINKOV ....................................................................................... 36 5.2 POGOJI ZA UVEDBO .................................................................................. 38 5.3 MOŽNOSTI NADALJNjEGA RAZVOJA .......................................................... 39 LITERATURA IN VIRI ............................................................................................ 40 KAZALO SLIK ....................................................................................................... 40 KAZALO TABEL .................................................................................................... 41 POJMOVNIK ......................................................................................................... 41 PRILOGE .............................................................................................................. 42

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Slavko Ovčina: Lokalizirana podpora procesu izdaje e-računa v Republiki Sloveniji z ERP sistemom SAP stran 1

1 UVOD 1.1 PREDSTAVITEV PROBLEMA Digitalizacija se zelo hitro razvija in narekuje številne spremembe in novosti v vsakodnevnem življenju posameznikov in družb. Temu trendu so še posebej izpostavljena podjetja, ki ponujajo rešitve na področju informacijskih tehnologij. Eno izmed takih podjetij je SAP AG, ki je ponudnik poslovno-informacijskega sistema, ki ima trenutno največji tržni delež med sistemi ERP na svetu. Na drugi strani naša država z zavedanjem o pomembnosti digitalizacije z vzpostavitvijo regulativ in sprejemanjem potrebne zakonodaje poskuša vplivati na uvajanje digitalizacije tam, kjer je to mogoče in predvsem optimalno. Ena izmed takih akcij je sprejetje regulative, s katero je uvedla obvezno poslovanje z e-računi z vsemi proračunskimi uporabniki. Z drugimi besedami, kdorkoli posluje z državnimi skladi, ministrstvi in podobno, mora za svoje storitve oddati račun v e-obliki. Zelo pogumno in zelo zrelo. Menimo, da je s tem Slovenijo premaknila krepko naprej v razumevanju e-družbe in prihodnosti. Ko podjetja in posamezniki dobijo možnost elektronskega poslovanja z državo, prispevamo dodaten drobec k razumevanju informacijske družbe in pomembnosti digitalizacije. SAP AG je, podobno kot mnogi drugi ponudniki poslovno-informacijskih sistemov, z veseljem sprejel ponujeno priložnost in aktiviral projekt za nadgradnjo svoje rešitve, ki bi uporabniku prijazno in procesno smiselno v celoti podprla poslovanje na področju izdaje e-računov v Republiki Sloveniji. Zaradi omejenih lastnih virov in pomanjkanja znanja na ravni lokalne regulative in zakonodaje so aktivirali podjetje S&T Slovenija, v katerem sem zaposlen, in ki ima bogato zgodovino svetovanja in razvoja poslovno-informacijskih rešitev, katerih proizvajalec je SAP AG. Poleg tega smo že pred leti zagnali pobudo, ki je vključevala razvoj na področju zagotovitve elektronskega poslovanja za uporabnike rešitve SAP ERP. Znotraj te pobude smo razvili tudi lastno rešitev za zagotovitev funkcionalnosti pošiljanja e-računov. To je bil tudi pomemben element, ki je vplival na odločitev, da SAP AG k sodelovanju pri svojem projektu povabi nas. Projekt je predvideval, da na podlagi standardnega okolja SAP ERP, znotraj modula SD (Prodaja), razvijemo dodatek, ki bi poleg komunikacije z UJP omogočal izvedbo celotnega procesa upravljanja z izdanimi e-računi v obliki e-SLOGA 1.6.

1.2 PREDSTAVITEV OKOLJA Okolje, kjer se je izvajal projekt, nam je bilo znano, ker smo v preteklosti že nekajkrat sodelovali pri razvoju lokalnih rešitev za Republiko Slovenijo za SAP AG. SAP AG je vodilno svetovno podjetje na področju poslovno-informacijskih sistemov po višini prihodkov iz tega segmenta. Sicer pa je SAP AG tretje največje neodvisno podjetje, ki nudi aplikacijske rešitve. Podjetje SAP AG je leta 1972 ustanovilo pet podjetnikov, ki so imeli vizijo za poslovni potencial in tehnologijo. Začenši z eno stranko z nekaj zaposlenimi je SAP



AG začel pot, s katero ni le preoblikoval informacijske tehnologije, ampak je za vedno spremenil način poslovanja podjetij. Nekaj ključnih podatkov o podjetju SAP AG:

obstoj 44 let,

približno 320.000 strank,

poslovanje podjetja se izvaja v 190 državah,

trenutno zaposlujejo približno 79.960 strokovnjakov v približno 130 državah,

podjetje ima več kot 100 inovacijskih centrov,

12.100 SAP certificiranih partnerskih podjetij globalno,

letni prihodki so v letu 2015 znašali približno 21 bilijonov €,

njihove oblačne rešitve imajo že 110 milijonov naročnikov.

Kot zanimivost velja omeniti, da gre približno 87 % vseh svetovnih transakcij danes tako ali drugače skozi SAP-ove sisteme. SAP AG je prodajno in podporno organiziran regijsko, in sicer:

Amerika,

Evropa,

Srednji vzhod in Afrika,

Azija in Pacifik. Število zaposlenih po funkcijskih področjih je prikazano na Sliki 1:

Slika 1: Število zaposlenih po funkcijskih področjih

PORTFELJ REŠITEV IN STORITEV Upravljanje s procesi:

Content and Collaboration,

Customer Relationship Management



Data Management,

Enterprise Management (ERP),

Financial Management,

Human Capital Management,

Product Lifecycle Management,

Supply Chain Management,

Supplier Relationship Management,

Technology Platform. Analitika, poročanje in načrtovanje:

Business Intelligence,

Predictive Analytics,

Enterprise Performance Management,

Governance, Risk, and Compliance. Aplikativne platforme in infrastrukturne rešitve:

Application Platform,

Content and Collaboration,

Interface Management,

Process Management and Integration. Obvladovanje podatkov:

Big Data on Hadoop,

Data Warehousing,

Database Management System,

Enterprise Information Management. IT-menedžment:

IT Infrastructure Management,

Application Lifecycle Management. Rešitve na področju varnosti:

Identity and Access Management,

Application and IT Infrastructure Security. Oblačne rešitve:

SAP SuccessFactors HR Solutions,

SAP S/4HANA Finance,

SAP Hybris Cloud for Customer,

SAP Hybris Cloud for Sales,

SAP Hybris Cloud for Service,

SAP Hybris Marketing,

SAP Hybris Commerce,

SAP Business ByDesign (ERP for Midsize Business),

SAP Business One Cloud (ERP for Small Business),

SAP BusinessObjects Cloud for Analytics,

SAP Jam Collaboration,

SAP Jam Communities,

Ariba Network: Sourcing, Procurement, & Finance,



Concur: Travel & Expense Management,

Fieldglass: Flexible Labor Management,

SAP HANA Cloud Platform,

SAP HANA Enterprise Cloud. VIZIJA Že več kot štiri desetletja SAP AG svojim strankam, velikim in malim podjetjem iz petindvajsetih industrij, omogoča, da svoje poslovanje vodijo bolje in učinkoviteje. Vizijo ustanoviteljev vsakodnevno udejanjajo z vsem, kar počnejo, ključno vodilo pri tem pa je nenehno inoviranje, da lahko svojim strankam ponudijo dodatne možnosti, s pomočjo katerih lahko dosegajo boljše poslovne rezultate. V vse kompleksnejšem svetu, katerega del smo, postaja preprostost vedno pomembnejša poslovna paradigma. Prav zato so se v SAP AG odločili za nov korak – strankam bodo pomagali, da bodo poslovale preprosteje. S svojim pristopom »RUN SIMPLE« poenostavljajo svojo tehnologijo in obvladujejo kompleksnost, da lahko njihove stranke uporabljajo njihove rešitve tako, kot jim najbolj ustreza, s tem pa poenostavljajo svoj posel in se uspešno spopadajo z izzivi na trgu. POSLANSTVO Verjamejo v izjemno sposobnost svojih zaposlenih. Verjamejo v odlično sodelovanje s partnerskim ekosistemom. Verjamejo v uspehe svojih strank. In verjamejo, da lahko s pomočjo nenehnega razvoja, ki so mu v SAP AG predani in predstavlja njihov poslovni DNK, pomembno prispevajo k izboljšanju poslovnih uspehov svojih strank, izboljšanju svetovnega gospodarstva in tudi življenja ljudi. SAP AG tako ostaja zvest svojemu poslanstvu, da bo s pomočjo inovativnih tehnologij podjetjem pomagal poslovati bolje, saj je uspeh njihovih strank tudi njihov uspeh in poslanstvo.

1.3 PREDPOSTAVKE IN OMEJITVE Predpostavke, ki so bile potrebne za uspešno rešitev problema:

zagotovljeno razvojno in testno okolje na SAP ERP (različica 6.0) na SAP AG,

nameščena najnovejša različica servisnega paketa, ki vključuje lokalizacijske popravke na razvojnem in testnem sistemu,

oddaljen dostop do razvojnega in testnega sistema,

dodeljene primerne avtorizacije za izvedbo razvojnih dejavnosti iz naslova projekta na razvojnem in testnem sistemu,

v primeru dela na lokaciji SAP AG zagotovljeno primerno delovno okolje z dostopom do interneta in razvojnega ter testnega sistema.

Omejitve:

prenašanje razvojnih transportov z razvojnega na testni sistem lahko izvaja zgolj pooblaščeno osebje iz razvojnega oddelka SAP AG,

časovna razlika med nami in delom razvojne ekipe SAP AG, ki je bila iz Indije,

jezik: določeni člani razvojne ekipe SAP AG niso dovolj dobro govorili angleško.



1.4 METODE DELA Za reševanje problema je bila uporabljena nekoliko prilagojena metodologija SAP ASAP. ASAP je SAP AG-ova metodologija vpeljave sistema ERP, zgrajena tako, da nas v naravnem toku pripelje skozi proces vpeljave sistema na vsa funkcionalna področja organizacije. Za potrebe rešitve tega problema smo uporabili nekoliko prilagojeno metodologijo ASAP. Struktura in koraki metodologije so ostali enaki, prilagojene so zgolj dejavnosti znotraj posameznih korakov. ASAP optimizira čas, kakovost in učinkovitost porabe vseh virov pri reševanju problema. Poleg hitrega in kakovostnega vodenja skozi korake nam ASAP predstavlja dobro in zdravo osnovo za spremembe in nadaljnje izboljšave rešitve v prihodnosti. Metodologija se torej ne ozira le po rešitvi trenutnega problema, ampak podpira dejavnosti znotraj celotnega življenjskega cikla rešitve. ASAP se je prvič pojavil na tržišču leta 1996 in od takrat so ga uporabili pri večini vseh vpeljav sistema ERP po vsem svetu. V ASAP–u so integrirane 3 ključne komponente, ki v medsebojnem delovanju podpirajo hitro in učinkovito implementacijo SAP sistema:

Metodologija ASAP je zasnovana na načelu zemljevida (“Roadmap“). Faze, dejavnosti in naloge si sledijo po točno določenem zaporedju, katerih izvajanje nas pripelje na cilj – rešitev problema. Ključne faze in aktivnosti po fazah so predstavljene na Sliki 2:

Slika 2: Metodologija SAP ASAP

Specifični ASAP pripomočki za podporo projektnemu vodenju, testiranju, spremljanju in odpravljanju problemov ter številna tehnična navodila in kontrolne liste.



SAP storitve, izobraževanje in tehnična podpora, kot npr. Hotline, EarlyWatch, Remote Upgrade itd. Ti produkti pomagajo pri standardizaciji in posledično k hitrejšemu izvajanju določenih nalog.

PRIPRAVA PROJEKTA Faza priprave projekta vključuje pripravo spremne dokumentacije in vse predpogoje, ki so potrebni za uspešno organizacijo in izvedbo projekta. Rezultate faze priprave projekta se predstavi vodstvu podjetja in vsem ostalim udeležencem projektne skupine na tako imenovanem zagonskem sestanku (Kick Off). Faza priprave projekta med drugimi vključuje sledeče najpomembnejše naloge:

pregled in revizijo strategije razvoja/uvajanja,

vzpostavitev delovnega okolja,

določitev organizacije projekta,

določitev postopkov in standardov projektnega vodenja,

določitev postopkov in standardov uvajanja/razvoja,

»Kickoff« projekt,

sestanek projektne skupine za standarde,

določitev tehničnih zahtev,

preskrbo strojnega in programskega okolja. PRIPRAVA POSLOVNEGA NAČRTA – BUSINESS BLUEPRINT Namen te faze je preverjanje skladnosti procesov podjetja s procesi SAP, ki zajema pregled standardnih funkcionalnosti ter dokumentiranje morebitnih odstopanj (GAP analiza). Poslovni načrt dokumentira zahteve poslovnih procesov organizacije. Na taki osnovi se doseže skupno razumevanje o tem, kako namerava organizacija voditi svoje poslovanje na SAP sistemu oziroma, kako se mora organizirati poslovni proces, da bi se lahko učinkovito uporabljalo SAP. Za potrebe našega problema smo v tej fazi za potrebe razumevanja regulative in procesa izvedli številne sestanke s SAP, GZS, nekaj večjimi podjetji, UJP itd. Nato smo pripravili tehnično arhitekturo rešitve in tehnično specifikacijo potrebnega dodatnega razvoja. REALIZACIJA V tej fazi se je rešitev razvila v skladu z zahtevami, ki so bile določene v fazi poslovnega načrta. Faza realizacije med drugimi vključuje sledeče najpomembnejše naloge:

začetno planiranje za podporo v produkciji,

osnovni (baseline) razvoj sistema in potrditev,

upravljanje sistema, vključno s plani testiranja, vzpostavitvijo okolja za kontrolo kvalitete (QA) in produkcijo ter funkcijami sistemskega administriranja,

razvoj vmesnikov,



razvoj dopolnitev,

končno konfiguracija in potrditev,

testiranje,

vzpostavitev konceptov avtorizacije,

izdelavo tehnične dokumentacije in dokumentacije za končne uporabnike ter izobraževanje.

KONČNE PRIPRAVE V tej fazi se pripravi vse za dejansko uvedbo sistema. Faza končne priprave med drugim vključuje sledeče najpomembnejše naloge:

pripravo in izvedbo izobraževanja končnih uporabnikov,

izboljšanje upravljanja sistema,

izboljšanje plana za prehod v živo in podpore v produkciji,

prehod v produkcijo,

izvedbo kontrole kvalitete. PREHOD V ŽIVO IN PODPORA V tej fazi se zagotovi podpora končnim uporabnikom pri njihovem delu in rešuje tekoča problematika. Faza prehoda v živo in podpore med drugim vključuje sledeče najpomembnejše naloge:

podporo produkciji,

dodatno izobraževanje,

izdelavo dolgoročnih planov razvoja,

revizijo projekta. Operativno delo se je izvajalo večinoma na lokaciji SAP Slovenija, d. o. o., v Ljubljani. Projektna skupina je bila sestavljena iz: S&T:

vsebinski svetovalec za modul Prodaja in distribucija (SD) v SAP ERP, ki je bil hkrati naš projektni vodja,

razvojnik.

SAP AG:

lokalna vsebinska svetovalka za lokalizacijo FI, ki je bila hkrati projektni vodja SAP AG,

razvojni oddelek, ki je vključeval arhitekta rešitve in tehničnega svetovalca, ki sta poskrbela, da je bila rešitev narejena v skladu z razvojnimi standardi SAP AG.



2 OSNOVE Za rešitev problema so bile potrebne 3 osnovne komponente:

sistem SAP ERP – modul SD,

SAP tehnološka platforma »SAP NetWeaver« – razvojno okolje SAP ERP,

pravne podlage in regulative, ki urejajo poslovanje z e-računi in definicija e-SLOGA.

Rešitev je bila narejena z razvojem dodatka na osnovi podatkov standardnega modula SAP ERP Prodaja in distribucija, ki ga bomo v nadaljevanju podrobneje opisali, in kjer se izvaja izdaja računov kupcem. Nadgradnjo smo lahko realizirali z orodjem »SAP ABAP Workbench«, kar je del SAP-ovega razvojnega okolja, kjer se uporablja SAP-ov lastni programski jezik ABAP. Za vsebinsko in tehnično definicijo e-SLOGA ter samo izmenjavo podatkov je bilo treba analizirati tri zakone, ki urejajo področja, povezana z našim problemom:

Zakon o elektronskem poslovanju in elektronskem podpisu (ZEPEP),

Zakon o varstvu dokumentarnega in arhivskega gradiva ter arhivih (ZVDAGA),

Zakon o davku na dodano vrednost (ZDDV).

2.1 SAP ERP, MODUL PRODAJA IN DISTRIBUCIJA SAP ERP SAP ERP je poslovno-informacijski sistem, katerega osnovo sestavljajo kompleksni integrirani moduli za računovodstvo, kontroling, planiranje in izvajanje proizvodnje, kontrolo kakovosti, prodajo, nabavo, materialno in skladiščno poslovanje, vzdrževanje in spremljanje projektov. Sistem SAP ERP presega omejitve tradicionalnih hierarhičnih in funkcijsko omejenih struktur. Vse aktivnosti uporabnikov so procesno organizirane. Prodaja in distribucija, materialno in skladiščno poslovanje, načrtovanje in izvajanje proizvodnje ter finančno računovodstvo in kontroling so poslovne funkcije, ki so integrirane v delovni tok poslovnih dogodkov prek oddelkov in funkcijskih področij. Zaposleni dobijo ustrezne informacije na svoje delovno mesto ob pravem času. SAP-ove rešitve ne poznajo niti organizacijskih niti geografskih omejitev. Sistem SAP ERP je odprt in podpira vse spremembe na organizacijskem in tehnološkem področju ter omogoča različno integracijo aplikativne programske opreme v notranje in zunanje okolje uporabnika. Informacijski sistem je zasnovan tako, da podpira večvalutno in večjezično poslovanje . Rešitev je lokalizirana, torej prilagojena zakonodaji in jeziku skoraj celega sveta. Osnovni moduli, ki so podprti v rešitvi SAP ERP, so:

upravljanje s kadri in plačami (SAP HRM),

proizvodnja in planiranje (SAP PP),

materialno poslovanje, nabava (SAP MM),

prodaja in distribucija (SAP SD),

projektni sistemi (SAP PS),



finance in kontroling (SAP FICO),

vzdrževanje (SAP PM),

obvladovanje kakovosti (SAP QM). MODUL PRODAJA IN DISTRIBUCIJA Za potrebe našega projekta je pomemben modul SD, ker se celoten proces priprave izhodnega e-računa izvaja v tem modulu. Glavni procesi v prodaji so predstavljeni na Sliki 3.

Slika 3: Poslovni procesi v prodaji

Integrirane poslovne funkcije, ki se izvajajo znotraj modula SD, so:

obdelava povpraševanja,

obdelava prodajnega naloga,

obdelava komisioniranja in dobave,

nadzor naročila in dobave iz logističnega informacijskega sistema (LIS),

obdelava računov,

plačilo stranke,

obdelava pritožb in vračila strankam.

2.2 SAP TEHNOLOŠKA PLATFORMA »SAP NETWEAVER«

SAP NetWeaver je arhitektura robustne, nadgradljive in odprte platforme, ki je osnova vseh SAP-ovih rešitev, in nudi celovito okolje za poslovne aplikacije. Je neodvisna od platforme (strojna oprema, baza podatkov in operacijski sistem) in se dobavlja kot integrirano okolje od osnovne platforme »SAP NetWeaver Application



Server«, orodij za integracijo procesov »SAP NetWeaver Process Integration« in upravljanja procesov »SAP Business Process Management«. Funkcionalnosti, kot so delovni tok, opozarjanje, upravljanje s sistemom itd., so vključene kot del dobave SAP NetWeaverja, kar pomeni, da je rešitev mogoče razširiti in integrirati s poslovnimi rešitvami zdaj ali v prihodnosti, ko se povečajo poslovanje in njegove informacijske potrebe. Platforma ima poenoten model metapodatkov, ki zajema celotno rešitev, od pridobivanja podatkov do skladiščenja podatkov, načrtovanja in poročanja. Ta model pomaga spodbujati pristop "ene plati resnice" do poslovne inteligence in podpira celovito analizo vpliva sprememb poslovnega modela ali modela podatkov. SAP NetWeaver je celovit, tako da ga je mogoče vključiti v avtentične analitične aplikacije. Zasnovan je tako, da s skupkom orodij omogoča preprosto integracijo. To se doseže prek arhitekture (eSOA) SAP NetWeaverja. Spodnja slika prikazuje pregled arhitekture SAP NetWeaverja na visoki ravni.

Slika 4: Diagram arhitekture SAP Netweaverja

ODPRTA INTEGRIRANA APLIKACIJSKA PLATFORMA SAP NetWeaver je sestavljen iz naslednjih komponent:

SAP NetWeaver AS: podpira spletne storitve, poslovne aplikacije in razvoj na osnovi standardov, ki so neodvisni od platforme, kar organom omogoča izkoriščanje obstoječe tehnologije za spletne storitvene rešitve;



SAP NetWeaver Process Integration (SAP NetWeaver PI): nudi odprte integracijske tehnologije, ki podpirajo sodelovanje na osnovi procesov po razširjeni verigi vrednosti;

SAP NetWeaver Master Data Management (SAP NetWeaver MDM): zagotavlja konsistentnost podatkov v več sistemih in pomaga pri integraciji poslovnih procesov po razširjeni verigi vrednosti;

SAP NetWeaver Mobile: nudi mobilno okolje časa izvajanja, ki je "neodvisno od prihodnosti" in temelji na odprtih in prilagodljivih tehnoloških standardih in močnem razvojnem okolju za gradnjo integriranih mobilnih rešitev z lastnimi uporabniškimi vmesniki ali uporabniškimi vmesniki na osnovi brskalnikov;

SAP Auto-ID Infrastructure: nudi organom vse zmožnosti, ki jih potrebujejo pri integraciji vseh samodejnih zaznavnih naprav, vključno s čitalniki in tiskalniki RFID, bluetooth napravami, vgnezdenimi sistemi in napravami za branje črtne kode.

SAP nudi vrsto komponent in orodij v tej enotni platformi, vendar je uporaba nekaterih ali vseh komponent/orodij opcijska in je odvisna od tehnoloških in infrastrukturnih potreb uporabnika. Nudi odprto platformo za poslovne aplikacije, ki jih dobavlja SAP, integracijo z aplikacijami, ki niso SAP-ove, in razvoj lastnih razširitev za SAP-ove rešitve na njihovi platformi, z uporabo panožnih standardov in programskih jezikov. FUNKCIONALNOST IZMENJAVE PODATKOV Rešitve SAP nudijo mehanizme za povezovanje z eksternimi sistemi v realnem času ali v paketnem načinu. V vsakem primeru so na razpolago vsa poslovna pravila (vključno z varnostjo, validacijo vnosov in integriteto transakcij). Razlog je, da so vsi zunanji vmesniki narejeni na aplikacijski plasti sistema, ne na plasti baze podatkov. SAP podpira neposredno integracijo med dvema točkama in je objavil vrsto protokolov in API-jev (aplikacijskih programskih vmesnikov) za vmesnike, ki omogočajo aplikacijam tretjih oseb pošiljanje in prejemanje podatkov iz sistema. Katerakoli aplikacija, ki lahko prenaša podatke prek ASCII ali omejene datoteke EBCDIC, OLE/DCOM, CORBA, RMI, XML ali TCP/IP, lahko deli informacije s SAP-ovim sistemom. Na voljo sta dve metodi za nastavitev vmesnikov:

Uporaba vmesnikov Business Application Programming Interface (BAPI)

SAP nudi več kot 2.000 odprtih vmesnikov, ki se lahko uporabljajo za dostop do njegovih funkcionalnosti v heterogenih infrastrukturah sistemov, ne da bi za to potrebovali dodatno povezovalno programsko opremo ali strojno opremo. Večina teh vmesnikov so BAPI-ji. To so strukturirane in stabilne metode na poslovnih objektih (npr. oblikovanje pravne zavezanosti), do katerih se lahko dostopa sinhrono ali asinhrono. Vsak BAPI ima svojo dokumentacijo, ki opisuje način implementiranja, in vzorčno kodo, ki se jo lahko uporabi/kopira za poenostavitev dela.



Uporaba SAP-ovega standardnega orodja za integracijo podjetniških aplikacij SAP NetWeaver Process Integration (SAP PI)

SAP za povezovanje z drugimi zunanjimi sistemi uporablja svojo močno tehnološko platformo SAP NetWeaver. V SAP NetWeaver je vključen produkt SAP PI, ki omogoča implementacijo medsistemskih procesov in vmesnikov. Omogoča medsebojno povezovanje sistemov različnih dobaviteljev (neSAP-ovih in SAP-ovih) z več različicami in programskimi jeziki (Java, ABAP in drugi). SAP PI temelji na odprti arhitekturi, uporablja odprte standarde (še posebej iz okolij XML in Java) in nudi storitve, ki so nujne v heterogeni infrastrukturi sistema. SAP PI se dobavlja skupaj s komponento SAP Integration Repository, ki priskrbi podrobnosti o zahtevah za povezovanje SAP-ovih rešitev po procesih. Nekatera od dobavljenih orodij in lastnosti so navedena v nadaljevanju:

modeliranje in oblikovanje sporočil, pretvorb in procesov integracije več komponent;

možnosti konfiguracije za upravljanje s procesi sodelovanja in toka sporočil;

čas izvajanja za upravljanje s sporočili in procesi;

adapter Engine za integriranje heterogenih komponent sistema;

centralni nadzor za nadzor toka sporočil in procesov. SAP zato podpira razdruženo sporočilno integracijo na osnovi povezovalne programske opreme, ki se lahko uporablja za dva glavna namena:

integracija podjetniških aplikacij v podjetju (EAI), kjer interne heterogene aplikacije komunicirajo z uporabo SAP PI. To se imenuje tudi komunikacija A2A (aplikacija z aplikacijo);

integracija med podjetji, kjer si organizacije ali agencije izmenjujejo sporočila z uporabo SAP PI. To se imenuje tudi komunikacija B2B (podjetje s podjetjem).

Osnovni koncept je, da se v fazi oblikovanja vsi potrebni vmesniki na začetku razvijajo neodvisno od platforme in so na razpolago prek opisa v jeziku WSDL (Web Service Description Language). Z uporabo tega opisa je mogoče na primer definirati preslikave med vmesniki, ne da bi to vplivalo na obstoječo infrastrukturo sistema. Vsi podatki iz faze oblikovanja se shranijo v Integration Repository in se kasneje implementirajo v določeni infrastrukturi sistema. V tej drugi fazi se v Integration Repository shranijo čas konfiguracije, komponente, vmesniki in preslikave, ki so primerne za infrastrukturo sistema, izberejo pa se lahko tudi procesi sodelovanja in se dodelijo eden drugemu v logičnem usmerjanju. Rezultat te konfiguracije se shrani v Integration Directory in se lahko prikliče in ovrednoti iz monitorja časa izvajanja v SAP PI. Znanje o integraciji procesa sodelovanja se zato shrani centralno v Integration Repository med dizajnom in v Integration Directory med konfiguracijo. SAP PI tako sledi načinu skupnega znanja sodelovanja. Do informacij o procesih sodelovanja ni več treba dostopati v vsakem sistemu, ampak se jih priklicuje centralno. Ta postopek znatno zniža stroške za razvoj in vzdrževanje skupnih aplikacij. SAP PI zato omogoča uporabo vrste zelo heterogenih komponent od vrste dobaviteljev, ki se izvajajo v različnih tehnoloških okoljih. Njegove integracijske



zmožnosti zajamejo skupno poslovno semantiko in so posredniki med storitvami ter njihovo tehnično izpolnitvijo. SAP PI vključuje tehnične funkcije, kot so določitev spletne storitve, zbiranje, preslikavanje in usmerjanje. Prav tako vzpostavi infrastrukturo za upravljanje s poslovnimi procesi in visokozmogljivo izvajanje znotraj in izven organizacijskih mej. Tehnična arhitektura SAP PI je prikazana na Sliki 5.

Slika 5: Pregled arhitekture SAP PI

Pri tem projektu se orodja izbirajo v skladu z naslednjimi parametri:

sistemska infrastruktura za povezovanje eden z enim (ne eden z več ali več z več);

narava in pogostost paketne izmenjave podatkov in v realnem času;

sistemi, ki se povezujejo, so SAP-ovi z neSAP-ovimi (ne neSAP-ovi z neSAP-ovimi);

število prodanih licenc in uporabnikov SAP PI v Republiki Sloveniji. Izbrano je orodje API, ker je v Republiki Sloveniji premalo uporabnikov SAP PI. Komunikacija/izmenjava informacij je lahko vhodna in izhodna. SAP NETWEAVER podpira naslednje operacijske sisteme:

IBM AIX 5.3, 6.1;

HP-UX 11;

MS Windows Server 2003, 2008;

Sun Solaris;

REDHAT Linux EL4, 5;



Linux SuSe SLES 9, 10. SAP NETWEAVER podpira naslednje podatkovne baze:

SAP na HANA;

SAP na DB2 for Linux, Unix, and Windows;

SAP na DB2 for i5/OS;

SAP na DB2 for z/OS;

SAP na Oracle 10.2;

SAP na Microsoft SQL Server;

SAP na MaxDB;

SAP na Informix;

SAP na ASE.

2.3 PRAVNE PODLAGE IN REGULATIVE, KI UREJAJO POSLOVANJE Z E-RAČUNI Zakonodaja, ki ureja področje elektronskega poslovanja v Republiki Sloveniji velja že več kot 10 let. Bili smo eni prvih, ki smo področje brezpapirnega poslovanja začeli obravnavati tudi na zakonodajnem področju. V zakonodaji Republike Slovenije se področje brezpapirnega poslovanja in predvsem zaščita uporabnikov ureja na način, da se predpisuje:

zagotavljanje prepoznavnosti avtorjev elektronskih dokumentov,

zagotavljanje nespremenljivosti elektronskih dokumentov,

hramba dokumentov in

zagotavljanje veljavnosti elektronskih dokumentov znotraj postopkov (sodni, davčni ter drugi).

Zakonodajalec je v želji po ureditvi nadzora področja in ponudnikov rešitev podelil pooblastilo Arhivu RS, ki je pooblaščen za izvajanje nadzora in evidence ponudnikov rešitev. Poleg tega Arhiv RS aktivno sodeluje pri posodabljanju zakonodaje. Določena področja poslovanja z elektronskimi dokumenti, kot je delovanje javne uprave, plačilni promet in veljavnosti računov v davčnih postopkih, pa so urejeni preko drugih predpisov in zakonodaje, vezanih na posamezno vsebinsko področje. Poslovanje z e-računi urejajo:

Zakon o elektronskem poslovanju in elektronskem podpisu (ZEPEP) Ta zakon ureja elektronsko poslovanje, ki zajema poslovanje v elektronski obliki z uporabo informacijske in komunikacijske tehnologije in uporabo elektronskega podpisa v pravnem prometu, kar vključuje tudi elektronsko poslovanje v sodnih, upravnih in drugih podobnih postopkih, če zakon ne določa drugače (Uradni list RS, 98/2004). Če ni dogovorjeno drugače, določbe tega zakona, z izjemo določb 4. in 14. člena, ne veljajo v zaprtih sistemih, ki so v celoti urejeni s pogodbami med znanim številom pogodbenih strank (Uradni list RS, 98/2004).

Zakon o varstvu dokumentarnega in arhivskega gradiva ter arhivih (ZVDAGA)



Ta zakon ureja način, organizacijo, infrastrukturo in izvedbo zajema ter hrambe dokumentarnega gradiva v fizični in elektronski obliki, veljavnost oziroma dokazno vrednost takega gradiva, varstvo arhivskega gradiva in pogoje za njegovo uporabo, naloge arhivov in javne arhivske službe ter s tem povezane storitve in nadzor nad izvajanjem (Uradni list RS, 30/2006).

Zakon o davku na dodano vrednost (ZDDV)

Enakovredna obravnava e-računa s pisnim računom z določbo 4. odstavka 84. člena ZDDV-1, na podlagi Direktive Sveta 2010/45/EU.

Veljavnost in hramba e-računa – pristnost izvora (5. odst. 84. čl. glede identitete izdajatelja oz. dobavitelja), celovitost vsebine (6. odst. 84.čl. glede vsebine računa, ki po izdaji ni bila spremenjena) in čitljivost računa (pisno ali na prikazovalniku, vključno po pretvorbi), zagotovljena od trenutka izdaje do konca obdobja hrambe računa (4. odst. 84. čl. ZDDV-1); – obvezni podatki na računu (82. čl. ZDDV-1); – hramba v svoji izvirni papirnati ali elektronski obliki, v kateri so bili poslani ali dani na razpolago (3. odst. 86. čl- ZDDV-1).

Pri izmenjavi e-računov s proračunskimi uporabniki je bilo potrebno upoštevati tudi:

Zakon o opravljanju plačilnih storitev za proračunske uporabnike (ZOPSPU) Zakon ureja opravljanje plačilnih storitev za neposredne in posredne uporabnike državnega in občinskih proračunov, Zavod za zdravstveno zavarovanje Slovenije ter Zavod za pokojninsko in invalidsko zavarovanje Slovenije, register proračunskih uporabnikov ter naloge in organizacijo Uprave Republike Slovenije za javna plačila (Uradni list RS, 59/10 2010).

Zakon o spremembah in dopolnitvah Zakona o opravljanju plačilnih storitev za proračunske uporabnike (ZOPSPU-A)

Pravilnik o standardih in pogojih na področju izmenjave elektronskih računov prek enotne vstopne in izstopne točke pri Upravi Republike Slovenije za javna plačila Pravilnik določa standarde in pogoje za izmenjavo računov v elektronski obliki, ki jih izdajajo ali prejemajo neposredni in posredni uporabniki državnega in občinskih proračunov, Zavod za zdravstveno zavarovanje Slovenije in Zavod za pokojninsko in invalidsko zavarovanje Slovenije prek enotne vstopne in izstopne spletne točke pri Upravi Republike Slovenije za javna plačila (Uradni list RS, 9/16 2016).

E-SLOG 1.6 e-SLOG je blagovna znamka Gospodarske zbornice Slovenije. Gre za standard na področju izmenjave e-računov v Republiki Sloveniji. Podlaga, ki je bila osnova za pripravo struktur in šifrantove-SLOG je mednarodni standard GS1 EANCOM®, ki ga je GS1 Slovenija (takratni EAN Slovenija) predelala za potrebe uporabe e-SLOGA. Spreminjanje vsebine shem ni dovoljeno. Uporabnikom je dovoljena uporaba e-SLOGA za namene elektronskega poslovanja. Uporaba je brezplačna (GZS, 2012).



Formalna pravilnost e-SLOG računa je opredeljena s skladnostjo XML računa s shemo e-SLOG enostavni račun 1.6. Shema opredeljuje tudi nabor dovoljenih vrednosti za določene elemente s šifranti. Slika 6 prikazuje primer tabele za predstavitev XML strukture.

Slika 6: Primer tabele za predstavitev XML strukture (GZS, 2012)

Legenda k tabeli za opis XML strukture, prikazana v Tabeli 1:

Naziv stolpca

Opis vsebine

Pon. Števnost elementa: – 1 (natanko enkrat) – 1–n (enkrat ali večkrat) – 0–n (nič ali večkrat) – 0–1 (nič ali enkrat) Števnost 1 in 1 – n pomenita, da je prisotnost elementa obvezna v skladu s shemo.

Opis elementa

Poljuden opis vsebine/namena elementa.

Naziv značke

Naziv XML oznake elementa po shemi e-SLOG 1.6 za enostavni račun. Znak + na začetku označuje gnezdenje elementa v element v vrstici nad njim.



Obv. Pomeni obveznost prisotnosti podatka v e-SLOG računu: »DA« – Obvezni Sem uvrščamo obvezne elemente računa po slovenski zakonodaji. Zanje obstajajo odgovarjajoči XML elementi v e-SLOGU, na primer izdajatelj, naročnik, postavke, povzetek davkov. »PP« – Priporočeni po priročniku (dogovorno obvezni podatki) Sem sodijo neobvezni XML elementi po slovenski zakonodaji, ki so potrebni za potrebe distribucije e-računov in avtomatizacije priprave plačil, za katere že obstajajo ustrezni XML elementi v e-SLOGU, na primer referenca za plačilo. »NE« – Neobvezni Neobvezni elementi po slovenski zakonodaji, ki so potrebni za poslovno interpretacijo e-računa ter zanje obstajajo elementi v e-SLOGU, na primer naslov računa, kontakti. »RK« ali »RP« – Razširitev rabe obstoječe e-SLOG sheme Načini za razširitve so opisani v poglavju »Razširitve rabe e-SLOG«. Oznaka »RK« označuje razširitev na ravni celotnega računa, oznaka »RP« označuje razširitev na ravni postavke.

Format Vrednosti lahko zavzamejo enega od naslednjih formatov: – število (XSD standardni podatkovni tip xs:float), – niz alfanumeričnih znakov (XSD standardni podatkovni tip xs:string), – datum (XSD standardni podatkovni tip xs:dateTime z zalogo vrednosti iz ISO 8061 in skladno z vzorcem: [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm]).

Zaloga vrednosti

Za opis omejitev zaloge vrednosti se uporablja: – omejitev dolžine pri nizih, – raba regularnih izrazov, – uporaba šifrantov: šifranti so opredeljeni s shemo e-SLOG 1.5 in so dodani kot priloga k priročniku s pojasnili. Pojasnila so ohranjena iz komentarjev k e-SLOG shemi. Prevedene so samo vrednosti kod, ki so najpogosteje uporabljane. Pri vrsticah, ki opredeljujejo razširitve se v tem stolpcu navaja še: »omejena« ali »neomejena«. Glej poglavje »Razširitve rabe e-SLOG«.

Primer vrednosti

Konkreten primer vsebine elementa za ilustracijo.

Tabela 1: Legenda k tabeli za opis XML strukture (GZS, 2012)

Za potrebe rešitve našega problema smo uporabili e-SLOG 1.6.



3 OBSTOJEČE STANJE 3.1 POSNETEK STANJA Celoten postopek izdaje fakture je del SAP ERP modula SD, ki ima poleg izdaje fakture še druge ključne aktivnosti. Celoten proces je prikazan na Sliki 7. Ker je SAP ERP rešitev, ki je narejena za globalno uporabo, je postopek standardiziran in je izvajanje ključnih aktivnosti v procesu enako znotraj posamezne verzije SAP ERP sistema. Končni uporabnik ima kljub temu določene možnosti za prilagajanje aktivnosti izdajanja računov znotraj ponujenih uporabniških izhodov in »BadI – Business Add Ins«. Za rešitev našega problema smo morali izhajati iz standardne rešitve, ker je bila sama rešitev objavljena od strani SAP AG, ki je uradni proizvajalec SAP ERP. Standardni proces prodaje, s poudarkom na izdajanju računov, se v najbolj osnovnem primeru prične, ko kupec izvede poizvedbo glede oskrbe z materialom. Prodajni referent vnese podatke o materialu in dobavi v povpraševanje, ki izračuna ceno na osnovi osnovnega cenika ali pogojev določitve cene, specifičnih za kupca, vključno s popusti ali doplačili. Povpraševanje se shrani z enoznačno številko, ki jo uporabnik lahko uporabi za referenco pri ustvarjanju prodajnega naloga. Po potrebi je mogoče oblikovati izpis povpraševanja za pošiljanje kupcu. Uporaba dokumenta povpraševanja omogoča podjetjem sledenje vsem povpraševanjem, ne samo prodajnim nalogom, ki že predstavljajo dejanska naročila kupcev. V nekaterih primerih lahko kupec zahteva formalni dokument ponudbe namesto povpraševanja. Ponudbo je mogoče spremeniti, ker nudi iste informacije kot povpraševanje, a vključuje več informacij o pogojih za trgovanje. Ponudbo je mogoče oblikovati kot samostojni dokument ali jo kopirati iz obstoječega povpraševanja kupca. Prodajni nalog je pogodbeni dokument za dobavo kupcu. Podrobnosti postavk prodajnega naloga lahko uporabnik vnese neposredno ali pa jih kopira iz obstoječega povpraševanja ali ponudbe. Ko kupec rutinsko naroča iste postavke, lahko uporaba funkcije predloga postavke pohitri proces vnosa prodajnega naloga. Med procesom prodajnega naloga je mogoče samodejno izvesti naslednje kontrole:

kontrolo kredita kupca,

razpoložljivost materiala (ATP),

samodejno določitev cen (cena po ceniku ali specifična za kupca). Za primer vzemimo tri tipe prodajnih nalogov:

standardni prodajni nalog,

hitri prodajni nalog,

gotovinski prodajni nalog. Standardni prodajni nalog podpira dobave prodajnih postavk tretje stranke, kjer se blago odpošlje kupcu neposredno od dobavitelja tretje stranke. Na razpolago je izpis potrditve prodajnega naloga. Podrobnosti prodajnega naloga se samodejno pošljejo veljavnemu mestu odprave v trgovinah in samodejno se oblikuje dobava z uporabo seznama zapadlosti dobav. To ustvari dobave s pravilno prioriteto za



komisioniranje, pri čemer se upošteva zahtevani datum dobave in prehodni čas za komisioniranje ter odpravo. To omogoča trgovinam, da prioritetno obdelajo nalog za komisioniranje, da zadovoljijo potrebe kupca in logističnih procesov znotraj skladiščne lokacije. Rešitev samodejno vzdržuje popolno preglednost in preprosto sledljivost med prodajnim nalogom in dobavo. Izpis dobavnice se izdela z uporabo seznama komisioniranja za trgovine in kot dokument odprave za kupca. Ko je vse blago za dobavo komisionirano, potrjeno v sistem in pripravljeno za pošiljanje kupcu, se izvede knjiženje izdaje blaga (KIB). KIB se integrira v realnem času, s čimer zmanjša raven zaloge v trgovinah, in izvede zahtevana finančna knjiženja za konte (npr. stroški prometa). Rešitev v prodajnem informacijskem sistemu (LIS) nudi poročila in dinamično zalogo v realnem času in poročila o statusu naloga za nadzor aktualnega statusa vseh dokumentov prodaje/dobave, s čimer olajšuje komercialni službi sledenje aktualnemu statusu o dobavah kupcem. Izpisi računov se ustvarijo glede na podrobnosti dobave pri KIB-u dobave. Račune je mogoče ustvariti samodejno z uporabo seznama zapadlih fakturiranj. Mogoče jih je ustvariti tudi ročno, še posebej, ko je treba upoštevati ročna doplačila ali ko je potreben posamezen račun za odpošiljanje z blagom. Ko je plačilo kupca prejeto, se v sistemu izvede plačilo. Med procesom plačila lahko uporabnik pregleda aktualni status konta za zapadla plačila kupcev v realnem času. To poenostavlja proces plačila, saj uporabniku omogoča preprosto usklajevanje vplačil z ustreznim računom. Proces plačil samodejno integrira s procesom upravljanja s krediti, ki je definiran v funkcionalnosti terjatev v računovodstvu. Za upravljanje reklamacij kupcev sta na razpolago dva tipa dokumentov:

dokument reklamacije – brez vračila blaga,

prodajni nalog vračil – z vračilom blaga. Dokument reklamacije omogoča podjetjem sledenje vsem reklamacijam kupcev, tudi tistim, kjer nadaljnja akcija ni potrebna. Če je blago treba vrniti, se uporabi prodajni nalog vračil, ki vključuje možni dogovorjeni rabat. Ko se blago vrne v trgovino, se zanj izda potrdilo o prejemu z referenco na prodajni nalog vračil. Ustvari se izpis dobropisa kupca z referenco na dogovorjeno ceno. Po potrebi je mogoče ustvariti ročne izpise dobropisov ali bremepisov brez reference na prodajni nalog. FAKTURIRANJE – IZDAJA RAČUNA Proces logistike prodaje se zaključi s korakom fakturiranja. Fakturiranje je popolnoma integrirano v sistem s prodajnim nalogom, procesom dobave in finančnim knjigovodstvom ter področji upravljanja s krediti. Informacija je takoj na razpolago za analizo podatkov donosnosti, na primer po oddelku, kupcu in produktu. Razpoložljive funkcije v fakturiranju so naslednje:

izdaja blaga na osnovi dobav,

izdaja dobropisov ali bremepisov,

izdaja proforma računa na osnovi prodajnega naloga ali dobave,

preklic transakcije fakturiranja in ustrezen storno,

takojšnje ažuriranje zapisov finančnega knjigovodstva.



Rešitev izvede funkcije fakturiranja z uporabo dokumentov fakturiranja, ki so zasnovani tako, da zadovoljijo potrebe tipičnih scenarijev fakturiranja. Ta skrbna zasnova in integracija podatkov zmanjšujeta napor, potreben za zaključevanje procesov fakturiranja, in možnosti pojava napak. Vsak dokument fakturiranja temelji na predhodnem dokumentu, po navadi dobavi, iz prejšnjega koraka v procesu prodaje. Račune je mogoče ustvariti samodejno z uporabo seznama zapadlih fakturiranj. Mogoče jih je ustvariti tudi ročno, še posebej, ko je treba upoštevati ročna doplačila ali ko je potreben posamezen račun za odpremo z blagom. Metode fakturiranja glede na način:

ločeno fakturiranje po posameznih dobavah – metoda predvideva izdajo računa za vsako posamezno dobavo,

kolektivno/zbirno fakturiranje – metoda predvideva izdajo zbirnega računa za več posameznih dobav,

delitev računov – metoda predvideva izdajo več računov za eno dobavo. Metode fakturiranja glede na čas:

periodične – zaračunavanje skupnega zneska glede na planirano obdobje,

glede na mejnike – zaračunavanje določenega mejnika (npr. mejnik na projektu),

obročne – proporcionalno zaračunavanje in datum plačila glede na določene obroke,

čas in denar – zaračunavanje sproti opravljenih storitev (npr. storitve svetovanja).

Ne glede na uporabljeno metodo fakturiranje rezultira v ažuriranju zapisov v finančnem knjigovodstvu. SAP ERP je integriran sistem, zato vsak izdani račun rezultira v modulu financ in kontrolinga. Če je tako nastavljeno, se v realnem času ažurira tudi modul konsolidacije.



Slika 7: Diagram osnovnega procesa prodaje v SAP ERP



3.2 KRITIČNA ANALIZA V prejšnjem stanju je bilo precej pomanjkljivosti na tehnološkem in tudi procesnem področju.

Tehnološko področje – sistem SAP ERP ne predvideva podpore izdajanja e-računov v obliki e-SLOG za Republiko Slovenijo direktno iz samega ERP sistema. Ker se uvedba regulatornih zahtev v Republiki Sloveniji izvaja pod nadzorom proizvajalca programske opreme SAP AG, so uporabniki tudi tehnološko omejeni, saj razvoja v lastni režiji ni smiselno izvajati, ker obstaja nevarnost, da le-ta ni izveden s standardi in strategijo razvoja SAP.

Procesno področje – proces je potekal neoptimalno, saj je bilo veliko ročnega dela in možnosti napak pri izdajanju računov. Prav tako pretok informacij ni bil ažuren in točen, ker je potekal v papirni obliki. Vse to je povzročalo nepotrebne stroške materiala in storitev (pošta, papir, vložišče).



4 PRENOVA Kot je že izpostavljeno v opisu obstoječega stanja, smo za rešitev našega problema morali izhajati iz standardne rešitve, ker je bila sama rešitev objavljena od strani SAP AG, ki je uradni proizvajalec SAP ERP. Proces kot tak se z razvojem slovenske lokalizirane rešitve ni smel spremeniti. Omejitev ni bila zgolj procesna, ampak tudi tehnična. Sprememba oz. modifikacija standardne kode, ki podpira standardni proces prodaje v SAP ERP, ni bila dovoljena. Zato je SAP AG izdelal ločeno okolje eDocument Framework za vzpostavitev e-poslovanja za posamezne procese znotraj SAP ERP rešitve. SAP ERP je tako po standardu poskrbel, da so vsi relevantni dokumenti (npr. izhodni račun, vhodni račun, dobavnica itd.) ob knjiženju ustrezno označeni, da jih eDocument Framework zazna in lahko uporablja pri nadaljnji obdelavi v sklopu e-poslovanja. Usmeritev je bila, da izdelamo rešitev, ki bi nadgradila eDocument Framework in zagotovila, da se iz sistema preko eDocument Frameworka generira e-račun v obliki e-SLOGA, ki velja za Republiko Slovenijo. Rešitev oz. dodatek je moral biti zastavljen odprto, kar pomeni, da mora omogočati spreminjanje določenih parametrov, kot so količina in vrsta priponk, odlagališče datotek, cenovni pogoji, hišne banke, matični podatki, komunikacija in integracija na dokumentni sistem itd. Komunikacija oz. pošiljanje e-računov je narejeno do nivoja odlaganja e-računov na vnaprej definirano področje. Rešitev ne predvideva že prednastavljene direktne komunikacije z UJP ali katerimi izmed ponudnikov storitev posredovanja e-dokumentov. Razviti in predpripravljeni sta funkciji, ki omogočata dodatno uporabniško razširitev rešitve in implementacijo konkretne integracije, specifične za posameznega uporabnika in prejemnika UJP ali ZZI:

ZZI: Z_ERACUNI_GEN_XML_OVOJNICA,

UJP: Z_ERACUNI_GEN_XML_OVOJ_CUS. Arhiviranje e-računov je v rešitvi predvideno. Sama končna rešitev predvideva tudi morebitno integracijo na dokumentni sistem, vendar ni prednastavljene integracije na noben specifičen dokumentni sistem, to je stvar realizacije pri samem uporabniku.

4.1 EDOCUMENT FRAMEWORK V osnovi gre za celovit pristop k ustvarjanju, procesiranju in upravljanju elektronskih dokumentov. Rešitev je primerna za izpeljavo specifičnih zahtev posameznih držav glede elektronskih dokumentov, in sicer v zvezi z obliko, integracijo in procesnimi koraki celovitega procesa. Vir dokumentov za eDocument Framework so lahko različni moduli SAP ERP, kot so prodaja, finance, nabava itd. SAP AG je objavil rešitev eDocument Frameworka v dveh opcijah:

polna rešitev in

osnovna rešitev.



POLNA REŠITEV Polna rešitev pokriva celovit proces zbiranja podatkov, izmenjavo sporočil (dokumentov) z zunanjimi partnerji in ostalimi subjekti in branje ter procesiranje odgovorov, prejetih od strani istih. Polna rešitev ni na voljo za vse države in je objavljena za zelo omejen nabor držav. OSNOVNA REŠITEV Osnovna rešitev je namenjena uporabnikom, ki želijo biti bolj fleksibilni pri samem procesiranju izhodnih sporočil (dokumentov) in zato preferirajo lasten razvoj funkcionalnosti za generiranje in procesiranje elektronskih dokumentov. Pri osnovni rešitvi so na voljo zgolj podatki o sami bazi dokumentov, ki so na voljo za nadaljnje procesiranje in se generirajo iz ostalih SAP ERP procesov. Uporabnik lahko nato sam razvije strukture in zastavi proces izmenjave datotek glede na to, kakšne so regulatorne zahteve in zahteve partnerjev, s katerimi posluje. Ne glede na način komunikacije, mora biti sama izhodna datoteka generirana pred samim pošiljanjem. Za reševanje našega problema smo uporabili osnovno rešitev. GENERIRANJE IN PREGLED BAZE DOKUMENTOV ZA E-POSLOVANJE Dokumenti, ki se generirajo v posameznih SAP ERP procesih in so relevantni za e-poslovanje, se beležijo v osnovni tabeli EDOCUMENT, katerega entitete so prikazane v Tabeli 2.

Ime entitete Primarni

ključ Tip entitete Velikost Opis

MANDT X CLNT 3 klient

EDOC_GUID X CHAR 32 eDocument: GUID

SEQ_NO NUMC 3 eDocument zaporedna številka

BUKRS CHAR 4 šifra podjetja

LAND CHAR 3 država podjetja

SOURCE_TYPE CHAR 10 eDocument tip izvora

SOURCE_KEY CHAR 32 eDocument ključ izvora

EDOC_TYPE CHAR 10 eDocument tip

PROC_STATUS CHAR 4 eDocument status

LOGSYS CHAR 10 logical system

CHANGED_BY CHAR 12 spremenil (uporabnik)

CHANGE_DATE DATS 8 spremenjeno dne (datum)

CHANGE_TIME TIMS 6 spremenjeno ob (čas)

CREATED_BY CHAR 12 kreiral (uporabnik)

CREATE_DATE DATS 8 datum kreiranja

CREATE_TIME TIMS 6 kreirano ob (čas)

PROCESS CHAR 10 eDocument proces

LAST_PROCSTEP CHAR 10 eDocument zadnji korak procesa



ERROR_FLAG CHAR 1 oznaka napake

PROCESS_VERSION NUMC 4 eDocument verzija procesa

DOCREF_SEQNR NUMC 5 zaporedna številka reference dokumenta eDoc

STATUS CHAR 40 pregled statusa eDocumenta

POSTING_DATE DATS 8 datum knjiženja prvotnega dokumenta

INTERFACE_TYPE CHAR 10 vrsta vmesnika

APPROVAL_ID STRING 0 eDocument: ID odobritve

INTERFACE_GUID CHAR 32 ID sporočila vmesnika

FILE_GUID CHAR 32 GUID datoteke

RESPONSE_CODE STRING 0 eDocument: Koda odgovora

INTERFACE_ID CHAR 30 vmesnik

INT_VERSION NUMC 4 verzija vmesnika za eDocument

Tabela 2: Predstavitev tabele EDOCUMENT (potrebne entitete)

Del osnovne rešitve je tudi program EDOC_RESUBMIT_EDOCUMENT, preko katerega se izvajajo izbor, obdelava, pošiljanje dokumentov in branje povratnic. Osnovne funkcionalnosti programa so:

izbor dokumentov za obdelavo – na Sliki 8 je prikazan izborni ekran, s primerom izbora podatkov dokumentov iz modula SD, z datumom računa 1. 8. 2016 podjetja SI10, ne glede na status obdelave. Na Sliki 9 pa je prikazan rezultat izbora.



Slika 8: Izborni ekran programa EDOC_RESUBMIT_EDOCUMENT

Slika 9: Pregled dokumentov v programu EDOC_RESUBMIT_EDOCUMENT

Obdelava dokumentov – program omogoča razvoj uporabniških funkcionalnosti za obdelavo dokumentov iz nabora. Podprte so možnosti razvoja različnih izhodnih struktur, komunikacijskih poti in obdelave prejetih odgovorov. Akcije, ki so na voljo, so prikazane na Sliki 8.



osvežitev seznama dokumentov,

kreiranje e-dokumentov,

košiljanje e-dokumentov,

osvežitev statusa z davčne uprave – funkcionalnost se v sklopu naše rešitve uporablja za uvoz odgovorov oz. povratnic,

izvoz datoteke – izvoz v XML datoteke,

zgodovina – pregled zgodovine e-dokumenta.

Slika 10: Akcije, na voljo v osnovnem programu eDocument Framework

Za vsako aktivnost nam je SAP AG omogočil uporabniški izhod ali BAdI, kjer smo lahko razvili rešitev za podporo kreiranja e-računov v obliki e-SLOGA za Republiko Slovenijo. Statusi dokumentov, ki jih poznamo in so vzdrževani v entiteti PROC_STATUS

tabele EDOCUMENT, so:

CREA – e-račun, kreiran,

SENT – e-račun, poslan prejemniku,

REJC – e-račun, zavrnjen s strani prejemnika,

APPP – e-račun, potrjen s strani prejemnika.

4.2 RAZVOJ UPORABNIŠKIH IZHODOV IN BADI SAP AG je za razvoj specifičnih rešitev po državah predvidel implementacijo BAdI. Za izboljšave in razvoj specifik na področju Republike Slovenije znotraj eDocument Frameworka je kreiran BAdI EDOC_INTERFACE_CONNECTOR, kjer je narejena razširitev za Republiko Slovenijo ZEDOC_INT_CONNECTOR_SI_BADI. Sam BAdI vsebuje 6 metod:

IF_EDOC_INTERFACE_CONNECTOR~COMMUNICATE_ACTION,

IF_EDOC_INTERFACE_CONNECTOR~TRIGGER,

IF_EDOC_INTERFACE_CONNECTOR~NAVIGATE_TO_MONITOR,

IF_EDOC_INTERFACE_CONNECTOR~RESUBMIT,

IF_EDOC_INTERFACE_CONNECTOR~PULL_REQUEST,

IF_EDOC_INTERFACE_CONNECTOR~CANCEL.

Za potrebe zagotovitve rešitve smo uporabili metodo IF_EDOC_INTERFACE_CONNECTOR~TRIGGER, kjer so implementirane vse razširitve za:

kreiranje e-računa in pošiljanje na izmenjevalno področje,

pošiljanje e-računa na izmenjevalno področje,

prevzem povratnic e-računov in obdelava.



Za zagotovitev parametrizacije rešitve smo kreirali parametrizacijsko tabelo, kjer so definirani vsi ključni parametri, ki so lahko vnaprej nastavljivi in določljivi, in funkcijski moduli, ki so potrebni za obdelavo podatkov. Parametrizacijska tabela se imenuje ZERAC_CUSTOMIZE in je prikazana v Tabeli 3.

Ime entitete Primarni

ključ Tip entitete Velikost Opis

MANDT X CLNT 3 klient

ZPARAMETER X CHAR 20 parameter za e-račune

ZCOUNT X CHAR 2 števec parametrov

ZVALUE1 CHAR 50 vrednost parametra za e-račune





Tabela 3: Predstavitev tabele ZERAC_CUSTOMIZE (potrebne entitete)

FM_XML_ INVOIC – Funkcija za kreiranje računa V tem parametru se vzdržuje ime funkcije, ki se kliče ob kreiranju xml datoteke za e-račun. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

Primer vnesenega parametra FM_XML_ INVOIC je prikazan na Sliki 11.

Slika 11: Prikaz vzdrževanega parametra FM_XML_ INVOIC

FM_XML_ ENVELOPE – funkcija za kreiranje ovojnice V tem parametru se vzdržuje ime funkcije, ki se kliče ob kreiranju xml ovojnice. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

FM_FILENAME_POV – funkcija za generiranje imena povratnice V tem parametru se vzdržuje ime funkcije, ki služi generiranju imena za iskanje datoteke povratnice na datotečnem sistemu. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

FM_XML_POVRATNICA – funkcija za pridobitev podatkov povratnice V tem parametru se vzdržuje ime funkcije, ki se kliče ob pridobivanju podatkov povratnice. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

FM_XML_PDFS – funkcija za kreiranje priponk PDF V tem parametru se vzdržuje ime funkcije, ki se kliče ob kreiranju PDF priponke. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo. Omogoča kreiranje več priponk, ki se kot PDF string zapisujejo v interno



tabelo. Priložena funkcija kreira en PDF dokument z izpisom fakture kot priloge k e-računu.

FILENAME_PDF – zadnji del imena pdf datoteke V tem parametru se vzdržuje drugi del imena pdf datoteke, ki se kreira. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo. Prvi del imena je vedno številka dokumenta.

FILENAME_XML_ENV – zadnji del imena XML datoteke ovojnice V tem parametru se vzdržuje drugi del imena xml datoteke ovojnice, ki se skreira. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo. Prvi del imena je vedno številka dokumenta.

FILENAME_XML_RAC – zadnji del imena XML datoteke e-računa V tem parametru se vzdržuje drugi del imena XML datoteke e-računa, ki se kreira. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo. Prvi del imena je vedno številka dokumenta.

ENV_CREATE – ali se ovojnica kreira (X = da) V tem parametru se vzdržuje indikator, ali se ob kreiranju e-računa kreira tudi XML datoteka za ovojnico. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

PDF_CREATE – ali se PDF datoteka kreira za SD dokument (X = da) V tem parametru se vzdržuje indikator, ali se ob kreiranju e-računa za SD dokumente kreira tudi PDF datoteka za ovojnico. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

SD_FORMNAME – forma za SD dokumente V tem parametru se vzdržuje ime SMARTFORM forme za izpis SD dokumenta. Parameter je potreben v primeru, ko se ob kreiranju e-računa kreira tudi PDF izpis kot priloga računa. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec, tip SD fakturnega dokumenta v prvo vrednost in ime forme v drugo vrednost. Lokalna rešitev je omejena samo na kreiranje izpisa z uporabo SMARTFORM forme.

FOLDER_ROOT – FM za upravljanje z mapo za izmenjavo dokumentov Parameter vsebuje ime funkcijskega modula, s katerim pridobimo pot do osnovnega direktorija, kjer se bodo datoteke kreirale in brale. V funkciji se kliče parameter FOLDER_RO_NAME. Privzeta vrednost je DIR_TRANS, kar pomeni pot na aplikacijskem strežniku.

FOLDER_RO_NAME – ime mape na osnovnem direktoriju Parameter je v kombinaciji s parametrom IN_FOLDER_ROOT. V njem je vrednost do root izmenjevalnega direktorija.

FOLDER_TYP_APP_PC – funkcijski modul za upravljanje z mapo za izmenjavo dokumentov V tem parametru se vzdržuje tip mape za izmenjavo dokumentov. Če je A, pomeni, da se datoteke zapisujejo na aplikacijski server, če je P, pomeni,



da se datoteke zapisujejo na uporabnikov prezentacijski računalnik. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo. Dovoljeni sta samo vrednosti A in P. Parameter mora biti obvezno izpolnjen.

OUT_FOLDER – mapa na aplikacijskem strežniku, za odlaganje datotek V tem parametru se vzdržuje pot do izhodne mape, ki se nahaja na aplikacijskem strežniku. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

IN_FOLDER – mapa na aplikacijskem strežniku za prevzemanje povratnic V tem parametru se vzdržuje pot do izhodne mape, ki se nahaja na aplikacijskem strežniku. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

VRSTARACUNA – povezava med tipom SD fakture in e-SLOG tipom V tem parametru se vzdržuje povezava med tipom SD fakturnega dokumenta in tipom dokumenta po e-SLOG specifikaciji. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec, tip SD fakturnega dokumenta v prvo vrednost in tip dokumenta po e-SLOG specifikaciji v drugo vrednost.

VRSTARACUNA_FI – povezava med tipom FI dokumenta in e-SLOG tipom V tem parametru se vzdržuje povezava med tipom FI fakturnega dokumenta in tipom dokumenta po e-SLOG specifikaciji. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec, tip FI dokumenta v prvo vrednost in tip dokumenta po e-SLOG specifikaciji v drugo vrednost.

BIC_H_BANKE – BIC hišne banke V tem parametru se vzdržuje BIC številka hišne banke. Če je šifra podjetja proračunski porabnik, se uporabi BIC Uprave za javne prihodke. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec, šifro podjetja v prvo vrednost in BIC številka hišne banke v drugo vrednost. Vzdržuje se lahko le en parameter za eno šifro podjetja.

HISNA_BANKA – IBAN hišne banke (pošiljatelj) V tem parametru se vzdržuje IBAN številka hišne banke. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec, šifro podjetja v prvo vrednost in IBAN številko hišne banke v drugo vrednost. Vzdržuje se lahko le en parameter za eno šifro podjetja.

KLAVZULA_SD – A0 Dav.Klav/Lok.drž, Klas.Dav.Kup, Klas.Dav.Mat V tem parametru se vzdržuje določitev davčne klavzule, ki se pošlje v e-računu. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje števec, tip države kupca (SI = Slovenija, EU = države EU, OT = tretje države) v prvo vrednost, klasifikator davka na kupcu v drugo vrednost, klasifikator davka na materialu v tretjo vrednost in naziv standardnega teksta v četrto vrednost. Standardni teksti se vzdržujejo v transakciji SO10.



KODA_NAMENA – prednastavljena koda namena plačila za SD dokument V tem parametru se vzdržuje prednastavljena koda namena za SD fakturne dokumente. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

KODA_NAMENA_FI – prednastavljena koda namena plačila za FI dokument V tem parametru se vzdržuje prednastavljena koda namena za FI fakturne dokumente. Vzdržuje se samo en parameter z napolnjeno prvo vrednostjo.

MATICNA_ST – matična številka pošiljatelja (senderja) V tem parametru se vzdržuje matična številka za šifro podjetja. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec, šifro podjetja v prvo vrednost in matično številko v drugo vrednost.

NAZIV_H_BANKE – naziv hišne banke V tem parametru se vzdržuje naziv hišne banke za šifro podjetja. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec, šifro podjetja v prvo vrednost in naziv hišne banke v drugo vrednost.

CENA_POGOJ – pogoj za bruto vrednost V tem parametru se vzdržujejo pogoji, ki se uporabijo pri izračunavanju bruto vrednosti. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec in tip pogoja v prvo vrednost.

POPUST_POGOJ – pogoj za popuste V tem parametru se vzdržujejo pogoji, ki se uporabijo pri izračunavanju popustov. Vzdržuje se lahko več parametrov, pri čemer je potrebno vnesti zaporedno številko v polje Števec in tip pogoja v prvo vrednost.

BIC_H_BANKE_REAL – dejanski BIC hišne banke V tem parametru se vzdržuje dejanska BIC številka banke pošiljatelja (sender), ki se uporabi v ovojnici v podatkih za plačilo. Vzdržuje se lahko več parametrov, po en za šifro podjetja. V vrednost 1 se vnese šifra podjetja, v vrednost 2 se vnese BIC številka banke. V primeru, ko je več parametrov, je števec obvezen vnos.

BIC_UJP – BIC UJP, ki se uporabi za proračunske porabnike. V tem parametru se vzdržuje BIC UJP, ki se uporablja za proračunske porabnike. Za namen testiranja se uporabi BIC UJPLSI20ICL, za produkcijsko pošiljanje pa UJPLSI2DICL. Vzdržuje se en parameter v polju Vrednost 1.

Za pravilno delovanje rešitve je potrebno vzdrževati tudi naslednje matične podatke v sistemu SAP ERP:

matični podatki kupcev;

vzdrževana mora biti davčna številka. Če ne obstaja ID za DDV (STCEG), se uporabi davčna številka 1 (STCD1);



v polju davčna številka 4 (polje STCD4) mora biti vnesena številka proračunskega porabnika;

vzdrževan mora biti transakcijski račun in IBAN. V primeru, da ima kupec več transakcijskih računov, se v XML e-računa vnese tisti, ki je označen s 'SIER' v polju Referenčni podatki (BKREF). Če je račun samo eden, oznaka ni potrebna;

naslov elektronske pošte ni obvezen podatek v xml e-račun datoteki. V lokalni rešitvi se za kupca prebere iz matičnih podatkov kupca na osnovnem ekranu, za pošiljatelja pa iz matičnih podatkov šifre podjetja;

matični podatki, vezani na šifro podjetja;

vzdrževani morajo biti podatki naslova na šifri podjetja. KREIRANJE E-RAČUNA IN POŠILJANJE NA IZMENJEVALNO PODROČJE V osnovi je v osnovni rešitvi eDocument Frameworka zgolj nekaj podatkov o samem računu oz. dokumentu, ki je pripravljen za obdelavo v e-dokument. Taki dokumenti imajo, kot je prikazano na Sliki 12, v polju EDOC_GUID tabele EDOCUMENT oznako 'N/A', kar pomeni, da e-dokument še ni bil generiran in posledično tudi EDOC_GUID še ni bil generiran.

Slika 12: Prikaz seznama dokumentov brez GUID oznake

Z oznako posameznih vrstic in priklicem aktivnosti preko gumba »Kreiranje« se izvede generiranje e-računa v obliki e-SLOGA in hkrati pošiljanje e-dokumenta na vnaprej parametrizirano področje za izmenjavo. Ključni parametri in funkcijski moduli, ki so uporabljeni za izvedbo te aktivnosti, so:

FOLDER_ROOT,

FOLDER_TYP_APP_PC,

FM_FILENAME_POV,

ENV_CREATE,

FM_XML_INVOIC,

PDF_CREATE,



GUI_DOWNLOAD. Rešitev znotraj obdelave dokumenta glede na parametrizacijo preko parametra FOLDER_ROOT izbere privzeto izmenjevalno mapo za odlaganje končnega e-računa. Poleg tega se preveri parameter FOLDER_TYP_APP_PC, ki določa, ali se e-račun odlaga lokalno, na delovno postajo uporabnika ali pa na aplikacijski strežnik sistema. Potem se v funkcijskem modulu FM_FILENAME_POV poišče in generira ime povratnice za pravilno razpoznavo, s parametrom ENV_CREATE se kreira ovojnica, s funkcijskim modulom FM_XML_INVOIC sam XML dokument s podatki računa, kot priponka pa se preko PDF_CREATE pripne PDF oblika računa, ki se prav tako generira znotraj rešitve. Na koncu se datoteka odloži na določeno področje z uporabo funkcijskega modula GUI_DOWNLOAD. Slika 13 prikazuje primer kreiranega e-računa, ki po uspešnem kreiranju dobi GUID oznako v sami rešitvi.

Slika 13: Prikaz GUID oznake na kreiranem e-računu

Slika 14 prikazuje primer kreiranih in poslanih e-računov s statusom 'SENT':

Slika 14: Prikaz seznama poslanih e-računov

XML kreirane e-račune je možno v rešitvi eDocument Framework pregledovati. Z dvoklikom na posamezno vrstico seznama se nam odpre okno s strukturo XML, kot je prikazano na Sliki 15.



Slika 15: Prikaz pregleda XML strukture e-računa

POŠILJANJE E-RAČUNA NA IZMENJEVALNO PODROČJE Aktivnost pošiljanja e-računa izvaja zgolj pošiljanje že generiranega in pripravljenega e-računa z vsemi priponkami. Glavni parametri in funkcijski moduli, uporabljeni pri tej aktivnosti, so:

FOLDER_ROOT,

FOLDER_TYP_APP_PC,

FM_FILENAME_POV,

GUI_DOWNLOAD.



Aktivnost pošiljanja e-računa glede na parametrizacijo preko parametra FOLDER_ROOT izbere privzeto izmenjevalno mapo za odlaganje končnega e-računa. Poleg tega se preveri parameter FOLDER_TYP_APP_PC, ki določa, ali se e-račun odlaga lokalno, na delovno postajo uporabnika ali pa na aplikacijski strežnik sistema. Potem se v funkcijskem modulu FM_FILENAME_POV poišče in generira ime povratnice za pravilno razpoznavo. Funkcijski modul GUI_DOWNLOAD poskrbi, da se e-račun prenese na določeno izmenjevalno področje. PREVZEM POVRATNIC E-RAČUNOV IN OBDELAVA

FM_FILENAME_POV

FM_XML_POVRATNICA Aktivnost prevzemanja povratnic e-računov najprej preko funkcijskega modula FM_FILENAME_POV preveri poimenovanje in mapo za prevzem povratnic. Po prevzemu datoteke se preko funkcijskega modula FM_XML_POVRATNICA ažurira status v eDocument Framework entiteti PROC_STATUS tabele EDOCUMENT. Če je prejemnik potrdil prejem in pravilnost e-računa, se, kot je prikazano na Sliki 16, status nastavi na 'APPP', če pa je e-račun zavrnjen oz. ima napake, se status nastavi na 'REJC'.

Slika 16: Prikaz statusa po prevzemu povratnice



5 ZAKLJUČKI

5.1 OCENA UČINKOV Učinke izdelave rešitve za podporo izdajanju e-računov z našo programsko rešitvijo smo analizirali s SWOT (Strengths, Weaknesses, Opportunities, Threats) analizo. Slovenski izraz za SWOT je PSPN (prednosti, slabosti, priložnosti, nevarnosti), pri čemer gre za ugotavljanje prednosti in slabosti neke rešitve in pa ugotavljanje priložnosti za boljši izkoristek rešitve ter nevarnosti, do katerih lahko pride zaradi rešitve same. Odločili smo se za analizo pošiljanja računov delovanja sistema in procesa pred in po prenovi, kar je prikazano na slikah 17 in 18. ANALIZA PRED PRENOVO

Slika 17: SWOT-analiza sistema pred prenovo

Zgornja analiza procesa/sistema pred prenovo nam prikazuje, da je celoten proces izdaje računa kupcem potekal v sklopu prodajnega modula SAP ERP sistema. Uporaba sistema je bila posledično dokaj enostavna. Kot glavni slabosti se izpostavita avtomatizacija procesa izdaje računa in komunikacije s kupcem ter arhiviranje izdanih računov. Pošiljanje računov in prejemanje povratne informacije s strani kupcev je potekala v papirni obliki preko klasične pošte. To pomeni, da je bila komunikacija s kupci zamudna in je zahtevala veliko ročnega dela. Poleg tega je bilo treba za potrebe regulative imeti vzpostavljeno papirno arhivo vseh dokumentov, vezanih na izdajo računov, kar je



predstavljalo dodatno slabost, saj ni bilo zagotovljenega varnostnega kopiranja arhive dokumentov. Priložnosti na področju izdajanja računov je precej. V procesu fakturiranja se pojavlja veliko napak, ki rezultirajo v visokih stroških dela na strani dobavitelja in tudi kupca. Poleg tega niso zanemarljivi niti stroški pošte in materiala, ki sta potrebna v procesu fakturiranja. Iskanje dokumentov po arhivi je zamudno ročno delo ter zelo odvisno od organiziranosti in dostopnosti arhive. Glavna nevarnost obstoječega sistema je nezmožnost kvalitetnega poslovanja s proračunskimi porabniki, katerim po novi regulativi ne bo več možno pošiljati računov v papirni obliki. Poleg tega obstaja nevarnost izgube tudi katerega izmed ostalih neproračunskih kupcev, ki bodo zahtevali uvedbo e-poslovanja na področju izdajanja računov. Ne nazadnje pa je kritična tudi izguba arhiviranih podatkov, če ni zagotovljena hramba v varnih prostorih, kjer je zagotovljena protipožarna in protipoplavna varnost. ANALIZA PO PRENOVI

Slika 15: SWOT-analiza sistema po prenovi

Sama prenova procesa in sistema je sicer rezultirala v precejšnjem izboljšanju stanja na področju fakturiranja, vendar so ostale še številne možnosti za izboljšanje same rešitve. Proces po prenovi je veliko bolj učinkovit in pregleden. Učinki prenove so vidni predvsem na področju priprave podatkov in preglednosti procesa. Rešitev zmanjšuje možnost napak pri pripravi podatkov in omogoča elektronski prejem odgovora



kupca. Tako je komunikacija s kupcem precej bolj ažurna. Ker je zagotovljena revizijska sled, je celoten proces možno spremljati preko informacijskega sistema, kar omogoča precej izboljšano preglednost nad procesom. Učinki se kažejo tudi v zmanjšanju operativnih stroškov na področju procesa fakturiranja, kjer so se optimizirali stroški kadrov in materiala. Ker je rešitev izdelana v sklopu ločenega modula, ki ni v celoti integriran v vse procese, kateri so podprti v SAP ERP in so vezani na fakturiranje kupcem, se pojavljajo določene slabosti. Predvsem gre za tehnične slabosti na določenih delih procesa fakturiranja. V sklopu rešitve ni zagotovljeno avtomatično in uporabniku prijazno dodajanje priponk, ki v procesu nastanejo poleg samega računa. Določene slabosti so vezane tudi na samo strukturo e-SLOGA, ki za določene industrije (npr. gradbeno) ne predvideva pomembnih podatkov, zato se to rešuje s prilagajanjem in uporabo določenih drugih polj strukture za pošiljanje tovrstnih podatkov. Iz naslova e-poslovanja in rešitve, ki smo jo naredili, se pojavlja veliko priložnosti za nadaljnji razvoj. Predvsem je pomembno dejstvo, da smo z uvedbo e-računov na prodajnem delu povzročili zahtevo po uvedbi e-poslovanja tudi na strani prejetih računov. To je naslednji korak k digitalizaciji in uvedbi kompletnega elektronskega poslovanja v družbah in organizacijah. Naslednja pomembna priložnost je vzpostavitev klasifikacijskega načrta dokumentov v organizacijah in vzpostavitev elektronskega arhiva za vso dokumentacijo. Zaznana nevarnost pa je predvsem vezana na sami tehnični del rešitve, kajti le-ta je narejena v okolju SAP, kjer se trenutno izvaja veliko število razvojnih aktivnosti iz naslova potreb po e-poslovanju globalno. To pomeni, da se popravki modula objavljajo zelo pogosto. Z vsako nadgradnjo sistema se pojavi nevarnost, da bo potrebno izvesti določene prilagoditve rešitve, ki smo jo pripravili za Republiko Slovenijo.

5.2 POGOJI ZA UVEDBO V fazi priprave in razvoja rešitve smo se srečali s številnimi omejitvami. SAP ERP je rešitev, katera je v uporabi globalno in zato spreminjanje osnovnega, standardnega delovanja sistema ni priporočljivo. Spreminjanje standarda se zaradi same kompleksnosti vzdrževanja nanaša v večini na popravke znotraj obstoječih procesov in odpravo napak. Dopolnitve standardnega dela sistema zahtevajo daljši razvojni proces in globalno testiranje, zato v našem primeru to ni bilo primerno. Regulatorne spremembe po posameznih državah zahtevajo fleksibilen in zelo agilen pristop k razvoju novosti. Zato se regulatorne dopolnitve pri SAP rešuje ponavadi z razvojem ločenih modulov, kateri se potem nadgrajujejo glede na zahteve. Ta pristop pa včasih poveča kompleksnost in zmanjša homogenost samega sistema. V danih okoliščinah je bila narejena standardna rešitev, ki v osnovi zagotavlja kreiranje e-računa, ki je skladen z regulatornimi zahtevami v Republiki Sloveniji. Hkrati je narejeno ogrodje rešitve, ki posameznim uporabnikom omogoča nadaljnji razvoj rešitve glede na njihove zahteve, predvsem na področju komunikacije in avtomatizacije procesa izmenjave e-dokumentov ter na področju integracije z dokumentnimi sistemi za zagotavljanje arhiviranja e-dokumentov.



V fazi testiranja so sodelovala tri zelo velika slovenska podjetja, ki so sprva pričakovala veliko več avtomatizma od same rešitve. Skupaj smo optimizirali rešitev do te mere, da se je najbolj, kolikor je sploh možno, približala neki standardizaciji in določenim izjemam pri pripravi podatkov za e-račune.

5.3 MOŽNOSTI NADALJNJEGA RAZVOJA Rešitev je tehnično koncipirana tako, da že predvideva določene točke, kjer si uporabnik lahko sam nadgrajuje rešitev. Predvsem so pomembna področja:

avtomatizacija komunikacije in izmenjave podatkov,

arhiviranje,

obvladovanje priponk. Poleg zgoraj omenjenega razvoja vidimo priložnosti predvsem na področju vpeljave e-poslovanja tudi na ostalih procesih poslovanja ter s tem tudi nadgradnjo rešitve za potrebe vključitve novih procesov. Prvi primer se je zgodil že v fazi izdelave te rešitve, ko so uporabniki in njihovi partnerji zahtevali vpeljavo prejemanja e-računov v obliki e-SLOGA v sklopu naše rešitve.



LITERATURA IN VIRI

SAP AG (2012). ASAP 8 Methodology for Implementation. SAP.com. Pridobljeno 1. 8. 2016 na https://support.sap.com/support-programs-services/methodologies/implement-sap/asap-implementation.html SAP AG (2015). SAP ERP. SAP.com. Pridobljeno 10. 8. 2016 na http://go.sap.com/product/enterprise-management/erp.html G. Lakshmipathi, Jyoti Prakash (2014). SAP ERP Sales and Distribution (SAP SD). SAP.com. Pridobljeno 10. 9. 2016 na http://scn.sap.com/community/erp/sd SAP AG (2016). SAP NetWeaver by Key Capability. SAP.com. Pridobljeno 10. 8. 2016 na https://help.sap.com/saphelp_nw70/helpdata/en/6a/44b2420e71c511e10000000a1550b0/frameset.htm SAP Help (2016). SAP Process Integration. SAP.com. Pridobljeno 10. 8. 2016 na http://help.sap.com/nwpi SAP Help portal (2015). Connectivity. SAP.com. Pridobljeno 10. 8. 2016 na https://help.sap.com/saphelp_nw70ehp2/helpdata/en/70/f3cbad30ee479cb15672219f3405f0/content.htm

Uradni list RS (98/2004). Zakon o elektronskem poslovanju in elektronskem podpisu (ZEPEP-UPB1). Uradni-list.si. Pridobljeno 10. 9. 2016 na http://www.uradni-list.si/1/objava.jsp?urlid=200498&stevilka=4284 Uradni list RS (30/2006). Zakon o varstvu dokumentarnega in arhivskega gradiva ter arhivih (ZVDAGA). Uradni-list.si. Pridobljeno 10. 9. 2016 na https://www.uradni-list.si/1/content?id=72425 Uradni list RS (59/10 2010). Zakon o opravljanju plačilnih storitev za proračunske uporabnike (ZOPSPU). Pisrs.si. Pridobljeno 10. 9. 2016 na http://www.pisrs.si/Pis.web/pregledPredpisa?id=ZAKO5770 Uradni list RS (9/16 2016). Pravilnik o standardih in pogojih izmenjave elektronskih računov prek enotne vstopne in izstopne točke pri Upravi Republike Slovenije za javna plačila. Pisrs.si. Pridobljeno 10. 9. 2016 na http://www.pisrs.si/Pis.web/pregledPredpisa?id=PRAV10445

GZS (2012). Priporočila za uporabo standarda GZS e-SLOG 1.6 za enostavni račun. e-slog.gzs.si. Pridobljeno 10. 9. 2016 na https://e-slog.gzs.si/pripone/Prirocnik_ESLOG_1_6_verzija_2012_1_5.pdf

KAZALO SLIK Slika 1: Število zaposlenih po funkcijskih področjih 2 Slika 2: Metodologija SAP ASAP 5 Slika 3: Poslovni procesi v prodaji 9 Slika 4: Diagram arhitekture SAP Netweaverja 10 Slika 5: Pregled povezljivosti SAP PI 13

https://support.sap.com/support-programs-services/methodologies/implement-sap/asap-implementation.html

https://support.sap.com/support-programs-services/methodologies/implement-sap/asap-implementation.html

http://go.sap.com/product/enterprise-management/erp.html

http://scn.sap.com/community/erp/sd

https://help.sap.com/saphelp_nw70/helpdata/en/6a/44b2420e71c511e10000000a1550b0/frameset.htm

https://help.sap.com/saphelp_nw70/helpdata/en/6a/44b2420e71c511e10000000a1550b0/frameset.htm

http://help.sap.com/nwpi

http://www.uradni-list.si/1/objava.jsp?urlid=200498&stevilka=4284

https://www.uradni-list.si/1/content?id=72425

http://www.pisrs.si/Pis.web/pregledPredpisa?id=ZAKO5770

http://www.pisrs.si/Pis.web/pregledPredpisa?id=PRAV10445

http://e-slog.gzs.si/

https://e-slog.gzs.si/pripone/Prirocnik_ESLOG_1_6_verzija_2012_1_5.pdf



Slika 6: Primer tabele za predstavitev XML strukture 16 Slika 7: Diagram osnovnega procesa prodaje v SAP ERP 21 Slika 8: Izborni ekran programa EDOC_RESUBMIT_EDOCUMENT 26 Slika 9: Pregled dokumentov v programu EDOC_RESUBMIT_EDOCUMENT 26 Slika 10: Akcije, na voljo v osnovnem programu eDocument Framework 27 Slika 11: Prikaz vzdrževanega parametra FM_XML_ INVOIC 28 Slika 12: Prikaz seznama dokumentov brez GUID oznake 32 Slika 13: Prikaz GUID oznake na kreiranem e-računu 33 Slika 14: Prikaz seznama poslanih e-računov 33 Slika 15: Prikaz pregleda XML strukture e-računa 34 Slika 16: Prikaz statusa po prevzemu povratnice 35 Slika 17: SWOT-analiza sistema pred prenovo 36 Slika 18: SWOT-analiza sistema po prenovi 37

KAZALO TABEL Tabela 1: Legenda k tabeli za opis XML strukture 17 Tabela 2: Predstavitev tabele EDOCUMENT (potrebne entitete) 25 Tabela 3: Predstavitev tabele ZERAC_CUSTOMIZE (potrebne entitete) 28

POJMOVNIK SAP AG – podjetje, proizvajalec programske opreme ASAP – Accelerated SAP – projektna metodologija od SAP SAP ERP – Enterprise Resource Planning DMS – dokumentni sistem UJP – Uprava Republike Slovenije za javna plačila SD – Sales and Distribution – prodajni modul v SAP ERP sistemu FI – Finance – finančni modul v SAP ERP sistemu e-račun – račun v elektronski obliki e-poslovanje – elektronsko poslovanje EarlyWatch – analiza optimalnega delovanja SAP sistemov – nadzorni sistem Remote Upgrade – nadgradnja preko oddaljenega dostopa Kick Off – zagon projekta Business Blueprint – poslovni načrt GZS – Gospodarska zbornica Slovenije QA – Quality assurance – zagotavljanje kakovosti API – aplikacijski programski vmesnik XML – je tričrkovna okrajšava za angleški izraz Extensible Markup Language ASCII – kratica za angleško American Standard Code for Information Interchange BAPI – Business Application Programming Interface JAVA – programski jezik ABAP – programski jezik za SAP SAP PI – Process Integration – sistem za integracijo procesov WSDL – Web Services Description Language je na XML temelječ vmesnik za definicijo spletnih storitev ZZI – podjetje v Sloveniji SWOT – Strengths, Weaknesses, Opportunities, Threats metodologija za analizo poslovanja DMS – Document Management System



PRILOGE Priloga 1: Primer programske kode iz funkcijskega modula FUNCTION z_eracuni_gen_xml_ovojnica.

*"----------------------------------------------------------------------

*"*"Local Interface:

*" IMPORTING

*" VALUE(LS_SD_INVOICE) TYPE EDOC_SRC_DATA_SD_INVOICE OPTIONAL

*" VALUE(LS_FI_INVOICE) TYPE EDOC_SRC_DATA_FI_INVOICE OPTIONAL

*" REFERENCE(SOURCE_TYPE) TYPE EDOC_SOURCE_TYPE

*" REFERENCE(DIR_OUT_PDF) TYPE CHAR300

*" REFERENCE(DIR_OUT_XML_RA) TYPE CHAR300

*" REFERENCE(DIR_OUT_XML_ENV) TYPE CHAR300

*" EXPORTING

*" VALUE(XML_OVOJNICA) TYPE XSTRING

*" TABLES

*" TAB_PDFS TYPE XSTRING_TABLE

*"----------------------------------------------------------------------

*******************************************************

FREE ls_request_o.

CASE source_type.

WHEN 'SD_INVOICE'.

* SENDER

FREE t_address[].

CLEAR l_address.

CLEAR wa_t001. CLEAR wa_adrc.

SELECT SINGLE * FROM t001 INTO wa_t001 WHERE bukrs = ls_sd_invoice-

document_header-bukrs .

SELECT SINGLE * FROM adrc INTO wa_adrc WHERE addrnumber = wa_t001-

adrnr.

SELECT SINGLE * FROM adr6 INTO wa_adr6 WHERE addrnumber = wa_t001-

adrnr.

CONCATENATE wa_adrc-name1 wa_adrc-name2 INTO ls_request_o-sender-

name SEPARATED BY space.

ls_request_o-sender-country = wa_adrc-country.

IF NOT wa_adrc-tel_number IS INITIAL.

ls_request_o-sender-phone = wa_adrc-

tel_number.

ELSE.

ls_request_o-sender-

phone = '999999999'.

ENDIF.

IF NOT wa_adr6-smtp_addr IS INITIAL.

ls_request_o-sender-email_id = wa_adr6-

smtp_addr.

ELSE.

ls_request_o-sender-

email_id = 'ni@email_naslo.va'.

ENDIF.

CLEAR l_address.

CONCATENATE wa_adrc-street wa_adrc-

house_num1 INTO l_address SEPARATED BY space.

APPEND l_address TO t_address.

CLEAR l_address.

l_address = wa_adrc-city1.


FREE ls_request_o-sender-address[].

ls_request_o-sender-address[] = t_address[].

CLEAR l_address.



FREE t_address[].

ls_request_o-sender-sender_identifier = wa_t001-stceg.

SELECT SINGLE zvalue2 INTO f_bic FROM zerac_customize

WHERE zparameter = 'BIC_H_BANKE'

AND zvalue1 = ls_sd_invoice-document_header-bukrs.

ls_request_o-sender-sender_eddress-

sender_agent = f_bic.

SELECT SINGLE zvalue2 INTO f_stevilka_racuna FROM zerac_customize

WHERE zparameter = 'HISNA_BANKA'


IF NOT f_stevilka_racuna IS INITIAL.


sender_mailbox = f_stevilka_racuna.

ELSE.


sender_mailbox = 'SI56000000000000000'.

ENDIF.

** PAYEMENT_DATA - Creditor

ls_request_o-payment_data-payment_method = '0'.

ls_request_o-payment_data-creditor-name = ls_request_o-sender-

name.

ls_request_o-payment_data-creditor-country = ls_request_o-sender-

country.

ls_request_o-payment_data-creditor-address[] = ls_request_o-sender-

address[].

* ls_request_o-payment_data-creditor-creditor_agent = ls_request_o-

sender-sender_eddress-sender_agent.

CLEAR f_bic.


WHERE zparameter = 'BIC_H_BANKE_REAL'


IF NOT f_bic IS INITIAL.

ls_request_o-payment_data-creditor-creditor_agent = f_bic.

ELSE.

ls_request_o-payment_data-creditor-creditor_agent = 'UJP00000000'.

ENDIF.

ls_request_o-payment_data-creditor-creditor_account = ls_request_o-

sender-sender_eddress-sender_mailbox.

** RECEIVER

CLEAR l_address.

FREE t_address[].

CLEAR wa_partner.

CLEAR wa_kna1.

CLEAR wa_knbk.

CLEAR wa_bnka.

READ TABLE ls_sd_invoice-

partner_data INTO wa_partner WITH KEY parvw = 'RG'.

SELECT SINGLE * FROM kna1 INTO wa_kna1 WHERE kunnr = wa_partner-kunnr.

CLEAR l_address.

CONCATENATE wa_kna1-name1 wa_kna1-name2 INTO ls_request_o-receiver-

name.

ls_request_o-receiver-country = wa_kna1-

land1.

l_address = wa_kna1-

stras.


CLEAR l_address.


ort01.




ls_request_o-receiver-address[] = t_address[].

CLEAR l_address.

FREE t_address[].

IF wa_kna1-stceg IS NOT INITIAL.

ls_request_o-receiver-receiver_identifier = wa_kna1-

stceg.

ELSE.


stcd1.

ENDIF.

IF NOT wa_kna1-telf1 IS INITIAL.

ls_request_o-receiver-

phone = wa_kna1-telf1.

ELSE.


phone = '999999999'.

ENDIF.

CLEAR wa_adr6.

SELECT SINGLE * FROM adr6 INTO wa_adr6 WHERE addrnumber = wa_kna1-

adrnr.

IF NOT wa_adr6-smtp_addr IS INITIAL.


email_id = wa_adr6-smtp_addr.

ELSE.


email_id = 'ni@email_naslo.va'.

ENDIF.

SELECT COUNT( * ) INTO count FROM knbk WHERE kunnr = wa_partner-kunnr.

IF count > 1.

SELECT SINGLE * FROM knbk INTO wa_knbk WHERE kunnr = wa_partner-

kunnr

AND bkref = 'SIER'.

ELSEIF count = 1.

SELECT SINGLE * FROM knbk INTO wa_knbk WHERE kunnr = wa_partner-

kunnr.

ENDIF.

SELECT SINGLE iban INTO f_iban FROM tiban WHERE banks = wa_knbk-banks

AND bankl = wa_knbk-bankl

AND bankn = wa_knbk-bankn

AND bkont = wa_knbk-bkont.

IF NOT f_iban IS INITIAL.

ls_request_o-receiver-receiver_eddress-receiver_mailbox = f_iban.

ELSE.

ls_request_o-receiver-receiver_eddress-

receiver_mailbox = 'SI56000000000000000'.

ENDIF.

IF wa_kna1-stcd4 IS NOT INITIAL.

SELECT SINGLE zvalue1 INTO f_BIC FROM zerac_customize

WHERE zparameter = 'BIC_UJP'.

ls_request_o-receiver-receiver_eddress-receiver_agent = f_bic.

ELSE.

SELECT SINGLE * FROM bnka INTO wa_bnka WHERE banks = wa_knbk-banks

AND bankl = wa_knbk-bankl.

m_len = 0.

m_len = strlen( wa_bnka-swift ).

IF m_len = 8.

CONCATENATE wa_bnka-swift

'XXX'

INTO ls_request_o-receiver-receiver_eddress-receiver_agent.

ELSE.

ls_request_o-receiver-receiver_eddress-receiver_agent = wa_bnka-

swift.



ENDIF.

ENDIF.

* PAYEMENT_DATA - Debitor

ls_request_o-payment_data-debtor-name = ls_request_o-

receiver-name.

ls_request_o-payment_data-debtor-country = ls_request_o-

receiver-country.

ls_request_o-payment_data-debtor-address[] = ls_request_o-

receiver-address[].

CLEAR l_address.

FREE t_address[].

*

CLEAR wa_bnka.



m_len = 0.


IF m_len = 8.


'XXX'

INTO ls_request_o-payment_data-debtor-debtor_agent.

ELSE.

ls_request_o-payment_data-debtor-debtor_agent = wa_bnka-swift.

ENDIF.

IF ls_request_o-payment_data-debtor-debtor_agent IS INITIAL.

ls_request_o-payment_data-debtor-debtor_agent = 'UJP00000000'.

ENDIF.

* ls_request_o-payment_data-debtor-debtor_agent = ls_request_o-

receiver-receiver_eddress-receiver_agent.

ls_request_o-payment_data-debtor-debtor_account = ls_request_o-

receiver-receiver_eddress-receiver_mailbox.

* DOC_DATA

ls_request_o-doc_data-doc_type = '0002'.

ls_request_o-doc_data-doc_type_ver = '01'.

ls_request_o-doc_data-doc_id = ls_sd_invoice-

document_header-vbeln.

ls_request_o-doc_data-external_doc_id = ls_sd_invoice-

document_header-vbeln.

* ls_request_o-doc_data-external_doc_id = '1'.

CALL FUNCTION 'BKK_CHANGE_TO_TIMESTAMP'

EXPORTING

datlo_iv = sy-datum

timlo_iv = sy-uzeit

tzone_iv = sy-zonlo

IMPORTING

timestamp_ev = ls_request_o-doc_data-timestamp.

* Rok plačila

CALL FUNCTION 'J_1A_SD_CI_DUEDATE_GET'

EXPORTING

iv_vbeln = ls_sd_invoice-document_header-vbeln

iv_zterm = ls_sd_invoice-document_header-zterm

iv_ratnr = 01

IMPORTING

ev_netdate = f_datum_placila.

ls_request_o-payment_data-requested_execution_date = f_datum_placila.

ls_request_o-payment_data-amount = ls_sd_invoice-document_header-

netwr +

ls_sd_invoice-document_header-

mwsbk.



ls_request_o-payment_data-currency = ls_sd_invoice-document_header-

waerk.

* sklic

if not ls_sd_invoice-document_header-kidno is initial.

ls_request_o-payment_data-remittance_information-

creditor_structured_reference =

ls_sd_invoice-document_header-

kidno. " Sklic za plačilo

else.

CONCATENATE 'SI00' ls_sd_invoice-document_header-vbeln INTO


creditor_structured_reference.

endif.


additional_remittance_informat = 'Plačilo računa'.

SELECT SINGLE zvalue1 INTO ls_request_o-payment_data-

purpose FROM zerac_customize

WHERE zparameter = 'KODA_NAMENA'.

* attachments

FREE t_attachment[].

CLEAR l_attachment.

clear wa_zerac_customize.

SELECT SINGLE * INTO wa_zerac_customize FROM zerac_customize WHERE zpa

rameter = 'FILENAME_XML_RAC'.

IF sy-subrc = 0.

CONCATENATE

ls_sd_invoice-document_header-vbeln

wa_zerac_customize-zvalue1

INTO

l_attachment-filename.

else.

CONCATENATE


'_Enostavni_Racun.xml'

INTO


endif.

l_attachment-type = 'xml'.

l_attachment-description = 'Racun v e-Slog XML obliki'.

APPEND l_attachment TO t_attachment.

SELECT SINGLE * FROM zerac_customize INTO wa_customize WHERE zparamete

r = 'PDF_CREATE'.

IF wa_customize-zvalue1 = 'X'.


SELECT SINGLE * INTO wa_zerac_customize FROM zerac_customize WHERE z

parameter = 'FILENAME_PDF'.

IF sy-subrc = 0.

CONCATENATE



INTO


filename_pdf_tmp_org = l_attachment-filename.

loop at tab_pdfs INTO wa_pdfs.

filename_pdf_tmp = filename_pdf_tmp_org.

stev = sy-tabix.

if stev = 1.

l_attachment-type = 'pdf'.

l_attachment-description = 'Racun v PDF obliki'.

else.

CONDENSE stev NO-GAPS.

CONCATENATE '_'

stev



'.pdf'

into stev_ext.

REPLACE '.pdf' WITH stev_ext INTO filename_pdf_tmp.

l_attachment-filename = filename_pdf_tmp.


l_attachment-description = 'Priponka v PDF obliki'.

endif.


ls_request_o-attachments-count = ls_request_o-attachments-

count + 1.

endloop.


count + 1..

else.

CONCATENATE


'_Enostavni_Racun.pdf'

INTO





stev = sy-tabix.

if stev = 1.



else.


CONCATENATE '_'

stev

'.pdf'

into stev_ext.





endif.



count + 1.

endloop.


count + 1..

endif.

ELSE.

ls_request_o-attachments-count = '1'.

ENDIF.

FREE ls_request_o-attachments-attachment[].

ls_request_o-attachments-attachment[] = t_attachment[].

WHEN 'FI_INVOICE'.

* SENDER

break mzal.

CLEAR wa_t001. CLEAR wa_adrc.

FREE t_address.

SELECT SINGLE * FROM t001 INTO wa_t001 WHERE bukrs = ls_fi_invoice-

document_header-bukrs .

SELECT SINGLE * FROM adrc INTO wa_adrc WHERE addrnumber = wa_t001-

adrnr.

CONCATENATE wa_adrc-name1 wa_adrc-name2 INTO ls_request_o-sender-

name SEPARATED BY space.

ls_request_o-sender-country = wa_adrc-country.

CLEAR l_address.

CONCATENATE wa_adrc-street wa_adrc-



house_num1 INTO l_address SEPARATED BY space.


CLEAR l_address.

l_address = wa_adrc-city1.


ls_request_o-sender-address[] = t_address[].

CLEAR l_address.

FREE t_address[].

ls_request_o-sender-sender_identifier = wa_t001-stceg.


WHERE zparameter = 'BIC_H_BANKE'

AND zvalue1 = ls_fi_invoice-document_header-bukrs.


sender_agent = f_bic.

SELECT SINGLE zvalue2 INTO f_stevilka_racuna FROM zerac_customize

WHERE zparameter = 'HISNA_BANKA'

AND zvalue1 = ls_fi_invoice-document_header-bukrs.


sender_mailbox = f_stevilka_racuna.

** PAYEMENT_DATA - Creditor

*

ls_request_o-payment_data-payment_method = '0'.

ls_request_o-payment_data-creditor-name = ls_request_o-sender-

name.

ls_request_o-payment_data-creditor-country = ls_request_o-sender-

country.

ls_request_o-payment_data-creditor-address[] = ls_request_o-sender-

address[].

CLEAR l_address.

FREE t_address[].

CLEAR f_bic.


WHERE zparameter = 'BIC_H_BANKE_REAL'


IF NOT f_bic IS INITIAL.

ls_request_o-payment_data-creditor-creditor_agent = f_bic.

ELSE.

ls_request_o-payment_data-creditor-creditor_agent = 'UJP00000000'.

ENDIF.

* ls_request_o-payment_data-creditor-creditor_agent = ls_request_o-

sender-sender_eddress-sender_agent.

ls_request_o-payment_data-creditor-creditor_account = ls_request_o-

sender-sender_eddress-sender_mailbox.

** RECEIVER

CLEAR wa_kna1.

CLEAR wa_knbk.

CLEAR wa_bnka.

LOOP AT tab_fi_items INTO wa_fi_items WHERE bschl = '01'.

ENDLOOP.

SELECT SINGLE * FROM kna1 INTO wa_kna1 WHERE kunnr = wa_fi_items-

kunnr.

CLEAR l_address.

CONCATENATE wa_kna1-name1 wa_kna1-name2 INTO ls_request_o-receiver-

name.

ls_request_o-receiver-country = wa_kna1-

land1.


stras.




CLEAR l_address.


ort01.


ls_request_o-receiver-address[] = t_address[].

CLEAR l_address.

FREE t_address[].

IF wa_kna1-stceg IS NOT INITIAL.


stceg.

ELSE.


stcd1.

ENDIF.

ls_request_o-receiver-phone = wa_kna1-

telf1.

SELECT COUNT( * ) INTO count FROM knbk WHERE kunnr = wa_fi_items-

kunnr.

IF count > 1.

SELECT SINGLE * FROM knbk INTO wa_knbk WHERE kunnr = wa_fi_items-

kunnr

AND bkref = 'SIER'.

ELSEIF count = 1.

SELECT SINGLE * FROM knbk INTO wa_knbk WHERE kunnr = wa_fi_items-

kunnr.

ENDIF.

SELECT SINGLE iban INTO f_iban FROM tiban WHERE banks = wa_knbk-banks

AND bankl = wa_knbk-bankl

AND bankn = wa_knbk-bankn

AND bkont = wa_knbk-bkont.

ls_request_o-receiver-receiver_eddress-receiver_mailbox = f_iban.

IF wa_kna1-stcd4 IS NOT INITIAL.

SELECT SINGLE zvalue1 INTO f_BIC FROM zerac_customize

WHERE zparameter = 'BIC_UJP'.

ls_request_o-receiver-receiver_eddress-receiver_agent = f_bic.

ELSE.



m_len = 0.


IF m_len = 8.


'XXX'

INTO ls_request_o-receiver-receiver_eddress-receiver_agent.

ELSE.

ls_request_o-receiver-receiver_eddress-receiver_agent = wa_bnka-

swift.

ENDIF.

ENDIF.

* PAYEMENT_DATA - Debitor

ls_request_o-payment_data-debtor-name = ls_request_o-

receiver-name.

ls_request_o-payment_data-debtor-country = ls_request_o-

receiver-country.

ls_request_o-payment_data-debtor-address[] = ls_request_o-

receiver-address[].

CLEAR l_address.

FREE t_address[].

*

CLEAR wa_bnka.



m_len = 0.




IF m_len = 8.


'XXX'

INTO ls_request_o-payment_data-debtor-debtor_agent.

ELSE.

ls_request_o-payment_data-debtor-debtor_agent = wa_bnka-swift.

ENDIF.

IF ls_request_o-payment_data-debtor-debtor_agent IS INITIAL.

ls_request_o-payment_data-debtor-debtor_agent = 'UJP00000000'.

ENDIF.

ls_request_o-payment_data-debtor-debtor_account = ls_request_o-

receiver-receiver_eddress-receiver_mailbox.

* DOC_DATA

ls_request_o-doc_data-doc_type = '0002'.

ls_request_o-doc_data-doc_type_ver = '01'.

CONCATENATE ls_fi_invoice-document_header-belnr ls_fi_invoice-

document_header-gjahr

INTO ls_request_o-doc_data-doc_id.

CONCATENATE ls_fi_invoice-document_header-belnr ls_fi_invoice-

document_header-gjahr

INTO ls_request_o-doc_data-external_doc_id.

* ls_request_o-doc_data-external_doc_id = '1'.

CALL FUNCTION 'BKK_CHANGE_TO_TIMESTAMP'

EXPORTING

datlo_iv = sy-datum

timlo_iv = sy-uzeit

tzone_iv = sy-zonlo

IMPORTING

timestamp_ev = ls_request_o-doc_data-timestamp.

* Rok plačila

CLEAR f_faedt.

CALL FUNCTION 'NET_DUE_DATE_GET'

EXPORTING

i_zfbdt = wa_fi_items-zfbdt

i_zbd1t = wa_fi_items-zbd1t



i_shkzg = wa_fi_items-shkzg

i_rebzg = wa_fi_items-belnr

i_koart = wa_fi_items-koart

IMPORTING

e_faedt = f_faedt.

CLEAR lv_timestamp_date.

CONVERT DATE f_faedt TIME lv_time

INTO TIME STAMP lv_timestamp_date TIME ZONE lv_tzone.

ls_request_o-payment_data-

requested_execution_date = lv_timestamp_date.

ls_request_o-payment_data-amount = wa_fi_items-dmbtr.

ls_request_o-payment_data-currency = ls_fi_invoice-document_header-

waers.

* sklic

IF NOT wa_fi_items-kidno IS INITIAL.


creditor_structured_reference

= wa_fi_items-kidno. " Sklic za plačilo

ELSE.



CONCATENATE 'SI00' ls_fi_invoice-document_header-belnr INTO


creditor_structured_reference.

ENDIF.

SELECT SINGLE vtext INTO ls_request_o-payment_data-

remittance_information-additional_remittance_informat

FROM tvzbt

WHERE spras = wa_kna1-spras

AND zterm = wa_fi_items-zterm.

SELECT SINGLE zvalue1 INTO ls_request_o-payment_data-

purpose FROM zerac_customize

WHERE zparameter = 'KODA_NAMENA_FI'.

* attachments

FREE t_attachment[].

CLEAR l_attachment.


SELECT SINGLE * INTO wa_zerac_customize FROM zerac_customize WHERE zpa

rameter = 'FILENAME_XML_RAC'.

IF sy-subrc = 0.

CONCATENATE

ls_fi_invoice-document_header-belnr


INTO


else.

CONCATENATE


'_Enostavni_Racun.xml'

INTO


endif.

l_attachment-type = 'xml'.

l_attachment-description = 'Racun v e-Slog XML obliki'.


CLEAR l_attachment.

SELECT SINGLE * FROM zerac_customize INTO wa_customize WHERE zparamete

r = 'PDF_CREATE_FI'.

IF wa_customize-zvalue1 = 'X'.


SELECT SINGLE * INTO wa_zerac_customize FROM zerac_customize WHERE z

parameter = 'FILENAME_PDF'.

IF sy-subrc = 0.

CONCATENATE



INTO




stev = sy-tabix.


if stev = 1.



else.


CONCATENATE '_'

stev

'.pdf'

into stev_ext.







endif.



count + 1.

endloop.


count + 1..

else.

CONCATENATE


'_Enostavni_Racun.pdf'

INTO





stev = sy-tabix.

if stev = 1.



else.


CONCATENATE '_'

stev

'.pdf'

into stev_ext.





endif.



count + 1.

endloop.


count + 1..

endif.

ELSE.

ls_request_o-attachments-count = '1'.

ENDIF.

FREE ls_request_o-attachments-attachment[].

ls_request_o-attachments-attachment[] = t_attachment[].

* mapping for envelope.

ENDCASE.

CALL TRANSFORMATION zeracun_ovojnica

SOURCE envelope = ls_request_o

RESULT XML xml_result.

xml_ovojnica = xml_result.

ENDFUNCTION.

lokalizirana podpora procesu izdaje e …ariba network: sourcing, procurement, & finance,...

Documents