Univerzitet u Beogradu
Fakultet organizacionih nauka
Slobodan N. Babić
Model interoperabilnog elektronskog poslovanja
platnih sistema zasnovanih na ontologijama
doktorska disertacija
Beograd, 2013.
UNIVERSITY OF BELGRADE
FACULTY OF ORGANIZATIONAL SCIENCES
Slobodan N. Babić
The model of interoperable electronic
Business of payments systems founded on
ontologies
doctoral dissertation
Belgrade, 2013
Mentor:
dr Marijana Despotović-Zrakić,
Vanredni profesor,
Univerzitet u Beogradu, Fakultet organizacionih nauka
Članovi komisije:
dr Božidar Radenković,
Redovni profesor,
Univerzitet u Beogradu, Fakultet organizacionih nauka
dr Milorad Stanojević,
Redovni profesor,
Univerzitet u Beogradu, Saobraćajni fakultet
Datum odbrane: ________________
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Model interoperabilnog elektronskog poslovanja platnih sistema
zasnovanih na ontologijama
APSTRAKT: Predmet ove disertacije je razvoj i primena modela interoperabilnog
elektronskog poslovanja platnih sistema zasnovanog na ontologijama i Resource-Event-
Agent - REA (ISO/IEC 15944-4:2007) ontološkoj objektnoj strukturi sistema.
Istraživanje je bazirano na globalnim poslovnim standardima finansijske industrije -
referentnim modelima za razmenu informacija. Saznanja iz implementacije sistema za
kliring čekova i sistema za direktno zaduženje u Udruženju banaka Srbije koji su
realizovani korišćenjem obrazaca za poslovnu integraciju (EIP - Enterprise Integration
Patterns) i standardizovanih sistema poruka primenjena su u istraživanju. Istraživanje
je prilagođeno i za implementaciju interoperabilnih platnih sistema u Srbiji.
Različiti platni sistemi u procesu elektronskog poslovanja su u interakciji sa različitim
poslovnim sistemima učesnika. Poslovni sistemi učesnika podržavaju veliki broj
korisnika i poslovnih procesa sa specifičnim zahtevima. Osnovni problem je
heterogenost između poslovnih procesa, podataka i korišćenih IT tehnologija. Iz tog
razloga vreme, finansijska sredstva i informatički resursi se troše na prevođenje
podataka iz jednog sistema u drugi. Razmena finansijskih transakcija elektronskim
putem postala je prevladavajuća. Time nastaje potreba za razvojem modela
interoperabilnog elektronskog poslovanja platnog sistema za razmenu finansijskih
transakcija i njihovu obradu. Standardizacija u domenu modeliranja platnih sistema,
koja će biti razmatrana, treba da doprinese i većoj efikasnosti ostalih sistema
elektronskog poslovanja i interoperabilnosti elektronskog poslovanja učesnika.
U svakoj državi platni sistem se sastoji od skupa platnih instrumenata, bankarskih
procedura i sistema za prenos sredstava između finansijskih institucija u cilju
obezbeđivanja cirkulacije novca. Centralna banka neposredno definiše, reguliše i
usmerava tokove novca i ispunjava svoju osnovnu funkciju regulatora finansijskih
tokova putem kontrole platnih sistema. Najvažniji je Real Time Gross Settlement System
- RTGS, sa kojim su hijerarhijski povezani sistemi banaka i drugih finansijskih
institucija, pravnih i fizičkih lica. Među njima su klirinške kuće, agenti, procesorske
kuće i zakonom definisane institucije koje se bave izvršenjem, procesiranjem,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
akvizicijom ili distribucijom informacija o finansijskim transakcijama, ali i drugi
sistemi elektronskog poslovanja. Platni sistemi, na način opisan u ovom radu,
objedinjuju elemente koji figurišu u svakom sistemu baziranom na porukama,
tehnološke elemente nadređenih institucija koji su implicirani standardnim formatom
poruka, ambijentalne uslove zadate mestom na kome se platni sistem ostvaruje (mesto u
finansijskoj vertikali, vrsti procesiranja za koje je opredeljen, geopolitičkoj topologiji i
drugim mogućim elementima), potrebnoj komunikacionoj interakciji, neophodnim
informacionim tehnologijama za realizaciju pojedinačnih i opštih zadataka.
Ontologije kao formalni opis objekata, njihovih osobina i odnosa u određenom domenu
eksplicitno su razumljive i za čoveka i za računar. U ovom radu ontološkim pristupom
se postiže interoperabilnost i konzistentnost u modelu i obogaćuje dizajn modela sa
domena znanja. Standard ISO 15944-4:2007, koji je razmatran u rešenju, definiše
ontološko okruženje za specifikaciju koncepata i relacija uključenih u poslovne
transakcije i scenarije nazvane Resource-Event-Agent - REA ontologijom. Model je
primenjen u konkretnom poslovnom okruženju.
Ključne reči: sistemi zasnovani na porukama, interoperabilnost, elektronsko
poslovanje, platni sistemi.
Naučna oblast: Internet tehnologije.
Uža naučna oblast: Elektronsko poslovanje.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
The model of interoperable electronic Business of payments systems
founded on ontologies
ABSTRACT: The subject of this dissertation is development and application of the
model of interoperable e-Business of payment systems based on ontologies and
Resource-Event-Agent - REA (ISO/IEC 15944-4:2007) ontological object system
structure. Referential models in the information exchange upon global business
standards of financial industry are basis for this investigation. It will apply the
experience and knowledge from the implementation of the Check Clearing and Direct
Debit systems within the Association of Serbian Banks, created by the use of Enterprise
Integration Patterns (EIP) and the standardized systems of messages. The investigation
will be adjusted to the implementation of interoperable payment systems in Serbia.
Various payment systems in the process of electronic transaction interact with various
participants′ business systems. Participants’ business systems support a great number
of users and business processes with specific requirements. In this, the basic problem is
dissimilarity between business processes, data and IT technologies. From that reason,
time, financial, and informatics resources are wasted on the data transfer from one to
another system. Today, the exchange of financial transactions electronically became
predominant. This calls for the development of models of interoperable e-Business of
payment systems for the exchange of financial transactions and their processing. The
standardization in the domain of payment system modeling, considered in this study
should contribute to greater efficiency of other electronic business systems and to
interoperability of participants’ electronic businesses.
In every country payment system comprises a number of payment instruments, banking
procedures, and the systems for the fund transfer between financial institutions. That
alowws the circulation of money in the country. The Central Bank directly defines,
regulates and directs the money flow, and fulfills the function of the regulator of
financial flows through the control of the payment systems. The most important is Real
Time Gross Settlement System - RTGS, which for the mentioned reasons, is mainly
under the supervision of Central Bank. Banks′ systems and the systems of other
financial institutions are connecting by RTGS System. Among them there are
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
institutions like clearing houses, payment agents, processing houses, and other. They
are defined by law, deals with implementation, processing, information acquisition, or
distribution regarding financial transactions, as well as other systems of electronic
business. Payment systems, on the wyu described in this work, unify the elements,
existent in every system based on messages, technological elements of supervising
institutions, implicated by the standard message format, ambient conditions imposed by
the place with the implemented payment system (in financial vertical, with kind of
processing for which it is committed, geo-political typology, and other possible
elements), required communicational interaction, information technologies necessary
for realization of general and specific tasks.
Being formal descriptions of objects, their characteristics and relationships in a
particular domain, ontologies are explicitly understandable for man and computer. In
this work, the ontological approach grants interoperability and consistency in model
and enriches the design of the model from the domain of knowledge. Standard ISO
15944-4:2007, which will be considered in this study, defines ontological background
for the specification of the concepts and relations included in the business transactions
and scenarios known as Resource-Event-Agent – REA ontology.
Key words: Message based systems, interoperability, electronic business, payment
systems.
Scientific area: Internet Technologies.
Field of Scientific area: Е-Business.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
SADRŽAJ
1 Uvod ......................................................................................................................... 1
1.1 Definisanje predmeta istraživanja .................................................................... 1
1.2 Ciljevi istraživanja ............................................................................................ 3
1.3 Polazne hipoteze ............................................................................................... 4
1.4 Metodologija istraživanja ................................................................................. 4
1.5 Struktura i organizacija rada ............................................................................. 5
2 Elektronsko poslovanje ............................................................................................ 7
2.1 Definicija elektronskog poslovanja .................................................................. 7
2.1.1 Prednosti elektronskog poslovanja ............................................................... 8
2.2 Komponente sistema elektronskog poslovanja................................................. 9
2.3 Okruženje i infrastruktura elektronskog poslovanja ........................................ 11
2.3.1 Tehnološki progres kao osnova razvoja elektronskog poslovanja ............... 11
2.3.2 Uticaj razvoja informacionih tehnologija na elektronsko poslovanje ........ 12
2.3.3 Uticaj razvoja elektronskog poslovanja na poslovanje............................... 13
2.3.4 Zakonodavni okvir elektronskog poslovanja .............................................. 14
2.3.5 Okruženje za uvođenje elektronskog poslovanja u preduzeća ................... 16
2.3.6 Elektronsko poslovanje platnih sistema u svetu i kod nas ......................... 19
2.4 Globalni standardi elektronskog poslovanja................................................... 20
2.4.1 Standardizacija informacionih tehnologija ................................................. 21
2.4.2 Standardizacija elektronskog poslovanja .................................................... 25
2.4.3 Standardizacija elektronskog poslovanja platnih sistema .......................... 26
2.4.4 Ograničenja standardizacije ........................................................................ 27
2.5 Koncept interoperabilnosti ............................................................................. 28
2.6 SOA i organizacije za standardizaciju elektronskog poslovanja .................... 33
2.7 Sigurnost elektronskog poslovanja ................................................................. 37
2.7.1 Sigurnost i interoperabilnost ....................................................................... 38
2.7.2 Model zaštite resursa .................................................................................. 39
3 Platni sistemi .......................................................................................................... 41
3.1 Osnovni pojmovi i definicije .......................................................................... 42
3.1.1 Sistemi procesorskih kuća .......................................................................... 45
3.1.2 Platni sistemi banaka i drugih finansijskih organizacija ............................ 47
3.1.3 Multikanalni sistemi za plaćanja pravna i fizičkih lica .............................. 50
3.2 Standardi platnih sistema ................................................................................ 51
3.2.1 EDIFACT standard ..................................................................................... 53
3.2.2 SWIFT i privatne mreže za razmenu poruka .............................................. 55
3.2.3 Standardi ISO15022 i ISO20022 ................................................................ 59
3.2.4 Standardi Banke za međunarodna poravnanja ............................................ 62
3.2.5 Zakonski okvir za procesorske kuće u Srbiji .............................................. 63
3.2.6 Usaglašavanje Srbije sa Evropskom unijom .............................................. 64
3.3 Primeri platnih sistema ................................................................................... 64
3.4 Platni sistemi u svetu ...................................................................................... 64
3.4.1 Platni sistemi u državama zapadnog Balkana............................................. 68
3.4.2 Platni sistemi u Srbiji .................................................................................. 74
4 Infrastruktura elektronskog poslovanja platnih sistema ......................................... 81
4.1 Internet tehnologije ......................................................................................... 81
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
4.1.1 Komunikacioni protokoli na internetu ........................................................ 81
4.1.2 XML tehnologije ........................................................................................ 84
4.2 Metod i paradigme za razvoj informacionih sistema...................................... 96
4.2.1 Strukturalne metodologije .......................................................................... 99
4.2.2 Objektne metodologije ............................................................................. 103
4.2.3 Dynamic systems development method ................................................... 107
4.2.4 Extreme programing ................................................................................. 108
4.3 Servisno orijentisana arhitektura ................................................................... 110
4.3.1 SOA - osnovna obeležja ............................................................................ 110
4.3.2 SOA - arhitektura ....................................................................................... 113
4.3.3 SOA - prednosti i nedostaci ....................................................................... 114
4.3.4 SOA - tehnologije za realizaciju ................................................................ 114
4.3.5 Veb servis kao tehnološka infrastruktura SOA .......................................... 115
4.4 Veb servisi ..................................................................................................... 118
4.4.1 Arhitektura veb servisa .............................................................................. 119
4.4.2 Sigurnost informacionih sistema zasnovanih na SOA i veb servisima .... 121
4.4.3 Međusobno povezivanje veb servisa ........................................................ 129
4.5 Semantički veb ............................................................................................. 133
4.5.1 Ontologije ................................................................................................. 134
4.5.2 Primena ontologija u integraciji sistema .................................................. 138
5 Razvoj modela interoperabilnog elektronskog poslovanja platnih sistema
zasnovanog na ontologijama ........................................................................................ 141
5.1 Procesi elektronskog poslovanja platnog sistema ........................................ 141
5.1.1 Instrumenti platnog prometa ..................................................................... 142
5.1.2 Učesnici u sistemu elektronskog poslovanja platnih sistema ................... 142
5.1.3 Osnovni procesi elektronskog poslovanja platnih sistema ....................... 143
5.2 Model podataka ............................................................................................ 155
5.3 SEPA model procesa ..................................................................................... 161
5.4 Matematički model EPPS-a .......................................................................... 167
5.5 Metod razvoja modela EPPS-a ..................................................................... 170
5.5.1 Identifikacija komponenti modela EPPS-a ............................................... 174
5.6 Provera validnosti poslovne transakcije EPPS-a .......................................... 180
5.6.1 Sistem provere podataka ........................................................................... 181
5.6.2 Sistem provere koraka poslovnih procesa ................................................ 181
5.7 Metode integracije platnih sistema ............................................................... 181
5.7.1 Razmena podataka .................................................................................... 183
5.7.2 Pretprocesiranje podataka ......................................................................... 194
5.7.3 Procesiranje podataka ............................................................................... 195
5.7.4 Postprocesiranje podataka ........................................................................ 197
5.7.5 Provere putem Registracionog tela ........................................................... 197
5.8 Struktura predloženog modela ...................................................................... 198
5.8.1 Globalni standardi poruka ........................................................................ 199
5.8.2 Logičke celine nad srodnim grupama poruka........................................... 199
5.8.3 Finansijske institucije ............................................................................... 200
5.8.4 Transportna infrastruktura ........................................................................ 200
5.9 Model evaluacije rešenja .............................................................................. 201
6 Primena i implementacija interoperabilng EPPS modela ..................................... 203
6.1 Arhitektura predloženog sistema .................................................................. 203
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
6.2 Aktivnosti razvoja sistema............................................................................ 207
6.2.1 Kreiranje lokalnih ontologija i domenske ontologije ............................... 210
6.2.2 Razvoj scenarija ........................................................................................ 214
6.2.3 Ključni indikatori performansi ................................................................. 215
6.2.4 Izbor metodologije razvoja i implementacije ........................................... 216
6.3 Projektni zahtevi ........................................................................................... 221
6.3.1 Projektni zadatak ...................................................................................... 222
6.3.2 Funkcionalni zahtevi ................................................................................ 226
6.3.3 Ostali zahtevi ............................................................................................ 229
6.4 Analiza zahteva............................................................................................. 230
6.4.1 Specifikacija CT ....................................................................................... 230
6.4.2 Saradnja između učesnika ........................................................................ 236
6.4.3 Specifikacija sistema za razmenu poruka ................................................. 237
6.4.4 Primena ontologija u analizi ..................................................................... 244
6.4.5 Obezbeđenje interoperabilnosti ................................................................ 246
6.4.6 Rezultati analize ....................................................................................... 246
6.5 Servisi za procesiranje .................................................................................. 249
6.6 Primena rešenja............................................................................................. 256
6.6.1 Komponente sistema ................................................................................ 256
6.6.2 Realizacija sistema ................................................................................... 257
6.7 Analiza postignutih rezultata modelom ........................................................ 272
6.7.1 Eksperiment u klirinškoj kući ................................................................... 274
6.7.2 Rezultati empirijskih merenja ................................................................... 277
6.7.3 Statistika rada sistema Udruženja banaka Srbije ...................................... 279
6.7.4 Simulaciona analiza .................................................................................. 280
6.7.5 Implementaciona analiza .......................................................................... 282
6.7.6 Analiza efekata primene i fleksibilnosti modela ...................................... 283
6.7.7 Poređenje sa drugim rešenjima ................................................................. 284
6.7.8 Evalauacija predloženog modela interoperabilnog elektronskog poslovanja
platnih sistema ...................................................................................................... 284
7 Naučni i stručni doprinosi .................................................................................... 288
8 Buduća istraživanja............................................................................................... 292
9 Zaključak .............................................................................................................. 293
10 Literatura .............................................................................................................. 295
11 Spisak slika ........................................................................................................... 314
12 Spisak tabela ......................................................................................................... 317
13 Prilozi ................................................................................................................... 318
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 1
1 Uvod
1.1 Definisanje predmeta istraživanja
Predmet ove disertacije je razvoj i primena modela interoperabilnog elektronskog
poslovanja platnih sistema zasnovanog na ontologijama i REA (ISO/IEC 15944-4:2007)
ontološkoj objektnoj strukturi sistema. Istraživanje je bazirano na globalnim poslovnim
standardima finansijske industrije - referentnim modelima za razmenu informacija.
Saznanja iz implementacije sistema za kliring čekova i sistema za direktno zaduženje u
Udruženju banaka Srbije koji su realizovani korišćenjem obrazaca za poslovnu
integraciju (EIP - Enterprise Integration Patterns) i standardizovanih sistema poruka će
biti primenjena u istraživanju. Istraživanje biće prilagođeno za implementaciju
interoperabilnih platnih sistema u Srbiji.
Ontologije kao formalni opis objekata, njihovih osobina i odnosa u određenom domenu
su eksplicitno razumljive i za čoveka i za računar. Ontološkim pristupom se postiže
interoperabilnost i konzistentnost u modelu i obogaćuje dizajn modela sa domena
znanja. Standard ISO 15944-4:2007, koji će biti razmatran u rešenju, definiše ontološko
okruženje za specifikaciju koncepata i relacija uključenih u poslovne transakcije i
scenarije nazvane Resource-Event-Agent (REA) ontologijom.
Korišćenje poruka (Messaging) ima važnu ulogu na nivou razmene podataka, odražava
se na aplikativne modele sistema i operacije u sistemu izazvane događajem. Na nivou
razmene poruka transportni mehanizam omogućava korišćenje posebnih modula za
razmenu poruka i njihovu obradu. Upotrebom sistema za razmenu poruka, u rešenju
koje će biti razmatrano, ostvaruje se pouzdanost u komunikaciji, transparentnost u
odnosu na programske jezike i platforme, postiže se asinhronost koja omogućava
modulima nezavisnost obavljanja operacija bez gubljenja vremena na čekanje izvršenja
operacija drugih modula. Postiže se mogućnost podešavanja vremena obrade u odnosu
na kapacitete, odstranjuju se zaglušenja i onemogućavanje rada modula prouzrokovanih
prevelikim brojem poziva operacija modula.
Interoperabilnost se postiže korišćenjem standardizovanih sistema poruka i transportnih
sistema za njihovu razmenu i omogućava učesnicima standardan pristup operacijama sa
finansijskim transakcijama. Razmena finansijskih transakcija se odvija na nivou
klirinških kuća, centralne banke, banaka i drugih finansijskih organizacija, organa
državne uprave, organizacija na nivou državnih zajednica, na međunarodnom nivou,
kao i privrednih subjekata i građana koji se javljaju kao učesnici u platnim sistemima.
Svima njima je potrebno da mogu na lak način razmeniti finansijske transakcije koje
opisuju korišćenjem istih meta podataka, a koje prate podatke tokom procesa njihovog
nastanka, prikupljanja, razmene i obrade. Koordinacija između učesnika u platnom
prometu unutar države jeste suštinska za postizanje konzistentnosti i efikasnosti
elektronskog poslovanja i postiže se standardizacijom na svim nivoima. Upotreba
globalnih finansijskih standarda u domenu platnih sistema unapređuje konzistentnost i
efikasnost elektronskog poslovanja i doprinosi unapređenju sistema za elektronsko
poslovanje i drugih sistema jer svaka poslovna transakcija elektronskog poslovanja ima
kao rezultat jednu ili više finansijskih transakcija. Glavni faktor uspešne implementacije
platnih sistema na državnom i međunarodnom nivou predstavlja uspostavljanje
višeslojne interoperabilnosti elektronskog poslovanja u skladu sa globalnim
standardima. Obaveza Narodne banke Srbije je stvaranje mogućnosti za elektronsku
razmenu finansijskih transakcija između svih učesnika i to je preduslov za realizaciju
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 2
ovog i drugih sistema za elektronsko poslovanje, u cilju približavanja EU i članstvu u
toj organizaciji.
Različiti platni sistemi u procesu elektronskog poslovanja su u interakciji sa različitim
poslovnim sistemima učesnika. Poslovni sistemi učesnika podržavaju veliki broj
korisnika i poslovnih procesa sa specifičnim zahtevima. Osnovni problem je
heterogenost između poslovnih procesa, podataka i korišćenih IT tehnologija. Iz tog
razloga vreme, finansijska sredstava i informatički resursi troše se na prevođenje
podataka iz jednog sistema u drugi. Razmena finansijskih transakcija elektronskim
putem postala je prevladavajuća. Time nastaje potreba za razvojem modela
interoperabilnog elektronskog poslovanja platnog sistema za razmenu finansijskih
transakcija i njihovu obradu. Standardizacija u domenu modeliranja platnih sistema,
koja će biti razmatrana, treba da doprinese i većoj efikasnosti ostalih sistema
elektronskog poslovanja i interoperabilnosti elektronskog poslovanja učesnika.
Model interoperabilnog elektronskog poslovanja platnog sistema je skup obrazaca koji
omogućavaju da strukture platnog sistema zasnovanog na ontologijama mogu
perzistirati u relacionom modelu podataka koji sledi iz standardizovanih XML šema
podataka.
Registraciono telo koje se predlaže u ovom radu ima zadatak da arhivira poruke i
potvrde prijema i na taj način za treća lica, na specijalan zahtev, recimo potrebe
veštačenja, učini poslovne procese elektronskog poslovanja sledljivim i neporecivim.
Sistemi Kompanije Dunav osiguranja, Dunav banke, Dunav auta i Udruženja banaka
Srbije biće realan sistem za analizu, istraživanje i primenu modela predloženog u ovoj
disertaciji.
Realizacija će se odvijati u sledećim pravcima:
• istraživanje postojećih modela platnih sistema, klasifikacija prema: načinu
plaćanja, mestu plaćanja, veličini transakcija, načinu obračuna, instrumentima
plaćanja, modelu plaćanja, platnim servisima,poslovnom modelu plaćanja,
korišćenim IT i komunikacionim tehnologijama i njihova primena u sistemima
elektronskog poslovanja;
• istraživanje postojećih metoda interoperabilnosti i istraživanje mogućnosti
njihove primene u sistemima elektronskog poslovanja;
• istraživanje mogućnosti modeliranja interoperabilnog modela zasnovanog na
ontologijama;
• istraživanje mogućnosti razvoja modela za generisanje, razmenu i obradu
finansijskih transakcija, integraciju i prihvatanje informacija iz distribuiranih,
heterogenih izvora podataka korišćenjem obrazaca za poslovnu integraciju;
• modelovanje arhitekture platnih sistema zasnovane na obrascima za poslovnu
integraciju;
• istraživanje mogućnosti za automatsko uspostavljanje interoperabilnosti u okviru
poslovnih procesa platnih sistema;
• prikaz i analiza koncepata vezanih za REA;
• implementacija interoperabilnog modela platnog sistema zasnovanog na
ontologijama
• merenje performansi po izabranim kriterijumima.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 3
Tokom rada na ovoj disertaciji koristiće se dostupni standardi, saznanja, alati i metode
vezane za modelovanje interoperabilnosti elektronskog poslovanja kod platnih sistema i
primena ontologija na razvoj modela interoperabilnog platnog sistema.
1.2 Ciljevi istraživanja
Osnovni cilj istraživanja je razvoj modela interoperabilnog elektronskog poslovanja u
platnim sistemima, zasnovanog na ontologijama finansijskih transakcija u platnim
sistemima i ontološkim modelima. Istraživanje će obuhvatiti tehnike i metode za
kreiranje ontologija elektronskog poslovanja, modela poslovnih procesa kao i
mogućnost za razvoj okvira interoperabilnosti sa drugim sistemima po istim principima
u slučajevima, kada odvijanje aktivnosti procesa izlazi iz granica jednog sistema i
prelazi u drugi.
Cilj istraživanja je i unapređenje i poboljšanje performansi servisa elektronskog
poslovanja platnih sistema: kvaliteta, troškova, prilagodljivosti, potražnje, brzine i
inovativnosti servisa.
Interakcija sistema elektronskog poslovanja u ovim slučajevima može se postići
koristeći iste principe integracijom standardizovanih komponenata sistema, koje su
neophodne za kompletiranje svih aktivnosti procesa, predviđajući unapred potrebne
integracije kada je to i moguće. Postojeći okviri za uspostavljanje interoperabilnosti
sistema koristiće sisteme poruka (Messaging) u odgovarajućoj arhitekturi poslovne
integracije.
Suštinski koncept razmene sistema poruka je standardizovanje složenih poslovnih
procesa u skup asinhronih, nezavisnih procesa koji omogućavaju različite, lake za
definisanje, implementaciju i sprovođenje, jednostavne poslovne funkcionalnosti. Jedna
od ideja ovog rada jeste da se princip asinhronih i povezanih procesa može primeniti na
informacione modele da bi se savladala složenost elektronskog poslovanja u različitim
platnim sistemima.
Prema ovom principu, opšti cilj ove teze je da razvije model koji doprinosi smanjenju
složenosti pri definisanju, implementaciji i korišćenju integrisanih platnih sistema u
procesu elektronskog poslovanja.
S obzirom na postavljene ciljeve, zadaci istraživanja su:
• analiza problema na polju razvoja ontološkog modela platnog sistema;
• analiza problema na polju interoperabilnosti elektronskog poslovanja platnih
sistema;
• istraživanje globalnih standarda finansijske industrije vezanih za zadavanje i
modeliranje poslovnih procesa platnih sistema, sa osvrtom na oblasti koje nisu u
potpunosti pokrivene postojećim standardima i specifikacijama;
• istraživanje postojećih modela interoperabilnosti platnih sistema;
• analiza standarda za ontološku predstavu modela platnih sistema;
• razvoj metamodela za unifikaciju organizacije podataka;
• razvoj metamodela poslovnih procesa platnih sistema zasnovanih na
standardizovanoj arhitekturi;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 4
• razvoj okvira interoperabilnosti elektronskog poslovanja platnih sistema;
• verifikacija razvijenog okvira interoperabilnosti elektronskog poslovanja platnih
sistema, modela poslovnih procesa i standardizovanog modela organizacije
podataka.
1.3 Polazne hipoteze
Polazeći od predmeta rada, postavljenih ciljeva i zadataka, može se postaviti glavna
hipoteza:
Modelom interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na
ontologijama moguće je unaprediti razvoj platnih sistema koji je prilagođen uslovima u
Republici Srbiji. Model treba da bude zasnovan na standardizovanom ontološkom
modelu podataka i procesa u poslovno orjentisanoj arhitekturi.
Pomoćne hipoteze:
• Primenom predloženog modela može se realizovati interoperabilno elektronsko
poslovanje platnih sistema u Republici Srbiji;
• Predloženi model je efikasniji u poređenju sa postojećim modelima integracije;
• Implementacijom predloženog modela smanjuju se troškovi i povećava se
pouzdanost elektronskog poslovanja platnih sistema u Republici Srbiji;
• Uvođenje registracionog tela za registraciju poruka, potvrda prijema i
verifikaciju poslate poruke i potvrde prijema čini poslovne procese elektronskog
poslovanja globalno sledljivim i neporecivim.
1.4 Metodologija istraživanja
Tokom izrade ovog rada od opštenaučnih metoda koristiće se: modelovanje, strukturna
analiza, funkcionalna analiza, komparativna metoda, metoda analogije, merenje i metod
naučnog posmatranja i eksperimenta. Modelovanje će se koristi prilikom izrade modela
interoperabilnog elektronskog poslovanja platnih sistema. Strukturna analiza,
funkcionalna analiza, komparativna i metoda empirijskog istraživanja koristiće se
prilikom analize postojećih rešenja integracije platnih sistema, kao i procesa platnog
prometa tokom eksperimenta. Merenje relevantnih parametara i analiza dobijenih
rezultata biće obavljeni pomoću standardnih statističkih metoda. U eksperimentalnom
delu posmatraće se performanse elektronskog poslovanja platnih sistema kada se
odvijaju pomoću IT infrastrukture zasnovane na standardizovanom ontološkom modelu
podataka i procesa u poslovno orjentisanoj arhitekturi. Dobijeni rezultati eksperimenta
treba da potvrde generalnu hipotezu o postizanju interoperabilnosti u elektronskom
poslovanju na razvijenom ontološkom modelu platnog sistema dobijenog
standardizacijom organizacije podataka i procesa platnih sistema.
Rezultati istraživanja biće prezentovani tekstualno, opisivanjem i prikazom kroz tabele,
slike i dijagrame sa uporednim rezultatima. Istraživanje će biti interdisciplinarno jer
uključuje naučne discipline metodologiju, informatiku, finansije i druge. Metode
logičkog objašnjenja koje će se koristiti: metoda analize i sinteze, induktivno i
deduktivno zaključivanje. Doktorska teza će obuhvatiti odgovarajuće grafičke prikaze i
prezentacije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 5
Istraživanja predložena u ovoj disertaciji obuhvatiće: metodologiju, alate i standarde
modelovanja interoperabilnih platnih sistema zasnovanih na ontologijama.
Studija slučaja u okviru ove disertacije ima za cilj da demonstrira predloženi model
platnog sistema zasnovan na ontologijama za generisanje, razmenu i obradu finansijskih
transakcija.
1.5 Struktura i organizacija rada
U okviru uvoda opisani su predmet, ciljevi disertacije, polazne hipoteze, metodologija
istraživanja i struktura rada.
U drugom poglavlju dat je kratak osvrt na pojam elektronskog poslovanja i značaj
informacionih tehnologija u elektronskom poslovanju sistema. Definisan je koncept,
nivoi i opšti okvir interoperabilnosti. Naglašena je važnost rešavanja problema
interoperabilnosti elektronskog poslovanja platnih sistema. Dat je značaj standarda za
interoperabilnost i ograničenja. Opisani su savremeni trendovi u tehnološkom progresu,
uticaj razvoja informacionih tehnologija i zakonodavni okvir elektronskog poslovanja
kao i prikaz elektronskog poslovanja platnih sistema u svetu i kod nas. U ovom
poglavlju prikazane su i prednosti elektronskog poslovanja i mogućnosti primene
servisno orijentisane arhitekture za realizaciju rešenja integracije, sa ciljem da se
podigne nivo interoperabilnosti i ekonomičnosti poslovnih subjekata elektronskog
poslovanja platnih sistema. Razmatran je i aspekt sigurnosti i sigurnosnih standarda u
elektronskom poslovanju.
U trećem poglavlju dat je pregled platnih sistema, od osnovnih definicija i klasifikacija
finansijskih organizacija do opisa multikanalnih sistema pravnih i fizičkih lica. Opisani
su standardi platnih sistema i sistema za razmenu poruka. Naglašeni su i globalni
standardi i način na koji se oni zadaju i prezentuju u globalnoj finansijskoj zajednici.
Prikazani su i relevantni platni sistemi u svetu, u državama našeg okruženja a
razmatrana je i zakonska regulativa i pregled platnih sistema za plaćanja na malo i
veliko u Srbiji. Posebno je dat osvrt na način na koji centralna banka vrši nadgledanje
platnih sistema i na koji način funkcioniše i kao operater platnih sistema kod nas.
U četvrtom poglavlju dat je pregled relevantnih tehnologija, gde posebno mesto
zauzimaju XML tehnologije sa standardima za zadavanje podataka i metapodataka
korišćenjem XML i RDF struktura. Prikazane su i relevantne strukturalne i objektne
metodologije razvoja sa prikazom metoda i paradigmi u razvoju informacionih sistema.
Opisana je servisno orijentisana arhitektura i veb-servisi kao osnov za izgradnju SOA.
Posebna pažnja posvećena je proučavanju veb-servisa sa svojom arhitekturom i
elementima sigurnosti informacionih sistema koji su zasnovani na servisno orijentisanoj
arhitekturi i veb-servisima. Opisana je uloga semantičkog veba sa ontologijama u
realizaciji semantičke interoperabilnosti i primena ontologija u integraciji sistema.
U petom poglavlju, koje predstavlja najznačajniji naučni doprinos ove disertacije,
opisan je razvoj modela interoperabilnog elektronskog poslovanja platnih sistema
zasnovanog na ontologijama. Definisana je struktura modela i softverska arhitektura
predloženog sistema integracije. Opisana je metodologija razvoja modela, razvijen je
model zasnovan na servisno orijentisanoj arhitekturi, integraciji informacija i aplikacija
korišćenjem ontologija. Dat je prikaz procesa elektronskog poslovanja platnog sistema,
opisana je struktura modela podataka i model procesa koji se potvrđuju prikazanim
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 6
matematičkim modelom. Kreirana je domenska ontologija i opisan je metod razvoja
elektronskog poslovanja platnih sistema zasnovan na ontologijama i način identifikacije
komponenata modela, kao i metode integracije koje obezbeđuju interoperabilnost
elektronskog poslovanja platnih sistema na nacionalnom i međunarodnom nivou.
U šestom poglavlju prikazana je implementacija osnovnom arhitekturom predloženog
generičkog modela poslovnih procesa elektronskog poslovanja platnih sistema, opisom
aktivnosti razvoja sistema, funkcionalnosti i prikazanim projektnim zahtevima koje
sistem mora da zadovolji. Definisana je struktura modela i logička i fizička arhitektura
predloženog sistema integracije. Predstavljane su aktivnosti, scenariji i mehanizmi
integracije. Izvršena je analiza postavljenih zahteva sistema za razmenu podataka i
servisa za procesiranje, opisan je i analiziran referentni model i prikazano uspostavljanje
interoperabilnosti poslovanja elektronskog poslovanja različitih sistema elektronskog
poslovanja i elektronskog poslovanja platnih sistema sa lancima snabdevanja, sistema
osiguravajućeg društva, registracionog tela i klirinške kuće, kao i izvršeni eksperiment u
konkretnom okruženju. Izvršena je analiza rezultata koji pokazuju da se primenom
razvijenog modela integracije omogućava interoperabilnost elektronskog poslovanja
platnih sistema na nivou: podataka, servisa, poslovnih procesa i na semantičkom nivou.
Predloženo rešenje prevazilazi konceptualne, tehnološke i organizacione prepreke
interoperabilnosti elektronskog poslovanja platnih sistema. Primenom predloženog
rešenja integracije podiže se nivo efikasnosti i ekonomičnosti elektronskog poslovanja
platnih poslovnih sistema.
U sedmom poglavlju dat je pregled naučnih i stručnih doprinosa disertacije. Budući
pravci istraživanja prikazani su u osmom poglavlju. U zaključku je dat pregled sadržaja
i naučnih doprinosa disertacije. Spisak literature sadrži relevantne reference za oblast
disertacije. U prilogu su dati spisak slika i tabela iz disertacije, operativna pravila sa
pratećom dokumentacijom koju je autor disertacije definisao sa tehnolozima Udruženja
banaka Srbije, regulativa evropskog saveta za plaćanja i finansijski proračun godišnjih
finansijskih prihoda od procesiranja klirinške kuće. Na kraju rada data je biografija
autora.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 7
2 Elektronsko poslovanje
U ovom poglavlju dato je objašnjenje pojmova elektronskog poslovanja i
interoperabilnosti. Opisane su komponente sistema i okruženje elektronskog poslovanja,
kao i to kako globalni tehnološki progres i razvoj informaciono komunikacionih
tehnologija utiče na razvoj elektronskog poslovanja. Objašnjeni su konteksti
elektronskog poslovanja i organizacione promene koje su nastale uvođenjem
elektronskog poslovanja, kao i napori na polju standardizacije i zaštite elektronskog
poslovanja.
2.1 Definicija elektronskog poslovanja
Razvoj informaciono - komunikacionih tehnologija i globalne ekonomije stvorio je
uslove za globalizaciju poslovanja. Model globalne organizacije i jake konkurencije
zahteva odgovarajuću koncepciju pristupa organizacija poslovanju, o čemu svedoči
uvećano ulaganje u tehnologiju orijentisanu prema klijentu [75]. Integracijom velikog
broja informacionih sistema i mreža, internet tehnologije su potpuno otvorile vrata
konceptu elektronske ekonomije time što su omogućile kreiranje inovativnih poslovnih
pristupa u domenu prodaje, kupovine i internom kreiranju poslovnih procesa.
Usmerenost savremenog poslovanja organizacija ka globalnom tržištu podrazumeva
integrisanost informacionih i komunikacionih tehnologija, kojima se obezbeđuje protok
podataka bez prostornih ograničenja.
Primenom koncepta savremenog poslovanja i integracijom savremenih tehnologija u
poslovanju dolazi do promena poslovanja u odnosu na okruženje ali istovremeno i
unutar same organizacije. Informacija dobija mesto nezaobilaznog elementa, pored
proizvoda, usluga i novca u strukturi tržišta. Domen promena se značajno menja
razvojem globalne informatičke infrastrukture kao podrške u realizaciji uobičajenih
svakodnevnih zadataka i prilikom donošenja strategijskih odluka organizacije,
odražavajući se na uspešnost organizacije u poslovnom okruženju. Uspešnost
poslovanja organizacije zavisi od pronalaženja mesta u globalnoj podeli rada čime se
postaje deo globalnih poslovnih procesa. Razvoj Interneta omogućio je jednostavnu i
brzu komunikaciju, mogućnost prenošenja velike količine podataka na velike
udaljenosti, kontinuiranu i globalnu dostupnost sadržaja. Elektronsko poslovanje je
opšti koncept koji obuhvata sve oblike poslovnih transakcija ili razmene informacija
koje se izvode korišćenjem informacione i komunikacione tehnologije i to: između
organizacija, između organizacija i njihovih klijenata i između organizacija i javne
administracije. Elektronsko poslovanje se može posmatrati sa više stanovišta: Sa
aspekta komunikacija elektronsko poslovanje je elektronska isporuka informacija,
proizvoda, usluga i elektronsko plaćanje. Sa poslovnog aspekta te je primena
tehnologije u svrhu automatizacije poslovnih transakcija i poslovanja. Sa stanovišta
usluga to je alat koji omogućava smanjenje troškova poslovanja uz povećavanje
kvaliteta i brzine pružanja usluga [198].
Jedna od najpotpunijih definicija elektronskog poslovanja data je u radu [212], gde se
elektronsko poslovanje definiše ne samo kao kupovina i prodaja robe i servisa, već i kao
servisiranje klijenata, saradnja u poslovnim procesima sa poslovnim partnerima ali i
obavljanje elektronskih transakcija u organizaciji. Elektronsko poslovanje je opšti
koncept koji obuhvata sve oblike poslovnih transakcija ili razmene informacija koje se
izvode korišćenjem informacione i komunikacione tehnologije između poslovnih
organizacija ili unutar same organizacije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 8
Začeto je prvim razmenama elektronskog sadržaja šezdesetih godina prošlog veka.
Početkom sedamdesetih godina ustanovljavaju se čvrsti koreni elektronskog poslovanja
nastankom elektronskog prenosa gotovine (EFT - Electronic Fund Transfer), koji se
odvijao između banaka putem sigurnih privatnih mreža. Osamdesetih godina razvijena
su dva nova oblika elektronskog poslovanja: elektronska razmena podataka (EDI -
Electronic Data Interchange) i elektronska pošta, koji su smanjili obim potrošnje i
cirkulacije papira i automatizacije dela poslovanja. EDI je omogućio elektronsku
razmenu dokumenata u standardnom elektronskom obliku. Bio je skupa tehnologija
koju su mogle da koriste samo najveće organizacije. Mala preduzeća su koristila onlajn
servise sa aplikativnim slojem koji je omogućavao elektronsku razmenu podataka.
Originalni koncept elektronskog poslovanja nastao je krajem devedesetih godina
prošlog veka. Pojam elektronskog poslovanja sredinom devedesetih godina prošlog
veka definisao je prvi IBM opisujući ga kao delatnost koja omogućava izgradnju i
primenu poslovnog modela u kome se organizaciona struktura menja zavisno od
poslova, a model poslovanja se oslanja na informatičke strukture i visok nivo
automatizacije, što doprinosi optimizaciji poslovnih procesa i sticanju prednosti nad
konkurencijom. Pokrenute su različite druge inicijative koje su doprinele da se
originalni koncept elektronskog poslovanja podigne na viši nivo, odnosno elektronsko
upravljanje poslovnim procesima korišćenjem informaciono-komunikacionih
tehnologija za vođenje i unapređenje poslovnih procesa [120]. Elektronsku ekonomiju
danas reprezentuju tri bitne komponente: infrastruktura kao podrška elektronskom
poslovanju, elektronski poslovni procesi kao način na koji se realizuje poslovanje i
transakcije elektronske trgovine, odnosno prodaja i kupovina.
2.1.1 Prednosti elektronskog poslovanja
Postoje brojne prednosti automatizacije poslovanja koje uključuju: porast operacijskih
delovanja, merljivi porast produktivnosti, smanjeno vreme procesa, skladan kvalitet
proizvoda i usluga zahvaljujući pravoj kontroli procesa, smanjenje troškova kroz
eliminaciju papirologije i „ručnih“ procesa, neposredan tok informacija između
zaposlenih i poslovnih partnera, povećanje zadovoljstva zaposlenih i zadovoljstva
poslovnih partnera. Kao osnovne prednosti elektronskog poslovanja izdvajaju se [198]:
• jednostavan i jeftin izlaz ka poslovnom okruženju;
• efikasno održavanje komunikacije sa poslovnim partnerima;
• automatizacija procesa;
• povećanje broja poslovnih transakcija;
• bolja optimizacija poslovanja;
• smanjenje grešaka, pogotovu gde je tačnost informacija od značaja;
• ušteda vremena, posebno u prenosu informacija;
• pristupačnost i razmenljivost informacija;
• drastično smanjenje troškova obrade;
• smanjenje obima ljudskog rada;
• smanjenje troškova poslovanja uštedom na smanjenju papirne dokumentacije;
• smanjenje troškova poslovanja uštedom na putnim i drugim sličnim troškovima;
• ekološki aspekti smanjenjem štampe i putovanja;
• niži troškovi plasiranja proizvoda i usluga na tržište koji rezultiraju nižim
prodajnim cenama i većom konkurentnošću;
• dostupnost na globalnom nivou 24 časa tokom svih sedam dana u nedelji;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 9
• mala ulaganja u IT da bi se obezbedila prisutnost u poslovnom ambijentu.
Elektronsko poslovanje često je prožeto i problemima uzrokovanim neslaganjima
između materijalnih i informacionih tokova. Nedostatak vidljivosti i informacionih
tokova u vezi sa statusom elektronske poslovne transakcije porudžbine može da izazove
nesigurnost i promenljivost u elektronskom poslovanju. Najveći nedostaci elektronskog
poslovanja su:
• izostanak socijalnog aspekta klasičnog poslovanja;
• suviše veliki intenzitet promena tehnologija;
• problemi bezbednosti;
• pojava novih tehničkih problema sa svojim rizicima;
• međunarodne barijere;
• kulturološke prepreke.
2.2 Komponente sistema elektronskog poslovanja
Elektronsko poslovanje je opšti koncept koji obuhvata sve oblike poslovnih transakcija
ili razmene informacija koje se izvode korišćenjem informacione i komunikacione
tehnologije. Tumačenje i razumevanje ovog pojma svakodnevno se menja, a načelno
treba da obuhvati složenost poslovanja jer obuhvata generisanje i održavanje evidencija
kupaca i partnera, da integriše digitalnu komunikaciju, e-trgovinu, onlajn istraživanja,
primenu svake vrste poslovanja i aktivnosti putem mreže, prikazano na slici 1.
Slika 1. Uprošćena slika elektronskog poslovanja
Osam segmenata okružuje klijenta kao polaznu osnovu svih savremenih poslovnih
procesa [204]: strategija elektronskog poslovanja, e-marketing, ljudski resursi, pravo i
zaštita, e-trgovina, lanci snabdevanja, veb-dizajn i veb-tehnologija. Osnovni cilj
poslovnih koncepcija jeste zadovoljenje potreba klijenata i formiranje poslovnog
okruženja u organizaciji tako da svi poslovni procesi budu u funkciji potreba klijenta, a
da se kao rezultat kvalitetnih odnosa s klijentima pojavi profit.
Strateški segmenti elektronskog poslovanja sastoje se od e-filozofije, strategije i
politike, e-marketinga, odnosa sa javnošću i informaciono-komunikacione
infrastrukture. Elektronsko poslovanje se odvija u distribuiranom okruženju Interneta,
gde je cilj ostvariti odabrani, najčešće visoki nivo interaktivnosti s klijentom. E-
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 10
marketing je strateško odlučivanje o poslovnim procesima u cilju zadovoljenja potreba
korisnika i organizacije, a zasniva se na kreiranju baza znanja o profilu i potrebama
kupaca, osoblja organizacije, menadžmenta i ostalih ciljnih elemenata u poslovnom
okruženju organizacije.
Operativni segmenti elektronskog poslovanja sastoje se od e-proizvodnje, e-
tehnologije, e-distribucije, e-zaštite i prava. E-proizvodnja se odvija u distribuiranom
okruženju, koje obezbeđuje rad na daljinu. Internet takođe omogućuje upravljanje
kvalitetom proizvoda koji su kreirani na osnovu potreba korisnika u realnom vremenu.
E-tehnologija postoji da bi se ostvario sistem efikasnog i isplativog elektronskog
poslovanja. Organizacija mora da poseduje određenu informacionu i komunikacionu
infrastrukturu, da ima opisane poslovne procese na nivou upravljanja bazama podataka i
da strateški i operativno koristi podatke iz informacionog sistema za upravljanje na
različitim hijerarhijskim nivoima odlučivanja. E- tehnologije su one koje omogućuju
ostvarenje poslovnih procesa, od nivoa veb-softverske tehnologije, dizajna i njihove
upotrebljivosti na nivou potreba korisnika. One obuhvataju i procese razmene između
zainteresovanih strana u poslovnom procesu u zavisnosti od tipa e-poslovanja (B2C,
B2B, B2E, B2G, C2G) [124]. E- distribucija služi da bi se uspešno završio proces
razmene dobara između zainteresovanih strana u procesu onlajn poslovanja, odnosno
obezbedili prilagođeni modeli lanaca distribucije fizičkih i nematerijalnih dobara i
usluga.
Da bi kompletan proces on-line poslovanja bio uređen i u skladu sa potrebama
zainteresovanih strana, mora postojati pravni okvir koji osigurava bezbedno poslovanje
sa maksimalno smanjenim rizicima, odnosno e-zaštita.
E-trgovina (e-commerce) predstavlja kupovinu i prodaju dobara ili usluga putem
Interneta kao i prihode od reklame, elektronsku razmenu dokumenata koji prate robu,
novac i usluge putem elektronskih sredstava. Ovaj proces uključuje kako maloprodajne,
tako i veleprodajne transakcije. Elektronska trgovina se ispoljava preko njenih formi i
modela. Osnovni modeli elektronske trgovine su kupovina iz izloga, portal, dinamičko
formiranje cena i onlajn kupovina i model pozajmice, a forme B2B, B2C, C2C i druge.
Upravljanje odnosima sa klijentima (Customer Relatioship Management - CRM)
predstavlja skup poslovnih procesa i tehnologija za upravljanje relacijama sa postojećim
i potencijalnim korisnicima i poslovnim partnerima u marketingu, prodaji i podršci,
preko svih raspoloživih kanala komunikacije. Ona podrazumeva sve aspekte interakcije
kompanije sa klijentima, bez obzira na to da li se radi o prodaji ili uslugama,
podrazumeva personalizaciju poslovanja sa svakim klijentom pojedinačno. CRM mora
biti integrisan u celokupan proces od inicijalnog kontakta do krajnje kupovine, a
marketing, prodaja i odeljenje podrške korisnicima moraju biti integrisani putem
informacione tehnologije.
Planiranje resursa preduzeća (Enterprise Resource Planning - ERP) rešenja
objedinjuju module finansija, logistike i proizvodnje. Najkraće rečeno, to je softverski
paket koji prati sve aspekte poslovanja jedne kompanije. Jedna od definicija ERP
sistema kvalifikuje softversko rešenje u ERP kategoriju ako zadovoljava sledeće uslove:
efektivno upravljanje procesima u preduzeću, postojanje zajedničke (jedinstvene) baze
podataka, mogućnost da se reaguje brzo na operativne zahteve. Implementirani ERP
sistem je u mogućnosti da integriše poslovanje različitih delova firme (npr.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 11
računovodstvo, proizvodnju, nabavku, prodaju itd.) u jednu jedinstvenu celinu. Tako se
dobija sistem preko koga je moguće upravljati svim ljudskim i materijalnim resursima,
kao i planirati, razvijati i pratiti poslovne procese i procedure.
Upravljanje lancima snabdevanja (Supply Chain Management - SCM) je termin koji
se koristi da opiše tok materijala, informacija i sredstava kroz lanac nabavke, od
snabdevača preko proizvođača pojedinih komponenata, konačnog spajanja i distribucije
(skladišta i maloprodaja), pa do konačnog kupca. Taj proces često sadrži i dodatne
usluge koje prate proizvod posle prodaje i povraćaj proizvoda na reciklažu. Lanac
vrednosti je skup poslovnih procesa koji povezuje snabdevače, proizvođače, prodavce
na malo, poslovne korisnike i ostale umešane u stvaranje, prodaju i isporuku robe do
krajnjeg kupca. Lanac vrednosti odgovara mreži kompanija koje rade zajedno i
koordiniraju svoje akcije prema isporuci proizvoda na tržište. To je dodatna aktivnost
koja je postala neophodan deo posla da bi se ispunili zahtevi kupaca.
Poslovna inteligencija (Business Intellignece – BI) predstavlja proces prikupljanja
raspoloživih internih i značajnih eksternih podataka i njihovo pretvaranje u korisne
informacije koje pomažu poslovnim korisnicima pri donošenju odluka [193]. Poslovni
podaci i istraživanja pružaju primarne i naknadne informacije o tržištu, potrošačima,
konkurenciji i ostalim činiocima poslovanja na osnovu kojih se može definisati
strategija poslovanja. U dinamičnom poslovnom okruženju kakvo je danas, od ključnog
značaja za preduzeće jeste da širokom krugu poslovnih korisnika obezbedi efikasan,
brz, jeftin i jednostavan pristup potrebnim informacijama. Sistem poslovne inteligencije
integriše podatke iz različitih izvora (transakcione i analitičke baze podataka, datoteke,
podaci sa veba itd.) u jedinstveni sistem koji korisnicima omogućava da podatke vide u
formatu koji je za njih najpogodniji, da vrše različite dodatne analize.
2.3 Okruženje i infrastruktura elektronskog poslovanja
Ambijentalno okruženje sistema elektronskog poslovanja je multidisciplinarno.
Osnovne discipline koje mogu da se uvrste u njega su sledeće: informatika, marketing,
ponašanje klijenata, finansije, ekonomija, upravljanje informacionim sistemima,
knjigovodstvo, upravljanje, upravljanje ljudskim resursima, poslovno zakonodavstvo,
robotika, javna administracija i inženjering.
2.3.1 Tehnološki progres kao osnova razvoja elektronskog poslovanja
Tehnološki razvoj je glavni pokretač većine procesa globalizacije. Pre objašnjenja o
posledicama nekoliko tehnološkog razvoja, moramo proći kroz definisanje tehnologije
kao sociološkog termina, tako da možemo bolje da sagledamo društvenu i političku
ulogu tehnologije u procesu globalizacije. Tehnologija se može definisati kao skup
društvenih znanja potrebnih za proizvodnju roba i usluga koji imaju sledeće elemente:
proizvodnju, znanje, instrumente, mogućnost posedovanja i promene. Tehnologija je
usko povezana sa proizvodnjom (robe i usluga); tehnologija uvećava našu proizvodnu
sposobnost. Tehnologija je rezultat intelektualnih aktivnosti i predstavlja vrstu
intelektualne svojine. Danas je razvijena kroz istraživanje i razvoj institucija, kao deo
sastavnih aktivnosti univerziteta. Instrumenti poboljšavaju performanse ljudskog tela.
Instrumenti ukazuju na korišćenje tehnologije od strane ljudskih bića. Instrumenti su
uglavnom fizički objekti, ali postoje i instrumenti nematerijalne prirode, kao što su baze
podataka ili algoritmi u kompjuterskom programiranju i slično. Osobe ili organizacije
koje poseduju tehnologiju u mogućnosti su i da je kontrolišu i na taj način utiču na
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 12
ekonomiju i politiku. Iz tog razloga možemo govoriti o tehnološki bogatim i siromašnim
zemljama i borba je najčešće u formi pridobijanja patenata, transfera i zaštite
intelektualnih prava. Tehnologija je usko povezana sa promenama. Na primer, 1957.
obeležen je najvažniji korak u istoriji globalizacije, kada je SSSR lansirao Sputnjik.
Sateliti su omogućili izgradnju potpuno pouzdane globalne mreže. Digitalne tehnologije
otvorile su put ka globalnim mrežama. Globalni mreže su mreže u kojoj su sve
informacije i znanje - i ideološki neophodno za realizaciju, održavanje i reprodukciju
sistema. Monopolizacija ekonomske moći takođe je u vezi sa tehnologijom. Elektronsko
bankarstvo je u srcu globalnog sistema mreža. Elektronski prenos sredstava (Electronic
Found Transfer - EFT), prvi je operativni oblik globalnih elektronskih finansijskih
mreža. EFT je omogućio slanje i primanje finansijskih sredstava među bankama.
Godine 1973. u Briselu, uz podršku 239 banaka u 15 zemalja, SWIFT [210] počinje
misiju stvaranja zajedničkog globalnog sistema za obradu podataka i komunikacionih
veza i zajedničkog standarda za međunarodne finansijske transakcije. Godine 1977,
Albert, princ Belgije, šalje prvu SWIFT poruku. Do tog vremena inicijalna grupa
članova je porasla na 518 komercijalnih banaka u 17 zemalja. Do kraja te godine,
SWIFT ima 518 klijenata u 22 zemalja sa 3.400.000 poruka. Između SAD i Evrope
1985. uspostavljena je satelitska veza. Uz korišćenje satelitske tehnologije SWIFT se
vrlo brzo razvijao, pa je do kraja 1999. SWIFT imao 6.797 aktivnih korisnika u 189
zemalja i dostigao 1.059.000.000 poruka. Danas, na primer, 15.11.2012. procesirano je
oko 18 miliona FIN (Financial INstitutions) poruka, ukupno do 15.11.2012 u novembru
193 miliona, do 15.11. u 2012. godini 4024 miliona, a rast u 2012. godini, u odnosu na
prošlu godinu je +3.09% [209].
2.3.2 Uticaj razvoja informacionih tehnologija na elektronsko poslovanje
Elektronsko poslovanje je indukovano na sledećim informatičkim resursima:
korisnicima sistema, kadrovima za planiranje, izgradnju i podršku sistemima po
odabranoj metodologiji, hardveru i komunikacionoj infrastrukturi, sistemskom i
aplikativnom softveru, tehnološkim znanjima i organizaciji. Skup elektronskih
poslovnih sistema sa informatičkim resursima nad kojima je indukovano jeste
informatička zajednica. Informatičku zajednicu kao društvo pokreće tehnološki
napredak u oblasti informaciono-komunikacionih tehnologija. Nov globalni pristup
utiče na reorganizaciju svetskih razmera političkim promenama, liberalizacijom
privrede, problemima zdravstva, ishrane i životne sredine i generiše do sada najdublje
promene u društvu. Razvoj informaciono-komunikacionih tehnologija i mogućnost
njihove primene u svim sferama društva promovisali su ih kao ključne faktore razvoja
svakog savremenog društva. Ove tehnologije menjaju način na koji ljudi, poslovni i
upravljački sistemi komuniciraju, kao i globalni ambijent u kome savremene ekonomije
i društva rade i razvijaju se. Generalno, svet je u procesu izgradnje nove infrastrukture
koja briše prostorne barijere i omogućava mobilnost poslovnih sistema. Tržište, tokovi
kapitala i poslova postaju jedinstveni na svetskom nivou i jednostavno dostupni sa svih
geografskih pozicija. Pojedini poslovni sistemi kao i državne i lokalne zajednice u celini
postaju učesnici globalne tržišne utakmice. Pravovremene, sveobuhvatne i tačne
informacije postale su osnovni upravljački resursi u poslovnim sistemima i institucijama
društva. Ovi resursi mogu se obezbediti jedino razvojem informacionog društva, koje se
na taj način nameće kao imperativ u svim zemljama koje žele da osiguraju progres i
budućnost svojim građanima.
Razvijene zemlje i ekonomije već se nalaze u procesu transformacije ka
„informacionom društvu“ [221] koje se zasniva na primeni savremenih informaciono-
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 13
komunikacionih tehnologija, i u kojem su informacije, znanje i ljudski resursi od
vitalnog značaja. Manje razvijene zemlje moraju aktivno delovati u cilju što bržeg
uključenja u ove procese jer je to jedini put za njihov razvoj i za bitno poboljšanje
standarda i kvaliteta života građana, kao i uslov integracije u savremene poslovne
tokove. Tri vida informaciono-komunikacionih tehnologija u najvećoj meri utiču na
razvoj, unapređenje i korišćenjeinformacionih sistema: razvoj sistema koji omogućavaju
obradu velike količine podataka i koji dobijanje rezultata distribuiraju u kratkom
vremenu; telekomunikacije koje predstavljaju glavnu tehnologiju za razvoja mreža
velike brzine, bežičnih sistema i satelita, koji omogućavaju direktnu vezu izmeću
računara i brz prenos svih vrsta podataka širom sveta; inteligentni aplikativni sistemi za
upravljanje informacionim sistemom, koji je jednostavan za upotrebu i povećava
efikasnost u radu.
2.3.3 Uticaj razvoja elektronskog poslovanja na poslovanje
Najveća promena koja utiče na poslovanje jeste upravo pojava Interneta i svih servisa
koje Internet omogućuje. Zadatak menadžmenta trgovinskih kompanija jeste upravo da
prepoznaju sve mogućnosti koje Internet pruža, da se sa njima dobro upoznaju ili da
uposle dovoljno stručan i obrazovan kadar koji će znati da adekvatno upotrebljava već
postojeća sredstva, a što je najvažnije, koji će biti spreman za konstantno učenje i
prilagođavanje novim tehnologijama i izumima koje Internet svakodnevno izbacuje na
tržište. U nastavku su navedeni neki uobičajeni načini vođenja poslovanja koji se skoro
više i ne obavljaju na drugi, već isključivo na opisan način uz podršku elektronskog
poslovanja.
Elektronska faktura podrazumeva da menadžment preduzeća ima mogućnosti da
svojim zaposlenima i poslovnim partnerima (kupcima) izdaje fakture u elektronskom
obliku, bez potrebe štampanja istih jer se po međunarodnom pravu o elektronskoj
trgovini svi dokumenti i elektronska komunikacija poslata sa službene adrese se
smatraju punovažnim bez pečata i potpisa. Srbija još uvek nema adekvatan zakon o
elektronskom poslovanju. Međutim, i tu postoji alternativa u obliku elektronskog
potpisa koji se prilaže uz poslati dokument. Svako preduzeće ili privatno lice u Srbiji
ima pravo da deponuje svoj elektronski potpis u Pošti Srbije ili u sudu.
Elektronski radni nalog u slučaju velikih preduzeća, gde se svakodnevno između više
službi/divizija, kao i na relaciji menadžment-ostali zaposleni, izdaje veliki broj radnih
naloga i ostale vrste interne komunikacije uz korišćenje adekvatnih programa za
komunikaciju može da postigne veliku uštedu vremena, radnog materijala, kao i da
poveća efektivnost interne komunikacije.
Efikasniji menadžment se postiže primenom servisa, pa dobija mnogo veću slobodu
upravljanja i mnogo veću kontrolu izvršenja radnih naloga i zadataka. Menadžment
struktura preduzeća, počevši od top menadžmenta, pa do menadžera sektora, šefova
radnih celina kao što su magacini, proizvodnja i prodaja, ima mogućnost praćenja
izvršenja svih radnih zadataka, praćenja stanja u magacinu, o dnevnom i trenutnom
učinku prodaje i slično, a da pri tome uopšte ne mora biti fizički prisutna u preduzeću.
Računovodstveni programi služe za vođenja poslovnih knjiga i danas se sve to
obavlja u elektronskom obliku uz pomoć različitih računovodstvenih i drugih programa.
Postoje i onjajn računovodstveni programi koji su dostupni uglavnom uz veoma male
godišnje troškove uz odgovarajuće održavanje.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 14
Elektronska evidencija zaliha u magacinima omogućava potpuno automatizovan
proces nabavke i isporuke potrebnih artikala za određenu prodavnicu. To funkcioniše na
taj način što, pri prodaji bilo kog artikla, automatski se u sistemu vodi količina
određenih artikala u datoj prodavnici, te se sistem reprogramira tako da automatski šalje
zahtev magacinu da se prodavnici pošalje određena količina artikala, čim broj artikala
spadne do određene cifre, koja je unapred unesena u program. Time se isključuje ljudski
faktor, komunikacija se ubrzava i čitavo poslovanje postaje efikasnije.
Elektronsko vođenje i izveštavanje o završnim računima i generalnom uspehu
poslovanja korišćenjem programa za vođenje završnih računa, kao i za periodične
preseke o uspešnosti poslovanja, omogućava preduzeću da čitavo svoje poslovanje
prikaže veoma transparentno za sve zainteresovane strane, a najpre omogućava
sopstvenom menadžmentu da ima bolji uvid u poslovanje preduzeća.
Elektronska prodavnica (E-Shop) omogućava da se tržište koje je nekada zavisilo od
fizičkog prisustva i zauzimanja što bolje fizičke lokacije sada naglo prebaci na globalno
tržište bez ikakvih ograničenja u poslovanju. Menadžment preduzeća treba da odluči da
li će čitavu svoju ponudu postaviti na Internet i na koji će način to učiniti. Činjenica je
da postavljanje elektronske prodavnice ne zahteva kupovinu ili zakup poslovnog
prostora, opreme, velikog broja radnika, potrošnog materijala i drugih radnih sredstava.
Marketing, odnosno promocija roba i usluga na Internetu može predstavljati osnovni
prostor za oglašavanje u kojem preduzeće ima potpunu slobodu delovanja i izražavanja i
mogućnost privlačenja novih klijenata i zadržavanja starih.
2.3.4 Zakonodavni okvir elektronskog poslovanja
Nedovoljna primena zajedničkih standarda eksplicitno znači suočavanje sa problemom
nedostatka interoperabilnosti. Ukoliko se doda i nedovoljna koordinacija institucija i
organizacija u primeni zajedničkih rešenja, problem nedostatka interoperabilnosti se
uvećava. Da bi se problem umanjio, od vitalnog značaja je definisanje zakonskog okvira
koji determiniše kontinuirano unapređenje procesa poslovanja i integracije na svim
nivoima.
U Srbiji na putu razvoja informacionog društva usvojena je potrebna zakonska
regulativa koja u narednom periodu treba da se unapređuje. Širok krug propisa koji
pokrivaju oblast za sprovođenje poslova elektronskog poslovanja od značaja su i za
nacionalni okvir interoperabilnosti, a odnose se na mere zaštite privatnosti, osiguranja
bezbednosti, obezbeđenja potpisanih elektronskih dokumenata, čuvanja elektronskih
zapisa, upravljanja elektronskim potpisom, upravljanja elektronskim poslovanjem,
elektronskom pisarnicom i elektronskom arhivom originalnih dokumenata. Uređivanje
informacionog društva važan je deo usklađivanja pravnog okvira Srbije sa evropskim.
Široki krug propisa koji pokrivaju oblast za sprovođenje poslova za elektronsko
poslovanje podjednako je značajan za nacionalni okvir interoperabilnosti. Stvaranje
pravnog okvira za izgradnju informacionog društva, usklađenog sa razvojem tehnologije
i međunarodnim standardima, započeto je sistemski nakon 2003. godine. Glavne
smernice u tom procesu, osim strateških dokumenata Evropske unije, određene su u
dokumentu Pakta za stabilnost Jugoistočne Evrope „eSEE Agenda+ za razvoj
informacionog društva u Jugoistočnoj Evropi 2007–2012.” usvojenog 2007. godine
[58], kao i u Vladinim dokumentima Strategija razvoja informacionog društva u
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 15
Republici Srbiji do 2020. godine [201], Strategija reforme državne uprave i nedavno
usvojenoj Strategiji razvoja elektronske uprave u Republici Srbiji za period od 2009. do
2013. godine.
Zakoni Republike Srbije koji definišu pravni okvir elektronskog poslovanja su:
• Zakon o elektronskom poslovanju (Sl. Glasnik RS, br. 135/2004);
• Odluka o elektronskom načinu obavljanja platnog prometa (Sl. Glasnik RS, br.
57/2004);
• Pravilnik o evidenciji sertifikacionih tela (Sl. Glasnik RS, br. 48/2005, 82/2005 i
116/2005);
• Pravilnik o bližim uslovima za izdavanje kvalifikovanih elektronskih sertifikata
(Sl. Glasnik RS, br. 26/2008);
• Pravilnik o registru sertifikacionih tela za izdavanje kvalifikovanih elektronskih
sertifikata u Republici Srbiji (Sl. Glasnik RS, br. 26/2008);
• Pravilnik o tehničko-tehnološkim postupcima za formiranje kvalifikovanog
elektronskog potpisa i kriterijuma koje treba da ispune sredstva za formiranje
kvalifikovanog elektronskog potpisa (Sl. Glasnik RS, br. 26/2008 i 13/2010);
• Odlika o elektronskom potpisivanju dokumenta sa podacima koje banke
dostavljaju Narodnoj banci Srbije (Sl. Glasnik RS, br. 28/2009 i 47/2009);
• Zakon o elektronskoj trgovini (Sl. Glasnik RS, br. 41/2009);
• Zakon o elektronskom dokumentu (Sl. Glasnik RS, br. 51/2009);
• Strategija razvoja elektronske uprave u Republici Srbiji za period od 2009. do
2013. godine (Sl. Glasnik RS, br. 83/2009 i 5/2010);
• Pravilnik o izdavanju vremenskog žiga (Sl. Glasnik RS, br. 112/2009);
• Uredba o elektronskom kancelarijskom poslovanju organa državne uprave (Sl.
Glasnik RS, br. 40/2010);
• Strategija razvoja informacionog društva u Republici Srbiji do 2020. godine (Sl.
Glasnik RS, br. 51/2010);
• Strategija razvoja elektronskih komunikacija u Republici Srbiji od 2010. do
2020. godine (Sl. Glasnik RS, br. 68/2010).
Ostali srodni zakonski i podzakonski akti od značaja su:
• Zakon o informacionoj bezbednosti;
• Zakon o zaštiti podataka o ličnosti;
• Zakon o tajnosti podataka;
• Zakon o autorskim i srodnim pravima;
• Zakon o slobodnom pristupu informacijama od javnog značaja;
• Zakon o registraciji privrednih subjekata;
• Zakonska regulativa na koju se oslanjaju informacioni sistemi za vođenje
registara (centralni registar stanovništva, matični registri, registri prebivališta i
boravišta, registri privrednih subjekata, registri nepokretnosti, registri korisnika
zdravstvenog osiguranja i dr.);
• Podzakonski akti Narodne banke Srbije u oblasti informacionih sistema u
finansijskoj industriji u Srbiji.
Zakoni o informacionom društvu doneti nakon 2003. godine u Republici Srbiji
usklađeni su sa zakonodavstvom Evropske unije. Konkretno, to su: Zakon o registraciji
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 16
privrednih subjekata, Zakon o dostupnosti informacija od javnog značaja i Zakon o
elektronskom potpisu, sa podzakonskim aktima. Donošenjem ovih zakona ustanovljeni
su osnovi za primenu koncepta elektronskog poslovanja, kao što su uvođenje
elektronskog potpisa i elektronskih sertifikata, mogućnost dostavljanja zahteva stranaka
elektronskim putem, pružanje usluga elektronskog poslovanja Internetom, komunikacija
stranaka i organa elektronskom poštom i slično.
2.3.5 Okruženje za uvođenje elektronskog poslovanja u preduzeća
Politički kontekst rezultat je usklađivanja različitih vizija i ciljeva organizacija. On
predstavlja njihovu jasno izraženu volju i nameru učestvovanja u postizanju zajedničkih
ciljeva u procesu elektronskog poslovanja. Na temelju političkog konteksta mogu se
prepoznati zajednički prioriteti, planirati zajedničke aktivnosti i definisati ograničenja
radi uspešnog uspostavljanja interoperabilnosti elektronskog poslovanja. Evropska unija
svoju politiku u oblasti elektronskog poslovanja deklarisala je 1997. godine kao
"evropsku inicijativu u oblasti elektronskog poslovanja". Na osnovu ove inicijative
bliska su rešenja koje su zemlje članice pojedinačno donele u regulisanju digitalnog
potpisa, sistema šifriranja i potvrde autentičnosti. U EU postoji najmanje 15 direktiva,
predloga i preporuka koje pokušavaju da regulišu e-trgovinu. Skup predloga i preporuka
je značajan iako izgleda da su te direktive donete deo po deo. EU je nastojala da u toj
oblasti politički nametne zakonsku kontrolu i postoji težnja da svaka država inkorporira
različite delove evropske zakonske regulative u svoje lokalne zakone. Neki od njih su
Direktiva o e-potpisu, Direktiva o prodaji na daljinu i ugovaranju na daljinu, Direktiva o
zaštiti podataka, Direktiva o e-trgovini i Direktiva o autorskom pravu.
Pravni kontekst je suštinski za uspešan razvoj elektronskog poslovanja i zahteva
ispunjenje i preduslova postojanja adekvatnih pravnih okvira. Ustavni osnov za
donošenje Zakona o elektronskoj trgovini sadržan je u članu 97. tačka 6. Ustava
Republike Srbije, kojima se utvrđuje da Republika Srbija uređuje i obezbeđuje, pored
ostalog, jedinstveno tržište, pravni položaj privrednih subjekata, sistem obavljanja
pojedinih privrednih i drugih delatnosti. Stvaranje pravne regulative u oblasti
elektronskog poslovanja započelo je donošenjem Zakona o elektronskom potpisu. Vlada
Republike Srbije postupak daljeg razvoja, unapređenja i pravnog regulisanja
elektronskog poslovanja nastavila je kroz donošenje Strategije razvoja informacionog
društva u republici Srbiji i Strategije razvoja trgovine Republike Srbije.U Strategiji
razvoja informacionog društva u republici Srbiji navodi se da elektronsko poslovanje u
osnovi znači automatizaciju poslovnih procesa primenom informacionih i
komunikacionih tehnologija i predstavlja efikasno sredstvo za obavljanje poslovnih
aktivnosti na nacionalnom i međunarodnom nivou. Prema Akcionom planu e-Evropa
2005, e-poslovanje obuhvata e-trgovinu (kupovinu i prodaju putem interneta) i
restrukturiranje poslovnih procesa sa ciljem realizacije najbolje upotrebe digitalnih
tehnologija. Odgovornost je Vlade da prati razvoj novog zakonodavstva i uputstava u
EU, i da na njima bazira praksu koju će primenjivati u domaćoj privredi. Informacije o
aktuelnim evropskim zakonima i standardima važan su element poslovnog okruženja i
njihova raspoloživost znatno će olakšati donošenje odluka na nivou kompanija i u
različitim administrativnim organima.
Tehničko – organizacioni aspekti upravljanja organizacijom, istorijski posmatrano, i
obrada podataka su prošli kroz ručnu, mašinsku i elektronsku fazu. Smatra se da je
ručna obrada stara koliko i poslovanje (ručno knjiženje, obračunavanje kamata itd.).
Mašinska obrada je vezana za pojavu prve mehaničke mašine, koju je izmislio
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 17
matematičar Paskal, od tada je nastala čitava serija mašina za računanje i pisanje
(računske mašine, polu automati, pisaće mašine, knjigovodstvene mašine). Pojavom
prvog elektronskog računara počela je era računara, koja je do danas prošla kroz
nekoliko faza - generacija računara. Tehnološke inovacije, pre svega novije generacije
kompjuterske tehnologije, omogućavaju ubrzavanje poslovanja, čak i trenutnu
povezanost raznih tržišta i mogućnost računanja sa svakim i najmanjim, vremenskim
intervalom. U odnosu na tehničke aspekte savremenog poslovanja vrše se i
organizaciona strukturiranja u okviru organizacija, tako da danas svaka organizacija ima
i svoju informatičku podršku koja se sastoji od specijalista iz različitih oblasti
informacionih tehnologija koji održavaju organizacionu interoperabilnost - poslovnu
usklađenost između sistema (učesnika). Organizaciona interoperabilnost omogućava
kvalitetno i održivo postizanje ciljeva definisanih političkim kontekstom unutar
utvrđenih okvira pravne interoperabilnosti. Organizaciona interoperabilnost omogućava
da sistemi efikasno povežu svoje procese radi pružanja zajedničke usluge nekom
korisniku. U praksi, organizaciona interoperabilnost se uspostavlja kroz integraciju
poslovnih procesa i sa njima povezanu razmenu informacija. Da bi različiti sistemi bili u
mogućnosti da efikasno i delotvorno rade zajedno, oni treba da usklade svoje poslovne
procese, a često i da definišu i uspostave nove poslovne procese. Usklađivanje
poslovnih procesa podrazumeva njihovo dokumentovanje na opštedogovoreni način,
tako da svi koji učestvuju u pružanju elektronskih usluga imaju globalni pogled na
složene poslovne procese i razumeju svoju ulogu u njima, analogno definisanju odnosa
među učesnicima u procesu interoperabilnosti. Organizaciona interoperabilnost
obuhvata saradnju raznorodnih aplikacija u davanju konačnih elektronskih usluga. Ova
dimenzija interoperabilnosti može se postići kroz posebne softverske aplikacije
utemeljene na XML-u (eXtensible Markup Language - XML), koje se nazivaju veb-
servisima i koje su osnova servisno orijentisane, fleksibilne arhitekture (Service
Oriented Architecture - SOA).
Semantički kontekst elektronskog poslovanja se ogleda u semantičkoj
interoperabilnosti. To je sposobnost različitih sistema u procesu elektronskog
poslovanja da na isti način tumače značenja informacija koje razmenjuju, a postiže se
usklađivanjem semantičkih područja poslovanja između sistema. Semantička
interoperabilnost odnosi se na uspostavljanje znanja koje poslovnim entitetima
uključenim u proces elektronskog poslovanja obezbeđuje prevazilaženje semantičkih
konflikata pri razmeni podataka. Semantički konflikti proizilaze iz razlika u korišćenim
terminologijama za izražavanje poslovnih koncepata i konteksta, tj. domena u kojem se
koncepti i podaci interpretiraju. Semantička aktiva (Semantic Assets) obuhvata sve
resurse potrebne za ostvarivanje semantičke interoperabilnosti, kao što su šifarnici,
rečnici pojmova, XML šeme i slični popisi, specifikaciju njihovih međusobnih veza i
pravila preslikavanja među njima. Semantika se povezuje sa razumevanjem i
interpretacijom značenja podataka, dok se sintaksa povezuje sa razumevanjem i
interpretacijom strukture podataka.
Tehnički kontekst elektronskog poslovanja je ambijent koji se stvara da bi sistem
mogao kontinuirano da posluje bez obzira na uslove koji vladaju. Iz tog razloga se
formiraju primarni, backup (rezervni) i disaster sajt (u slučaju katastrofe). Svaki od
sajtova treba da ima obezbeđeno neprekidno napajanje energijom koje se postiže
uređajima za neprekidno napajanje (Uninterruptible Power Supply - UPS), sistemima
agregata za permanentno obezbeđivanje izvora energije za sisteme za neprekidno
napajanje, uređajima za održavanje odgovarajućih ambijentalnih uslova (na primer
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 18
temperature, vlažnosti vazduha), kao i odgovarajućim sistemima za detektovanja,
alarmiranje i dojavu neusaglašenosti u sistemu i to po svakoj komponenti sistema
posebno. Primarni sajt je planiran po kapacitetima za optimalan rad u normalnim
uslovima. Posebnim tehnikama se obezbeđuje ažurna kopija podataka na backup i
disaster sajtu da bi oni mogli da preuzmu funkciju u slučaju potrebe. Uobičajena je
hardverska replikacija storage sistema u kombinaciji sa log shipping-om baze podataka.
Primarni sajt je od backup sajta udaljen nekoliko kilometara, dok se udaljenost disaster
sajta treba meriti stotinama kilometara. Disaster sajt treba da zadovolji posebne uslove
koji ga čine u slučaju katastrofe manje ranjivim, na primer da bude na drugoj tektonskoj
ploči ukoliko se primarni sajt nalazi na trustnom području. Backup sajt je planiran za
rad sa degradiranim performansama u slučaju da dođe do nemogućnosti funkcionisanja
primarnog sajta. Posebno se objavljuje rad na backup sajtu. Kapaciteti su planirani za
ograničen rad i procesiranje ograničenog broja transakcija koje je neophodno obaviti za
normalno funkcionisanje države. Nije predviđeno da se duži vremenski period
procesiranje obavlja na backup sajtu, već samo do otklanjanja problema koji je nastao
na primarnom sajtu. Pošto su svi uslovi rada normalni, dovođenje primarnog sajta u
funkcionalno stanje ne sme da traje dugo. Disaster sajt treba da ima performanse bliske
primarnom sajtu jer se predviđa rad na disaster sajtu u uslovima velikih poremećaja, na
primer zemljotresa, terorističkog napada na primarni sajt i slično, gde je šteta na
primarnom sajtu velika i nije moguće dovesti u funkcionalno stanje u kratkom
vremenskom periodu.
Komunikaciona infrastruktura treba da obezbedi tehničku interoperabilnost, siguran i
zaštićen prenos informacija (potpisivanje sadržaja, kriptovanje sadržaja, kriptovanje
komunikacije). Vrši se posebno segmentiranje mreže na svim nivoima u posebne
zaštićene zone za svaki operativni segment, posebno se isturaju komunikacioni čvorovi
prema centrima za komunikaciju koji su vidljivi ostalim učesnicima, komunikacioni
centri su u posebno zatvorenim mrežama u kojima su poznati učesnici koji se vladaju
prema određenim pravilima. Prave se planovi rada mreže u odnosu na normalan rad, rad
u otežanim uslovima sa backup sajtom i rad u katastrofalnim uslovima na disaster sajtu.
Prilikom projektovanja hardverskih komponenata vodi se računa o tome da kod svake
hardverske komponente ne postoji single point of failure. Svaka hardverska komponenta
treba da bude multiplicirana da u slučaju otkaza jedne komponente sistema nastavi
normalno da radi, a sistem hardverskih komponenata da bude tako projektovan da je
moguće sistem skalirati u slučaju potrebe za povećanjem kapaciteta. Hardverska
infrastruktura se sastoji od storage sistema za sigurno pohranjivanje velikih količina
podataka, odgovarajuće komunikacione infrastrukture za obezbeđivanje brze
komunikacije između hardverskih komponenti sistema na sajtu (uglavnom fiber channel
infrastruktura), serverske infrastrukture, infrastrukture za pravljenje rezervne kopije
podataka i trajno skladištenje podataka, kao i hardverske infrastrukture za udaljenu
replikaciju podataka. Operativni sistemi i sistemski softver determinisani su
aplikativnim rešenjem sistema.
Organizacione promene nastale uvođenjem elektronskog poslovanja ogledaju se u
mogućnostima koje elektronsko poslovanje donosi. One se pre svega ogledaju u
izmenjenom načinu obavljanja poslovnih transakcija, radnom vremenu, prostornoj
neograničenosti, brzini obavljanja poslovnih transakcija, umanjenoj ceni poslovne
transakcije, ali i u potrebi za povećanjem sigurnosti zbog izmenjenog načina obavljanja
transakcija, izmeni poslovnih procesa, kadrovima koji su potrebni da bi se izvršila
poslovna transakcija. Po pitanju radnog vremena, elektronsko poslovanje omogućuje
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 19
bez dodatnih ulaganja u resurse neograničeno radno vreme (24 sata dnevno, sedam dana
u nedelji, 365 dana godišnje). U tradicionalnom poslovanju za obavljanje poslovnih
transakcija bilo je potrebno angažovati veliki broj zaposlenih u tri smene u čitavoj
poslovnoj mreži, tako da su troškovi poslovanja van tradicionalnog radnog vremena bili
izuzetno veliki. Struktura organizacionih jedinica je izmenjena u smislu da uvođenjem
elektronskog poslovanja moraju da postoje specijalizovani sektori za tekuće održavanje,
za sistemsku podršku i za aplikativnu podršku, koji se sastoje od informatičara
specijalizovanih za sve aspekte podrške elektronskom poslovanju. I tehnolozi posla,
kadrovi koji obavljaju poslovne procese, imaju posebne zadatke u odnosu na
tradicionalno poslovanje i moraju da poseduju adekvatna znanja za korišćenje
informacionih tehnologija. Pored vremenske neograničenosti, prostorna neograničenost
donosi nove mogućnosti organizacionih promena uvođenjem elektronskog poslovanja.
Radnik više nije vezan za mesto, pa čak ni za zemlju gde postoji organizaciona jedinica
kojoj pripada, već se dodeljivanjem odgovarajućih privilegija u sistemu može omogućiti
udaljen pristup i dati mogućnost obavljanja poslovnih transakcija koje su mu dodeljene.
U klasičnom poslovanju bilo je potrebno potrošiti vreme za dolazak i odlazak u
poslovnu jedinicu radi obavljanja poslovne transakcije uz utrošak dodatnog vremena za
obavljanje same poslovne transakcije. Elektronsko poslovanje omogućava
obezbeđivanje potrebnih informacija za obavljanje poslovne transakcije, izvršenje
poslovne transakcije i distribuciju informacija o obavljenoj poslovnoj transakciji bez
utroška vremena za ličnu identifikaciju poslovnog subjekta, odnosno odlaska i dolaska
poslovnog subjekta u jedinicu i kasniju distribuciju informacije o obavljenoj transakciji.
Ukoliko su informacije spremne, u elektronskom poslovanju akvizicija informacija
potrebnih za poslovnu transakciju, obavljanje transakcije i distribucija informacija o
poslovnoj transakciji gotovo je trenutna ukoliko su ispunjeni svi uslovi za obavljanje
transakcija. Vremenska neograničenost, prostorna neograničenost i brzina obavljanja
poslovne transakcije čine da je cena poslovne transakcije u elektronskom poslovanju
niska. Pošto se poslovne transakcije moraju obavljati u bezbednom okruženju i na
siguran način, moraju postojati odgovarajući mehanizmi koji organizaciono obezbeđuju
ta dva aspekta, a koji uvećavaju troškove poslovne transakcije.
2.3.6 Elektronsko poslovanje platnih sistema u svetu i kod nas
Platni sistem je jedan od osnovnih podsistema finansijskog sistema. Stručna javnost
tokom poslednje dve decenije [198] posvećena je proučavanju, razvoju i implementaciji
standarda vezanih za ovu oblast. Ključni razlog tolikog interesovanja može se odslikati
kroz sledeće: pouzdan i efikasan platni sistem jeste jedna od osnovnih pretpostavki
efikasnog funkcionisanja celokupnog finansijskog sistema države. Pored stručne
javnosti, platnim sistemima poseban značaj pridaju i međunarodne finansijske
institucije, organizujući internacionalne komitete koji se bave navedenom oblašću i
proklamovanjem odgovarajućih standarda, preporuka i smernica. Institucija koja je
utemeljivač osnovnih standarda vezanih za ovu oblast je Bank For International
Settlemens – BIS, u Bazelu u okviru koje funkcioniše Commitee for Payment and
Settlement Systems. Platni promet se organizuje i razvija u skladu sa ekonomsko-
finansijskim razvojem zemlje i uspostavljenim odnosima poverenja između centralne
banke i poslovnih banaka. Razvoj platnog prometa prati stalno usavršavanje
organizacije, načina oblika i instrumenata plaćanja. U svetu nema jedinstvenog i
idealnog načina organizovanja platnih sistema. Savremeno organizovan platni promet
pruža učesnicima u plaćanju mogućnost korišćenja savremenih i prikladno kreiranih
instrumenata plaćanja, kao i mogućnost izbora i korišćenja oblika i načina plaćanja. Da
bi platni promet bio tačan, efikasan i ekonomičan, mora postojati uzajamna usklađenost
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 20
između organizacije procesa plaćanja, instrumenata, oblika i načina plaćanja.
Savremeno organizovan platni promet zasnovan je na korišćenju informaciono-
komunikacione tehnologije. Platni promet se odvija razmenom elektronskih poruka kroz
informacione sisteme učesnika. Elektronskom porukom smatra se informacija koje je
elektronski generisana, poslata, proverena, primljena i sačuvana. Struktura poruka
utvrđena je od strane zakonodavnog organa, obično centralne banke. Validnom
elektronskom porukom smatra se svaka elektronska poruka propisanog formata, koja je
overena elektronskim potpisom i primljena u skladu sa propisanim pravilima. U
razvijenim tržišnim ekonomijama danas egzistiraju različiti modeli sistema obračuna
platnog prometa. Kada su u pitanju transakcije velikih vrednosti, različitost ovih modela
sastoji se u izboru operatera sistema, što je uglavnom centralna banka, u izboru vrste
obračuna, odnosno bruto i neto obračuna, i mogućnosti korišćenja intradnevnog
kreditiranja i izboru funkcije operacione kontrole pri upravljanju veličinom
intradnevnog kredita.
SEPA (Single Euro Payments Area) trenutno je najveći zajednički projekat evropske
bankarske industrije. Iniciran je neusaglašenošću da građani ne mogu da koriste iste
naloge za plaćanja, naloge za naplatu i platne kartice na isti način na čitavoj teritoriji
Evropske unije. Na planu integracije i harmonizacije velikih plaćanja [179] zajedno sa
Evropskom monetarnom unijom 1999. godine pušten je sistem Target. To je zajedno sa
Fedwire sistemom najveći RTGS (Real Time Gross Settlement) sistem u svetu. Target
je tehnički distribuiran, sastoji se od tehnički decentralizovanih platformi. Target 2
predstavlja nadogradnju sistema Target baziran je na jedinstvenoj, zajedničkoj platformi
i podrazumeva standardizaciju tehnologije, efikasnije procesiranje i efikasnije
upravljanje likvidnošću, a po pitanju platforme, za razliku od Targeta prestavlja
tehnički centralizovan sistem. Na planu malih plaćanja Europen Payment Council čini
napore na polju transfera zaduženja, transfera odobrenja i platnih kartica. Suočava se sa
problemima odsustva interoperabilnosti pošto je zona izdeljana na različite nacionalne
platne sisteme, od kojih je svaki zadržao specifična rešenja koja su okrenuta prema
običajima i potrebama sopstvenih korisnika i zahtevima domaćeg zakonodavstva.
Razlike među tim sistemima su u pogledu tehnologije realizacije, postupaka, standarda,
vrste usluga, bankarskih tarifa i sadržaja koji se koriste u režimu međubankarskih
obračuna i plaćanja. 28.01.2012. godine pušten je SEPA credit transfer instrument
plaćanja, što znači da je 27 zemalja članica, Island, Lihtenštajn, Norveška i Švajcarska
dobilo jedinstveni instrument za obavljanje bankarskih poslova. Očekuje se da će do
2015. godine u SEPA oblasti važiti jedinstveni formulari i pravila i za sve ostale
instrumente plaćanja i da će sve novčane transakcije u evrima moći da se odvijaju preko
bilo kog tekućeg računa u Evropi pod istim uslovima.
2.4 Globalni standardi elektronskog poslovanja
Standard kao termin u disertaciji koristi se u širem smislu i pokriva dokumente, koji
obezbeđuju pravila, smernice i karakteristike za aktivnosti i njihove rezultate, sa ciljem
postizanja optimalnog stepena reda u datom kontekstu [83]. Primena standarda olakšava
postizanje interoperabilnosti sistema elektronskog poslovanja. Međutim, rad na razvoju
i sprovođenje standarda ne znači da će interoperabilnost, i pored primene standarda, biti
automatski postignuta. Standardi u oblasti interoperabilnosti kreiraju se da bi osigurali
konzistentnost između uređaja, platformi i sistema. Oni promovišu interoperabilnost
sistema, tako što obezbeđuju da se proizvodi, kreirani korišćenjem različitih tehnologija,
mogu zajedno koristiti [75].
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 21
Standardizacija elektronskog poslovanja je globalan proces i odvija se permanentno
u interesom povezanim organizacijama za razvoj standarda. Standardizacija se odvija na
svim nivoima i vrlo često se za istu grupu standarda formiraju različite organizacije
pošto je interes povezanih struktura koje iniciraju razvoj standarda da imaju standard
pod svojom kontrolom. Standardizacija elektronskog poslovanja odvija se, pre svega,
prema oblastima poslovanja: finansije, lanci snabdevanja, javna uprava, meteorologija,
javni saobraćaj, hotelijerstvo i mnogi drugi. Standardizacija elektronskog poslovanja
prema oblastima jeste, u stvari, standardizacija instrumenata elektronskog poslovanja
kroz standardizaciju standardizacija podataka, odnosno poruka i poslovnih procesa, to
jest načina upotrebe poruka. Komponente od kojih se sastoje složeni poslovni objekti
uglavnom nisu standardizovane i na tom polju se takođe vrši standardizacija od strane
organizacije UN/CEFACT koja standardizuje osnovne komponente (Core Components).
Na taj način se vrši standardizacija objekata poslovanja (standardizacija metapodataka) i
standardizacija podataka. U svakoj oblasti poslovanja možemo za vrlo kratko vreme
pronaći nekoliko standarda koji se u isto vreme standardizuju, koji se preklapaju ili koji
su naslednici drugih, postojećih standarda, koji su još uvek u upotrebi. Ovi globalni
standardi imaju svoju očiglednu prednost zbog interoperabilnosti na nivou procesne i
semantičke interoperabilnosti ali u većini slučajeva nisu pogodni sa stanovišta
isplativosti primene zbog toga što je promovisanje novih standarda veoma agresivno i
često, pa, iako su novi standardi napredniji, veoma česta izmena sistema elektronskog
poslovanja nosi sa sobom neprihvatljive troškove poslovanja. Standardizacija razmene
podataka danas ide do tog nivoa da se nad standardnim protokolima implementiraju
sistemi za logičku razmenu podataka koji ne zavise od konkretnog protokola i mogu se
primeniti nad raznim postojećim protokolima ili nekim budućim. Sintaksna
interoperabilnost postiže se upotrebom XML standarda u standardizaciji svake oblasti
poslovanja i uz tehničku interoperabilnost savremeni standardi su po ovom pitanju
usaglašeni. Globalni standardi elektronskog poslovanja prate sva tri nivoa
interoperabilnosti i najveća je neusaglašenost na nivou semantičke interoperabilnosti jer
poslovni sistemi koji iniciraju izradu standarda žele da imaju presudan uticaj i kontrolu
nad ovim segmentom kao tehnološkom inovacijom, a samim tim nad čitavim
predmetnim domenom.
2.4.1 Standardizacija informacionih tehnologija
Standardizacija u oblasti informacionih tehnologija ogleda se pre svega u uvođenju
standarda u izgradnji infrastrukture elektronskog poslovanja, odnosno data centara,
sprovođenju tehnologije virtualizacije i primeni cloud computing tehnologije. Navedene
tri kategorije informacionih tehnologija u poslednje vreme zauzimaju značajno mesto u
izgradnji sistema elektronskog poslovanja i postaju de facto standard za implementaciju.
Standardizacija u oblasti data centara [169] obezbeđuje da se pružanje IT
operativnih i poslovnih servisa vrši u skladu sa najvišim industrijskim standardima
zaštite. Tier klasifikacija data centara odnosi se na opis infrastrukture data centara po
nivoima, sa ciljem održavanja određenog nivoa operativnosti celokupnog data centra.
Karakteristike pojedinih sistema ili podsistema data centra samo su deo ukupne slike
Tier standardizacije data centra. Za svaki od podsistema definiše se redundantnost i
vreme ispravnog rada kako bi se ispunili specifični Tier zahtevi raspoloživosti. Ocena
data centra daje se na osnovu ocene najslabijeg podsistema koji utiče na raspoloživost
celokupnog data centra. Data centri imaju višestruke, fizički izolovane podsisteme, koji
omogućavaju potpunu redundantnost na nivou napajanja i sistema hlađenja. TIA 942
standard sadrži preporuke koje se odnose na dizajn prostora namenjenog za data centar,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 22
strukturno kabliranje, usklađivanje sa Tier standardima i okruženje. Objekti data centara
mogu da imaju i više hiljada kvadratnih metara korisne površine, sa prostorom za utovar
i istovar opreme, teretnim liftovima i namenskim parkingom za vozilo za dolivanje
goriva. Klasifikuju se kao objekti kategorije I, za VIII seizmičku zonu po MCS
(Mercalli-Cancani-Sieberg) skali. Objekat treba da obezbeđuje redundansu od najmanje
za sledeće sisteme: električne, mehaničke i infrastrukturu telekomunikacionog
povezivanja. Data centar treba da je direktno povezan na gradsku elektro-energetsku
mrežu preko dve različite trafo-stanice, pomoću dve nezavisne grane za napajanje.
Trase podzemnih vodova treba da su potpuno fizički razdvojene. Sistemi napajanja
električnom energijom treba da su projektovani su tako da je moguće održavanje jedne
od grana napajanja bez uticaja na funkcionalnost sistema u celini. Dizel generatori sa
podzemnim sezonskim rezervoarima treba da obezbeđuju kontinuirano napajanje data
centra u trajanju od 72 časa, pri punom kapacitetu, a bez dolivanja goriva. Generatori se
automatski startuju pri prekidu osnovnog elektro-energetskog napajanja. Kapacitet
generatora pokriva sva kritična opterećenja celokupnog data centra. UPS sistem treba da
se sastoji iz dva nezavisna UPS podsistema sa autonomijom rada od više desetina
minuta pri punom projektovanom opterećenju data centra. Centralni sistem za nadzor i
upravljanje treba da omogućava stalno praćenje temperature i vlažnosti vazduha za
svaku od soba s opremom. Sistem za detekciju i rano otkrivanje požara u data centru
obično koristi laserske detektore za rano otkrivanje dima koji obezbeđuju rano
upozorenje o promenama u bilo kom delu data centra. Kontrola fizičkog pristupa
opremi korisnika sprovodi se preko odgovarajućih bezbednosno-sigurnosnih sistema,
pri čemu je obezbeđena višestruka mehaničko-elektronska kontrola ulaska u objekat i
sobe sa opremom. Objekat treba da je obezbeđen sigurnosnom ogradom, uz potpuno
kontrolisani pristup ulazu koji je opremljen dvadesetčetvoročasovnim sistemom video-
nadzora i uz stalno prisustvo fizičkog obezbeđenja. Kontrola pristupa prostorijama u
data centru treba da je sprovedena u skladu sa unapred dodeljenim korisničkim pravima
pristupa i bezbednosnim procedurama, koje podrazumevaju i autentifikaciju preko PIN
kodova i čitača ID kartica, koji su instalirani na svim vratima u data centru.
Virtualizacija je tehnologija čijim korišćenjem može da se izvrši smanjenje troškova
po pitanju hardvera, potrošnje električne energije i prostora predviđenog za smeštanje
prateće IT opreme. Korišćenjem ove tehnologije vrši se dinamično povećanje
iskorišćenja IT resursa, povećava se njihova fleksibilnost i bezbednost, uz konsolidaciju
računarske opreme. Virtualizacija se preporučuje kao najbolje rešenje za povećanje
pouzdanosti i otpornosti na otkaze IT resursa, kao i kod projektovanja rešenja za
oporavak od svih vidova katastrofa. Sama tehnologija doprinosi i očuvanju životne
okoline, te se svrstava u porodicu green tehnologija. Virtualizacija obuhvata serversku
infrastrukturu, radne stanice i aplikacije. Ubrzani razvoj Interneta, hardverskih
komponenata i sistemskog softvera rezultovao je ekspanzijom broja servera, servisa i
aplikacija u data centrima. U cilju efikasnog iskorišćenja IT resursa i ozbiljnog
smanjenja inicijalnog i operativnog ulaganja u IT došlo je do razvoja savremenog
rešenja koje danas nazivamo virtualizacijom. Virtualizacija servera predstavlja
tehnologiju koja omogućava da se na jedan fizički server „smesti” više virtualnih
servera, u cilju optimizacije sistema, povećanja bezbednosti, lakšeg održavanja i
investiranja u hardver, prostor i električnu energiju. Virtualizacija desktop infrastrukture
podrazumeva tehnologiju pomoću koje se korisniku uz pomoć kompjuterske mreže
isporučuje centralizovana virtuelna mašina iz računarskog data centra (radna stanica).
Tehnologija zahteva servere na kojima se smeštaju virtuelne radne stanice, kao i fizički
tanki klijent, ili računar za komunikaciju sa serverima. Virtualizacija radne površine
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 23
zasniva se na dinamičkoj isporuci virtuelnog Microsoft Windows operativnog sistema –
radne površine u obliku servisa, bez obzira na lokaciju istog, uz neophodan uslov da
postoji mrežna komunikacija sa serverskom infrastrukturom. Virtualizovane radne
stanice se po funkcionalnosti i izgledu ne razlikuju od klasičnih radnih stanica na
kojima je lokalno instaliran operativni sistem. Ovakav koncept donosi niz ušteda i
obezbeđuje znatno jednostavnije i jeftinije održavanje operativnih sistema na radnim
stanicama. Ukupna cena primenom virtualizacije radne površine može biti smanjena i
do 40%. U cilju obezbeđivanja kontinuiranog rada informacionih sistema, kao i zaštite
servisa i aplikacija od katastrofe, potrebno je obezbediti visoko dostupne servise koji će
geografski biti smešteni na drugu lokaciju. Danas je uz pomoć savremenih tehnologija
moguće implementirati i integrisati virtuelnu IT infrastrukturu u poslovno okruženje na
jednostavniji, brži i ekonomski isplativiji način.
Cloud Computing ili računarski oblak predstavlja skup podataka i usluga koje
koegzistiraju u deljenom skalabilnom skupu resursa zasnovanom na tehnologiji
virtualizacije i / ili skaliranim aplikativnim okruženjima. To je model koji omogućava
jednostavan mrežni pristup, na zahtev korisnika, deljenom skupu resursa (na primer
mrežni resursi, serveri, prostor na hard diskovima, aplikacije i servisi), koji mogu da
budu brzo dostupni za upotrebu ili ugašeni, a sa minimalnim intervencijama, ili
akcijama od strane pružaoca usluga.
Ovakav model sastoji se od sledećih karakteristika:
• Samostalno korišćenje na zahtev (Korisnik može da koristi resurse kada on to
želi, sa bilo kojeg mesta i u bilo koje vreme putem globalne mreže. Ovi resursi
podrazumevaju serversko vreme ili mrežni prostor, fizički prostor na skladišnim
uređajima, kojima se pristupa bez potrebe za ljudskom intervencijom bilo kod
klijenta, ili kod servis provajdera usluga).
• Širok spektar mogućnosti mrežnog pristupa (Mogućnosti sistema dostupne su
klijentima putem mreže i može im se pristupiti sa različitih uređaja, kao što su
desktop računari, mobilni telefoni, smartphone i tablet uređaji).
• Alokacija resursa (Računarski resursi provajdera su grupisani kako bi opslužili
veliki broj istovremenih korisnika). Mehanizam raspodele procesorske snage, ili
količine memorije, funkcioniše tako što sistem dinamički vrši raspodelu ovih
parametara prema zahtevima korisnika. Sami korisnici nemaju kontrolu nad
fizičkim parametrima, odnosno nad lokacijom resursa, ali na nekim višim
nivoima podešavanja svog sistema u okviru Cloud rešenja mogu da izaberu gde
će njihovi podaci biti smešteni i procesirani (na primer geografski položaj data
centara).
• Elastičnost i fleksibilnost sistema (Mogućnosti Cloud rešenja mogu u veoma
kratkom vremenskom periodu da budu dostupne korisniku sistema, ukoliko on
ima potrebu za tim. Pretpostavimo da se naš sajt nalazi u oblaku i da nam je
promet u smislu broja posetilaca sličan svakoga dana. Zatim, pretpostavimo da
jednog dana, iz nekog razloga, posećenost veb-prezentacije skoči za 100%.
Ukoliko je sajt hostovan na našem, privatnom serveru, postoji velika mogućnost
da se on jednostavno „sruši“ i prestane sa radom, zbog softverskih i hardverskih
ograničenja. U takvim slučajevima, Cloud dinamički dodeljuje potrebne resurse
kako bi obezbedio nesmetano funkcionisanje, a kada promet ponovo opadne,
resursi se automatski vraćaju u prvobitno stanje. Korisnik može da kupuje
dodatne resurse i mogućnosti u bilo kojim količinama i bilo kada).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 24
• Merljiva usluga - plaćanje po utrošku (Cloud sistemi automatski kontrolišu i
optimizuju neophodne resurse u zavisnosti od potreba korisnika i tipa usluge
koja se traži (prostor na disku, procesorska snaga, količina RAM-a i slično). Sve
ove usluge su merljive i njihovo korišćenje je transparentno, kako za provajdera,
tako i za klijente. To je veoma važno jer finansijski momenat igra veliku ulogu
kad je u pitanju ova nova tehnologija, naročito za velike, enterprise sisteme i
kompanije).
Postoje tri servisna modela:
• Software as a Service – SaaS (SaaS omogućava klijentima da koriste usluge
podešavanja i korišćenja aplikacija koje se nalaze na infrastrukturi pružaoca
usluga. To znači da provajder obezbeđuje potreban hardver (serveri, memorije,
procesori i sl.), kao i aplikaciju koja je klijentu potrebna. Njoj može da se
pristupa preko različitih uređaja i interfejsa, kao što je veb Browser (Internet
Explorer, Mozilla Firefox, Chrome, Safari, Opera…). Primer ovog modela je
webmail, kao što su Yahoo ili G-Mail. Kod ovog modela, korisnici nemaju
kontrolu nad konfiguracijom hardvera i softvera koji koriste).
• Platform as a Service – PaaS (Cloud platforma kao usluga predstavlja model u
kome korisnici koriste aplikacije koje su kupili ili sami razvili, a u Cloudu
koriste platformu koja će njihovu aplikaciju podržati. U ovom slučaju, klijenti
nemaju kontrolu nad hardverom provajdera, već samo nad svojim softverom koji
se nalazi u Cloudu).
• Infrastructure as a Service – IaaS (Cloud infrastruktura kao usluga jeste model u
kome klijenti dobijaju na raspolaganje hardverske resurse i tehnologiju u vidu
procesorske snage, prostora na disku, operativnih sistema i slično. Ne postoji
mogućnost kontrole samog hardvera, ali moguće je upravljati operativnim
sistemima, prostorom na disku, aplikacijama, i u posebnim slučajevima odabrati
neke dodatne opcije provajdera, kao na primer Firewall, monitoring aplikacija i
hardverskih resursa).
Postoje četiri modela računarskog oblaka:
• Privatni Cloud (Privatna Cloud infrastruktura je u vlasništvu organizacije i
njome upravlja sama organizacija (kompanija) ili treća lica koja to rade za njih
(outsourcing). Ovakav model može da bude fizički smešten u okviru prostorija
organizacije ili dislociran na neko drugo mesto. IT infrastruktura se fizički
smešta u posebno tehnički definisane prostore koji se nazivaju data centri).
• Zajednički Cloud (Kod ovog modela, infrastruktura je deljena između nekoliko
organizacija i pruža podršku grupi organizacija (ili kompanija) koje dele iste
interese, kao što su misija i vizija, sigurnosna politika i slično. Kao i u
prethodnom slučaju, njime može biti upravljano od strane interno zaposlenog
osoblja ili kroz outsourcing model usluga).
• Javni Cloud (U ovom slučaju sistem je u posedu kompanije koja se bavi
prodajom Cloud usluga i dostupan je svim pojedincima i poslovnim subjektima.
Ovde se podrazumevaju svi servisi i usluge koji su putem globalne mreže javno
dostupni krajnjem korisniku bez obzira na njihovu lokaciju. Dobar primer su
socijalne mreže Facebook, Twitter).
• Hibridni Cloud (Model koji je sastavljen od dva ili više prethodno navedenih
Private, Community, Public u kome svaki od njih ostaje nezavisan, ali su
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 25
međusobno povezani prateći definisane standarde i procedure kako bi se
obezbedila mobilnost podataka između njih [88]. Tako, na primer, velika
kompanija može svoj sistem da drži većinom u privatnom oblaku, dok neke
poslovne funkcije može da prebaci u javni oblak, recimo slanje velikog broja e-
mail-ova, kako bi rasporedila opterećenje sistema prema svojim potrebama).
Prednosti virtualizacije su sledeće: uštede u prostoru i energiji, uštede u novcu i
vremenu, lakše proširivanje sistema, bolje iskorišćenje sistema, dugotrajna i pouzdana
platforma, lakše i jeftinije upravljanje, jednostavnije održavanje, fleksibilnost IT servisa
koji se nalaze na virtuelnoj infrastrukturi, visoka dostupnost, jednostavan i brz oporavak
aplikacija, jednostavna migracija i migriranje podataka, automatizovana procedura
oporavka servisa i aplikacija.
2.4.2 Standardizacija elektronskog poslovanja
Organizacija kao i tehnologija moraju se definisati, a definišu se u odnosu standarde
koji su usvojeni od strane za to ovlašćenih nadležnih institucija. U elektronskom
poslovanju vrši se:
Standardizovanje organizacionih procedura i dokumentovanje njihovog izvršenja
je regulisano u Srbiji JUS ISO standardom 9001 tj. Standardima za upravljanje
kvalitetom. Mogu biti aktuelni i drugi relevantni standardi usko povezani sa
predmetnom oblasti poslovanja.
Standardizovanje profesionalnih procedura rada i dokumentovanje njihovog
izvršenja doprinosi jasnom definisanju skupa podataka koji treba prikupljati i zaštititi.
Tehnološki standardi vezani za informacione tehnologije odnose se, na primer na
obavezu posedovanja licenciranih antivirusnih programa, korišćenje određenih
protokola prenosa, sprovođenje posebnih mera zaštite i slično.
Standardi iz oblasti predmetne informatike predstavljaju standarde koji regulišu
uvođenje informacionih tehnologija u predmetnu oblast elektronskog poslovanja i
odnose se na arhitekturu informacionog sistema, minimalne setove podataka, sadržaj
standardnih XML poruka za razmenu podataka u predmetnom poslovnom sistemu,
preporučene standarde za sigurnost, privatnost i poverljivost i preporuke za legistativu.
Standardizacija u oblasti upravljanja sigurnošću informacija postiže se uvođenjem
familije ISO/IEC 17799. standarda koju čine: osnove i rečnik pojmova, zahtevi, kodeks
postupaka (dobra praksa) za upravljanje sigurnosti informacija, uputstvo za
implementaciju, merenja u menadžmentu sigurnosti informacija, menadžment rizika
sigurnosti informacija . Standard se bazira na sledećim kategorijama koje pokrivaju
aspekte sigurnosti informacija: sigurnosna politika, organizacija za sigurnost
informacija, upravljanje resursima, sigurnost ljudskih resursa, fizička sigurnost,
upravljanje komunikacijama i operacijama, kontrola pristupa, nabavka, razvoj i
održavanje informacionih sistema, upravljanje sigurnosnim incidentima, upravljanje
kontinuitetom poslovnih procesa, usklađivanje sa zakonskim i drugim propisima. Svaka
od navedenih sigurnosnih kategorija definiše sigurnosne ciljeve kao i kontrole koje je
potrebno sprovesti da bi se ispunili ti ciljevi. Važno je napomenuti da se kontrole
definišu kao: način upravljanja rizicima, što podrazumeva politike, procedure, uputstva,
organizacione strukture koje mogu da budu administrativne, tehničke, upravljačke ili
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 26
pravne. Paralelno sa ovim standardom razvijan je standard (ISO/IEC 27001) koji
definiše zahteve koje menadžment sistem za sigurnost informacija mora da zadovolji i
po kome se sprovodi i sertifikacija ako se to zahteva. Ovi zahtevi baziraju se na
ciljevima i kontrolama (dobroj poslovnoj praksi) koje su definisane u standardu
ISO/IEC 17799. Ceo koncept sigurnosti informacija koji je definisan u standardima
ISO/IEC 27001 i ISO/IEC 17799 bazira se na konceptu upravljanja rizicima. Ocena
rizika je definisana kao ocena pretnji informacijama (pretnje koje dovode do povrede
poverljivosti, integriteta i raspoloživosti informacija) njihovog uticaja na informacije i
na ranjivost (slabost) informacija i informacionih sistema, kao i verovatnoće njihove
pojave.
2.4.3 Standardizacija elektronskog poslovanja platnih sistema
Standardizacija elektronskog poslovanja platnih sistema odvija se u tri osnovna pravca:
1. Harmonizacija zakonske regulative sa inovacijama na finansijskom tržištu,
koja se uglavnom ogleda na najnovijim inicijativama Evropske unije u skladu sa
ISO20022 standardom [98] u čijoj specifikaciji učestvuju sve vodeće finansijske
institucije;
2. Usklađivanje standarda na nivou semantičke interoperabilnosti: UNIFI
(ISO20022) poruke u sebi sadrže elemente svih relevantnih standarda dobijenih
reverznim inženjeringom i tako igraju ključnu ulogu u konvergenciji ostalih
standarda ka jedinstvenom, opšteprihvatljivom standardu. Na slici 2. prikazana
je uloga UNIFI osnovnog platnog modela. Sa slike je vidljivo da univerzalni
standard za finansijske poruke ima zadatak da bude kopča između prikazanih
standarda, odnosno, da prevodi sintaksu jednog standarda u drugi, te tako učini
poruke jednog standarda prepoznatljivim od strane drugog standarda. Iterativnim
izmenama u ostalim standardima vremenom bi svi standardi konvergirali ka
jedinstvenom UNIFI standardu, a do pojave jedinstvenog svetskog standarda svi
finansijski sistemi implementirani na osnovama različitih standarda mogli bi da
sadejstvuju.
3. Pooštravanje standarda za upravljanje informacionim sistemima
finansijskih institucija u skladu sa standardima ISO2700x.
Slika 2. Radovi u smeru sadejstva i konvergencije u standardizaciji XML poruka
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 27
Najvažnija inicijativa u standardizaciji elektronskog poslovanja platnih sistema koja će
biti preovlađujuća i u budućnosti jeste ISO20022 [99], [113]. ISO je mreža nacionalnih
institucija za standardizaciju. Internacionalni standard ISO 20022 je inicijalno priređen
od strane Tehničkog komiteta ISO TC68.
Slika 3. ISO20022 repozitorijum sa rečnikom podataka
ISO 20022 - UNIversal Financial Industry Message scheme (UNIFI) je internacionalni
standard koji definiše ISO platformu za razvoj finansijskih standarda, prezentuje
finansijske poslovne modele i pripadajuće transakcije. U tu svrhu razvijen je i
repozitorijum kao i skup standardizovanih šema poruka koje se nalaze na ISO20022
sajtu. Katalog poslovnih procesa i rečnik podataka prikazan na slici 3. jesu osnovni
segmenti ISO20022 repozitorijuma na kome počiva i sam standard. Rečnik podataka,
prikazan na desnoj strani slike 3. sadrži: poslovne koncepte sa semantikom poslovnih
procesa, koncepte poruka izgrađenih od kombinacija korišćenih objekata rečnika
podataka i tipove podataka objekata koji nedvosmisleno određuju skup dozvoljenih
vrednosti poslovnih elemenata i elemenata poruka. Katalog poslovnih procesa prikazan
je na levoj strani slike 3. i organizovan je po poslovnim područjima. Poslovna područja
(na primer poslovanje sa hartijama od vrednosti ili plaćanja) opisuju se korišćenjem
poslovnih procesa koji su podržani odgovarajućim poslovnim transakcijama. Poslovne
transakcije u katalogu poslovnih procesa zadaju se dijagramima toka. Dijagram toka
sadrži jednu ili više poruka. Svaka poruka je zadata definicijom koja je predstavljena i u
obliku odgovarajuće ISO20022 xsd šeme. Nabrojane artifakte ISO20022 repozitorijuma
možemo pronaći u dokumentaciji ISO20022 standarda, unutar sekcije „Catalogue of
UNIFI messages” za svako poslovno područje i to u obliku formalnog opisa strukture
poruka i xsd šeme odgovarajuće poruke.
2.4.4 Ograničenja standardizacije
Standard predstavlja sporazum, a u najboljem slučaju, sporazum predstavlja kompromis.
Pokušaj da se sve strane saglase oko istih procesa ili rečnika za sve njihove aktivnosti
jeste težak, ako ne i nemoguć posao [30]. Moguće je postići saglasnost oko opštih
metoda i prihvatljivih razlika za kreiranje i implementaciju poslovnih procesa. Do sada
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 28
je kreirano više standarda, koji se bave različitim fazama razvoja sistema elektronskog
poslovanja, ali većina njih imala je ograničen uspeh. Veliki broj standarda je složen, što
je dovelo do nerazumevanja njihovog značenja. Posledice su nekompatibilnost
implementacija i pored činjenice da su standardi korišćeni. Problem sa korišćenjem
standarda je i taj što ih je previše. Neki standardi nisu dobro definisani ili se preklapaju
sa drugim standardima, koje istovremeno predlažu konkurentske organizacije.
Dešavanja oko standarda zbunjuju potencijalne korisnike i oni odlažu njihovo usvajanje
i primenu, bar dok neki standard ne postane šire prihvaćen [173].
Problem može nastati i što se podržavanjem jednog standarda nenamerno sprečava
prihvatanje nekog drugog, alternativnog standarda. Standard nema operativni značaj sve
dok se partneri ne usaglase kako da obavljaju posao na način definisan prihvaćenim
standardom. Suština je da je posao, a ne standard, od kritične važnosti. Primena
standarda je suštinski važna jer, osim obezbeđenja interoperabilnosti, uvodi pojedina
rešenja, koja doprinose razvoju poslovanja [30]. Povoljna okolnost je da distribuirano
računarstvo trenutno prolazi kroz period tranzicije, od vlasničkog pristupa ka pristupu
zasnovanom na standardima. Ipak, veći deo današnje tehnologije još uvek je vlasnički,
što uslovljava kupovinu različitih softverskih proizvoda od istog isporučioca, da bi se
omogućila integrisanost i kompatibilnost.
Da bi se obezbedila neophodna interoperabilnost sistema elektronskog poslovanja,
potrebno je koristiti novi koncept pri definisanja standarda. Postojeća standardizacija
bila je prihvatljiva u vreme paketne obrade informacija. Aktuelni standardi su veoma
kompleksni. Definišu samo razmenu podataka i način razmene podataka. Umesto toga,
potrebno je da se kreiraju standardi koji će na jednostavan način definisati
dokumentovanje: šta, kada i zašto je potrebno da se informacije razmenjuju u realnom
vremenu i u elektronski prihvatljivom format [153]. Neki od uočenih problema sa
standardima za modelovanje elektronskog poslovanja su [103]:
• Postojanje više standarda koji se preklapaju.
• Postojanje više organizacija za definisanje standarda.
• Postojanje različitih stavova o proširenju standarda.
U situaciji kada se određeni standardi izaberu i koriste, dešava se da se ne koriste
adekvatno. Razlog su neprecizna tumačenja, a posledica su problemi pri ostvarivanju
interoperabilnosti sa drugim sistemima i ograničenja kod njihovog naknadnog
korišćenja, prilikom proširenja delova sistema. Korišćenje standarda može da ima veliki
uticaj na interoperabilnost organizacija. Međutim, mnogi standardi još uvek su na
konceptualnom nivou, zbog čega nije moguća jednostavna implementacija na
operativnom nivou [232]. Zato je neophodan dalji rad na standardima u oblasti jezika i
podržanih platformi, posebno na kreiranju i izvršavanju modela poslovnog procesa.
2.5 Koncept interoperabilnosti
Razvoj informaciono-komunikacionih tehnologija omogućio je prelaz sa samostalnih
(stand alone) arhitektura na tzv. umrežene arhitekture informacionih sistema. Danas se
umreženi IT sistemi oslanjaju na infrastrukturu World Wide Web-a (WWW) koja
predstavlja tehnološku okosnicu elektronskog poslovanja omogućavajući različite
poslovne procese i povezivanja unutar i van granica nekog sistema. Sa stanovišta
tehnološke infrastrukture i softverske arhitekture sistemi predstavljaju heterogeno
okruženje koje se velikom brzinom razvija. Sposobnost različitih informacionih sistema
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 29
da rade zajedno - interoperabilnost jeste ključni faktor uspešnog elektronskog
poslovanja [118].
Pojam interoperabilnosti, u opštem slučaju, odnosi se na sposobnost dva sistema da
međusobno razmenjuju informacije. Ima mnogo pokušaja da se definiše šta
interoperabilnost znači. Neke od najcitiranijih definicija interoperabilnosti iz kojih se
mogu izvesti zajedničke karakteristike interoperabilnosti jesu [124]:
• sposobnost za saradnju. (The ability to operate in conjunction) (Oxford
Dictionary, 2003);
• sposobnost da dva ili više sistema, ili komponenata razmene informacije između
sebe i da nakon toga te iste informacije mogu da koriste. (The ability of two or
more systems or components to exchange information and to use the information
that has been exchanged) (IEEE, 1990);
• sposobnost komunikacije, izvršavanja programa, ili prenosa podataka između
različitih funkcionalnih jedinica na način koji zahteva da korisnici imaju malo ili
nimalo znanja o jedinstvenim karakteristikama tih jedinica. (The capability to
communicate, execute programs, or transfer data among various functional
units in a manner that requires the user to have little or no knowledge of the
unique characteristics of those units) (ISO, 2003);
• stanje postignuto između komunikaciono-elektronskih sistema ili delova
komunikaciono-elektronske opreme kada informacije ili usluge mogu da se
razmenjuju direktno i na zadovoljavajući način između njih i/ili njihovih
korisnika. (The condition achieved among communications-electronics systems
or items of communications-electronics equipment when information or services
can be exchanged directly and satisfactorily between them and/or their users)
(dod, 2001);
• sposobnost deljenja i razmene informacija korišćenjem zajedničke sintakse i
semantike da bi se omogućile specifične funkcionalne veze aplikacija. (The
ability to share and exchange information using common syntax and semantics
to meet an application-specific functional relationship) (ISO, 2000);
• sposobnost da dva ili više sistema ili komponenata razmenjuju i koriste deljene
informacije. (The ability of two or more systems or components to exchange and
use shared information) (Open Group, 2000);
• sposobnost sistema da pružaju i koriste servise-usluge od strane drugih sistema i
da korišćenjem tako razmenjenih servisa omoguće efikasan zajednički rad. (The
ability of systems to provide and receive services from other systems and to use
the services so interchanged to enable them to operate effectively together)
(Open Group, 2000);
• sposobnost zasebnih i različitih organizacija da sarađuju u smeru postizanja
zajednički korisnih i dogovorenih ciljeva, što uključuje razmenu informacija i
znanja kroz poslovne procese koje podržavaju, putem razmene podataka između
njihovih IKT sistema. (Interoperability is the ability of disparate and diverse
organisations1 to interact towards mutually beneficial and agreed common
goals, involving the sharing of information and knowledge between the
organizations via the business processes they support, by means of the exchange
of data between their respective information and communication technology
(ICT) systems) (European Interoperability Framework - EIF v2.0, 2008) [65].
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 30
Prema navedenim definicijama interoperabilnost karakterišu sledeća svojstva:
• uključenost dva ili više entiteta (sistema, mreža, uređaja, aplikacija ili
komponenata);
• sposobnost za interakciju (npr. zajednički rad, međusobna komunikacija,
razmena podataka, informacija i znanja, pružanje i prihvatanje servisa-usluga);
• korisnici treba da imaju malo ili nimalo znanja o jedinstvenim karakteristikama
entiteta koji rade zajedno;
• smisao je u postizanju nekog cilja (efikasan zajednički rad, funkcionalno
povezivanje različitih aplikacija, razmena i korišćenje informacija i usluga).
Interoperabilnost zahteva određeni stepen kompatibilnosti između sistema koji
razmenjuju informacije kako bi se minimizovale transformacije koje se zahtevaju kod
razmene podataka i kako bi se obezbedili preduslovi za korektnu interpretaciju prenetih
podataka. Idealna situacija je da su sistemi koji učestvuju u procesu međusobnog
elektronskog poslovanja usaglašeni sa standardnima iz odgovarajućeg aplikacionog
domena. Međutim, u praksi je to uglavnom nemoguće ostvariti zbog brzine tehnoloških
promena, nedostatka univerzalno prihvaćenih standarda, postojanja zastarelih sistema ili
jednostavno zbog postojanja autonomije svakog od sistema. Zahtevana kompatibilnost
se može ostvariti korišćenjem apstrakcija kojima će se sakriti kompleksnost i
implementacioni detalji.
Da bi se obezbedilo efikasno elektronsko poslovanje sistema i pružanje usluga
korisnicima, neophodno je obezbediti nesmetan tok i razumevanje informacija. Za
realizaciju tog zahteva potrebno je definisati tehničke specifikacije i rešenja za
ostvarivanje međuoperativnosti i koherentnosti informacionih sistema. Pored toga,
potrebno je obezbediti uniforman način komunikacije između aplikacija sistema i
spoljnih, pre svega poslovnih sistema u okviru zemlje, kao i na međunarodnom nivou.
Definisanje tehničkog okvira za razmenu podataka i implementacija usvojenih
specifikacija u aplikacijama omogućila bi efikasnu razmenu podataka između bilo kojih
aplikacija koje podržavaju date specifikacije direktno, i bez potrebe bilo kakvog
specifičnog prilagođenja aplikacija. Time bi se postigao cilj - nesmetan protok i
razumevanje informacija kroz celi sistem, što bi efektivno značajno povećalo vrednost
instaliranih aplikacija.
Često se pojam „interoperabilnost" pogrešno izjednačava sa pojmom „integracije
sistema". Integracija u okviru preduzeća odnosi se na: fizičku integraciju (povezivanje
uređaja i mašina preko računarskih mreža); integraciju aplikacija (integracija
softverskih aplikacija i sistema baza podataka) i poslovnu integraciju (koordinacija
funkcija za upravljanje i nadgledanje poslovnih procesa). Sa stanovišta povezanosti,
integrisani sistemi čvrsto su povezani, odnosno njihove komponente međusobno su
zavisne i ne mogu biti izdvojene. Za razliku od integrisanih sistema, interoperabilni
sistemi slabo su povezani [159]. Dva integrisana sistema implicitno su interoperabilna,
međutim, dva interoperabilna sistema ne moraju biti istovremeno i integrisana [196].
Da bi se razumela priroda interoperabilnosti, potrebno je još naglasiti da
interoperabilnost nije nešto što se može trajno i u potpunosti postići. Promena i
unapređenje tehnologija, poslovnih procesa, razvoj standarda i sl. utiču na to da se na
interoperabilnosti stalno mora raditi i možemo samo govoriti da je u određenom slučaju
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 31
postignuta veća ili manja interoperabilnost sistema. Prema ovom shvatanju, za
interoperabilnost se može reći da je stalni proces koji treba da obezbedi da se
maksimizira mogućnost za razmenu i ponovno korišćenje informacija unutar nekog
sistemima i između različitih sistema [123].
Interoperabilnost je i preduslov i olakšavajući faktor sistemima za efikasno pružanje
usluga kojim se rešava potreba za:
• saradnjom između sistema i ostalih organizacija i institucija na nacionalnom i
međunarodnom nivou;
• razmenom informacija radi ispunjenja zakonskih uslova ili političkih obaveza;
• razmenom i ponovnom upotrebom informacija radi povećanja administrativne
efikasnosti i smanjenja administrativnih opterećenja na građane i poslovne
subjekte.
Od područja poslovanja i ciljane grupe korisnika zavise i standardi koji su od interesa za
interoperabilno elektronsko poslovanje. Postoji niz okvira za interoperabilnost od kojih
je svaki baziran na 10-20 arhitektonskih principa [175].
Okvir interoperabilnosti može se definisati kao skup standarda i smernica koji opisuje
način na koji su se organizacije usaglasile ili bi trebalo da se usaglase da će uzajamno
poslovati. Okvir interoperabilnosti nije statički dokument, već se sa vremenom mora
prilagođavati promenama tehnologija, standarda i administrativnih zahteva [63].
Referentni dokument za područje interoperabilnosti u Evropi je Evropski okvir za
interoperabilnost EIF 1.0 [63] koji je napravljen u svrhu koordinisanja IDABC programa
(Interoperable Deliveri of European eGovernment Services to public Administrations,
Businesses and Citizens). Na snazi je verzija 1.0 iz novembra 2004, a intenzivno se
raspravlja o usvajanju verzije 2.0, koju je sredinom 2007. pripremio Gartner [64], a koja
je predstavljena u decembru 2010.
Osim Evropskog okvira za interoperabilnost postoji niz nacionalnih okvira za
interoperabilnost u Evropi i svetu koji sadrže konkretne preporuke važećih standarda.
Neki od njih su: HKSARG IF (Hong Kong) [91], AGTIF (Australija), eGIF (Velika
Britanija) [217], EstIF (Estonija) [59], Nora (Nizozemska) [62], OIO (Danska) [50],
FEA (Sjedinjene Američke Države) [226] itd. Agendom Plus za elektronsku
Jugoistočnu Evropu (eSEE Agenda+) interoperabilnost je prepoznata kao jedna od
ključnih aktivnosti u okviru oblasti Jedinstveni informacioni prostor jugoistočne
Evrope. U vezi sa tim, obaveza zemalja regiona je usvajanje nacionalnog okvira
interoperabilnosti za administracije, kako bi se osigurala kompatibilnost i saradnja
sistema, procesa i ljudskih resursa i kako bi se omogućio nesmetano poslovanje na
panevropskom nivou i pružili servisi usmereni na korisnike [58].
Prvi nivo interoperabilnosti obuhvata tehničke aspekte povezivanja informacionih
sistema kao što su specifikacije interfejsa, usluge povezivanja, usluge integracije
podataka, predstavljanje i razmena podataka itd. Tehnička interoperabilnost treba da se
obezbedi kada je god to moguće korišćenjem opšteprihvaćenih i otvorenih standarda
usvojenih od strane priznatih organizacija za standardizaciju [63]. U okviru tehničke
interoperabilnosti mogu se razlikovati: komunikaciona interoperabilnost i sintaksna
interoperabilnost. Komunikaciona interoperabilnost zavisi od infrastrukture i
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 32
standardizovanih protokola koji su unapred precizno definisani (npr. enkapsulacija,
okviri, algoritmi za proveru grešaka itd.). Ova interoperabilnost može biti ostvarena
primenom OSI (Open Systems Interconnection) referentnog modela koji definiše
komunikacione slojeve i protokole pomoću kojih mogu da komuniciraju različiti
računari i sistema, slika 4.
Tehnička interoperabilnost
Komunikaciona
interoperabilnost (OSI)
Sintaksna interoperabilnost
Semantička interoperabilnost
Procesna interoperabilnost
Slika 4. Tri osnovna nivoa interoperabilnosti
Sintaksna interoperabilnost obezbeđuje razmenu sadržaja između različitih sistema ili
softverskih komponenata nezavisno od jezika u kome su iste implementirane, runtime
okruženja i drugih tehnoloških razlika. Sintaksna interoperabilnost služi premošćivanju
jaza između formata podataka, standarda jezika, operativnih sistema i hardverskih
platformi. Ostvaruje se uspostavljanjem i prihvatanjem zajedničkog formata (sintakse)
prezentacije podataka. Najrašireniji sintaksni standard za ostvarivanje ovog nivoa
interoperabilnosti jeste XML jezik za prezentaciju podataka. Semantička
interoperabilnost je sposobnost organizacije i njihovih informacionih sistema da otkriju
zahtevane informacije, eksplicitno opišu značenje podataka koje žele da dele sa drugim
organizacijama i procesiraju informacije u skladu sa njihovom svrhom.
Problem interoperabilnosti javlja se kada se dva poslovna sistema ili više poslovnih
sistema, nađe u međusobnoj vezi. Postojeći softverski sistemi sastavljeni su od
aplikacija, koje su razvijane u različitim periodima, od strane različitih razvojnih
timova, koji su najčešće radili bez stvarne koordinacije. Pored toga, za razvoj aplikacija
korišćene su različite tehnologije. U većini slučajeva, nove aplikacije kreiraju se
korišćenjem, u tom momentu, najnovijih tehnologija, često bez kritičkog odnosa prema
neophodnosti implementacije baš najnovijih tehnologija. Zaboravlja se da nova,
trenutno aktuelna tehnologija postaje zastarela kroz određeni vremenski period. Takođe,
većina ranijih aplikacija nije dizajnirana da komunicira sa drugim aplikacijama.
Korišćenje komercijalnih softverskih paketa povećava problem s obzirom na to da su
dizajnirani da određeni problem rešavaju uopšteno. U toj situaciji, za povezivanje
aplikacija potrebno je kreirati prilagođene linkove i interfejse.
Posmatrana na ovaj način, interoperabilnost je cilj koji treba dostići. Iz praktične
perspektive, bez obzira na brojnu literaturu koja se bavi problemima interoperabilnosti,
istraživanja su još uvek u ranoj fazi. Neki od problema, koje je potrebno i dalje rešavati,
jesu [173]:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 33
• korišćenje standarda ne garantuje uvek postizanje interoperabilnosti;
• primena principa projektovanja ne garantuje uvek postizanje interoperabilnosti;
• sveobuhvatno rešavanje zaštite informacija i bezbednosna pitanja u celoj
organizaciji, koja su od ključnog značaja za obezbeđivanje pouzdanih
elektronskih poslovnih odnosa i saradnje;
• pitanja izvan domena tehnike, kao što su: komunikacija na kulturnom i ljudskom
nivou i interakcije računara i domena specifičnih znanja, dokazano je da mogu
postati prepreka u postizanju interoperabilnosti;
• potreba da se analizira i oceni interoperabilnost sama po sebi;
• brz razvoj tehnologije može da smanji stepen interoperabilnosti sistema ukoliko
se zahtevi za interoperabilnošću ne razmatraju na nivou dizajna.
Posmatrano iz različitih perspektiva, postoji nekoliko načina za postizanje
interoperabilnosti. Opšteprihvaćeni načini za rešavanje problema interoperabilnosti su:
standardi, okviri za interoperabilnost, okviri za arhitekturu informacionih sistema
preduzeća, semantičke tehnologije zasnovane na ontologijama i servisna orijentacija.
2.6 SOA i organizacije za standardizaciju elektronskog poslovanja
Modelom vođena integracija (model driven integration) je pojam koji označava
automatizovanu ili poluautomatizovanu integraciju heterogenih sistema uz pomoć
apstraktnih modela opisanih najčešće u UML-u. Osnovna ideja je postojanje
infrastrukture koja skladišti standardizovane opise informacionih sistema i korišćenje
predefinisanih interfejsa, koja bi iz takve infrastrukture mogla prikupljati i obrađivati
podatke i na taj način prikupiti dovoljno znanja o svojoj okolini kako bi automatska ili
poluautomatska integracija s okolnim aplikacijama i sistemima bila omogućena.
Pokretač integracije je deljenje podataka, a da bi se podaci mogli razmenjivati i deliti
oni moraju odgovarati zajedničkom modelu. Taj model pružaju upravo metapodaci.
Metapodaci se definišu kao podaci koji opisuju druge podatke, najčešće u kontekstu
elemenata informacionih sistema. U početku su metapodaci korišćeni za stvaranje
dokumentacije projekata. Globalnim prihvatanjem UML standarda metapodaci su
postali osnovni alat za modelovanje sistema, tj. stvaranje apstraktne, ali precizne slike
sistema. Metapodaci su i sredstvo integracije heterogenih sistema. Jedan od problema s
integracijom je činjenica da još uvek nema široko prihvaćene metodologije koja stvara
uspešnu sinergiju tehnologija sa potencijalima integracije uz pomoć normalizovanih
metapodataka. Implementacija arhitekture SOA (Service Oriented Architecture –
servisno orjentisana arhitektura) [126] zasnovane na vebu i XML-u najčešće se izvodi
na najnižem metanivou, tj. modeliranjem sistema u zavisnosti of konkretne poslovne
okoline i zadatog problema, s minimalnim osvrtom na potencijalno dostupne
metapodatke koji opisuju zadate komponente sistema. Upravo metapodaci najčešće u
sebi sadrže informacije ključne za integraciju sistema, pogotovo s obzirom na dizajn
komponenata sa kojima bi se ta integracija sprovela. Servisno orijentisana arhitektura
(SOA – Service Oriented Architecture) je pojam koji najčešće označava infrastrukturni
model sistema čija je funkcionalnost zasnovana na međusobno interoperabilnim
„uslugama", tj. funkcionalnim entitetima koji kolaboriraju kroz zajednički definisane
standarde. Egzaktna SOA definicija ne postoji, pa čak ni konsenzus oko toga da li
pojam označava samo paradigmu, model sa svojstvima i smernicama kojih se pri
implementaciji treba pridržavati ili čak strogo definisani skup tehnologija koje zajedno
čine okosnicu servisno orijentisane arhitekture. Ključne karakteristika sistema SOA,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 34
koje se najčešće spominju u svim definicijama, jesu modularnost, distribuiranost i slaba
povezanost.
Poruka se u servisno orjentisanoj arhitekturi definiše kao „nezavisna jedinica
komunikacije“. To znači da entitet koji pošalje poruku više nema kontrolu nad njom niti
nad aktivnostima koje će se nad njom kasnije dogoditi. Analogno adresi na pošiljci,
poruka u sistemu servisno orjentisane arhitekture mora sadržati informacije pomoću
kojih se ona može usmeriti na željenu adresu i omogućiti primanje odgovora ako je to
potrebno. Principi dizajna usluga i poruka predstavljaju vrlo bitan segment pojma
servisno orjentisane arhitekture. Neki od tih principa su:
• slaba povezanost - radi se o uspostavljanju takvog tipa odnosa - između samih
usluga, ali i usluga i korisnika - koji minimizira međuzavisnost i potrebna je
samo svest o međusobnom postojanju;
• ugovor o komunikaciji - svaka usluga mora se prilagoditi definisanim
standardima, tj. ugovoru o komunikaciji, čiji se detalji mogu opisati na određeni
način u specifikaciji usluge;
• autonomija - usluge imaju apsolutnu kontrolu nad poslovnom logikom koju
sadrže u sebi;
• apstrakcija - sve informacije koje usluga pruža o sebi nalaze se u specifikaciji
usluge; sama;
• implementacija je sakrivena od okruženja;
• ponovna iskoristljivost - usluga može biti deo većeg broja poslovnih procesa, a
njena funkcionalnost ne mora biti prilagođena samo posebno odabranoj prilici,
već se kao univerzalna može prema potrebi ponovno koristiti;
• modularnost - skupovi usluga moraju se modularno kombinovati u poslovnim
procesima i/ili šire definisane usluge;
• nepostojanje stanja - usluga mora minimizirati informacije koje su specifične za
pojedini slučaj upotrebe;
• mogućnost pronalaženja usluge - usluge se stvaraju tako da se mogu opisati
preko definisanih mehanizama kako bi se informacije o njima mogle na
adekvatan način pronaći i kako bi im se moglo pristupiti.
Ono što je ključno naglasiti jeste činjenica da je pojam uslužno orjentisane arhitekture
tehnološki nezavisan – principi koje definiše su generički i za implementaciju
funkcionalnosti je potrebno odabrati konkretnu platformu.
U šezdesetim godinama prošlog veka razvijen je jezik zvan SGML (Standard
Generalized Markup Language). Originalna ideja razvoja ovog jezika bila je stvaranje
načina reprezentacije informacije koju će kompjuteri moći da interpretiraju i koji bi bio
relativno postojan s obzirom na izmenu i evoluciju tehnologije. Nakon prihvatanja od
strane organizacije ISO (International Organization for Standarization) jezik je vrlo
dobro prihvaćen kao metajezik pomoću koga se mogu definisati dokumenti zasnovani
na oznakama za različite primene u tadašnjoj informatičkoj tehnologiji. Navedena ideja
markup jezika uvodi anotaciju informacije unutar dokumenta dodatnim podacima koji
mogu poslužiti kao metapodaci, uputstva za način prikaza i drugo. Najpopularniji
naslednici jezika SGML su jezik HTML (HyperText Markup Language) i XML
(eXtensible Markup Language). Specifikacija XML-a predstavlja pojednostavljeni
podskup SGML-a, dizajniran na način da omogući implementaciju jednostavnijih
parsera. XML veliku popularnost dostiže sredinom devedesetih godina kada se Internet
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 35
polako počinje prepoznavati kao idealna platforma za moderno elektronsko poslovanje.
Pomoću XML-a aplikacije imaju mogućnost uobličavanja poslovnih informacija na
platformski neutralan način prilagođen i ljudskom razumevanju (pošto je zasnovan na
tekstu a ne binarnom kodiranju) i kompjuterskoj obradi (zbog strogo definisane
sintakse). Dodatne specifikacije kao što je XML Schema (koja omogućuje definisanje
ograničenja nad strukturom XML dokumenata i tipovima podataka koje sadrže) i XSLT
(koja omogućuje transformaciju XML dokumenata iz jedne u drugu XML strukturu
dokumenta, ali i u druge formate) još više pospešuju univerzalno prihvatanje XML-a.
Godine 2000. organizacija W3C (World Wide Web Consortium) prima zahtev za
ratifikacijom specifikacije nazvane SOAP (Simple Object Access Protokol – jednostavni
protokol za pristup objektima). Prvobitna namena ove specifikacije bila je
standardizacija postupka poziva udaljenih metoda (RPC – Remote Procedure Call).
Glavna ideja je kodiranje parametara poziva u XML dokument, transport dokumenta, te
dekodiranje na strani primaoca u oblik koji primalac može razumeti.
Proizvođači softvera su uočili potencijal ovog standarda koji uz jezik XML i internet
protokole predstavlja kvalitetan gradivni blok za razvoj distribuiranih aplikacija za
elektronsko poslovanje zasnovanih na vebu. Ovaj koncept nazvan je veb-servis. Ključni
segment veb-servisa bio je javni interfejs kome se može pristupiti preko internet
protokola. Zbog toga je jedna od prvih inicijativa bila razvoj jezika za opis tog
interfejsa, odnosno specifikacija WSDL (Web Services Description Language – jezik za
opis usluga veba). Iako se veb-servisi ne ograničavaju na SOAP protokol, on je ipak
postao jedan od najšire prihvaćenih protokola u konkretnim implementacijama.
Treća komponenta (pored komunikacijskog protokola i standardizacije načina opisa
usluga) koja je uokvirila specifikaciju veb-servisa jeste specifikacija UDDI (Universal
Description, Discovery and Integration). Ova specifikacija pružila je način stvaranja
registara u kojima se mogu čuvati i taksonomski organizovati opisi veb-servisa.
Softverska industrija ga za sada nije preterano dobro prihvatila tako da arhitektura SOA
danas još uvek registar usluga smatra uglavnom opcionom komponentom sistema.
Rešenja za razmjenu poruka (message-oriented middleware ili MOM) uključila su
protokol SOAP u svoja rešenja zajedno s postojećim komunikacionim protokolima koja
su koristila; veliki poslovni sistemi razvili su vlastita prilagođena rešenja zasnovana na
veb-servisima kao alternativu EDI (Electronic Data Interchange) standardu; veb-servisi
su uzrokovali veliku popularnost modela nove arhitekture za realizaciju informacionih
sistema – servis orjentisanu arhitekturu ili SOA.
Sve moderne implementacije SOA oslanjaju se na SOAP kao osnovni komunikacioni
protokol; postupak modelovanja poslovnih dokumenata u pripadne XML dokumente i
njihove XSD sheme sada često mora uzimati u obzir i postojanje SOAP-a i njegovih
karakteristika. SOA stavlja naglasak na razmenu poruka zasnovanu na dokumentima
(document-style messaging), što se razlikuje od početne primene Za SOA su pogodne
kontekstualno opširne inteligentne poruke umesto usko definisanih ciljno usmerenih
poruka kao kod poziva udaljenih metoda. Poruka treba imati sposobnost samostalne
egzistencije, mora da sadrži dovoljno informacija kako bi olakšala obradu kroz usluge i
tako omogućila autonomiju usluga i isključila potrebu za čuvanjem njihovog stanja.
Karakteristike i zahtevi savremenih SOA diktiraju proširenje specifikacije veb-servisa
kako bi se ti zahtevi mogli ispuniti; rezultat ove inicijative jeste nastanak tzv. WS-
proširenja (WS-extensions) – skupa specifikacija koje veb-servisima dodaju nove
mogućnosti kao npr. mehanizme sigurnosti, razmene metapodataka i slično [170].
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 36
Nove tehnologije elektronskog poslovanja obavezno uključuju kvalitet usluge (QoS –
Quality of Service). Zahtevi mogu biti: sigurnosni mehanizmi, pouzdanost isporuke ili
objavljivanje greške na adekvatan način, performanse sistema u skladu s očekivanjima,
tj. informatička struktura koja ne sme inhibirati sprovođenje poslovnih zadataka u
zadatim vremenskim okvirima, transakcijske mogućnosti tj. zaštita integriteta skupa
poslovnih procesa koji se moraju ili uspešno obaviti ili potpuno obustaviti.
W3C (World Wide Web Consortium) je internacionalna organizacija za donošenje
standarda osnovana 1994. koja se smatra jednim od glavnih učesnika u transformaciji
World Wide Web-a iz infrastrukture povezanih radnih stanica u globalni semantički
medijum za razmenu informacija. Uspeh W3C-a započinje izdavanjem specifikacije
jezika HTML bez koga je Internet današnjice nezamisliv. Kada se krajem prošlog veka
počeo uočavati potencijal Interneta kao glavne infrastrukturne tehnologije za
omogućavanje modernog elektronskog poslovanja, W3C donosi ključne standarde koje
bi takva rešenja podržali: specifikaciju XML, te srodne specifikacije, kao što su XML
šema i XSLT. Konačno, W3C je izdao specifikacije ključne za implementaciju usluga
veba – norme SOAP i WSDL. W3C je poznata kao organizacija čiji standardi prolaze
kroz mnoge revizije i recenzije koje se javno objavljuju kako bi se dobilo što više
korisnih povratnih informacija. To često ima za posledicu da se standardi često čekaju i
po nekoliko godina.
OASIS je internacionalna organizacija zadužena za norme poznata po preuzimanju WS-
BPEL specifikacije, normi ebXML i doprinosu pri nastanku specifikacije UDDI.
Organizacija OASIS doprinela je razvoju i proširenju XML-a kao standarda, a trenutni
veliki projekt jeste normizacija jedne od najvažnijih komponenti specifikacija proširenja
veb-servisa – okvira WS-Security zaduženog za sigurnosne mehanizme.
Dok W3C najčešće preuzima ulogu razvoja bazičnih standarda, OASIS se primarno
usredsređuje na proširenje tih standarda i njihovo vertikalno prilagođavanje različitim
industrijskim granama. Standardi grupe OASIS imaju kraći rok do objave od W3C
Standarda.
Organizacija WS-I osnovana je sa ciljem definisanja odgovarajućeg skupa standarda,
čijom se primenom omogućava interoperabilnost elektronskog poslovanja sistema koji
se pridržavaju preporuka koje daje WS-I. Počev od 2002. godine, kada je osnovana, ova
organizacija ima podršku od 200 organizacija uključujući neke od najvećih proizvođača
softvera koji se bave implementacijama arhitektura SOA.
WS-I je najpoznatija po izdavanju tzv. Osnovnog profila (Basic Profile) - dokumenta
koji predlaže skup standarda koji bi trebalo koristiti kako bi se osigurao maksimalan
mogući stepen interoperabilnosti unutar sistema. Ovaj dokument, između ostalog, sadrži
i preporuku tačno određenih verzija standarda WSDL, SOAP, UDDI, XML i XML Sheme
i kao takav ima važnu ulogu kod prilagođavanja arhitekture SOA na konkretna poslovna
rešenja (organizacije koje vrše prilagođavanja sistema obično naznače da je njihova
adaptacija „saglasna Osnovnom Profilu"). Nedavno je izdato i proširenje Osnovnog
Profila nazvano Osnovni sigurnosni profil (Basic Security Profile) koji sadržava - prema
mišljenju organizacije WS-I - skup najvažnijih tehnologija vezanih uz sigurnost XML-a i
veb-usluga. Uz navedene Profile WS-I nudi niz primera implementacija i alata koji
testiraju saglasnost sa Osnovnim profilom.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 37
U razvoju standarda značajnu ulogu imaju veliki proizvođači softvera kao što su Sun,
IBM [94], Oracle, Microsoft, Hewlett-Packard, Canon, Verisign itd. Interesi i doprinosi
velikih organizacija za navedene standarde doveli su do nekih zanimljivih uticaja na
oblik samih standarda i njihovu prihvaćenost, pogotovo ako se uzme u obzir da se
usprkos zajedničkom cilju interoperabilnosti, ovde radi o konkurentskim organizacijama
od kojih svaka ima svoje interese vezane za tržište softvera.
Uloga velikih kompanija je dvojaka. S jedne strane oni sarađuju u razvoju standarda,
dok s druge prihvaćenost njihovih rešenja utiče kako na uspešnost standarda tako i na
profit same kompanije. Zbog toga je uravnoteženje i optimizacija standarda sa politikom
kompanije i zahtevima tržišta osnovni strateški zadatak svake kompanije uključene u
saradnju. Nije nepoznat slučaj da nekoliko velikih kompanija osnuje vlastitu koaliciju i
tako proširi svoj uticaj unutar nezavisnih organizacija, iako se takve koalicije najčešće
koncentrišu na pojedinu ciljnu specifikaciju od koje sve imaju zajedničku korist (npr.
IBM, Microsoft i BEA su zajedničkim snagama izrazito podržavali razvoj i zaključenje
više specifikacija vezanih za tehnologiju proširenja veb-servisa - WS-extensions, kako bi
njihova najnovija rešenja mogla implementirati neke ključne mehanizme koji trenutno
nedostaju softverskim rešenjima zasnovanim na veb-uslugama). Ponekad takve koalicije
deluju kontraproduktivno - npr. Sun i Oracle su zajedno izneli specifikaciju za sigurnu
isporuku poruka nazvanu WS-Reliability, da bi Microsoft i IBM u isto vreme izdali svoju
specifikaciju za identičnu svrhu nazvanu WS-ReliableMessaging. Ovakvi primeri
pokazuju da autoritet organizacija za standarde još uvek nije toliko uticajan da bi mogao
garantovati jednaku poziciju svima na tržištu, otvorene standarde i interoperabilnost.
Tržišna politika, konkurencija i uticaj velikih kompanija iz tih razloga će uticati na broj,
oblik i prihvaćenost otvorenih standarda i interoperabilnost modernih rešenja
zasnovanih na arhitekturi SOA.
2.7 Sigurnost elektronskog poslovanja
U procesu elektronskog poslovanja mora se obezbediti okvir za siguran rad sa
informacijama. Ovo podrazumeva da se moraju preduzeti sve mere zaštite u
informacionim sistemima kako bi se minimizirala mogućnost gubitka informacija ili
njihovo neovlašćeno menjanje/korišćenje, što bi u određenim slučajevima moglo da
izazove nesagledive posledice. Zbog toga je potrebno razviti rešenja i definisati
postupke i mere koje će obezbediti informaciono-komunikacionu sigurnost i stvoriti
mehanizme za njihovu primenu. Ovo je od ključnog značaja jer se time stvaraju uslovi
da su elektronske transakcije pouzdane, zaštićene i sa zahtevanim stepenom
poverljivosti.
Preterano i neumereno fokusiranje na sigurnost može, s druge strane, da rezultuje
rešenjima koja su suviše rigidna, komplikovana i skupa i koja mogu predstavljati
prepreku za razvoj i primenu novih tehnologija. Primena i korišćenje novih
informacionih tehnika i proizvoda, kao i komunikacionih mreža jeste dinamički proces,
što zahteva permanentno i sistematsko sagledavanje mogućnosti pristupa administracije
kritičnim resursima, kvaliteta servisa i zaštitnih mehanizama. Dakle, neophodno je
permanentno procenjivati rizike s jedne strane i sigurnost sistema s druge strane i tražiti
izbalansirano rešenje. Sigurnosni mehanizmi takođe moraju da uzmu u obzir Zakon o
zaštiti ličnih podataka, i da onemoguće neautorizovano korišćenje ličnih podataka koji
su predmet zakonske zaštite.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 38
Postoje različite podele koje identifikuju najvažnije zahteve koje jedan sistem mora
ispuniti da bi se mogao smatrati sigurnim. Prema jednoj od najčešće primenjivanih
podela, najvažniji sigurnosni aspekti bilo kog informacionog sistema su: poverljivost,
integritet i dostupnost.
Poverljivost podrazumeva garantovanje da resursima mogu pristupiti samo i isključivo
autorizovani korisnici. To znači da samo oni koji treba da imaju pristup nekom resursu
zapravo i mogu da mu pristupe, s tim da se pristup ne ograničava na pregledanje,
čitanje, mijenjanje i slično, već i otkrivanje postojanja resursa.
Integritet podrazumeva da resursi mogu da budu promenjeni samo od strane
autorizovanih korisnika ili samo na autorizovan način. U ovom kontekstu, promena
uključuje kreiranje, menjanje, promenu statusa i brisanje resursa.
Dostupnost podrazumeva da resursi moraju biti dostupni legitimnim korisnicima, ako
imaju odgovarajuća pristupna prava, i ako resursima pristupaju na dobro definisan
način.
Da bi se obezbedili ovi sigurnosni aspekti, potrebno je obezbediti rešenja za utvrđivanje
identiteta korisnika (identifikacija i autentifikacija) i prava korisnika (autorizacija).
Računarske mreže zasnovane na TCP/IP (Transmission Control Protocol/Internet
Protocol) skupu komunikacijskih protokola u svom izvornom obliku ne vode računa o
zaštićenom prenosu podataka, kao ni o problemima utvrđivanja autentičnosti pošiljaoca.
TCP/IP komunikacijski protokol ima ugrađene mehanizme za otkrivanje i ispravljanje
grešaka pri prenosu podataka, ali o problemima zaštite privatnosti i tajnosti podataka ne
vodi računa. Drugim rečima, infrastruktura Interneta i svih mreža za zasnovanih na
TCP/IP skupu protokola garantuje pouzdan prenos podataka s izvorišta na odredište
(koliko je to moguće), ali podaci koji se šalju mogu biti vidljivi svakome ko je u
mogućnosti da presretne mrežnu komunikaciju. Podaci koji se prenose mrežom
podložni su promenama od strane napadača, pa je time narušena izvornost i
verodostojnost podataka. Za svaku ozbiljniju primenu komunikacije putem Interneta i
ostalih TCP/IP mreža ovi uslovi nisu prihvatljivi, pa su razvijene metode kriptovanja za
zaštitu podataka pre nego što se oni pošalju kroz mrežu.
2.7.1 Sigurnost i interoperabilnost
Interoperabilnost različitih sistema znači da se oni lako mogu povezati i da lako mogu
sarađivati. Da bi saradnja i interoperabilno elektronsko poslovanje različitih sistema bili
uspostavljeni, između ostalog, potrebno je te sisteme „otvoriti” jedne prema drugima.
To otvaranje u praksi najčešće je povezano otvaranjem prolaza u sigurnosnoj
infrastrukturi za legalne korisnike (koji se ponašaju na propisan način). Svako otvaranje
prolaza znači i narušavanje sistema bezbednosti i povećanje ranjivosti tog sistema. Sa
druge strane, veći stepen bezbednosti dovodi do zatvaranja sistema i otežanog
poslovanja. Drugi problem je što sistemi zaštite različitih poslovnih sistema mogu biti
toliko različiti da njihova međusobna saradnja može doći u pitanje. Iz tog razloga kada
se želi uspostaviti interoperabilno elektronsko poslovanje, mora se voditi računa i o
interoperabilnosti sistema zaštite koji treba da se bazira na opšteprihvaćenim
standardima.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 39
Kriptografske metode mogu da obezbede poverljivost i integritet poruke, ali ako
korisnik kome je upućena šifrirana poruka nije u stanju da je i dešifruje, ceo postupak
postaje besmislen i u praksi se često dešava da se poruke razmenjuju u čitljivom obliku.
Infrastruktura javnih ključeva (PKI - Public Key Infrastructure) može da obezbedi
sistem za utvrđivanje identiteta korisnika, ali ako svaka organizacija izgrađuje sopstveni
PKI bez uspostavljanja međusobnog poverenja, pojavljuje se problem sa
autentifikacijom. Mi danas umesto jedne identifikacione kartice imamo više
identifikacionih kartica: ličnu katu, karticu za svaku banku sa kojom sarađujemo,
personalizovanu karticu za kupovinu u lancu supermarketa itd. Za postizanje visoke
interoperabilnosti bilo bi potrebno da se uspostavi okruženje u kome sertifikati izdati
kod jednog provajdera mogu biti provereni i u drugom sertifikacionom sistemu.
Razlozi zbog kojih veći stepen interoperabilnosti može da utiče na niži stepen
bezbednosti su:
• tehnološki - strane u elektronskom poslovanju objektivno ne mogu da zasnivaju
poslovanje na istim standardima zbog heterogenosti informacionih sistema;
• politika poslovanja - postoji tehnološka mogućnost uspostavljanja sigurnog
interoperabilnog poslovanja, ali nije postignut dogovor o primeni odgovarajućih
standarda;
• nepostojanje odgovarajućih standarda;
• ljudski faktor, nemarnost, neznanje i drugi slični faktori.
2.7.2 Model zaštite resursa
Zaštita resursa je proces održavanja prihvatljivog nivoa rizika, a ne završno stanje, tj.
nije konačni proizvod. Organizacija ili institucija ne može se smatrati u potpunosti
zaštićenom ni u jednom trenutku, čak ni neposredno posle izvršene provere usklađenosti
s vlastitim sigurnosnim pravilima. Jednostavno rečeno, rizik uvek postoji, dok je
stopostotnu zaštitu nemoguće postići. Postupkom zaštite resursa teži se smanjenju rizika
na najmanju moguću meru.
Veće ulaganje u sigurnost smanjuje izloženost resursa riziku. S druge strane, ono izlaže
vlasnika resursa većim troškovima i smanjuje profitabilnost. Zato je veoma značajno da
se odredi tačka u kojoj se postiže ravnoteža između ulaganja u sigurnost i postignutih
efekata.
Treba takođe imati u vidu sledeće: kao i u drugim sistemima i oblastima, sigurnosni
mehanizmi ili procedure vrlo često smanjuju udobnost rada ili pogoršavaju performanse
sistema. Kratkoročno gledano, to može negativno uticati na opšte efekte rada;
dugoročno, ove mere pozitivno utiču na uspeh u radu. To se ogleda i kroz materijalne
pokazatelje, i kroz pokazatelje koji nisu direktno materijalni, kao što su rast ili gubitak
reputacije, tj. ugleda, zavisno od toga da li se incidenti dešavaju ili ne.
Najvažniji faktori uspeha su sledeći:
• aktivnosti koje se odnose na ceo sigurnosni proces moraju biti zasnovane na
zahtevima posla i moraju ih voditi poslovna rukovodstva;
• neophodno je dobro razumeti rizike od potencijalnih pretnji i ranjivosti sistema;
• osnovni koncepti zaštite moraju biti izloženi svim rukovodiocima i zaposlenima
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 40
kako bi svi shvatili koliko je zaštita važna;
• kompanijska ili institucionalna uputstva za primenu pravila i standarda zaštite
moraju se dostaviti svim zaposlenima i svim saradnicima koji nisu stalno
zaposleni.
Proces zaštite (slika 5.) zasniva se na četiri osnovna koraka [171]: procena, zaštita,
otkrivanje i odgovor. U ovom modelu, neki autori koriste izraz „planiranje“ (planning)
umesto izraza „procenjivanje“, a izraz „sprečavanje“ ili „prevencija“ (prevention)
umesto izraza „zaštita“.
PROCENA
ZAŠTITA
OTKRIVANJEODGOVOR
Slika 5. Model procesa zaštite resursa
• procena (assessment). Procena je priprema za ostale tri komponente. Smatra se
posebnom akcijom zato što je u vezi s pravilima, procedurama, pravnom i
drugom regulativom, određivanjem budžeta i drugim upravljačkim dužnostima, i
još je povezana s tehničkom procenom stanja zaštite. Greška u proceni bilo kog
od ovih elemenata može naškoditi svim operacijama koje slede.
• zaštita (protection). Zaštita, tj. sprečavanje ili prevencija, podrazumeva primenu
protivmera kako bi se smanjila mogućnost ugrožavanja sistema. Ukoliko zaštita
zakaže, primenjuje se sledeći korak - otkrivanje.
• otkrivanje (detection). Otkrivanje ili detekcija predstavlja proces identifikacije
upada, tj. povrede sigurnosnih pravila ili incidenata koji se odnose na sigurnost.
Neki autori definišu incident kao svaki „nezakonit, neovlašćen ili neprihvatljiv
postupak koji je preduzet, a odnosi se na računarski sistem ili mrežu”.
• odgovor (response). Odgovor ili reakcija predstavlja proces oporavka, tj. lečenja
posledica upada. U aktivnosti reakcije spadaju postupci „zakrpi i nastavi”, ili
„goni i sudi”. Ranije se na prvo mesto stavljalo oporavljanje funkcionalnosti
oštećenih resursa, kao što je korišćenje rezervnih kopija podataka za vraćanje
sistema u stanje pre izvršenog napada. U novije vreme sve češće se koriste
pravna sredstva (sudski proces protiv onoga ko ugrožava sigurnost), među koja
spada prethodno prikupljanje dokaza metodama digitalne forenzike pomoću
kojih se potkrepljuje tužba.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 41
3 Platni sistemi
Definicija plaćanja može se i pojednostaviti: plaćanje je prenos novčanih vrednosti.
Pravna definicija platnog sistema bi mogla bi se formulisati na sledeći način: platni
sistem je organizacija koja podržava prenos vrednosti u smislu ispunjenja novčanih
obaveza. Platni sistem, u najširem smislu, predstavlja skup sistema za transfer novčanih
sredstava koji olakšavaju cirkulaciju novca. Da bi platni sistem na zadovoljavajući način
obavljao svoju ulogu, potrebno je da se novčana sredstva što kraće zadržavaju u
kanalima platnog prometa. Pored toga, sistem treba da bude pouzdan, što prvenstveno
znači bezbedno izvršavanje transakcija i postojanje kontinuiteta raspoloživosti prema
korisnicima. Izvršavanje transakcija po ekonomski prihvatljivim cenama takođe je
značajna karakteristika koja doprinosi kvalitetu platnog sistema. S obzirom na to da
platni sistem utiče na brzinu ekonomskih tokova, troškove i likvidnost učesnika, kao i
da predstavlja kanal za transmisiju mera monetarne politike, odnosno da njegovo
neadekvatno funkcionisanje može da naruši poverenje javnosti u celokupni finansijski
sistem – jasna je izrazita zainteresovanost centralne banke da obezbedi njegovo
pouzdano i efikasno funkcionisanje [33].
Banka za međunarodna poravnanja [23] podrazumeva da je platni sistem skup
instrumenata, učesnika, bankarskih procedura i infrastrukture koja omogućava vršenje
funkcije. Platni instrumenti su standardizovana forma kojom se inicira plaćanje.
Razlikuju se instrumenti kojima se iniciraju kreditni, operacije direktnog zaduženja,
elektronske platne kartice, čekova i elektronskog novca. Raznovrsnost ponude platnih
instrumenata i upotreba novijih i efikasnijih instrumenata kao što su elektronske kartice
i elektronski novac određuje stepen razvoja platnog sistema.
Uloga učesnika u platnim sistemima menja se u zavisnosti od stepena razvijenosti
platnog sistema koji posmatramo i konkretnih rešenja koja su primenjena u njegovoj
organizaciji. Najvažniji učesnik u platnim sistemima, a posebno ako su u pitanju zemlje
u razvoju, jeste centralna banka koja ima ulogu i vlasnika i organizatora platnog
sistema. Iz tih uloga proizilaze i ostale, kao što su donošenje radnih procedura, odluka i
uputstava i kontrola sprovođenja donetih akata [147]. Centralna banka ostvaruje potpuni
uvid i kontrolu nad svim elementima platnog sistema zemlje, a osim toga analizira i
usklađenosti platnog sistema sa međunarodnim standardima.
Najveća grupa učesnika u platnom sistemu jesu poslovne banke, kojima je platni promet
tradicionalno deo portfolija usluga [137]. Radi poboljšanja konkurencije, sa ciljem da se
postignu viši nivo kvaliteta i niže cene, u poslove platnog prometa uključuju se i
štedionice, mreže, odnosno automatske klirinške kuće koje se bave prometom po
osnovu platnih kartica i onlajn provajderi, kao što su Pay Pall i Cybercash. Učesnici
platnog prometa mogu biti trezori, koji u pojedinim državama imaju direktan pristup
platnom sistemu, odnosno transakcije puštaju direktno, bez posrednika u sistem, kao i
institucije koje vrše poravnanje u trgovini hartijama od vrednosti [109].
Značaj i uticaj poslova platnog prometa dugo je smatran jednostavnim i trivijalnim,
čime je zanemarivana činjenica da platni sistemi predstavljaju kičmeni stub svake
privrede. Stavovi se u poslednjih dvadeset godina menjaju i uviđa se da na nivo
privrednog razvoja jedne zemlje utiče na nivo razvijenosti platnog sistema [110], a
susrećemo i stavove da se platni sistem mora posmatrati kao ključna komponenta
finansijskog tržišta zemlje [198].
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 42
3.1 Osnovni pojmovi i definicije
Banka za međunarodna poravnanja izdala je Objašnjenja termina korišćenih za platne
sisteme i sisteme poravnanja [28], koja su prevedena i na srpski jezik i koji se nalazi na
sajtu Narodne banke Bosne i Hercegovine [37]. Rečnik je napravljen tako da uglavnom
definicijom termina objasni reč. U nastavku se nalazi skup pojmova sa definicijom koji
se uobičajeno koriste prilikom definisanja elementa platnog sistema.
Plaćanje je trasatov transfer monetarnog potraživanja na strani koja je prihvatljiva za
trasanta. Karakteristično potraživanje dobija oblik novčanica ili saldo depozita kod
finansijske institucije ili centralne banke.
Platni sistem se sastoji od skupa instrumenata, bankarskih procedura i sistema
međubankarskog transfera sredstava koji osigurava cirkulaciju novca.
Kreditni transfer, platni nalog ili niz platnih naloga urađenih u svrhu stavljanja
finansijskih sredstava na raspolaganje primaocu. I platni nalozi i finansijska sredstva
opisana u tom smislu kreću se od banke platilaca/inicijatora do banke korisnika, moguće
preko nekoliko drugih banaka posrednika i/ili vise od jednog kreditnog transfer sistema.
Direktno zaduženje je ranije odobreno zaduženje na bankovnom računu [130] platioca
inicirano od strane primaoca.
Platni instrument je svaki instrument koji omogućava imaocu/korisniku transfer
sredstava.
Platna instrukcija ili nalog (platna poruka) za transfer sredstava (u obliku monetarnog
potraživanja od neke ugovorne strane) po nalogu korisnika. Nalog se može odnositi ili
na potražni transfer ili na dugovni transfer.
Klirinška kuća. Centralno mesto mehanizma za centralnu obradu preko kojeg se
finansijske ustanove sporazumevaju da razmene naloge za plaćanje ili druge finansijske
obaveze (npr. vrednosne papire). Te institucije poravnavaju ono što su razmenile u
određeno vreme na osnovu pravila i procedura klirinške kuće. U nekim slučajevima
klirinška kuća može preuzeti značajnu ulogu druge strane, finansijske odgovornosti ili
odgovornosti upravljanja rizikom, za klirinški sistem.
Kliring (obračun). Kliring je proces [139] transfera informacija i obračunavanje
obaveza između dužnika i poverioca (banaka). Sastoji se od identifikacije, poravnanja i
potvrđivanja.
Poravnanje. Aktuelan transfer sredstava izmedju dve strane.
Na slici 102. hijerarhijski su prikazani učesnici u platnim sistemima, od Retail učesnika
u svojim platnim sistemima, preko Wholesale učesnika, koji imaju svoje platne sisteme,
pa do platnog sistema centralne banke. Radi se o jednom veoma kompleksnom sistemu,
a ta činjenica se može ilustrovati i brojem učesnika u svakodnevnom radu RTGS
sistema centralne banke sa podređenim sistemima [129].
Platni instrument može biti definisan kao skup formi i procesa u cilju izmene
vlasništva u smislu plaćanja. Platni instrument može biti definisan i kao alat za
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 43
inicijalizaciju transfera u smislu plaćanja. Instrumenti i načini njihovog korišćenja mogu
se veoma razlikovati, sa jasnim izuzetkom kod gotovog novca, gde je u svim zemljama
sveta njegovo značenje i korišćenje identično.
U definiciji Banke za međunarodna poravnanja gde se pod instrumentom plaćanja
podrazumeva bilo koji instrument koji omogućava prenos sredstava. Na slici 6.
prikazani su instrumenti plaćanja u Srbiji. Svi nalozi koje treba da se realizuju
završavaju u RTGS sistemu Narodne banke Srbije ili kliring sistemu Narodne banke
Srbije, u zavisnosti od visine iznosa sredstava iskazanog na nalogu.
Elektronski platni instrument može biti definisan kao skup elektronskih formi i
elektronskih procesa u cilju izmene vlasništva u smislu plaćanja. Elektronsko plaćanje
je transfer elektronskim sredstvima do korisnika korišćenjem elektronskog platnog
instrumenta. Danas se koristi veoma širok spektar elektronskih instrumenata. Oni
uključuju, na primer, direct debit, debitne kartice, kreditne kartice, Credit Transfers kao
alate koje u sebi sadrži veoma raznorodne kumulativne skupove servisa i platnih portala
sa različitim instrumentima plaćanja.
Na slici 7. prikazan je jedan takav portal koji u sebi objedinjuje više elektronskih
instrumenata plaćanja. Važno je napomenuti da finansijska institucija, na prikazanom
primeru u pitanju banka, je sama dizajnira elektronski instrument u skladu sa svojom
poslovnom politikom, definisanim profilom poslovanja, profilom svojih korisnika.
Slika 6. Primer instrumenata za plaćanja: nalozi za uplatu, isplatu, prenos i naplatu
Nacionalni platni sistem institucionalne i infrastrukturne elemente i procesa za iniciranje
i prenos novčanih prava u skladu sa obavezama centralne banke i komercijalnih banaka.
On obuhvata tržište kapitala i tržište vlasničkog kapitala (akcije). Izuzetno važno mesto
zauzimaju procesi poravnanja hartija od vrednosti. Okvir postavljen na ovaj način može
da predstavi celokupan platni sistem jedne zemlje – nacionalni platni sistem.
Komponente, celine i tokovi mogu se videti na slici 8. Infrastruktura nacionalnog
platnog sistema [33] sačinjena je od međusobno povezanih celina. Nacionalni platni
sistemi razlikuju se u zavisnosti od veličine zemlje i njenog privrednog razvoja, ali
ukoliko bismo izvršili generalizaciju, osnovni elementi su: institucionalna
infrastruktura, sistem plaćanja velikih vrednosti, sistem(i) plaćanja malih vrednosti i
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 44
sistem(i) za kliring i saldiranje hartija od vrednosti.
Slika 7. Prikaz skupa servisa i portala elektronskih instrumenata plaćanja
Dužnik PoverilacNovčana potraživanja i transferi
Novac centralne banke
(dnevna likvidnost)
Gotovina Depozit
Novac komercijalnih
banaka
Instrumenti plaćanja
Institucionalni okvir
Plaćanja
- Transakcioni sistemi
- Sistemi kliringa
- Sistemi poravnanja
Tržište dogovora Sistemi HOV Tržište akcija
- Tržišni okvir
- Konsultacije sa glavnim
učesnicima
- Zakonska regulativa
- Nadzor
Slika 8. Nacionalni platni sistem
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 45
Svi nacionalni platni sistemi spadaju u kategoriju sistemski značajnih platnih sistema
(Systematicly Important Payment System – SIPS). U razvijenim privredama osim
centralnog platnog sistema funkcionišu i drugi platni sistemi, ali oni ne moraju imati
sistemski značaj. Sistemski značajne platne sisteme karakteriše veliki obim transakcija
(po broju i veličini), čime bi otkaz ili nepravilnost u njihovom radu ugrozio
funkcionisanje privrede u celini. U Srbiji se pravi razlika „između sistemski značajnih i
značajnih platnih sistema, pri čemu je sistemski značajan platni sistem onaj čiji
poremećaji u radu ili u radu njegovih učesnika mogu izazvati ozbiljne poremećaje u
finansijskom sistemu, a kod značajnog platnog sistema oni se ne mogu izazvati, ali se
može izazvati nepoverenje učesnika i njihovih klijenata u te sisteme“. Sistemski
značajan platni sistem mora da ima mehanizme za upravljanje sistemskim rizicima, koji
bi sprečili „domino efekat“, odnosno lančanu reakciju u slučaju otkaza jedne banke ili
više banaka u sistemu [33].
3.1.1 Sistemi procesorskih kuća
Klasifikacija platnih sistema, slika 9., može se izvršiti na osnovu načina plaćanja,
mesta plaćanja, veličine obračuna, načina obračuna i vremena obračuna [33].
Klasifikacija rizika sistema za poravnanje klirinških kuća prikazana je u tabeli 1.
Klasifikacija platnih sistema na osnovu načina plaćanja. Klasifikacija platnih
sistema prema načinima plaćanja vrši se u odnosu na prisustvo ili odsustvo posrednika
u platnom prometu. Razlikuju se dve vrste aranžmana. Bilateralni korespondentski
platni aranžmani predstavljaju najjednostavniji način povezivanja dve banke u platnom
prometu. Banke su međusobno povezane nostro/loro računima i nije potrebno
uključivanje posrednika. Platni aranžmani uz prisustvo agenta poravnanja
podrazumevaju da se saldiranje između dve strane ne obavlja direktno, već da je
uključen posrednik. Automatske klirinške kuće (Automated Clearing Houses – ACH)
najznačajniji su posrednici u savremenim poslovima platnog prometa i omogućavaju
multilateralne platne aranžmane. One su jedna od prvih formi računarski podržane veze
između banaka koja se oslanja na mrežnu tehnologiju i predstavlja preteču
elektronskog transfera novca.
Slika 9. Pregled sistema za razmenu vrednosti
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 46
Klasifikacija platnih sistema prema mestu plaćanja. Platni sistemi se, prema mestu
plaćanja, odnosno mestu na kome se nalaze lica (institucije) koje u njima učestvuju,
dele na unutrašnji (nacionalni) i međunarodni (prekogranični) platni promet.
Klasifikacija platnih sistema prema veličini transakcija. Platni sistemi se, prema
kriterijumu veličine transakcije, mogu podeliti na sisteme koji vrše transfer transakcija
velikih vrednosti (large -value funds transfer ili large-value transfer systems) i sisteme
koji vrše transfer transakcija malih vrednosti (retail funds transfer ili small-value
transfer systems). Platni sistemi velikih vrednosti dominantno se odnose na (relativno)
mali broj plaćanja velikih vrednosti, koji su vremenski veoma osetljivi. U sistemima
plaćanja malih vrednosti, u kojima se procesira veliki broj transakcija plaćanja, obično
male vrednosti u formi čekova, transfera odobrenja, direktnih zaduženja i plaćanja
platnim karticama. Ti sistemi ne moraju biti od sistemske važnosti, ali su od značaja za
poverenje javnosti u mehanizme i način obavljanja transakcija plaćanja.
Klasifikacija platnih sistema prema načinu obračuna. Nakon iniciranja procesa
plaćanja, banke primaju platne instrukcije, nakon čega nastupa faza saldiranja
(poravnanja) između banaka učesnica u procesu. Razlikuju se dva modaliteta
saldiranja, prema kojima se vrši klasifikacija platnih sistema. To su neto obračun i
bruto obračun.
Neto obračun (net settlement ili netting) ili odloženi neto obračun (differed net
settlement – DNS) Multilateralne neto operacije podrazumevaju prikupljanje
instrukcija plaćanja od svih učesnika, da bi se nakon kliringa knjižile samo razlike
(salda). Drugim rečima, netting sistemi predstavljaju operativnu proceduru saldiranja
između komercijalnih banaka, pri kojoj se potraživanja i obaveze svake pojedinačne
banke potiru (kompenzuju) u toku radnog dana (najčešće više puta), a na kraju radnog
dana banke moraju da pokriju samo svoja negativna salda. Sistemom za neto obračun
najčešće se procesira veliki broj malih plaćanja, tako da je moguće grupisanje,
sortiranje i izračunavanje neto pozicije za svaku banku pojedinačno.
Bruto obračun (gross settlement) podrazumeva da se obračun svih individualnih
plaćanja vrši pojedinačno, jedan po jedan. U modelu bruto obračuna razlikuju se tri
modela: model koji dozvoljava prekoračenja, model u kome prekoračenja nisu
predviđena, model redova čekanja. Bruto obračun podrazumeva da svaki nalog bude
pojedinačno obrađen i uknjižen, što čini ovu vrstu obračuna znatno skupljom od neto
obračuna. Osim toga, banke moraju da imaju veći iznos sredstava koji će im omogućiti
likvidnost tokom celog dana. Opravdanje za široku upotrebu ovog modela proizilazi iz
redukovanog rizika jer je problem sistemskih rizika mnogo izraženiji kod
multilateralnog neto obračuna.
Klasifikacija platnih sistema prema vremenu obračuna. Klasifikacija platnih
sistema može se izvršiti i prema vremenu, odnosno hitnosti obračuna transakcija. U
tom smislu razlikujemo sisteme koji vrše obračun u realnom vremenu, tako da se sve
transakcije obrađuju čim stignu u sistem i sisteme sa odloženim obračunom, u kome se
transakcije obrađuju i saldiraju u unapred definisanim vremenskim intervalima ili na
kraju radnog dana.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 47
rbr Naziv rizika Opis rizika
1. Rizik poravnanja
Opšti termin koji se koristi da se označi rizik da se poravnanje u sistemu transfera neće
desiti kako se očekivalo. Ovaj rizik može uključivati i kreditni i likvidni rizik
2. Kreditni rizik
Rizik da ugovorna strana neće poravnati obavezu, u punoj vrednosti, kada je dospela ili u
bilo koje vreme kasnije. U sistemu razmene za vrednost, rizik je obično definisan tako da
uključuje troškove rizika zamene i glavni rizik.
3. Rizik likvidnosti
Rizik da ugovorna strana (ili učesnik u sistemu poravnanja) neće poravnati obavezu u punoj
vrednosti u vreme dospeća. Rizik likvidnosti ne uključuje činjenicu da je ugovorna strana ili
učesnik nesolventan, pošto oni mogu biti u stanju da poravnaju tražene dugovne obaveze u
nekom neodređenom periodu, kasnije.
4. Operativni rizik
Rizik ljudske greške ili kvara neke komponente hardvera ili komunikacijskog sistema koja
je ključna za poravnanje.
5. Sistemski rizik
Rizik da će propust ispunjenja obaveza koje se od njega traže, jednog od učesnika u sistemu
transfera ili uopšteno na finansijskim tržištima, prouzrokovati da ostali učesnici ili
finansijske institucije ne budu u mogućnosti ispuniti svoje obaveze (uključujući poravnanje
obaveza u sistemu transfera) o dospeću. Taj propust može prouzrokovati značajnu likvidnost
ili kreditne probleme i kao rezultat toga mogu biti pretnja stabilnosti finansijskih tržišta.
Tabela 1. Rizici kod sistema za poravnanje
3.1.2 Platni sistemi banaka i drugih finansijskih organizacija
Kao primer platnog sistema banke u nastavku će biti opisana Assecco-ova softverska
rešenja koja su u širokoj upotrebi u domaćim bankama [12].
Assecco je kompanija za razvoj softvera, specijalizovana za bankarska softverska
rešenja. Osnovana je 1994. godine i vodeći je snabdevač bankarskog softvera u Srbiji,
Crnoj Gori, Makedoniji i Bosni i Hercegovini. Razvila je softversko rešenje BI -
Interaktivni transakcioni sistem koji omogućava dvadesetčetvoročasovni rad banke bez
end-of-day/close-of-business prekida, čija je arhitektura prikazana na slici 10.
Administracija sistema zajednička je centralizovana i za sve podsisteme. Na podsistem
jezgra i administracije dodaju se ostali moduli BI sistema. Parametrizacija sistema je
organizovana preko mehanizma bankarskog stabla koji obuhvata skup svih poslova koji
se rade u banci.
Slika 10. Troslojna arhitektura Antegra BI sistema [12]
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 48
Nacionalni platni promet. Podsistem za podršku nacionalnog platnog prometa
obezbeđuje odgovarajuće tehničko okruženje, u okviru postojeće organizacione šeme
banke, neophodno za obavljanje poslova službe platnog prometa u banci. Kao deo
integrisnog Antegrinog sistema BI, ovaj podsistem ima čvrste veze sa svim ostalim BI
podsistemima i potrebnim eksternim sistemima, slika 11, bez obzira na to da li on
koristi njihove usluge, bilo tako što oni koriste njegove usluge za obavljanje plaćanja.
Podsistem u potpunosti automatizuje razmenu podataka sa Klirinškom kućom i
Centralnom bankom (STP - Straight Through Processing).
Slika 11. Veza Antegra BI sistema sa eksternim sistemima [12]
Organizacija platnog prometa. Poslovi platnog prometa obavljaju se u Sektoru
platnog prometa kome pripadaju: služba za praćenje disponibiliteta banke, obračunski
centar banke, obradna mesta banke, prijemna mesta banke. Podsistem je koncipiran da
može podržati dve vrste organizacionih struktura: centralizovanu, u kojoj sve filijale
funkcionišu kao prijemna mesta i postoji samo jedno obradno mesto, ili
decentralizovanu, koju karaketriše visok stepen samostalnosti filijala koje su
koncipirane kao obradna mesta. Vrste platnog prometa, u odnosu na uspostavljenu
organizacionu strukturu, jesu: interni platni promet filijala, interni platni promet u banci
i eksterni platni promet između banaka. Bez obzira na vrstu platnog prometa, obrada
naloga se vrši tako što se nalozi sa prijemnog mesta šalju na odgovarajuće obradno
mesto. Posle uspešno obavljene autorizacije nalog se realizuje u internom platnom
prometu ili se šalje na realizaciju u eksterni platni promet. Nalozi se izvršavaju po
redosledu koji definišu prioritet naloga i vreme prijema. Sistem vodi potpunu evidenciju
o prilivima i odlivima sredstava banke. Na disponibilitetu se prate stanja eksternih
računa banke: žiro računa, računa rezervi, računa pozicija u bruto (RTGS - Real Time
Gross Sistem) i neto (Giro Clearing) obračunu, računa poslatih i primljenih naloga.
Transakcije u platnom prometu. Program za unos naloga za plaćanje, u osnovnom
režimu rada, optimizovan je tako da omogući unos proizvoljnog naloga za plaćanje. Za
specijalne vrste naloga za plaćanje, u cilju ubrzanja rada šalterskih radnika, postoje
posebni režimi rada istog programa, u koje se lako ulazi. Specijalne vrste naloga su:
grupni nalozi, šabloni za tipske transakcije, prikupljanje sredstava i plaćanje
komunalnim službama sa dostavljanjem specifikacija za rasknjižavanje u papirnom i
elektronskom obliku.
Platne kartice (BiCard). Ovaj modul obavlja poslove sa karticama koji se tiču back
office funkcionalnosti (naplata potraživanja nastalih korišćenjem kartice) i rada na
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 49
šalteru. Pored ovoga on, u cilju postizanja jedinstvene tačke odobravanja svih
transakcija i zaduženja računa klijenata kod banke, održava onlajn vezu sa
komutacionim čvorištem transakcija po karticama. BiCard omogućava da se u okviru
istog sistema integrišu svi standardni kartični proizvodi koje banka ima za cilj da izdaje.
U okviru podsistema podržane su funkcije odloženog plaćanja i plaćanja na rate, koje su
bile karakteristične za čekove po tekućim računima. Ova funkcionalnost bankama daje
mogućnost da, sa platnim karticama, korisnicima pruže usluge slične onima koje su
imali prilikom korišćenja čekova.
Kreditne kartice. Kreditne kartice predstavljaju specifičnu grupu platnih kartica koja
funkcioniše po principima obnavljajućih kreditnih limita. Kreditne kartice se dele na
dve osnovne grupe Charge i Revolving. Za Charge kartice karakteristično je da sredstva
potrošena u toku obračunskog perioda korisnik mora da uplati u celini u zadatom
periodu. Kod Revolving kartica korisnik mora da uplati samo deo od ukupno potrošenih
sredstava. Pored standardnih funkcionalnosti koje prate rad svih platnih kartica kao što
su: prikupljanje zahteva, card managment, obrada i knjiženje transakcija i Onlajn
autorizacije, kroz ovaj podsistem su dodate i nove funkcionalnosti kao što su: skoring,
obračun potrošnje i formiranje obaveza korisnika, specifičan način obračuna kamate,
praćenje uplata, praćenje kašnjenja sa uplatama korisnika i formiranje opomena.
Veza sa novim procesorom. Deo poslovanja vezan za platne kartice kao što su
upravljanje ATM i POS terminalima, personalizacija kartica, stand-in autorizacija i
obezbeđivanje intefejsa prema kartičnim sistemima VISA, Master itd. za banke uslužno
rade specijalizovane ustanove koje jednim imenom nazivamo procesori. Procesori sa
kojima su uspostavljeni i online i offline način rada jesu: Mellon, Arius – Europlanet,
Transacty, ING Banka, Chip card, Delat Singular.
mBanking obaveštavanje. mBanking (Mobile Banking) modul generiše poruke o
događajima na računima i karticama unutar Core banking sistema radi obaveštavanja
komitenata o tim događajima u realnom vremenu. Svaka realizacija transakcije može da
generiše odgovarajuću mBanking poruku, u zavisnosti od toga da li postoji
odgovarajuće ovlašćenje za generisanje poruke ili ne. Generisane poruke predaju se
eksternim ili internim sistemima za obaveštavanje koji zatim obavljaju distribuciju
poruka komitentima, koristeći raznovrsne komunikacione kanale. Generisanje velikog
broja poruka može da zahteva značajne resurse sistema, ali zahvaljujući paralelnom
procesiranju, mBanking minimalno usporava Antegrin core banking sistem.
Web Paket. WebPaket je modul kojim se omogućava da se putem veb kanala (eksterni
eBanking sistem) univerzalnim zahtevom aplicira ili za kredit ili za kreditnu karticu.
Zahtevi za ovaj proizvod se predaju, tj. unose kod prodavca. Trgovci putem veb
aplikacije eksternog eBanking sistema unose zahtev i dokumentaciju vezanu za zahtev
koju prosleđuju Core sistemu gde se dalje vrši preuzimanje izveštaja iz kreditnog biroa,
obavlja proces Scoring-a, verifikacije podataka i dokumentacije i donosi odluka o
odobravanju, tj. neodobravanju zahteva. Nakon pozitivnog rešavanja zahteva (odobren
zahtev), vrši se zaduživanje komitenta za iznos kupovine, dok se sredstva prebacuju na
privremenu partiju trgovca. Tek po pristizanju originalne dokumentacije u vezi
proizvoda koji se želeo finansirati kreditom ili kreditnom karticom, sredstva se sa
privremene partije trgovcaprebacuju na stvarnu partiju trgovca.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 50
Sepa Direct Debit module. Za banke u Srbiji u skladu sa uputstvima i odlukama
Udruženja banaka Srbije i Narodne banke Srbije, a u saradnji sa partnerskim firmama
Pexim i Omnilogika iz Beograda, razvijen proizvod namenjen bankama pod imenom
SEPA Direct Debit. Ovaj softverski modul omogućava banci da učestvuje u SEPA
Direct Debit kliringu u Srbiji. Antegrino rešenje integriše se sa bankarskim sistemom u
banci. Aplikacija komunicira sa jezgrom bankarskog softvera koji banka već koristi,
preko jasno definisanih servisa.
3.1.3 Multikanalni sistemi za plaćanja pravnih i fizičkih lica
Kao primer multikanalnog sistema za plaćanje u nastavku biti će opisana Halcomova
softverska rešenja, koja su u širokoj upotrebi u domaćim bankama [176]. Sistem je
namenjen i pravnim i fizičkim licima.
Halcomova softverska rešenja u upotrebi su u 10 različitih monetarnih sistema
(Slovenija, BIH, Srbija, Crna Gora, Kosovo, Nemačka, Albanija, Iran, Katar i Maroko),
u 72 banke, četiri centralne banke i klirinške kuće i kod preko 141.000 zadovoljnih
korisnika. Do sada je u okviru Halcom platnih sistema obrađeno preko 529.000.000
platnih naloga. Halcomove certifikacione agencije izdale su preko 190.000 pametnih
kartica sa digitalnim sertifikatima.
Hal E-bank je namenjen preduzećima koja imaju jedno ili više radnih mesta za rad sa
elektronskom bankom. Svaka ovlašćena zaposlena osoba prilikom otvaranja programa
prijavljuje se u sistem pomoću svoje personalizovane pametne kartice. Na osnovu
ovlašćenja dodeljenih od strane preduzeća za određeni račun vlasnik pametne kartice
dobija dozvolu za rad samo sa onim funkcijama za koje je ovlašćen. Povezivanje sa
bankom vrši se prema izboru: preko interneta, pozivne linije ili iznajmljene linije.
Hal E-bank/ SMS omogućava: obaveštenja o promenama na računima, informacije o
stanju ili realizovanim transakcijama, plaćanja na predefinisane račune.
Hal E-bank/International Cash Management pravnom licu omogućava upravljanje
računima sa istim rešenjem elektronske banke na računima u bankama u inostranstvu
preko usluga domaće banke. Banka rešenjem International Cash Management pruža
klijentima globalno poslovanje i dodatne usluge boljeg upravljanja sa sredstvima na
svim svojim računima.
Hal M-Bank je jednostavno, brzo i sigurno rešenje za elektronsko bankarstvo preko
mobilnog telefona. Hal M-Bank omogućava upotrebu usluga koje se najviše koriste kod
elektronske banke* neposredno preko mobilnog telefona.
Hal M-Payments je rešenje za jednostavno i sigurno mobilno plaćanje koje koristi
digitalni potpis i funkcioniše na običnim mobilnim telefonima
Hal E-Invoices rešenje za distribuciju e-faktura kao siguran komunikacijski kanal
upotrebljava postojeće rešenje za elektronsko bankarstvo i zato omogućava automatsko
plaćanje i knjiženje, kao i jednostavni vremenski pečat i dugoročno arhiviranje e-
faktura. Osnovna zamisao Halcomovog rešenja za distribuciju e-faktura jeste da se
elektronska faktura iz informacionog sistema prodavaca preko elektronske banke
prenese u informacioni sistem kupca. U kupčevoj e-banci se iz podataka e-faktura
jednostavno kreiraju platni nalozi, koje kupac zatim mora elektronski da potpiše. Kod
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 51
firmi koje koriste naprednije sisteme za podršku poslovnih procesa, e-faktura se
jednostavno, kako na kupčevoj tako i na prodavčevoj strani, automatski knjiži u
njihovim pozadinskim obradama (ERP). Najznačajnije prednosti Hal E-Invoices za
pravne osobe jesu: distribucija podataka putem sigurnog i stabilnog komunikacijskog
kanala (koristi rešenje za elektronsku banku), automatsko plaćanje i knjiženje, rešenje je
nezavisno od formata podataka pošiljaoca i primaoca e-faktura, kao i od oblika e-
faktura, omogućava jednostavni elektronski pečat i dugoročno arhiviranje e-faktura
zajedno sa drugim Halcomovim rešenjima. Rešenje Hal E-Invoices omogućava
distribuciju e-faktura takođe i domaćinstvima i pojedincima. Putem veb portala e-
fakture se mogu distribuirati i pojedincima koji ne koriste elektronsku banku. Potrošač
(kupac) koji prihvati (ugovori) primanje e-faktura može pristupiti svom mailbox-u, na
koji mu je upućena e-faktura sa digitalnim certifikatom.
Hal E-Forms je koncept informatičkih rešenja koji banci omogućava dodavanje novih
e-obrazaca za željene e-usluge bez posredovanja programerskih kuća. Banka dobija alat
sa kojim sama napravi e-obrazac (na osnovu postojećih dokumenata Word, Adobe PDF)
i distribuira ga korisnicima. Korisnik takve obrazsce primi kroz kanala elektronske
banke, popuni, digitalno potpiše i pošalje nazad do banke.
Hal E-Archive je efikasan način za elektronsko arhiviranje digitalno potpisanih i
vremenski overenih e-dokumenata, kao i ostalih dokumenata u elektronskom obliku radi
revizijskog praćenja i zakonske potrebe čuvanja platnih naloga. Među najvažnijim
prednostima je jednostavna upotreba, nemogućnost da dođe do gubitka arhiviranog
dokumenta, kao i najviša stopa sigurnosti i zaštite podataka.
Hal E-Clearing je sistem međubankarskih sravnjenja plaćanja malih vrednosti kao što
su kreditna plaćanja, neposredna terećenja, sravnjenje čekova i POS transakcija. Pri
tome je moguće bilateralno ili multilateralno sravnjivanje pojedinih vrsta plaćanja ili
svih plaćanja u celosti u sistemima za međubankarska bilateralna ili multilateralna
plaćanja malih vrednosti.
3.2 Standardi platnih sistema
Osnovne inicijative na finansijskom tržištu po pitanju standardizacije koje globalne
institucije sprovode prikazani su u tabeli 2. Ukoliko finansijske organizacije koje se
bave platnim sistemima žele da se na savremen način bave finansijskim servisima i da
nude savremene finansijske proizvode jasno je da je neophodno i uključivanje
finansijske organizacije u rad navedenih institucija.
rbr Naziv inicijative Opis inicijative
1. Inicijative u domenu standarda i primene
Inicijative koje se odnose na aktivnosti kojima je osnovni smer delovanja
razvoj i implementacija standarda i prakse na tržištu
2. Infrastrukturne inicijative Inicijative povezane sa razvojem tržišne infrastrukture koja ima primenu u međunarodnom tržištu
3. Inicijative na polju rešenja Grupa inicijativa za razvoj specifičnog proizvoda ili servisa
4. Inicijative u domenu regulacija Regulacije koje imaju uticaj u domenu globalnih plaćanja
Tabela 2. Osnovne inicijative na globalnom tržištu plaćanja [48]
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 52
rbr Naziv Opis Link
1. COGEPS razvija evropsku strategiju u domenu plaćanja www.abe.org
2. EBA zadužena za razvoj platne infrastrukture evropske zajednice www.abe.org
3. EC zadužen za razvoj jedinstvenog evropskog tržišta www.europa.eu.int
4. ECB Banka centralnih banaka Evropske unije www.ecb.int
5. ECBS
odgovorna za identifikaciju i promociju standarda
u skladu sa potrebama evropske bankarske
industrije
www.ecbs.org
6. EPC zadatak je da kreira arhitekturu, instrumente i procese za Single Euro Payment Area (SEPA) www.europeanpaymentconcil.org
7. Eurogiro uloga je uvećanje kooperacije izmeđe žiro i banaka pošta u domenu plaćanja www.eurogiro.com
8. FED
vodeća od 12 US FED banaka u rukovođenju
aktivnostima iz oblasti finansijskih servisa i
odgovarajuće podrške
www.frbservices.org
9. G-30
osnovana od strane Međunarodnog monetarnog
fonda, BIS, ECB, centralnih banaka, vodećih
finansijskih institucija i univerziteta da utvrdi
moguću praksu i polise
www.group30.org
10. GPC
osnovana od strane devet vodećih bankarskih grupa
u cilju smanjenja troškova i izgradnje efikasnijeg
finansijskog tržišta za sve učesnike
11. Identrus
obezbeđuje finansijske institucije – članice sa
potrebnim standardima za utvrđivanje digitalne
autentifikacije
www.identrus.com
12. IFX
kreira XML standarde za razmenu poruka,
fokusirana na modeliranju end-to-end poslovne
transakcije uključujući i Retail bankarske potrebe
www.ifxforum.org
13. ISO mreža nacionalnih institucija za standardizaciju
www.iso.ch
www.iso15022.org
www.iso20022.org
14. TC 68
pokriva aktivnosti iz oblasti bankarstva, hartija od
vrednosti i drugih finansijskih servisa, pridružena
SWIFT organizacija
15. OAG promoviše metodologiju baziranu na poslovnim procesima i XML sintaksi www.openapplications.org
16. OASIS
globalni konzorcijum koji vodi razvoj,
konvergenciju među standardima i adaptaciju
standarda u domenu elektronskog poslovanja za
bezbednost, veb-servise, XML, poslovne
transakcije, elektronsko izdavaštvo i
transparentnost između različitih tržišta
www.oasis.org
18. SWIFT
neprofitna organizacija koja obezbeđuje servise i
softver za razmenu poruka između preko 7000
finansijskih institucija u preko 200 zemalja
www.swift.com
19. TWIST inicijativa predvođena sa Rozal Dutch/Shell da definiše XML standarde za korporativne korisnike www.twiststandards.org
Tabela 3. Važnije organizacije sa globalnim uticajem u finansijskoj industriji
U tabeli 3. prikazane su važnije globalne organizacije koje imaju presudan uticaj u
formiranju finansijskog tržišta, posebno u domenu platnog prometa. Poražavajuća
činjenica je neučestvovanje srpskih predstavnika u tim institucijama. Vodeća globalna
uloga pojedinih finansijskih organizacija inicijalizovana je upravo mogućnošću
stvaranja adekvatnog okruženja za poslovanje. Ukoliko srpske finansijske institucije
žele da budu podjednako razvijene kao inostrane, moraju u vrlo kratkom vremenskom
periodu da se uključe u rad tih institucija. Inače će inostrane finansijske institucije
zauzeti vodeću ulogu u formiranju i našeg tržišta i na taj način dobiti tržišnu utakmicu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 53
Razvoj EDI standarda započeto je sedamdesetih godina prošlog veka i to nezavisno u
Severnoj Americi i Evropi. Započeta standardizacija elektronske razmene podataka se
nastavlja i danas, a najzastupljeniji standardi danas su EDIFACT, ISO15022 (sa SWIFT
MT podstandardom) i najsavremeniji ISO20022 standard koji će biti opisan u narednim
poglavljima.
3.2.1 EDIFACT standard
Danas je informaciona tehnologija osnova savremene i efikasne ekonomije i poslovnog
komuniciranja u međunarodnim razmerama, a standardi su preduslov njenog bržeg
razvoja i primene [180]. U prethodnih nekoliko godina veliki značaj dobile su aktivnosti
međunarodne standardizacije na području elektronske razmene podataka (EDI) i
donošenje skupa standarda pod zajedničkim imenom EDIFACT sa ciljem da se olakšaju
i ubrzaju tokovi roba i usluga na međunarodnom planu. Veoma ozbiljne pripreme za
primenu standarda EDIFACT (Electronic Data Interchange For Administrations
Commerce and Transport) u raznim regionima, zemljama, asocijacijama i firmama,
praktično na svim kontinentima prinudile su zemlje, organizacije i firme koje žele da
zadrže svoje mesto na svetskim tržištima da vrlo brzo prihvate EDI tehnologiju po
EDIFACT standardima [55].
S tehničke strane gledišta EDI (Elektronska razmena podataka) je razmena
strukturiranih komercijalnih podataka između računara zasebnih firmi, izvršena bez
manuelne intervencije, elektronskim putem, posredstvom standardizovanih poruka koje
zamenjuju tradicionalne papirne komercijalne dokumente. Ovakva odrednica sadrži više
bitnih elemenata, bez čijeg zadovoljenja ne može biti reči o elektronskoj razmeni
podataka. EDI je razmena podataka. Razmena podrazumeva dvosmerni prenos poruka.
EDI je razmena strukturisanih komercijalnih podataka. Sem komercijalne prirode,
poruke moraju imati format koji omogućava mašinsku obradu. EDI je razmena podataka
između računara zasebnih firmi. Pojam zasebnih firmi ne treba posmatrati sa aspekta
pravnih subjekata, već sa stanovišta da svaki deo iste firme, opremljen računarom, teži
optimizaciji svog dela posla, pa EDI može da služi za razmenu podataka, kako sa
drugim pravnim subjektima tako i sa drugim delovima iste firme, sa kojima je u
poslovnim interakcijama. EDI je razmena poruka između računara bez manuelne
intervencije. EDI je razmena podataka između aplikacija, a ne između ljudi, kao što je
to slučaj kod elektronske pošte. EDI je razmena elektronskim putem. Razmena
magnetnih medija, čak kada bi oni sadržali strukturisane komercijalne podatke,
očigledno ne predstavlja EDI. EDI je razmena posredstvom standardizovanih poruka i
podrazumeva postojanje usvojenih standarda za strukturisane poruke. EDI je razmena
poruka koje zamenjuju tradicionalne komercijalne papirne dokumente.
Odluka poslovnog rukovodstva o primeni elektronske razmene podataka mora da sadrži
mnogo više od želje da se razmena podataka između računara vrši elektronskim putem,
u skladu sa usvojenim standardima. Ta odluka, pre svega, mora da sadrži neke
poslovne, ekonomski valorizovane ciljeve. U širokoj lepezi ciljeva za koje se firme,
danas u sve većoj meri multinacionalno poslovno orijentisane, opredeljuju za uvođenje
elektronske razmene podataka najčešće se navode:
• smanjenje troškova papirne dokumentacije (papira, osoblja, vremena);
• smanjenje obima ljudskih grešaka u obradi podataka;
• brža i bolja informisanost i dostava informacija;
• efikasnije upravljanje novčanim sredstvima;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 54
• mogućnost poboljšanog upravljanja zalihama;
• poboljšano upravljanje transportom i distribucijom;
• pojednostavljenje i ubrzanje carinskih procedura;
• povećanje produktivnosti;
• prevazilaženje jezičkih barijera i problema različitih vremenskih zona.
Sa standardima za EDI počelo se sedamdesetih godina i to nezavisno u Severnoj
Americi i Evropi. Ovi standardi su donošeni na svim nivoima: na nivou preduzeća,
država, regiona, delatnosti, samo ne na međunarodnom nivou. Tako su prvi ANSI X.12
standardi doneti sredinom osamdesetih godina i primenjivali su se u Severnoj Americi.
Istovremeno su se u Evropi primenjivali GTDI standardi (Guidelines Trade Data
Interchange) usvojeni od strane UN ECE. Inicijativa za izradu međunarodnih standarda,
baziranih na razvoju i iskustvima primene ANSI X.12 i UNIECE GTDI standarda
potekla je 1985. godine i urodila plodom već 1987. godine usvajanjem standarda pod
zajedničkim akronimom UN/EDIFACT. Prema definiciji usvojenoj na 31. sednici
UN/ECE/WP.4, u martu 1990. godine, UN/EDIFACT su pravila Ujedinjenih nacija za
elektronsku razmenu podataka u oblasti administracije, trgovine i transporta. Ona
obuhvataju skup međunarodnih standarda, kataloga i uputstava za EDI, naročito onih
koja se odnose na trgovanje robom i uslugama između nezavisnih, automatizovanih
informacionih sistema.
Skup UN/EDIFACT standard obuhvata:
• poruke UNSM (United Nations Standard Messages);
• kataloge elemenata iz kojih se grade ove poruke (segmenata, složenih
elemenata podataka i elemenata podataka);
• kodne liste elemenata podataka koji se prikazuju u šifriranom obliku;
• uputstva i pravila za razvoj i implementaciju ovih standarda.
Rad na UN/EDIFACT standardima odvija se u saradnji sa ISO organizacijom i sa
odborima za EDICAFT širom sveta i po modelu grupa za razvoj poruka u finansijskoj
industriji, trgovini, carini, statistici, zdravstvu, turizmu i javnim službama. Evropa je
odigrala ključnu ulogu u izradi standarda za elektronske ekvivalente klasičnih
dokumenata preuzevši koordinaciju izrade EDIFACT poruka u okviru WEEB (Western
European EDIFACT Board). Razvijene su Standardne poruke Ujedinjenih nacija
(United Nations Standard Message - UNSM), poruke koje pokrivaju sve aspekte
administrativnih, trgovinskih i transportnih transakcija. Glavni nosioci međunarodne
standardizacije za EDI su: UN/ECE, Međunarodna organizacija za standardizaciju ISO i
Međunarodna telekomunikaciona unija (ITU - International Telecommtmication Union).
U bankarskom poslovanju standardizacija, u kojoj EDI zauzima značajno mesto,
predstavlja važan preduslov razvoja jedinstvenog finansijskog informacionog sistema.
Standardizacija treba da:
• identifikuje postojeće standarde: nacionalne, međunarodne, evropske, granske;
• identifikuje donosioce standarda, kao i metodologiju izrade;
• identifikuje standarde za projektovanje informacionog sistema (softverski
inženjering, razmenu podataka, zaštitu, protokole);
• utvrdi prioritete preuzimanja međunarodnih standarda,pravnu regulativu;
• utvrdi strategiju preuzimanja međunarodnih i regionalnih standarda.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 55
EDI kao elektronska razmena podataka obuhvata četiri osnovna procesa:
• standardizaciju procedura komunikacija;
• formatizovanje podataka u poruke koje se razmenjuju između računara;
• prenos poruka;
• prevođenje poruka u oblik koji omogućava obradu prenesenih podataka.
Sistem EDI se tokom vremena razvio, kako u pogledu novih standarda tako i na
području efikasnije zaštite za prenos podataka i novca. Na osnovu strogo definisanih
standarda vrši se transfer „elektronskog novca“ i poslovnih poruka. EDI tehnologija sve
više postaje uslov poslovanja na svetskom tržištu, koje teži da se ujedini u jedinstveno
svetsko tržište na osnovu primene informatičkih dostignuća. Informatizacijom
bankarskih i drugih finansijskih usluga globalni elektronski prenos sredstava postaje
veza kompjuterizovanih banaka i drugih učesnica u platnom prometu. Osnovni problemi
korišćenja novih tehnologija odnose se na opasnost od raznih vrsta neovlašćenog
korišćenja i „upada“ u telekomunikacionu mrežu banke. Razvojem Interneta i sve
većom svetskom povezanošću došlo je do standardizacije elektronskih poruka sa ciljem
bržeg i jednostavnijeg razumevanja različitih formata poruka. U okviru razvoja platnog
prometa modelirani su dokumenti platnog prometa na bazi nacionalnih standarda. W3C
(World Wide Web Consortium) predložio je OFX (Open Financial Exchange), koji je
kreiran od strane softverskih kompanija CheckFree, Intuit i Microsoft početkom 1997.
godine. da podrži veb transakcije i omogući povezivanje različitih korisničkih
finansijskih softvera preko interfejsa. Baziran je na klijent/server i zahtev/odgovor
modelu, definiše standarde u razmeni podataka finansijskih transakcija, omogućava
finansijskim institucijama slobodan izbor platforme za informacione tehnologije jer su
definisani standardi u razmeni podataka koji su nezavisni od sistemskih softvera. Kao
rešenje za elektronsku razmenu podataka OFX su koristile velike banke kao što su:
Bank of America, Chas Manhattan Bank, Citibank. Pored banaka bile su uključene su i
bankarske grupacije, brokerske organizacije, osiguravajuća društva i softverske
kompanije. Novije verzije OFX standardnih specifikacija bazirane su na XML jeziku
(Extensibile Markup Language). Svoju primenu OFX specifikacije našle su u velikim
bankarskim mrežama (SWIFT), a sa transformacijom platnog sistema kod nas nameće
se potreba primene XML-a u elektronskom platnom prometu [234], [33].
3.2.2 SWIFT i privatne mreže za razmenu poruka
SWIFT – Society for Worldwide Interbank Financial Telecommunication je osnovan
1973. godine sa ciljem kreiranja zajedničke svetske mreže za obradu podataka i
komunikaciju, uz pronalaženje zajedničkog jezika za internacionalne finansijske
transakcije. SWIFT se pobrinuo da finansijske institucije između kojih će se
razmenjivati poruke budu značajno uključene u proces razvoja mreže da bi se osigurala
efikasnost i praktičnost. Još u ranoj fazi razvoja definisana su osnovna pravila na kojima
se zasniva SWIFT, a to su sigurnost, pouzdanost i odgovornost [206]. U Belgiji i
Holandiji 1976. godine otvoreni su prvi operativni centri. Posle 12 meseci
funkcionisanja akumulirani zbir obrađenih poruka je prešao cifru od deset miliona, što
je predstavljalo pravu potvrdu i ogroman uspeh. Prvi operativni centar u SAD otvoren je
1979. godine, a 1980. povezane su prve zemlje azijskog kontinenta i to su bile Hong
Kong i Singapur.
Povezivanje centralnih banaka učvrstilo je poziciju SWIFT-a kao zajedničkog kanala
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 56
između svih učesnika u bankarskom sektoru. SWIFT je 1985. godine instalirao satelitski
link koji će povezivati operativne centre SAD i Evrope da bi se podržao porast broja
razmenjenih poruka i nivo usluga putem satelitske komunikacije. Sistem SWIFT-a
dobija nagradu 1991. godine Smithsonian instituta za oblast informacionih tehnologija,
kojom se konstatuje da bi bez postojanja njegovog sistema finansijske institucije bile
ograničene na kombinaciju papirnih dokumenata i nekompatibilnih privatnih mreža, što
bi umnogome ograničilo njihovu sposobnost da prate razvoj međunarodnih finansijskih
tokova. Interbank File Transfer (IFT), AccordWorkstation, SWIFTAsset Reconciliation,
SWIFT-Alliance neki su od novih proizvoda i usluga koji su lansirani do 1994 godine.
Model straight-through processing (STP) razvija se 1996. godine. Ovim modelom
snižavaju se troškovi, upravlja se rizikom i poboljšava se automatizacija. SWIFT takođe
podržava inicijative za razvoj tržišne infrastrukture u domenu clearing-a, settlement-a i
trgovine.
Uvođenje evra 1999. godine uslovljava mnoga prilagođavanja u okviru raznih
kategorija poruka. SWIFT počinje razvoj standarda sledeće generacije i strategije koja
se odnosi na e-poslovanje. SWIFT sistem 2000. godine objavljuje planove za dva
servisa koji podržavaju prelazak na „business-to-business” domen. To su servisi Trust
Act koji osigurava korporativno trgovanje preko Interneta i e-paymentsPlus koji
korporacijama sa veb baziranim plaćanjima omogućava siguran servis. SWIFTNet
messaging services prvi put počinje da funkcioniše 2001. godine implementacijom u
okviru domaće tržišne infrastrukture i to u okviru RTGSPlus sistema Centralne banke
Nemačke i Centralne banke Engleske.
Koncepcija SWIFT sistema sastoji se od različitih sistemskih celina, odnosno
tehnoloških nivoa mreže, čija hijerarhija uslovljava hardware, software, komunikacionu
strukturu mreže i međusobne kontrolne relacije i veze. Svaka od pojedinih sistemskih
celina sprovodi određeni deo funkcija: System Control Processor (SCP), Slice
Processors (SP), Regional Processors (RP), SWIFT Access Point (SAP), Gateway
Computer. System Control Processor se nalazi u središtu SWIFT sistema. U okviru ove
mreže postoje dva SCP u Americi i dva u Holandiji. Međutim, uvek je aktivan samo
jedan od njih. Zadatak SCP je da kontroliše sve pristupe sistemu i obavlja monitoring
kompletne SWIFT mreže i njenih servisa, kao i distribuciju novog software-a, kontrolu
ponovnog uspostavljanja veze i stanja posle prekida u mreži i sl. U SWIFT mreži
postoje dva Slice Processor-a od kojih je uvek aktivan samo jedan. Slice Processor
predstavlja deo SWIFT sistema koji komunicira sa korisničkim logičkim terminalom
(LT). Zadatak SP-a jeste da usmerava poruke između pojedinih korisnika SWIFT-a
preko regionalnih procesora, da čuva kopije svih emitovanih poruka i na zahtev
korisnika ispostavlja kopiju takvih poruka, da generiše sistemske poruke. Svaki
Regional Processor logički predstavlja ulaznu i izlaznu tačku SWIFT sistema. Svi
korisnici pristupaju SWIFT mreži preko regionalnog procesora. Svaku unetu i
emitovanu poruku proverava regionalni procesor, pre nego što se uputi na svoj dalji put,
prema Slice Processor-u. Isto tako i sve dolazeće poruke jedno vreme se zadržavaju u
odgovarajućem regionalnom procesoru, koji sprovodi kontrolu poruka, a zatim ih
isporučuje na naznačenu adresu. SWIFT Access Point – SAP su mrežni konekcioni
čvorovi koji podržavaju portove kroz koje omogućavaju korisnicima fizički pristup
SWIFT mreži. Sastoje se od telekomunikacione opreme koja je pod nadzorom SWIFT-a
sa lokalnom podrškom koju obezbeđuju lokalni ugovarači SAP-a, kojih ima nekoliko u
jednoj zemlji, a neke manje zemlje su priključene na SAP u susednoj zemlji.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 57
Široka rasprostranjenost i veliki broj učesnika uslovili su da SWIFT dobije primat nad
ostalim telekomunikacionim sredstvima, pa su tako došle do izražaja mnogobrojne
prednosti korišćenja SWIFT mreže. Prednosti upotrebe SWIFT-a posmatrano sa aspekta
troškovne efikasnosti jesu sledeće: omogućava jedinstven pristup raznim finansijskim
institucijama i sistemima, vremenski rok prijema – kruženja poruka maksimalno je
skraćen, platforma za kreiranje poruka se može višestruko upotrebljavati, široka je skala
usluga po pristupačnoj ceni, standardi koji se koriste podržavaju automatizaciju i brzu
obradu poruka, smanjeni su troškovi prenosa poruka u odnosu na teleks i poštu,
poboljšan cash management jer su informacije koje se dobiju ažurne što omogućava
bolje iskorišćenje sredstava.
Prednosti upotrebe SWIFT-a, posmatrano sa aspekta upravljanja rizikom: mrežna
elastičnost sistema kroz dupliranje opreme i linija, mrežna sigurnost sistema,
bezbednost prenosa poruka kroz autentifikaciju, detekciju, segregaciju saobraćaja i
enkripciju, što znači da neovlašćeni korisnici ne mogu koristiti mrežu, smanjen
operativni rizik kroz brzu obradu podataka, efikasna kontrola prilikom emitovanja i
uručenja. Posmatrano sa aspekta poslovnog kontinuiteta SWIFT je pokazao vodeću
poziciju u poslovnom kontinuitetu sa skoro stoprocentnom raspoloživošću iz godine u
godinu jer SWIFT je mreža operativna 24 sata svakog dana širom sveta.
SWIFT mreža svojim korisnicima omogućava: potpunu automatizaciju platnih procesa,
primenom standardnog jezika komunikacije, smanjenje rizika kod plaćanja, povećanje
pouzdanosti i tajnosti poruke između primaoca i pošiljaoca, promptni prenos poruke,
povezanost sa bankama širom sveta, automatske sisteme razmene šifara i odgovarajućih
ključeva, efikasnije upravljanje sredstvima, automatsku obradu podataka dnevno
poravnavanje prometnih transakcija i dnevnu kontrolu stanja, kontrolisanje i smanjenje
troškova poslovanja [208].
SWIFT standardi su striktno definisana pravila i formati popunjavanja polja u okviru
standardizovanih SWIFT poruka, odnosno opisi odgovarajućih procedura koje se
moraju do detalja sprovesti da bi se omogućilo normalno funkcionisanje SWIFT sistema
i razmena odgovarajućih poruka u okviru mreže. Svi standardi precizno su definisani i
tekstualno opisani sa odgovarajućim ilustracijama. Poštovanjem standarda poruka
moguće je kreirati, memorisati i emitovati poruke uz odgovarajuću validaciju i
autorizaciju. Razmena SWIFT poruka podvedena je pod stroga pravila standarda
(međunarodno priznatih), a struktura poruka je u korelaciji sa vrstom i tipom
bankarskog instrumenta koji se u suštini mapira (po utvrđenim pravilima mapiranja
sadržaja poruka). Standardi nad porukama znače jedinstvena pravila interpretacije
poruka, odnosno sve članice SWIFT mreže na isti način tumače sadržaj poruka koje
razmenjuju sa ciljem izvršavanja plaćanja/naplata u poslovima sa inostranstvom.
SWIFT tehnologija rada, u odnosu na tradicionalni sistem rada, omogućava:
unificiranost jezika komunikacije i postupaka, ažuran prenos poruka, veći stepen
pouzdanosti i tajnosti u prenosu transakcija, efikasniju kontrolu postupka plaćanja,
direktno povezivanje sa bilo kojom bankom koja se nalazi u SWIFT mreži, znatno veću
efikasnost upravljanja sredstvima, automatizovanu obradu podataka i smanjenje
troškova poslovanja. Standardizovana SWIFT tehnologija rada ima za krajnji cilj veću
efikasnost upravljanja sredstvima. U svom razvoju SWIFT se ograničio na transfer
sredstava između banaka, što je samo po sebi izuzetno značajno za efikasniji razvoj
banke. Korišćenje ove tehnologije, u smislu automatizovanja radnih postupaka i
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 58
procedura, koje se odnose na disponiranje deviznih sredstava i upravljanje deviznim
sredstvima, pruža značajnu mogućnost unapređenja poslovanja banke. Unificiranost
jezika komunikacije i postupaka odnosi se na uspostavljanje SWIFT standarda za
komuniciranje i utvrđivanje kategorija poruka za bankarske finansijske transakcije.
U postupku slanja i primanja poruke ugrađene su procedure i kontrole koje garantuju
sigurnost prenosa. Banka koja šalje poruku brine o unosu podataka u SWIFT računarsku
mrežu, u formi i na način kako je to utvrđeno propisanim formatima, zatim vrši
autentifikaciju, tj. šifriranje koje se obavlja automatizovano od strane računara na
osnovu razmenjenih ključeva između korespodentskih banaka. Zatim sledi formiranje
ISN – a (Input Sequence Number – ulazni sekvencijalni broj koji računarski sistem
banke pošiljaoca formira za svaku ulaznu poruku) i puštanje poruke. Regionalni
procesor proverava protokol i postupak enkripcije i klasifikaciju poruke. Operativni
centar proverava ISN i format, arhivira poruku i formira OSN, tj. izlazni sekvencijalni
broj koji je sastavni deo ORN – Output Reference Number), koga sadrži svaka dolazeća
poruka, a sastoji se od izlaznog datuma, identifikacije izlaznog terminala, koda banke i
OSN-a. Regionalni procesor u zemlji primaoca poruke obavlja deskripciju, klasifikaciju
poruke i proverava protokol. Banka, primalac poruke, kontroliše prijem, kontroliše OSN
i autentifikaciju, vrši klasifikaciju i distribuciju poruke.
SWIFT povezuje sve banke korisnike ove tehnologije rada i pruža im nedvosmislene
prednosti u poslovanju. SWIFT tehnologija rada omogućava integraciju i potpunu
automatizaciju radnih procedura. Kroz SWIFT mrežu vrši se realizacija plaćanja [178],
po mehanizmima sistema razmene poruka. Organizacija mreže ima trostepenu
arhitekturu, odnosno prvi stepen je nivo korisnika i programski interface prema SWIFT
mreži; drugi stepen je SWIFT administracija i mreže računara koje u okviru SWIFT
tehnologije podržavaju rad korisnika (banaka i drugih finansijskih institucija, brokerskih
kuća, klirinških kuća, centralnih banaka), sada već i kompanija kao članova SWIFT
mreže; treći stepen je SWIFT mreža sa svim osnovnim i value added servisima, koja
funkcioniše danas kao IP mreža u sistemu SWIFTNet FIN aplikacija kao bazni servis
razmene poruka i nizom interaktivnih servisa mreže sa svim potrebnim
funkcionalnostima za neposredni rad korisnika SWIFT mreže [234].
U SWIFT tehnologiji referenciranje poruka predstavlja mehanizam kontrole emitovanih
i primljenih poruka. Model poslovnih funkcija integriše se putem razvoja lokalnih baza
podataka i pojedinačnih aplikativnih segmenata, uz uvažavanje pravila i SWIFT
standarda. Na taj način ostvaruje se informatički model SWIFT-a, koji obezbeđuje:
podršku međunarodnom platnom prometu [177], u pogledu transfera poruka, i
integraciju poslovnih funkcija platnog prometa i disponibiliteta deviznih sredstava
banke. U tehničkom smislu, SWIFT mreža kao autonomna mreža integriše se u
računarsku mrežu banke, izgrađenu na principima integrisane arhitekture.
SWIFT posebno obraća pažnju na bezbednost mreže. U tom smislu, razvijene su usluge
vezane za bezbednost mreže pod nazivom USE Project (User Security Enhagement), a
odnose se na: bilateralnu razmenu ključeva kojom je omogućena razmena ključeva,
utvrđivanje ispravnosti prenosa poruke i sigurnosno prijavljivanje na mrežu korišćenjem
IC kartice. Ključni proizvod SWIFT-a (pored Messaging Services) je SWIFTNet Y-
COPY servis kao bazna infrastruktura za Sistem velikih plaćanja – SVP (RTGS), koji se
ugrađuje u nacionalne i transnacionalne sisteme veliki plaćanja i predstavlja nukleus
tehnologije upravljanja i regularnim servisima i rizicima u sistemu velikih plaćanja [23].
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 59
3.2.3 Standardi ISO15022 i ISO20022
ISO 20022 [99] - UNIversal Financial Industry Message scheme (UNIFI) je
internacionalni standard, naslednik standarda ISO15022 [208], koji definiše ISO
platformu za razvoj finansijskih standarda. Pristup prisutan u šemama poslovnog
modeliranja omogućava korisnicima i informatičarima da prezentuju finansijske
poslovne modele i pripadajuće transakcije sa formalnom sintaksno nezavisnom
notacijom. Ovi poslovno-transakcioni modeli su stvarni poslovni standardi. Oni mogu
biti prevedeni u fizičke poruke željene sintakse. U vreme kada je UNIFI počeo sa
razvojem, XML (eXtensible Mark-up Language) je već bio vodeća sintaksa za e-
komunikaciju.
Prvi fokus UNIFI je internacionalna finansijska komunikacija između finansijskih
institucija, njihovih klijenata i domaća ili internacionalna infrastruktura uključena u
procesiranje finansijskih transakcija. U tu svrhu je razvijen i repozitorijum, kao i skup
standardizovanih šema poruka koje se nalaze na ISO20022 sajtu.
Standard u sebi sadrži i metodologiju razvoja, registracioni proces i organizaciju
centralnog finansijskog repozitorijuma koji sadrži UNIFI poruke i njihove komponente.
Navedeni UNIFI standard se sastoji od pet delova:
• Part 1: Overall methodology and format specifications for inputs and output
from the ISO20022 Repository (Prvi deo: Opšta metodologija i specifikacija
formata za izmenu i pregled ISO20022 repozitorijuma);
• Part 2: Roles and responsibilities of the registration bodies (Drugi deo: Uloga i
odgovornosti registracionih tela);
• Part 3: ISO20022 modelling guidelines (Technical Specification) (Treći deo:
ISO20022 vodič za modelovanje (tehnička specifikacija));
• Part 4: ISO20022 XML design rules (Technical Specification) (Četvrti deo:
ISO20022 pravila za dizajniranje (tehnička specifikacija));
• Part 5: ISO20022 reverse engineering (Technical Specification) (Peti deo:
ISO20022 reverzni inženjering (tehnička specifikacija)).
Ako ne postoje UNIFI poruke koje pokrivaju specifične transakcije, može se
inicijativom definisati novi model i poruke koje će odobriti UNIFI registraciono telo.
Ako poruka postoji u repozitorijumu, ali ne zadovoljava sve potrebe, može se
inicijativom kreirati nova verzija poruka koja će ih prilagoditi potrebama.
U tabeli 4. prikazan je opis dela sadržaja ISO20022 sajta koji se odnosi na platne
poruke. Da bi ISO definisao poruke i da bi ih učinio javnim dobrom objavljene su sve
UNIFI poruke sa svim elementima koje ih opisuju:
• dokument u pdf formatu koji u potpunosti opisuje poruke;
• XML šema svih poruka;
• poslovni primeri, odnosno XML instance svake poruke;
• zip fajl koji sadrži HTML verziju UML modela poruka;
• zip fajl koji sadrži UML model poruka, koji je u potpunosti otvoren i može da se
koristi sa IBM Rational Rose 8.5.0506.2811;
• zip fajl koji sadrži aktiviti dijagrame (za poslovne tokove), dijagrame sekvenci
(za izradu scenarija) i dijagrame klasa (za poruke). Dijagrami su dostupni u više
formata.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 60
Tabela 4. Platne poruke UNIFI formata za poslovne procese plaćanja
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 61
Spisak UNIFI poruka u odnosu na domen primene:
• plaćanja (Payments);
• notifikacije za inostrana plaćanja (FOREX Notification);
• hartije od vrednosti (Securities);
• trgovačke poruke (Trade Services).
Oslanjajući se na ISO20022 standard za poruke, u skladu sa svojim potrebama EPC je
dodatno definisao odgovarajući set poruka i na taj način napravio svoju modifikaciju
ISO20022 standarda, koju će u platnom prometu da koriste banke, druge finansijske
institucije i korisnici finansijskih usluga na malo. I dosadašnja praksa korišćenja poruka
bila je ista. Narodna banka Srbije je, na primer, definisala svoj set poruka 2003 godine
na bazi SWIFT poruka sužavajući mogućnost korišćenja poruka, tj. definisanjem svog
podstandarda. Podstandard se definiše da bi se suzila upotreba zadatog seta poruka u
smislu jasnije implementacije, lakše kontrole tokova poruka i drugih sličnih razloga.
U tabeli 5. predstavljen je skup osnovnih EPC poruka koje mogu da se preuzmu sa EPC
sajta, i koje se redovno ažuriraju. Skraćenica „pacs“ označava da je u pitanju poruka za
plaćanje – payment, a cs potiče od reči clearing (poravnanje) i settlement (izvršenje). U
nizu brojeva koji sledi xxx.yyy.zz, xxx označava vrstu poruke (originalni broj koji je na
odgovarajućoj ISO poruci), yyy definiše upotrebu poruke, a zz verziju.
Naziv poruke Ime fajla sa xsd šemom
FIToFICustomerCreditTransfer.EPCCoreV02 $pacs.008.002.02.xsd
FIToFICustomerDirectDebit.EPCCoreV02 $pacs.003.002.02.xsd
PaymentStatusReport.EPCCoreV02 $pacs.002.002.02.xsd
PaymentReturn.EPCCoreV02 $pacs.004.002.02.xsd
FIToFIPaymentReversal.EPCCoreV02 $pacs.007.002.02.xsd
Tabela 5. EPC osnovni set poruka
U tabeli 6. prikazane su osnovne poruke koje u sebi imaju definisane i dodatne opcione
servise. Dodatni opcioni servisi su one usluge finansijskih organizacija koje nisu
obavezne, koje mogu da donesu prihod ili privuku klijente i finansijske institucije su
dužne da ih, ukoliko su ih uvele zbog određenog broja klijenata, pružaju i ostalim
svojim klijentima bez diskriminacije. Ovakav pristup determinisanja upotrebe servisa
omogućen je zahvaljujući prednostima koje pružaju savremene informacione i
komunikacione tehnologije. Naime, ukoliko je ICT servis uveden za određen broj
subjekata, samo administrativne zabrane (a ne troškovi) mogu da onemoguće primenu
istih servisa i za ostale.
Naziv poruke Ime fajla sa xsd šemom
FIToFICustomerCreditTransfer.EPCCoreAOSV02 $pacs.008.003.02.xsd
FIToFICustomerDirectDebit.EPCCoreAOSV02 $pacs.003.003.02.xsd
PaymentStatusReport.EPCCoreAOSV02 $pacs.002.003.02.xsd
PaymentReturn.EPCCoreAOSV02 $pacs.004.003.02.xsd
FIToFIPaymentReversal.EPCCoreAOSV02 $pacs.007.003.02.xsd
Tabela 6. EPC osnovni set poruka sa definisanim dodatnim opcionim servisima
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 62
3.2.4 Standardi Banke za međunarodna poravnanja
Sa ciljem uvođenja standarda i tehnološkog reda formiran je Komitet Banke za
međunarodna poravnanja (Bank for International Settlements - BIS) u Bazelu (BIS
CPSS - Committee for Payments and Settlement Systems) koji je definisao metodologiju
sistematizovanu u 10 osnovnih principa za sistematski značajne platne sisteme (BIS
Core Principles for Systematically Important Payment Systems) [23], [28], [37] koji
imaju snagu preporuka. Praksa je potvrdila značaj preporuka u više od 40 zemalja.
Primena principa, u procesu pripreme, projektovanja i implementacije sistema plaćanja
(RTGS) vrlo je efikasna, pouzdana i produktivna metodologija, u smislu metodologije i
definicija 10 osnovnih principa za sistemski važne sisteme plaćanja.
Ključni princip u primeni osnovnih principa (Core principles) zasnovan je na
definisanju razlike sistemski važnih sistema plaćanja i onih koji to nisu. U svakoj zemlji
postoji uvek više sistema plaćanja koji su bitni za njihove korisnike, vrlo značajni za
funkcionisanje poslovnih subjekata i izvršavanje njihovih finansijskih obaveza. Prema
tački 6.66 osnovnih principa, samo oni sistemi plaćanja koji mogu da upravljaju
regularnim tokovima plaćanja, finansijskim poremećajima, upravljaju rizikom i
iznenadnim finansijskim udarima, njihovim prenosom i kontrolom u platnom prometu u
zemlji, ali i inostranstvu, mogu se nazvati sistemski važnim sistemima plaćanja. Pored
navedenih karakteristika, još znatan deo uslova (zakonskih i tehnoloških) mora da
ispuni svaki sistemski važan sistem plaćanja (RTGS).
Definisanje metodologije za poštovanje osnovnih principa i njihovu implementaciju ima
za cilj korišćenje univerzalnih uputstava i preporuka radi projektovanja i funkcionisanja
bezbednijih i značajno efikasnijih sistemski važnih sistema velikih plaćanja u svetskoj
ekonomiji. Poseban značaj implementacije osnovnih principa vezan je za zemlje u
tranziciji gde postoji potreba za konsolidacijom i harmonizacijom SVP i u kojima se
značajno povećavaju i broj transakcija i obimi plaćanja koji se emituju i primaju u
platnom prometu u zemlji i međunarodnom platnom prometu, odnosno nacionalnim i
svetskim finansijskim tržištima.
U sistemima velikih plaćanja koji su od interesa za Banku za međunarodna poravnanja,
ključni instrumenti plaćanja su prenosi sredstava i direktno zaduženje [145]. Drugi
instrumenti plaćanja: plaćanje platnim karticama, plaćanje čekovima [132], i internet
plaćanja u principu su karakteristični za sisteme malih plaćanja i nisu od interesa za
Banku za međunarodna poravnanja. U nastavku je 10 osnovnih principa Banke za
međunarodna poravnanja:
I Sistem treba da ima dobru zakonsku osnovu po svim relevantnim
nadležnostima.
II Pravila i procedure sistema treba da omoguće učesnicima jasno
razumevanje uticaja sistema na sve finansijske rizike koje učesnici trpe
učestvujući u sistemu.
III Sistem treba da ima jasno definisana pravila za upravljanje kreditnim
rizikom i rizikom likvidnosti, koja specificiraju odgovornosti operatora
sistema i učesnika i koja predviđaju odgovarajuće mogućnosti za
upravljanje i sprečavanje tih rizika.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 63
IV Sistem treba da omogući promptno konačno plaćanje na dan valute,
ukoliko je moguće tokom dana, a minimalno na kraju dana.
V Sistem u kome se radi multilateralno neto poravnanje mora, minimalno,
da osigura pravovremeno izvršenje dnevnih poravnanja, čak i kada
učesnik, sa najvećim pojedinačnim neto obavezama, nije u mogućnosti
da izvrši plaćanja.
VI Sredstva koja se upotrebljavaju za poravnanje treba da glase na centralnu
banku; ukoliko se koriste druga sredstva, ona smeju da budu izložena
minimalno ili bez kreditnog rizika i minimalno ili bez rizika likvidnosti.
VII Sistem treba da ima visok stepen sigurnosti i operativne pouzdanosti i da
ima obezbeđenu opremu i procedure za kontinuirano obavljanje dnevnih
obrada i blagovremeni završetak dnevne obrade.
VIII Sistem treba da omogući sredstva za izvršenje plaćanja koja su praktična
za korisnike i efikasna za poslovanje.
IX Sistem treba da ima objektivne i javno objavljene kriterijume za učešće,
koji predviđaju ravnopravan i slobodan pristup.
X Aranžmani za upravljanje sistemom moraju biti efektivni, transparentni i
kontrolabilni.
Odgovornosti centralne banke u primeni Osnovnih principa se odnosi na jasno
definisanje ciljeva svog sistema plaćanja i da javno objavi njegovu ulogu i politiku u
skladu sa definisanim Osnovnim principima, da obezbedi da sistem kojim upravlja
funkcioniše u skladu sa Osnovnim principima, da vrši kontrolu sistema za plaćanje
kojima ne upravlja,u skladu sa Osnovnim principima, i da saglasno principima izvršava
potreban nadzor. Centralna banka, sa ciljem promocije bezbednosti i efikasnosti svog
sistema plaćanja, koji funkcioniše na bazi Osnovnih principa, treba da sarađuje sa
drugim centralnim bankama i svim nadležnim domaćim i inostranim autoritetima.
3.2.5 Zakonski okvir za procesorske kuće u Srbiji
Prema novom nacrtu zakona o platnim uslugama u Republici Srbiji, što može da se
smatra savremenim gledištem Direkcije za platni promet Narodne banke Srbije [128],
platni sistem je sistem za prenos novčanih sredstava koji ispunjava sledeće uslove: da je
sporazum u pisanoj formi na osnovu kojeg se uspostavlja platni sistem zaključen
između najmanje tri učesnika, ne uključujući indirektnog učesnika, da najmanje jedan
učesnik – pružalac platnih usluga ima sedište u Republici Srbiji i da ima zajednička
pravila rada i standardizovane procedure za kliring ili poravnanje naloga za prenos
između učesnika [134]. Učesnici u platnom sistemu mogu biti investiciono društvo iz
RS i investiciono društvo iz EU, pravno lice sa sedištem u trećoj državi koje obavlja
poslove koji odgovaraju poslovima KI ili investicionog društva, organi javne vlasti u
RS, kao i privredno društvo i drugo pravno lice čiji je osnivač RS, autonomna pokrajina
ili jedinica lokalne samouprave za čije obaveze po zakonu jemči RS, država članica,
ECB, CB države članice, organi javne vlasti za čije obaveze po zakonu jemči država iz
EU, posebne nacionalne kreditne institucije koje su izuzete propisom Evropske unije
kojim se uređuje osnivanje i poslovanje KI, operator drugog platnog sistema i sistema
za poravnanje HoV [138], [143].
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 64
3.2.6 Usaglašavanje Srbije sa Evropskom unijom
Narodna banka Srbije intenzivno sprovodi brojne aktivnosti na usaglašavanju
nacionalne regulative s propisima Evropske unije iz oblasti platnih sistema. Kao rezultat
tih aktivnosti, izrađeni su Nacrt zakona o platnim uslugama i Nacrt zakona o konačnosti
poravnanja u platnim sistemima i sistemima za poravnanje hartija od vrednosti [149].
Reč je o usklađivanju sa osnovnim direktivama Evropske unije [61] (Directive
2007/64/EC on payment services in the internal market, Directive 98/26/EC on
settlement finality in payment and securities settlement systems i Directive 2009/110/EC
on the taking up, pursuit and prudential supervision of the business of electronic money
institutions) kojima se stvara usklađen, moderan i sveobuhvatan set pravila za pružanje
platnih usluga na nivou Evropske unije.
Direktiva o platnim uslugama (Directive 2007/64/EC on payment services in the
internal market) – PSD, pored toga što pruža pravnu osnovu za stvaranje jedinstvenog
evropskog tržišta za pružanje platnih usluga, čime se podstiče veća efikasnost i
smanjenje troškova, predstavlja i skup pravila kojima je cilj da se unapredi konkurencija
u ovoj oblasti otvaranjem tržišta plaćanja za nove učesnike – platne institucije. Takođe,
Direktiva pruža neophodnu pravnu osnovu za sprovođenje SEPA projekta.
Direktiva o konačnosti poravnanja i platnim sistemima i sistemima hartija od vrednosti
(Directive 98/26/EC on settlement finality in payment and securities settlement systems)
– SFD pravnu sigurnost u platnima sistemima u slučaju pokretanja postupaka kao što su
stečaj, likvidacija i sl. nad nekim od učesnika u sistemu, čime se sprečava širenje
sistemskog rizika na druge učesnike u sistemu.
Direktiva o osnivanju, poslovanju i prudencijalnoj superviziji institucija koje izdaju
elektronski novac (e-novac) (Directive 2009/110/EC on the taking up, pursuit and
prudential supervision of the business of electronic money institutions) – 2EMD
uspostavlja pravni okvir za izdavanje e-novca, s ciljem da se omogući razvoj ovog
tržišta i pojava novih, inovativnih i pouzdanih servisa e-novca kao tehnološke inovacije
u oblasti platnih sistema koja pospešuje konkurenciju u pružanju platnih usluga. E-
novac je digitalni ekvivalent za gotovinu smešten na elektronskom uređaju ili na
udaljenom serveru, i označava elektronski ekvivalent, uključujući magnetno pohranjenu
novčanu vrednost koja predstavlja novčano potraživanje prema izdavaocu tog novca, a
izdata je nakon prijema novčanih sredstava (radi izvršavanja platnih transakcija) i
prihvata je fizičko ili pravno lice koje nije izdavalac tog novca. Uobičajeni oblici e-
novca su „elektronski novčanik“ u vidu smart kartice na kojoj je smeštena određena
novčana vrednosti, po pravilu relativno manjeg iznosa, zatim e-novac pohranjen na
mobilnom telefonu ili na računu na internetu.
3.3 Primeri platnih sistema
3.4 Platni sistemi u svetu
Platni sistemi u Austriji
Ekonomija Austrije je tesno povezana sa ekonomijama drugih zemalja Evropske unije,
posebno sa ekonomijom Nemačke. Ova zemlja ima veoma snažne ekonomske veze sa
zemljama u Centralnoj, Istočnoj i Jugoistočnoj Evropi, te joj je takva pozicija u regionu
omogućila da postane atraktivno investiciono tržište. Austrija je ušla u Evropsku
ekonomsku i monetarnu uniju 1999. godine i bila je jedna od prvih zemalja koje su se
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 65
odlučile za ulazak u Target2 RTGS sistem u novembru 2007. godine.
Centralna banka. Oesterreichische Nationalbank (OeNB) [33], [234] je centralna
banka Republike Austrije i predstavlja sastavni deo evropskog sistema centralnih
banaka (European System of Central Banks - ESCB) kao i euro-sistema (Eurosystem).
Centralna banka daje svoj doprinos donošenju odluka o monetarnoj i ekonomskoj
politici u Austriji i u evrozoni. U skladu sa Saveznim zakonom o Nacionalnoj banci
Austrije (1984. - Nationalbank Act - NBG), Centralna banka Austrije je akcionarsko
društvo. Uzimajući u obzir status centralne banke, nju reguliše određeni broj posebnih
odredbi Zakona o Centralnoj banci Austrije. Kapital Centralne banke Austrije iznosi
EUR 12 miliona, pri čemu je 70% u vlasništvu Savezne vlade dok je 30% u vlasništvu
organizacija poslodavaca i zaposlenih, kao i banaka i osiguravajućih kompanija.
Platni sistem. Platni sistem u Austriji karakteriše razgranata mreža filijala banaka i
šaltera pošte, kao i veliki broj posebnih platnih proizvoda. Infrastruktura platnog
sistema sadrži jednoobrazne sisteme za obradu platnih transakcija tradicionalnim
instrumentima, kao što su kreditni transferi ili direktna zaduženja, i za sve veći broj
načina elektronskog plaćanja. Centralna banka Austrije aktivna je kod svake vrste
unapređenja platnog sistema koji je od značaja za ekonomiju, posebno vodeći računa o
pitanjima efikasnosti i sigurnosti. Centralna banka isto tako vodi Sistem za
međubankarske transfere (Austrian Real-time interbank selement - Artis). Za
međubankarska plaćanja u Retail-u, koja su regulisana na nivou EU, OeNB je direktan
učesnik u sistemu Step2. Time je svakoj austrijskoj komercijalnoj banci omogućen
pristup Step2 sistemu, kao indirektnom učesniku preko Centralne banke Austrije. OeNB
je razvila i vodi sistem Step.AT za kliring i neting domaćih plaćanja u Retail-u, koji je
počeo da funkcioniše u julu 2007. godine. Ovo pruža alternativu tradicionalnom sistemu
korespondentskog bankarskog poslovanja i austrijskim i regionalnim bankama
obezbeđuje infrastrukturu u skladu sa SEPA.
Asocijacija za istraživanje saradnje u oblasti plaćanja. Research Association for
Payment Cooperation (Stuzza) funkcioniše u istom svojstvu kao evropski Odbor za
platni promet. U svojini je Centralne banke Austrije i najvećih poslovnih banaka u
zemlji. Glavni zadatak mu je da razvija efikasne operativne pristupe za platne
transakcije, kao i da postiže usaglašenost po pitanju zajedničkih standarda. Do sada
realizovani projekti pokrili su logistiku poslovanja sa efektivom, elektronske potpise,
mobilno bankarstvo, sisteme izvršenja velikih naloga za plaćanja kao i elektronsko
bankarstvo. Stuzza takođe koordinira sve SEPA aktivnosti austrijskih banaka.
Artis. Artis je počeo svoj operativni rad kao austrijska komponenta Targeta. Ne postoje
nikakva ograničenja po pitanju vrste ili veličine plaćanja koje može biti podneto Artis-u.
Komunikacija u okviru ovog sistema obavlja se preko SWIFT mreže. Aplikacija e-
Konto omogućava fleksibilan pristup Artis-u, kao i informacijama u vezi sa likvidnošću.
Učesnici u ovom sistemu mogu pristupiti informacijama preko interneta uz uslov da
poseduju certifikate o bezbednosti na serverima ili koriste SwiNet Browse i SwiNet
Interact. Učesnici takođe mogu da koriste e-Konto radi slanja platnih naloga Artis- u uz
korišćenje elektronskog potpisa. Banke licencirane u Austriji, kao i one sa sedištem u
evropskoj ekonomskoj zoni (učesnici na daljinu), mogu učestvovati u Artisu. Indirektno
učešće je takođe dozvoljeno ukoliko banke ovlaste neku drugu banku da upravlja
njihovim računom. Artis se bavi:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 66
• nalozima za plaćanje od Centralne banke Austrije
o operacije na novčanom tržištu,
o gotovinski platni promet i
o drugo,
• plaćanjima drugim sistemima velike vrednosti,
• međubankarskim plaćanjima koja proizilaze iz novčanog tržišta
• međubankarskim plaćanjima koja proizilaze iz FX transakcija,
• međubankarskim plaćanjima po nalogu klijenata u slučajevima kada se zahteva
da saldiranje bude istog dana,
• plaćanjima velike vrednosti.
Kreditni rizik i rizik likvidnosti. Centralna banka Austrije ne preuzima nikakav rizik
za neizvršena plaćanja jer se ona izvršavaju samo ukoliko tekući račun ima dovoljno
pokriće ili ukoliko je učesnik u okviru dozvoljenog prekoračenja. Ukoliko učesnik ima
manjak likvidnih sredstava, na njegov zahtev biće mu odobren traženi iznos dnevnog
kredita, uz uslov da je obezbedio odgovarajući kolateral na depo računu. Limit dnevnog
kredita za učesnike određuje se na osnovu vrednosti prethodno deponovanog kolaterala
kod Centralne banke Austrije. Učesnik se obaveštava da li je traženo prekoračenje
limita odobreno ili odbijeno, i u slučaju pozitivnog odgovora, odmah se inicira obrada
plaćanja koja čekaju na računu učesnika. Dozvoljeno prekoračenje važi samo do kraja
dana. U toku 2005. godine prosečan dnevni broj transakcija Artis-a iznosio je 15.417, sa
prosečnom dnevnom vrednošću od EUR 49,15 milijardi.
Platni promet u sistemu malih plaćanja. Većina plaćanja u ritejlu u Austriji izvršava
se na bilateralnoj osnovi između kreditnih institucija. Platne transakcije se izvršavaju
preko OeNB, najvećih austrijskih banaka ili banaka organizovanih unutar višeslojnih
sektora pri centralnim instititucijama (štedionice, poljoprivredne kreditne zadruge ili
Raiffeisen i industrijske kreditne zadruge ili Volksbanken). Međusektorska plaćanja se
izvršavaju preko bilateralnih računa ili holdinga koji se vode kod trećih banaka. U
višeslojnim sektorima centralne institucije su nadležne za ujednačavanje likvidnosti
unutar i između sektora. Banke koje ne pripadaju nijednom višeslojnom sektoru drže
bilateralne obračunske račune. Po pravilu, veće institucije predstavljaju institucije kod
kojih se otvaraju računi, dok manje institucije vode evidencije. Računi se vode kao
računi kreditora (na njima su međubankarski depoziti za upravljanje plaćanjima i
likvidnošću). Step.AT nudi multilateralni kliring i istovremeno predstavlja alternativu
postojećoj proceduri korespondentskog bankarskog poslovanja.
Sistemi saldiranja hartija od vrednosti. Organizovana trgovina gotovinom i
derivatima u Austriji obavlja se na Bečkoj berzi, jedinoj austrijskoj berzi akcija i jednoj
od najstarijih berzi na svetu. Bečka berza je nezavisno tržište za austrijske hartije od
vrednosti, kao i za hartije od vrednosti Centralne i Istočne Evrope i njihovih
odgovarajućih derivata. CCP.Austria je centralni partner za sve berzanske transakcije i u
vlasništvu je Bečke berze i austrijske Kontrolbanke (OeKB). Ona garantuje za sve
transakcije na novčanom tržištu, kao i na tržištu derivata, i obezbeđuje kliring i druge
usluge povezane sa kliringom za sve proizvode koji su predmet trgovine. Trgovina na
berzi se obavlja preko Xetra kompjuterskog sistema za trgovinu. CCP.A je odgovorna
za kliring i saldiranje na svih pet tržišnih segmenata Bečke berze. Austrijska
Kontrolbank predstavlja klirinšku banku za CCP.A i istovremeno je odgovorna za
saldiranje naloga.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 67
Saldiranje. Oesterreichische Kontrolbank (OeKB) je istovremeno i austrijski centralni
depozitar hartija od vrednosti. Sve hartije od vrednosti drže se u kolektivnim depoima
što omogućava depozitarima da drže hartije od vrednosti različitih vlasnika u
kolektivnom depou, bez potrebe da ih razvrstavaju i da stavljaju u depoe formirane za
svakog vlasnika ponaosob. Svi vlasnici određene kategorije hartija od vrednosti su
istovremeno i suvlasnici u odnosu na svoje holdinge. Centralni registar hartija od
vrednosti (CRHoV) obezbeđuje široku paletu usluga deponovanja i saldiranja. Da bi
neka institucija mogla da učestvuje u CRHoV, neophodno je da bude vlasnik računa
hartija od vrednosti koji se vodi kod CRHoV, što se ugovara sa CRHoV. Ovo uključuje:
kreditne institucije, priznate investicione firme, članove domaćih berzi, zvanične
brokere na berzi hartija od vrednosti, strane Centralne registre i strane klirinške
institucije za hartije od vrednosti. CRHoV takođe može da prihvati druga pravna i
fizička lica, kao i partnerstva, kao nosioce računa hartija od vrednosti. CRHoV održava
stalne veze sa jednim brojem evropskih centralnih registara uključujući Clearstream
Banking (Frankfurt, Luksemburg), Euroclear Netherlands, SIS, Euroclear Bank i Monte
Titoli.
Sistemi plaćanja u Sjedinjenim Američkim Državama
Udruženje klirinških kuća iz Njujorka organizovalo je CHIPS godine 1970, a postepeno
su se uključivale i druge komercijalne banke, korporacije Edge Act, državne agencije
Sjedinjenih Država i filijale stranih banaka, investicione kompanije prema članu XII i
privatne banke [33], [234]. CHIPS je na početku koristio sistem sa poravnanjem na
sledeći dan, a 1991. je prihvatio sistem sa poravnanjem na isti dan na kraju radnog dana.
Međutim, sada se koristi sistem sa neprekidnim poravnanjem u realnom vremenu, u
kojem se neprekidno vrši multilateralno umreženo poravnavanje. Svaka banka učesnica
u obavezi je da položi na početku radnog dana i CHIPS-u iznos najmanje u visini
„početne pozicije“ učesnika. Početne pozicije određuje predsednik CHIPS-a bar jednom
mesečno prema obrascu formulisanom u klirinškoj kući. CHIPS-ovi računari prate sve
poraste i opadanja početne pozicije učesnika i kretanja u toku dana i tako znaju
„trenutnu poziciju“ svakog učesnika u datom momentu. Nalog plaćanja se ne odobrava
ako bi doveo do toga da pozicija, bilo pošiljaoca, bilo primaoca padne ispod nule ili
pređe dvostruki iznos njegove početne pozicije.
Automatske klirinške kuće. Početkom sedamdesetih nagli porast obima obrade čekova i
mogućnosti velikih novih računarskih sistema doveo je do pojave koncepta
automatizovane klirinške kuće (ACH - Automated Clearing House). Već 1974.
osnovano je državno udruženje NACHA (National Automated Clearing House
Association). Kroz njihove regionalne resurse banke Federalnih rezervi obezbeđuju
resurse, opremu i osoblje za regionalne mreže ACH. Lokalne ACH kuće su povezane
elektronski.
ACH operateri su obično banke federalnih rezervi ali mogu da budu i privatne
kompanije kao što je Američko udruženje klirinških kuća, Mreža elektronskog plaćanja,
pridruženi član Njujorške automatske klirinške kuće ili VisaNet ACH servisa. ACH
operateri primaju, uređuju i obrađuju elektronske stavke koje prime od drugih ACH
operatera ili od depozitne finansijske institucije koja šalje (ODFI) i zatim obezbeđuje
poravnanje između ODFI-ja i primajuće depozitne finansijske institucije (RDFI). ACH
operateri čine ACH sistem na nivou države dostupnim svim depozitnim finansijskim
institucijama. Kao fiskalni agenti SAD, banke federalnih rezervi pružaju usluge
elektronskog plaćanja za programe Državne blagajne zasnovan na ACH-u za direktno
usmeravanje federalnih periodičnih plaćanja kao što su socijalno osiguranje, veteranske
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 68
penzije i plate federalnih službenika. U okviru Ukaza o monetarnoj kontroli iz 1980.
ACH operateri iz privatnog sektora pozvani su da konkurišu bankama federalnih
rezervi. Ukaz je obezbedio da banke federalnih rezervi nisu više mogle da nude
besplatne konkurentske usluge i bile su obavezne da naplate dovoljno da se pokriju
troškovi usluge. „Faktor prilagođavanja privatnom sektoru“ uključuje se u cene obrade
da bi se teren izravnao prema učesnicima koji žive od profita. Transakcije između ACH
operatera u privatnom sektoru i onih iz banaka federalnih rezervi moraju biti usklađene
sa operativnim uputstvima federalnih rezervi o rasporedu međuregionalnih depozita i
rezervisanja. ACH operateri iz privatnog sektora međusobno razmenjuju transakcije
prema rasporedu depozita i distribucije koji sami usklađuju.
Nadređena organizacija. NACHA obezbeđuje nadzor i upravljanje najvećoj američkoj
mreži elektronskog plaćanja. Što je najvažnije, NACHA kreira, vrši reviziju i održava
pravila i smernice ACH operatera. On takođe razvija programe za povećanje obima
ACH a ima i obrazovne servise za svoje članove i korisnike ACH sistema. Regionalne
ACH kuće zadužene su za lokalna pravila i takođe pružaju obrazovanje i usluge koje
omogućavaju povezivanje svih vrsta finansijskih institucija - komercijalnih banaka,
štedionica i kreditnih zajednica.
3.4.1 Platni sistemi u državama Zapadnog Balkana
U nekadašnjoj Jugoslaviji Zavod za obračun i plaćanje – ZOP, u sastavu Narodne banke
Jugoslavije, obavljao je poslove platnog prometa, evidencije i finansijske statistike, kao
i poslove kontrole pravnih lica u Saveznoj Republici Jugoslaviji, za čije je obavljanje
Narodna banka Jugoslavije, i u skladu sa propisima kojima je bio uređen način i
postupak obavljanja platnog prometa dotadašnje Službe za platni promet, a do
donošenja propisa i opštih akata, kojima je Narodna banka Jugoslavije uređivala
obavljanje tih poslova [33], [234].
Opis poslova koje je obavljao nekadašnji Zavod za obračun i plaćanja - ZOP
Poslovi platnog prometa: otvaranje, vođenje i ukidanje računa učesnika u platnom
prometu; obračun izvršenih plaćanja; prenos novčanih sredstava između učesnika u
platnom prometu; naplata, uplata i isplata sa računa; kontrola izvršenog platnog
prometa, kao i drugi poslovi platnog prometa, u skladu sa propisima [33], [234].
Poslovi evidencije i finansijske statistike obuhvataju: vođenje jedinstvenog plana
računa; vođenje plana računa za uplatu javnih prihoda i registra imalaca računa;
evidentiranje stanja i promena stanja na računima, evidentiranje uključivanja sredstava
depozita i novčanih tokova, kao i evidentiranje naplate i rasporeda javnih prihoda;
poslove izveštavanja po evidencijama koje se vode u Zavodu. Zavod prikuplja,
kontroliše, obrađuje i publikuje podatke iz godišnjih obračuna i izveštaja pravnih lica.
Poslovi kontrole: Zavod obavlja kontrolu primene saveznih zakona i drugih propisa
kojima se uređuje računovodstvo, platni promet u zemlji i isplata zarada zaposlenih kod
pravnih lica i radnji koje su dužne da vode poslovne knjige, kao i kontrolu izmirivanja
obaveza prema saveznom budžetu - do donošenja saveznog zakona kojim će se urediti
ta kontrola. Zavod obavlja reviziju računovodstvenih iskaza pravnih lica i reviziju
javnih rashoda, osim revizije banaka i drugih finansijskih organizacija, na način i do
rokova koji su utvrđeni saveznim zakonima kojima se uređuje obavljanje tih poslova.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 69
Pravni poslovi obuhvataju: izradu pojedinačnih akata u upravnom postupku i drugim
postupcima, zastupanje po ovlašćenju guvernera, pred sudovima i drugim državnim
organima.
Organizaciono-kadrovski i opšti poslovi obuhvataju: vođenje kadrovske evidencije
radnika Zavoda; izradu pojedinačnih akata iz oblasti radnih i stambenih odnosa i zarada;
pripremanje i sprovođenje konkursa - oglasa o prijemu radnika na rad u organizacione
jedinice Zavoda; održavanje poslovnih zgrada i osnovnih sredstava; realizaciju
ugovorenih nabavki; poslove obezbeđenja i zaštite na radu i druge opšte poslove.
Računovodstveno-finansijski poslovi obuhvataju vođenje poslovnih knjiga o
sredstvima i izvorima sredstava Zavoda po organizacionim jedinicama, na nivou
analitike računa za praćenje poslovanja koje te jedinice obavljaju u skladu sa Odlukom
o analitičkom kontnom planu Narodne banke.
Iz ZOP-a su tokom ustanovljavanja platnih sistema u nezavisnim državama koje su
nastale posebno razvijani platni sistemi za velika plaćanja, mala plaćanja i sistemi za
poravnanje hartija od vrednosti, koji su prikazani u nastavku rada:
Bosna i Hercegovina
Opšti okvir. Posebne karakteristike okruženja u BiH posledica su složene političke
situacije, uticaja stranog faktora, decentralizovane funkcije centralne banke i
neusaglašenosti donošenja zakonske regulative [33], [234]. Raspadom SFR Jugoslavije
u BiH su stvorena tri platna sistema, od kojih je svaki imao monopol na bezgotovinsko
plaćanje na teritoriji koju je pokrivao: ZPP u području sa bošnjačkim stanovništvom,
ZAP u području sa hrvatskim stanovništvom u Federaciji i SPP u Republici Srpskoj.
Predstavnici međunarodne zajednice u Madridu doneli su odluku 1998. godine o
zatvaranju Zavoda za platni promet (ZPP) i formiranju posebnih klirinških kuća. Platni
promet je podeljen posebno za Republiku Srpsku i Federaciju Bosne i Hercegovine sa
zajedničkom Centralnom bankom, koja vrši poravnanje narednog dana.
Opšti regulatorni okvir. Specifičnost organizacije u BiH ogleda se i u zakonskoj
regulativi koja se odnosi na poslove platnog prometa. Platni sistem je jedinstven za celo
područje BiH, a pošto su u pitanju dve države, regulativa je podvojena. Pravni osnov za
funkcionisanje platnog prometa u BiH jeste Zakon o platnim transakcijama u Federaciji
Bosne i Hercegovine, koji je donet u avgustu 2000. godine, a platni promet u RS
sprovodi se prema odredbama Zakona o platnim transakcijama u Republici Srpskoj, koji
je donet u decembru iste godine. Ta dva zakona su vrlo detaljno harmonizovana i među
njima ne postoje bitne razlike, čime je omogućena suštinska integracija platnog prometa
ovih entiteta. Oba zakona jasno definišu tipove platnih transakcija, učesnike u platnom
prometu, načine izvršavanja naloga, odgovornosti, štete i restitucije i sve ostalo što je
neophodno za funkcionisanje platnog sistema.
Učesnici u sistemu. Najviši organ CB BiH je Upravno vijeće, koje je nadležno za
utvrđivanje monetarne politike i kontrolu njenog sprovođenja, organizaciju i strategiju
Centralne banke u skladu s ovlašćenjima utvrđenim zakonom. Centralna banka BiH ima
Centralni ured, tri glavne jedinice i dve filijale. Centralni ured je u Sarajevu, a glavne
jedinice su Glavna jedinica Sarajevo, Glavna banka Republike Srpske Banjaluka i
Glavna jedinica Mostar. Filijale su Filijala Centralne banke u Brčkom i Filijala Glavne
banke RS na Palama. Centralna banka BiH je centralni i ključni učesnik u radu platnog
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 70
sistema BiH. Sve transakcije sistema RTGS i žirokliring sistema prikupljaju se u
operativnom centru Centralne banke, koja obavlja kliring i saldiranje tih platnih naloga,
a zatim vraća informacije poslovnim bankama. U platnim transakcijama banka može
vršiti radnje za klijenta ili korespondentsku banku koja se nalazi izvan Bosne i
Hercegovine, u skladu sa važećim propisima.
Gotovinska plaćanja. Od 1998. godine za gotovinska plaćanja u BiH kao nacionalna
valuta koristi se konvertibilna marka. Oznaka valute je BAM, a šifra 977. Konvertibilna
marka je odlukom CB BiH u fiksnom paritetu, koji je naveden u prethodnom odeljku, i
svaka emitovana novčanica pokrivena je evrima.
Sistem plaćanja velikih vrednosti. U BiH je organizovan RTGS – bruto sistem
poravnanja u realnom vremenu, za transfer plaćanja velikih vrednosti. Ovaj sistem
sadrži CAS – Central Accounting System u kome su, u CB BiH, sredstva banaka koje
učestvuju u platnim transakcijama i gde se vrši poravnanje platnih naloga. Sistem RTGS
je skuplji od žirokliringa i trebalo bi da se koristi uglavnom za velika plaćanja [2].
Sistem RTGS je veoma siguran, s obzirom na to da koristi sve prednosti SWIFT mreže,
koja ima najviše standarde sigurnosti, a sistem tehnički onemogućava poravnanje
naloga za koje prethodno nisu obezbeđena sredstva. Takav nalog se neće izvršiti sve
dok banka ne obezbedi dovoljna sredstva na računu. U ovom sistemu banke mogu slati
plaćanja svakog radnog dana, u periodu od 8.00 do 16.00 časova.
Platni sistemi malih vrednosti. Žirokliring (Gyro Clearing) je sistem plaćanja malih
vrednosti, do 20.000 KM. Funkcioniše po principu multilateralnog kliringa koji se
odvija u tri ciklusa u toku radnog dana, 9.50 – I ciklus, 12.50 – II ciklus i 14.50 – III
ciklus. U svim klirinškim ciklusima prethodno se objedinjuju nalozi koji stižu iz svih
centara u BiH. Sva plaćanja između učesnika u kliringu poravnaju se i samo rezultat tog
poravnanja, neto zaduženja ili odobrenja odlaze u sistem RTGS, gde je poravnanje
konačno kada se ova salda prenesu sa računa banaka koje duguju na račune banaka koje
potražuju. Žirokliring koristi SWIFT formate poruka, ali ne i SWIFT mrežu, kao sistem
RTGS. Centralna banka BiH je, za potrebe žirokliringa, izgradila potpuno novu mrežu u
BiH. Sve komercijalne banke, u zavisnosti od toga u kom delu BiH se nalaze,
najkvalitetnijim telekomunikacionim linijama vezane su za potklirinške kuće u
Banjaluci, Mostaru i Sarajevu, a nove na Žirokliring centar u CB BiH u Sarajevu.
Sistem za kliring i saldiranje hartija od vrednosti. Kao što je već navedeno u delu
disertacije koji se odnosi na zakonsku regulativu, kliring i saldiranje u BiH vrše dve
institucije. To su Registar vrijednosnih papira u Federaciji BiH, sa sedištem u Sarajevu,
dok u Banjaluci funkcioniše Centralni registar hartija od vrijednosti a.d. Banjaluka.
Republika Makedonija
Opšti okvir. U platnom sistemu koji je u Makedoniji funkcionisao pre reforme
razlikovale su se dve grupe učesnika – fizička i pravna lica [33], [234]. Fizička lica su
se u platni promet uključivala preko banaka, a pravna lica su imala zakonsku obavezu
posedovanja jedinstvenog žiro računa u Zavodu za platni promet (ZPP). U oktobru
1997. godine Narodna banka Republike Makedonije (NBRM) usvojila je odluku po
kojoj se velika plaćanja (preko 5 miliona denara, a od aprila 1998. godine granica je
preko 3 miliona denara) izvršavaju preko komercijalnih banaka. Ova mera je dovela do
višeg stepena integracije bankarskog i privrednog sektora. Osim toga, bankama je bilo
omogućeno da raspolažu informacijama na osnovu kojih su bile u stanju da obezbede
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 71
optimalnu likvidnost za podmirenje saldiranja u toku dana. Odluka je bila prvi korak
reforme platnog sistema, koja je započeta 2001. godine.
Opšti regulatorni okvir. Zakonska regulativa u oblasti nacionalnog platnog sistema
Makedonije doneta je pre početka prelaska platnog prometa u banke da bi se izbegli
problemi, kojih je bilo u iskustvu Bosne i Hercegovine, u kojoj je zakonska regulativa
kasnila i izazvala je velike probleme. Osnovni zakon koji se primenjuje je Zakon o
platnom prometu [150]. Prva verzija, koja je omogućila primenu novih odrednica u
izmenjenom platnom sistemu, počela je da se primenjuje 1. jula 2001. godine. Prema
tom zakonu, određeno je da su nosioci platnog prometa NBRM i banke koje imaju
dozvolu da se bave platnim prometom. Uveden je obavezni bezgotovinski platni promet
za sva preduzeća, a gotovina u blagajnama preduzeća ograničena je blagajničkim
maksimumom. Ograničeno je i plaćanje u gotovini. Ovaj zakon je predstavljao veliko
unapređenje za Makedoniju i omogućio joj je da reformiše platni sistem po ugledu na
razvijene evropske zemlje. Poslednja verzija zakona usvojena je 2007. godine, a počela
je da se primenjuje 1. januara 2008. godine. Uvedene su vrlo značajne odrednice vezane
za izdavanje elektronskog novca i elektronskog plaćanja.
Učesnici u sistemu. Narodna banka Republike Makedonije je vlasnik, operater i
kontrolor platnih sistema. Na osnovu tih funkcija, NBRM otvara račune institucija
odgovornih za obavljanje poslova platnog prometa. U tu svrhu, institucija odgovorna za
sprovođenje platnog prometa podnosi zahtev za otvaranje računa, uz neophodne
dokumente, kao i spisak ovlašćenih potpisnika i ugovor o otvaranju naloga. Svi
postojeći računi stoje na raspolaganju učesnicima elektronskim putem u sistemu MIPS.
Osim toga, učesnik može i da zatvori račun u NBRM podnošenjem zahteva za
zatvaranje računa, a račun učesnika može biti zatvoren i na osnovu sudske odluke ili po
nalogu nadležnog organa. Druga velika grupa učesnika su poslovne banke, koje u
Makedoniji, u okviru platnog sistema, pokrivaju sve aktivnosti koje su neophodne da bi
platni promet mogao da se obavlja bez zastoja. Otvaraju i održavaju račune fizičkih i
pravnih lica, primaju i prosleđuju platne instrukcije u samoj banci, u međubankarskom
platnom prometu i međunarodnom platnom prometu. Obezbeđuju i funkcionisanje
plaćanja po osnovu transakcija elektronskih platnih kartica [142].
Gotovinska plaćanja. Denar je zvanična valuta Republike Makedonije. Oznaka denara
je MKD, a šifra 4217. Narodna banka Republike Makedonije ima ekskluzivno pravo na
štampanje i izdavanje gotovinskih novčanica u Makedoniji.
Sistem plaćanja velikih vrednosti. U Makedoniji za promet platnih naloga velikih
vrednosti organizovan je Makedonski interbankarski platni sistem – MIPS, koji po
svojim karakteristikama spada u bruto sistem obračuna u realnom vremenu (RTGS).
Operator i vlasnik MIPS sistema je NBRM. Cilj sistema je da obezbedi nesmetano
funkcionisanje platnog prometa, kao i realizaciju svih operacija koje su inicirane od
učesnika. Transakcije se obavljaju u skladu sa Operativnim pravilima sistema MIPS.
Platni sistemi malih vrednosti. Vlasnik i operator platnog sistema za obračun malih
vrednosti je klirinška kuća Klirinški interbankarski sistemi a.d. Skoplje. Nju su 2001.
godine osnovale banke, saglasno Zakonu o platnom prometu, sa ciljem obavljanja
kliringa i saldiranja plaćanja malih vrednosti na multilateralnoj neto osnovi. Učesnici u
kliringu su banke registrovane za obavljanje domaćeg platnog prometa. Granični iznos
koji se može procesirati putem kliringa je 1.000.000 denara. Klirinška kuća funkcioniše
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 72
u skladu sa pozitivnom zakonskom regulativom u oblasti platnog prometa Makedonije,
uzimajući u obzir BIS pravila i preporuke. Sistem koji funkcioniše u okviru klirinške
kuće poštuje Pravila poslovanja i obuhvata sledeće podsisteme: kliring malih
međubankarskih plaćanja (KIBS-kliring), jedinstveni registar transakcionih računa
(Erts-KIBS), informacije o blokiranim računima (KIBS-blokada), izdavanje sertifikata
(KIBS-IS), informativni servis (KIBS-info).
Sistem za kliring i saldiranje hartija od vrednosti. Institucija koja je u Makedoniji
zadužena za kliring i saldiranje hartija od vrednosti je Centralni depozitar za hartije od
vrednosti a.d. Skoplje (Централен депозитар за хартии од вредност а.д. Скопје). U
skladu sa članom 172 Zakona o hartijama od vrednosti Republike Makedonije i
Odlukom br. 07-167/1, u februaru 2001. godine ZPP je dobio ovlašćenje Vlade
Makedonije da sprovede mere i aktivnosti za osnivanje i implementaciju Registra hartija
od vrednosti. Osnovni cilj Centralnog registra bilo je uspostavljanje registra svih hartija
od vrednosti (akcija i obveznica) emitovanih u Republici Makedoniji. Osnivanjem
registra predviđeno je da budu zadovoljeni interesi: vlasnika hartija od vrednosti, stranih
investitora, trećih strana u transakcijama, emitenata, brokera, Makedonske berze akcija,
drugih autorizovanih institucija, ali i formiranje depoa hartija od vrednosti.
Republika Hrvatska
Opšti okvir. Početkom primene novog Zakona o platnom prometu u Hrvatskoj, u aprilu
2002. godine ostvaren je i poslednji korak u sprovođenju reforme hrvatskog platnog
sistema, čime je obezbeđena nova infrastruktura [33], [234]. Platni sistem u Hrvatskoj
postavljen je na tri nivoa. Prvi nivo se obavlja u okviru pojedinačne poslovne banke,
koja vrši plaćanje i saldiranje između svojih komitenata – deponenata. Drugi nivo je
obračun u Nacionalnom klirinškom sustavu (NKS) preko koga se banke međusobno
saldiraju za plaćanja svojih komitenata ako su deponenti druge banke. Direktni učesnici
u obračunu preko sistema NKS jesu banke i štedionice. Učesnik u sistemu NKS je i
Hrvatska narodna banka (HNB), a učesnik može biti i institucija koja posreduje u
obavljanju poslova platnog prometa, institucija koja obavlja poslove platnog prometa u
ime i za račun banke/štedionice i pravno lice koje, na osnovu posebnog ovlašćenja
direktnog učesnika, dostavlja naloge za platne transakcije u NKS, radi obračuna. Treći
nivo je Hrvatski sustav velikih plaćanja (HSVP).
Institucionalni aspekti. Centralna institucija u hrvatskom platnom prometu je Hrvatska
narodna banka. Ona je bila ključna u sprovođenju reforme platnog prometa, u periodu
od januara do aprila 2002. godine. Tada je platni promet decentralizovan i poslovi u
ovom domenu preneti su sa centralizovane ustanove na poslovne banke. Hrvatska
narodna banka je u tom periodu formirala Jedinstveni registar računa poslovnih
subjekata. Od 2002. godine Jedinstvenim registrom računa poslovnih subjekata
operativno upravlja Financijska agencija.
Opšti regulatorni okvir. Regulativa i nadzor nad platnim sistemom Hrvatske u
nadležnosti je HNB. Ona funkcioniše na osnovu Zakona o Hrvatskoj narodnoj banci,
kojim se regulišu najvažnija pitanja i domen ove institucije (položaj, poslovi, vlasnički
status, ovlašćenja i organizacija HNB, kao i odnos HNB sa Republikom Hrvatskom,
bankama i međunarodnim institucijama i organizacijama). Nosioci poslova platnog
prometa su HNB i banke. Nedepozitne institucije mogu, na osnovu ugovora, poslove
platnog prometa da obavljaju samo u ime i za račun depozitnih institucija.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 73
Gotovinska plaćanja. Kuna je zvanična valuta koja se koristi za gotovinska plaćanja u
Hrvatskoj. Oznaka valute je HRK, a šifra 191. Hrvatska narodna banka izdaje kovani i
papirni novac, a gotovinska plaćanja predstavljaju značajan udeo u ukupnim plaćanjima.
Sistem plaćanja velikih vrednosti. Hrvatska narodna banka je vlasnik i kontrolor
Hrvatskog sustava velikih plaćanja (HSVP). Sistem HSVP je proizvod kompanije
LogicaCMG iz Londona i započeo je sa radom 6. aprila 1999. godine.
Platni sistemi malih vrednosti. Nacionalni klirinški sustav (NKS) jeste platni sistem
malih vrednosti čiji je vlasnik i operator FINA. Počeo je sa radom 5. februara 2001.
godine. Sistem NKS je namenjen obračunu naloga za prenos između učesnika na neto
multilateralnoj šemi. Učesnici NKS-a su banke, HNB i treće strane. Posredni učesnici
sistema NKS su banke i druge finansijske institucije koje, na osnovu posebnih propisa,
koje donosi HNB, izvršavaju saldiranje međubankarskih platnih transakcija preko druge
banke.
Sistem za kliring i saldiranje hartija od vrednosti. Središnje klirinško depozitarno
društvo d.d. (SKDD) upravlja centralnim depoom dematerijalizovanih hartija od
vrednosti, upravlja sistemom kliringa i saldiranja transakcija hartijama od vrednosti
sklopljenih na tržištu berze i na multilateralnoj trgovinskoj platformi (MTP) ili izvan
tržišta berze i MTP-a (OTC transakcije), i određuje jedinstvene identifikacione oznake
dematerijalizovanih hartija od vrednosti (ISIN i CFI oznake).
Republika Crna Gora
Opšti okvir. Svesna značaja platnog sistema, Centralna banka Crne Gore (CBCG)
otpočela je, odmah po osnivanju samostalne države, 2001. godine, sa reformom tog
sistema [33], [234]. U prvoj fazi izrađena je sveobuhvatna strategija razvoja platnog
sistema u Crnoj Gori. U „Analizi finansijskog tržišta 2007. godine“ istaknuto je da je
reforma sprovedena fazno, imajući u vidu vrlo specifičan i funkcionalno kompleksan
platni sistem, koji je nasleđen od bivše SFRJ i SRJ. Njeni prioriteti su:
demonopolizacija poslova u platnom prometu, u smislu da poslovne banke svojim
klijentima ubuduće pružaju sve usluge u platnom prometu i izgradnja potpuno novog,
modernog platnog sistema uz maksimalno uvažavanje svih relevantnih međunarodnih
preporuka i bankarskih standarda, kao i specifičnih potreba u zemlji. Sve aktivnosti
sprovedene su u koordinaciji sa poslovnim bankama, državnim organima i
organizacijama i drugim relevantnim subjektima, i uz intenzivnu konsultantsku pomoć
pojedinih međunarodnih organizacija i centralnih banaka zemalja iz okruženja.
Opšti regulatorni okvir. Ključni regulatorni okvir u oblasti platnog sistema u Crnoj
Gori jeste Zakon o platnom prometu u zemlji, koji je donet u oktobru 2008. godine. Cilj
tog zakona je unapređenje platnog prometa u zemlji, dalje usklađivanje regulative sa
suštinskim principima za sistemski važne platne sisteme, Komitetom za platne i
obračunske sisteme Međunarodne banke za obračun, kao i regulativom EU.
Učesnici u sistemu. Prema Zakonu o platnom prometu u zemlji, učesnici u platnom
sistemu mogu biti: Centralna banka, banke i filijale stranih banaka, državni organi i
nosioci javnih ovlašćenja, centralne banke ostalih zemalja, ECB, Centralna depozitarna
agencija i ovlašćeni učesnici na tržištu hartija od vrednosti.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 74
Gotovinska plaćanja. Crna Gora ima specifičnu situaciju sa valutom u odnosu na
ostale zemlje Zapadnog Balkana. Zvanično sredstvo plaćanja u Crnoj Gori je evro.
Uveden je na osnovu Zakona o Centralnoj banci, kao zamena za nemačku marku, koja
je 2000. godine zamenila dinar. Odnos te dve valute, koji su utvrdile EU, centralne
banke zemalja evrozone i ECB jeste 1 EUR= 1,95583 DEM. Taj kurs je fiksni i ne
menja se, kao ni kursevi ostalih bivših valuta zemalja evrozone.
Sistem plaćanja velikih vrednosti. Platni sistem velikih vrednosti u Crnoj Gori
organizovan je kao i u ostalim zemljama Zapadnog Balkana po principu bruto obračuna
u realnom vremenu – RTGS. Učesnici u sistemu RTGS su CBCG, banke koje obavljaju
poslove platnog prometa u zemlji i drugi subjekti čiji se računi, u skladu sa zakonom,
vode kod CBCG.
Platni sistemi malih vrednosti. Sistem DNS organizuje se u okviru CBCG i služi za
procesiranje malih plaćanja, po multilateralnom neto principu sa odloženim vremenom
obračuna. Učesnici u DNS sistemu su CBCG i banke koje obavljaju poslove platnog
prometa u zemlji.
Sistem za kliring i saldiranje hartija od vrednosti. Na tržištu kapitala u Crnoj Gori
funkcionisale su dve berze: Montenegroberza a.d. i Nova berza hartija od vrijednosti
Crne Gore a.d. Montenegroberza je osnovana u junu 1993. godine, na osnovu Zakona o
tržištu novca i tržištu kapitala. Od septembra 2006. godine, Montenegroberza je u
potpunosti u privatnom vlasništvu. Vlada Crne Gore je, aukcijskom prodajom na berzi,
prodala svoj udeo od 5% u Montenergoberzi. Dve crnogorske berze su spojene
pripajanjem – NEX Montenegro je pripojen Montenegroberzi, 31. decembra 2010.
godine.
3.4.2 Platni sistemi u Srbiji
Operator platnog sistema može biti: pravno lice koje upravlja radom platnog sistema,
Narodna banka Srbije, banka sa sedištem u RS, platna institucija sa sedištem u RS,
institucija elektronskog novca sa sedištem u RS, drugo pravno lice u RS osnovano kao
a.d ili d.o.o, UBS ili drugi pružaoci platnih usluga sa sedištem u RS, kreditna institucije
iz države članice ili iz treće države preko svog ogranka, drugo pravno lice sa sedištem u
državi članici preko svog ogranka [33], [234]. Poslovi platnog sistema su izvršavanje
naloga za prenos, kliring (može uključiti i netiranje), netiranje (multilateralna ili
bilateralna neto pozicija za poravnanje) i poravnanje (izmirenje novčane obaveze,
odnosno namirenje potraživanja prenosom novčanih sredstava preko računa koji se
koriste za poravnanje.
Da bi pravno lice postalo operater platnog sistema, mora da priloži NBS pravila rada
koji treba da sadrže: poslovno ime i sedište operatora i agenta za poravnanje, uslove za
učešće i način učešća u platnom sistemu, način dostavljanja i provere naloga za prenos,
način obavljanja kliringa i/ili poravnanja, prava i obaveze učesnika u platnom sistemu i
operatora u vezi sa upravljanjem rizicima u platnom sistemu, radni dan i dnevni
terminski plan rada platnog sistema, uslove i način prestanka učešća u platnom sistemu.
Pravila rada platnog sistema koji je utvrđen kao bitan sadrže i momenat neopozivosti i
momenat ulaska naloga za prenos u platni sistem. Pravilima rada ne smeju se ograničiti
učešće u drugim platnim sistemima, diskriminatorno uređivati prava i obaveze učesnika,
niti ograničavati učešće koje se zasniva na pravnom statusu učesnika u platnom sistemu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 75
ili korisnika platnih usluga. Ne primenjuje se na: „sistemski važne“ platne sisteme i
platni sistem čiji su učesnici isključivo pružaoci platnih usluga koji čine grupu društava
povezanih udelom u kapitalu u kojoj jedno od tih društava ima kontrolno učešće nad
drugim društvima u grupi. Narodna banka Srbije operatoru izdaje dozvolu Narodne
banke Srbije, osim za rad platnog sistema čiji je operator NBS.
Dužnosti operatora platnog sistema su: održavanje tehničkih, organizacionih,
kadrovskih i drugih uslova utvrđenih ovim zakonom i drugim propisima, sistem
upravljanja i sistem unutrašnjih kontrola, upravljanje rizicima u platnom sistemu.
Operator je dužan da podnese zahtev za davanje saglasnosti za izmene i dopune
elemenata pravila rada platnog sistema. NBS bliže propisuje sistem upravljanja i sistem
unutrašnjih kontrola, kao i minimalne zahteve za upravljanje rizicima u platnom
sistemu. Operator je dužan da o nameri da poveri obavljanje pojedinih operativnih
poslova u vezi s radom platnog sistema drugog lica obavesti NBS. Operator mora
obezbediti: da se ne umanjuju obaveze i odgovornosti operatora prema učesnicima, da
se ne dovodi u pitanje usklađenost rada platnog sistema sa pravilima za rad i odredbama
ovog zakona, da se ne narušava mogućnost obavljanja nadgledanja od strane NBS.
Operator je dužan da čuva podatke o izvršenim nalozima za prenos i drugu
dokumentaciju nastalu u vezi sa uredbom platnog sistema, da u svojim poslovnim
knjigama odvojeno evidentira poslovne promene koje se odnose na prihode ostvarene u
vezi sa upravljanjem platnim sistemom, na pojedinačne finansijske izveštaje za
prethodnu godinu, sa izveštajem spoljnog revizora dostavi NBS, da na svojoj Internet
prezentaciji objavljuje i redovno ažurira osnovne informacije i podatke o platnom
sistemu čiji je operator, da dostavlja izveštaje koji se odnose na upravljanje platnim
sistemom.
3.4.2.1 Zakonska regulativa za platne sisteme u Srbiji
Zakoni koji regulišu procese platnih sistema u Republici Srbiji su sledeći [128]:
• Zakon o Narodnoj banci Srbije, [151], [152] prečišćeni tekst sačinjen na
osnovu teksta Zakona o Narodnoj banci Srbije („Službeni glasnik RS“, br.
72/2003) i njegovih izmena i dopuna objavljenih u „Službenom glasniku RS“,
br, 55/2004, 85/2005 – dr.zakon, 44/2010 i 76/2012
• Zakon o izmenama i dopunama Zakona o Narodnoj banci Srbije, „Službeni
glasnik RS“, br. 76/2012
• Zakon o Narodnoj banci Srbije, prečišćeni tekst sačinjen na osnovu teksta
Zakona o Narodnoj banci Srbije („Službeni glasnik RS“, br. 72/2003) i njegovih
izmena i dopuna objavljenih u „Službenom glasniku RS“, br, 55/2004, 85/2005
– dr.zakon i 44/2010
• Zakon o bankama, [148] prečišćeni tekst sačinjen na osnovu teksta Zakona o
bankama („Službeni glasnik RS“, br. 107/2005) i njegovih izmena i dopuna
objavljenih u „Službenom glasniku RS“, br. 91/2010
• Zakon o platnom prometu, prečišćeni tekst sačinjen na osnovu teksta Zakona o
platnom prometu („Službeni list SRJ“, br. 3/2002) i njegovih izmena i dopuna
objavljenih u „Službenom listu SRJ“, br. 5/2003 i „Službenom glasniku RS”, br.
43/2004, 62/2006 i 31/2011
Podzakonski akti se sastoje od odluka, pravila i uputstava [128]:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 76
• Odluka o obavljanju kliringa i obračuna direktnih zaduženja po osnovu ovlašćenja,
„Službeni glasnik RS“, br. 6/2010
• Odluka o opštim pravilima za obavljanje direktnih zaduženja po osnovu ovlašćenja,
„Službeni glasnik RS“, br. 6/2010, /ispravka 12/2010/
• Odluka o međubankarskom kliringu plaćanja u devizama, „Službeni glasnik RS“, br.
31/2007, 93/2007
• Odluka o načinu obavljanja platnog prometa preko novčanog računa centralnog registra,
depoa i kliringa hartija od vrednosti, „Službeni glasnik RS“, br. 89/2011
• Odluka o obračunu i kliringu i o funkcionisanju obračunskih računa banaka kod
Narodne banke Srbije, „Službeni glasnik RS“, 57/2004
• Odluka o uslovima i načinu otvaranja, vođenja i gašenja računa kod banke, „Službeni
glasnik RS“ br. 33/2005, 25/2009
• Odluka o načinu nadgledanja platnih klirinških i obračunskih sistema, „Službeni glasnik
RS“ br. 46/2009
• Odluka o obliku, sadržini i načinu korišćenja jedinstvenih instrumenata platnog
prometa, „Službeni glasnik RS“ br.57/2004, 82/2004
o Prilog 1
Nalog za uplatu
Nalog za isplatu
Nalog za naplatu
Nalog za prenos
o Prilog 2
o Prilog 2a
• Odluka o bližim uslovima i načinu davanja i oduzimanja bankama licence za obavljanje
platnog prometa, „Službeni glasnik RS“ br.57/2004, 33/2005
• Odluka o elektronskom načinu obavljanja platnog prometa, „Službeni glasnik RS“ br.
57/2004
• Odluka o jedinstvenoj strukturi za identifikaciju i klasifikaciju računa i o planu računa
za obavljanje platnog prometa kod banke, „Službeni glasnik RS“ br. 57/2004
• Odluka o određivanju poslova koje može da obavlja agent i uslovima za obavljanje tih
poslova, „Službeni glasnik RS“ br. 57/2004, 33/2005
• Odluku o vrsti podataka koje banke dostavljaju Narodnoj banci Srbije i o načinu i
rokovima dostavljanja tih podataka, „Službeni glasnik RS“, br. 81/2010
• Odluka o određivanju jedinstvenih identifikacionih brojeva banaka za obavljanje
platnog prometa
• Odluka o načinu vršenja kontrole platnog prometa kod banaka, „Službeni glasnik RS“
br. 57/2004
• Odluka o obavljanju međubankarskog obračuna čekova po tekućim računima građana,
„Službeni glasnik RS“ br. 72/2004
• Odluka o obavljanju obračuna i poravnanja platnih kartica, „Službeni glasnik RS“ br.
4/2009
• Uputstvo o načinu i rokovima dostavljanja podataka banaka o izvršenom platnom
prometu
• Uputstvo za realizaciju naloga za međubankarska plaćanja u slučaju da učesnik RTGS i
kliring sistema NBS nije u mogućnosti da realizuje plaćanja usled tehničkih problema
• Uputstvo o načinu dostavljanja podataka za vođenje jedinstvenog registra računa
• Uputstvo za dostavljanje Narodnoj banci Srbije podataka o poslovanju banaka s platnim
karticama
• Uputstvo o postupanju sa menicama izdatim do 31. decembra 2002. godine, „Službeni
glasnik RS“ br. 114/2005
• Prilog 1 (spisak filijala i ekspozitura Narodne banke Srbije u kojima postoje odseci za
prinudnu naplatu)
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 77
• Instrukcije bankama za postupanje po reklamacijama u vezi sa međubankarskim
plaćanjima
• Operativna pravila za kliring međunarodnih plaćanja
• Operativna pravila za kliring (neto obračun)
• Operativna pravila za obračun u realnom vremenu po bruto principu
• Operativna pravila za međubankarski kliring plaćanja u devizama
• Uputstvo o formatu i nameni poruka za razmenu podataka u obavljanju poslova platnog
prometa
• Uputstvo za sprovođenje odluke o elektronskom načinu obavljanja platnog prometa
3.4.2.2 Narodna banka Srbije kao operator platnih sistema
Narodna banka Srbije [128], [33], [234] je operator tri platna sistema: RTGS sistema,
kliring sistema i sistema međubankarskog i međunarodnog kliringa plaćanja u
devizama. RTGS sistem (obračun u realnom vremenu po bruto principu) podrazumeva
prijem i izvršavanje pojedinačnih naloga za plaćanje banaka u najkraćem mogućem
vremenu od momenta njihovog prijema – i to do visine pokrića na računu. U RTGS
sistemu mogu se izvršavati svi nalozi za plaćanje, s tim što se obavezno izvršavaju
nalozi za plaćanje iznos većih od 250.000 dinara („velika plaćanja“), što je utvrđeno
operativnim pravilima za RTGS sistem i kliring. Pod kliringom, tj. neto obračunom,
podrazumeva se prijem pojedinačnih naloga za plaćanje, ili grupa naloga za plaćanje, uz
koje se dostavlja specifikacija pojedinačnih naloga radi obračuna multilateralnih neto
iznosa na obračunskim računima. Nakon toga, za svakog učesnika u kliringu utvrđuje se
neto pozicija, čije se poravnanje vrši preko njegovog žiro računa. Plaćanja u kliringu
(„mala plaćanja”) jesu nalozi čiji je iznos do 250.000 dinara. Plaćanja u kliringu
izvršavaju se u procesu neto poravnanja u tri klirinška ciklusa svakog radnog dana (u
10.30, 12.30 i 14.45 časova). Učesnici u RTGS sistemu i u kliring sistemu Narodne
banke Srbije povezani su u jedinstvenu celinu, u kojoj se platne transakcije razmenjuju
porukama, zasnovanim na SWIFT standardu, kroz privatnu komunikacionu mrežu
Narodne banke Srbije. Sistem obezbeđuje primenu DVP (istovremeni prenos hartija od
vrednosti i novčanih sredstava) principa u obračunu hartija od vrednosti. Učesnici u
RTGS i kliring sistemu su Narodna banka Srbije, banke, Republika Srbija -
Ministarstvo finansija, Centralni registar, depo i kliring hartija od vrednosti i Udruženje
banaka Srbije. Radno vreme RTGS i kliring sistema utvrđeno je Dnevnim terminskim
planom. Sistem izvršava transakcije učesnika u toku radnog dana od 9.00 do 18.00
časova.
Pravna lica i fizička lica koja obavljaju delatnost dužna su da za plaćanje u dinarima
otvore tekući račun u banci, da vode sredstva na tom računu i vrše plaćanja preko tog
računa, u skladu sa Zakonom o platnom prometu i ugovorom o otvaranju i vođenju tog
računa zaključenim s bankom. Fizička lica koja ne obavljaju delatnost mogu imati kod
banke račune za plaćanje u dinarima. Pravna i fizička lica mogu imati više od jednog
računa u jednoj banci i račune u više banaka.
3.4.2.3 Platni sistemi malih plaćanja u Srbiji
Sistemi malih plaćanja u Republici Srbiji koji su osnovani na osnovu Zakona o platnom
prometu i propisima donetim na osnovu tog Zakona su: Kliring sistem Narodne banke
Srbije, DinaCard sistem i Sistem za međubankarski kliring čekova, Sistem za
međubankarski kliring direktnih zaduženja [33], [234].
Kliring sistem Narodne banke Srbije je sistem za razmenu i obradu pojedinačnih
naloga za plaćanje ili grupa naloga za plaćanje učesnika u platnom sistemu radi
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 78
obračuna multilateralnih neto iznosa za poravnanje. Operator kliring sistema je Narodna
banka Srbije, a poravnanje multilateralnih neto pozicija obavlja se u RTGS sistemu.
Učesnici u kliring sistemu mogu biti: Narodna banka Srbije, banke i Republika Srbija -
ministarstvo nadležno za poslove finansija.
DinaCard sistem - sistem za procesiranje i obradu potraživanja učesnika po osnovu
korišćenja nacionalne platne kartice - DinaCard, radi obračuna multilateralnih neto
iznosa za poravnanje. Operator DinaCard sistema je Narodna banka Srbije, odnosno,
organizacioni deo Narodne banke Srbije koji je nadležan za kliring po karticama -
Nacionalni centar za platne kartice, a poravnanje multilateralnih neto pozicija obavlja se
u RTGS sistemu. Učesnici u DinaCard sistemu mogu biti: banke koje izdaju DinaCard
kartice i banke preko kojih nastaje potraživanje po osnovu korišćenja. DinaCard kartica,
a koje su vlasnici mreža za prijem kartica.
Sistem za međubankarski kliring čekova je sistem za procesiranje i obradu
potraživanja učesnika po osnovu čekova po tekućim računima građana. Operator
sistema za međubankarski kliring čekova je Udruženje banaka Srbije, a poravnanje
multilateralnih neto pozicija obavlja se u RTGS sistemu. Učesnici u sistemu mogu biti:
banke i Republika Srbija - ministarstvo nadležno za poslove finansija, koji sa
Udruženjem banaka Srbije potpisuju Sporazum o obavljanju međusobnih usluga.
Sistem za međubankarski kliring direktnih zaduženja je sistem za procesiranje i
obradu transakcija po osnovu direktnih zaduženja radi izračunavanja multilateralnih
neto iznosa za poravnanje. Operator sistema za međubankarski kliring direktnih
zaduženja je Udruženje banaka Srbije, a poravnanje multilateralnih neto pozicija
obavlja se u RTGS sistemu. Učesnici u sistemu mogu biti: banke i Republika Srbija -
ministarstvo nadležno za poslove finansija, koji sa Udruženjem banaka Srbije potpisuju
ugovor o obavljanju kliringa i obračuna direktnih zaduženja.
Radi efikasnije primene Odluke o načinu nadgledanja platnih klirinških i obračunskih
sistema i Politike nadgledanja, Narodna banka Srbije je na bazi utvrđenih Kriterijuma za
klasifikaciju platnih sistema malih plaćanja koji funkcionišu u Republici Srbiji i
podataka za 2009. godinu procenila značaj sistema malih plaćanja i klasifikovala
Kliring sistem Narodne banke Srbije kao sistemski značajan platni sistem, a kao
značajne platne sisteme DinaCard sistem i sistem za međubankarski kliring čekova,
prikazano u tabeli 7, za period 01.01. – 31.12.2009. godine.
rbr Indikator Kliring sistem NBS DinaCard sistem Međubankarski
kliring čekova
1. Tržišno učešće 87,59 %; 6,59 % 5,82 %
2. Učešće u RTGS-u 1,69%; 0,13% 0,11%
3. Prosečna dnevna vrednost u dinarima 2.021.137.069,39 152.055.598,31 134.411.151,44
4. Koncentracioni racio 58,41%; 68,51% 80,46
5. Neting racio 66,27%; 74,53% 45,31%
6. Najveća negativna neto pozicija u dinarima 115.538.272.362,52 14.956.220.054,29 11.966.440.053,66
Tabela 7. Kvantitativni indikatori za sisteme malih plaćanja u RS
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 79
3.4.2.4 Nadgledanje platnih sistema u Srbiji
Narodna banka Srbije daje dozvolu i vodi evidenciju platnih sistema koji imaju dozvolu
za rad, kao i platnih sistema pod upravom Narodne banke Srbije [128], [141]. Narodna
banka Srbije vrši i nadzor nad obavljanjem poslova platnih sistema. Predmet nadzora je
provera usklađenosti poslovanja platnog sistema (sigurnost i efikasnost) sa zakonom o
platnim uslugama i podzakonskim aktima donetim na osnovu tog zakona. Nadzor se
vrši nad operatorom u delu njegovog poslovanja koji se odnosi na upravljanje radom
platnog sistema. Način vršenja nadzora može biti posredan ili neposredan. Na osnovu
nadzora propisuju se odgovarajuće mere u postupku nadzora koje mogu biti: upućivanje
preporuke, upućivanje pismene opomene, upućivanje nalogodavnog pisma, izricanje
naloga i mera za otklanjanje utvrđenih nepravilnosti, oduzimanje dozvole za rad platnog
sistema. Narodna banka Srbije može da odlučuje o meri koju preduzima prema subjektu
nadzora na osnovu diskrecione ocene.
Nadgledanje platnih sistema je funkcija centralne banke u okviru koje se ciljevi
sigurnosti i efikasnosti promovišu praćenjem postojećih i planiranih sistema, procenom
tih sistema i po potrebi, iniciranjem promena u njima. Centralne banke su posebno
zainteresovane za sigurno i efikasno funkcionisanje platnih sistema zbog ostvarivanja
njihovih osnovnih funkcija – obezbeđivanja poverenja u nacionalnu valutu i očuvanja
finansijske stabilnosti. Obavljanje funkcije nadgledanja od strane centralne banke
usmereno je na određeni sistem, a ne na individualne učesnike u sistemu.
Transparentnost centralne banke u vezi s obavljanjem funkcije nadgledanja je od
izuzetnog značaja za operatore sistema, kako bi razumeli i pratili poslovne zahteve i
standarde sa kojima se očekuje da budu usaglašeni. Pored toga, centralne banke, kroz
transparentnost, demonstriraju adekvatan stepen doslednosti u obavljanju nadgledanja i
pružaju osnovu za ocenu njegove uspešnosti.
Radi boljeg razumevanja i efikasnije primene odluke kojom se uređuje način
nadgledanja platnih klirinških i obračunskih sistema, a u saglasnosti s principima za
uspešno nadgledanje za koje se zalaže Banka za međunarodna poravnanja (Bank for
International Settlement – BIS), Narodna banka Srbije definiše Politiku nadgledanja
platnih sistema. Politikom nadgledanja platnih sistema bliže se utvrđuju ciljevi i
aktivnosti nadgledanja koje obavlja Narodna banka Srbije radi unapređenja platnih
sistema i obezbeđivanja nesmetanog funkcionisanja platnog prometa u zemlji. Osnovni
ciljevi nadgledanja su sigurnost i efikasnost platnih sistema i instrumenata plaćanja,
kojima se iniciraju transakcije plaćanja koje se izvršavaju u platnim sistemima.
Sigurnost označava limitiranje rizika koji se mogu pojaviti u platnom sistemu i koji
mogu ugroziti ili negativno uticati na adekvatno i kontinuirano funkcionisanje platnog
sistema i finansijsku stabilnost zemlje. Efikasnost podrazumeva brzo i ekonomično
obavljanje operacija u platnom sistemu, kao i nivo usluga koji je ekonomski isplativ za
učesnike sistema i njihove klijente i koji odgovara njihovim potrebama.
Nadgledanje platnih sistema obuhvata sledeće aktivnosti: praćenje (monitoring) i
analizu statističkih podataka, informacija, izveštaja i drugih dokumenata koji se odnose
na funkcionisanje platnih sistema i korišćenje instrumenata plaćanja kojima raspolaže
Narodna banka Srbije i procenu usklađenosti platnih sistema s međunarodnim
standardima i principima za funkcionisanje platnih sistema utvrđenih odlukom kojom se
propisuje način nadgledanja platnih sistema (u daljem tekstu: procena usklađenosti
platnih sistema). Monitoring predstavlja kontinuiranu aktivnost čije obavljanje ima za
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 80
rezultat izradu različitih izveštaja koji doprinose razumevanju funkcionisanja platnih
sistema, kao i njihove međusobne povezanosti i uticaja na finansijsku stabilnost zemlje.
Procena usklađenosti platnih sistema predstavlja periodičnu aktivnost koja se obavlja s
ciljem sagledavanja usklađenosti tih sistema s međunarodnim standardima i principima
za funkcionisanje platnih sistema. Navedena aktivnost nije usmerena na individualne
učesnike u sistemu, već na platni sistem u celini i obavlja se u skladu sa Metodologijom
za procenu usklađenosti platnih sistema.
Narodna banka Srbije definiše smernice za primenu principa za funkcionisanje platnih
sistema kako bi na transparentan način prikazala standarde kojima se rukovodi prilikom
obavljanja procene platnih sistema, kao jedne od aktivnosti u okviru nadgledanja. Na
osnovu rezultata monitoringa platnih sistema i procene usklađenosti tih sistema,
Narodna banka Srbije može predlagati i inicirati izmene u platnim sistemima i to putem:
davanja preporuka operatoru platnog sistema o sprovođenju neophodnih izmena koje su
od značaja za njegovo sigurno i efikasno funkcionisanje („moralno ubeđivanje”),
međusobne saradnje organizacionih delova Narodne banke Srbije, izmena i dopuna
pravne regulative kojom se uređuje platni promet u zemlji, kao i donošenjem različitih
smernica i preporuka kojima će se obezbediti ispunjavanje osnovnih ciljeva
nadgledanja.
Radi transparentnosti, Narodna banka Srbije rezultate nadgledanja prezentuje u okviru
Godišnjeg izveštaja o stanju u finansijskom sistemu zemlje, kao i kroz različite izveštaje
koje objavljuje na svojoj Internet stranici. U obavljanju nadgledanja Narodna banka
Srbije obezbeđuje poverljivost određenih statističkih podataka, informacija i drugih
dokumenata koji se odnose na funkcionisanje platnih sistema i koristi ih samo u svrhu
obavljanja aktivnosti koje obuhvata nadgledanje tih sistema. Narodna banka Srbije, radi
uspešnog obavljanja nadgledanja i ispunjavanja postavljenih ciljeva, aktivno sarađuje sa
drugim relevantnim institucijama na nacionalnom i međunarodnom nivou, kao i sa
centralnim bankama drugih zemalja.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 81
4 Infrastruktura elektronskog poslovanja platnih sistema
4.1 Internet tehnologije
Informaciona tehnologija koja je najradikalnije promenila svet i najviše doprinela
internacionalizaciji i globalizaciji je Internet. Nijedna tehnologija do sada, u tako
kratkom vremenskom periodu, nije ostvarila brži razvoj i snažniju primenu od Interneta.
Za afirmaciju ove informacione tehnologije, između mnogih, zaslužne su sledeće
činjenice:
• Internet se smatra nosiocem novog talasa digitalne revolucije;
• Ogroman kapital je usmeren na razvoj Interneta, globalnog informatičkog
projekta, jedinstvenog informatičkog prostora;
• Internet je infrastrukturna i komunikacijska pretpostavka koncepta svetske
ekonomske globalizacije, modernog e-poslovanja.
Internet funkcioniše kao jedinstvena globalna mreža. Predstavlja decentralizovan sistem
više autonomnih lokalnih i globalnih mreža međusobno povezanih na osnovu istog
skupa protokola. Decentralizovana organizacija mreže doprinosi njenoj otpornosti na
otkaze - otkaz bilo kog dela mreže ne utiče na ostatak mreže. Sam način povezivanja
autonomnih celina u jedinstvenu mrežu bio je podložan stalnim promenama. Današnja
arhitektura Interneta može se opisati kao skup međusobno povezanih logičkih celina,
koju čine mreže pojedinih provajdera i njihovih korisnika.
Internet označava globalni informacioni sistem koji je logički međusobno povezan
globalnim jedinstvenim adresnim prostorom zasnovanim na Internet protokolu (IP) ili
njegovim budućim ekstenzijama; može da omogući komunikacije korišćenjem
Transmission Control Protocol/Internet Protocol-a (TCP/IP) ili njegovih budućih
ekstenzija i/ili drugih IP kompatibilnih protokola; i omogućava, koristi ili čini
dostupnim, bilo javno ili privatno, usluge visokog nivoa koje se oslanjaju na
komunikacionu ili sličnu infrastrukturu [225]. Iako je arhitekturu globalne mreže teško
sagledati u celini, struktura se danas može podeliti na tri nivoa: korisnički nivo (user
level), pristupni nivo (access level), nivo jezgra (core level). Korisnički nivo obuhvata
mreže krajnjih korisnika koje mogu biti povezane korišćenjem jednog linka (single-
homed) ka jednom davaocu Internet usluga - Internet provajderu (ISP) ili više
nezavisnih fizičkih i logičkih veza (multi-homed) ka više nezavisnih provajdera.
Infrastrukturu interneta čini nekoliko glavnih komponenata [93]: kičma (backbone),
ruteri (digitalni preklopnici), tačke pristupa (POP i NAP), serveri, korisnički računari.
4.1.1 Komunikacioni protokoli na internetu
Da bi računari povezani u mrežu mogli međusobno da komuniciraju, neophodno je da
se usvoje pravila za komunikaciju, zajednička za sve koji žele da pristupe mreži. Skup
pravila i normi koji opisuje postupke koji se primenjuju u računarskim
telekomunikacijama naziva se protokol [74]. Pravila i konvencije koji se koriste u
komunikaciji između dva sloja n dva računara zovu se protokol sloja n. Protokol
predstavlja u osnovi dogovor između dve jedinice o načinu komuniciranja. Za elemente
odgovarajućih slojeva na različitim računarima kaže se da su ravnopravni. Ravnopravni
elementi mogu da budu procesi, hardverski uređaji, ili čak ljudi. U stvarnosti se nikad
ne prenose podaci direktno od sloja n jednog sistema ka sloju n drugog sistema. Svaki
sloj prosleđuje podatke i upravljačke informacije sloju ispod sebe, sve do najnižeg sloja.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 82
Ispod najnižeg sloja je fizički medijum kroz koji se odvija stvarna komunikacija.
Između svaka dva susedna sloja nalazi se interfejs. Interfejs određuje osnovne operacije
i usluge koje donji sloj nudi gornjem sloju. Osnovni elementi protokola su sintaksa
(format podataka i nivo signala), semantika (upravljačke informacije, upravljanje
greškama), timing-signali za sinhronizaciju (podešavanje brzine prenosa,
sekvenciranje).
Skup slojeva i protokola naziva se arhitektura mreže. Specifikacija arhitekture mreže
mora da sadrži dovoljno informacija kako bi realizator mogao da za svaki sloj napiše
program ili projektuje hardver koji će slediti pravila odgovarajućeg protokola. Lista
protokola koju koristi određeni sistem (jedan protokol po sloju), naziva se skup
protokola (protocol stack).
TCP/IP predstavlja grupu protokola, od kojih svaki ima specifičnu ulogu, dok je sam
naziv zapravo akronim dva najvažnija protokola iz grupe - transportnog TCP protokola
(Transmission Control Protocol) i mrežnog IP protokola (Internet Protocol). TCP/IP
slojevi su:
• Fizički sloj (Physical layer) - definiše električne i mehaničke osobine koje mora
da zadovolji prenosni medijum, kao i formate signala koji se koriste na
medijumu za prenos.
• Sloj veze (Data link layer) - definiše formate paketa koji se prenose po fizičkom
medijumu, kao i postupke detekcije i eventualne korekcije grešaka u prenosu.
• ARP (Address Resolution Protocol) - definiše postupak konverzije 32-bitne
Internet (IP) numeričke adrese u adresu razumljivu sloju veze i vezan je za
konkretnu mrežnu tehnologiju.
• IP (Internet Protocol) - obavlja zadatke vezane za usmeravanje (rutiranje)
paketa u mreži, u zavisnosti od polazne i odredišne Internet (IP) adrese.
• UDP (User Datagram Protocol) - vrši razvrstavanje datagrama prema
aplikacijama (npr. datagrame koji pripadaju Telnet servisu, datagrame koji
pripadaju FTP servisu itd.), odnosno, vrši multipleksiranje prema servisima.
• TCP (Transmission Control Protocol) - osim što vrši multipleksiranje paketa
prema servisima, TCP obavlja niz složenijih zadataka vezanih za uspostavljanje
i raskidanje veze, kontrolu ispravnosti i redosleda paketa na prijemu, kontrolu
toka podataka itd; TCP obavlja potpunu kontrolu ispravnosti podataka na
krajevima veze, zahteva ponovno emitovanje paketa ako primeti da paket nije
stigao ili je stigao oštećen, vrši kontrolu toka podataka, u smislu dinamičkog
propuštanja veće ili manje količine podataka u jedinici vremena.
Aplikativni sloj (Application layer) - predstavlja skup protokola vezanih za
funkcionisanje pojedinih aplikacija. Na primer, FTP (File Transfer Protocol) definiše
protokol vezan za prenos datoteka; SMTP (Simple Mail Transfer Protocol) definiše
proceduru razmene elektronske pošte između dva sistema priključena na Internet; HTTP
(Hyper-Text Transport Protocol) je protokol kojim se prenose elementi (tekstovi, slike,
zvučni zapisi) koji čine veb-prezentaciju itd.
U nastavku su primeri protokola mreža [161]:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 83
WAN
HDLC (High-level Data Link Control) koji predstavlja grupu protokola namenjenu za
prenos podataka između čvorova u mreži. Podaci su organizovani u frame-ove. HDLC
je protokol drugog sloja OSI modela (Sloj voda podataka). Prenos HDLC paketa je
sinhron i fizički sloj treba da obezbedi odgovarajuće metode za sinhronu predaju i
prijem ovih paketa
LAPB (Link Access Procedure, Balanced) je protokol sloja voda podataka namenjen za
komunikaciju između DTE i DCE u X.25 protokol stack-u koji je izveden iz HDLC
protokola, to je Point to Point protokol i koristi Asynchronous Balanced Mode (ABM)
transfer mod. Veoma je robustan i koristi se u serijskoj komunikaciji, kao i u satelitskim
vezama.
Frame Relay protocol je protokol drugog sloja OSI arhitekture. Koristi se za
povezivanje LAN mreža i krajnjih tačaka WAN mreža. Ram Frame Relay protokola
prenosi se preko virtuelnih kola (logički definisani putevi od izvora do odredišta). Može
prihvatiti različite tipove podataka.
X.25 mreža se može podeliti po vrsti uređaja koje povezuje u tri grupe: Data Terminal
Equipment (DTE) grupu sa krajnjim uređajima u mreži (terminali, personalni računari),
Data Circuit-terminating Equipment (DCE) sa komunikacionim uređajima (modemi,
switch-evi) i Packet Switching Exchange (PSE) switch-evi koji čine osnovu prenosne
mreže i oni prenose podatke između DTE kroz X.25 PSN (Public Switching Network).
X.25 protokol je definisan od strane ITU kao implementacija prva tri sloja OSI modela.
LAN
Ethernet protokol se može uzeti kao primer protokola LAN mreža koji obuhvata
funkcije fizičkog sloja i sloja voda podataka. Originalna verzija Ethernet protokola
(Ethernet Version) kreirana je od strane kompanija Digital, Intel i Xerox i poznata je
pod nazivom DIX, dok je IEEE 802.3 definisan kasnije. Oba ova standarda, odnosno
tipa frame-ova mogu koegzistirati u istoj mreži, koristeći istu tehniku pristupa
medijumima prenosa – tehniku višestrukog pristupa sa nadgledanjem nosioca i
detekcijom kolizije.
Primeri LAN protokola su i Internet protokol verzija 4 (IPv4), Internet protokol verzija
6 (IPv6), UDP protokol, UDP protokola za komunikaciju u realnom vremenu, odnosno
RTP protokol, ICMP protokol (Internet Control Message Protocol, koji pomoću
odgovarajućih kontrolnih poruka dobija povratnu informaciju o stanju i eventualnim
problemima koji postoje u mreži).
Primeri alata baziranih na ICMP protokolu:
• Ping koji koristi Echo Request i Echo Reply poruke, svaka Echo poruka sadrži
broj sekvence (inicijalno 0) koja se inkrementuje za 1 nakon svake transmisije i
vremensku markicu (Timestamp) koja govori o vremenu transmisije, a koristi se
za testiranje dostupnosti odredišta, vremena potrebnog za prenos paketa,
brojanje hopova do odredišta (ukoliko ne dobijemo odgovor, ne znači da je
odredište nedostupno).
• Traceroute se kao i ping koristi za proveru dostupnosti odredišta, ali daje i
informaciju o prenosnom sistemu (npr. IP ruterima) između izvora i odredišta,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 84
koristi ICMP echo poruke adresirane na odredišnu IP adresu i koristi se TTL
brojač hopova, pri čemu se „primorava” svaka deonica da vrati poruku „greška“.
4.1.2 XML tehnologije
XML (eXtensible Markup Language) [229] je zasnovan na istim principima kao i
SGML, ali je znatno jednostavniji i prilagođen je veb-u. Kao i SGML, i XML se koristi
za definisanje drugih jezika, pa se naziva i metajezik. Međutim, XML je mnogo
jednostavniji od SGML-a. XML je jezik oznaka koji ne ograničava skup oznaka koje se
mogu koristiti, niti gramatiku tog jezika.
Postoje dva osnovna koncepta kod XML dokumenta. Prvi koncept uslovljava da svaki
XML dokument mora biti dobro strukturiran. Dobro strukturiran dokument je onaj čiji
su svi otvoreni tagovi i zatvoreni, i to po istom redosledu, te korišćena sintaksa sledi
specifikaciju. Drugi koncept XML dokumenta je validnost dokumenta. Validan
dokument je onaj koji odgovara definiciji tipa dokumenta (DTD - Document Type
Definition). DTD tačno navodi oznake i raspored elemenata koji se mogu koristiti u
XML dokumentu. On predstavlja proširenje XML dokumenta, opisujući njegove
gradivne elemente. Pomoću DTD-a može se definisati struktura dokumenta kreiranjem
liste dopuštenih elemenata [39].
XML je metajezik, koji služi za opis drugih jezika. Omogućava razvoj tipova podataka,
u cilju identifikacije i korišćenja informacija u dokumentima. Podaci u XML-u se
predstavljaju u strukturi stabla, pri čemu svaki čvor stabla može da se tretira kao
poseban objekat. U XML-u akcenat je na opisu podataka. Preko preciznog opisa i
validacije podataka smanjuje se mogućnost primene proceduralnih alata, čime se
olakšava proces obrade podataka i smanjuje broj grešaka. Podaci opisani u XML-u
nezavisni su od platforme na kojoj se koriste. XML je koncipiran sa idejom da omogući
punu iskorišćenost i međuoperativnost World Wide Web-a.
XML je kreiran sa namerom da bude jednostavan za učenje, jeftin, brz i optimizovan za
Internet. XML se naziva i eXcellent Marketing Language jer predstavlja:
• univerzalni format podataka, XML omogućuje kreiranje sopstvenih formata
podataka i njihovu razmenu preko postojećih mreža i aplikacija;
• integraciju podataka, XML vrši jednostavnu integraciju podataka kod već
postojećih aplikacija i platformi;
• prilagodljiv, razumljiv jezik i za čoveka i za mašinu, primaoca i pošiljaoca, te
predstavlja najupotrebljiviji standard za manipulaciju podataka i njihovu
razmenu.
Svrha XML je da generiše sopstvene tagove, njihovo značenje i njihov prikaz. XML
opisuje strukturu podataka, integriše protokole i obezbeđuje razmenu podataka.
Odnosno, predstavlja skup pravila koja omogućavaju opis podataka u tekstualnom
formatu. Primeri primene XML su:
• XML for Content Providers. Istoj informaciji može se pristupati i ona se može
čitati na različitim jezicima. Svaki XML dokument može da sadrži opis
gramatike ili sintakse kako bi se mogao proveriti i ispraviti sadržaj.
• XML for Content and Knowledge Management. XML nosi informaciju o
sadržaju pa su pretraživanje, indeksiranje i pronalaženje podataka jednostavniji.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 85
Transformacija podataka iz XML omogućava prikaz na različite medije (veb,
CD ROM, papir), bez nepotrebnih modifikacija i dupliranja sadržaja.
• XML for Content Aggregation. XML obezbeđuje da se informacije sa različitih
mesta integrišu na jednom mestu.
• XML for Electronic Document Interchange. XML omogućava kreiranje
strukture za razmenu informacija i objedinjuje postojeće protokole i standarde.
• XML and E-Commerce. XML obezbeđuje sintaksu za identifikaciju informacija
potrebnih za obavljanje poslovnih transakcija.
• XML for Design. Scalable Vector Graphic (SVG) predstavlja jezik za opis
dvodimenzionalnih vektora kojima se predstavljaju grafički elementi
korišćenjem XML-a.
XML-ov model podataka je predstavljen na slici 12.
Slika 12. XML model podataka
Svi čvorovi u XML dokumentu formiraju stablo dokumenta (ili stablo čvorova). Svaki
element, atribut, tekst itd. u XML dokumentu predstavlja čvor u stablu. Stablo počinje
čvorom dokumenta i nastavlja da se grana sve dok ne obuhvati sve tekstualne čvorove
na najnižem nivou stabla.
Termini „roditelj“ (parent) i „dete“ (child) koriste se da bi opisali odnos između
čvorova. Neki čvorovi mogu da imaju čvorove decu, dok drugi čvorovi nemaju decu
(čvorovi listovi). Zato što je XML dokument strukturiran u formi stabla, može biti
prenesen bez poznavanja tačne strukture stabla i bez poznavanja tipova koji su sadržani
u njemu.
4.1.2.1 Sintaksna interoperabilnost i XML
Sintaksna interoperabilnost služi prevazilaženju jaza između formata podataka,
standarda jezika, operativnih sistema i hardverskih platformi [227]. Od posebnog
interesa je interoperabilnost, koja se tiče mogućnosti da dva sistema prepoznaju
zajednički standard obrade i prezentacije podataka. Danas najrašireniji sintaksni
standard jeste XML (Extensible Markup Language). XML je jezik koji se koristi za
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 86
opisivanje strukture podataka. Njegove mogućnosti mogu da dođu do izražaja svuda gde
se obavljaju operacije ulaza i izlaza, memorisanja ili prenosa podataka sa jednog mesta
na drugo. Verovatno najpoznatija oblast njegove primene je rad na mreži, posebno u
slučaju mobilnih uređaja čija se tehnologija komunikacije sa mrežom bazira na XML-u.
XML je preteča WAP-a i WML-a.
XML je standard razvijen u WWW Konzorcijumu (World Wide Web Consortium -
W3C), organizaciji koja određuje opšti smer kojim se veb razvija. W3C grupa zadužena
za XML opisala je XML na sledeći način: „Proširivi markerski jezik (XML) je
potkategorija standardnog opšteg markerskog jezika (Standard Generalized Markup
Language, SGML). Njegov cilj je da izvornom SGML-u omogući postavljanje,
preuzimanje i obradu na vebu na način kako je danas to moguće sa HTML-om. XML je
napravljen sa ciljem da bude jednostavan za primenu i da omogući kombinovanu
upotrebu sa SGML-om i HTML-om.“
XML je fleksibilan način kreiranja podataka zajedničke strukture. Takav zapis podataka
omogućava da se preko mreže prenose istovremeno dve stvari: podaci i njihova
struktura. Oznake (tag) ga čine samoopisnim i lako razumljivim među ljudima, ali i
programima. XML mogu koristiti pojedinci, grupa pojedinaca ili kompanije koje žele
razmenjivati informacije na konzistentan način.
XML definiše otvoreni, fleksibilni standard za opisivanje, smeštanje, objavljivanje i
razmenu bilo koje vrste informacija. Poslovni podaci izraženi XML-om oslobođeni su
ograničenja privatnih formata i trebalo bi da budu razumljivi i nakon što zastare
računarski sistemi na kojima su nastali i sistemi za rad s bazama podataka gde su bili
smešteni. XML-om se mogu opisati i izraziti različite vrste podataka; tako, na primer,
postoje XML standardi dokumenata (DTD – Document Type Definition) za finansijske
podatke, bibliografiju, genetski kod, elektronsko poslovanje - ebXML itd.
Prvi standard za prezentaciju strukturiranih dokumenata bio je SGML (Standard
Generalized Markup Language), usvojen od strane ISO-a (International Standards
Organisation) 1986. godine. Ovaj standard se oslanjao na viziju tzv. strukturiranih
dokumenata. Taj pojam je obuhvatao težnju da se pre kreiranja dokumenata njihova
logička struktura odredi unutar zacrtanog okvira. Taj okvir se zove DTD (Document
Type Definition). Unutar DTD-a hijerarhijska struktura delova dokumenata je
definisana, gde je moguće te delove dokumenata povezati s atributima koji celini dodaju
semantičke informacije, tj. informacije o značenju. Krajem osamdesetih, uz razvoj veb
platforme, na osnovu SGML-a razvijen je i HTML (Hypertext Markup Language), još
uvek prisutni standard za prezentaciju onlajn dokumenata. Godine 1998, od strane
W3C-a, razvija se XML. HTML opisuje kako sadržaj (veb stranice) treba da izgleda, ali
on ne daje informaciju o strukturi i značenju podataka. XML, s druge strane, izdvaja
sadržaj od njegove prezentacije i definiše način označavanja za različite scenarije, tj.
upotrebe. To znači da je DTD unutar HTML-a fiksiran, dok je kod XML-a prilagodljiv.
Drugim rečima, kod XML-a nazive elemenata (tagova) može definisati onaj ko pravi
XML dokument.
U velikim organizacionim strukturama u elektronskom poslovanju platnih sistema
postoji veliki broj različitih organizacionih jedinica, koje bi mogle biti sklone korišćenju
različitih XML rečnika. U slučaju da dva ili više različitih autora koriste dva ili više
elemenata sa istim imenom, a ti elementi pripadaju različitim rečnicima, onda se ti
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 87
sporni elementi povezuju s XML prostorima imena (name-spaces), pomoću kojih se
definiše način razlikovanja tih elemenata.
4.1.2.2 XML dokument
XML dokument čini skup strukturiranih podataka smeštenih u neku vrstu poruke koja
opisuje podatke. XML dokumenti mogu biti datoteke, kao i poruke koje se mogu
prenositi Internetom, ali i između komponenata jednog računala. Sintaksa tih
dokumenata može, ali ne mora, biti čitljiva čoveku, a sam dokument može sam sebe
opisivati. Međutim, XML dokumenti ne moraju biti dokumenti u tradicionalnom smislu,
mogu biti i podaci izvučeni npr. iz relacionih baza podataka. Takođe, XML dokumenti
mogu se obrađivati i na serveru (kada dva servera razmenjuju podatke bez intervencije
čoveka) i kod klijenta. Posebno bitan tip XML dokumenata su XML šeme koje tumače
deljene rečnike (između više korisnika) i daju mogućnost uređajima da se ponašaju u
skladu sa ljudskim pravilima, na način da pružaju osnovu za definisanje strukture,
sadržaja i semantike XML dokumenata.
4.1.2.3 XML šema kao standard za podatke
U smislu tehnologije, evropska bankarska industrija je odredila da standardni SEPA
format podataka bude baziran na XML-u (ISO 20022 [112]) za transport platnih poruka.
U budućnosti ovaj uniformni tehnički standard će biti polazište za transparentnu platnu
infrastrukturu u jedinstvenoj evropskoj platnoj zoni što će omogućiti potpunu
automatizaciju izvršenja plaćanja.
ISO 20022 - UNIversal Financial Industry Message scheme (UNIFI) je internacionalni
standard koji definiše ISO platformu za razvoj finansijskih standarda. Pristup prisutan u
šemama poslovnog modeliranja omogućava korisnicima i informatičarima da prezentuju
finansijske poslovne modele i pripadajuće transakcije sa formalnom sintaksno
nezavisnom notacijom. Ovi poslovno-transakcioni modeli su stvarni poslovni standardi.
Oni mogu biti prevedeni u fizičke poruke željene sintakse. U vreme kada je UNIFI
počeo sa razvojem, XML (eXtensible Mark-up Language) je već bio vodeća sintaksa za
e-komunikaciju.
Ako ne postoje UNIFI poruke koje pokrivaju specifične transakcije, može se
inicijativom definisati novi model i poruke koje će odobriti UNIFI registraciono telo.
Ako poruka postoji u repozitorijumu, ali ne zadovoljava sve potrebe, može se
inicijativom kreirati nova verzija poruka koja će ih prilagoditi potrebama. Ekvivalentan
način zadavanja standarda koriste i ostale organizacije koje svoje elektronsko
poslovanje baziraju na XML baziranim standardima, te na taj način XML šema postaje
standard za podatke.
XSD šeme, kao standard za podatke, mogu se iskoristiti kao osnova objektno -
relacionog mapiranja [77]. Kao dokaz, može se izvesti generisanje šeme baze podataka
iz XSD šeme. Postoje i alati koji taj zadatak mogu obaviti. Objektno - relaciono
mapiranje je skup obrazaca za kreiranje i metode koja omogućava da objektno
orijentisana struktura podataka može perzistirati u relacionoj bazi podataka. Objektno -
relaciono mapiranje je važan deo skoro svakog sistema koji koristi relacioni sistem
upravljanja bazama podataka. Veoma je važno objektno - relaciono mapiranje primeniti
na pravi način pošto i izrada strukture baze podataka i strukture objekata zavise od tog
mapiranja. Transformacija podataka iz objekata u memoriji i obratno može umanjiti
performanse, mogućnost skaliranja sistema i robusnosti sistema. Kompleksne
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 88
nekonzistentne tehnike mapiranja mogu biti teške za realizaciju i baze podataka i
aplikativnih elemenata sistema. Baza podataka je, uobičajeno, zajednička za više
aplikativne elemente sistema, od kojih mnogi mogu biti razvijeni mnogo nakon što je
realizovana baza podataka. Postoji mnogo alata, veći broj metodologija i obrazaca za
realizaciju mapiranja. Osnovni zahtev je centralizacija definicija šema u obliku koji
može biti konvertovan u objektno orijentisanu i relacionu strukturu. XSD je jedna od
takvih reprezentacija. XSD šema dozvoljava da se definiše bogata struktura podataka
koja može biti konvertovana i u objektno orijentisanu strukturu i relacionu strukturu.
Bez obzira na kompleksnost, XSD je praktično najbolji izbor u odnosu na alternative i
otvara mnoge mogućnosti za inovacije u integraciji. Na primer, u potrazi za osobinom
sistema, dodajući osobinu XSD šemi, tu osobinu možemo automatski direktno objektu i
tabeli u isto vreme. Ukoliko se ontologija izmeni, može se proizvesti XSD baziran na
izmenjenoj ontologiji, što će se odraziti i na objektnu i relacionu strukturu sistema.
Osnovna korist od korišćenja XSD šeme je činjenica da je dovoljno definisati šemu
samo jednom, dok u suprotnom postoji potreba da se definisanje vrši dva puta za
objektno orijentisane elemente i ponovo za relacione strukture. Objektno - relaciono
mapiranje je jedan od osnovnih elemenata arhitekture aplikativnih sistema u poslovanju.
Proširivi jezik za označavanje, u oznaci XML je format podataka koji omogućava
razmenu podataka između istih ili različitih računarskih sistema bez potrebe pisanja
programa ili „interfejsa“. Značenje skraćenice XML je sledeće: „Extensible” (proširiv)
jer nije ograničen na jednu upotrebu ili jednu aplikaciju. „Markup” (označiti) jer
identifikuje informacije – posebno polje po polje ili elemente od kojih se sastoji poruka.
„Language” (jezik) jer je skup pravila ili „protokol“. Proširivi jezik za označavanje -
XML je fleksibilan, javni skup standarda za označavanje i organizaciju informacija
koje, na taj način priređene, mogu biti transportovane putem mreže kao što je internet i
spremne za interpretaciju od strane različitih računarskih sistema. Tehnički, XML može
biti opisan kao od platforme nezavisan, samoopisujući, proširiv standard za razmenu
informacija. Proširivi jezik za označavanje - XML je samo metajezik - dijalekti mogu
biti razvijeni kao standard, da podrži različite tipove poruka predviđenih za jednu vrstu
posla.
Kada se zapišu kao XML, podaci mogu biti deljeni ili transportovani preko različitih
sistema, bez obzira da li su ti sistemi interni ili eksterni – između različitih organizacija.
U odnosu na flat fajl (txt fajl sa informacijama odvojenih zarezom ili slično), XML
poseduje dodatnu dimenziju u povećavanju stepena integracije podataka.
Pretpostavimo da Preduzeće A snabdeva Preduzeće B sa podacima u CSV (Comma
Separated Values) formatu. Ukoliko Preduzeće A omaškom upiše neki podatak loše u
CSV fajl, šanse da će CSV fajl biti dobro importovan u sistem Preduzeća B sa
saznanjem koji podaci su loše upisani, jesu male, a postoji i verovatnoća da će loše
formatirani podaci izazvati neregularan rad sistema Preduzeća B. U XML fajlu se zna
na koji način će podaci biti prezentovani i biće uočeni loši podaci. Isto tako, može biti
izvršena i provera podataka na osnovu odgovarajuće XSD šeme (XML Schema
Document) koja može biti poslata sa odgovarajućim XML fajlom.
Kada Preduzeće A želi da pošalje CSV fajl sa podacima hijerarhijske strukture (kao
primer možemo uzeti listu faktura sa pripadajućim detaljnim opisima stavki po
fakturama), tada se stvari obično iskomplikuju bilo sa složenošću strukture fajla ili sa
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 89
višestrukim fajlovima u kojima su predstavljeni podaci, a delom i isti podaci u različitim
fajlovima, na primer, podaci koji su potrebni da se predstavi deo ili čitav ključ sloga.
Za XML takva struktura nije potrebna jer je u njemu uključen mehanizam koji
obezbeđuje hijerarhijsku strukturu podataka odgovarajućom strukturom XML atributa.
XML je objektno orijentisan, u smislu pogodnosti opisivanja objekata realnog ili
apstraknog sveta iz bilo kog problemskog domena uzimajući u obzir osobine objekata,
umesto nasilnog uvođenja normalizovanih dekompozicija u različitim tabelama
povezanim relacijama. Ovo čini XML dokumente i intuitivno razumljivijim i zbog toga
čini lakšim potreban dizajn aplikativnih struktura, kao i implementaciju sistema
baziranih na XML strukturama.
Iako se ne ističe kao glavna osobina, jedna od glavnih prednosti XML fajla jeste
čitljivost podataka od strane čoveka i na taj način se uvećavaju mogućnosti generalne
podrške i mogućnosti u razvoju elemenata odgovarajućeg sistema. Kao ilustracija
navedenog može da posluži sledeći primer:
reprezentacija podataka uz pomoć flat fajla je
GBPNABB20031204335423
a reprezentacija istih podataka u obliku XML dokumenta je
GBP
NABB
2003
12
04
33
54
23
gde je vidljiva razlika u prezentaciji podataka, kao i znatno bolja čitljivost i razumljivost
XML prezentacije podataka.
Proširivi jezik za označavanje - XML je globalan. Za bolje razumevanje pažnje koju je
XML privukao, korisno je podsetiti se drugog široko zastupljenog standarda koji danas
svi koriste: ASCII (American Standard Code for Information Interchange).
ASCII usredsređen na konkretan alfabet i sistem za pisanje ima za osnovnu
pretpostavku da dozvoljava različitim računarskim sistemima i operativnim sistemima
da razumeju razmenjene podatke. U okviru adaptacije u Unicode 1.0 i nastavak
evolucije, ASCII ideja je proširana da obuhvati sve jezike i sisteme za pisanje u svetu.
Savremeni računarski sistemi danas imaju sposobnost da generišu, čitaju i procesiraju
tekst dokumente bazirane na ASCII ili Unicode standardu. Proširivi jezik za
označavanje - XML prihvatio je takav pristup i otišao korak dalje, gradeći na Unicode
standardu univerzalan način da opiše strukturu podataka za razne namene.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 90
Dijagram je uprošćena i strukturirana vizuelna reprezentacija koncepta, ideje,
konstrukcije, relacije, statistike, anatomije i slično, korišćena u svim ljudskim
aktivnostima u smislu vizualizacije i uprošćavanja sadržaja. Dijagrami su, dakle,
ilustracije sa skupom simbola koji su specifični za posebnu namenu. Simboli koji se
pojavljuju na XML dijagramima su:
Element: Osnovni deo dijagrama je imenovani pravougaonik. Svaki od njih predstavlja
simbol zvani element. Svaki element može biti snabdeven dodatnim informacijama, kao
što je prikazano na Slici 13.
Slika 13. Grafički simbol za predstavljanje elementa
Ovo je mandatory i prost element tipa string. Gornji levi ugao ima osenčenje koje
ukazuje na podatke sadržane u ovom elementu, a type specificira da su podaci tipa
string. Ukoliko postoji enumeracija (tj. lista određenih vrednosti), tada će „enum“ ćelija
da sadrži listu.
Opcioni element: Na slici 14. prikazan je grafički simbol opcionog elementa. Opcioni
element se predstavlja isprekidanom linijom. Komentari u okviru elementa daju dodatne
detalje koji opisuju taj element.
Slika 14. Grafički simbol za predstavljanje opcionog elementa
Ponavljajući element: Element prikazan na slici 15. je element koji sadrži druge
elemente koji se „otkrivaju“ ukoliko se element „razvije“ uz pomoć znaka „+“, koji se
nalazi na desnoj stranici. Može da se pojavljuje najmanje jedanput, dok gornja granica
nije definisana, što se prikazuje simbolom sa desne strane – „beskonačno“.
Slika 15. Grafički simbol za predstavljanje elementa koji se ponavlja
Konektor sekvence: Konektor sekvence na slici 16. označava da je dateRange
sastavljen od maksimalno tri elementa. U slučaju prikazanom na slici svaki od ovih
elemenata je opcioni, ali u nekim drugim slučajevima jedan, više ili svi elementi mogu
biti obavezni.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 91
Slika 16. Grafički simbol za predstavljanje konektora sekvence
Konektor izbora: Konektor na slici 17. je indikator izbora. To znači da će kod
financialTerms biti uvek izabran tačno jedan od elemenata koji se nalaze sa desne
strane.
Slika 17. Grafički simbol za predstavljanje konektora izbora
Definicija korišćenja kompleksnog tipa: Dijagram na slici 18. ilustruje korišćenje
kompleksnog tipa za definisanje elementa. Prvo se definiše tip Quote. Kada se kreira
forwardPointsQuote, kao kompleksan, njegov tip se definiše kao Quote. Kao posledica
toga, element forwardPointsQuote automatski preuzima definiciju specificiranu za
Quote. Ovakve konstrukcije elemenata su česte kada se koriste isti elementi u mnogo
različitih uloga, da se isti tip ne bi na svim mestima više puta definisao .
Slika 18. Primer grafičkog predstavljanja kompleksnog tipa
Kompleksan tip: Na prvi pogled, slika 19. kompleksan tip je veoma sličan normalnom
elementu. Ono što taj elemenat čini moćnim jeste da on može da bude ponovno korišćen
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 92
za specifikaciju različitih elemenata koji imaju identične zahteve po pitanju atributa.
Ovo je učinjeno tako da se kompleksan tip ne vidi eksplicitno u rezultujućem XML-u.
Kada se izvrše promene kompleksnog tipa, svaki element koji je sa njim definisan biće
promenjen u skladu sa izvršenom izmenom.
Slika 19. Grafička predstava kompleksnog tipa koji se koristi u definicijama
TWIST poruka : Poruke neprofitne organizacije TWIST (Transaction Workflow
Innovation Standards Team) [213] jesu primer poruka koje su nastale na osnovu
ISO20022 poruka. Poruke se koriste u Retail domenu (poslovi pravnih i fizičkih lica u
procesima plaćanja) finansijskog tržišta. Ovim porukama TWIST organizacija daje
punu podršku procesima razvoja jedinstvene evropske platne zone, prihvatajući
standarde i metodologiju koju je propisao EPC i to sa proširenim skupom procesa
finansijske industrije koje ove poruke pokrivaju. Organizacija TWIST se među prvima
uključila u procese izgradnje jedinstvene evropske platne zone i na taj način sebi
obezbedila jednu od najznačajnijih uloga u tom domenu.
Slika 20. Struktura TWIST XML poruke
Koreni element TWIST poruke je element TwistMessage, slika 20. TwistMessage je
sačinjen od četiri elementa: messageHeader, conversationIdentification, conversation
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 93
element, i element party. Zaglavlje poruke (message header) uvek je prisutno i koristi
se za beleženje informacija o tome ko šalje poruku i kome. Sve relevantne informacije o
fizičkoj pojavi poruke sadržane su u zaglavlju. Element conversationIdentification može
da sadrži i neophodne informacije koje se odnose na ranije poruke. Treći element je
conversation. Sadrži elemente: tradeConversation, tradeStatementConversation,
settlementConversation, accountConversations i setupConversations. Na kraju
TwistMessage je skup elemenata o stranama konverzacije (party). Strane koje učestvuju
u razmeni podataka definišu se na kraju kroz potpunu potrebnu specifikaciju i u poruci
se na odgovarajućim mestima prosto referencira na taj njihov detaljan opis, umesto da
se ponavljaju na različitim mestima u dokumentu.
Slika 21. Struktura zaglavlja TWIST XML poruke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 94
Slika 22. Struktura elementa ConversationIdentification
Zaglavlje identifikuje poruku, verziju TWIST poruke koja je korišćena i ko je šalje,
prikazano na slici 21. Zaglavlje poruke nije formatizovano u smislu protokola za prenos
poruke mrežnom infrastrukturom. Element messageHeader je deo poruke bez obzira da
li se poruka prenosi na flopi disku, kao fajl na disku, prebačena ftp-om na neku lokaciju,
kopirana na CD ili isporučena na bilo koji način na drugu lokaciju. Drugi mehanizmi,
od kojih neki koriste i informacije iz zaglavlja poruke, služe za prenos poruke.
Element prikazan na slici 22. koristi se da bi se identifikovao predmet dopisa kome ova
poruka pripada. Inicijalna poruka dopisa sadrži novu identifikaciju dopisa, t.j. novi
conversationId.
Dakle, predmet dopisa je identifikovan sa conversationId. Svaka poruka u razmeni mora
da ima referencu koja pokazuje kom predmetu konverzacije poruka pripada, i to se čini
referenciranjem na conversationId.
Predmet dopisa je podeljen u grupe koje su prikazane na slici 23. Svaka poruka mora
biti formirana od tačno jednog elementa prikazanog na slici.
Slika 23. Struktura grupa poslova na koje poruka može da se odnosi
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 95
Svaki element iz conversation grupe sadrži informacije koje su potrebne za opisivanje
jedne vrste dopisa.
Poslednji element u poruci je definicija strana komunikacije. Definicija je neophodna za
svaku stranu koja je referencirana u telu poruke. Tipični primeri strana su Primalac i
Pošiljalac.
Internacionalne organizacije za standardizaciju poruka svoje specifikacije daju u obliku
XSD šema sa pratećom nestruktuiranom dokumentacijom koja daje više informacija za
razumevanje kompleksnosti. XSD šeme predstavljaju osnovu za kreiranje instanci
poruka. Branislav Lazarević i grupa autora u knjizi „Baze podataka“ [108] tvrde da je
takva specifikacija pogodna za izgradnju konceptualnog modela odgovarajućih baza
podataka. U svom magistarskom radu Nenad Aničić uvodi pojam „normalizovanog
XML dokumenta“. Preko normalizovanog XML dokumenta dolazi se do relacione baze
podataka, za koju pokazuje da ima zadovoljavajuće karakteristike.
Aleksis Smirnov u svom radu [194] pokazuje da XSD šema može biti osnova za
objektno-relaciono mapiranje i dokazuje da se može napraviti alat koji bi prevodio XSD
šemu u odgovarajući model baze podataka. Pošto u radu Smirnova polazišna XML
struktura nije normalizovana, ne dobija se baza podataka sa zadovoljavajućim
karakteristikama, ali primenom standardnih pravila može se doći do zadovoljavajuće
baze podataka.
4.1.2.4 Resource Description Framework šeme standard za metapodatke
Rad na Opšem okviru za opisivanje resursa (Resource Description Framework, RDF)
započeo je R. V. Guha dok je radio za Apple Computer i njegova prva verzija stekla je
status W3C Preporuke 1999. Nova verzija objavljena je 2004. [34]. kao skup srodnih
specifikacija. Strogo govoreći, RDF nije jezik, nego model podataka za opisivanje
mašinski čitljive semantike za „mrežne resurse”. Matematički govoreći, ovaj model
sastoji se od usmerenih grafikona sa čvorovima koji su povezani označenim lukovima.
Kao ključni napredak u odnosu na XML, RDF uvodi strukturu izjavne rečenice u svoje
podatke. Svaka RDF rečenica ima tri dela. Oni se označavaju ili kao „subjekt”,
„predikat” i „objekt”, ili kao „objekt”, „atribut” i „vrednost”. Subjekt/objekt, odnosno
objekt/vrednost, treba da budu shvaćeni kao da leže na čvorovima RDF-ovih usmerenih
grafikona, a predikati/atributi na lukovima. Semantički govoreći, u svakoj rečenici
subjekt/objekt treba da budu shvaćeni kao „stvar” o kojoj se u rečenici nešto kazuje,
predikat/atribut kao svojstvo koje je pripisano subjektu/objektu, a objekt/vrednost kao
vrednost (ili neki drugi kvalifikator) doznačena tom subjektu/objektu kao da mu
specifično pripada.
Budući da je RDF model podataka, a ne jezik, potrebno ga je iskazati u jeziku. Često se
prikazuje u XML-u, kakav je u službenoj specifikaciji W3C-a. Međutim, ta verzija je
nezgrapna u pogledu sintakse. Nešto jednostavnija verzija uključuje N3 i njegov još
jednostavniji podskup N-Triples. Drugi jezik, razvijen na Univerzitetu u Bristolu, jeste
TURTLE (Terse RDF Triple Language) koji neznatno proširuje N-Triples; predložene
su i mnoge druge verzije. Za uspešnu semantičku interoperabilnost, koja je cilj
semantičkog veba, aplikacije koje koriste RDF treba da izvedu primenu RDF-a na
nezavisan način. RDF trodelna struktura iskaza čini ovaj okvir vrlo prilagodljivim jer
proizvoljan broj tripleta može biti „naslagan” po bilo kojem redu. Nasuprot tome, u
XML-u, raspored u kojem se elementi pojavljuju u dokumentu značajanje : to podosta
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 96
otežava razmenu podataka. Strukture podataka koje se definišu u XML-u takođe su
dosta složene i sintaksno nezgrapne jer se mogu sastojati od proizvoljnih mešavina
stabala, grafikona i nizova znakova. RDF-ov triplet usmeren stil modeliranja podataka
nudi sredstva koja omogućuju grafičko strukturiranje podataka raznovrsnih
dokumenata; s druge strane, XML može iskazati grafikone samo unutar datog
dokumenta. Standardni RDF upitni jezik već postoji; svaki je jezik na tipičan način
povezan s određenom verzijom.
RDF treba da omogući da se preko Interneta programski obrađuju podaci na isti način
na koji se u konvencijalnom vebu obrađuje hipertekst. Time se omogućuje distribuirana
obrada podataka preko veba. Konvencionalni veb podržava korisnički pristup
dokumentima, „stranicama“ tekstova i slika, dok Semantic Web [224], zasnovan na
RDF-u, treba da podrži pristup bazama strukturiranih podataka. RDF omogućuje
softversko procesiranje veb-informacija.
4.2 Metod i paradigme za razvoj informacionih sistema
Globalizacija je unela mnoge izazove za kompanije. Male kompanije imaju veliku
prilagodljivost, ali skromna sredstva u domenu odgovora na date izazove. Velike
kompanije imaju drugačiji problem, širenje poslovanja često za posledicu ima problem
praćenje informacionih tokova. Čak i manje promene u toku informacije mogu dovesti
do gubitka nekih bitnih elemenata. Dugi niz godina kompanije su nalazile načina da se
nose sa ovim izazovima i mnoga rešenja su išla i smeru stvaranja virtualnih timova ljudi
koju nisu na istoj geografskoj lokaciji ali rade na istom zadatku. Ovakva rešenja su u
velikoj meri uslovljena razvojem Interneta i informatičkim mogućnostima same
kompanije. Na tržištu postoji mnogo različitih softverskih i hardverskih rešenja, ali ova
rešenja su mahom skupa i potrebno je izuzetno veliko znanje za njihovo korišćenje.
Neke kompanije jednostavno nemaju ova sredstva i samim tim su hendikepirane u
nastojanju da se uključe u proces globalizacije. Po jednoj definiciji globalizacija je
proces kroz koje se regionalne i nacionalne ekonomije integrišu kroz međunarodne
sisteme trgovine, transporta, bankarstva i sl. Pomoću transfera tehnologije, tehnologija
se širi u svetu. Najbolji primer ovoga jeste Internet, koji je prisutan skoro u svakoj
zemlji. Danas postoji veliki promet robe i dobara, tako da se u jednoj prosečnoj zemlji
može naći roba koja nije prirodna za to podneblje i to po niskoj ceni. Organizacija
multinacionalnih korporacija postaje posebno polje interesovanja za mnoge nauke,
takođe je u poslednjih nekoliko decenije interesovanje za razvoj malog i srednjeg
biznisa pojačano. Razlog je očigledan, male kompanije imaju izuzetno veliku agilnost u
odnosu na velike kompanije, a velike kompanije imaju potrebu za nekim promenama
paradigmi sa ciljem postizanja veće fleksibilnosti. Upravo je ovo bio veliki podstrek da
se počne razmišljati u smeru većeg stepena iskorišćena informacionih sistema jer se uz
dobru informaciju mogu zaraditi ili uštedeti velika materijalna sredstva.
Virtuelni timovi. Neke promene paradigme poslovanja su popularizacija i razvoj
timskog rada, timski rad je po svojoj prilici najbolje rešenje za postizanje rezultata u
relativno kratkom roku. Međutim, u domenu internacionalnog poslovanja timski rad ima
veliku manu, a to je da se od članova zahteva da budu na jednoj geografskoj lokaciji. Za
mnoge internacionalne korporacije i manje kompanije koje su uključene u proces
međunarodnog poslovanja ovo nije prihvatljivo rešenje [230].
Mali broj kompanija zaista uspostavlja idealne strukture kompletno bazirane na timu, u
ovom scenariju. U praksi, većina filijala se rukovodi uz pomoć tradicionalnih,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 97
hijerarhijskih sistema i akcija zemalja domaćina, a ne sistema timova sa delegiranom
moći. Bez obzira na to, menadžeri zemlje domaćina i njihove filijale zauzimaju važne
pozicije unutar šire mreže proizvodnih sistema kompanije. Zato je koordinacija
različitih interesa osnovna stvar i ovi menadžeri i njihove jedinice treba da reaguju
jedna na drugu na način sličan timskom radu kada se radi o kolaborativnim mrežama
međusobnih odnosa u internacionalnim aktivnostima. Broj Internet korisnika je veći od
dve milijarde ljudi, što znači da postoji jako velika osnova za uvođenje Interneta u sferu
svakodnevnog poslovanja. Ljudi su već navikli na Internet i tehnologije koje ovaj servis
nudi, a sa druge strane, stalni razvoj tehnologije poboljšava kvalitet iste i čini je
sigurnijom za korišćenje. Kamen temeljac virtualnog tima jeste Internet i mnoge
tehnologije koje su u bliskoj vezi sa ovim fenomenom. Rad van kancelarije postaje
svakodnevica mnogim ljudima, mogućnost da se dobiju ažurne informacije sa mesta
njihovog nastanka uz pravilnu interpretaciju eksperta diže poslovanje na jedan sasvim
novi nivo. U prethodnom periodu skupljanje i obrada podataka bili su skupi procesi koji
su uključivali posredovanje operatera za unos podataka i stručnjaka za automatsku
obradu podataka. Danas ovo više nije slučaj, podatak može ući u informacioni sistem na
mestu na kojem nastaje bez mogućnosti greške ili sa malom mogućnošću. Uz eksperta
koji se nalazi na licu mesta dešavanja nekog procesa, moguće je dobiti, pored čvrstih
podataka, i ekspertizu koja je mnogo kvalitetnija jer nema entropije podataka.
Paradigma otvorenog koda. Primer ove tvrdnje su vlade Nemačke i Velike Britanije.
Ove zemlje su usled pritisaka da smanje troškove prešle na softver otvorenog koda. To
konkretno znači da su ove vlade odlučile ne samo da smanje troškove, već i da aktivno
učestvuju u razvoju IT rešenja [196]. Naravno, jako je teško porediti javni i privatni
sektor, ali princip je isti, svi akteri zahtevaju manje troškove, veću sigurnost IT
proizvoda i sl. U ovom primeru nemamo direktnu vezu sa fenomenom „cloud
computing“-a, ali sistem otvorenog koda se isto može smatrati novom paradigmom koja
je u direktnoj suprotnosti sa važećom paradigmama komercijalnog softvera. Otvoreni
kod će se najviše vezivati za individualne korisnike i male kompanije, sa druge strane
sve kompanije koje žele da postignu konkurentsku prednost preferiraće softverska
rešenja iz domena „cloud computing“-a. Veliki komercijalni proizvođači softvera već
danas nude neka svoja rešenja iz domena „cloud computing“-a, a ne napuštajući sistem
razvoja „klasičnog“ softvera. Tako da je moguće da će se i dalje nuditi softver kao do
sada, sa tom razlikom što će se unapređenja i revizije ređe pojavljivati.
Što se tiče virtualnih timova, „cloud computing“ će verovatno imati sve veći uticaj na
dalji razvoj ovog vida timskog rada. Međutim, biće potrebno mnogo vremena kako bi se
virtualni timovi u potpunosti afirmisali. Fleksibilnost je postala nova poslovna
paradigma, a „cloud computing“ i virtualni timovi imaju tu moć da izađu u susret novim
izazovima tržišta. U prošlosti „mainframe“ arhitektura je jednostavno napuštena zbog
tehničkih ograničenja i inferiornosti u odnosu na sisteme koji su sami obrađivali
podatke. Samim tim možemo zaključiti da nam u bliskoj budućnosti predstoji oštra igra
konkurenata, što je za korisnike dobro zbog veće palete softverskih rešenja.
Kolaboracija kao nova poslovna paradigma. Kolaboracija je rekurzivan proces u
kome više ljudi ili organizacija sarađuju da bi ostvarili zajednički cilj [186]. Po svojoj
prirodi kolaboracija je kreativan proces, koji se realizuje deljenjem znanja, učenjem i
izgradnjom konsenzusa. Kolaboracija ne zahteva rukovođenje, već se bolji rezultati
postižu decentralizacijom i jednakošću. Pod kolaboracijom se podrazumeva i bogatstvo
sadržaja sa kojima objekti (inteligentni uređaji, ljudi i kompanije) mogu zajedno stvarati
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 98
nove vrednosti, korišćenjem Internet tehnologija [93].
Tradicionalna transakciona teorija poslovanja podrazumeva obaveznu razmenu dobara
ili servisa između učesnika. U tradicionalnoj komandnoj i kontrolnoj poslovnoj
hijerarhiji, gde su procesi upravljali ljudima, posao je bio podeljen na manje delove za
čiju realizaciju su bili određivani pojedinci ili grupe zaposlenih. Sada, u vreme digitalne
ekonomije, radnici znanja (knowledge workers) upravljaju poslovnim procesima,
konstantnom manipulacijom podataka i razmenom informacija direktno sa ostalim
radnicima, nezavisno od tradicionalne menadžerske strukture. To stvara konstantni nivo
pseudotransakcija između zaposlenih, sa partnerima, potrošačima, snabdevačima,
konkurencijom i određenim subjektima okruženja, pri čemu ne postoji razmena ni roba
ni servisa. To što nema razmene roba ili servisa, ne umanjuje značaj ovih interakcija za
donošenje validnih odluka ili upravljanje poslovnim procesima. Interakcija među
ljudima, da bi se postigao zajednički cilj, bez razmene roba ili usluga, može se definisati
kao kolaboracija. U modernim organizacijama kolaboracija se podstiče, upravlja i prati
informacionim tehnologijama. Danas, zahvaljujući tehnologijama grupisanim oko
semantičkog veba 2.0, može se postići visok nivo efikasne kolaboracije, unutar
kompanije i sa svim ostalim partnerima. Analizom tipova kolaboracije uočava se pet
kaskadnih nivoa kolaboracije, koji su prikazani na slici 24.
Slika 24. Tipovi kolaboracije
SOA I WEB 2.0 – kao paradigma e – poslovanja. Ideja kolaboracije donosi suštinske
i globalne promene načina poslovanja [45]. Potrebe savremenog poslovanja čine da
zahtevi za kolaboracijom prevazilaze mogućnosti zatvorenih informacionih sistema,
koji su dizajnirani i realizovani u vreme kada su tehnološka rešenja nametala parcijalno
tretiranje poslovnih procesa. Upravljanje poslovnim procesima (BPM - Business
Process Management) jeste metodologija upravljanja resursima kompanije i definisanje
interakcija između resursa, u cilju generisanja servisa ili proizvoda prema potrebama
klijenata. Upravljanje poslovnim procesima je sveobuhvatan i celovit pristup
unapređivanju poslovanja i podešavanja organizacije zahtevima tržišta. Upravljanje
poslovnim procesima predstavlja koherentan pristup poslovanju tako što obezbeđuje da
postoji samo jedan poslovni proces za zadovoljavanje određene poslovne potrebe i samo
jedan servis za podršku tog poslovnog procesa. Taj servis se može izvršavati u
mrežnom okruženju, tj. u svim organizacionim delovima kompanije. U skladu sa tom
servisno orijentisanom paradigmom, upravljanje poslovnim procesima može se
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 99
posmatrati kao jedna kompozitna aplikacija, koja orkestrira poslovnim procesima kao
servisima i na taj način integriše i automatizuje poslovanje. Bazirana na standardima i
principima najbolje prakse, servisno orijentisana paradigma omogućava sveobuhvatno,
integrativno unapređivanje upravljanja poslovnim procesima. Bez primene servisno
orijentisane paradigme moguće je postići samo parcijalna organizaciona ili tehnološka
unapređenja, ali infrastruktura kompanije i dalje sporo reaguje na promene, nije
fleksibilna i skupa je. Kamen temeljac uspešne primene servisno orijentisane
paradigme, svakako, predstavlja poznavanje poslovne problematike u određenom
domenu. Pored tih bazičnih znanja, neophodno je i poznavanje specifičnih znanja iz
informacionih tehnologija, pre svega sa aspekta primene servisno orijentisane
arhitekture [124].
Projektovanje sistema za upravljanje poslovnim procesima jedan je iterativan postupak
u kome se poslovni procesi, njihove karakteristike i efekti prate tokom celog „života“
procesa, u svim organizacionim celinama kompanije. Potpuno razumevanje poslovne
strategije kompanije kao i razumevanje metoda i resursa iz IT domena, preduslovi su
uspešnog projektovanja i realizacije sistema za upravljanje poslovnim procesima. Iako
su SOA i Web 2.0 nastali u IT domenu, oni danas predstavljaju paradigmu za korišćenje
distribuiranih mogućnosti kompanije radi postizanja poslovnih ciljeva, na
konzistentan način, uz mogućnosti merenja postignutih efekata. Polazeći od
dekompozicije poslovanja, prikazano radno okruženje omogućava orkestraciju novih i
postojećih servisa u poslovne procese. Servisno orijentisano radno okruženje koristi se
kao platforma za razvoj novih, dinamičkih poslovnih aplikacija, ali istovremeno
omogućava inkrementalno unapređenje „nasleđenih“ aplikacija, čime se značajno
čuvaju prethodne investicije. Integracija servisno orijentisane arhitekture i semantičkog
veba 2.0 sa poslovnim procesima i metodama poslovne inteligencije omogućava
efikasno i fleksibilno reagovanje na promene tržišnih uslova, zahteve potrošača i
izazove konkurencije. Konvergencijom SOA i veba 2.0 stvorena je fleksibilna i
kolaborativna softverska arhitektura, novi pristup, koji omogućava masovno učešće svih
zainteresovanih u procesu unapređivanja i usavršavanja poslovanja [124].
Sva moderna softverska rešenja podrazumevaju primenu servisno orijentisane
arhitekture i semantičkog veba 2.0. Njihova snažna povratna veza na poslovanje
kompanija čini ih važnim gradivnim elementima referentnog modela elektronskog
poslovanja. Fleksibilnost servisno orijentisane arhitekture i kolaborativnost semantičkog
veba 2.0 predstavljaju novo radno okruženje, koje omogućava efikasno korišćenje
najnovijih tehnologija, kako informatičko-komunikacionih, tako i tehnologija iz domena
poslovanja. Ova paradigma omogućava fleksibilno usklađivanje tehnoloških i poslovno-
upravljačkih funkcija kompanija, i čini kompanije otvorenim za interaktivnu
komunikaciju, ne samo sa kupcima i partnerima, već sa svima koji imaju pristup
Internetu. Informacioni sistemi realizovani na principima servisno orijentisane
arhitekture i semantičkog veba 2.0 omogućavaju korišćenje potencijala najnovijih
tehnologija u cilju realizacije ekonomskih i poslovnih benefita [124].
4.2.1 Strukturalne metodologije
Razvoj informacionog sistema prema principima životnog ciklusa podrazumeva takav
proces koji teče kroz niz sukcesivno procesnih faza, gde završetkom jedne faze
započinje naredna i gde između susednih faza postoji snažna iterativna interakcija. Ovo
je proces kojim sistem analitičari, softver inženjeri i programeri izgrađuju informacioni
sistem. To je, takođe, paradigma i sredstvo upravljanja ovako složenim, dugotrajnim i
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 100
skupim projektima. Prilazi i metodologije razvoja informacionih sistema često se
mešaju sa životnim ciklusom. Neretko se postavlja pitanje: ima li razlike? Neki eksperti
tvrde da su prilazi i metodologije razvoja informacionih sistema supstitut za životni
ciklus. Drugi misle da su prilazi i razvojne metodologije, više-manje namenjeni da
upotpune, metodološki razjasne i omoguće efikasniji razvoj informacionog sistema i
smatra se da principi i filozofija životnog ciklusa informacionog sistema nisu iščezli, da
su još uvek veoma aktuelni jer informacioni sistemi nastaju, razvijaju se, sazrevaju, ali i
nestaju. Oni se, dakle, u okviru ovakvog stanovišta mogu razvijati različitim prilazima i
metodologijama. Prilazi i metodologije, o kojima će u ovom radu biti reči, strukturni su,
objektni i agilni [228].
Jedna od najvažnijih metodologija razvoja informacionog sistema je strukturna
metodologija životnog ciklusa, koja je usredsređena na strukturni prilaz. Osnova ove
metodologije je strukturna sistem analiza [5], dizajn, implementacija i strukturne
metode, tehnike, CASE alati. Najpoznatije u literaturi i u praksi najčešće korišćene
strukturne metodologije su:
• SADT (Structured Analysis and Design Techniques) Whitten, Bentley, (1998),
• SSADM (Structured Analysis and Design Method) Whitten, J., Bentley, L.D.
(1998),
• ISAC (Information System Work and Analysis of Change) Lundberg, (1981),
• SSA (Structured Systems Analysis), Gane, C, Sarson, T. (1979),
• IE (Information Engineering) Martin, J.(1990),
• RAD (Rapid Application Development) Gane, C. (1990).
4.2.1.1 Rapid Application Development (RAD)
RAD ili Metodologiji brzog razvoja informacionog sistema ima sledeće korake [41]:
• uspostavljanje upravljačke strukture projekta;
• identifikovanje, analiza i specifikacija informatičkih zahteva i odgovora na
informacione zahteve;
• logička analiza i modelovanje sistema;
• logičko modelovanje podataka;
• projektovanje relacionih baza podataka;
• transformacija logičkog modela u fizički;
• specifikacija logičkih procedura obrade podataka;
• implementacija sistema.
Uspostavljanje upravljačke strukture. Uspostavljanje upravljačke strukture projekta
nužno je zbog problema sa multiorganizacionim sistemima. Projekti razvoja novog ili
modifikacije postojećeg sistema skoro uvek izazivaju radikalne promene u više
organizacionih jedinica i mogu biti uzrok mnogih konflikata i otpora. Većina ljudi u
organizaciji ne voli promene, čak i ako su one veoma korisne za organizaciju kao
celinu, odeljenja, radne grupe i pojedince. Izvori konflikata i otpori mogu biti različiti.
Najčešće se, međutim, tiču problema opravdanosti ulaganja i preduzimanja ogromnih
napora da se novi sistem razvije jer menadžeri su skloni tvrdnji da takva ulaganja i
napor nisu srazmerni korisnosti koju sistem donosi, jedni se boje da će novi sistem
smanjiti njihovu moć, a drugi da će njihov posao postati teži, dosadniji, pa čak da će i
nestati. Za savladavanje otpora i prevazilaženje konflikata zahteva se značajno vreme,
pa je to često i razlog zašto razvoj informacionog sistema dugo traje. Ljudi koji čine tim
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 101
za razvoj informacionog sistema, stručnjaci za informatičke tehnologije, imaju pred
sobom dve ozbiljne prepreke u efikasnom suzbijanju otpora i rešavanju konflikata. Prva
je ta što oni ne poznaju dovoljno oblasti u kojima se otpori i konflikti pojavljuju, imaju
pomanjkanje kompetencija. Druga, nemaju adekvatna ovlašćenja i autoritet u odnosu na
ove ljude. Iz ovih razloga je neophodno na vreme spoznati da ključ uspeha brzog i
efikasnog razvoja informacionog sistema leži u načinu upravljanja celokupnim
projektom. Osoba koja će stati na čelo projekta mora biti iz samog vrha menadžmenta
organizacije, koja ima odgovornost za uspeh projekta i autoritet nad delokrugom
projekta, politikama koje će podržavati razvoj projekta i omogućiti organizacione
promene koji će razvoj i implementacija projekta implicirati. Menadžer koji dobija
ovakvu ulogu poznat je kao „izvršni sponzor“, i on uspostavlja odgovarajuću
upravljačku strukturu projekta.
Specifikacija zahteva. Identifikovanje, analiza i specifikacija informacionih zahteva i
odgovora na informacione zahteve, analiza i definisanje informacionih zahteva drugi je
deo jedinstvene metodologije brzog razvoja informacionog sistema. Metod koji se
koristi u identifikaciji zahteva je metod intervjua. Za razliku od tradicionalnog pristupa,
koji je akceptirao seriju nezavisnih, pojedinačnih intervjua, ovde je reč o primeni
tehnike grupnih intervjua, gde jedan ili više analitičara intervjuiše „komitet“ za
upravljanje projektom i reprezente korisnika u isto vreme. Sprovođenje niza i velikog
broja pojedinačnih intervjua, od strane većeg broja analitičara, prouzrokuje više teškoća,
među kojima su najznačajnije:
• proces intervjuisanja dugo traje, izostaje komunikacija između intervjuisanih i
troškovi su veliki;
• stavovi intervjuisanih u vezi sa istim problemima mogu biti različiti i veoma je
teško pomiriti izražene razlike;
• između različitih organizacionih jedinica često se javljaju različiti ciljevi i
zahtevi koji su kolitični, uvek za posledicu imaju konflikte i otpore koje je
veoma teško rešiti odnosno ukloniti.
Metod grupnog intervjua veoma efikasno rešava ove vrste problema. Grupni intervjui
imaju teorijsko uporište u teoriji grupne dinamike. Suština pristupa grupne dinamike se
može iskazati u sledeće četiri paradigme:
• Sastanak je najproduktivniji ako je vođen od moderatora, koji je „prirodni
poslužitelj“ grupe, koji vrednuje i distribuira ideje. Njegova je odgovornost da
pomogne grupi, da njihovu energiju usredsredi na zadatak sa predlaganjem
metoda i procedura, zaštitom članova grupe od ataka i stvaranjem šanse svakom
da u radu učestvuje.
• Najproduktivnije grupno odlučivanje je konsenzus, u kojem se svako oseća
„pobednikom“, ili ako nije dobio tačno ono što je želeo, prihvata odluku bez
kompromisa ili nekog „debelog“ ubeđivanja.
• Grupna sesija je najproduktivnija ako se pridržava plana, koji je grupa prihvatila
konsenzusom;
• Grupna sesija je najproduktivnija ako se rezultati diskusije prikazuju na zidu,
kako se oni pojavljuju, gde ih svako može videti. Displej se često označava kao
„grupna memorija“, a član koji kreira displej igra ulogu „zapisivača“.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 102
Grupni intervju podrazumeva zajednički sastanak reprezentanta korisnika i
projektantskog tima u istoj sobi i u isto vreme, koji kontinuirano drže radnu sesiju
(workshoop) koja traje najmanje jedan, obično tri, a ponekad i pet dana. Uspeh ove
tehnike identifikacije informacionih zahteva značajno je zavisan od načina vođenja
sesije grupnog intervjua, koja treba da bude vođena, prema indikacijama uspešnosti iz
dosadašnje prakse, osobom koja nije opterećena parcijalnim interesima konačnih izlaza
projekta, neko ko ima isključiv cilj da što pre i na što efikasniji način dođe do
konsenzusa o koherentnom zajedničkom skupu zahteva. Glavna korist upotrebe ovog
metoda je veoma kratko vreme izvršenja faza identifikacije zahteva. Ako se konflikti
pojave oni mogu biti otvoreno i neposredno raspravljani i razrešeni veoma brzo.
Posebno značajna korist se ispoljava u mogućnosti da korisnici participiraju u
donošenju odluke o delokrugu i prirodi sistema koji se razvija za njih, i koji svoj stav
izražavaju sledećom tvrdnjom: „Ovo je naš sistem, a informatičko osoblje nam pomaže
da ga izgradimo“ Gane, C. (1990). Svaki projekat razvoja informacionog sistema,
tokom intervjua uključuje nekoliko grupa radnih sesija. To su po Gane, C. (1990):
strategijska sesija – sa zadatkom determinisanja delokruga projekta, ciljeva, resursa;
podaci/procesi sesija – sa zadatkom izgradnje ili pročišćavanja dijagrama toka podataka
i modela podataka i definisanja logike poslovne politike; ekrani/izveštaji sesija – sa
zadatkom da se definiše interaktivni dijalog i izgledi izveštaja. Učesnici intervjua su
predstavnici korisnika.
Analiza i modeliranje. Ovim korakom metodologije modeluju se procesi sistema.
Osnovni ciljevi koji se postižu putem upotrebe tehnike dijagrama toka podataka su:
• definisanje granice sistema i poslovnog domena koji isti pokriva;
• veoma jednostavna i za korisnika krajnje prihvatljiva prezentacija sistema,
potpuno razumljiva za poslovni svet koji nije familijaran sa informacionim
tehnologijama;
• prikaz memorisanih podataka (datoteka, evidencija, kartoteka, arhiva) u sistemu
i procesa koji te podatke transformišu, kao i njihov međusobni odnos (relacije).
Logičko modelovanje podataka. Logičko modelovanje sistema u najužem smislu
podrazumeva izradu DTP za određeno domensko područje i takozvani First-Cut („prvi
presek“) modela podataka [31]. Bilo bi metodološki konzistentnije u pojam logičke
analize i modelovanja sistema uključiti i entitet- odnos analizu (E-O-M) podataka i
specifikaciju logičkih jedinica procedura obrade. Prema tome, logičku analizu i
modelovanje sistema možemo shvatiti kao proces od dva koraka.
Relaciona analiza podataka se preduzima sa ciljem da se projektuje logička struktura
baze obeležja relacionog modela baze podataka, odnosno da se dobije struktura n
međusobno povezanih dvodimenzionalnih tabela koje će sačinjavati jednu bazu
podataka. Metod kojim se takva struktura dobija poznat je pod nazivom metod
normalizacije. Preimplementaciono „sređivanje“ modela podataka odnosi se na njegovo
prilagođavanje zahtevima kao što su prihvatljivo vreme pristupa i pretraživanja,
prihvatljiv memorijski prostor neophodan za smeštaj baze podataka. Spajanje relacija
može biti uputno i korisno realizovano u cilju da se uštedi vreme i unapredi integralnost
celine. Dizajner baze podataka pre nego što nacrta E-R-M, obaviće konsultacije po ovim
pitanjima i zajedno sa administratorom baze podataka izvršiti konsolidaciju modela.
Specifikacija procesiranja. U specifikacije logičkih procedura obrade podataka
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 103
detaljno se specificiraju detalji definisanih jedinica logičkih procedura. Specifikacija
obavezno sadrži sledeće elemente, Gane, C. (1990):
• Isečak iz sistemskog DTP, koji pokazuje gde se ova proceduralna jedinica nalazi
u ostatku sistema;
• Detalje o tabelama (relacijama) kojima se pristupa ovom jedinicom procedure;
• Izgled ekrana ili izveštaja koji su uključeni u jedinicu procedure;
• Napomene o logici i sadržaju procedure koja treba da bude implementirana,
pisane u strukturnom engleskom ili nekoj drugoj nedvosmislenoj formi.
Pošto su sve specifikacije jedinica procedure urađene, programeri mogu veoma brzo
izgraditi prototip ili izvesti direktnu celovitu implementaciju u nekom programskom
jeziku, odnosno alatu.
Implementacija. Implementacija sistema i razvoj softverskog dela sistema poslednji je
korak RAD metodologije [41]. Neproceduralnim alatima i softverom za upravljanje
bazama podataka kao što su ORACLE, INFORMIX, DB-2, PROGRES, FOCUS,
aplikacije se razvijaju veoma brzo zahvaljujući, pre svega, tome što oni obezbeđuju lako
ili brzo definisanje ekrana i editovanje podataka koji se unose putem ekrana, računanje i
manipulaciju nizovima, pretraživanje i ažuriranje baza podataka (SQL standardi),
generisanje planiranih izveštaja i ekranskih displeja, sistemsko generisanje aplikacija.
Većina ovih jezika su „klasterizovani subjezici“, jer obezbeđuju subjezike za različite
funkcije, na primer: subjezik za definisanje ekrana, drugi za pretraživanje baza podataka
itd.
4.2.2 Objektne metodologije
Najpoznatije u literaturi i u praksi najčešće korišćene objektne metodologije su:
• OOAD (Object Oriented Analysis and Design) Martin, J., Odell, J.J. (1992),
• OOADA (Object Oriented Analysis and Design) Booch, G. (1994),
• OMT (Object Modeling Technique) Rumbaugh, J. (1991)
• OOA/OOD (Object Oriented Analysis/Object Oriented Design) Yourdon, E.
(1995)
• RUP (Rational Unified Process) Jacobson, I. et.al (1999)
4.2.2.1 Rational Unified Process (RUP)
Rational Unified Process (u nastavku RUP) predstavlja objektno orijentisani proces za
izradu softvera [107]. Ovaj proces je zasnovan na pristupu baziranom na disciplinama, u
okviru kojih se vrši raspodela poslova i odgovornosti na članove razvojnog tima i ostale
učesnike u procesu razvoja softvera. Osnovna namena RUP-a jeste proizvodnja
visokokvalitetnog softvera, kao krajnjeg rezultata projekta, koji zadovoljava potrebe
korisnika, a u okviru planiranog budžeta i vremena. RUP je framework (radni okvir)
koji je moguće prilagođavati potrebama organizacije koja ga usvaja. On sadrži skup
dobro definisanih preporuka i uputstava za uspešan razvoj softverskog proizvoda.
Upravo radi toga, kod navođenja definicije RUP-a izbegava se izraz metodologija, koji
predstavlja znatno čvršći set pravila od navedenog izraza framework. Međutim,
pojedinačnim podešavanjem RUP-a organizacija može da kreira svoj metodološki okvir,
a u okviru njega i čvrsta pravila izgrađena na osnovu datih preporuka i uputstava.
U izgradnji informacionog sistema RUP preporučuje korišćenje raznih metoda i tehnika,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 104
ali su svakako najdominantnije tehnike modelovanja korišćenjem Unified Modeling
Language-a (u nastavku UML), tj. jedinstvenog jezika za modelovanje. Za RUP se čak
može reći da predstavlja uputstvo za korišćenje UML-a. RUP je inicijalno zamišljen za
razvoj velikih projekata, ali je svoju primenu našao i u srednjim i malim softverskim
projektima. Softverski timovi, naročito veliki, znatno unapređuju svoju produktivnost
korišćenjem RUP-a. RUP omogućuje svakom članu razvojnog tima lak uvid u bazu
znanja, zasnovanu na uputstvima, obrascima i uputstvima za korišćenje alata, što
predstavlja podršku u svim kritičnim razvojnim aktivnostima. To doprinosi da svi
članovi razvojnog tima, bez obzira na aktivnosti koje obavljaju, koriste zajedničku
metodologiju, jezik i pogled na to kako treba razvijati softverski proizvod. Principi na
kojima je zasnovan RUP omogućuju razvoj kvalitetnih softverskih proizvoda i
postavljanje metodoloških koraka kojima će se realizovati kompletne preporuke i
uputstva zasnovani na dolenavedenim principima.
Iterativan razvoj. Klasični proces razvoja softvera zasniva se na modelu vodopada,
koji je ranije opisan. Alternativa modelu vodopada jeste iterativno-inkrementalni model
razvoja softvera. Korišćenjem ovoga modela dolazi se do relativno brze realizacije
početne verzije softvera koja se razvija dodatnim iteracijama. Takođe, integrisanje i
testiranje softvera obavlja se češće, te se na taj način postiže smanjenje rizika. Što je
razlika između trenutka otkrivanja greške i trenutka nastanka greške veća, to je njeno
otkrivanje i otklanjanje teže i skuplje. Iterativni proces se sastoji iz više sekvencijalnih
procesa zasnovanih na modelu vodopada. Time je vremenska dimenzija izmeštena u
odnosu na sadržajnu dimenziju, pa je vreme između potencijalnog nastanka i otkrivanja
grešaka značajno skraćeno. Kao prednosti iterativnog razvoja mogu se navesti sledeće:
• Greške učinjene u razvoju ranije se identifikuju i moguće je uspešnije reagovati;
• Omogućava se korisnička povratna sprega;
• Razvojni tim je primoran da se fokusira na ona pitanja koja su najvažnija za
projekat;
• Kontinuirano i iterativno testiranje pruža objektivan uvid u status razvoja;
• Nepravilnosti tokom analize zahteva, dizajna i implementacije otkrivaju se
ranije;
• Tim za testiranje je uključen tokom celog životnog ciklusa projekta;
• Tim usavršava naučene lekcije i tako može neprekidno da unapređuje proces
razvoja.
Upravljanje zahtevima. Prateći rezultate Standish grupe dolazi se do spoznaje, da je u
37% slučajeva razlog za neuspeh projekata vezan za informacione zahteve. Nedostatak
korisničkih zahteva predstavlja razlog neuspeha projekata u 13% slučajeva, nepotpuni
zahtevi i specifikacije u 12% slučajeva, a promena zahteva i specifikacija takođe u 12%
slučajeva. Dodajući navedenim podacima činjenicu da su troškovi otklanjanja grešaka
nastalih u oblasti zahteva izuzetno visoki, iako ih iterativan pristup značajno umanjuje,
nameće se zaključak da se zahtevima ne posvećuje dovoljna pažnja u procesu razvoja
informacionih sistema. Informacioni zahtevi predstavljaju inpute za dizajn sistema,
testiranje sistema, kao i izradu korisničke dokumentacije. Greške u fazi analize zahteva
pogubne su po uspeh projekta razvoja. Da bi se gorenavedeni procenti smanjili,
potrebno je posvetiti značajnu pažnju pronalaženju, organizovanju, dokumentovanju i
upravljanju zahtevima. RUP upravo to i radi kroz disciplinu zahteva čiji je cilj da opiše
šta sistem treba da radi. Taj opis treba da bude prihvaćen, kako od strane korisnika, tako
i od strane razvojnih inženjera.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 105
Upotreba arhitekture zasnovane na komponentama. Vizuelizacija, specifikacija,
konstrukcija i dokumentovanje softverskog sistema zahteva da sistem bude sagledan iz
brojnih perspektiva. Svaka zainteresovana strana - stejkholder (analitičari, integratori
sistema, testeri, projektni menadžeri, dizajneri) donosi različitu sliku projekta, i svaki od
njih gleda sistem na različite načine, mnogo puta tokom života projekta. Arhitektura
sistema je možda najvažnija podela koja se može koristiti da bi se upravljalo ovim
različitim gledištima i na taj način kontrolisao iterativni i inkrementalni razvoj sistema
tokom njegovog životnog ciklusa [106].
Arhitektura je prevashodno bitna za razvojni tim koji realizuje projekat, ali indirektno
utiče i na zadovoljstvo krajnjeg korisnika. Arhitektura sistema obuhvata grupu
značajnih odluka o:
• Organizaciji softverskog sistema;
• Izboru gradivnih elemenata i njihovih interfejsa, od kojih je sistem sastavljen;
• Ponašanju gradivnih elemenata, određenom upravo njihovom saradnjom;
• Kompoziciji strukturalnih i bihevioralnih elemenata u veće rastuće podsisteme;
• Arhitektonskom stilu, koji objedinjuje gorenavedene odluke u jednu celinu.
Razvoj baziran na komponentama (CBD - Component-Based Development) je
značajan pristup softverskoj arhitekturi jer omogućava ponovnu upotrebu, kao i
specijalizaciju komponenata. Pored sopstvene izgradnje komponenata za ponovnu
upotrebu moguća je upotreba komponenata i iz velikog broja komercijalno dostupnih
izvora (Microsoft Component Object Model - COM i Microsoft Foundation Classes -
MFC, Common Object Request Broker Architecture - CORBA, Enterprise JavaBeans -
EJB samo su neke od široko podržanih platformi na kojima je arhitektura zasnovana na
komponentama ostvariva). Kombinujući iterativan razvoj sa arhitekturom zasnovanom
na komponentama, svaki korak proizvodi izvršnu arhitekturu sistema, koja je merljiva,
pogodna za testiranje i vrednovanje u odnosu na zahteve sistema. Na ovaj način se
otvara mogućnost za konstantno napadanje ključnih rizika projekta.
Vizuelno modelovanje. Model predstavlja pojednostavljenu sliku realnosti, koja
kompletno opisuje sistem iz pojedinačnih perspektiva. U softverskom inženjeringu
modeli se izgrađuju da bi se bolje razumeo sistem koji se modeluje. Kod izrade velikih
sistema modelovanje pomaže njihovom razumevanju u potpunosti. Slobodno se može
konstatovati da bi bez modelovanja automatizacija takvih sistema bila nemoguća.
Činjenica da jedna slika govori više nego hiljadu reči poznata je odavno. Međutim, ono
što je nedostajalo jeste standardizacija. UML kao jedinstveni jezik za modelovanje
prihvaćen je od strane vodećih svetskih IT kompanija i nametnut je kao standard u
softverskoj industriji. On služi za vizualizaciju, specifikaciju, konstrukciju i
dokumentaciju sistema koji se izgrađuje. UML je omogućio svim članovima razvojnog
tima da razgovaraju istim jezikom. Standardizacija je dovela do toga da se UML
izučava u školama i fakultetima širom sveta, pa je time zamenjivost bilo kojeg člana
razvojnog tima značajno olakšana. RUP i UML predstavljaju nerazdvojivu celinu.
Vizuelno modelovanje podiže kvalitet procesa razvoja softverskog proizvoda, što je
lako uočljivo preko sledećih karakteristika:
• Use Case-ovi i scenarija nedvosmisleno definišu ponašanje sistema;
• dizajn je jasan i nedvosmislen;
• nemodularne i nefleksibilne arhitekture su lako uočljive na nivou modela;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 106
• različite perspektive i različiti nivoi detaljnosti mogu se koristiti u različiti
situacijama;
• otklanjanje nekonzistentnosti na nivou dizajna značajno olakšava
implementaciju;
• Use Case model i dizajn model stvaraju jasne inpute za testiranje;
• korišćenje UML-a nameće standardizaciju u softverskoj industriji.
Kontinuirana potvrda kvaliteta softvera. Softverski problemi su od 100 do 1000 puta
skuplji kada se pronalaze i otklanjaju nakon uvođenja nego pre toga. Upravo zato,
važno je kontinuirano proveravati kvalitet sistema sa posebnim akcentom na njegovu
funkcionalnost, pouzdanost, aplikativne performanse i sistemske performanse.
Proveravanje funkcionalnosti sistema uključuje kreiranje testova, za svaki ključni
scenario koji predstavlja neki aspekt željenog ponašanja sistema. Prilikom proveravanja
funkcionalnosti sistema potrebno je evidentirati svaki scenario koji nije zadovoljio
zahteve i pristupati njegovom osposobljavanju. Poštujući iterativan razvoj softvera tako
je potrebno pristupati i testiranju, testirajući svaku iteraciju. Provera kvaliteta softvera
pruža brojna rešenja ključnim uzrocima problema razvoja softvera:
• procena statusa razvojnog projekta izrađuje se objektivno, jer se vrednuju
rezultati testa;
• objektivno procenjivanje otkriva nekonzistentnosti u zahtevima, dizajnu i
implementaciji;
• testiranje i verifikacija su usmereni na oblasti najvišeg rizika, te se na taj način
uvećavaju kvalitet i efektivnost tih oblasti;
• greške se otkrivaju rano, radikalno snižavajući troškove njihovog ispravljanja.
Kontrola promena softvera. Ključni izazov prilikom razvoja softverskih sistema jeste
usklađivanje rada razvojnih inženjera organizovanih u razvojne timove koji zajedno
rade na više iteracija stvarajući softverski proizvod. Tokom razvoja novonastajući
sistem se menja i razvija, a kontrola tih razvojnih promena nužna je za sprečavaje haosa
u procesu razvoja. Usklađivanje aktivnosti, artifakta i uloga predstavlja ponovljivi
workflow koji prati razvoj softvera kroz promene u procesu razvoja. Standardizacija
workflow-a, sastavljenih od aktivnosti, artifakta i uloga, u procesu razvoja omogućuje
praćenje promena, rano otkrivanje problema i brzo reagovanje u cilju njihovog
otklanjanja. RUP razvoj informacionih sistema postavlja između dve dimenzije,
vremenske i sadržajne. Vremenska dimenzija je podeljena u četiri faze: uvođenje,
elaboracija, konstrukcija i tranzicija. Sadržajna dimenzija je podeljena u šest osnovnih i
tri pomoćne discipline. U osnovne spadaju disciplina poslovnog modelovanja, disciplina
zahteva, disciplina analize i dizajna, disciplina implementacije, disciplina testiranja i
disciplina raspoređivanja. Pomoćne discipline su konfigurisanje i upravljanje
promenama, upravljanje projektom i okruženje. Svaki element matrice RUP-a
predstavlja kombinaciju elemenata statičke strukture RUP-a i vremenskog rasporeda
istih. RUP je moguće posmatrati kroz dve dimenzije, kroz dinamičku, u kojoj se proces
opisuje kroz životni ciklus razvoja proizvoda, i statičku, u kojoj se opisuju aktivnosti i
rezultati aktivnosti podeljeni na uloge.
Dinamička struktura RUP-a. RUP razvojni proces predstavlja kroz ciklus od četiri
prethodno u tekstu navedene faze. Kao krajnji proizvod ovog ciklusa dobija se gotov
softverski proizvod. Faze u procesu razvoja se ne izvršavaju u jednom prolazu, već se
svaka od faza izvršava u nekoliko iteracija. RUP ne predviđa tačan broj iteracija. Do
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 107
tačnog broja iteracija po svakoj fazi dolazi se prilikom prilagođavanja RUP-a
sopstvenim potrebama, tj. prilikom definisanja konkretnog procesa razvoja. Svaka od
utvrđenih iteracija donosi inkrement koji uvećava vrednost softverskog proizvoda u
izradi. Kraj svake od faza smatra se ključnom tačkom u procesu razvoja. Ključne tačke
predviđaju, na osnovu izvršene intergacije inkremenata realizovanih u posmatranij fazi,
krajnje rezultate date faze.
4.2.3 Dynamic systems development method
DSDM [41] okvir može biti realizovan u okviru agilnog ili tradicionalnog razvojnog
procesa. Poštovanje devet principa neophodno je za realizaciju DSDM [26], i ignorišući
jedan od njih prekinuće sa filozofijom okružena i značajno će se povećati rizici projekta.
Neki od koraka u zavisnosti od okruženja u kojem se primenjuje [199], mogu se
modifikovati da bi odgovarali konkretnom projektu. Principi su sledeći:
• aktivno uključivanje korisnika je imperativ;
• članovi tima moraju biti osposobljeni i ovlašćeni za donošenje odluka;
• fokus se stavlja na česte isporuke proizvoda;
• sposobnost za primenu kod korisnika jesu kriterijumi za prihvatanje isporuka;
• iterativno inkrementalni razvoj je obavezan;
• sve promene u toku razvoja moraju biti reverzibilne;
• proglašenje osnovnih zahteva visokog nivoa;
• testiranje je integrisano u životni ciklus razvoja;
• kolaborativni i kooperativni pristup u razvoju.
DSDM kao framework je veoma dinamičan i modularan, slika 25. DSDM ne zahteva
implementaciju celokupne projektne strukture, samo zahteva strogu poslušnost u
primeni devet principa. Pored toga, svaki projekat menadžer može sprovesti
odgovarajuće izmene procesa razvoja manje ili više agilne, u zavisnosti od situacije i
ograničenja, a u mogućnosti je čak i da kombinuje sa drugim metodama razvoja. DSDM
nema za cilj da reši sve probleme razvoja. Kada devet principa ne može biti realizovano,
DSDM najverovatnije nije najbolji izbor. DSDM projekat se sastoji od sedam koraka
fazama, slika 14. (pretprojektne aktivnosti, studija izvodljivosti, poslovna studija,
iteracije funkcionalnog modela, iteracije dizajna, implementacija i postprojekat faza), u
koje su organizovane ugrađene uloge sa odgovarajućim odgovornostima. DSDM je
podržan od strane nekoliko ključnih tehnika. Preporučene Core tehnike, opisane u radu
jesu [105]:
• vremenske kutije;
• MoSCoW pravila (Must, Should, Could, Want);
• pravljenje prototipa;
• specijalizove radionice.
Rukovodioci moraju da pre početka i tokom DSDM primene da ga imaju pod
kontrolom, a ključni faktori koji moraju da budu pod kontrolom jesu: prihvatanje
DSDM filozofije pre početka rada, odlučivanje o ovlašćenjima korisnika i programera
unutar razvojnog tima, posvećenost višeg menadžmenta naručioca da obezbedi značajno
učešće krajnjeg korisnika, inkrementalne isporuke, jednostavan pristup od strane
programera krajnjim korisnicima, stabilnost tima, veštine razvojnog tima, veličina
razvojnog tima, primenjene tehnologije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 108
CMM (Capability Maturity Model), ISO 9001 i ekstremno programiranje savršeno su
pogodni da se integrišu u DSDM implementacije jer se mnogi koncepti DSDM mogu
poboljšati kao i upravljanje projektom.
DSDM je napredan okvir nastao na osnovu najboljih praksi implementacije; prednosti
su jednostavnost, proširivosti, što je dokazano u primeni, ali ne prestavlja rešenje za sve
vrste projekata. Slabost DSDM je, kao i sa mnogim drugim strukturiranim pristupima,
skup i spor prelazak koji zahteva značajan kulturni zaokret u bilo kojoj organizaciji.
DSDM jasno se predstavlja kao najzrelija metoda agilnog razvoja. Nekoliko agilnih
metodologije dele zajedničke osnove sa DSDM, na primer Scrum, koji kao DSDM,
promoviše jačanje tima. Cristal metodologije zauzvrat pretpostavljaju da su kolekcija
najboljih praksi, gde kao DSDM zahteva sveobuhvatan posao u primeni pokazujući
svoju evolutivni karakter verzija njihovog okvira posle svake revizije od strane DSDM
konzorcijuma [105].
Slika 25. Faze projekta [105]
Spisak firmi koje koriste DSDM je dugačak, u njemu su i Shell, osiguravajuće kuće
Loids banke, British Telecom, British Airvais, Deutsche Bahn, Hevlett-Packard,
Renault, grad Los Anđeles i drugi. Mnoge druge organizacije već mogu koristiti
DSDM, ali još uvek nisu spremne da se javno obavežu na DSDM, čak najveći prodavac
softvera, Microsoft pozajmljuje ideje iz DSDM prilikom objavljivanja svog poluagilnog
rešenja. Primena agilnih metodologija razvoja je veoma vidljivo u porastu.
4.2.4 Extreme programing
Prvi Extreme Programming projekat je startovan 06.03.1996. Extreme Programming je
jedan od popularnijih metoda agilnih procesa [92]. Pokazala se uspešnom u mnogim
kompanijama različitih veličina i industrija širom sveta. Extreme Programming je
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 109
uspešan pošto ima naglasak na zadovoljstvu naručioca. Umesto isporuke svega što se
može zahtevati jednog dalekog dana u budućnosti, ovaj proces isporučuje softver onim
redom kako proizvod nastaje. Extreme Programming ohrabruje developere da odgovore
na promenu u zahtevima korisnika, čak i kasno u životnom ciklusu razvoja softvera.
Extreme Programming naglašava timski rad. Rukovodioci, naručioci posla i developeri
su podjednaki partneri u timu koji međusobno sarađuje. Extreme Programming
implementira prosto i efikasno okruženje koje omogućava timu da bude produktivan.
Tim se samoorganizuje oko problema koji treba rešiti na najefikasniji mogući način.
Extreme Programming poboljšava projekat razvoja softvera u pet osnovnih pravaca:
razvijenoj komunikaciji, negovanju jednostavnih rešenja uz povratne informacije,
uzajamnom poštovanju učesnika i smelost. Developeri uključeni u Extreme
Programming proces konstantno komuniciraju sa naručiocem i kolegama
programerima. Oni ne usložnjavaju dizajn svojih rešenja i neguju čista i elegantna
rešenja. Imaju povratnu spregu sa testiranja njihovih komponenata od početnog dana
razvoja proizvoda. Isporučuju komponente naručiocu što je to pre moguće i na predloge
odmah implementiraju izmene. Svaki mali uspeh produbljuje poverenje u doprinos
svakog člana ekipe. Sa ovim osnovama developeri su u stanju da hrabro odgovore na
promenljive zahteve i primenu nove tehnologije.
Slika 26. Extreme programming procesi
Najistaknutiji aspekt Extreme Programming su jednostavna pravila. Ekstremno
programiranje je poput rešavanja slagalice. Postoji mnogo malih komada. Pojedinačno
komadi nemaju nikakvog smisla, ali tek kada se iskombinuju u zajedničku kompletnu
sliku, može da se vidi šta u stvari predstavljaju. Pravila mogu izgledati čudno i možda
čak i naivno na prvi pogled, ali su zasnovana na čvrstim vrednostima i principima.
Pravila su ustrojena između članova tima, ali nisu krajnji cilj za sebe. Pravila definišu
okruženje koje promoviše timsku saradnju. Jedanput postignut produktivan timski rad
će imati kontinuitet i ako se pravila izmene da bi se rezultati uklopili u specifične
potrebe naručioca. Slika 26. pokazuje kako su komponovana Extreme Programming
pravila. Kupci su u ulozi partnera u procesu razvoja softvera, programeri aktivno
doprinose u skladu sa novim iskustvima, dok su menadžeri u poziciji da se koncentrišu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 110
na komunikaciju i izgradnju odnosa sa partnerima. Neproduktivne aktivnosti su
odstranjene da smanje troškove, kao i frustraciju osoba koje su uključene u projekat.
4.3 Servisno orijentisana arhitektura
Uslužno orijentisana arhitektura (SOA – Service Oriented Architecture) je pojam koji
označava infrastrukturalni model sistema čija se funkcionalnost zasniva na međusobno
interoperabilnim „uslugama“, tj. funkcionalnim entitetima koji su u interakciji putem
definisanih standarda [100]. Egzaktna definicija ne postoji, pa čak ni konsenzus oko
toga da li pojam označava samo paradigmu, model sa svojstvima i smernicama kojih se
pri implementaciji treba pridržavati ili čak strogo definisani skup tehnologija koje
zajedno čine okosnicu uslužno orijentisane arhitekture. [11]
Raghu R. Kodali, softverski inženjer iz kompanije Oracle i autor članaka za portal
JavaWorld smatra da je SOA „…evolucija distribuiranog računarstva nastala na
paradigmi zahtev/odgovor za potrebe sinhronih i asinhronih aplikacija. Poslovna logika
aplikacije ili samo individualne funkcije objavljuju se u obliku usluga za korisnike, tj.
klijentske aplikacije. Ključ sistema je svojstvo slabe povezanosti usluga, tj. nezavisnosti
između interfejsa usluga i njihove implementacije. Kreatori aplikacija mogu izgrađivati
aplikacije povezivanjem jedne ili više usluga bez znanja o njihovoj konkretnoj
implementaciji.“ [93]. Ova definicija naglašava nekoliko ključnih karakteristika SOA
sistema koje se najčešće spominju u svim definicijama – modularnost, distribuiranost i
slaba povezanost [124].
Jedna od bolje sročenih definicija, koja se takođe često može naći u člancima
povezanim sa SOA, jeste ona koju je dao Malte Poppensieker, profesor Trierskog
univerziteta u Nemačkoj i koja glasi: „SOA je arhitektura u kojoj autonomne, slabo
povezane i široko definisane usluge dobro definisanih interfejsa pružaju poslovnu
funkcionalnost koja može biti na određeni način otkrivena i kojoj se može pristupiti
kroz odgovarajuću infrastrukturu. Ovo omogućuje kako unutrašnju tako i spoljašnju
integraciju, kao i fleksibilnu ponovnu iskoristljivost logike aplikacije logike kroz
kompoziciju i rekompoziciju usluga.“ [57]. Ova definicija uz ponovno naglašavanje
slabe povezanosti i integracije spominje i nekoliko dodatnih paradigmi koje se najčešće
vežu uz pojam uslužno orijentisane arhitekture: svojstvo otkrivanja usluga, nužnost
dobro definisanih interfejsa i pojam ponovne iskoristljivosti koji je okosnica
funkcionalnosti uslužno orijentisane arhitekture.
Za vizuelnu reprezentaciju SOA arhitekture često se koristi trougao „klijent-usluga-
registar“ koji prikazuje visokoapstraktnu sliku glavnih odlika ovakvog sistema – objavu,
pronalaženje, te povezivanje s traženom uslugom. U tom trouglu se jasno izdvajaju tri
glavna učesnika SOA arhitekture: pružalac usluga, klijent usluga i registar usluga kao
infrastrukturalna podrška koja omogućava pretragu usluga i daje konkretne informacije
o njihovoj lokaciji i o tome kako im se može pristupiti.
4.3.1 SOA - osnovna obeležja
Servisno orijentisana arhitektura (SOA) predstavlja model korišćenja aplikacija ili
softverskih modula u obliku informatičkih usluga, nezavisno od granica sistema u kome
se te aplikacije nalaze. SOA sadrži komponente koje osiguravaju interoperabilnost i
transparentnost aplikacija, nezavisno od njihove fizičke lokacije ili tehnologije
implementacije. Ova tehnologija se bazira na korišćenju postojećih sistema i aplikacija i
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 111
nema tendenciju potpunog zamenjivanja starih, nasleđenih sistema. Koncept SOA u
određenom smislu štiti postojeće investicije u softverske/hardverske platforme koje
povezuje, olakšava izmene, i dalji razvoj usluga korišćenjem istih nasleđenih sistema.
Tehnologija veb-servisa (Web Services) je osnova arhitekture usmerene uslugama. Veb-
servisi omogućavaju poslovnim aplikacijama zajedničke transportne protokole,
programske interfejse i transakcione modele. Veb-servisi takođe omogućavaju
korišćenje aplikacija unutar i izvan organizacije u kojoj se nalaze. Pomoću njih možemo
relativno jednostavno uključiti spoljne partnere, dobavljače ili korisnike u interne
informacione sisteme. Osnovne poslovne prednosti korišćenja servisno orijentisane
arhitekture pri dizajnu informacionih sistema su: brža i jeftinija izgradnja novih usluga
ili aplikacija, manji troškovi održavanja sistema, viši stepen interoperabilnosti.
Ono što tradicionalne računarske sisteme razlikuje od servisno orijentisanih sistema je
to da se servisno orijentisani sistemi oslanjaju na pristup utemeljen na labavim vezama
(loosely coupled approach ili loosely coupled architecture), dok su se tradicionalni
računarski sistemi oslanjali na čvrsto spregnute arhitekture (tightly coupled
approach/architecture). Ovaj pristup čvrsto spregnutih arhitektura pokazao se
neadekvatnim kod početaka razvoja internetskog računarstva, krutim za primenu u
heterogenim i promenljivim uslovima elektronskog poslovanja, takođe i nepodesnim za
stvaranje sigurnog i kvalitetnog kolaborativnog okruženja.
Osnovna obeležja servisno orijentisane arhitekture su:
• SOA čini virtualnu platformu servisa, dostupnu bilo kom informacionom
sistemu; potpuno odvaja servise od njihove interne implementacije;
• svi interfejsi moraju da budu univerzalno dostupni svim ostalim elementima
sistema; mogućnost njihovog pozivanja ne sme da zavisi od fizičke lokacije i
internih protokola ili infrastrukture komponente;
• servisi mogu biti lokalni (unutar sistema) ili spoljašnji (izvan sistema); različite
ravnopravne opcije pristupa servisima su: pristup iz iste aplikacije, pristup
unutar istog sistema, pristup iz nekog drugog sistema;
• poruke kojima postavljamo zahtev prema veb-servisima moraju da budu opisne,
a ne instrukcijske; šema poruke i sintaksa moraju da budu čvrsto definisane i
unapred dogovorene kako bi provajder servisa ispravno interpretirao zahtev za
uslugom;
• sistem mora da poseduje mogućnost proširenja i dovoljnu fleksibilnost kako bi
omogućio brze promene funkcionalnosti bez dodatnog menjanja postojećih
komponenata; promene uslovljene poslovnim okruženjem često se ne mogu
dovoljno brzo implementirati u odgovarajuće informacione sisteme, a upravo
SOA arhitektura treba da omogući potrebnu fleksibilnost;
• sistem mora da omogući svojim korisnicima pronalaženje različitih servisa koji
trenutno mogu da zadovolje njihove zahteve;
• sistem mora da bude izgrađen na otvorenim standardima, jednostavnim
protokolima i ne sme da ima jedinstvenu tačku ispada čitavog sistema;
• arhitektura mora da omogući da sistem, a ne programer aplikacije, brine o
sigurnosti i pravilima izvođenja transakcija; proizvođači SOA platformi nude
većinu ovih elementa u obliku gotovih modula svojih proizvoda kako bi
zadovoljili osnovne specifikacije servisno orijentisane arhitekture.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 112
Na osnovu ovoga može se zaključiti da SOA zahteva poštovanje sledećih koncepata:
• interoperabilnost (interoperability) – e-servisi moraju između sebe biti
kompatibilni; u SOA servis je definisan kao funkcionalnost koju može izvesti
komponenta nekog sistema i koju mogu da koriste drugi sistemi; u praksi to
znači da jedan e-servis može da zahteva izvršenje jedne ili više operacija drugog
e-servisa; takođe je potrebno da, ako korišćenjem nekog e-servisa dobijamo
izlazne rezultate, ti rezultati budu u obliku koji je upotrebljiv za ostale e-servise;
• ponovna upotreba (reusability) – e-servise treba razvijati na modularan način,
što znači da se njihovi delovi mogu ponovo upotrebiti u drugim e-servisima;
• enkapsulacija (encapsulation) – korisnik ne treba da zna šta se dešava iza
korisničkog interfejsa; preko jedinstvenog interfejsa može da se koristi više e-
servisa, a specifikacije njihove implementacije korisniku treba da ostanu
sakrivene;
• skalabilnost (scalability) – arhitektura mora da omogućava proširenja novim
performansama, na hardverskom i softverskom nivou; npr. mogućnost
proširivanja servera sa dodatnim performansama, module novim
funkcionalnostima itd;
• labavo povezani sistemi (loosely connected systems) – taj koncept znači da mora
postojati mogućnost povezivanja e-servisa, ali da svaki od njih predstavlja
samostalnu jedinicu (funkcionalnost).
Servisno orijentisana arhitektura definiše model interakcije između tri glavne
funkcionalne jedinice: korisnika servisa, provajdera servisa i registra servisa, u kome
korisnik servisa stupa u interakciju s provajderom servisa kako bi otkrio servis koja
odgovara njegovim zahtevima putem registra za pretraživanje.
SOA sadrži šest osnovnih elemenata u svom konceptualnom modelu [124]:
• Korisnik servisa: Korisnik može biti aplikacija, neki drugi servis ili neka druga
vrsta softverskog izvora kome je potreban servis; Korisnik servisa inicira zahtev
za pronalaženje servisa i koristi servis; Lokacija servisa otkriva se ili
pretraživanjem registra, ili, ako je poznata, korisnik može direktno da stupi u
interakciju s provajderom servisa;
• Povajder servisa: to je mrežna adresabilna komponenta koja prihvata i izvršava
zahteve primljene od korisnika; on pruža precizan opis usluge i njenu
implementaciju; Provajder servisa može biti mainframe sistem, komponenta ili
neka druga vrsta softverskog sistema koji ispunjava zahteve korisnika za nekom
uslugom;
• Registar servisa: je direktorijum (imenik) kome se putem mreže može pristupiti i
koji sadrži spisak i opis dostupnih servisa; njegova glavna funkcija je da
skladišti i objavljuje opise servisa i da ih dostavlja zainteresovanim korisnicima.
• Ugovor o servisu: je specifikacija načina na koji se vrši interakcija izmedu
korisnika i provajdera servisa; sadrži informacije o formatu zahtev-odgovor
(request-response) poruke, uslovima u kojima bi servis trebalo da se izvršava i
kvalitetu servisa;
• Proxy servis (service proxy): provajder servisa može postaviti proxy servis preko
koga korisnik servisa pristupa veb-servisima; Korisnik izvršava zahtev za
servisom pozivom API funkcije na proxy-ju; Proxy servis pronalazi ugovor o
servisu i podatke o provajderu servisa u registru; on tada u ime korisnika šalje
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 113
zahtev za veb-servisom provajderu servisa i povezuje se sa servisom.
• Zakup servisa: svaki put kada korisnik uputi zahtev za veb-servisom i ostvari
kontakt sa njim, vreme koje mu se dodeljuje za korišćenje servisa ograničeno je i
naziva se zakup servisa; kada istekne period zakupa, korisnik servisa mora da
uputi registru zahtev za obnovu ugovora o zakupu servisa; kada ograničenje
trajanja konekcije ne bi postojalo moglo bi se desiti da korisnici beskonačno
dugo drže resurse veb-servisa a time i provajdera servisa.
4.3.2 SOA - arhitektura
SOA se bazira na višeslojnom (n-tier) logičkom modelu. Slojevi SOA logičke
arhitekture prikazani su na slici 27. [124]:
Sloj operativnog radnog sistema: Ovaj sloj sadrži resurse sistema: postojeće aplikacije
uključujući CRM (customer relationship management) i ERP (enterprise resource
planning), starije objektno orijentisane sisteme, aplikacije poslovne inteligencije i baze
podataka. Preko servisno orijentisanih integracionih tehnika ovi postojeći sistemi se
mogu integrisati u SOA.
Sloj komponenata servisa: U ovom sloju se nalaze komponente odgovorne za
realizaciju funkcionalnosti i podržavanje odgovarajućeg kvaliteta ponuđenih servisa
(upravljanje, dostupnost i nivelacija opterećenja kome je izložen servis).
Sloj servisa: Ovaj sloj sadrži stvarne servise koji se mogu lako otkriti i potraživati od
strane drugih korisnika (aplikacija) sa ciljem pružanja specifičnih poslovnih funkcija za
korisnike. Servisi mogu biti jednostavni i složeni.
Sloj kompozicije poslovnog procesa: Servis može biti sastavljen u jedinstvenu
aplikaciju putem orkestracije ili koreografije usluge, što podržava specifičnu upotrebu
slučajeva i poslovnih procesa.
Sloj korisnika servisa: Korisnički sloj je mesto gde korisnici servisa, bez obzira da li su
to osobe, programi, drugi veb-servisi ili pretraživači, komuniciraju sa SOA. Pruža
korisničke interfejse za servise i složene aplikacije. Korisnicima je omogućen pristup
preko različitih kanala (veb-stranice, klijentske aplikacije, mobilnog uređaja, terminal
itd.)
Druga pitanja koja se tiču SOA jesu integracija servisa i aplikacija unutar sistema
podržavanjem parametara kao što su pouzdanost, odgovarajuće usmeravanje i
koordinacija servisa, i upravljanje drugim tehničkim detaljima uključujući ugovor o
protokolu i strane zadužene za integraciju. Zahtevi kvaliteta servisa (Quality of Service,
QoS), sigurnost, upravljanje i praćenje servisa takođe su zahtevi o kojima treba voditi
računa prilikom dizajna servisno orijentisanih arhitektura.
Slika 27. Model višeslojne logičke arhitekture SOA [124]
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 114
4.3.3 SOA - prednosti i nedostaci
Jedna od ključnih prednosti primene SOA jeste interoperabilnosti i laka integracija
različitih sistema. Jedan od vodećih problema poslovnih sistema današnjice jeste
nepostojanje zajedničkih standarda i mnoštvo zatvorenih poslovnih aplikacija koje se ne
mogu na jednostavan način povezivati i međusobno komunicirati i čija je
funkcionalnost ograničena na pristup kroz strogo definisane prilagođene korisničke
interfejse. Jednostavna mogućnost integracije različitih komponenata sistema i
adaptacija otvorenih standarda mogu troškove integracije svesti na minimum i znatno
olakšati, kako poslovanje unutar sistema, tako i poslovanje između različitih sistema.
Ponovna iskoristivost komponenata opravdava ulaganje u informacione resurse ovog
tipa jer postoji potencijal njihovog budućeg korišćenja bez potrebe za nabavkom ili
izgradnjom novih komponenata slične ili iste funkcionalnosti. Proširivost sistema
omogućava laku nadogradnju sistema prema novim poslovnim zahtevima i potrebama,
bez potrebe za opsežnim reinžinjeringom sistema. Npr. tzv. WS-proširenja
omogućavaju nadogradnju postojećeg sistema SOA zasnovanog na veb-servisima
mehanizmima sigurnosti, pouzdanosti i sl. Oslonac SOA na tehnologiju XML-a
omogućava lakši prelazak na XML reprezentaciju poslovnih podataka i lakšu
konsolidaciju poslovnih informacija. XML dokumenti i XML šeme omogućavaju lako
upravljanje, smeštanje i analizu poslovnih podataka. Troškovi povezani uz
skalabilnošću informacione infrastrukture znatno su smanjeni, pošto se ulaže u
jedinstvenu komunikacionu tehnologiju zasnovanu na otvorenim standardima.
Uprkos navedenim prednostima, adaptacija na principe SOA može dovesti i do
negativnih posledica, pogotovo ako se ista uvodi bez potrebnih predznanja i procena
svih mogućih uticaja na postojeći poslovni sistem. Česta greška kod prilagođavanja
sistema SOA konceptu, je pristup od-dna-prema-gore (bottom-up approach), gde se
implementacija arhitekture SOA svodi samo na proširenje postojećih aplikacija pomoću
interfejsa veb-servisa dok se tipovi podataka koje one koriste direktno preslikavaju u
XML šeme i navode kao parametri metoda servisa. Rezultat ovoga može biti skup
servisa, koji uprkos korišćenju istih standarda nemaju dosledno definisane tipove
podataka za razmenu, pa je time integracija otežana, stepen interoperabilnosti manji, a
ulaganje u SOA neopravdano. Uvođenje SOA sa sobom donosi i određeni uticaj na
performanse sistema. Mapiranje podataka na XML prikaz, provere ispravnosti i obrada
XML dokumenata često mogu negativno uticati na performanse celog sistema. Zbog
toga arhitekturu SOA treba uvoditi postepeno, uočavajući potencijalne probleme i uska
grla koja najviše utiču na pogoršanje performansi i lošu efikasnost sistema. Veb-servisi
predstavljaju jedno od najraširenijih tehnologija za implementaciju SOA arhitekture, ali
oni izvorno ne sadrže sigurnosne mehanizme. Otvaranje poslovnih aplikacija kroz
interfejse veb-servisa može nenamerno stvoriti sigurnosne rupe unutar sistema i
kompromitovati osetljive informacije unutar poslovnog sistema i omogućiti neovlašćeni
pristup informacijskim resursima. Zbog toga je ključno unapred oceniti sigurnosne
zahteve nad sistemom i pronaći adekvatno rešenje njihove implementacije.
4.3.4 SOA - tehnologije za realizaciju
SOA i tehnologija veb-servisa često se međusobno izjednačavaju iako se zapravo radi o
dva različita koncepta. Principi SOA su stariji od veb-servisa - npr. tehnologija CORBA
(Common Object Request Broker Architecture) i Microsoft-ov DCOM (Distributed
Component Object Model) odgovaraju osnovnim principima SOA jer nude mogućnost
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 115
izgradnje slabo povezanih servisa-funcionalnosti sa standardizovanim interfejsima. Ove
tehnologije se doduše ne spominju često kao tehnologije za realizaciju arhitekture SOA
iz nekoliko razloga – DCOM nije bio platformski neutralan, već usko povezan uz
proizvode kompanije Microsoft, dok je CORBA bila implementirana od većeg broja
proizvođača softvera, ali konačna rešenja nisu bila međusobno kompatibilna.
XML, SOAP i konačno tehnologija veb-servisa prve su tehnologije koje su gotovo bez
izuzetka podržavale sve zahteve SOA. Ono što je ključno jeste činjenica da su početkom
21. veka veliki proizvođači softvera prihvatili tu tehnologiju i počeli razvijati rešenja
koja su – za razliku od tehnologije CORBA – bila kompatibilna pa su se mogla lako
integrisati u jedinstveni informacioni sistem. Može se reći da su od 2002. do 2007.
godine pojam SOA i pojam veb-servisa u gotovo svim aspektima bili gotovo
jednoznačni.
Krajem prve dekade 21. veka neki stručnjaci smatraju da pojam SOA polako nadrasta
tehnologiju veb-servisa [124]. Zahtevi modernog poslovnog informatičkog tržišta rastu
u opsegu i kompleksnosti što tehnologija ne može da prati. Primer toga su proširenja
tehnologije veb-servisa, tzv. WS-Extensions, o kojima će kasnije biti reči. Ova
proširenja za sada još nisu deo standarda veb-servisa već su predmet stalne rasprave i
međusobnog preuzimanja nadležnosti od strane velikih proizvođača softvera, koji su
čak u nekoliko navrata izdali paralelne specifikacije iste predviđene funkcionalnosti.
Zbog toga se predviđa sve jače razdvajanje pojma SOA i pojma veb-servisa tj. prelazak
pojma SOA na viši nivo apstrakcije dok veb-servisi postaju samo jedan u nizu gradivnih
blokova SOA. Takođe, očekuje se šira primena veb-usluga pošto one kao tehnologija ne
moraju nužno funkcionisati samo kao deo SOA. Usprkos tome, trenutno veb-usluge i
dalje važe kao glavna i ključna tehnologija za izgradnju SOA.
4.3.5 Veb-servis kao tehnološka infrastruktura SOA
Veb-servisi su tehnološka infrastruktura, tj. skup međusobno povezanih tehnologija čija
sinteza omogućava traženu funkcionalnost. World Wide Web konzorcijum definiše veb-
servise kao programske interfejse za komunikaciju između aplikacija preko veb-a. Ova
definicija naglašava da veb-servis omogućava komunikaciju računara sa računarom. U
istom smislu druga definicija navodi da je veb-servis usluga koja se izvršava na
Internetu korišćenjem veb-protokola i da ne uključuje akciju čoveka [124]. Veb-servisi
su distribuirane funkcionalne softverske komponente koje su sposobne za međusobnu
komunikaciju i komunikaciju sa aplikacijama preko standardnih Internet protokola, pa
su kao takve ponuđene za korišćenje u razvoju drugih aplikacija. Drugim rečima, veb-
servisi su zamišljeni kao gradivni blokovi za kreiranje otvorenih, interoperabilnih,
distribuiranih aplikacija. Veb-servisi su modularne, samoopisujuće aplikacije koje se
mogu objaviti, locirati i pozvati sa bilo koje tačke veb-a ili lokalne mreže. Veb-servisi
se ponašaju nezavisno jedan o drugog, a prema svojim korisnicima se predstavljaju kao
crne kutije. Njihova interna implementacija je nevidljiva za korisnika.
4.3.5.1 Simple Object Access Protocol (SOAP)
SOAP (Simple Object Access Protocol) je protokol nastao zajedničkim radom IBM-a i
Microsofta. Njegov dalji razvoj na sebe je preuzeo W3C. To je protokol za slanje
poruka i poziva udaljenih procedura (RPC, ili Remote Procedure Calls), baziran na
XML-u. SOAP ne definiše novi aplikacioni protokol, već koristi postojeće internet
protokole poput HTTP-a i SMTP-a. SOAP povezuje koncept veb-servisa sa postojećom
internetskom infrastrukturom. RPC ili poziv udaljene procedure je vrsta protokola koji
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 116
programu koji se obavlja na klijentskom računaru omogućava izvršenje programa na
serveru.
SOAP definiše kako aplikacije mogu da komuniciraju, i to na sledeći način:
• komunikacija je orijentisana na razmenu poruka, što znači da aplikacije mogu da
komuniciraju jedna sa drugom, razmenom tekstualnih poruka; format ovih
poruka je specificiran u SOAP-u;
• SOAP poruka ima jednostavnu strukturu koja se sastoji od XML parent
elementa sa dva child elementa: zaglavlja i tela;
• SOAP poruke primaocu daju informaciju o tome kako poruke treba da se obrade
i ko treba da ih obradi;
• RPC-i, tj. izvršenje programa ili delova programa, procedura, ostvaruje se sa
SOAP protokolom.
Na današnjem Internetu veliki broj aplikacija komunicira koristeći TCP (Transmission
Control Protocol) i IP (Internet Protocol) protokole. Problem na koji nailaze je u tome
što većina aplikacija ima posebne aplikacione protokole kojima mogu da komuniciraju
samo s ograničenim brojem drugih aplikacija. HTTP protokol je aplikacioni protokol
koji se u mrežnoj arhitekturi nalazi iznad TCP protokola i služi za komunikaciju između
veb-pretraživača i provajdera. Iako je HTTP vrlo uspešan protokol, ograničen je na
samo nekoliko jednostavnih operacija - GET, POST i PUT. Rezultat toga je da
međusobno povezane aplikacije koriste tu povezanost samo za Internet pretraživanje, a
ne da bi bez ograničenja razmenjivale podatke. SOAP rešava taj problem definisanjem
standardnog načina komunikacije između aplikacija. SOAP omogućava komunikaciju
među aplikacijama iznad bilo kog protokola uključujući i TCP. Arhitektura SOAP
protokola prikazana je na slici 28.
Slika 28. Arhitektura SOAP poruke [124]
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 117
SOAP je aplikacioni protokol i kao takav može da radi iznad bilo kog prenosnog
protokola. Današnji Internet prepun je zaštitnih mehanizama koji dozvoljavaju jedino
komunikaciju preko HTTP protokola. I pored toga, a u cilju pouzdanog povezivanja
aplikacija, SOAP mora da omogući prenos podataka. To se postiže postavljanjem
SOAP-a, u mrežnoj arhitekturi, iznad HTTP-a. Postavljanje SOAP-a iznad HTTP-a
znači da su SOAP poruke deo HTTP poruka i kao takve mogu da se prenose preko svih
mreža koje propuštaju HTTP protokol. HTTP je dobar izbor i zbog toga što je nezavisan
od platforme i uređaja koji ga koriste. Kako bi postigao platformsku nezavisnost SOAP
za predstavljanje podataka koristi XML. Kao i HTTP, XML je platformski nezavisan.
Zahvaljujući tome SOAP omogućava komunikaciju između aplikacija bez obzira na
platformu na kojoj se izvode i mrežu na kojoj su postavljeni.
Osnovna prednost SOAP-a je u tome što je jednostavan. SOAP nije zamišljen da reši
sve probleme distribuiranih sistema, već da definiše onaj minimum koji je potreban da
bi aplikacije mogle međusobno da komuniciraju. SOAP se zasniva na prenosu SOAP
poruka od pošiljaoca (sender) do primaoca (recipient). Da bi se shvatio SOAP najbolje
je na SOAP poruke gledati kao na poruke koje se razmenjuju između klijenta i mrežne
usluge. Arhitektura SOAP poruke (slika 28.) sastoji se od omotača (envelope) koji može
da ima zaglavlje (header) i mora da ima telo (body). Unutar tela SOAP poruke nalaze se
podaci (teret) koje treba preneti od pošiljaoca do primaoca.
4.3.5.2 Web Services Description Language (WSDL)
Kao što se XML šema koristi za opisivanje tipova podataka veb-servisa, tako postoji i
potreba za jezikom koji bi opisivao čitav interfejs veb-servisa. WSDL (Web Service
Description Language) opisuje interfejs veb-servisa, protokole koje podržava veb-servis
i lokaciju na kojoj je servis smešten.
Slika 29. WSDL opis veb-servisa [124]
Aplikacija koja želi da koristi neki veb-servis koristi WSDL datoteku kako bi saznala
lokaciju tog servisa, dostupne pozive funkcije i načina pristupa (za svaki poziv funkcije
WSDL opisuje njegov oblik). Korisnik koji poziva uslugu aplikacije prvo od provajdera
dobija WSDL datoteku, a onda koristi informacije iz te datoteke kako bi oblikovao
SOAP zahtev. Moguće je odrediti sintaksu za poziv funkcije bez WSDL-a, samo iz
dostupne dokumentacije, ali pritom je u komunikaciju uključen čovek. Sa WSDL-om se
taj postupak može automatizovati. WSDL opis veb-servisa može se podeliti u dva
osnovna dela, kako je prikazano na slici 29.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 118
4.3.5.3 Universal Description, Discovery and Integration (UUDI)
Prilikom kreiranja i stavljanja u upotrebu veb-servisa, potrebno je imati na umu
činjenicu da potencijalni korisnici tih servisa najpre moraju saznati gde su oni dostupni.
WSDL dokumenti jasno određuju pristupne tačke za pojedini servis i kako se njime
koristiti, ali problem je u tome što korisnici treba da pronađu mesto gde se WSDL
dokumenti nalaze. Zbog toga je potrebno stvoriti mehanizme koji će na brz i
jednostavan način omogućiti otkrivanje podataka potrebnih za pristup veb-servisima. To
su u stvari registri koje provajderi servisa pune informacijama o svojim servisima, a
korisnici ih pretražuju ne bi li našli ono što ih zanima.
Provajder servisa, nakon što je kreirao određeni servis, čuva podatke o njemu na mesto
koje je poznato potencijalnom korisniku (javni UDDI registar). Korisnik zatim
pretražujući podatke nalazi informaciju potrebnu za pristupanje servisu i njihova
saradnja može da počne. Najvažniji mehanizam za otkrivanje veb-servisa danas je
UDDI standard (Universal Description, Discovery and Integration). To je standard koji
je uveliko doprineo opštem prihvatanju i upotrebi veb-servisa na Internetu.
Implementacija UDDI specifikacije je UDDI poslovni registar (UDDI Business
Registry). Namenjen je provajderima koji žele da objave svoje servise i korisnicima koji
određene servisa traže. Taj telefonski imenik veb-servisa koristi standardnu industrijsku
klasifikaciju za kategorizaciju poslovnih i drugih tipova servisa. Postoje:
• bele stranice, koje opisuju provajdera servisa (ime, adresu, kontakt itd);
• žute stranice sadrže industrijske kategorije;
• zelene stranice opisuju interfejs servisa (WSDL).
Korisnici mogu pretraživati UDDI registar po industrijskim i proizvodnim kategorijama,
i po geografskoj lokaciji. Kao rezultat pretraživanja dobija se XML datoteka koja sadrži
informacije (linkovi, tehnički podaci itd) na temelju kojih se mogu naći servisi koji
odgovaraju zahtevima.
4.4 Veb-servisi
Definicija veb servisa od strane World Wide Web konzorcijuma (W3C) jeste: „Veb-
servis je sistem dizajniran da podrži interakciju raznorodnih sistema preko mreže“.
Osnovni cilj, sa kojim je počelo projektovanje i primena veb-servisa jeste omogućiti
povezivanje raznovrsnih distribuiranih softverskih komponenata, bez obzira na kojoj su
platformi realizovane, koji je programski jezik pri tom korišćen, kao i platforma na
kojoj se izvršavaju. Sa ovim ciljem se kreće u realizaciju veb-servisa a neka vizija
sistema koji se pri tome ima na uvid je da se veliki broj nezavisnih komponenti
dostupnih preko Interneta upotrebi na bilo kojoj platformi i u svim razvojnim
programskim jezicima. Prema ovome veb-servise treba shvatiti kao skup aplikacija
objavljenih na vebu koje se mogu pozvati sa bilo koje tačke na Internetu. veb-servisu je
moguće pristupiti preko računarske mreže, kao što je Internet, što omogućava da se
servis nalazi na udaljenim računarskim sistemima. Prema W3C fondaciji veb-servis
obuhvata više raznorodnih sistema, ali zajedničko za sve definicije je da se termin veb-
servis odnosi na klijent-server arhitekturu, gdje klijent i server komuniciraju preko
HTTP protokola, koji je široko rasprostranjen kao Internet protokol. Aplikacije
zasnovane na ovim standardima mogu se razvijati bilo gde, u bilo koje vreme i na bilo
kojim sistemima koristeći prednosti unapred izgrađenih komponenata, ubrzavajući
izradu aplikacija i smanjujući cenu razvoja novih sistema. Veb-servis predstavlja bilo
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 119
koji servis koji je dostupan preko Internet mreže, koristi standardizovani XML sistem za
razmenu poruka i nije vezan ni za jedan operativni sistem ili programski jezik.
4.4.1 Arhitektura veb-servisa
Pre pojave veb-servisa pojavljivao se problem pri pokušaju integracije različitih
aplikacija, koji je nastajao uglavnom zbog različitih programskih jezika i tehnologija
koje su korišćene pri kreiranju tih aplikacija. Verovatnoća da su dva poslovna sistema
razvijena korišćenjem istog programskog jezika vrlo je mala, a često je potrebno
zajednički koristiti njihove komponente integrišući ih na taj način u jedno zajedničko
poslovno rešenje. Da bi se veb-servisi primenili za integraciju različitih aplikacija, one
treba da budu prilagođene za upotrebu putem Interneta.
Slika 30. Povezivanje različitih platformi i tehnologija pomoću SOA i veb-servisa [124]
Korišćenjem standardnih protokola za razmenu podataka putem Interneta
(komunikaciona interoperabilnost), koji su nezavisni od računarske platforme, veb-
servisi u svom radu prihvataju i realizuju zahteve klijenata. Komunikacija klijenata i
servisa odvija se razmenom XML dokumenata pa se iz tog razloga veb-servisi nazivaju
XML veb-servisima. Primena XML standarda omogućava da razmena podataka između
klijenata i veb-servisa ne zavisi od tehnologije koja je nosilac izvora podataka, a ni od
računarske platforme koja je u pozadini (slika 30.). Pri tome klijenti koji koriste veb-
servise mogu biti različiti: mobilni telefoni, PDA uređaji, veb-pretraživači, druge
aplikacije, poslovni sistemi i drugi veb-servisi.
Vizija upotrebe veb-servisa predviđa njihovo registrovanje u privatnim i javnim
poslovnim registrima, tako da kreatori servisa opisuju komponente servisa, definišu
njihove interfejse, poslovnu logiku i uslove korišćenja. Mogući scenario korišćenja veb-
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 120
servisa može se prikazati sledećim koracima:
• kreator veb-servisa kreira osnovne komponente servisa, sklapa ih međusobno i
priprema za korišćenje, koristeći programski jezik i platformu po vlastitom
izboru;
• kreator veb-servisa definiše i opisuje veb-servis korišćenjem WSDL-a (Web
Service Description Language), omogućavajući dostupnost servisa drugim
korisnicima;
• kreator veb-servisa registruje servis u UDDI (Universal Description, Discovery
and Integration) registru; ti registri omogućavaju razvojnim timovima
objavljivanje njihovih servisa kao i pretraživanje i korišćenje drugih objavljenih
servisa;
• potencijalni korisnik pronalazi veb-servis pretraživanjem UDDI registra;
• korisnička aplikacija, veb-pretraživač ili uređaj za mobilnu komunikaciju
povezuje se na odabrani veb-servis korišćenjem SOAP-a (Simple Object Acces
Protocol), HTTP ili WAP protokola koji nude mogućnost korišćenja XML
formata za slanje parametara komponentama servisa i prihvatanja rezultata
obrade.
Veb-servisi svoju funkcionalnost, interoperabilnost i mogućnost izvršenja tri osnovne
operacije (slika 31.): objavljivanje, traženje i korišćenje, postižu pomoću standardnih
protokola, koji su prihvaćeni među vodećim informatičkim firmama (Microsoft, Sun,
IBM itd).
Slika 31. Arhitektura veb-servisa [124]
Na slici 32. prikazan je stek protokola veb-servisa. Sa desne strane prikazani su zahtevi
koji bi trebali da budu zadovoljeni kroz svaki sloj modela. Sa leve strane navedeni su
protokoli kojima se ostvaruju određene funkcionalnosti. Osnovni sloj steka protokola
veb-servisa je mreža. Veb-servisi moraju da budu klijentima dostupni preko mreže.
Veb-servisi koji su javno dostupni na Internetu koriste uobičajene mrežne protokole.
Zbog svoje dostupnosti HTTP protokol je de facto standardni mrežni protokol za veb-
servise dostupne na Internetu. Dozvoljeno je da komunikacija s veb-servisom bude
ostvarena ne samo HTTP-om, već i FTP-om (File Transfer Protocol), elektronskom
poštom, a moguća je i upotreba infrastruktura poput CORBA-e, ali se preporučuje njeno
korišćenje samo u intranet mrežama. Sledeći sloj, razmena XML poruka, predstavlja
XML kao osnovu za izradu protokola za razmenu poruka. SOAP (Simple Object Access
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 121
Protocol) je protokol za razmenu podataka kodiranih XML-om između klijenta i
provajdera. Sloj opis servisa je sloj koji se sastoji samo od dokumenata. WSDL (Web
Services Description Language) je standard za opis veb-servisa i takođe se bazira na
XML-u. UDDI (Universal Description, Discovery and Integration) je specifikacija
zasnovana na XML-u. Osnovna namena UDDI-a jeste da pruži način za objavljivanje i
pronalaženje veb-servisa. Komunikacija klijenta i provajdera s UDDI-em odvija se
pomoću SOAP protokola. Na samom vrhu nalazi se WSFL (Web Services Flow
Language). WSFL je XML jezik namenjen opisivanju načina povezivanja veb-servisa.
U WSFL-u su raščlanjena dva načina povezivanja veb-servisa:
• Ussage pattern - opisuje na koji način postići određeni poslovni cilj (opisuje
kojim redom je potrebno koristiti veb-servise da bi se postigao cilj);
• Overall partner interactions - opisuje međusobni uticaj veb-servisa jednih na
druge (ne prikazuje niz poziva kojim se postiže određeni cilj, već prikazuje sva
moguća međudejstva veb-servisa).
Da bi se izradili i uspešno koristili veb-servisi, nisu potrebni svi slojevi modela. Slojevi
objavljivanja, otkrivanja i protoka veb-servisa nisu neophodni za njegovu izradu.
Objavljivanje, otkrivanje i protok veb-servisa nije neophodan ukoliko osoba koja gradi
klijenta poseduje informacije o veb-servisu.
Slika 32. Stek protokola veb servisa [124]
Za implementaciju veb-servisa razvijeno je nekoliko tehnologija. Dve najpoznatije
tehnologije su Microsoft-ova .NET platforma, a druga tehnologija je vezana uz razvoj
servisa i klijenata u Java programskom jeziku. Razvoj veb servisa u Javi zasniva se na
korišćenju Apache SOAP Toolkit-a (biblioteka funkcija koje omogućavaju SOAP
komunikaciju između klijenata i veb servisa). IBM je izdao programski paket web
services Toolkit, koji, uz Apache SOAP, sadrži biblioteku funkcija koje podržavaju
pristup UDDI registru i rad s WSDL dokumentima. Uz biblioteke funkcija, Web
services Toolkit sadrži nekoliko programa namenjenih automatskom generisanju
programskog koda i dokumenata koji olakšavaju izradu veb-servisa.
4.4.2 Sigurnost informacionih sistema zasnovanih na SOA i veb-servisima
Sigurnost aplikacija jedan je od njihovih najvažnijih aspekata, kako pri njihovom
razvoju, tako i u toku njihove eksploatacije. Kada se govori o sigurnosti u oblasti
informacionih tehnologija, mogu se posmatrati tri razdvojene, ali gotovo podjednako
važne komponente: hardver sa komunikacionom infrastrukturom, softver i podaci.
Svaka komponenta ima svoju vrednost u okviru sistema i zahteva posebne tehnike
zaštite. Osjetljivost sistema, pretnje, napadi i kontrola mogu se jednim terminom nazvati
sigurnosnim aspektima. Osetljivost predstavlja sigurnosnu slabost sistema koja postoji u
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 122
proceduri, dizajnu ili samoj implementaciji, a koja može biti iskorišćena za zloupotrebu
sistema. Primera radi, neki sistem može da bude osetljiv po pitanju neovlašćene
manipulacije podacima zato što nema implementiran mehanizam utvrđivanja identiteta
korisnika pre omogućavanja pristupa podacima.
Pretnja predstavlja skup okolnosti koje potencijalno mogu da naprave štetu sistemu. Za
lice ili sistem koji pokušava da iskoristi ili iskorištava osetljivost sistema kaže se da vrši
napad na sistem. Kontrola je zaštitna mera, odnosno akcija, procedura, uređaj ili tehnika
koja uklanja ili u značajnoj meri umanjuje osetljivost sistema, čime onemogućava ili u
značajnoj meri otežava vršenje napada na sistem, odnosno sistem štiti od pretnji.
Generalno, sigurnosne pretnje mogu se podeliti u četiri grupe:
• presretanje - situacija u kojoj neovlašćena strana dobija pristup nekom resursu
sistema ili podacima koji se prenose;
• prekid (ometanje) - situacija u kojoj sistem, zbog aktivnosti napadača, postaje
nedostupan ili je njegovo korišćenje jako otežano za legitimne korisnike
sistema;
• modifikacija - situacija u kojoj neovlašćena strana ne samo da ima pristup
nekom resursu sistema, već nad tim resursom vrši i promene;
• fabrikovanje - situacija u kojoj neovlašćena strana izvrši fabrikaciju, odnosno
krivotvorenje nekog resursa sistema koji dalje legitimnim korisnicima
predstavlja kao legitiman resurs.
Primena SOA u projektovanju i realizaciji distribuiranih sistema donela je novine i u
pogledu sigurnosti. Ne samo da se javila potreba za razvojem novih sigurnosnih
koncepata i tehnika, već se ispostavilo da su mnoge do sada često korištene sigurnosne
prakse u slučaju SOA nedovoljne, pa čak i kontraproduktivne. Za razliku od ranijih
distribuiranih sistema, SOA podrazumeva slabu spregu. Isto tako, klijenti veb-servisa i
veb-servisi mogu da budu implementirani u različitim jezicima, i distribuirani na
različitim platformama. Zbog toga, prethodno veoma popularni centralizovani pristup
sigurnosti više nije moguć. SOA implementacija u vidu veb-servisa obično
podrazumeva da se komunikacija između klijenata i servisa vrši preko HTTP/HTTPS
(Hypertext Transfer Protocol i Hypertext Transfer Protocol Secure) transportnog
protokola, što isto tako može predstavljati dodatni sigurnosni problem [124].
4.4.2.1 Elementi i dimenzije sigurnosti veb-servisa
Pošto se veb-servisi zasnivaju na istim osnovnim HTTP i veb-arhitekturama kao i
uobičajene veb-aplikacije, podložni su sličnim pretnjama i ranjivostima. Sigurnost veb-
servisa bazira se na nekoliko važnih koncepata koji uključuju [171]:
• identifikaciju i autentifikaciju; identifikacija je provera identiteta korisnika,
procesa ili uređaja; autentifikacija je skup metoda za proveru istinitosti
saopštenog identiteta; identifikacija i autorizacija obično idu zajedno, radi
pouzdanijeg utvrđivanja identiteta kao preduslov za omogućavanje pristupa
resursima informacionog sistema;
• autorizacija; pristupna prava za korišćenje resursa informacionog sistema za
korisnike, procese ili uređaje čiji je identitet potvrđen na zadovoljavajući način;
• integritet; potrebno je obezbediti mehanizme kojima se može verifikovati da nije
došlo do neovlašćene-zlonamerne ili slučajne izmene podataka u toku prenosa,
obrade ili na mestu gde su sačuvani;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 123
• neporecivost; neporeciv dokaz slanja i prijema podataka i identiteta pošiljaoca;
• tajnost; podatke mogu videti samo legitimni korisnici; podaci moraju biti
nečitljivi za neautorizovane korisnike čak i ako nađu načina da zaobiđu
mehanizme za kontrolu pristupa; tajnost se najčešće postiže kriptovanjem
podataka;
• privatnost; privatnost je ljudsko pravo; opisuje pravo osobe na ograničenje
pristupu i korišćenju njenih ličnih podataka; lični podaci su potrebni
pojedincima ili organizacijama za pružanje usluga, ali oni se ne smeju
redistribuirati trećim stranama bez znanja i saglasnosti osobe na koju se odnose;
privatnost se može osigurati kombinacijom tehničkih i zakonskih sredstava.
Definisane su sledeće dimenzije sigurnosti kod veb-servisa [171]:
• sigurna razmena poruka (secure messaging);
• zaštita resursa (resource protection);
• pregovaranje o ugovorima (negotiation of contracts);
• upravljanje poverenjem (trust management);
• sigurnosna svojstva softvera veb-servisa (security properties).
Ove dimenzije obuhvataju prethodno navedene elemente sigurnosti. Svaka dimenzija je
od suštinskog značaja za razvoj sigurnih aplikacija korišćenjem veb-servisa.
4.4.2.2 Sigurna razmena poruka i zaštita resursa
Komunikacija sa javnim veb-servisima obavlja se pomoću poruka preko Interneta, koji
je poznat po svojoj nesigurnosti. Pri dizajnu SOAP protokola koji predstavlja
komunikacioni mehanizam za povezivanje veb-servisa, nije se vodilo računa o
sigurnosti. Otvorena priroda Interneta omogućava da SOAP paketi mogu biti lako
preuzeti, pročitani ili promenjeni od strane neovlašćenih osoba. Na raspolaganju je
nekoliko opcija kojima se može obezbediti sigurna razmena poruka sa veb-servisima
[124], [171]:
• HTTP preko SSL/TSL (HTTPS); pošto se za prenos SOAP poruka koristi HTTP
protokol, veoma je jednostavno sa HTTP preći na HTTPS.
• XML Encryption i XML Signature (XML kriptovanje i XML digitalni potpis).
XML sigurnosni standardi razvijeni od strane W3C dopuštaju da XML sadržaj
bude elektronski potpisan i kriptovan; pošto su sve SOAP poruke pisane u XML
formatu, kreatori veb-servisa mogu elektronski potpisati ili kriptovati bilo koji
deo SOAP poruke korišćenjem ovih standarda; problem je što ne postoji
standardni mehanizam za informisanje primaoca kako su ovi standardi
primenjeni na poslatu poruku;
• WS-Security. WS-Security je razvijen kao proširenje SOAP standarda, tako što
obezbeđuje mehanizam za korišćenje XML Encription i XML Signature pri
razmeni SOAP poruka; WS-Security definiše element SOAP zaglavlja u koje se
mogu uključiti sigurnosne informacije u XML dokument.
Kada su resursi javno dostupni, veoma je važno da budu adekvatno zaštićeni. Obično,
veb-servisi treba da budu dostupni samo ovlašćenim korisnicima tako da se zahteva
mehanizam za kontrolu pristupa. Da bi se izvršila kontrola pristupa, potrebno je da se
veb-servisi međusobno identifikuju i autentifikuju. Nekoliko različitih metoda je na
raspolaganju, uključujući autentikaciju na transportnom sloju, token autentikaciju preko
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 124
WS Security standarda SAML (Security Assertion Markup Language) potvrda ili drugih
token-a i SOAP autetifikaciono zaglavlje. Autentifikacija se za veb-servise najčešće vrši
preko prilagođenih implementacija, ali na raspolaganju je i OASIS standard XACML
(eXtensible Access Control Markup Language) čijom primenom se može eliminisati
vreme i troškovi potrebni za razvoj i testiranje sopstvenih rešenja za autentikaciju [171].
Izazovi sa kojima se suočavamo pri zaštiti resursa prevazilaze jednostavno pružanje
mehanizma za kontrolu pristupa. Cilj napadača ne mora da bude samo pristup veb-
servisu. Umesto toga, ciljevi napadača mogu da uključuju ometanje rada servisa, da
deluje kao „čovek u sredini“, prisluškivanje, lažno predstavljanje, ili čak koristeći
slabosti u implementaciji servisa u cilju kontrole platforme ili sistema u kome se servis
nalazi [124].
4.4.2.3 Referentni model sigurnosnih standarda veb-servisa
Zajednica za otvorene standarde koja je stvorila veb-servise razvila je niz sigurnosnih
standarda za veb-servise. Na slici 33. prikazan je referentni model koji povezuje
različite standarde sa različitim funkcionalnim slojevima za tipičnu implementaciju veb-
servisa. Ovi slojevi nisu hijerarhijski kao što su to za TCP/IP ili OSI referentni model.
Slika 33. Sigurnosni standardi za veb servise: Referentni model [124]
Standardi na mrežnom, transportnom i XML sigurnosnom sloju koriste se za zaštitu
poruka koje se prenose kroz komunikacionu mrežu. Sigurnosni standardi IPsec,
SSL/TLS (Secure Sockets Layer / Transport Layer Security), XML Encription i XML
Signature osiguravaju bezbednost SOAP poruka na različitim nivoima. SSL/TLS
obezbeđuju siguran tunel za prolaz SOAP poruka, dok XML Encription i XML
Signature obezbeđuju integritet, neporecivost i tajnost.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 125
Iznad XML sigurnosnog sloja postoje dve vrste standarda, jedni izgrađeni na osnovu
SOAP specifikacije i drugi samostalni standardi. Standardi za sigurnost poruka WS-
Security i WS-SecureConversation definišu korišćenje XML Signature i XML
Encription u cilju zaštite SOAP poruke, dok standardi za pouzdanu razmenu poruka
(Reliable Messaging) definišu protokole neophodne da osiguraju prijem poruke.
Standardi za kontrolu pristupa (Access Control) nisu jedinstveni za veb-servise,
XACML može da definiše politiku pristupa za bilo koji sistem a SAML se može
koristiti za definisanje tvrdnje u bilo kom okruženju. Standard WS-Policy u sloju polisa
dizajniran je za kreiranje dokumenata vezanih za polise i definiše veb-servis polise
neophodne za komunikaciju sa drugim servisima. Specifikacija ne definiše način
transportovanja ili pronalaženja polisa. Specifikacije za upravljanje bezbednošću
definišu upravljanje sertifikatima kao što su PKI sertifikati unutar SOA. Standardi za
upravljanje identitetom mogu da koriste standarde za kontrolu pristupa (Access
Control), standarde za polise (Policy) i SOAP standarde za pružanje usluga za
distribuciju i upravljanje identitetom korisnika i sertifikatima u SOA [124].
4.4.2.4 Sigurnosni standardi i zaštita veb-servisa
Postoji više sigurnosnih standarda, koji se nalaze u različitim fazama razvoja kod više
različitih organizacija, kao i više raznih implementacija u sličnim fazama dovršenosti.
Sa jedne strane, postojanje velikog broja sigurnosnih specifikacija je dobro jer je
neophodno za široko prihvatanje i korišćenje veb-servisa. Sa druge strane, veliki broj
specifikacija vezanih za sigurnost veb-servisa dovodi do konfuzije kod odabira
konkretnih specifikacija za korišćenje, odnosno zahteva veći broj ljudi u razvojnom
timu.
Dimenzija sigurnosti Zahtevi Odgovarajuće specifikacije
Razmena poruka
Tajnost i integritet WS-Security SSL/TLS
Autentifikacija WS-Security Tokens SSL/TLS X.509 sertifikati
Resursi
Autorizacija
XACML
XrML
RBAC, ABAC
Privatnost EPAL XACML
Odgovornost nema
Pregovaranje
Registri UDDI ebXML
Otkrivanje semantike SWSA OWL-S
Poslovni ugovori ebXML
Poverenje
Uspostavljanje
WS-Trust
XKMS
X.509
Posredovanje (Trust Proxying) SAML WS-Trust
Objedinjavanje
WS-Federation
Liberty IDFF
Shibboleth (lozinka)
Sigurnosna svojsta softvera
Polise WS-Policy
Sigurnosne polise WS-SecurityPolicy
Dostupnost WS-ReliableMessaging WS-Reliability
Tabela 8. Specifikacije i standardi za rešavanje sigurnosti SOA [124]
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 126
U tabeli 8. prikazano je kojim specifikacija i standardima mogu biti zadovoljeni
sigurnosni zahtevi veb-servisa.
Svaka sigurnosna dimenzija SOA ima jedan ili više sigurnosnih zahteva. Svaki zahtev
može biti podržan sa bilo kojim brojem standarda. Na primer SSL/TLS i WS-Security
pružaju podršku za:
- tajnost;
- integritet;
- autentikaciju za dimenziju sigurne razmene podataka.
4.4.2.5 Sigurnosna arhitektura
Slika 34. prikazuje arhitekturu veb-servisa u radnom okruženju. Komponente prikazane
arhitekture opisane su u daljem tekstu.
Slika 34. Veb-servis – sigurnosna arhitektura [124]
Sloj veb-servisa (WEB Service Layer) je sloj u kome su: softver veb-servisa, podaci koji
se obrađuju od strane veb-servisa, poruke koje veb-servis koristi za komunikaciju sa
drugim veb-servisima. Sloj radnog okvira veb-servisa (WEB Services Framework
Layer) sadrži komponente koje pružaju sigurnosne funkcije koje veb-servis koristi, ali
koje nisu deo koda samog veb-servisa. Veb-servisi takođe mogu da komuniciraju preko
sloja radnog okvira sa sigurnosnim servisima u sloju veb-servera (WEB Server Layer),
koji pruža uslugu povezivanja na mrežnom nivou i prateće usluge zaštite kao što su:
komunikacija u okviru sesije preko HTTP i HTTPS protokola, ali i zaštita sesije
pomoću SSL/TLS. Sloj veb-servera takođe obezbeđuje veb-servisima pristup spoljnim
sigurnosnim mehanizmima kao što su: kontrola pristupa bazama podataka, kontrola
pristupa sistemu datoteka, ostali sigurnosni servisi.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 127
4.4.2.6 Zaštita veb-servisa
Da bi se mogao zaštititi sistem zasnovan na veb-servisima, moraju se razumeti pretnje
sa kojima se suočava takav jedan sistem. Iako postoji mnoštvo sigurnosnih standarda i
tehnologija dostupnih za zaštitu veb-servisa, one ne moraju biti odgovarajuće ili
potrebne za određeni sistem ili pojedini servis. Iz tog razloga neophodno je razumeti
pretnje sa kojima se veb-servisi suočavaju tako da se za određeni sistem može utvrditi
koje su od tih pretnji realne da bi se izvršila zaštita veb-servisa od njih. Prema WS-I,
najčešće pretnje sa kojima se veb-servisi suočavaju jesu [171], [124]:
• izmena poruke; napadač umeće, uklanja ili menja podatke u okviru poruke u
cilju obmane primaoca;
• gubitak tajnosti; informacije unutar poruke postale su dostupne neovlašćenom
korisniku;
• falsifikovane poruke; lažne poruke koje šalje napadač, a za koje primalac veruje
da su upućene od legalnog pošiljaoca, a ne od napadača;
• čovek u sredini; napadač se postavi između učesnika u komunikaciji koji
razmenjuju poruke kao posrednik koga ni jedna strana nije svesna; napadač ima
mogućnost da pregleda i menja poruke koje prosleđuju;
• prevara identiteta (principal spoofing); napadač konstruiše i šalje poruku sa
takvim potvrdama da primalac veruje da poruka stiže od drugog pošiljaoca
(varijacija falsifikovane poruke);
• falsifikovanje potvrde o pravima (forged claims); napadač falsifikuje potvrde o
pravima da bi pristupio informacijama ili nekim drugim resursima za koje nije
autorizovan;
• reprodukcija poruke; napadač kopira ispravan zahtev i naknadno ga više puta
šalje u sistem; primer takvog napada bi moglo biti višestruko slanje kopije
zahteva za prenos novca u banci, što bi rezultovalo višestrukom sumom novca
na računu napadača;
• reprodukcija dela poruke; napadač u poruku umeće deo druge poruke u cilju
dobijanja dozvole za pristup informacijama ili resursima za koje nije ovlašćen;
deo druge poruke koji se umeće može biti sigurnosna potvrda iz neke druge
poruke;
• DoS (Denial of Service) napadi odbijanja servisa pokušavaju onemogućiti
sistem većim brojem zahteva nego što ih sistem može obraditi; kod običnih veb-
stranica, DoS napade je relativno lako detektovati; međutim, kod veb-servisa
detekcija takvih napada može biti teža; posebno kada veb-servis zahteva
relativno puno vremena za obradu; tada čak i mali broj zahteva može
onemogućiti sistem u daljem radu, a da pri tome automatizovani sistem detekcije
upada i ne detektuje napad.
Veb-servis je tehnologija bazirana na XML-u, i na nju se kao takvu odnose pravila
XML sigurnosti. Pošto se veb-servisi koriste kao distribuirane funkcionalnosti na
Internetu ili u lokalnoj mreži, na nju se odnose i pravila HTTP sigurnosti. Sledeći veb-
servisi i HTTP standardi mogu pružiti zaštitu od navedenih pretnji [171]:
• W3C XML Encription; upotrebljava se za šifriranje poruka i nudi tajnost cele
SOAP poruke ili njenog dela;
• W3C XML Signature; koristi se za digitalno potpisivanje poruka, čime se
obezbeđuje integritet poruke i autentifikacija pošiljaoca;
• WS-Security Tokens; sigurnosne potvrde se uključuju u poruku da bi primalac
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 128
mogao da identifikuje pošiljaoca i da odredi da li je ili nije autorizovan da izvrši
zahtevanu akciju;
• W3C WS-Addressing Ids; omogućava pošiljaocu poruke jedinstveni
identifikator za svaku poruku;
• IETF SSL/TLS; zaštićeni HTTP protokol za slanje i prijem SOAP poruka;
• SSL/TLS sa autentifikacijom klijenta; zahteva da se primalac i pošiljaoc
autetifikuju jedan drugom pre nego što uspostave razmenu poruka korišćenjem
zaštićenog HTTP protokola;
• IETF HTTP autentifikacija; omogućava da se korisničko ime i lozinka šalju kao
deo HTTP zaglavlja.
Izmena
poruke
Gubitak
tajnosti
Falsifiko-
vanje
poruke
Čove
k u
sredin
i
Prevara
identitet
a
Falsifikovanj
e potvrde o
pravima
Reprodukcija
dela poruke
Reprodu-
kcija
poruke
DoS
W3C
XML
Encrpytio
n
X X X X X
W3C
XML
Signature
X X X X X X
WS-
Security
Tokens
X X X
W3C
WS-
Addresin
g lds.
X
IETF
SSL/TLS X X X* X X* X* X
SSL/TLS
sa
autetifika
cijom
klijenta
X X X X X X X
IETF
HTTP
autentifik
acija
X X X
*Zaštita je pružena samo za poruke koje provajder servisa klijentu ali ne i obrnuto
Tabela 9. Pretnje i veb-servis standardi koji pružaju zaštitu od njih [228]
U Tabeli 9. je prikazano koji standardi pružaju zaštitu od kojih pretnji. Tabela pokazuje
da SSL/TSL i WS-Security preko XML Encription i XML signature pružaju sličnu
zaštitu [171].
4.4.2.7 Ugovori poverenja i upravljanje poverenjem
Jedan od primarnih ciljeva SOA jeste da olakša automatizaciju poslovnih procesa
omogućavajući servisima da automatski otkriju jedni druge i iskoriste ponuđene
funkcionalnosti. Da bi se olakšalo međusobno poslovanje različitih sistema, potrebno je
da su veb-servisi u stanju da automatski između sebe stvore i sprovode ugovor
međusobnog poslovanja i da ga se pridržavaju.
ebXML (electronic business eXtensible Markup Language) je jezik iz porodice XML
jezika. Definiše protokole komunikacija i sadržaj poslovnih dokumenata koji mogu da
se razmenjuju između poslovnih aplikacija u mreži. ebXML daje odgovore na pitanja:
kako obezbediti transportne mehanizme za poslovne dokumente; kako učiniti sadržaj
ovih dokumenata razumljivim; kako otkriti koji se tipovi poslovnih dokumenata mogu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 129
elektronski razmenjivati [124]. ebXML predstavlja katalizator u standardizaciji
elektronskih poslovnih rečnika (semantika), infrastrukture i poslovne dokumentacije.
ebXML doprinosi postizanju interoperabilnosti na sledeći način:
• korišćenjem XML kao opšteg standarda;
• pružanjem objedinjene semantike koja je svima dostupna;
• implementacijom ebXML, sistemi mogu da automatizuju metode i tokove svojih
elektronskih poslovnih transakcija, čime se povećava povezanost i efikasnost
usluga i omogućuje način za smanjenje cene i uvođenje tehnoloških inovacija.
ebXML standardi su previše složeni da bi se koristili za jednostavne veb-servise.
Obično, WSDL interfejs ili zapis u registru o pojedinačnom veb-servisu može se
smatrati implicitnim ugovorom između servisa, ali ne postoje standardi koji podržavaju
izvršavanje implicitnih ugovora. Istraživanja u oblasti koreografije veb-servisa treba da
razreše taj problem. Jedan od osnovnih principa bezbednosti je da učesnici u transakciji
veruju jedni drugima. Veb-servisi podržavaju različite modele poverenja koji mogu da
se koriste da bi se omogućilo veb-servisima da veruju u identitet subjekata unutar SOA.
Specifikacija WS-Trust opisuje modele poverenja koji omogućavaju veb-servisima da
sigurno sarađuju. Specifikacija WS-Federation obezbeđuje skupu organizacija da
uspostavi jedan virtualni sigurnosni domen, odnosno definiše mehanizam za
obezbeđenje informacija o identitetu, atributima, autentikaciji i autorizaciji kod servisa
koji se nalaze u različitim sigurnosnim domenima.
Upravljanje poverenjem trenutno je ograničeno na poverenje u identitet WB servisa.
Arhitekture modela poverenja koje se koriste su:
• Pairwise (mudri parovi) - svaki veb-servis ima sigurnosne informacije o svim
drugim ve-servisima u SOA sa kojima interaguje; problem je kada SOA sadrži
veliki broj veb-servisa; dodavanje novog veb-servisa predstavlja problem jer se
informacije o njemu moraju proslediti svim ostalim veb-servisima; ovaj model
je loš kod proširenja sistema;
• Brokered (posrednički) – veb-servisi koriste TTP (trusted third party), odnosno
posrednika od poverenja, veb-servisi treba samo da verifikuju identitet
posrednika poverenja umesto identiteta svih ostalih veb-servisa u SOA;
• Federated (objedinjeni). veb-servisi iz različitih organizacija mogu da sarađuju;
ovaj model se oslanja na prethodna dva (pairwise i brokered) dozvoljavajući
organizacijama da koriste sopstvene centralne posrednike poverenja, dok se
oslanja na pairwise ili posredničko poverenje između organizacija;
• Perimeter defense (odbrana na granici); XML gateway (prolaz) postavljen je
između pružaoca i korisnika veb-servisa; XML gateway se postavlja na granicu
SOA i ima funkciju zaštite unutrašnjih veb-servisa; u tom smislu veb-servisi
mogu biti dizajnirani bez mehanizama sopstvene zaštite; problem je ako napadač
uspe da preskoči XML gateway, svi unutrašnji veb-servisi koji nemaju sopstveni
sistem zaštite podložni su napadu.
4.4.3 Međusobno povezivanje veb-servisa
Kod servisno orijentisane arhitekture projektovanja softvera, aplikacije više nisu
monolitne celine, nego se sastoje od niza modularnih veb-servisa koji su gradivni
blokovi ove arhitekture. Veb-servis se može posmatrati kao jedna softverska funkcija
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 130
koja se po potrebi poziva od strane korisnika servisa. Sam po sebi, veb-servis ne
predstavlja kompletno poslovno rešenje. Povezivanjem više veb-servisa odgovarajućih
funkcionalnosti može se izgraditi efikasno, fleksibilno i sveobuhvatno poslovno rešenje
sposobno da se prilagođava raznim promenama (tehnologije, zakona, odnosa) u
okruženju u kome se koristi.
Postoje dva osnovna načina međusobnog povezivanja veb servisa u jedan složeniji
proces. To su orkestracija odnosno koreografija i prvenstveno se razlikuju po tome ko u
datom trenutku kontroliše izvršavanje procesa (Slika 35.).
Orkestracija podrazumeva jedan centralni proces koji preuzima kontrolu nad svim veb-
servisima (internim i eksternim) uključenim u poslovno rešenje i vrši koordinaciju
njhovog rada. Kod orkestracije veb-servisi nisu „svesni“ da su deo većeg procesa.
Centralni proces obezbeđuje neometano odvijanje poslovnog procesa - tok procesa.
Orkestracija veb-servisa je pružanje otvorenog, baziranog na standardima, pristupa za
povezivanje veb-servisa u cilju kreiranja poslovnih procesa višeg nivoa.
Koreografija nema centralnog koordinatora, već svaki uključeni veb-servis zna da je
učesnik većeg procesa, zna koji veb-servis treba da pozove nakon što uspešno završi sa
radom i šta treba da uradi ako dođe do greške. Koreografija u svojoj suštini je saradnja
veb-servisa.
Koreografija i orkestracija nisu koncepcije koje isključuju jedna drugu. Trenutno se više
koristi orkestracija, prvenstveno zato što je kod nje tačno poznato ko je u svakom
trenutku odgovoran za izvršenje procesa, pa je moguće iskoristiti postojeće veb-servise
koji i ne trebaju da znaju da su deo većeg procesa. Njihovu implementaciju ne treba
dodatno menjati/prilagođavati, već se koriste onako kako su dizajnirani. Ujedno, u
orkestraciji je lakše rešavati probleme ako nešto krene kako ne treba.
Poslovni proces se definiše kao niz aktivnosti koje se moraju izvršavati nekim
redosledom sa ciljem ostvarenja određene funkcionalnosti ili poslovnog cilja unutar
neke organizacione strukture (organ uprave, preduzeće). Definicija procesa opisuje
mrežu aktivnosti, njihove odnose, jedinice koje učestvuju uključujući aplikacije,
organizacije i ljude, tok podataka između aktivnosti i podatke koji zaokružuju proces,
kao što su uslovi potrebni za pokretanje procesa i kraj izvršavanja.
Slika 35. Koreografija i orkestracija [124]
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 131
Upravljanje poslovnim procesom (Business Process Management, BPM) pruža
infrastrukturu za dizajn, primenu, izvršavanje, održavanje i praćenje poslovnih procesa.
BPM sistemi (Business Process Management System, BPMS) pružaju potrebne alate za
tumačenje definicija procesa, modelovanje, razvoj i upravljanje procesima dok se
izvršavaju. BPMS raspoređuju određene stavke procesa odgovarajućim učesnicima, a
potrebni izvori se pozivaju na mestima gde je to potrebno.
BPM nudi strategije koje se koncentrišu na definisanje poslovnih procesa i njihovu
integraciju unutar i između organa uprave, a ne na razvoj čvrsto povezanih
individualnih struktura aplikacija. Integracija poslovnih procesa uključuje integraciju
nekoliko aplikacija pomoću različitih metapodataka, platformi i procesa. Veb-servisi su
prihvaćena tehnologija za interpretaciju poslovnih procesa. Jezik za definisanje
poslovnih procesa koristi se za opisivanje redosleda kojim se veb-servisi pozivaju s
ciljem izvršenja poslovne funkcije. Iako postoje različiti jezici za definisanje procesa
koje predlažu organizacije i dobavljači, još ne postoji standardan i univerzalno
prihvaćen jezik za opis poslovnih procesa. Svaki od tih jezika ima različite dobre i loše
strane kad je reč o izražavanju poslovnog procesa.
Standardi kao što su BPEL4W, WSCI i BPML dizajnirani su da pojednostave
međusobno povezivanje veb-servisa, da smanje cenu poslovnih procesa, i da povećaju
efikasnost i tačnost izvršenja poslovnih procesa. Bez zajedničkog skupa standarda,
svakoj organizaciji bilo bi ostavljeno da sama izgrađuje svoj sopstveni skup
odgovarajućih poslovnih protokola, ostavljajući jako malo fleksibilnosti za pravu
saradnju veb-servisa.
4.4.3.1 Web Service Coreography Interface (WSCI)
Web Service Coreography Interface (WSCI) je jezik zasnovan na XML-u predložen od
strane Intalio, SunMicrosystems-a, SAP-a i BEA Systems-a. Jezik opisuje tok poruka
razmenjenih između veb-servisa uključenih u interakciju pružajući na taj način
globalnu, porukama usmerenu definiciju procesa.
Slika 36. WSCI interfejs i veb-servis [124]
To je jezik koreografije, što znači da opisuje vidljivo ponašanje veb-servisa, a da se pri
tom ne bavi definisanjem izvršnog poslovnog procesa i osobina transakcija. WSCI
opisuje međusobne zavisnosti između operacija veb-servisa tako da klijent može
razumeti kako da stupi u interakciju sa odgovarajućim servisom u kontekstu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 132
predmetnog procesa, i kako bi mogao pretpostaviti kakvo će biti ponašanje tog servisa u
svakom trenutku životnog ciklusa procesa.
WSCI opisuje detalje ponašanja veb-servisa unutar procesa čije se izvršenje može
pokrenuti dobijanjem odgovarajuće poruke. Jedan WSCI interfejs opisuje razmenu
poruka sa tačke gledišta veb-servisa. Slika 36. prikazuje odnos između WSCI interfejsa
i veb-servisa.
4.4.3.2 Business Process Execution Language for Web Service (BPEL4WS)
Najčešći jezik za definisanje procesa je Business Process Execution Language for Web
Service (BPEL4WS), specifikacija koju su zajedno napisali IBM, BEA, Microsoft, SAP
i Siebel. To je jedinstveni jezik koji u sebi nosi osobine IBM-ovog Service Flow
Languagea (WSFL) i Microsoftovog XLANG-a. BPEL4WS koristi gramatiku
zasnovanu na XML-u sa ciljem kreiranja definicije procesa i smešten je kao sloj na vrhu
WSDL-a kako bi opisao potrebne komponente veb servisa za definisanje razmenjenih
poruka, izvršenih operacija i potrebnih tipova porta.
Jezik se koristi za podršku dva odvojena scenarija korišćenja:
• apstraktni proces koristi se za definisanje uloge poslovnog protokola i
identifikaciju ponašanja procesa razmene poruka između različitih strana
uključenih u protokol, skrivajući pri tom interno ponašanje;
• izvršni proces identifikuje stvarno ponašanje učesnika u poslovnoj interakciji
definišući redosled izvršavanja veb-servisa između svakog poslovnog partnera;
on definiše kako interakcija servisa između tih partnera se koordinira i uvodi
sistematične mehanizme za rešavanje pitanja poslovnih izuzetaka i grešaka u
procesu.
BPEL4WS definisanje procesa sadrži niz elemenata koji opisuju kontrolu toka,
asinhrone interakcije, korelacije, greške, kompenzacije i druge komponente unutar
poslovnog procesa. Definicija procesa definiše proces kad je reč o njegovoj interakciji s
partnerima. Partner može da pruži servis procesu, da od procesa zatraži servis, ili može
biti u dvosmernoj interakciji s procesom. Partnerski linkovi identifikuju oblik odnosa s
partnerom definišući tipove poruke i portova koji se koriste u oba smera.
Slika 37. identifikuje odnos između BPEL4WS procesa i njegovih partnera.
Slika 37. BPEL4WS proces i partneri
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 133
4.4.3.3 Business Process Managment Language (BPML)
Business Process Management Language (BPML) je meta jezik za opisivanje poslovnih
procesa. Specifikacija jezika je razvijena od strane Business Process Management
Initiative (BPMI.org), nezavisne organizacije angažovane od strane Intalio, Sterling
Commerce, Sun, CSC, i drugih. BPML je inicijalno dizajniran da podrži izvršavanje
poslovnih procesa u BMP sistemima.
BPML specifikacija pruža apstraktni model i XML sintaksu za prikaz izvršnih
poslovnih procesa i podržanih entiteta. BPML u sebi ne definiše neki određeni proces ili
aplikaciju procesa određene oblasti, već definiše apstraktni model i gramatiku za
izražavanje generičkih procesa. To omogućava da se BPML koristi u različite svrhe,
između ostalog za definiciju poslovnih procesa organa uprave ili preduzeća, definiciju
složenih veb-servisa, definiciju višestrane saradnje i dr.
BPML specifikacija zavisi od sledećih specifikacija: XML 1.0, XML- prostora imena,
XML šeme i XPath 1.0. Dodatno, podrška za uvoz i referenciranje definicije servisa
datog u WSDL 1.1 deo je specifikacije BPML.
4.5 Semantički veb
World Wide Web (WWW) sadrži ogromne količine informacija stvorenih od različitih
organizacija, zajednica i pojedinaca. Korisnici veba mogu vrlo lako pristupiti tim
informacijama i ostalim povezanim resursima preko odgovarajućih URI (Uniform
resource identifier) adresa. Jednostavnost upotrebe je glavni razlog popularnosti veba,
što je dovelo do toga da većina podataka nastaje i objavljuje se putem veba i na taj način
čini dostupnim korisnicima.
Jednostavnost upotrebe klasičnog veba ima svoju negativnu stranu, u potrazi za
informacijama često se dešava se umesto potrebnih i željenih pronađu nevažne i
nepovezane informacije. Time se pretraživanja korisnika svodi na dug i mukotrpan
posao jer se ne troši vreme samo na traženje potrebnih informacija, već korisnik gubi
vreme razdvajajući korisne informacije od nepovezanih i nevažnih. Kako bişmo
ilustrovali ovaj problem, pretpostavimo da tražimo nešto vrlo jednostavno, tipa „Petar
Petrović“. Kao rezultat pretraživanja dobićemo mnogo informacija, počevši od
Facebook korisnika, različitih tekstova (knjige, časopisi, vesti) u kojima se pojavljuju
ovo ime i prezime, pa možda i informacije o nestalim osobama.
Vrlo je česta pojava da korisnici prilikom pretraživanja, ukoliko pretraživanje ima više
značenja, dobiju mnogo različitih informacija. Ta višeznačnost se može odnositi i na
nacionalne jezike, a i na pojedini jezik. Ideja semantičkog veba je jednostavna, a to je
iskoristiti znanja, principe i tehnologije koje su u osnovi običnog veba, za novi veb koji
bi bio univerzalan medijum za razmenu podataka, informacija i znanja. Problem
postojećeg veba je što je oblikovan tako da njegov korisnik bude čovek, a ne mašina.
Potrebno je uvesti nov način predstavljanja podataka na vebu, koji će biti mašinski
čitljiv i omogućiti različitim programima da izdvoje značenje iz njih, a koji će pritom
biti dovoljno fleksibilan da pokrije različite primene i da omogući sopstveni razvoj.
Semantički veb [124] treba da bude proširenje postojećeg koje će omogućiti preciznije
definisanje semantike - značenja informacija i servisa na vebu, što bi računarima
omogućilo dublju analizu podataka - sadržaja. Za bolje shvatanje pojma sematičkog
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 134
veba česta je analogija u kojoj se današnji veb poistovećuje s jednom knjigom
(razumljivo ljudima), a semantički veb s bazom podataka (razumljivo računaru).
Slika 38. Arhitektura semantičkog vebaa sa preporukama W3C za standarde.
Sam koncept računaru razumljivih dokumenta u semantičkom vebu ne implicira bilo
kakvu vrstu veštačke inteligencije ili obrade ljudskog jezika (natural language
processing). Semantički veb samo naglašava mogućnost računara da rešava dobro
definisane probleme pomoću dobro definisanih operacija na postojećim dobro
definisanim podacima. Ideja je omogućiti opis informacija na vebu na način pogodan za
računarsku obradu. Kada jezik kojim je moguće opisati informacije postoji, na ljudima
je da opišu svoju internet stranicu ili servis tim jezikom. Kada se pojavi i neka druga
internet stranica opisana istim tim jezikom, one će moći da „razumeju“ jedna drugu i
međusobno razmenjuju informacije. Sa stanovišta podataka veoma je važno da se
podaci koji se razmenjuju ili prikazuju nedvosmisleno i opišu. Da bi se omogućila
funkcionalnost semantičkog veba, potrebno je obezbediti širok spektar standarda na
kojima se semantički veb bazira. Na slici 38. prikazana je arhitektura semantičkog veba
koja opisuje sve neophodne standarde.
Unicode i URI slojevi služe da omoguće korišćenje internacionalnog skupa znakova i
pruže način za identifikovanje objekata u semantičkom vebu. XML sloj sa prostorom
imena i šemom definicija osiguravaju integraciju definicije semantičkog veba sa ostalim
standardima baziranim na XML-u. Sa RDF-om i RDF Shemom (RDFS) moguće je
napraviti izjave o objektima sa URI-ovima i definisati rečnike kojima se može baratati
preko URI-ova. Ovo je sloj u kom se mogu dati tipovi resursima i linkovima. Ontološki
sloj podržava evoluciju rečnika i može definisati relacije između različitih koncepata
[183].
4.5.1 Ontologije
U svom izvornom filozofskom značenju ontologija predstavlja nauku o biću, o onome
što postoji. U računarstvu i informatici ontologija znači formalno definisani sistem od
pojmova i/ili koncepata i relacija između tih pojmova. Tačnije, ontologija je obrazac
podatka koji predstavlja koncepte unutar nekog domena i odnose između tih koncepata.
Koristi se za razumevanje objekata koji se nalaze unutar tog domena. Ontologije su
korišćene u veštačkoj inteligenciji, semantičkom vebu i softverskom inženjerstvu kao
oblik reprezentacije znanja o svetu ili nekog njegovog dela.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 135
Kod dve različite baze podataka mogu se koristiti različiti identifikatori za ono što je u
stvari isti pojam, kao što je npr. poštanski broj. Može se desiti da određeni program želi
da poredi ili kombinuje informacije iz dve različite baze podataka. U ovom slučaju
javlja se određeni problem. Naime, program mora da zna da su ova dva termina
upotrebljena tako da znače istu stvar. U idealnom slučaju, potrebno je da program
poseduje, odnosno ima način da otkrije takva zajednička značenja na kakve god baze
podataka naiđe. Rešenje ovog problema nudi jedna od osnovnih komponenata
semantičkog veba, kolekcija informacija koja se naziva ontologijama. Ontologija je
dokument ili datoteka koja formalno definiše relacije između termina. Najpoznatija i
najtipičnija vrsta ontologije za veb sastoji se od klasifikacije i skupa pravila
zaključivanja.
Klasifikacija definiše klase objekata i relacije između njih. Na primer, adresa može biti
definisana kao tip lokacije, a šifra grada može biti definisana tako da se odnosi samo na
lokacije. Klase, potklase i relacije između entiteta veoma su važne i korisne za
korišćenje na vebu. Može se izraziti veliki broj relacija između entiteta tako što se
dodeljuju osobine klasama dozvoljavajući potklasama da nasleđuju takve osobine. U
ovom primeru ako šifra grada mora biti tipa grad, a gradovi u opštem slučaju imaju veb-
sajtove, može se diskutovati o veb-sajtu kome je pridružena šifra grada čak i ako
nijedna baza podataka ne povezuje šifru grada direktno sa veb-sajtom. Pravila
zaključivanja u ontologijama donose još snage. Ontologija može izraziti pravilo, ako je
šifri grada pridružena šifri države, a adresa koristi tu šifru grada, onda ta adresa ima njoj
pridruženu šifru države. Program bi onda mogao lako zaključiti, na primer, da adresa
Narodne banke Srbije, koja je u mestu Beograd, mora biti u državi Srbiji i stoga bi
trebalo da je formatirana u skladu sa standardima Srbije. Računar ne ,,razume“ zaista
bilo koju od ovih informacija, ali može na osnovu klasifikacija i skupa pravila da
manipuliše ovim terminima daleko delotvornije na načine koji su korisni i koji imaju
značenje za čoveka - korisnika.
Ontologije mogu poboljšati funkcionisanje veba na razne načine. Na jednostavan način
mogu se upotrebiti da poboljšaju tačnost veb-pretraživanja. Program za pretraživanje
može tražiti samo one stranice koje referišu precizan pojam, umesto svih onih koje
koriste dvosmislene ključne reči. Naprednije primene koristiće ontologije da povežu
informacije na stranici sa pridruženim im strukturama znanja i pravilima zaključivanja.
Možemo reći da ontologiju čine rečnik i određena pravila i ograničenja u upotrebi
termina ovog rečnika.
4.5.1.1 Definicija ontologije i istorijska pozadina
U kontekstu računarskih i informacionih nauka, ontologija je kolekciju reprezentacionih
primitiva sa kojima se modeluje domen znanja ili diskurs. Reprezentacioni primitivi su
obično klase (ili kolekcije), atributi (ili svojstva) i relacije (ili međusobni odnosi između
članova klase). Definicije reprezentacionih primitiva uključuju informacije o njihovom
značenju i ograničenjima njihove logički konzistentne primene. U kontekstu sistema
baza podataka, ontologija se može posmatrati kao nivo apstrakcije modela podataka,
analogno hijerarhijskom i relacionom modelu, ali namena joj je modeliranje znanja o
individualnim članovima, njihovim atributima i njihovim relacijama sa drugim
individualnim članovima. Ontologije se obično specificiraju preko jezika koji
dozvoljavaju apstrakciju različitu od strukture podataka i implementacionih strategija; u
praksi, ontološki jezici su po opisnoj snazi bliži logici prvog reda nego jezicima koji se
koriste za modelovanje baza podataka. Stoga, kaže se da su ontologije na
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 136
„semantičkom“ nivou, dok su šeme baza podataka modeli podataka na „logičkom“ i
„fizičkom“ nivou. Zbog njihove nezavisnosti od modela podataka, koji su na nižem
nivou, ontologije se koriste za integrisanje heterogenih baza podataka, omogućavanje
interoperabilnosti između različitih sistema i specificiranje interfejsa nezavisnih servisa
baziranih na znanju. U standardima semantičkog veba [224], ontologije se tretiraju kao
eksplicitni sloj. Danas postoje standardni jezici i varijeteti komercijalnih i otvorenih
izvornih alata za kreiranje i rad sa ontologijama.
Termin „ontologija“ dolazi iz oblasti filosofije koja se bavi proučavanjem bića ili
postojanja (egzistencije). U filosofiji, o ontologiji se može govoriti kao o teoriji prirode
egzistencije (npr. Aristotelova ontologija uvodi primitivne kategorije, kao što su
materija i kvalitet, koje su pretpostavka za odgovor na Sve što je). U računarskim i
informacionim naukama, ontologija je tehnički termin koji označava artifakt koji je
projektovan za određenu svrhu, koji treba da omogući modelovanje znanja o nekom
domenu, stvarnom ili nestvarnom (imaginarnom). Termin je usvojen od strane ranih
istraživača u oblasti veštačke inteligencije (Artificial Intelligence), koji su prepoznali
primenjivost radova iz matematičke logike [116] i utvrdili da AI istraživači mogu
kreirati nove ontologije kao računarske modele koji omogućavaju određene vrste
automatskog zaključivanja [87]. Osamdesetih godina AI istraživači koriste termin
ontologija koji upućuje i na teoriju modelovanja realnog sveta (npr Naive Physics [87]) i
komponentu sistema znanja. Neki istraživači, na osnovu inspiracije iz filosofskih
ontologija, posmatraju računarsku ontologiju kao vrstu primenjene filosofije [197]. U
ranim devedesetim napori da se kreiraju interoperabilni standardi identifikovani su kao
tehnološki stek koji poziva ontološki sloj kao standardnu komponentu sistema znanja
[155]. Često citirane veb-strane i radovi [80] asocirani su sa tim naporima vezanim za
kreiranje definicije ontologije kao tehničkog termina u računarskim naukama. Ovaj rad
definiše ontologiju kao „eksplicitnu specifikaciju konceptualizacije“, odnosno, kao
„objekte, koncepte, i druge entitete za koje se pretpostavlja da egzistiraju u nekoj oblasti
od interesa i relacije koje se uspostavljaju između njih“. Dok termini specifikacija i
konceptualizacija mogu biti debatovani, dotle su osnovne tačke ove definicije ontologije
sledeće:
• ontologija definiše (specificira) koncepte, relacije i druge činioce koji su
relevantni za modelovanje domena;
• specifikacija uzima oblik definicija reprezentacionog rečnika (klase, relacije itd),
koje obezbeđuju značenje rečnik i formalna ograničenja na njihovom
koherentnom korišćenju.
Jedini prigovor ovoj definiciji je da je preširoka, ali omogućava širok spektar
specifikacija, počev od prostih rečnika (glossary) do logičkih teorija formalizovanih
preko predikatskog računa [195]. Ali ovo važi za modele podataka određene složenosti,
na primer, pojedinačna tabela baze podataka i njene kolone je ipak instanca relacionog
modela podataka. Pragmatičnije gledano, može se reći da je ontologija i alat i proizvod
inženjeringa i definisana svojom namenom. Iz te perspektive, ono što je bitno u
korišćenju ontologije jeste da obezbedi reprezentacionu mašineriju kojom se
instanciraju modeli domena u bazi znanja, da omogući upite kao servise zasnovane na
bazi znanja i predstavi rezultate rade takvih servisa. Na primer, API servis za
pretraživanje može ponuditi ne više do rečnika tekstualnih termina kojim je formulisan
upit, i može raditi kao ontologija. S druge strane, današnji W3C standardi semantičkog
veba sugerišu specifičan formalizam za kodiranje ontologija (OWL) u nekoliko
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 137
varijeteta koji se razlikuju u opisnoj snazi [117]. Odavde proizilazi da je ontologija
specifikacija apstraktnog modela podataka (konceptualizacija domena) koja je
nezavisna od njege partikularne forme. Ovde se ontologija diskutuje u kontekstu
primene u inženjeringu softvera i baza podataka. Ontologija specificira vokabulari koji
čine određene tvrdnje, koje mogu biti ulazi ili izlazi agent znanja (kao što je softverski
program). Kao specifikacija interfejsa, ontologija obezbeđuje jezik za komunikaciju sa
agentom. Agent koji podržava taj interfejs nije u obavezi da koristi termine ontologije
pri internom kodiranju svoga znanja.
4.5.1.2 Primena ontologija
Ontologijom se formalno definiše skup termina koji se koriste da bi se opisao i
predstavio određeni domen, oblast znanja. Ontologije koriste ljudi, baze podataka i
aplikacije koje imaju potrebu za zajedničkim korišćenjem informacija iz datog domena.
Domen može biti specifična predmetna oblast ili oblast znanja poput medicine,
proizvodnje uređaja, upravljanja nekretninama, upravljanja vladinim servisima [216],
upravljanja finansijama. Istovremeno, ontologije mogu koristiti i određeni alati kojima
se unapređuju veb-usluge, kao što su precizni veb-pretraživači, inteligentni softverski
agenti i alati za upravljanje znanjem. U odnosu na znanje koje se modeluje u okviru
ontologije, dolazi se i do opštih karakteristika ontologija, tako da razlikujemo sledeće
tipove ontologija:
• ontologije zasnovane na pravilima (generičke ontologije) - definišu
terminologiju i koncepte koji su od značaja za krajnjeg korisnika, bez obzira da
li je krajnji korisnik osoba ili korisnička aplikacija;
• procesne (aplikativne) ontologije - definišu ulaze, izlaze, ograničenja, veze,
pojmove i redosled informacija koji je značajan za određeni proces ili skup
procesa. Obično sadrži sve neophodne podatke za modelovanje pojedinačnih
domena znanja;
• domenske (klasične) ontologije - definišu terminologiju i koncepte značajne za
pojedinačne oblasti interesovanja (npr. elektronika, medicina, mehanika…);
• interfes ontologije - definišu strukturu i sadržaj ograničenja značajnih za
određene interfejse (npr., API (Application Programming Interface), baze
podataka...);
• više ontologije.
Pri definisanju neke ontologije, neophodno je opisati sledeće vrste koncepata:
• klase - kojima se predstavljaju različiti domeni interesovanja;
• veze - koje mogu postojati između klasa;
• karakteristike (atributi) – karakteristike klasa;
• ograničenja atributa – služe za proveru konzistentnosti postavljenih rešenja, ali i
za dalje unapređenje pretraživanja i dolaženje do novih saznanja.
Korišćenjem ontologija omogućuje se [8]:
• zajedničko korišćenje razumljivih struktura informacija između ljudi i/ili
softverskih agenata;
• mogućnost ponovnog korišćenja domena znanja;
• dokazivanje tačnosti pretpostavki;
• odvajanje domena znanja od operativnog znanja;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 138
• analiza domena znanja.
Korišćenjem ontologija pretraživačke mašine prelaze sa tekućeg pristupa pretraživanja
po ključnoj reči na pronalaženje sadržaja koji su sintaktički različiti ali semantički
predstavljaju slične reči.
Primer upotrebe ontologija na vebu mogu biti sajtovi za elektronsku trgovinu gde su
ontologije potrebne jer omogućavaju [124]:
• mašinski zasnovanu komunikaciju između prodavca i kupca;
• vertikalnu integraciju tržišta, kada kompanija proširuje svoje poslovanje
na nove oblasti koje pripadaju istoj proizvodnoj liniji;
• upotrebu semantički istih termina koji se koriste na različitim prodajnim
mestima.
4.5.2 Primena ontologija u integraciji sistema
Korišćenje ontologija kao mogućeg rešenja za problem semantičke interoperabilnosti
intenzivno se istražuje. Ontologije se koriste za reprezentovanje semantičkih sadržaja
izvora podataka koji se deklarišu u formi koncepata, njihovih atributa i semantičkih
veza. U gotovo svim ontološki zasnovanim integracionim pristupima ontologije se
koriste za eksplicitni opis semantike poslovnih objekata. Generalno, mogu se
identifikovati tri različita pristupa primene ontologije: centralizovani pristupi (pristupi
zasnovani na jednoj globalnoj ontologiji), decentralizovani pristupi (pristupi zasnovani
na višestrukim ontologijama) i hibridni pristupi.
U centralizovanim pristupima, koji se zasnivaju na medijatorskoj arhitekturi, kao
zajednički model podataka koristi se ontologija. Globalna ontologija reprezentuje skup
koncepata koji egzistiraju u određenom domenu i pomoću njih opisuje semantičke
sadržaje nekog poslovnog domena. Pristup podacima formuliše se u terminologiji
globalne ontologije, a realizuje nad lokalnim izvorima podataka preko jasno definisanih
semantičkih preslikavanja između globalne ontologije i šema lokalnih izvora podataka,
slika 39. Korisnički upiti definišu se u terminima opisanih koncepata, a dobijeni
odgovori na postavljene upite reprezentuju se preko instanci istih koncepata.
Slika 39. Integracija preko jedne zajedničke ontologije
Poznati pristup ove vrste ontološke integracije je SIMS (Sand Information Management
for Decision Systems). SIMS model aplikacionog domena opisan je u LOOM
deskriptivnom logičkom jeziku. Ovaj model koristi se za opis sadržaja izvora podataka
prvenstveno pomoću uspostavljanja is-a veza između lokalnih i globalnih koncepata. U
SIMS-u se koriste dva jezika za definisanje upita: LOOM i podskup SQL-a koji sadrži
operacije projekcije, selekcije i spajanja.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 139
Pristupi koji se zasnivaju na jednoj globalnoj ontologiji mogu se primenjivati na
integracione probleme, gde svi izvori podataka koji se integrišu obezbeđuju približno
isti pogled na specifični domen. Međutim, ako jedan izvor podataka ima različit pogled
na domen, tj. obezbeđuje drugi nivo granularnosti, usaglašavanje takvog izvora
podataka sa globalnom ontologijom postaje težak zadatak. Takođe, pristupi koji se
baziraju na jednoj globalnoj ontologiji osetljivi su na izmene u izvorima podataka jer
impliciraju promene u globalnoj ontologiji i preslikavanjima sa lokalnim izvorima
podataka. U decentralizovanim pristupima koji se zasnivaju na višestrukim
ontologijama svaki izvor podataka opisan je pomoću sopstvene lokalne ontologije i
između svakog para lokalnih ontologija definisana su ontološka preslikavanja koja
identifikuju semantički slične ili ekvivalentne izraze iz različitih ontologija. Svaki izvor
podataka razvija se nezavisno od drugih izvora i njihovih ontologija, slika 40. U
ovakvoj ontološkoj arhitekturi izmene izvora podataka (dodavanje novih, modifikacija
ili izbacivanje postojećih) jednostavne su i lake.
Slika 40. Integracija zasnovana na višestrukim ontologijama
Prednosti ovog pristupa su jednostavnost i fleksibilnost: ne zahteva se globalna
ontologija i ontološkim preslikavanjima se upravlja lokalno. Međutim, odsustvo
zajedničke ontologije čini proces poređenja različitih ontologija ekstremno teškim. Za
prevazilaženje ovog problema uvedena su međuontološka mapiranja. Međutim, u praksi
nije lako definisati međuontološka preslikavanja jer se mogu javiti različiti problemi
vezani za semantičku heterogenost. Ovi pristupi, uopšteno govoreći, nisu previše
skalabilni, jer se zahtevaju O(n2) ontološka mapiranja, gde je n broj ontologija. Zbog
toga su nepodesni za velike ontološke sisteme (kao što je to, na primer, semantički veb).
Jedan od sistema koji koristi decentralizovani ontološki pristup jeste OBSERVER. Ovaj
ontološki integracioni sistem obezbeđuje jedinstvenu platformu za pretraživanje
višestrukih ontologija. Ontologije se koriste za preslikavanja izraza u korisničkim
upitima u odgovarajuće izraze definisane u drugim ontologijama. Međuontološka
preslikavanja definisana su pomoću posebne komponente IRL (Inter Ontological
Relationship Manager). Korisnik bira jednu od ontologija iz sistema (koje su smeštene
na ontološkom serveru) i formuliše upit nad izabranom ontologijom. Ontološke
translacije korisničkog upita obavljaju se preko IRL komponente. OBSERVER koristi
deskriptivnu logiku za reprezentovanje i procesiranje ontologija.
U hibridnim ontološkim pristupima pokušavaju se prevazići nedostaci pristupa
zasnovanih na jednoj zajedničkoj ontologiji ili višestrukim ontologijama. Slično
pristupima koji se zasnivaju na višestrukim ontologijama semantika svakog izvora
podataka opisana je pomoću njegove sopstvene ontologije. Za upoređivanje lokalnih
ontologija koristi se zajednički rečnik, slika 41. Zajednički rečnik definiše osnovne
izraze domena koji se mogu kombinovati u cilju opisa mnogo složenije semantike izraza
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 140
u lokalnim ontologijama. Svaki izraz iz lokalnih ontologija opisuje se pomoću osnovnih
koncepata tako da je upoređivanje izraza lakše nego u višestrukim ontologijama.
Slika 41. Hibridni ontološki pristup integraciji
Ovaj pristup kombinuje prednosti oba prethodna pristupa: reducira broj preslikavanja i
omogućava fleksibilno upravljanje preslikavanjima u lokalnom kontekstu. Prednost
hibridnog pristupa je u tome što se novi izvori podataka mogu lako dodati bez
modifikacije u preslikavanjima ili zajedničkom rečniku. Korišćenje zajedničkog rečnika
omogućava poređenje lokalnih ontologija. Nedostatak hibridnih pristupa je u tome što
se postojeće ontologije ne mogu lako ponovo koristiti jer su u vezi sa zajedničkim
rečnikom [6].
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 141
5 Razvoj modela interoperabilnog elektronskog
poslovanja platnih sistema zasnovanog na ontologijama
Svaka poslovna transakcija indukuje jednu ili više finansijskih transakcija (FT). Vrlo je
čest slučaj da se poslovna transakcija u nekom segmentu ne naplaćuje poslovnom
partneru. I interne poslovne transakcije imaju svoju cenu koja se, po pravilu, ne
naplaćujuje ali se prilikom izračunavanja ukupne cene poslovnog procesa i ona uzima u
obzir kao trošak. U elektronskom poslovanju generisanjem eksternih finansijskih
transakcija vrši se automatizacija poslovnih procesa [73]. I u elektronskom poslovanju
generisanjem internih finansijskih transakcija za naknadu troškova procesiranja može se
izvršiti automatizacija kalkulacije ukupnih troškova poslovnih procesa.
5.1 Procesi elektronskog poslovanja platnog sistema
Za model sistema elektronskog poslovanja platnih sistema (EPPS) od interesa su
instrumenti plaćanja, podaci, učesnici i procesi [17]. Sistemi plaćanja na osnovu kojih
nastaje finansijska transakcija i konkretna okruženja u kojima je nastala finansijska
transakcija nisu predmet ovog rada.
-
1. Legalizacija procesa EPPS
P
O
D
R
E
Đ
E
N
I
S
I
S
T
E
M
I
N
A
D
R
E
Đ
E
N
I
S
I
S
T
E
M
I
2. Priprema za izvršenje FT
3. Akvizicija informacija o FT
4. Pretprocesiranje FT
5. Procesiranje FT
6. Postprocesiranje FT
7. Priprema za distribuciju
8. Prosleđivanje poruke
Slika 42. Sažeti model EPPS
Osnovni procesi elektronskog poslovanja platnih sistema su [95]:
1. proces legalizacije razmene i procesiranja finansijskih transakcija:
1.1. proces stvaranja zakonskog okruženja za primenu instrumenata platnog
prometa;
1.2. proces stvaranja poslovnog okruženje za primenu instrumenata platnog
prometa;
2. proces pripreme izvršenja finansijske transakcije;
3. proces akvizicije informacija o finansijskoj transakciji;
4. proces pretprocesiranje finansijske transakcije;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 142
5. proces procesiranja finansijske transakcije;
6. proces postprocesiranja finansijske transakcije;
7. proces pripreme za distribuciju;
8. proces prosleđivanja poruke.
Na slici 42. prikazan je sažeti model elektronskog poslovanja platnih sistema.
5.1.1 Instrumenti platnog prometa
Instrumenti platnog prometa su [133], [154]:
• nalog za prenos;
• nalog za naplatu;
• nalog za uplatu;
• nalog za isplatu.
Nalog za uplatu i nalog za isplatu trenutno su gotovinski, odnosno materijalni i ne
postoji globalni model dematerijalizacije novca ako se izuzmu lokalne inicijative [24].
U tom kontekstu može se razmatrati emiter novčanih vrednosti, u većini slučajeva
centralna banka države i emisija novca koja se odlikuje brojem novčanica koje emituje,
vrednošću novčane jedinice i identifikacijom novčane jedinice, odnosno serijskim
brojem novčanice i vlasnikom emitovane jedinice.
Ukoliko emiter novčane vrednosti vodi evidenciju tokom životnog ciklusa novčane
jedinice o novčanoj jedinici i vlasniku novčane jedinice, može se u tom kontekstu i
nalog za uplatu i nalog za isplatu posmatrati u svetlu elektronskog poslovanja platnih
sistema. Po pitanju naloga za prenos u elektronskom poslovanju platnih sistema
standardizovan je pod nazivom „Credit Transfers“ ili pod drugim nazivom „Direct
Credit“, a nalog za naplatu je standardizovan pod nazivom „Direct Debit“ ili pod
drugim domaćim uobičajenim nazivom „direktno zaduženje“ [140].
5.1.2 Učesnici u sistemu elektronskog poslovanja platnih sistema
Učesnici u sistemu elektronskog poslovanja platnih sistema su [154]:
• Retail korisnici (učesnici u prometu „na malo“): pravna i fizička lica;
• druge finansijske institucije (učesnici u prometu „na veliko“): agenti plaćanja,
posredničke kuće, klirinške kuće za neto poravnanje finansijskih transakcija,
kuće za poravnanje hartija od vrednosti, kreditni biroi, osiguravajuća i
reosiguravajuća društava, brokerske kuće i ovlašćena lica i institucije za
obavljanje poslova platnog prometa;
• banke kod kojih su deponovana sredstva pravnih, fizičkih lica i drugih
finansijskih organizacija na osnovu kojih se obavljaju finansijske transakcije tih
učesnika;
• centralne banke sa sistemima za bruto i neto poravnanje finansijskih transakcija:
RTGS sistem, klirinški sistem, sistemi za poravnanje međunarodnih finansijskih
transakcija;
• međunarodne finansijske institucije: inostrane klirinške kuće, inostrane banke
koje su učesnici u međunarodnim sistemima za poravnanje, inostrane
međunarodne organizacije;
• međunarodni fondovi među kojima je i međunarodni monetarni fond MMF.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 143
5.1.3 Osnovni procesi elektronskog poslovanja platnih sistema
Proces legalizacije razmene i procesiranja finansijske transakcije sastoji se od
aktivnosti, prikazanih na slici 43. i slikama sa dijagramima aktivnosti slika 44. i slika
45:
a.) Procesa stvaranja okruženja za zakonsku primenu instrumenata platnog
prometa, odnosno potpisivanja odgovarajućih zakonskih dokumenata koji definišu
proces plaćanja, na primer:
• ugovora sa bankom o otvaranju računa;
• potpisivanja prihvatanja cenovnika platnih usluga;
• potpisivanja protokola plaćanja;
• potpisivanja potvrde o preuzimanju potrebnih sredstava za izvršavanje iniciranja
transakcije;
• potpisivanje ugovora sa poslovnim partnerom o mogućnostima i uslovima
iniciranja finansijske transakcije direktnog zaduženja i drugo.
b.) Procesa stvaranja okruženja za poslovnu primenu instrumenata platnog
prometa, odnosno definisanja:
• kanala za razmenu finansijskih transakcija;
• načina sigurne razmene finansijskih transakcija;
• neporecive razmene finansijskih transakcija;
• potpisivanja protokola o korišćenju informatičkih resursa;
• prihvatanja tarifa za razmenu finansijskih transakcija.
1. Legаlizacija procesa razmene i procesiranja FT
1.1. Stvaranje zakonskog okruženja za primenu instrumenata platnog prometa
1.2. Stvaranje poslovnog okruženja za primenu instrumenata platnog prometa
1.1.2. Potpisivanje
ugovora
1.1.3. Potpisivanje
cenovnika za FT
1.1.1. Potpisivanje
protokola
1.1.4. Preuzimanje alata
za izvršavanje FT...
1.2.1. Definisanje
kanala razmene FT
1.2.2. Definisanje
bezbednosti i
neporecivosti
1.2.3. Potpisivanja
protokola o IT
resursima
1.2.4. Potpisivanja
cenovnika razmene FT...
Podređeni
sistemi
Nadređeni
sistemi
Slika 43. Poslovni procesi plaćanja: Legalizacija
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 144
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 145
Proces pripreme izvršenja finansijske transakcije, slika 46. i dijagram aktivnosti na
slici 47, za nadređene i podređene finansijske sisteme se sastoji od:
• otvaranja komunikacionih kanala za prihvatanje informacija o finansijskim
transakcijama;
• potrebne prijave na nadređene sisteme;
• prihvatanja prijave na sistem podređenih sistema za razmenu informacija o FT;
• verifikacije učesnika za razmenu;
• prihvatanja osnovnih informacija potrebnih za razmenu i procesiranje;
o dnevne tarife;
o kursne liste;
o druge servisne informacije.
-
2. Priprema za izvršenje
finansijske transakcije
2.2. Prijava na nadređeni sistem
2.3. Prihvatanje prijave podređenog sistema
2.1. Otvaranje komunikacionih kanala
2.4. Verifikacija učesnika
2.5. Razmena servisnih informacija
Nadređeni sistemi
Podređeni sistemi
Slika 46. Poslovni procesi plaćanja: Priprema za izvršenje FT
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 146
Proces akvizicije informacija o finansijskoj transakciji, slika 48. i dijagram
aktivnosti na slici 49, sastoji se od:
• prijema odgovarajuće standardizovane poruke koja u sebi sadrži:
o informacije o sebi;
o sadržanim instrukcijama;
o transakcijama;
• skladištenja originalne poruke sa odgovarajućim elementima;
o za proveru pošiljaoca;
o sadržaja poruke;
• dekripcija (dešifrovanje) poruke;
• provere pošiljaoca poruke;
• provere nepromenjenosti sadržaja poruke;
• provere sintakse poruke;
• provere semantike poruke;
• provere osnovnih poslovnih pravila vezanih za primljenu poruku;
• slanja potvrde
o prijema ukoliko je poruka u redu ili odbijanju poruke sa razlogom
odbijanja.
-
3. Akvizicija informacija o FT
3.2. Skladištenje originalne poruke
3.3. Dekripcija poruke
3.1. Prijem poruke
3.5. Generisanje potvrde prijema
3.4. Provera poruke
3.4.4. Provera osnovnih poslovnih pravila
3.4.1. Provera pošiljaoca poruke
3.4.2. Sintaksna provera poruke
3.4.3. Semantička provera poruke
Slika 48. Poslovni procesi plaćanja: Akvizicija informacija o FT
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 147
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 148
-
4. Pretprocesiranje FT
4.2. Provera poslovnih pravila
4.3. Skladištenje podataka za procesiranje
4.1. Semantička provera
4.4. Generisanje stavki
4.4.1. Stavke za praćenje
4.4.2. Stavke za statistiku
4.4.3. Stavke za izveštavanje
-
Slika 50. Poslovni procesi plaćanja: Pretprocesiranje FT
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 149
-
5. Procesiranje FT
5.2. Izvršenje zadatih operacija za FT
5.3. Skladištenje rezultata procesiranja FT
5.1. Izdvajanje podataka o FT
4.4. Generisanje stavki
4.4.1. Stavke za praćenje
4.4.2. Stavke za statistiku
4.4.3. Stavke za izveštavanje
-
Slika 52. Poslovni procesi plaćanja: Procesiranje FT
Proces procesiranje finansijskih transakcija uključuje izvršenje potrebnih operacija
nad informacijama o transakciji, slika 52. i dijagram aktivnosti na slici 53, i sastoji se
od:
• izdvajanja podataka finansijske transakcije;
• skladištenja podataka o finansijskoj transakciji;
• izvršenja odgovarajućeg skupa operacija nad finansijskim transakcijama koje
zavise od:
o vrste organizacije u kojoj se finansijska operacija obavlja;
o zakonske regulative koja propisuje operacije koje se trebaju obaviti;
o položaja institucije koja obavlja finansijsku transakciju;
o funkcije institucije koja obavlja finansijsku transakciju;
• skladištenja rezultata procesiranja finansijske transakcije i u zavisnosti od tipa
finansijske transakcije i vrste procesiranja koja:
o može biti izvršena odmah ili
o može biti odložena;
• generisanja stavki za potrebe praćenja
o izvršavanja finansijske transakcije;
o statistike;
o izveštavanja o finansijskim transakcijama.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 150
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 151
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 152
-
8. Prosleđivanje poruke
8.2. Prijem potvrde
8.1. Iniciranje slanja poruke
8.3. Označavanje ispravnosti poruke u sistemu
Podređeni
sistemi
Nadređeni
sistemi
-
Slika 57. Poslovni procesi plaćanja: Prosleđivanje poruke
Proces prosleđivanja informacija o finansijskoj transakciji prikazan na slici 57. i
kroz zajednički dijagram aktivnosti procesa pripreme za distribuciju i procesa
prosleđivanja na slici 58, sastoji se od:
• iniciranja slanja;
• prijema poruke kod primaoca;
• potvrde o
o prihvatanju poruke o pri čime se proces završava;
o ili potvrde o odbijanju poruke;
kada se originalna poruka o finansijskoj transakciji označava kao
poruka sa greškom;
inicira proces reklamacije u svom sistemu u odnosu na poruku o
grešci.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 153
Prikaz modela elektronskog poslovanja platnih sistema prikazan je na slici 59. i sačinjen
od podmodela opisanih u prethodnom tekstu.
Slika 59. Struktura modela EPPS
Poslovni procesi plaćanja odvijaju se po termin planu. Termin plan može da sadrži i
dodatna procesiranja finansijskih transakcija koja su asinhrona u odnosu na akviziciju
poslovnih transakcija, kao što je, na primer, zakonska obaveza slanje izvoda. Slanje
izvoda započinje u procesu Procesiranje FT, a završava se procesom Prosleđivanje
poruke.
Model EPPS može da se sagleda, osim sa logičkog stanovišta, i sa fizičkog stanovišta.
Model je zasnovan na sledećim informatičkim resursima:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 154
• hardverskoj infrastrukturi;
• komunikacionoj infrastrukturi;
• osnovnom sistemskom softveru;
• baznim sistemskim komponentama;
• aplikativnim komponentama;
• sistemima za upravljanje bezbednošću;
• sistemima za monitoring;
• sistemima za upravljanje;
• sistemima za nadzor;
• sistemima za fizičku zaštitu;
• sistemima za izveštavanje;
• Help Desk sistemom;
• sistemskom podrškom;
• pomoćnim sistemima za obezbeđivanje neprekidnog napajanja električnom
energijom.
Registraciono teloSistem za razmenu poruka
CA – PKI infrastruktura Drugi sistemi elektronskog poslovanja organizacije
Elektronsko poslovanje
platnih sistema
Slika 60. Interakcija EPPS sa drugim osnovnim sistemima
Sistem elektronskog poslovanja platnih sistema je u interakciji sa sledećim sistemima,
prikazanim na slici 60:
• sistemom za razmenu poruka;
• registracionim telom;
• infrastrukturom za podršku PKI i sertifikacionim telom;
• drugim poslovnim sistemima elektronskog poslovanja organizacije.
Prilikom modeliranja sistema elektronskog poslovanja platnih sistema posebnu pažnju
je potrebno posvetiti elementima kontinualnog poslovanja i na adekvatan način
obezbediti sajt u slučaju iznenadnog prekida rada osnovnog sajta i sajt u slučaju
nemogućnosti rada osnovnog sajta u katastrofalnim uslovima. Napredniji sistemi
elektronskog poslovanja platnih sistema sadrže još jednu instancu osnovnog sistema na
kome mogu da se izvode operacije u laboratorijskim uslovima.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 155
5.2 Model podataka
Model podataka proizilazi is strukture standardizovane poruke [17], [44]. Izučavanjem
strukture ISO20022 poruka [98] SWIFT ML standardnih poruka [205],[207], ISO20022
poruka preslikanih u XML strukturu, EANCOM [15], [81], standardnih poruka lanaca
snabdevanja [54], [82] meteo poruka (poruka za akviziciju i distribuciju
hidrometeoroloških podataka), TWIST poruka [213] koje su agregacija finansijskih
transakcija i transakcija sistema lanaca snabdevanja i drugih, uočena je analogna
struktura poruke. Model poruke može biti predstavljen XML strukturom (XSD šemom).
Struktura XML šeme koja se preslikava u relacionu strukturu baze podataka predstavlja
generički model podataka koji u zavisnosti od upotrebe može da se transformiše u
ekvivalentne strukture. U nastavku je prikazana generička struktura poruke sa
odgovarajućim elementima XML šeme koji se preslikavaju u atribute relacione
strukture [18]. Navedena struktura poruke, prikazana na slici 61, može se koristiti kod
opisivanja elemenata sistema.
Poruke nastaju u sistemima gde postoje potrebe razmene informacija o poslovnim
transakcijama. Informacije o transakcijama se primaju iz različitih segmenata –
podsistema, ali se vrši razmena i između različitih poslovnih tipova sistema. Put
transakcije kod svih učesnika u procesima plaćanja isti, determinisan adresom i
poslovnim sadržajem poruke.
Slika 61. Struktura finansijske poruke
Na slici 61. prikazana je struktura finansijske poruke [14]. Poruka se sastoji od svog
zaglavlja i jezgra, odnosno tela poruke. U opštem slučaju, poruka može da ima više
jezgara, koji čak ne moraju da pripadaju ni istim standardima poruka. Svako jezgro
poruke može da se sastoji od jednog ili više dokumenata. Dokumentaciono jezgro sadrži
informacije koje ga i čine dokumentom: na jedinstven način može se odrediti
verodostojnost dokumenta, onog koji je taj dokument izdao, zbog čega je taj dokument
izdat i slično. Dokument se u suštini sastoji od instrukcija (CRUD) sa kojim se kreira
nova instanca nekog poslovnog objekta (create), daje informacije o nekom poslovnom
objektu (read), vrši njeno ažuriranje (update) ili povlačenje (delete) [27]. Transakcija se
sastoji od operacija koje treba obaviti da bi se ona ostvarila. Instrukcija može biti
proizvoljan broj [38]. Poruka se sastoji od zaglavlja poruke i tela poruke, čija je
specifikacija atributa u nastavku:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 156
Struktura dokumenta je sledeća:
Instrukcija ima sledeću strukturu:
Transakcija ima sledeću strukturu:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 157
Na slici 62. do slike 64. prikazana je XML struktura modela poruke sa opisanim
elementima modela. Na slikama 65. i 66. prikazana je struktura poslovnog pravila [9]
poruke i konkretan primer pravila.
Slika 62. XML struktura modela poruke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 158
Slika 63. XML struktura modela poruke – grafički prikaz
Slika 64. XML struktura modela poruke, telo poruke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 159
Slika 65. XML struktura modela poslovnog pravila u strukturi poruke
Slika 66. Primer konkretnog poslovnog pravila u poruci
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 160
Slika 67. Relaciona šema poruke sa poslovnim pravilom
Model poslovnih pravila može se predstaviti uz pomoć XML strukture šema poruka
koje opisuju sistem [16], [44]. Mogu se implementirati u standard zajedno sa strukturom
podataka za razmenu. Na taj način mogu da se integrišu sistemi koji ne poznaju
strukturu poruka i poslovna pravila koje će biti, u zavisnosti od ovlašćenja koja ima
sistem koji šalje poruke u sistem koji prima poruke, primenjena u ishodišnom sistemu. I
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 161
ovde se struktura XML šeme preslikava u relacionu strukturu baze podataka, ali i
primenjuje izvorno poslovno pravilo koje je poslato uz poruku [222], [114].
Sistemi koji su u nadređenom položaju mogu na ovaj način, nakon sticanja sistemskih
uslova, da zadaju sisteme na podređenim lokacijama, dok bi podređenim lokacijama
bilo dovoljno da navedu identifikaciju poslovnog pravila. Sistemi sa definisanim
poslovnim pravilima u porukama složeniji su za zadavanje i upravljanje, ali ne
zahtevaju komplikovan sistem za podršku na ishodišnoj lokaciji. Struktura poslovnog
pravila: Poslovno pravilo(ID pravila; Ime pravila; Verzija pravila; Ime poslovne akcije;
Datum početka; Datum isteka; Prioritet; Nivo pristupa; Opis; Akcija posle uspešne
primene; Naziv akcije nakon uspeha primene; Akcija posle neuspešne primene; Naziv
akcije nakon neuspeha primene; Jezik), Potpis. Poslovna pravila se ogledaju i u drugim
ograničenjima sistema, koji se implementiraju nad perzistentnim elementima sistema.
Na primer, Identifikator dužnika u domaćem platnom prometu mora da bude dužine
osam karaktera ukoliko je u pitanju pravno lice, odnosno 13 ukoliko se radi o fizičkom
licu - preduzetniku. Na slici 67. prikazana je relaciona šema poruke sa poslovnim
pavilima instance poslovnog pravila prikazana na slici 65.
5.3 SEPA model procesa
Credit Transfers šema evropskog saveta za plaćanja [70] ima za cilj da uspostavi
pravila i standarde međubankarskog poslovanja [96], [97] po pitanju upravljanja SEPA
Credit Transfers-om kao instrumentom plaćanja radi ostvarenja interoperabilnosti [60]
u komunikaciji i razmeni informacija o novčanim transferima. Takođe, šema naglasak
stavlja na usvajanje otvorenih standarda kako bi se olakšala integracija među
bankarskim sistemima [69].
Evropski savet za plaćanja u sklopu ove šeme obavezuje banke da referentne
informacije o plaćanju (remittance reference information) prosleđuju neizmenjene kroz
bankarske sisteme [188], od nalogodavca do korisnika [68]. EPC smatra da će time
proces automatskog poravnanja računa biti značajno pojednostavljen. Šema je
primenjiva u okviru SEPA zone, koju predstavlja 25 EU zemalja, kao i Island,
Lihtenštajn, Norveška i Švajcarska [66]. Tajnost podataka o SEPA Credit Transfers-u
mora biti garantovana i, po želji vlasnika platnog računa, može biti dodatno zaštićena
šifrovanjem. Dijagram na slici 68, preuzet iz EPC125-05 dokumenta, predstavlja opšti
pogled na proces Credit Transfers-a. Zahtev za korišćenje servisa (servisa za realizaciju
instrukcija zadatih nalogom za transfer) inicira se od strane Nalogodavca, koji želi iz
nekog razloga da izvrši transfer sredstava Korisniku sredstava. Platni servis, u domenu
banke, prihvata osnovni zahtev. Da bi ovaj zahtev za prenosom sredstava bio
realizovan, banka zadužuje račun Nalogodavca (koji mora da ima sredstva neophodna
za namirenje iznosa na koji će biti odobren račun Korisnika) obezbeđuje dodatne
informacije potrebne da bi se transfer obavio. Banka Nalogodavca treba da ustanovi da
li Nalogodavac ima potrebna sredstva ili dovoljno sredstava sa kojim se može izvršiti
Credit Transfers, da ustanovi da nalogodavac postupa u skladu sa svojim ovlašćenjima i
da Credit Transfers ne krši ni jedan važeći zakon, regulative ili neki drugi uslov,
uključujući uslove određene od strane banke Nalogodavca. Tada će banka Nalogodavca
izvršiti plaćanje i nakon toga obavestiti Nalogodavca. Elementi za transfer će postojati
ukoliko i banka Korisnika ima ugovorene metode i pravila za prihvataanje informacija o
plaćanju, kao i metod i pravila za prihvatanje informacija o iznosu izvršenog plaćanja.
Na osnovu toga, banka Korisnika će koristiti primljene informacije da odobri račun
Korisnika, učini sredstva dostupnim za korišćenje kada je to moguće i na kraju će
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 162
informisati Korisnika o izvršenom transferu sredstava na njegov račun.
Svrha međubankarskog kliringa i poravnanja jeste da se na korektan način razmene
informacije i na siguran način izvrši razmena vrednosti. Zahtev za servis kliringa i
servis izvršenja izravnanja je indukovan potrebom za transfer novca između banaka.
Prostor Credit Transfers se particioniše na:
1. Credit Transfers Initiation – inicijacija platnog naloga;
2. Credit Transfers Clearing and Settlement – poravnanje i izvršenje platnog
naloga;
3. RTGS Settlement – izvršenje naloga.
Bruto poravnanje se ne izvršava u sistemu Credit Transfers, već u RTGS sistemu, gde
se vrši konačno poravnanje. Sistem RTGS nije predmet analize, već je to samo
komunikacija prema RTGS sistemima i od njih ka Credit Transfer sistemu.
Slika 68. EPC Model Credit Transfers-a iz knjige pravila [98]
Sve tri grupacije poslova se particionišu po mestu gde se odvija procesiranje:
I Retail System:
Odvija se kod Nalogodavca, odnosno Korisnika. Nalogodavac i Korisnik komuniciraju
sa bankom. Zbog mesta odvijanja procesa ovaj segment se naziva „Retail System“.
II Bank’s Retail Credit Transfer System & Processor Credit Transfers System:
Odvija se u banci i bavi se komunikacijom banke sa svojim klijentima i prosleđivanjem
zahteva procesorskoj kući. Zbog mesta odvijanja procesa ovaj segment se naziva
„Bank’s Retail Credit Transfers System“ prema klijentima i „Bank’s Processor Credit
Transfers System“ prema procesorskoj kući/kućama.
III Processor’s Neto System & Bruto System:
Odvija se u procesorskoj kući i bavi se komunikacijom sa bankama i RTGS sistemom
(odnosno sistemom za izvršavanje poravnanja). Zbog mesta odvijanja procesa ovaj
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 163
segment se naziva „Processor’s Neto System“ prema bankama i „Processor’s Bruto
System“ prema sistemu za bruto poravnanje.
Iz gornjeg sledi da se sistem za Credit Transfers sastoji od pet osnovnih podsistema:
1. Retail System;
2. Bank’s Retail Credit Transfers System;
3. Bank’s Processor Credit Transfers System;
4. Processor’s Neto System;
5. Processor’s Bruto System.
Podsistemi su determinisani i posmatraju se na taj način jer su distribuirani elemeti
sistema za koje su različite:
Kvalifikacije (retail korisnici, banke i procesorske kuće kvalifikovane su za obavljanje
različitih poslovnih procesa koji međusobno nemaju nikakvih zajedničkih elemenata).
Autorizacije (retail korisnici, banke i procesorske kuće autorizovane su od različitih
odgovornih subjekata za različite poslove i nalaze se u jedinstvenoj poslovnoj vertikali).
Odgovornosti (postoji jasno determinisano vlasništvo nad poslovima).
Navedeni podsistemi Credit Transfers uklapaju se u generički model.
Direct Debit (platni promet po osnovu direktnog zaduženja) kao lokalni instrument
plaćanja unutar evrozone, SEPA (Single Euro Payment Area) [71] ima za cilj da zameni
trenutni pristup poravnanju učesnika u nacionalnim i međunarodnim okvirima čije su
osnovne prednosti sledeće:
• jednostavan i jeftin način za prenos sredstava;
• mogućnost određivanja tačnog datuma za prikupljanje potrebnih sredstava;
• pouzdanost izvršenja plaćanja u predefinisanom vremenskom ciklusu [67];
• šansa za optimizaciju tokova novca i upravljanjem sa sredstvima;
• automatsko knjiženje (razduživanje) prispelih plaćanja;
• mogućnost da se automatizuju REJECTS (odbijane pre započinjanja procesa
naplate), REFUSALS (odbijanje zahteva pre likvidacije ili poravnanja),
RETURNS (odbijanje zahteva posle poravnanja), REVERSALS (povraćaj ili
storno započete naplate zbog nedostatka sredstava na računu dužnika koji se
konstatuje nakon kliringa), REVOCATIONS (opoziv instrukcije naplate od
strane poverioca u skladu sa Ugovorom poverioca i njegove banke),
REQUEST FOR CANCELATION (zahtev za otkazivanje je opoziv
instrukcija naplate od strane banke kreditora), REFUNDS (refundiranje
sredstava dužniku od strane njegove banke prema ugovoru);
• jedan platni instrument u okviru SEPA za zaduživanje bankovnih računa u
SEPA zoni;
• mogućnost za prikupljanje sredstava korišćenjem jednog platnog
instrumenta;
• redukcija administrativnih troškova i povećana sigurnost zbog korišćenja
digitalnog potpisa mandata, kada elektronski potpis bude moguće koristiti.
Formalan opis osnovnog toka procesa platnog prometa po osnovu direktnog zaduženja,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 164
učesnika u ovom procesu, kao i opis formata poruka u komunikaciji između finansijskih
institucija dati su u nastavku.
Platni promet po osnovu direktnog zaduženja (u daljem tekstu Direktno zaduženje)
predstavljaju transakcije koje inicira poverilac na osnovu mandata, Prilog 4, u cilju
izmirenja međusobnih obaveza. Mandat (dokument Specifikacija mandata za obavljanje
platnog prometa po osnovu Direktnog zaduženja) je dokument kojim dužnik daje
ovlašćenje svom poveriocu da inicira transakcije i svojoj banci da postupa u skladu sa
instrukcijama iz tih transakcija, a koje će rezultirati zaduženjem dužnikovog računa.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 165
• Banka dužnika (Debtor Bank) je banka kod koje je račun dužnika.
• Dužnik (Debtor) je pravno ili fizičko lice koje mandatom daje pomenuta
ovlašćenja poveriocu i banci dužnika, i čiji se račun zadužuje.
Na slici 69. prikazan je proces Direktno zaduženje – Osnovni tok:
• PT04-01 Collect Information for Collection (prikupljanje informacija za
zbirku): poverilac priprema podatke za instrukciju Direktnog zaduženja.
• PT04-02 Pre-notify the Debtor (predobaveštavanje dužnika): poverilac
obaveštava Dužnika o datumu prezentovanja instrukcije banci dužnika i iznosu
kojim će biti zadužen.
Vremenski okvir [ > D-14CD ]: obaveštenje se šalje najkasnije 14
kalendarskih dana (u daljem tekstu „CD“) pre naznačenog dana izvršenja
instrukcije (u daljem tekstu „D“).
• PT04-02bis Initiate Refusal (iniciranje odbijanja): na osnovu obaveštenja,
Dužnik može da naloži Banci dužnika da odbije instrukciju
• PT04-03 Send the Collections (slanje zbirke): Poverilac šalje jednu ili više
instrukcija Banci poverioca. Kao obavezan deo svake instrukcije, poverilac šalje
i potrebne informacije iz Mandata.
Vremenski okvir [D-2TD < send date < D-14CD ]: aktivnost može
otpočeti najranije 14 CD od dana D. Aktivnost se mora završiti
najkasnije 2 bankarska dana (u daljem tekstu „TD“) od dana D.
Vremenski okvir [D-5TD< send first / one-off] : u slučaju jednokratne
instrukcije i prve instrukcije višekratnih instrukcija, aktivnost mora
završiti najkasnije 5 TD od dana D.
• PT04-04 Reject some Collections (odbijanje nekih zbirki): Banka poverioca
vraća nevalidne instrukcije poveriocu.
• Corrections: Poverilac vrši ispravku nevalidnih instrukcija.
• PT04-05 Send the Collections (slanje zbirki): Banka poverioca šalje
instrukcije Klirinškoj kući.
• PT04-06 Reject some Collections (odbijanje nekih zbirki): Klirinška kuća
vraća nevalidne instrukcije Banci poverioca.
• PT04-07 Send the Collections (slanje zbirki): Klirinška kuća šalje instrukcije
Banci dužnika, koje sadrže potrebne informacije iz Mandata.
Vremenski okvir [ D-2TD < send date < D-14CD ]: aktivnost može
otpočeti najranije 14 CD od dana D. Aktivnost se mora završiti
najkasnije 2 bankarska dana (u daljem tekstu „TD“) od dana D.
Vremenski okvir [ D-5TD< send first / one-off ] : u slučaju jednokratne
instrukcije i prve instrukcije višekratnih instrukcija, aktivnost mora
završiti najkasnije 5 TD od dana D.
• Clearing and Settlement (kliring i poravnanje): Klirinška kuća izračunava
neto pozicije i vrši poravnanje.
• PT04-08 Reject some Collections (odbijanje nekih zbirki): Banka dužnika,
vraća instrukcije koje nisu validne Klirinškoj kući sa razlogom odbijanja.
Vremenski okvir: aktivnost počinje odmah po prijemu instrukcija, a
mora se završiti pre naznačenog dana D.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 166
• PT04-09 Debit the Debtor (zaduživanje dužnika): Banka dužnika zadužuje
račun dužnika za navedeni iznos i datum u instrukciji.
Vremenski okvir [ D>debit>D+5TD ]: aktivnost može otpočeti najranije
dana D, a mora se završiti do 5 TD od dana D.
• PT04-10 Send Returned Collection (slanje odbačenih kolekcija): Ukoliko
Banka dužnika ne može da zaduži račun Dužnika, instrukcije moraju biti
vraćene Klirinškoj kući sa razlozima vraćanja.
Vremenski okvir [ D>debit>D+5TD ]: aktivnost može otpočeti najranije
dana D, a mora se završiti do 5 TD od dana D
Pri izvršenju Direktnog zaduženja, propisano je da banka i klirinška kuća (u daljem
tekstu Finansijske institucije) razmenjuju informacije definisane preko niza DS
struktura (DS – Data Set). Svaka DS struktura predstavlja skup podataka neophodnih za
obavljanje pojedinih aktivnosti unutar procesa Direktnog zaduženja.
Zbog različitih aktivnosti i uloga učesnika u procesu, neki DS može imati više
pojavljivanja u različitim fizičkim porukama. Fizičke poruke su propisane UNIFI (ISO
20022) standardom, i one su stvarni nosioci informacija u komunikaciji finansijskih
institucija. UNIFI standard grupiše poruke u sledeće oblasti:
• Payment Initiation (iniciranje plaćanja) predstavlja komunikaciju između
Dužnika i Poverioca sa bankom dužnika i bankom poverioca, respektivno.
Prefiks u oznaci poruka iz ove oblasti je „pain“ (payment initiation). Upotreba
ovog skupa poruka nije obavezujuća, ali ga SEPA standard preporučuje.
• Payment Clearing and Settlement (kliring i poravnanje plaćanja) predstavlja
komunikaciju između finansijskih institucija, i prefiks u oznaci poruka iz ove
oblasti je „pacs“ (payment clearing and settlement). Upotreba ovog skupa
poruka je po SEPA standardu obavezujući.
Slika 70. opisuje ugovorene relacije i interakciju između glavnih učesnika procesa
direktnog zaduženja. Učesnici su uslovljeni sa relacijama označenim brojevima:
(1) Ugovorene relacije pravilima sa kojima su se učesnici saglasili.
(2) Između dužnika i poverioca postoji potreba da se izvrši plaćanje koje je
rezultovalo potpisivanjem mandata – ugovora kojim poverilac stiče pravo
iniciranja finansijske transakcije direktnog zaduženja u svoju korist na račun
dužnika.
(3) Između banke poverioca u skladu sa pravilima kojima je determinisan servis
direktnog zaduženja realizuje se inicirana transakcija direktnog zaduženja.
(4) Dužnik se obaveštava o budućoj transakciji i o izvršenoj transakciji po
pravilima.
(5) Banke dužnika izvršavaju transakciju direktnog zaduženja preko mehanizma
sistema za poravnanje po pravilima.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 167
Slika 70. Ugovorena interakcija učesnika u procesima direktnog zaduženja [98]
Navedeni Direct Debit procesi uklapaju se u generički model dat u poglavlju 5.1.1.
Procesi Direct Debit i Credit Transfers se uklapaju u generički model.
5.4 Matematički model EPPS-a
Rekurzija je već jako dobro poznat pojam iz oblasti matematike i kibernetike. U
poslovnom okruženju rekurzija se veoma retko koristi eksplicitno [187]. Međutim,
rekurziju je moguće primeniti u sistemima koji su kompleksni: korišćenjem slučaja gde
je unutrašnjost sistema hijerarhijski rekurzivna (specijalan slučaj koji se pojavljuje
veoma često u praksi, pogotovu u domenu platnih sistema), korišćenjem slučaja gde su
objekti sistema rekurzivni i korišćenjem slučaja gde se javlja rekurzivni problem koji
treba rešiti. Veoma često se sreću rekurzivne ruske figurice zvane „babuške“, a slika 71.
sadrži još neke primere. „Objekat se naziva rekurzivnim ako on sadrži samog sebe kao
deo ili ako je definisan sa nekim svojim delom“ [187].
Slika 71. Primeri rekurzivnih modela
Slika 72. Rekurzivna struktura finansijskog tržišta u Srbiji
(Wholesale nivo – nivo banaka, Retail nivo – nivo pravnih i fizičkih lica)
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 168
Sistem se, dakle, ne sastoji samo od elemenata sa atributima i relacijama između njih,
već i od činjenice da pripada nekom nadređenim sistemu i da se sastoji od podređenih
sistema, odnosno za svaki sistem može se pronaći struktura kojoj pripada. Na slici 72.
prikazan je platni sistem koji ima rekurzivnu strukturu.
Rekurzivna struktura se, sem kao odnos između skupova, može predstaviti i na nekoliko
drugih načina. Jedan od načina je i prikaz sa ugnježdenim zagradama, pa tako struktura
sa slike 72. može da izgleda ovako: (G(D, E(A, B, C), F)). Jasno je da se rekurzivni
objekat može prikazati i rekurzivnom strukturom. Prikaz može da bude i tabelaran, u
kome kolone predstavljaju hijerarhijski nivo u okviru samog rekurzivnog objekta, a
vrste nazive elemenata koji se ponavljaju, kao što je prikazano na slici 73.
G Nivo NBS
D Wholesale nivo
F
E
A Retail nivo
B
C
Slika 73. Rekurzivna struktura finansijskog tržišta
u Srbiji, prikazana u tabelarnom obliku
Na osnovu prethodnog razmatranja, sledi matematički model rekurzivne strukture:
Platni sistem Srbije se sastoji od sistema za plaćanje na više nivoa. Najniži nivo je onaj
na kome se vrši akvizicija i finalna distribucija informacija o platnim transakcijama. To
je Retail nivo. Nivo iznad je nivo poslovnih banaka, odnosno Wholesale nivo. Iznad
nivoa poslovnih banaka je nivo RTGS Narodne banke Srbije [220]. Iznad nivoa RTGS
Narodne banke Srbije nalaze se različiti nivoi globalne razmene informacija o platnim
transakcijama.
Platni sistemi iste namene na različitim nivoima po svojoj funkcionalnosti su
ekvivalentni. Označimo na taj način dobijeni bazični model sistema na sledeći način:
(1) BM, gde je BM bazični model sistema.
Neka Fl(k) predstavlja model sistema na k-tom nivou. Funkcija fl(X) neka predstavlja
funkciju transformacije unije više sistema koja je jednaka X. Transformacija sistema se
ogleda u autorizovanosti nad podacima, odgovornosti i dodeljenoj potrebnoj
kvalifikovanosti koja se sprovodi kroz propisivanje zakonske regulative, normi i
primene drugih propisanih standarda. Preslikavanje fl je takvo da se na višim nivoima
razlike Rn-1 preslikavaju u tačku (preslikavanje zanemaruje Rn-1 na višem nivou), jer se
radi o funkcijama sistema koje nisu predmet sistema višeg nivoa.
Neka RX predstavlja deo sistema višeg nivoa od onog koji ima unija sistema X a koji
nije sadržan u uniji sistema X.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 169
Pretpostavimo da se sistem na najnižem nivou može realizovati korišćenjem bazičnog
modela, kao na slici 74:
(2) Fl(0) = f l (BM) R0, l N, R0 je ostatak sistema koji nije sadržan u BM.
Slika 74. Grafički prikaz modela sistema najnižeg nivoa
Na osnovu prethodnih razmatranja, nivo n sistema se može predstaviti na sledeći način:
(3) , k, l, m, n N .
Model opisan formulom (3) može se grafički prikazati kao na slici 75.
Slika 75. Grafički prikaz modela sistema n-tog nivoa
Primer:
Neka su F1(n-1), F2(n-1) i F3(n-1) tri različita platna sistema različitih banaka, tj. sistemi
za Credit Transfers, Direct Debit i kliring čekova, respektivno. Tada će sistem Fl(n) biti
procesorska kuća za Credit Transfers, Direct Debit i kliring čekova. Neće imati, recimo
zakonom propisane obaveze Rn-1 koje funkcija fl preslikava u tačku (odnosno
zanemaruje), ali će imati njoj namenjene funkcije koje se odražavaju u razlici Rn.
Kada su sistemi F1(n-1), F2(n-1) i F3(n-1) iste vrste, recimo Direct Debit, onda se
formula (3) uprošćava i nije potrebno tražiti uniju jer su sistemi na nivou n-1
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 170
ekvivalentni, pa je dovoljno primeniti funkciju transforamcije na bilo koji sistem i
dodati razliku Rn da bi se dobio sistem nivoa n. U ovom slučaju je i sistem n-tog nivoa
ekvivalentan sa bilo kojim od sistema n-1 nivoa.
5.5 Metod razvoja modela EPPS-a
Razvojem savremenih standarda u informacionim tehnologijama i napretkom u oblasti
komunikacionih tehnologija, automatizacija u domenu sistema elektronskog poslovanja
platnih sistema postaje aktuelnija, a sve je izraženija tendencija u povezivanju
segmenata poslovnih sistema, poslovnih procesa sa adekvatnim skupovima podataka u
njima. Standard za analizu, zadavanje i implementaciju poslovnih sistema podržanih
informacionim tehnologijama koji se opisuje u ovom radu rešava niz problema
povezanih sa odgovornošću, autorizacijom i kvalifikovanošću različitih subjekata koje
poslovni sistem sadrži. Na primer, jasno se razdvajaju uloga i zadaci u analizi,
zadavanju i implementaciji tehnologa posla koji treba da se podrži sa informacionim
tehnologijama od tehnologa sa znanjima informacionih tehnologija. Primeri su i
zadavanje procesa od strane tehnologa posla koji se opisuje u Operativnim pravilima i
opisivanje struktura podataka u XML šemama od strane IT tehnologa.
Potpisani elektronski dokumenti u jednom sistemu su na osnovu Zakona o elektronskom
potpisu [136] i Zakona o elektronskom dokumentu [144] ravnopravni sa ostalim
zakonski priznatim dokumentima. Mnogi standardizovani sistemi poruka sadrže i
odgovarajuće pozicije u okviru poruka za elektronski potpis i na taj način obezbeđuju
bezbedan prenos podataka. Determinisanje sistema se postiže definisanjem dokumenata
koji definišu poslovni ambijent u kome se odigravaju poslovni procesi, odnosno
adekvatno i konzistentno poslovno okruženje, Prilog 7. Opisan je postupak
determinisanja poslovnih sistema, koji se može primeniti na svaki sistem za obradu
transakcija ili neki njegov deo. Sistemi za obradu transakcija su dizajnirani da
procesiraju rutine različitih poslovnih transakcija efikasno i na strogo determinisan
način. Svaki poslovni sistem ima potrebu za jednim ili više sistema za obradu
transakcija, na primer: za fakturisanje, za plaćanje, za praćenje, za izračunavanje poreza,
taksi i drugih davanja, za preračun potrebnih materijala za proizvodnju, za kontrolu
stanja magacina i slično.
Ukoliko neki elementi za predloženi postupak nisu standardizovani, preporuka je da se
pre determinisanja izvrši standardizacija elemenata potrebnih za operativna pravila,
uputstvo o formatu i nameni poruka, tehničko uputstvo i šeme poruka. U finansijskoj
industriji izvšena je standardizacija, tako da za isti element postoji više različitih
standarda. Često takav odnos prema standardima nosi sa sobom mnoge teškoće,
materijalne izdatke i dodatne rizike.
Finansijske institucije definisanjem univerzalnih standarda pokušavaju da prevaziđu
takvu situaciju, tako da se sada stvaraju standardi kojima ostali konvergiraju, sa
intencijom potpune zamene sa novim standardima. Osnovni standardi za ovakav način
determinisanja sistema možemo naći u standardima propisanim za finansijsku razmenu
poruka, kao što su ISO20022 i SWIFT. Razmenu poruka za integraciju koristi Narodna
banka Srbije (veoma intenzivno − oko milion finansijskih transakcija dnevno) i
Klirinška institucija banaka Udruženja banaka Srbije. Specifičnost oba sistema je
potpuna determinisanost sa operativnim pravilima. U slučaju Narodne banke Srbije, to
je determinisanost sa operativnim pravilima za obračun u realnom vremenu i kliringu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 171
[135], kao i uputstvom o formatu i nameni poruka. Slični sistemi su opisani i u
publikaciji o platnim sistemima izdatoj od strane Danske nacionalne banke [49], [165].
Dokumenti koji treba da budu produkovani da bi se sistem mogao zadati i na osnovu
toga i implementirati predstavljeni su u Tabeli 10, gde je predstavljena i odgovornost za
pojedinačni dokument [20]. Za izradu svakog dokumenta potrebno je sprovesti zasebnu
analizu nekom od raspoloživih metodologija. Navedeni dokumenti predstavljaju i
osnovne dokumente potrebne nadležnim organima za odobravanje rada sistema i
procesa koji su na taj način zadati [14]. Navedeni dokumenati neophodan su ali i
dovoljan uslov za započinjanje i realizaciju funkcionalne specifikacije kao prvog koraka
implemantacije sistema [21]. Predstavljeni dokumenti su zadati industrijskim
standardima, zakonskom regulativom, normativnim aktima i drugim raznorodnim
standardima koje treba uzeti u obzir prilikom analize potrebne za njihovu izradu [86].
Rbr. Opis dokumenta Odgovornost Dokument
1. Operativna pravila Tehnolog posla Prilog 1.
2. Format i namena poruka Tehnolog posla Prilog 2.
3. Termin plan Tehnolog posla Prilog 3.
4. Tehničko uputstvo IT tehnolog Prilog 5. i Prilog 6.
5. Poslovna pravila IT tehnolog Prilog 5. i Prilog 6.
6. Sheme IT tehnolog http://www.ubs-asb.com/
KIB, Direktna zaduženja računa,
UBS platna šema 7. Instance IT tehnolog
Tabela 10. Vrsta dokumenata i odgovornost za izradu
Operativnim pravilima zadaje se ponašanje sistema, uzevši u obzir standardne osobine
koje treba da ispune. Tehničko uputstvo determiniše strukturu sistema a termin plan
definiše periodiku procesa sistema (učestalost dešavanja). Dokument „Format i namena
poruka“ ima zadatak da povezuje ponašanje sa strukturom, odnosno operativna pravila
sa tehničkim uputstvom. Sheme i instance poruka su praktični artifakti koji mogu da
služe za implementaciju konkretnih kategorija u sistemu (formi, interfejsa, struktura za
prihvatanje konkretnih instanci sistema).
Opis dokumenata: Svaki od dokumenata, bez obzira na prirodu sistema koji se
determiniše i bez obzira na definisanu arhitekturu razmene poruka, sadrži
fenomenološki analogne fakte koji se na istovetan način opisuju i zadaju u svakom od
njih, pa su i navedeni dokumenti iste strukture koja je u nastavku i navedena.
Operativna pravila: Naziv ovog dokumenta je „Operativna pravila za realizaciju IME
SISTEMA“, gde je IME SISTEMA tačan naziv sistema koji se realizuje. Pored verzije
sistema, atribut dokumenta je i datum verzije, primer u Prilogu 1. Produkcioni sistem
mora podržati sve važeće verzije dokumenta, izuzev onih za koje je nalogodavac
eksplicitno naznačio da se ne smeju podržavati. Operativna pravila se sastoje od:
• osnovnih odredbi i pojmova u kojima se naznačuje na osnovu koje regulative
sistem ima autorizaciju i odgovornost, definicija aktera u sistemu, definicija
osnovnih entiteta sistema koji su predmet sistema, definicija osnovnih procesa
koji su predmet sistema;
• načina i uslova koje učesnici treba da ispune;
• odgovornosti učesnika i mere zaštite;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 172
• definicije šta predstavljaju podaci, kako se od podataka sačinjavaju poruke –
dokumenti i način kako se ti dokumenti razmenjuju;
• definicija prava i obaveza učesnika;
• rokova u kojima se procesi moraju obavljati;
• način realizacije osnovnih procesa;
• način rešavanja izuzetaka i reklamacija;
• definiše se način sistema obaveštavanja biroa za procesiranje o promenama
statusa, validnosti primljenih dokumenata, odbijanju instrukcija, osnovnih
podataka o procesiranju instrukcija, ostvarenoj realizaciji instrukcija i
realizovanim instrukcijama, kao i odgovarajućeg skupa informacija o promeni
statusa učesnika, njegovih instrukcija i odbijanju instrukcija;
• način i uslovi isključenja učesnika iz sistema;
• naknade za poslove biroa za procesiranje;
• moguće dodatne servise;
• završne odredbe koje se odnose na sam dokument, odnosno operativna pravila.
Operativna pravila imaju prvi zadatak da povežu realni sistem sa aktuelnom zakonskom
regulativom i standardima koji se koriste prilikom obavljanja poslovnih procesa.
Operativna pravila zadaju i učesnike sa preduslovima za njihovo uključenje u sistem,
uslove rada i isključenja u sistem. Operativna pravila moraju da određuju ambijent i po
pitanju definisanja pojmova i drugih osnovnih elemenata sistema. Pored načina i uslova
za rad učesnika, determinišu se i mere zaštite i odgovornosti, način realizacije i
obezbeđenje obavljanja poslovnih procesa, kao i skupovi podataka koji ih obezbeđuju,
na koji način se učesnici u sistemu obaveštavaju, način rešavanja reklamacija, terminski
plan za obavljanje poslovnih procesa, dodatni servisi, tarife, kao i specijalne završne
odredbe koje u nekim specijalnim aspektima determinišu sistem.
Format i namena poruka: Naziv ovog dokumenta je „Uputstvo o nameni i formatu
poruka za sistem NAZIV OSNOVNOG TEHNOLOŠKOG PROCESA“. Pored verzije
sistema, atribut dokumenta je i datum verzije, primer u Prilogu 2. Produkcioni sistem
mora podržati sve važeće verzije dokumenta, izuzev onih za koje je nalogodavac
eksplicitno naznačio da se ne smeju podržavati. Uputstvo o nameni i formatu poruka
sastoji se od:
• osnovnih pojmova koji determinišu tehnološko okruženje u kome se odvijaju
procesi;
• tehnološke strukture podataka;
• specifikacije osnovnih procesa i procesa za rešavanje izuzetaka;
• specifikacije procesa za rešavanje reklamacija;
• definicije osnovnih i ostalih dokumenata – poruka;
• definicije administratorskih poruka;
• definicije poruka na nivou razmene dokumenata;
• tehnološka pravila za realizaciju instrukcija;
• tehnološka pravila za realizaciju procesiranja;
• definicije proširenog skupa servisa.
Uputstvo o formatu i nameni poruka određuje skupove i tokove podataka potrebnih za
obavljanje poslovnih procesa. Definišu se registri učesnika i registri drugih objekata koji
se u sistemu procesiraju. Procesi elektronske razmene dokumenata ovim uputstvom se
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 173
povezuju sa konkretnim skupovima podataka i porukama koje se detaljno opisuju u
dokumentu „Tehničko uputstvo“. Uputstvo o formatu i nameni poruka, pored toga što
opisuje namenu poruka, definiše i poslovnu upotrebu definisanog skupa poruka.
Uputstvo određuje osnovnu komunikaciju i servise elektronske razmene dokumenata i
procesiranje.
Terminski plan: Naziv ovog dokumenta je „Terminski plan za sistem IME
SISTEMA“, gde je IME SISTEMA tačan naziv sistema koji se realizuje, primer u
Prilogu 3. Pored verzije sistema, atribut dokumenta je i datum verzije. Produkcioni
sistem mora podržati najnoviju verziju dokumenta. Terminski plan se sastoji od
informacija o radnom vremenu biroa za procesiranje, terminskog plana sa izabranim
periodikama koje se zadaju sa sledećim atributima: opisom poslovnog procesa,
oznakom dokumenta sa kojim se proces realizuje i terminom realizacije.
Tehničko uputstvo: Naziv ovog dokumenta je „Tehničko uputstvo za poruke NAZIV
OSNOVNOG TEHNOLOŠKOG PROCESA“, primer u prilozima 5 i 6. Pored verzije
sistema, atribut dokumenta je i datum verzije. Produkcioni sistem mora podržati sve
važeće verzije dokumenta, izuzev onih za koje je nalogodavac eksplicitno naznačio da
se ne smeju podržavati. Tehničko uputstvo se sastoji od opisa struktura dokumenata –
poruka sa indeksom koji jedinstveno determiniše element u poruci, kardinalnosti
elementa, naziva elementa, tipa podataka elementa, opisa i definicije poslovnih pravila
koji se odnose na taj element. U tehničkom uputstvu se opisuje i svrha poruke, ko je
generisao dokument, opis osnovne strukture. U tehničkom uputstvu se specificiraju i
šifarnici ili kodovi za šifarnike.
Tehničko uputstvo definiše detaljan format poruka sa sledećim atributima za svaku
poziciju u okviru poruke:
• index (jedinstveni identifikator u okviru poruke);
• obaveznost (da li je obavezno ili opciono polje);
• naziv pozicije u poruci (naziv XML čvora);
• XML tag;
• kardinalnost;
• tip;
• identifikator poslovnog pravila ukoliko ga ima za datu poziciju.
Slika 76. Primer opisa pozicije EmailAddress
u ISO20022 tehničkom uputstvu
Svaka od pozicija naknadno se detaljno opisuje, kao što je to prikazano na slici 76.
Pored navedenih elemenata, definišu se precizno i poslovna pravila sa identifikatorom
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 174
poslovnog pravila navedenog uz poziciju u poruci i detaljan opis sa eventualnim
preporukama za implementaciju pravila.
Poslovna pravila: Naziv ovog dokumenta je „Poslovna pravila za poruke NAZIV
OSNOVNOG TEHNOLOŠKOG PROCESA“, primer u prilozima 5 i 6. Pored verzije
sistema atribut dokumenta je i datum verzije. Produkcioni sistem mora podržati sve
važeće verzije dokumenta, izuzev onih za koje je nalogodavac eksplicitno naznačio da
se ne smeju podržavati. Poslovna pravila se sastoje od detaljnog opisa poslovnog pravila
u odnosu na indeks elementa ili više indeksa elemenata na koje se poslovno pravilo
odnosi, odnosno element poslovne poruke.
Šeme poruka: Šeme poruka proističu iz dokumenta Tehničko uputstvo i Poslovnih
pravila. Šeme poruka se materijalizuju u XML formatu. U sebi sadrže informacije o
strukturi dokumenata i osnovnim ograničenjima nad odgovarajućim skupovima
podataka.
Instance poruka: Instance poruka se operativno koriste prilikom realizacije sistema i
praktičnih provera pretpostavki tokom analize i implementacije sistema. Strukture
podataka mogu da budu kompleksne i instance služe za provere osnovnih
implementacionih pretpostavki.
Navedeni opisani proces zadavanja sistema standardizuje i analizu sistema koju treba
sprovesti u procesu implementacije informatičke podrške poslovnim procesima.
5.5.1 Identifikacija komponenata modela EPPS-a
Ontologija, u skladu sa najzastupljenijom definicijom elektronskog poslovanja jeste
„specifikacija konceptualizacije” [79], [29]. REA (Resource-Event-Agent) ontologija je
specifikacija deklarativne semantike uključene u poslovne procese [127]. Teorija koja
stoji iza REA je iz oblasti računovodstva, gde je REA prvi put uvedena, i njene
komponente imaju jasne mikroekonomske izvore koji su povezani specifičnim vezama i
u mnogo slučajeva koriste se u praksi prilikom izgradnje informatičke podrške
poslovnih sistema [17]. U UN/CEFACT radu sve definicije REA ontologije su
primenjene u kolaborativnom prostoru između poslovnih sistema [29] gde se tržišna
razmena obavlja u tesnoj povezanosti dva ili vise poslovnih entiteta [83]. U uprošćenoj
varijanti, REA može biti predstavljena kao UML dijagram klasa sa asocijacijama i
generalizacijama u odnosu na klase objekata.
Osnovni REA model prvi put je publikovan u julu 1982. u izdanju časopisa The
Accounting Review [84]. Osnovne premise ovog rada izdržale su sve teoretske izazove u
narednih 20 godina i danas je zastupljen u obrazovnim, praktičnim i teoretskim
kontekstima (ISO15944-4:2007). Slika 77. ilustruje osnovnu strukturu REA ontologije.
Sa leva nadesno su konfigurisani ekonomski resursi, ekonomski događaji i ekonomski
agenti i to je tipičan poslovni kolaboracioni patern i izvor imena modela REA. Uspešna
poslovna saradnja podrazumeva pre svega dve vrste ekonomskih događanja, od kojih
svaka opisuje ekonomske resurse koji su uključeni u razmenu između dva trgovinska
partnera [191]. Na primer, dobavljač (Partner u trgovini) prenosi vlasništvo nad
automobilom (ekonomskim resursom) klijentu (Partneru u trgovini) u zamenu za koji će
(dualna asocijacija) Kupac obezbediti novac (ekonomski resurs) za dobavljača. Postoje
dva dualne instance objekta čiji je obrazac prikazan na slici 36, gde prenos predstavlja
pravni ili ekonomski osnov za drugu instancu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 175
Slika 77. Osnovna REA ontologija [219]
Deklarativna semantika prikazana na slici 77. je centralna za sve relacije u ekonomiji.
Ekonomski resursi su objekti koji imaju vrednost i koji su pod kontrolom jednog od dva
agenta. Partneri u trgovini uvek očekuju transfer resursa kada se angažuju. Dakle, slika
77. je obrazac za svaku ekonomsku razmenu [78]. U elektronskoj trgovini stvarna faza
razmene je dobro opisana sa objektnom strukturom prikazanom na slici 77. Međutim,
trgovinskim partnerima u dugoročnim odnosima potrebno je više poverenja i predvidiva
struktura poslovanja u kojima su obe strane unapred ugovorile ponašanje prilikom
razmene. REA ontologija opisuje ovo proširenje sa dodatnim klasama [102] prikazanim
kao ekonomska obaveza, ekonomski ugovor i sporazum, prikazani na slici 78.
Slika 78. REA ontologija sa obavezom (angažovanjem) [219]
Obaveza je obećanje partnera u trgovini da će inicirati ekonomski događaj. Inicirani
ekonomski događaj će ispuniti tu obavezu [185]. Obećanja mogu biti recipročna od
strane drugog partnera u trgovini, koji se obavezuje da će inicirati drugi tip ekonomskog
događaja zauzvrat. Ekonomski ugovor je skup reciprotetnih obaveza između partnera u
trgovini koji sa sobom nose jedno ili više ekonomskih razmena u budućnosti. Ugovor je
podtip mnogo uopštenije klase objekata zvane sporazum, a sporazum može regulisati i
drugi sporazum. U slučaju automobile-za-pare razmene biće uključena obaveza sa
kojom se kupac mora saglasiti da prihvati isporuku automobile na određen datum, na šta
će zauzvrat biti ugovorno obavezan da napravi seriju gotovinskih isplata dobavljaču
automobila. Na dnu slike 78. prikazana su dva dodatna objekta. Lokacija i Izjava.
Materijalizacija izjave je nešto što je potrebno partneru u trgovini kada se insistira na
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 176
dokumentima parcijalne razmene, na primer kada kupac automobil uzima u posed pre
nego što ga je isplatio u celosti. Ovaj dodatak je više stvar uobičajenog poslovanja od
ontološke kompletnosti. Lokacija je drugi objekat koji je ponekad potreban da bi se
ispunio ekonomski transfer. Lokacija prosto identifikuje mesto koje zauzima ekonomski
događaj. Ekonomske i ontološke zasnovanosti obaveza su više opisane u radovima
Geerts-a i McCarthy-ja [83].
Obrasci objekata prikazani na slici 78. primarni su deskriptivi u smislu ilustracije šta se
stvarno događa u ekonomskoj razmeni ili šta se za nju obećava. Ove deskriptivne
komponente su argumentovane iz perspektive komponenata koje dozvoljavaju
specifikaciju kontrolnih polisa ili kolaborativnih obrazaca. Ove izvršne komponente su
obezbeđene sa inkluzijom tipa slika osnovnih deskriptivnih objekata [7]. Dijagram klasa
na slici 79. prikazuje ovu dopunu. Dodatni tipovi na slici 79. su naneti u dva navrata: tri
osnovne deskriptivne klase – ekonomski agent, ekonomski događaj i ekonomski agent
(partner) imaju klase dodate za njihove tipove; ove nove klase su povezane sa
deskriptivnim objektima tipizirajući asocijaciju. Na primer, tip resursa može biti različit
tip automobila; kao primer ekonomskog događaja mogu biti uzete transakcije građana
ili transakcije finansijskih organizacija, svaka sa različitom strukturom; a kao primer
ekonomskog agenta (partnera) mogu biti uzete različite klase zaposlenih, svaka sa
različitim zahtevanim tipom treninga; klasa lokacija takođe je tipizirana; primer tipa
lokacije mogu biti različiti tipovi dokova za utovar sa različitim veličinama i različitim
brzinama utovara. Za upotpunjavanje ekonomskog obećanja neophodna je asocijacija
između svaka dva nova nivoa tipa objekata. Ovo je ilustrovano na slici 79. sa
navedenim asocijacijama.
Slika 79. REA ontologija sa tipovima [219]
Postoje i druge REA asocijacije koje nisu ilustrovane na slici 79. da bi se dijagram
učinio manje kompleksnim. REA ontologija je dobro poznata i dosta se koristi u
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 177
knjigovodstvenom domenu a u manjem obimu i u domenu poslovnih sistema poslovanja
preduzeća. Funkcionalni kriterijumi i REA mogućnosti primene REA ontologije
navedeni su u tabeli 11.
Funkcionalni
kriterijum REA objašnjenje
Da li izražava konsenzus
znanja zajednice?
Originalni rad i sve nadogradnje od kada je publikovan u časopisu The Accounting Review, IEEE
Intelligent Systems, etc. i postao je otvoren za konstantna preispitivanja i kritiku. 1996, originalni
rad je dobio prvu nagradu Seminal Contribution to the Accounting Information Systems Literature
od strane American Accounting Association. Rad je kasnije ocenjen 2003 godine i od strane
Accounting Education Award sa najvišom ocenom AAA.
Da se koristi kao referenca
precizno definisanih
termnina?
Tri vodeće knjige o analizi i dizajnu knjigovodstvenih sistema koriste REA veoma intenzivno da
definišu primitive sistema i objasne modeliranje knjigovodstvenih pojava.
Da li je jezik koji je
korišćen dovoljno jasan?
REA primitive mogu biti korišćeni da modeliraju bilo koju ekonomsku pojavu u poslovnom
okruženju. Danas, svaka preduzimljiva logika može biti primenjena u nekom broju slučajeva ali
samo one koje su povezane na nekom nivou granuralnosti sa REA primitivima mogu biti
dokumentovane.
Da li je stabilna? Originalni rad je publikovan 1982. godine. Nema suštinske kritike svojih funkcija koje su
objavljene u međuvremenu do danas.
Da li može biti krišćena za
rešavanje različitih tipova
problema ili kao početna
osnova za konstrukciju
više vrsta primene?
REA može biti korišćen kao model i za dizajn komponenata u knjigovodstvenom softveru.
Takođe, može biti korišćen za modeliranje drugih povezanih poslovnih procesa ili poslovnihh
kolaboracija za ebXML ili TMWG od UN/CEFACT. Takođe, može biti korišćen za modeliranje
internih fenomena u poslovanju između poslovnih sistema kao što su lanci snabdevanja, ali i za
analizu efeikasnosti softvera u okviru poslovne organizacije. Štaviše, proizvedena dokumentacija
se može izraziti na više nivoa granularnosti, u rasponu od visokih nivoa lanaca vrednosti i lanaca
snabdevanja, pa do nivoa toka osnovnih poslovnih procesa. Originalni model pokriva i inter i intra
transakcije među poslovnim jedinicama.
Tabela 11. Ontološki kriterijumi i REA ntologija
Tabela 12. prikazuje poređenje ISO Open – EDI [55], REA – Ontology i UN/CEFACT.
Koncept ISO Open-EDI REA Ontologija UN/CEFACT
Naglasak na „ekonomskoj
vrednosti“ kao osnovi za
poslovni proces i definiciju
poslovne saradnje
Poslovna transakcija
odnosi se na razmenu
neke od vrednosti
Uključuje određene ekonomske
događaje u kojima jedan privredni
resurs (vrednost pod kontrolom
preduzeća) razmenjuje za drugi
ekonomski resurs
Poslovna saradnja je aktivnost
u kojoj se stvara jedan objekat
merljive vrednosti, kao
obavljena usluga ili kao
kreiran proizvod
Određeni „glumci“ ili
agenti koji učestvuju u
ekonomskim aktivnostima
unutar ili između poslovnih
preduzeća
Osoba je pravno ili
fizičko lice koje ima
sposobnost da prihvati
obaveze i da ih ispuni,
kao i posledice koje iz
njih proizilaze
Ekonomski agenti su lica i
organizacioni delovi koji učestvuju u
ekonomskim događajima preduzeća
Partner je actor u poslovnoj
kolaboraciji
Sposobnost da se stvore i
prenesu informacije o
„obavezama“ kao kritične
komponente elektronske
trgovine
Ključna osobina
poslovne transakcije je
da uključuje obaveznu
razmenu između osoba
Obaveza je dogovor da se izvrši
ekonomski događaj u dobro
definisanoj budućnosti, koji će
rezultirati povećanjem ili smanjenjem
sredstava
Obećanje je obaveza da se
izvrši ekonomski događaj
(prenos vlasništva nad
određenom količinom resursa
određenog tipa)
Prethodno uhodani obrasci
za različite klase
kolaboracije elektronskog
poslovanja
Open-edi scenario je
formalna specifikacija
klasa poslovnih
transakcija koji imaju isti
poslovni cilj
Scenario je konfiguracija tipova
događaja, vrste resursa, tipova
obaveza, kao i agregiranih tipova
agenata
Deklarativno kolaboracioni
obrasci su razvijeni na osnovu
BRV komponenata UMM
metamodela
Tabela 12. Poređenje metodologija: ISO, REA i UN/CEFACT
Poslovne transakcije su modelirane za registrovanje, referenciranje i ponovno korišćenje
scenarija i komponenata scenarija uz korišćenje tehnika za identifikaciju ključnih
komponenata poslovnih transakcija, odnosno poslovnih objekata. Poslovni transakcioni
model ima tri osnovne komponente pod nazivom „Person” (osoba), „Process” (proces) i
„Data” (podaci). Ove tri fundamentalne komponente poslovnog transakcionog modela
(Business Transaction Model – BTM) su reprezentovane grafički na slici 80.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 178
Slika 80. Poslovni transakcioni model - osnovni elementi
Koristeći UML kao formalnu deskriptivnu tehniku dolazimo do sledeće UML
reprezentacije poslovnog transakcionog modela, koji je prikazan na slici 81.
Slika 81. UML reprezentacija slike 80.
Poslovni transakcioni model se fokusira na osnovne potrebe razmene informacija
između učesnika sa sledećim osnovnim karakteristikama: da akcije slede jasno
definisana pravila, da su uključene obaveze strana, da je uspostavljanje obaveza između
osoba automatizovano, da učesnici kontrolišu i održavaju svoj status, da učesnici
učestvuju autonomno, da mnogostruke istovremene transakcije mogu biti podržane uz
sledeće zahteve: jasno definisana dogovorena upotreba, sa eksplicitno definisanim
jednoznačnim ciljem, ranije definisan skup aktivnosti i/ili procesa, predefinisani i
strukturirani podaci [56], obaveze među osobama, koje se uspostavljaju kroz
elektronsku razmenu podataka.
Poslovni transakcioni model ima dve klase ograničenja i to: internu klasu ograničenja i
eksternu klasu ograničenja [47]. Ove dve klase ograničenja poslovnih transakcija su
ilustrovane na slici 82.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 179
Slika 82. Poslovni transakcioni model: klase ograničenja
Identifikacija kategorija poslovnih subjekata EPPS-a: U skladu sa definicijom pojma
Person u platnim sistemima imamo sledeće REA agente:
• Retail_Person (osoba koja učestvuje u prometu „na malo“)
o pravno lice;
o fizičko lice (svako ljudsko biće koje ima zakonska prava da inicira
plaćanje);
• Agent plaćanja
o Pravno lice koje ima zakonom priznate i odobrene servise za pravna,
fizička lica i finansijske organizacije;
• Banka
o U skladu sa definicijom BIS-a;
• Klirinška kuća
o U skladu sa definicijom BIS-a;
• Centralna banka
o U skadu sa definicijom BIS-a.
Identifikacija kategorija poslovnih resursa EPPS-a: U skladu sa definicijom pojma
Resurs, u platnim sistemima imamo sledeće REA resurse:
• roba: koja pripada trgovinskom lancu i može biti prezentovana u sistemu koji se
naslanja na platni sistem;
• pravo: fizičko lice sa svojim pravima nad instrumentom plaćanja, platnim
računima i porukama za iniciranje plaćanja;
• uslužni servis: može biti isporučen od strane platnih agenata, banaka, klirinških
kuća i centralne banke.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 180
Identifikacija kategorija poslovnih događaja EPPS-a: U skladu sa definicijom pojma
Event, u platnim sistemima imamo sledeće REA događaje:
• korišćenje platne instrukcije;
• ekstrahovanje platne instrukcije iz platnog instrumenta od strane banke;
• ekstrahovanje platne transakcije iz platne instrukcije od strane klirinške kuće;
• razne kalkulacije procesora, instrukcije poravnanja i slično.
5.6 Provera validnosti poslovne transakcije EPPS-a
Registraciono telo prilikom svakog slanja poruke i odgovora na poruku od svih učesnika
u sistemu prima istu takvu poruku i skladišti je. Registraciono telo ima zadatak da
arhivira poruke i potvrde prijema i na taj način za treća lica, na specijalan zahtev, na
primer za potrebe sudskog veštačenja, učini procese elektronskog poslovanja sledljivim
i neporecivim. Svi dokumenti su potpisani i imaju potpisane potvrde prijema od strane
učesnika koji je poruku dobio. Primer registracionog tela u finansijskoj industriji
prilagođenog posebnim aktivnostima poslovnih procesa Kompanije Dunav osiguranje je
Dunav arhiva, sistem za čuvanje poslovnih poruka i arhivističke dokumentacije.
Arhivističke kategorije kao što su način rukovanja i izdavanja dokumenata, tip
dokumenta, kategorija dokumenta i kategorija vreme čuvanja propisani su zakonskom
regulativom i internim dokumentima sistema. Jedno Registraciono telo postoji i u
Udruženju osiguravača u Beogradu, koji je specijalizovan za izdavanje registracionih
brojeva polisa i čuvanje dokumenata osiguravajućih društava u poslovima izdavanja
polisa autoodgovornosti, odnosno obaveznog osiguranja vozila u saobraćaju. Sistem u
Udruženju osiguravača na zahtev osiguravajućih društava izdaje dokumente koji su
pohranjena u sistemu na osnovu kojih osiguravač ostvaruje popust prilikom ugovaranja
obaveznog osiguranja vozila.
Usluge Registracionog tela moraju da budu usklađene sa zakonskom regulativom uz
poštovanje aspekata ekonomske efikasnosti, zaštite životne sredine i, iznad svega,
aspekta bezbednosti. U registracionom telu svi procesi treba da se konstantno
nadgledaju i evidentiraju od strane edukovanog osoblja. Na taj način se ustanovljava
zatvoren bezbednosni sistem u kome se svi procesi konstantno prate. Da bi moglo da
garantuje apsolutnu sigurnost toka operacija Registraciono telo treba da vrši nadzor
samostalno uz periodični eksterni ekspertski nadzor.
Bezbednosni standardi, redovna obuka zaposlenih, kontinuirano praćenje procesa u
skladu sa međunarodnim standardima, poverljivo uništavanje u skladu sa DIN 32757,
protivprovalni sistem, kontrola pristupa, video nadzor sa digitalnim zapisom događaja,
zaštićena baza podataka sa backup-om, dizaster sajtom, laka pretraga dokumentacije,
napredno indeksiranje, praćenje svih operacija, izdavanje potvrda o uništenju,
neprestano nadgledanje i obnavljanje resursa neki su od aspekata koji moraju da se
obezbede na pravi način. Potrebno je obezbediti praćenje svih operacija, posebno vršiti
trace pristupa i pregleda dokumenata koje je potrebno čuvati pod posebnim uslovima.
Neke od sekundarnih prednosti ovakvog tretiranja dokumentacije su: optimalno
iskorišćenje prostora, smanjenje troškova, zaštite, izbegavanje troškova prostora za
arhivu i održavanje istih, stabilnost troškova arhiviranja, predvidljivi troškovi
arhiviranja, olakšano praćenje rokova dokumentacije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 181
5.6.1 Sistem provere podataka
Procesi koji su dozvoljeni u okviru registracionog tela su Insert, View, Move. Proces
Update ne postoji, pa ukoliko želi da se popravlja stanje zapisa u Registracionom telu,
onda se prave novi zapisi koji su ravnopravni sa postojećim, i prilikom veštačenja se
uzimaju svi zapisi ravnopravno, kao i razlog zbog kojeg je postojala potreba za
procesom Update. Proces Delete nije dozvoljen i ukoliko želi da se popravlja stanje
zapisa u Registracionom telu, onda se prave novi zapisi koji su ravnopravni sa
postojećim, i prilikom veštačenja se uzimaju svi zapisi ravnopravno, kao i razlog zbog
koga je postojala potreba za procesom Delete.
Proces View je moguć uz posebne administrativne dozvole i ukoliko se poznaju potrebni
elementi za pronalaženje dokumenta, odnosno ukoliko je poznat broj potvrde prijema.
Tehnike pretraživanja i pretraživanja sekundarnih baza podataka sa izvedenim
skupovima podataka daju veću fleksibilnost u pretrazi i mogućnost semantičkog
povezivanja zapisa dostupnim tehnologijama. Binarni zapisi se pre potpisivanja
konvertuju u base64 format koji nije moguće pretraživati na standardan način, ali mogu
se pretraživati sekundarne baze podataka nastalih iz binarnih formi na standardan način
i može se vršiti povezivanje sa primarnim bazama. Prilikom stvaranja sekundarnih baza
podataka mogu da se koriste i tehnike optičkog prepoznavanja, prepoznavanja govora,
oblika i drugih tehnika. Na taj način multimedijalne informacije mogu postati dostupne i
mogu da se vrše povezivanja multimedijalnih artifakata sa bazama primarnih
dokumenata, i da se obogaćuju postojeće veze između dokumenata, ali i da se stvaraju
nove, koje mogu dati nove poglede na dokumentaciju pohranjenu u Registracionom
telu. U zdravstvu, podaci koji su neophodni za poslovne procese su multimedijalni,
recimo, savremeni zdravstveni karton, pa je jasno i da je od posebnog interesa za
ovakav sistem administracija sistema koja mora da zadovolji sve aspekte bezbednosti i
zaštite sistema Registracionog tela.
5.6.2 Sistem provere koraka poslovnih procesa
Proces View u registracionom telu omogućava pronalaženje dokumenata, uz posebne
administrativne dozvole i ukoliko se poznaju potrebni elementi, odnosno ukoliko je
poznat referentni broj transakcije. Referentni broj transakcije omogućava pronalaženje
svih instrukcija i poruka u kojima se navedena transakcija u procesu izvršenja nalazila,
odnosno potpunu rekonstrukciju procesa kroz koji je transakcija sa traženim referentnim
brojem prošla.
5.7 Metode integracije platnih sistema
U finansijskoj industriji uobičajena je razmena poruka povezanih sa izvršenjem
finansijskih instrukcija [22]. Razmena poruka podrazumeva korišćenje uzoraka [172],
[72] sa sledećih aspekata: tačaka sa kojih se vrši razmena poruka, sadržaja i konstrukcije
poruke, usmeravanja poruke, transformacije poruke, izbora kanala prosleđivanja poruke,
upravljanja sistemima razmene poruka. Svaki od navedenih aspekata podržan je sa više
uzoraka; na primer, za transformaciju poruke poznati su sledeći uzorci: Message
Translator, Envelope Wrapper, Content Enricher, Content Filter, Claim Check,
Normalizer, Canonical Data Model [90]. Važno je napomenuti da su opisani uzorci
namenjeni integraciji, a ne i dizajnu softvera. Uzorci vezani za dizajn navedenih sistema
[231], iako od velikog značaja za ovu tematiku, nisu predmet ovog rada.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 182
Sistem se mora implementirati da bi se obezbedio (saglasno dizajnu) visok nivo
skalabilnosti, a posebno sa aspekta uvećanog obima podataka u postojećim bazama
podataka, prenos informacija, uvećanje broja raspoloživih servisa i uvećanje broja
korisnika servisa. Obezbeđivanje skalabilnosti ne treba uticati na održavanje traženih
nivoa sigurnosti, raspoloživosti i performansi. Povećanje poslovnog opterećenja sistema
primarno bi mogao da bude prouzrokovano povećanjem količine informacija snimljenih
u postojećim bazama podataka informatičkih sistema koje postoje u institucijama
uključenih u sistem, povećanjem broja transakcija, povećanjem broja servisa,
povećanjem složenosti transakcija, povećanjem kompleksnosti servisa, povećanjem
broja korisnika (krajnjih korisnika ili drugih sistema elektronskog poslovanja).
Sistem mora biti implementiran na takav način da omogući povećanje kapaciteta
procesiranja, bez promena u arhitekturi. Dizajn sistema treba da obezbedi da se
adaptibilnost i proširivost ne desi po ceni opadanja sistemskih performansi
svakodnevnog rada. Potrebno je implementirati sledeće zahteve: dodavanje novih
usluga, dodavanje novih tipova podataka (mogući su multimedijski i biometrijski
podaci), dodavanje novih metaopisa, dodavanje novih korisnika i uloga, dodavanje
novih servisa, kreiranje novih servisa koji predstavljaju kombinaciju postojećih,
implementaciju polisa i pristup servisima, implementaciju polisa i pristup podacima
preko korišćenja servisa.
U dizajn sistema potrebno je ugraditi medijatorske interfejse koji treba da izvrše
prilagođavanje formata podataka preko njihove konverzije u jedinu XML šemu. Uvek
kad postoje, treba da se upotrebljavaju standardi za razmenu podataka.
Sigurnosni, odnosno bezbednosni zahtevi interoperabilnosti definisani su u standardu
ISO 17799 koji pokazuje sigurnost informatičkih sistema kao rezultat dizajniranja,
sprovođenja, rukovođenja i kontinuiranog unapređenja. Zbog sigurnosti informacija
moraju se primenjivati sigurnosne polise i periodično se revidirati i ažurirati u odnosu
na rizik za narušavanje sigurnosti. Polise su definisane: opisom strana involviranih u
servisu, korisnicima, administratorima, rukovodiocima i kontrolnim telima. Uloge i
odgovornosti strana uključenih u obezbeđivanje servisa sa aspekta primene i upravljanje
polisama moraju biti jasno definisane, identifikovane i periodično kontrolisane. Kao
podrška polisama, mora se obezbediti mogućnost definisanja aplikativne podrške
operativnim procedurama, koje prenose principe sigurnosne politike u praksi (u
različitim tehnološkim sredinama, za različite korisnike i sistemske operatore). Glavne
operativne procedure su: procedure koje omogućavaju prikladnu zaštitu, snimanje
zaštitnih kopija i arhiviranje definisanih servisa, koji će obezbediti mogućnost za
obnavljanje dostupnosti servisima nakon eventualnih prekida u radu; procedure za
monitoring i kontrolu svih nivoa infrastrukture koje su povezane sa postupcima za
verifikaciju i kontrolu, što omogućava otkrivanje i sleđenje preuzetih operacija pri
korišćenju servisa; procedure za upravljanje nedozvoljenim zahtevima za korišćenje
usluge i odgovarajuće reakcije u slučaju prestupa ili problema u sigurnosti sistema;
procedure za autorizaciju i pristup sistemu; procedura za kreiranje, upravljanje i brisanje
korisnika; procedura za primenu kriptografske zaštite. Jasno se mora definisati: gde, za
koje poruke i kad treba koristiti kriptografsku zaštitu, kako se upravlja ključevima
kriptografske zaštite, kako reagovati u slučaju problema sa zaštićenim porukama ili pri
gubljenju sertifikata ili ključeva za kriptografsku zaštitu, procedure za povezivanje
prema postojećim informacionim sistemima u institucijama, postupak koji mora
uključivati i definisanje osnovnih nivoa sigurnosti, periodične provere i zaštitne mere
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 183
koje treba preduzeti. Servisi su predmet kontrole i moraju obezbediti način za sledljivost
porekla i prava korisnika servisa. Pri tome treba voditi računa o regulisanju dostupnosti
usluga spoljašnjim telima, opisu domena bezbednosti u saglasnosti sa nacionalnim i
internim sigurnosnim regulativama, polisama nacionalnog nivoa, polisama određene
institucije i slično, klasifikacijama informacijama i odgovornosti u skladu sa evropskim
bezbednosnim regulativama Saveta Evropske unije, o definisanju prava pristupa i
ograničavanju pristupa podacima, definisanju bazičnog nivoa bezbednosti (politike
poverenja), koje se primenjuje na sve strane koje komuniciraju sa sistemom za državnu
interoperabilnost.
Moraju se obezbediti postupci za centralnu evidenciju koji obezbeđuju periodičan
monitoring uključujući upravljanje alarmima pri korišćenju servisa. Vazno je
napomenuti da evidentiranje ne obuhvata same podatke, nego samo korisnike servisa,
tip servisa i metaopisa servisa. Aktivnosti koje treba da se evidentiraju uključuju sve
potražnje za korišćenjem servisa, sve odgovore potražnje uspešne i neuspešne, metaopis
servisa, sve pristupe sistemu i sve izvršene događaje, kao i neuspešne ili neovlašćene
pristupe sistemu. Centralna evidencija mora omogućiti administratorima da slede
aktivnosti po vremenu njihovog izvršenja i da identifikuju korisnike koji su izvršili
svaku pojedinačnu aktivnost, i po potrebi, mora pomoći u identifikaciji krajnjih
korisnika. Zbog toga što se nijedna aktivnost ne može izvršiti ukoliko se ne može
evidentirati, sistem evidentiranja mora uvek biti na raspolaganju i mora predvideti
sekundarni bekap podataka za evidenciju.
Podaci sa evidencije se ne mogu modifikovati. Podaci evidencije se ne mogu brisati pre
zakonskog datuma isticanja važnosti. Svaki korisnik mora biti u mogućnosti da pregleda
evidenciju svih aktivnosti izvršenih sa njegove strane ili aktivnosti izvršenih na
njegovim podacima. Možda će biti potrebno evidenciju transakcija korisnika vratiti
korisniku pa zbog toga treba obezbediti mere za pojednostavljenja ovog zadatka.
Evidencija se isto tako može koristiti i u statističke ciljeve. Moraju se razviti funkcije ili
alati za izveštavanje i analizu kako bi se obezbedili izuzeci u upotrebi i obradive
informacije recenzentima.
U narednim poglavljima će biti opisana integracija i to na sledećim nivoima:
• na nivou procesa razmene podataka u poglavlju 5.7.1;
• na nivou pretprocesiranja u poglavlju 5.7.2;
• na nivou procesiranja podataka u poglavlju 5.7.3;
• na nivou postprocesiranja u poglavlju 5.7.4.;
• na nivou registrovanja razmene u poglavlju 5.7.5.
5.7.1 Razmena podataka
Poslovna integracija može da se postigne i primenom posebnog aplikativnog sloja koji
omogućava podsistemima jednog poslovnog sistema da budu u interakciji. Na taj način
čine jedinstven sistem sa unijom skupa funkcionalnosti svih integrisanih sistema. Danas
je situacija takva da su neke aplikacije u poslovnim sistemima razvijene samostalno,
dok ostale mogu biti nabavljene od različitih nezavisnih proizvođača. Takvi aplikativni
sistemi često rade na različitim računarskim sistema, na raznovrsnim platformama, a
mogu biti i geografski distribuirani.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 184
Aplikativni sistemi mogu da budu nekad korišćeni od strane poslovnih partnera ili
klijenata, odnosno integrisani sa njihovim sistemima [90]. Često aplikativni sistemi
moraju da budu integrisani iako nisu dizajnirani sa namerom da rade u interakciji sa
drugim sistemima i ne mogu iz raznih razloga da budu menjani.
№ NAZIV OPIS
1. PRENOŠENJE DATOTEKA
Standarizovana, strukturirana datoteka može biti nosilac potrebnih
skupova informacija između dva sistema i na taj način može biti
integracioni faktor sistema.
2. DELJENJE BAZE PODATAKA
Aplikativni sistemi mogu da se integrišu putem iste, deljene baze
podataka, deleći iste podatke koji su uskladišteni u bazi.
3. POZIVANJE UDALJENE PROCEDURE
Integracija može da se izvrši i tako što jedan aplikativni sistem izloži
odgovarajući skup procedura i dozvoli drugom sistemu da ih sa
odgovarajućim inicijalnim podacima poziva i inicira ili izazove
odgovarajuće ponašanje ili prostu razmenu podataka.
4. RAZMENA PORUKA
Poruka koja se sastoji od zaglavlja i tela koje nosi informacije potrebne
ishodišnom sistemu daje mogućnost integracije putem posebno
razvijanih sistema za razmenu poruka.
Tabela 13. Načini integracije
Integrisane aplikacije bi trebalo da minimiziraju svoju zavisnost jedne od drugih, tako
da svaka može da se nezavisno razvija bez izazivanja dodatnih problema za ostale.
Interfejs za integraciju aplikacija treba da sprovede zadate funkcionalnosti, ali i da bude
dovoljno uopšten da se prilagodi promeni kada je to potrebno. Integraciju je poželjno
izvesti na način da procesi u sistemima mogu da se odvijaju asinhrono. Ukoliko se
izvrši projektovanje i organizacija sistema tako da procesi budu asinhroni, izvršiće se
bez čekanja oni za koje su ispunjeni uslovi za pokretanje i na taj će se način smanjiti
značajan utrošak vremena i ostalih resursa, koji je prisutan u nekom tačno određenom
sinhronom scenariju.
Postoji više pristupa integraciji aplikativnih sistema od kojih svaki ima svoje dobre i
loše strane. Integracija se u suštini sastoji od razmene određenih, unapred definisanih
klasa podataka i eventualnog iniciranja određenog ponašanja u zavisnosti od sadržaja
podataka. Tabela 13. daje pregled osnovnih načina integracije koji se danas koriste.
U svakom konkretnom slučaju integracije potrebno je izabrati najadekvatniji način jer
nijedan od navedenih nije univerzalno najbolji niti najelegantniji.
Integracija prenosom datoteka: Fajlovi su univerzalno skladište podataka koje svi
aplikativni sistemi mogu da koriste uz pomoć odgovarajućih exstraktora i loadera, kao
što je to ilustrovano na slici 83. Aplikativni sistemi proizvode i učitavaju fajlove ili u
odgovarajućim intervalima ili aktivirani nekim događajem, u skladu sa prirodom
procesa. Pri tome je i transformacija fajlova u različite formate vrlo često neophodna
iako je standardizacija na globalnom nivou dostigla zavidan nivo.
Slika 83. Prenos datoteka
Sistem 1 Sistem 2
FAJL
extractor loader
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 185
Prilikom razmene fajlova, potrebno je rešiti probleme imenovanja fajlova, istovremenog
pokušaja čitanja i upisa podataka od različitih sistema, odlučivanja kada fajl više nije
aktuelan i kada ga treba obrisati, prenosa fajlova sa jedne strukture foldera na drugi,
prenosa fajlova sa jednog sistema na drugi ukoliko su sistemi udaljeni.
U poslednje vreme mnoge organizacije za standardizaciju u raznim oblastima ljudskog
delovanja koriste XML u izgradnji savremenih standarda. Postoje i mnoge kompanije
koje se bave isključivo proizvodnjom komponenata za učitavanje, ekstrahovanje i
transformaciju podataka. Takođe, na tržištu softverskih alata možemo pronaći vrlo lako
pregršt alata koji mogu da se koriste za profesionalnu namenu čija je kompleksnost za
korišćenje skoro na nivou office aplikacija.
Integracija deljenom bazom: Ukoliko aplikacije koriste isti sistem za upravljanje
bazama podataka, postoji mogućnost da aplikacije budu u interakciji zahvaljujući
deljenoj bazi podataka, i na taj način budu integrisane, kao što je to prikazano na slici
84. Ukoliko se jedna klasa svih integrisanih aplikacija oslanja na istu bazu podataka,
onda možemo biti prilično sigurni da se oni mogu uvek koristiti dosledno, što nam
garantuju mehanizmi baza podataka. Mogućnost determinisanja transakcija,
zaključavanje slogova i mogućnost ažuriranja podataka iz različitih izvora daju potrebne
elemente za upravljanje integracijom sistema.
Slika 84. Deljenje baze podataka
Sama integracija, implementacija komponenata, korekcije u sistemu i slične operacije
[125] obavljaju se brzo i na standardan način od strane administratora baza podataka.
Postoje mnogi dostupni alati koji još više olakšavaju navedene operacije. Važno je
napomenuti i jednu nepovoljnu činjenicu za ovu vrstu integracije, a to je da je veoma
teško implementirati unificiranu bazu podataka koja bi zadovoljila određen broj
različitih sistema, pogotovu zbog mogućih sukobljenih potreba različitih sistema, kao
što je brzina pristupa podacima potrebna jednom sistemu i složenost modela podataka
koji je potreban drugom sistemu. Isto tako, u slučaju integracije deljenom bazom
podataka, Često mogu nastati problemi koji su u vezi sa vlasništvom nad podacima, te
se ovaj način integracije ne bi mogao preporučiti sistemima koji imaju suprotstavljene
interese u odnosu na iste ili slične klase podataka.
Integracija pozivom procedura: Izmena podataka može da bude prosta, da se izvrši
promena vrednosti jednog ili više atributa. Međutim, veoma često izmena jednog ili više
atributa može biti kompleksna operacija: promena prezimena može da pokrene i niz
drugih procesa koji mogu da se odvijaju sekvencijalno ili paralelno. Udaljeni poziv
procedure poseduje interfejs iza koga mogu biti sakriveni podaci i procedure koji su
pokrenuti. Identifikacioni broj osobe i novo prezime mogu biti potrebni podaci koji
Sistem n Sistem1
Sistem 2
BAZA PODATAKA
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 186
pokreću udaljenu proceduru, koja inicira sve odgovarajuće izmene i sve akcije koje je
potrebno preduzeti u tom slučaju. U slučaju udaljenog poziva procedure potrebno je da
jedan sistem obezbedi interfejse i da dozvoli njihovo korišćenje drugim aplikativnim
sistemima, kao što je prikazano na slici 85.
Slika 85. Integracija udaljenim pozivom procedure
Bitna činjenica je da svaki aplikativni sistem može da održava integritet svojih
podataka. Isto ako, svaki sistem održava i skup svojih interfejsa, a nepovoljna činjenica
je da za jednu istu strukturu podataka može da postoji veći broj različitih interfejsa za
različite korisnike aplikativnih sistema. Svaka izmena jednog sistema sa velikom
verovatnoćom povlači i moguće izmene u interfejsima koji se izlažu dugim sistemima i
na taj način se smanjuje nezavisan razvoj različitih na ovaj način integrisanih sistema.
Bus je podsistem koji se koristi za transfer podataka između aplikativnih komponenata u
jednom računarskom sistemu ili između aplikativnih komponenata različitih računarskih
sistema.
Razmena poruka korišćenjem Message Bus-a vrši se na pouzdan način uz pomoć
različitih i prilagodljivih formata poruka, kao što je prikazano na slici 86. Prenos može
biti i asinhron i to je rešenje u situaciji kada distribuirani sistemi nisu u mogućnosti da
budu dostupni.
Slika 86. Sistem za razmenu poruka
Enterprise Service Bus (ESB) predstavlja okruženje sačinjeno da unapredi sofisticiranu
povezanost između servisa. Ono ustanovljava međusloj za pretprocesiranje koje pomaže
da se prevaziđe određen skup problema povezanih sa pouzdanošću, skalabilnošću i
nejednakošću po pitanju komunikacionih mogućnosti. ESB je sačinjen od niza uzoraka
kao što su: asinhroni red čekanja, posrednik servisa (transformacija modela podataka,
transformacija formata podataka, premošćavanje protokola), rutiranje, pouzdan prenos
poruka, centralizacija polisa, centralizacija pravila i prenos poruka iniciranih
događajima [69].
Sistem 1
R
P i Sistem 2
Sistem n Sistem Sistem 2
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 187
5.7.1.1 Komunikacija zasnovana na porukama
Poruke koje se razmenjuju u savremenim sistemima različitih namena tretiraju se kao
dokumenti i to u elektronskoj formi. Da bi poruke (dokumenti) mogle da se razmenjuju
na zakonski i informatički konzistentan način za potrebe projekata platnog sistema bilo
je potrebno definisati dokument, klase dokumenata, formu dokumenata i način
pojavljivanja [158].
Definicija dokumenta:
a) Dokument izdaje autorizovano, odgovorno i kvalifikovano lice;
b) Sadržaj dokumenta služi za proveru verodostojnosti prezentovanih informacija
i/ili stvaranje novog dokumenta;
c) Svaki dokument sadrži informacije uz pomoć kojih je moguće utvrditi njegovu
verodostojnost.
d) Dokument opisan sa a.), b.) i c.) može biti izdat i u elektronskom formatu.
Klase dokumenata:
• Zakonski dokument (dokument kojim nadležni organ odobrava, propisuje,
verifikuje i kvantifikuje predmet zakonske regulative;
• Dokument standarda (potreban je za determinisanje tehnoloških sistema);
• Tehnološki dokument (potreban za interakciju tehnologa sa tehnološkim
procesom u svrhu obavljanja tehnoloških procesa, odlučivanja i upravljanja
sistemom).
Forma dokumenta:
• Papirna forma (priređena ručno, mašinski ili mešovito);
• Forma priređena IT resursom (može biti kao strukturiran izveštaj koji koristi kao
izvor strukturirane podatke – recimo iz baze podataka ili kao nestrukturiran
izveštaj jer sadrži tehnološko znanje o sistemu – recimo HELP aplikacije;
• forma priređena kao bilo koji vid publikacije;
• usmena izjava kao dokument (samo ako je osoba koja usmeno izgovara sadržaj
odgovorna, kvalifikovana i autorizovana).
Način pojavljivanja dokumenta:
• kao osnova za novi poslovni proces tehnološkog sistema;
• kao interakcija sa poslovnim procesom;
• kao posledica tehnološkog procesa.
Tokom svog životnog ciklusa dokument prolazi kroz sve pojavnosti dokumenta. Javlja
se kao posledica tehnološkog procesa (npr. u Ministarstvu unutrašnjih poslova), u
interakciji je sa poslovnim procesom (npr. prilikom legitimisanja pri ulasku u saveznu
ustanovu) i kao osnova za poslovni proces otvaranja tekućeg računa (utvrđivanje
identiteta budućeg vlasnika tekućeg računa). Sistemi bazirani na standardima definisani
su oko jednog ili više objekata, „nosilaca“ standarda. U slučaju standardizovanih
finansijskih poruka, osnovni objekti su instrukcije potrebne za obavljanje finansijskih
transakcija. Za svaki objekat moraju da se opišu operacije kreiranja, čitanja, izmene i
brisanja (create, read, update i delete). Ove operacije se predstavljaju odgovarajućim
porukama. Da bi sistem bio konzistentan, mora postojati način da se pristupi objektima
sistema uz pomoć poruka, te mora postojati poruka za postavljanje upita, kao i poruka
za prosleđivanje odgovora. Primalac informacija bi u tim sistemima trebalo da ima
mogućnost da prihvati prijem, odnosno odgovornost nad porukom sa odgovorom ACK
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 188
(acknowledge), ili da odbije prijem, odnosno da ima mogućnst da saopšti da ne želi da
prihvati odgovornost nad porukom sa odgovorom NAK (negative acknowledge), bilo iz
pravno formalnog ili iz organizacionog aspekta. Objekti nad kojima sistemi nemaju
ingerenciju opisuju se atributima koji se nalaze u šifarnicima sistema.
Prilikom standardizacije nekog sistema, ili proučavanja već standardizovanog sistema,
potrebno je prvo uočiti osnovne objekte sistema i poruke koji se odnose na njih.
Procesiranje poruka na ishodišnoj lokaciji, odnosno obrada informacija iz tako
standardizovanih poruka, svodi se na prostu primenu skupa potrebnih operacija nad tim
podacima. [17]
5.7.1.2 Poruka
Poruka je, uopšteno govoreći, objekat za komunikaciju. Ona obezbeđuje informaciju, a,
takođe, sama može da bude informacija. Dakle, njeno značenje je zavisno od konteksta
u kome se pojavljuje – koristi [158]. Termin „poruka” može da se primeni i na
informaciju i formu.
Tranzijent je kratkoživuća oscilacija u sistemu prouzrokovana iznenadnom promenom
kontinualnih parametara u sistema; softverski objekat sa kratkim i ograničenim životnim
vekom koji se ne čuva za kasnije ponovno korišćenje.
Perzistentnost određuje karakteristiku podataka koji nadživljavaju izvršenje programa
koji ih je kreirao: koji je primenjen u praksi smeštanjem podataka u skladište kao što je
file sistem ili relaciona baza podataka ili objektna baza podataka. Bez ove osobine,
strukture podataka postoje samo u memoriji i biće izgubljene nakon prestanka rada
programa. Perzistentnost omogućava da program bude restartovan i ponovo učitan sa
strukturom podataka iz prošlog poziva programa. Paterni za dizajniranje koji rešavaju
ovaj problem su container based persistence, component based persistence i Data
Access Object model [174].
5.7.1.3 Sistemi bazirani na porukama - Message Oriented System (MOS)
Remote Procedure Call ili skraćeno RPC i Data Object ili skraćeno DO su proširili
uobičajene (single-process) modele programiranja na distribuirano okruženje. Oni su
učinili komunikaciju transparentnom ili implicitnom. Message Oriented Middleware ili
skraćeno MOM uveo je novi model za programiranje distribuiranih aplikacija baziranih
na eksplicitnoj komunikaciji, koja može da bude transijent ili perzistent [174]. Slika 87.
prikazuje model MOM-a, tj. primer generalne organizacije komunikacionog sistema u
kome su hostovi povezani kroz mrežu. Dva aplikativna sistema na slici 87. povezani su
preko komunikacionih servera i mreže. Da bi aplikativni sistem mogao da komunicira
preko komunikacione infrastrukture prikazane na slici, mora da poseduje interfejs za
poruke, preko koga vrši slanje i primanje poruka. Komunikacioni server, u lokalu,
prihvata poruku i uz pomoć programa za rutiranje vrši odgovarajuće „pakovanje“
poruke i sa takvim porukama puni lokalni bafer koji je nezavisan od komunikacionih
kanala. Iz bafera, odgovarajućim komunikacionim mehanizmima, poruka se prosleđuje
na naznačenu adresu preko definisane mreže. Komunikacioni server, na koji je
adresirana poruka, prima poruku i skladišti je u odgovarajući bafer. Poruka u baferu je
od tog trenutka nezavisna od komunikacije i preko programa za rutiranje prosleđuje se
odgovarajućem lokalnom aplikativnom sistemu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 189
Slika 87. Model Message Orijented Middleware-a
5.7.1.4 Perzistentnost i sinhronost
Sistem može biti i takav da primalac i pošiljalac ne moraju u isto vreme da budu prisutni
na komunikacionoj magistrali. Ta vrsta komunikacije naziva se perzistentna. To je
osobina koja se koristi kod Fire and Forget mehanizama za slanje poruke, gde
pošiljalac poruke pošalje poruku i u sledećem trenutku „zaboravi” da je poslao, odnosno
sistem pošiljaoca nakon slanja više ne vodi računa o poruci koju je poslao. Primer
perzistentne komunikacije je prikazan na slici 88. Poštar donosi poštu koja je ubačena u
ulični poštanski sandučić i nakon predaje pošiljke u poštanski bafer na svom ishodištu
sigurno ne prati šta se događa sa pošiljkom nakon predaje.
Slika 88. Perzistentni model
Različiti komunikacioni modeli mogu da budu upotrebljeni u nekom sistemu. Izbor
zavisi od dosta parametara, ali svi su vezani u krajnjoj instanci organizacijom posla koji
se obavlja sadržajem poruke, mogućnošću izbora komunikacionog kanala i zahtevom da
li na poruku u „istoj ruci” mora da se nađe prijemnica poruke ili ACK poruka, odnosno
odbijenica poruke NAK poruka. Na slikama 89, 90. i 91. prikazani modeli su sa
različitim osobinama u odnosu na stalnost prisustva učesnika u komunikaciji i
sinhronizaciju potvrde prijema.
Slika 89. prikazuje perzistentnost i sinhronost u komunikaciji:
a. Perzistentna asinhrona komunikacija
b. Prezistentna sinhrona komunikacija
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 190
Slika 89. Perzistentnost i sinhronost u komunikaciji
Slika 90. prikazuje tranzijentnost i sinhronost u komunikaciji:
c. Tranzijentna asinhrona komunikacija
d. Tranzijentna sinhrona komunikacija bazirana na potvrdi
Slika 90. Tranzijentnost i sinhronost u komunikaciji
Slika 91. prikazuje tranzijentnu sinhronu komunikaciju baziranu na isporuci poruke i
potvrdi:
e. Tranzijentna sinhrona komunikacija bazirana na isporuci poruke
f. Tranzijentna sinhrona komunikacija bazirana na potvrdi poruke
Slika 91. Tranzijentna sinhrona komunikacija bazirana na isporuci i potvrdi
5.7.1.5 Redovi za čekanje
Redovi za čekanje svojom paradigmom omogućavaju perzistentnost. Postoje četiri
kombinacije za slabo povezanu komunikaciju koja koristi redove za čekanje i ona je
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 191
ujedno model redova za čekanje, koji su prikazani na slici 92. Primer modela reda za
čekanje poruka koji svakodnevno koristimo je e-Mail.
Slika 93. je generalna arhitektura redova za čekanje poruka sa vezom između
adresiranja redova za čekanje i mrežnog adresiranja. I primalac i pošiljalac imaju svoju
internu adresu, odnosno adresu na nivou reda za čekanje sa kojom komunicira logički
aplikativni nivo.
Slika 92. Model redova za čekanje
Na nivou reda za čekanje vrši se translacija tih adresa i mapiranje na adrese
transportnog nivoa. Na taj način pošiljalac i primalac mogu komunicirati po modelu
redova za čekanje prikazanom na slici 92. Sistem redova za čekanje može biti obogaćen
i sa ruterima poruka tako da adresiranje ne mora da bude direktno.
Slika 93. Uopštena arhitektura modela redova za čekanje
Nad sistemom redova za čekanje mogu da se izgrade složene sistemske aplikativne
organizacije u cilju veće automatizacije poslovnih procesa. Slika 94. opisuje jednu
takvu organizaciju - broker poruka, nad sistemom redova za čekanje. Broker poruka
može adaptirati format poruke pre isporuke i ta osobina se na značajan način može
iskoristiti u optimizaciji izgradnje sistema. U širem smislu, broker može sadržati čitav
niz pretprocesiranja i postprocesiranja poruka.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 192
Slika 94. Broker poruka
Iz prethodno navedenih činjenica, nakon sagledavanja potreba sistema jedne oblasti,
može se na kvalitetan način determinisati standardan sistem za transport. Takav
transport je moguće izgraditi, recimo, za sistem finansijske industrije, i on će bez
potrebe dograđivanja moći da pokrije ukupne potrebe za transportom svih vrsta poruka
u oblasti finansijske industrije.
Jedan takav je SWIFTNet sistem koji predstavlja podskup nad gorenavedenim
osobinama komunikacionog kanala. Microsoft je u svom Windows Foundation -
Communication Foundation FX sistemu (beta poznata pod imenom INDIGO) bio
najavio mnogo jače želje - da napravi komunikacioni okvir za sve poslove koji će se
baziraju na razmeni poruka. Svoj sistem je ugradio u Windows Framework koji sada
može da podrži proizvoljan proces message brokera.
Drugi pristup problematici transporta poruka korišćenjem prednosti redova za čekanje je
Advanced Message Queue Protokol [4], specifikacija po kojoj niz nezavisnih
proizvođača softvera već isporučuje upotrebljive open source projekte. U radnoj grupi
za specifikacije učestvuju JPMorgan Chase & Co., Cisco Systems, Inc., Envoy
Technologies Inc., iMatix Corporation, IONA Technologies, Red Hat, Inc., TWIST
Process Innovations Ltd, and West, Inc. Na taj način je obezbeđen nesmetan razvoj
specifikacije samih proizvoda kao i kritična baza korisnika tog protokola.
5.7.1.6 Uzorci za integraciju organizacija - Enterprise Integration Patterns (EIA)
Ovaj rad prikazuje i mogući pristup problematici razmene dokumenata u poslovnim
sistemima korišćenjem uzorka Document Message i način postavljanja adekvatnog
okruženja oko ovog uzorka: determinisanje poslovnih sistema operativnim pravilima,
tehničkim i tehnološkim uputstvima, kao i tehničkim pravilima o formatu i nameni
poruka. Opisan je način na koji se vrši razmena poruka, integracija raznorodnih
poslovnih sistema prenosom podataka putem poruka kao osnovnog sredstva i Enterpise
Service Bus kao najviši nivo organizacije opšte namene na bazi Document Mesage
uzorka.
Do rezultata prikazanih u ovom radu došlo se korišćenjem primera iz bankarske prakse.
Bankarski sistemi su dobro uređeni, u njima su procesi definisani i uređeni u skladu sa
zakonskom regulativom koja je u slučaju banaka i drugih finansijskih institucija
brižljivije propisana zbog same prirode poslova koji su im povereni. Zbog toga, sve
pozitivne i negativne pojave su izraženije u bankarskim sistemima i na bazi toga mogu
se lakše uočavati i proučavati zakonitosti u sistemima uopšte. Jedan od dokumenata
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 193
platnog prometa u Srbiji je Nalog za uplatu (pored Naloga za isplatu, Naloga za naplatu
i Naloga za prenos [128]). Prilikom uplata na šalterima finansijskih organizacija od
popunjenog obrasca, po završetku procesa plaćanja, generišu se dva ravnopravna
dokumenta − po jedan za svaku stranu. Isti proces se može obaviti i korišćenjem
informatičkih resursa, elektronskim putem.
Upravo ta ekvivalentnost rezultata procesa obavljenog na šalteru banke ili procesa
obavljenog samo putem korišćenja elektronskih informatičkih resursa jeste osnova na
kojoj se baziraju osnovne pretpostavke date u ovom radu. Dokument možemo opisati na
sledeći način:
• Dokument izdaje autorizovano, odgovorno i kvalifikovano lice.
• Sadržaj dokumenta služi za proveru verodostojnosti prezentovanih informacija
i/ili stvaranje novog dokumenta.
• Svaki dokument sadrži informacije uz pomoć kojih je moguće utvrditi njegovu
verodostojnost.
U poslovnim procesima dokument se može javiti:
• kao osnova za novi poslovni proces tehnološkog sistema;
• u interakciji poslovnih procesa;
• kao posledica tehnološkog procesa.
Na ovaj način opisan dokument može biti izdat i u elektronskom formatu i predstavlja
dobru osnovu za konzistentnu integraciju poslovnih procesa. Elektronski dokumenti se
danas ne čuvaju na posebnoj lokaciji od strane zakonom propisane posebne institucije
kao što je to propisano zakonskom regulativom za određene vrste papirnih dokumenata.
5.7.1.7 Postupak integracije sistema baziranog na document message uzorku
Uzorak Document Message [90], ilustrovan na slici 95, koristi se za pouzdanu razmenu
podataka između aplikativnih sistema. Document Message uzorak prosleđuje originalne
podatke i omogućava primaocu poruke da se odluči šta će da radi sa primljenim
podacima. Podaci mogu da budu poslati kao količina podataka potrebnih da opišu
pojedinačni objekat, ali i strukturu podataka koja može da se dekomponuje u manje
jedinice. Najvažniji deo Document Message uzorka je sadržaj poruke − dokument.
Slika 95. Document Message uzorak
U Srbiji je 2004. godine objavljen „Zakon o elektronskom potpisu“ koji uređuje
upotrebu elektronskog potpisa u pravnim poslovima i drugim pravnim radnjama,
poslovanju, kao i prava, obaveze i odgovornosti u vezi sa elektronskim sertifikatima.
Sadržaj dokumenta, kao i identitet entiteta koji je kreirao dokument čuva se
potpisivanjem dokumenta. Elektronskim potpisivanjem dokumenta otklanja se
mogućnost lažiranja identiteta, modifikovanja dokumenta i poricanja potpisa. Ukoliko
se dokument šifruje, nije moguć ni neovlašćen pristup sadržaju dokumenta.
POŠILJALAC PRIMALAC
DOKUMENT
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 194
Uspešno prenošenje dokumenta od pošiljaoca do primaoca i vreme kada je dokument
poslat veoma su bitni. Međutim, sam prijem može da bude i odložen, u skladu sa
mogućnostima komunikacionih resursa primaoca. Garantovana isporuka je još jedan
važan aspekt u razmeni podataka Document Message uzorkom. Važan aspekt, u odnosu
na mogućnost prijema je i vreme važenja dokumenta, jer nakon određenog vremena
može i da istekne važnost poslatog dokumenta i poslovni proces koji treba da se obavi
sa takvim dokumentom ne bi bio validan. Isto tako, u komunikaciji jedan na jedan,
važno je da se prilikom prenosa podataka ne pravi duplikat dokumenata, već se uvek
radi samo sa jednim uzorkom − originalom. Document Message uzorkom može da se
prenosi bilo koja poruka iz zadatog sistema poruka. Java Message Service (JMS) API
[160], [181] je standard za razmenu poruka koji omogućava aplikativnim
komponentama baziranim na Java Enterprise Edition platformi da kreiraju, šalju,
primaju i čitaju poruke, sa omogućenom distribuiranom komunikacijom u kojoj
dokument može biti serijalizovani objekat ili objekat sa tekstualnim ili XML sadržajem.
Prilikom upotrebe Document Message uzorka dokument se obično šalje koristeći point-
to-point kanal, za prenos dokumenata iz jednog procesa ka drugom procesu bez
pravljenja duplikata poruke. Iz prethodnog sledi da je uzorak Dokument Message
valjano polazište oko koga se može izgraditi konzistentan sistem [162].
5.7.2 Pretprocesiranje podataka
Problem pretprocesiranja se svodi na uvođenje novih poruka u sistem. Problem
uvođenja novih poruka u sistem i njihovo pretprocesiranje u sistemu može da se delom
automatizuje i da se na taj način dogovori životni ciklus elemenata sistema: uvođenje
novih funkcionalnosti u sistem, izmena starih funkcionalnosti uvođenjem verzija
poruka, ukidanje funkcionalnosti ukidanjem odgovarajućih poruka u sistemu, slika 96.
Nadređeni sistem šalje XML instancu, odnosno poruku sa sadržajem podređenom
sistemu. Sistem primaoca poruke proverava da li je dobijeni fajl XML instanca, da li je
verzija šeme po kojoj je kreirana instanca poznata sistemu i vrši ostale potrebne provere,
kao na primer, da li je instanca od poznatog učesnika, da li je dobar potpis i slično.
Ukoliko je već registrovana, odobrena i implementirana šema, odnosno verzija šeme,
XML instanca se učitava u bazu podataka i izvršavaju se nad njom zadate operacije.
Ukoliko nije, traži se u instanci po kojoj je šemi kreirana instanca. Šema sa zadatim
imenom u instanci, pronalazi se na zadatoj lokaciji, koja je takođe navedena u instanci i
odatle se preuzima.
Na osnovu preuzete šeme generišu se upozorenje Administratoru sistema da je stigla
instanca koja nije podržana u sistemu. Administrator, na osnovu dokumenata o
uvođenju nove šeme:
• daje nalog za generisanje baze (aplikacija – pogled na bazu sa pristiglim
xsd šemama koje nisu odobrene – samo jedno pojavljivanje šeme sa
istim nazivom);
• daje nalog za generisanje baze iz XML šeme;
• po kreiranju šeme daje nalog za kreiranje *.dll-a, odnosno dinamičke
biblioteke, za učitavanje instanci u kreiranu šemu baze podataka (alat
ima mogućnost da za generisanu bazu sam pronađe podrazumevano -
default mapiranje);
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 195
• administrator određuje gde će takva instanca da se učitava
(podrazumevanu - default šemu za tu instancu) – u aplikaciji ima
informaciju da je generisana baza i *.dll, odnosno dinamička biblioteka;
• odobrava da se učitavaju instance te šeme;
• učitava sve postojeće instance šeme u bazu za pretprocesiranje;
• šalje nadređenom sistemu poruku da je izvršeno uspešno prihvatanje
nove instance za pretprocesiranje.
Slika 96. Uvođenje novih funkcionalnosti u sistem
Instance koje pristižu preko sistema za razmenu u ovom trenutku sve mogu da se
prihvataju na pretprocesiranje. Nakon toga, na osnovu dokumenta o uvođenju nove
šeme, Administrator dodaje odgovarajuće operacije za prihvatanje instance iz sistema za
pretprocesiranje u sistem za procesiranje i odgovarajuće operacije za prihvatanje
instance za procesiranje, i šalje nadređenom sistemu poruku da je izvršeno uspešno
prihvatanje nove instance za procesiranje. Spremište za procesiranje i operacije moraju
da budu predefinisani po dokumentima koje je nadređeni sistem prosledio podređenom
sistemu u procesu uvođenja nove zakonske regulative, novih normativa, pravila i slično.
Na ovaj način se omogućava i da proizvoljan broj verzija jedne vrste poruka bude u
opticaju, što zavisi od učesnika koji zadaje pravila u sistemu.
5.7.3 Procesiranje podataka
Poslovna poruka, definisana jednim od standarda (SWIFT MT, ISO20022, EANCOM
ili bilo kojim drugim), sadrži informacije u skladu sa standardom i odgovarajućom
regulativom (zakonskom regulativom, regulativom procesora i drugim pravno
normativnim regulativama) koje se odnose na poslovnu oblast za koju se poruka koristi.
Poruka u sebi sadrži jednu ili više poslovnih instrukcija, a instrukcija u sebi sadrži jednu
ili više transakcija. Prilikom izdvajanja instrukcija iz poruke, ili prilikom izdvajanja
transakcija iz instrukcije, po nekim strogo utvrđenim pravilima, mogu se vršiti
transformacije izvornih informacija zbog potreba poslovnih procesa, odnosno
proizvoditi derivati instrukcija/transakcija. Procesiranje je bilo koji skup operacija nad
instrukcijom/transakcijom ili nad derivatima instrukcije/transakcije. Na primer,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 196
poslovna poruka plaćanja sadrži skup instrukcija i transakcija. Obrada poruke plaćanje
je bilo koji set operacija nad platnom instrukcijom/platnom transakcijom ili nad
derivatima platne instrukcije/platne transakcije.
Primeri operacija nad tako definisanim platnim instrukcijama/platnim transakcijama
mogu biti: ekstrahovanje platne instrukcije iz platnog instrumenta, ekstrahovanje platne
transakcije iz platne instrukcije, izračunavanje sume skupa platnih transakcija,
oduzimanje vrednosti platne transakcije od neke druge vrednosti (na primer, sume
drugih transakcija), odbijanje platnog instrumenta zbog neispunjavanja zadatih uslova u
sistemu (na primer, učesnik koji formira instrukciju je blokiran), odbijanje izvršenja
platne transakcije jer nije ispunjen zadati uslov u sistemu (na primer, ukupan iznos
sredstava na računu neadekvatan) i slično. Na sličan način, možemo definisati druge
tipove procesiranja, odnosno procesiranje instrukcija/transakcija u drugim poslovnim
oblastima.
Način procesiranja poslovnih poruka definiše se tehnološkim procesom obrade poruka.
Tehnološki proces definišu učesnici prema potrebama poslovnog procesa koji podržava,
karakteristikama standarda poruka i operativnim pravilima. Jedan od načina za
tehnološku obradu poruka u klirinškim kućama, ili procesiranje, na primeru iz mašinske
industrije [17] naveden je u tabeli 14.
rbr. Proces Opis
1.
Pribavljanje i provera
administrativnih privilegija za
pristup ulaznim podacima
Sistem za procesiranje proverava da li ima raspoloživog
materijala za procesiranje. Ukoliko utvrdi da ima, proverava
da li ima pravo da ga koristi i da je raspoloživ za procesiranje.
2. Skladištenje ulaznih informacija
Ulazni podaci se preuzimaju, daje im se odgovarajući kontekst
i vrši skladištenje.
3. Procesiranje poslovnih poruka
UML
(pisana tehnologija za primenu tehnološkog procesa obrade)
3.1. Operacija1
3.2. Operacija 2
3.n. Operacija n
4. Skladištenje izlaznih informacija
Nakon procesa obrade iz konteksta informacija vrši se izbor
načina na koji će izlazne informacije da se skladište.
5.
Davanje administrativnih
privilegija za pristup izlaznim
podacima
Nakon skladištenja da bi bili dostupni drugim procesima,
podacima se dodaju administrativne privilegije za pristup.
Uobičajeno je da se grupama podataka dodeljuje odgovarajući
status.
Tabela 14. Proces prerade (procesiranja) poruka
Procesiranje poruka mogu obavljati učesnici u distribuiranom informacionom sistemu
samostalno, ali se iz praktičnih razloga pojavljuju i specijalizovane institucije, tzv. biroi
za transport i procesiranje poruka, odnosno klirinške kuće. Oni učestvuju u samom
poslovnom procesu koji se realizuje (npr. lancu snabdevanja), a njihov je jedini zadatak
da vrše uslužnu obradu poslovnih poruka.
Klirinške kuće najčešće vrše obradu poruka više različitih poslovnih procesa. Klirinška
kuća koja bi, recimo, podržavala procese platnog sistema za međubankarska poravnanja
po nekom standardu i procese lanca snabdevanja po EANCOM standardu vršila bi tri
vrste procesiranja:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 197
• procesiranje poruka za naručivanje, isporuku i fakturisanje poruka po EANCOM
standardu;
• procesiranje EANCOM poruka za Retail plaćanja;
• sistem za Wholesale ili međubankarska poravnanja; ti sistemi su međusobno
jasno razgraničeni, ali mogu i međusobno komunicirati jasno definisanim
standardnim porukama.
Cilj biroa je da vrši procesiranje raznorodnih poruka različitih standarda i povezivanje
raznorodnih poslovnih procesa, odnosno da izvršava primenu zadatih standarda. Postoje
različiti sistemi standardizovanih poruka za razmenu informacija u poslovnim
procesima finansijske industrije, zdravstva, trgovine, carine. Kao logično pitanje,
nameće se informatička organizacija poslovanja čiji bi predmet bila primena,
elektronska razmena i procesiranje organizovanih podataka adekvatnim sistemima
poruka. Danas u svetu je trend opisivanje poslovnih podataka uz pomoć proširivog
jezika za opisivanje, odnosno XML-a. Na taj način se vrši segmentiranje poslovnih
procesa na različite sisteme kojima pripada odgovarajući skup njihovih poruka. Svaki
od navedenih sistema mora da bude u interakciji sa mnogim drugim sistemima putem
kanala koji im obezbeđuje sigurnu razmenu podataka. Svi nabrojani sistemi imaju i
potrebu da budu globalno povezani i da konekcija bude prema više raznorodnih sistema.
Raznorodnost se ogleda i u različitosti informatičke tehnologije, ali i sa delatnošću koja
je predmet sistema. Pregled sistema poruka prikazan u radu jeste osnova za buduća
razmišljanja o elektronskom servisnom sistemu za razmenu podataka između
raznorodnih institucija. Svi nabrojani sistemi doprinose poboljšanju poslovnih procesa,
a samim tim imaju pozitivan privredni i sociološki efekat, u smislu pojeftinjenja usluga,
smanjivanja vremena potrebnog za obradu informacija i uvođenja novih vrsta
savremenih servisa. Navedenim prednostima se poboljšava kvalitet poslovanja javnih
servisa i pravnih lica, a kvalitet života fizičkih lica.
5.7.4 Postprocesiranje podataka
Postprocesiranje ima zadatak da na osnovu standarda koji važi za sistem kome treba
poslati poruku sastavi poruku na osnovu rezultata od potrebnih transakcija koje
instrukcija treba da sadrži, od potrebnih instrukcija koje poruka treba da sadrži i da
pripremi poruku za slanje. Poruka se predaje sistemu za transport poruka koji isporučuje
poruku i vraća kao rezultat ACK, odnosno potvrdu prijema ili NAK, odnosno odbijanje
prihvatanja poruke. ACK i NAK sadrže, pored referentnog broja transakcije, i
jedinstvenu identifikaciju prijema/odbijanja na osnovu kog može da se pravi
reklamacija, a u poruci ukoliko je u pitanju NAK mora da se nalazi i poruka o razlogu
odbijanja originalne poruke.
5.7.5 Provere putem Registracionog tela
Putem registracionog tela u svakom trenutku administrator sistema može poslati upit u
registraciono telo. Postoje dva slučaja: potrebne su informacije o originalnoj poruci i o
procesu u elektronskom poslovanju platnih sistema koji je izazvala inicijalna
transakcija. Ukoliko su potrebne informacije o originalnoj poruci, registracionom telu se
šalje identifikacija poruke. Na osnovu identifikacije poruke dobija se originalna poruka i
odgovarajući odgovor: potvrdu prijema ili obaveštenje o odbijanju. Ukoliko je potrebno
da se dobije informacija o poslovnoj transakciji, registracionom telu se šalje upit sa
referentnim brojem transakcije koja inicira poslovnu transakciju. Kao odgovor dobija se
skup svih poruka koje sadrže dati referentni broj transakcije, skup svih potvrda prijema
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 198
ili obaveštenja o odbijanju sa vrednostima koje opisuju vremenski raspored toka
transakcija poslovnog procesa. Provera se izvršava iz dva razloga: utvrđivanja originala
poruke, odnosno instrukcije, odnosno transakcije i utvrđivanja toka procesa. Provera se
može obaviti zbog internih potreba pošiljaoca poruke, ali i zbog veštačenja poruke ili
poslovnog toka.
5.8 Struktura predloženog modela
Format finansijske poruke je takav da poruke u sebi sadrže informacije koje su potrebne
za sam prenos poruke sa jedne na drugu lokaciju, kao i tehnološke informacije –
podatke poslovnog procesa kome su namenjene. One predstavljaju podlogu za kreiranje
logičkog objektno orijentisanog sistema, gde su objekti u interakciji isključivo uz
pomoć poruka [19].
Odabirom odgovarajućih poruka iz propisanog skupa poruka možemo da „pokrijemo”
finansijsku celinu, tj. odabrani podskup standarda koji određuje odgovarajuću logičku
celinu [166]. Sledi da su svi logički delovi, u stvari, determinisani normativima vlasnika
procesa, a u skladu sa dozvolama - odobrenjima – ugovorima koje on ima u svojoj
sredini (ambijentu) u odnosu na ostale učesnike.
Fizički sistemi su uvek posledica organizacije vlasnika procesa [164] i oni su
organizaciono opredeljeni ukoliko vlasnik ima pravo na osnivanje takvog vida
organizacije, ili neke druge, a vidljivo je da su neki organizaciono opredeljeni da
funkcionišu po finansijskoj vertikali ili geopolitički [163].
Podrška Narodne banke Srbije: ubrzanje
usredsređivanjem na odabir ispravnih rešenja,
Podrška Narodne banke Srbije: ubrzanje
usredsređivanjem na odabir ispravnih rešenja,
Prirodna konekcija sa drugim platnim sistemima kroz
promovisane kanale razmene
Prirodna konekcija sa drugim platnim sistemima kroz
promovisane kanale razmene
MS Certification AuthorityMS Certification Authority
WEB/Win portal appWEB/Win portal app
A4SWIFT akceleratorA4SWIFT akcelerator
Biz Talk serverBiz Talk server
MS SQL ServerMS SQL Server
Servisi za izveštavanjeServisi za izveštavanje
MS Windows platformaMS Windows platforma
Izveštavanje
Administracija
Monitoring
Izveštavanje
Administracija
Monitoring
Servisno orijentisan arhitektura
Modelom vođen razvoj
Bez Single Point Of Failure
Rešen životni ciklus sistema
Industrijski standardi
Servisno orijentisan arhitektura
Modelom vođen razvoj
Bez Single Point Of Failure
Rešen životni ciklus sistema
Industrijski standardi
Pouzdano
Modularno
Skarabilno
Pouzdano
Modularno
Skarabilno
StrukturaStrukturaFizički sistemiFizički sistemiLogičke celineLogičke celineStandardiStandardi
URL bazirano
adresiranje
Kanali:
TelCo
GSM
Satelit
Drugi
komunikacioni
kanali
URL bazirano
adresiranje
Kanali:
TelCo
GSM
Satelit
Drugi
komunikacioni
kanali
CAISO20022ISO20022
1: camt.*
2: pacs.*
3: pain.*
4: reda.*
5: semt.*
6: sese.*
7: setr.*
1: camt.*
2: pacs.*
3: pain.*
4: reda.*
5: semt.*
6: sese.*
7: setr.*
TWIST
SWIFT
…
PRIVATNI
STANDARDI
…
DRUGO
T IST
S IFT
PRIVATNI
STANDARDI
DRUGO
RTGS
Credit
Transfer
Direct
Debit
Kartice
…
e – invoicing
Kliring
čekova
.
.
.
DRUGO
RTGS
Credit
Transfer
Direct
Debit
Kartice
e – invoicing
Kliring
čekova
.
.
.
DRUGO
Nacionalne
banke
Klirinške
kuće
Agenti
plaćanja
Procesorske
kuće
Fabrike
plaćanja
.
.
.
Banke
.
.
.
Druge
finansijske
organizacije
Nacionalne
banke
Klirinške
kuće
Agenti
plaćanja
Procesorske
kuće
Fabrike
plaćanja
.
.
.
Banke
.
.
.
Druge
finansijske
organizacije
QMS ISO 9001:2008
ISO27000
QMS ISO 9001:2008
ISO27000
MICROSOFT
ORACLE
...
HEWLET PACKARD
FUJITSU
...
MICROSOFT
ORACLE
...
HEWLET PACKARD
FUJITSU
...
Transportni sistem za razmenu poruka
sa mehanizmima bezbednosti i zaštite
Slika 97. Šema za izbor sistema za realizaciju
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 199
Na slici 97. prikazani su i drugi standardni sistemi poruka za različite namene, drugačije
od onih koje se upotrebljavaju u platnim sistemima. To pokazuje, na još jedan način, da
se i drugi sistemi bazirani na porukama mogu realizovati po ugledu na platne sisteme.
Javna i privatna komunikaciona infrastruktura, bezbedonosni mehanizmi, operativni
sistemi, sistemski softver uključujući i baze podataka, hardverski proizvodi, aktivne
mrežne komponente, i interakcija sa okruženjem jesu segmenti koji čine ambijentalne
uslove za rad.
5.8.1 Globalni standardi poruka
Može se slobodno reći da je čitav sistem determinisan odabranim sistemom poruka
kojim se zadaju setovi podataka uz pomoć kojih se determinišu poslovni procesi. Već
samim obimom poruka i načinom na koji se koriste određeni su mogući poslovi u
sistemu, kao i tačan način na koji se koriste podaci, ali i setovi potrebnih podataka. Na
taj način se do krajnosti determiniše sistem i isključuje bilo koji stepen proizvoljnosti.
Standard ISO20022 je baziran na XML standardu, preuzeo je sve dobre osobine svog
prethodnika, a uveo sve savremene trendove u informacionim i finansijskim
tehnologijama. Na taj način ponudio je mogućnosti koje su bile uobičajene za prethodne
standarde, ali i mogućnost da se sa odgovarajućim tranzicionim šemama ostali
finansijski standardi preslikaju ili dopune i na taj način približe ISO20022 standardu sa
planom konvergencije do potpunog preklapanja sa njim.
Organizacija TWIST je izabrala Retail segment kao predmet svog delovanja, ali sa
svojim porukama standard dozvoljava mogućnost pakovanja višenamenskog sadržaja
koji se ogleda u mogućnosti kombinovanja poruka za plaćanja sa porukama lanca
snabdevanja na različite načine. Setom poruka TWIST organizacije moguća je izgradnja
uskospecijalizovanih procesorkih kuća, kao i procesorskih kuća koje objedinjuju u sebi
više različitih poslovnih kategorija. Na taj način one daju dobar model konsolidovanja
disparatnih poslovnih procesa i objedinjavanja na logičan način.
Proprietary standardi su oni koji su nastali silom prilika i predstavljaju dobru osnovu za
sagledavanje potreba za uvođenjem novih standarda iz različitih oblasti. Jedan od
primera koji bi mogao u budućnosti da bude odlučujući u komponovanju bankarskih
poslovnih sistema jeste izgradnja sistema poruka koji bi podržao core procese banke.
Na osnovu tog proprietary standarda, uopštavanjem, može da se izgradi core banking
standard koji bi standardizovao procese banke i na taj način razvoj core sistema banke
učinio logičnim, jeftinijim i pouzdanijim.
Na slici 97. u koloni za standarde nalazi se više grubo opisanih standarda koje možemo
da odaberemo kao polazište u izgradnji platnog sistema različitih namena. Ono što se
može predvideti jeste da će budući vlasnik platnog sistema u većini slučajeva izabrati
jedan osnovni standard, a na osnovu geopolitičkih, ekonomskih, tradicionalnih i drugih
činjenca izabrati ostale preovlađujuće standarde za neki geografski region sa kojima će
sistem raditi.
5.8.2 Logičke celine nad srodnim grupama poruka
Svaki od standarda navedenih na slici 97. ima mogućnost da pokrije većinu poslovnih
procesa platnih sistema. To su: Credit Transfers, RTGS, Direct Debit, Card
Framework, eBusiness, eInvoicing, Check Clearing i drugi. Nastali su u različitim
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 200
sredinama iz različitih pobuda i zadaju porukama različite formate. Međutim, pošto im
je domen nad kojim su formirani isti, uglavnom su sa istim nivoom informacija u sebi.
Tako na primer, ukoliko se razmatra poruka, platni nalog, atributi plaćanja su u svim
regijama sveta isti i količina informacija o platnom nalogu po svakom standardu je ista.
Korišćenje jednog standarda u određenoj regiji uglavnom je implicirano željom za
monopolom na tržištu transakcija, a postoji i objektivan razlog da se ne napušta
ustoličeni standard jer su trenutna ulaganja u implementaciju novog standarda suviše
velika, a vrlo je česta situacija da implementacija postojećeg standarda toliko košta i
objedinjuje tolike resurse da ne postoji društvenopolitička volja da se izvrši njegovo
osavremenjavanje. Međutim, analizom se uvek utvrđuje da su svi razlozi za opstanak
starih standarda poruka loši i preovladava činjenica da su novi standardi veoma pogodni
u svim fazama životnog ciklusa platnog sistema i da sa sobom nose mnoge dodatne
prednosti.
5.8.3 Finansijske institucije
Finansijske institucije kroz koje je prožeta struktura platnih sistema mogu da se pode na
dva segmenta: na veliko (Wholesale) i na malo (Retail). U Wholesale grupi su
nacionalne banke, klirinške kuće, agenti plaćanja i banke, kao i druge finansijske
organizacije. Retail segmentu pripadaju sve ostale organizacije (pravna lica) i fizička
lica. Veoma je bitna činjenica da je domen platnih sistema nad oba segmenta i da je
prilikom komponovanja platnih sistema potrebno analizirati čitavu celinu iako se razvija
samo neki njen deo. Razlog za to je što se akvizicija podataka o transakcijama vrši u
Retail segmentu, pa se procesiranje nastavlja sve do realizacije u delu platnog sistema
koji pripada nacionalnoj banci.
Finansijske institucije u odnosu na svoje nadležnosti mogu da izaberu jednu ili više
logičkih celina nad srodnim grupama poruka za procesiranje u odnosu na jedan ili više
standarda za poruke. Tako na primer Udruženje banaka Srbije (fizički sistem -
institucija) nakon uvođenja Direct Debit-a imaće dva standarda po kojima radi za
format poruka (ISO15022 i ISO20022), a procesiraće platne naloge, odnosno Credit
Transfers (u funkciji realizacije čekova) i naplatu putem direktnog zaduženja, odnosno
Direct Debit.
5.8.4 Transportna infrastruktura
Message broker je program koji vrši translaciju poruke za primaoca sa formalnog
protokola pošiljaoca u telekomunikacionoj mreži gde programi komuniciraju razmenom
formalno definisanih poruka. Primeri brokera koji imaju i dodatne funkcionalnosti,
pored opisanih u prethodnom poglavlju, jesu: Apache ActiveMQ, Comverse Message
Broker (Comverse Technology), eSCL Message Broker (Interface & Control Systems),
Financial Fusion Message Broker (Sybase), JBoss Messaging (JBoss), Microsoft
BizTalk Server (Microsoft), Oracle Message Broker (Oracle Corporation), Proteus i
open source implementacija od Info-Scapea, WebSphere Message Broker (IBM),
Cloverleaf (E-novation Lifeline). Svaki od prethodnih proizvoda, sem mogućnosti
komunikacije i mogućnosti korišćenja za transport poruka, ima specifične
funkcionalnosti koje ga opredeljuju na određeni segment funkcionalnosti. SAGA SEP
transportna komponenta i OpenAMQ sistem, koji su opisani u prethodnim poglavljima,
nemaju funkcionalnosti koje su povezane sa nekom drugom oblašću koja nije transport
poruka. Oni su usko specijalizovani i njihova specijalizacija na funkcionalnost
transporta i onih funkcionalnosti koje su striktno povezane za transport poruka čine ih
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 201
visokoupotrebljivim u MOS. Njihova uska specijalizovanost pomaže i u jasnom
razgraničavanju drugih procesa platnih sistema i njihovoj informatički urednoj
implementaciji.
Za razliku od message brokera, Message-oriented middleware obuhvata kategoriju
softvera za komunikaciju između aplikacija koji uopšteno počiva na asinhronoj
komunikaciji nasuprot request/response metodi. Mnogi message-oriented middleware
(MOM) sistemi zavise od redova za čekanje, mnogi počivaju na broadcast ili na
multicast načinu komunikacije. Osnovna prednost ovih sistema ili protokola leži u
mogućnostima da uskladište poruke, rutiraju ili transformišu u procesu dostave.
Sistemi za transport poruka su definisani na logičkom nivou, nad protokolima
komunikacije, tako da ne zavise od infrastrukture komunikacionih kompanija. Zbog
njihove ekstremne fleksibilnosti i mogućnosti, kao i specijalizovanosti na
funkcionalnosti, koje ne zavise od oblasti poslovanja na koju se poruke odnose,
najozbiljniji su kandidat da postanu standard u svom domenu. U prilog tome ide i
činjenica da je intencija svih globalnih organizacija za standardizaciju da se
standardizuju poruke po domenima čovekovog delovanja, pa će tako u svim značajnim
sistemima takav način razmene informacija biti preovladavajući. Činjenica da je po
pitanju primene novih tehnologija message oriented paradigma dobila svoju potvrdu baš
u domenu razvoja platnih sistema, čini da su platni sistemi postali jedna od
najdinamičnijih oblasti.
5.9 Model evaluacije rešenja
Proces evaluacije rada celokupnog sistema za elektronsko poslovanje platnih sistema
odvija se prema šemi prikazanoj na slici 98. [25]
Slika 98. Proces evaluacije sistema elektronskog poslovanja platnih sistema
Jedan od najvažnijih segmenata procesa evaluacije je izbor kriterijuma po kojima će se
evaluacija vršiti. Kriterijumi koji se koriste za evaluaciju podeljeni su u tri grupe:
• tehničko-tehnološki kriterijumi;
• poslovni kriterijumi;
• korisnički kriterijumi
Liste kriterijuma za evaluaciju elektronskog poslovanja platnih sistema prikazane su u
tabelama 15, 16 i 17.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 202
Kriterijum Definicija Dimenzije Mere
Interoperabilnost U kojoj meri su sistemi u stanju da komuniciraju jedni sa drugima.
Stepen korišćenja standardnih ili
standardizovanih formata
podataka zasnovanih na XML-u.
Modularna
kompozitnost
Korišćenje softverskih komponenata (kreiranje
mogućnosti za ponovnu upotrebu i deljenje).
Stepen do koje mere su pokrivene
funkcionalnosti sistema od strane
komponenata.
Pouzdanost Obim u kome se može očekivati da sistem obavlja svoju funkciju. Funkcionalnost Broj prekida rada
Dostupnost Vreme u kome je sistem spreman da obavlja zahtevane funkcionalnosti. Vreme
Procenat u odnosu na prekide u
radu
Bezbednost Koliko je u sistem moguće ubaciti neautorizovanih poruka. Broj pokušaja Broj uspelih pokušaja
Performantnost Obim u kome se može očekivati izvršenje
određenog broja transakcija.
Broj transakcija i
vreme
Broj finansijskih transakcija na
sat
Tabela 15. Tehnološki kriterijumi za evaluaciju elektronskog poslovanja platnih sistema
Kriterijum Definicija Dimenzije Mere
Stabilnost servisa Stabilno u dužem vremenskom okviru Vreme Broj izmena sistema u vremenskom okviru
Nezavisnost Nezavisnost od domena primenom izolovane aplikativne logike
Nezavisnost od
domena Broj različitih primena
Izolacija aplikativne
logike
Količina direktno implementirane
logike
Proširivost
Lako za dodavanje, modifikaciju, zamenu,
uvećanje, izmenu ili pripajanje
funkcionalnosti
Obimnost Cena izmena
Primenljivost Funkcionalnost i cena primene.
Broj primena Cena u odnosu na broj aplikativnih primena
Količina potrebnih
resursa za primenu Ukupna cena resursa za primenu
Skalabilnost Lako za skaliranje Obimnost Broj transakcija
Ekonomičnost Troškovi razvoja i održavanja niski i
raspoređeni kroz vreme Cena
Cena u vremenskom periodu,
Prilog 8.
Tabela 16. Poslovni kriterijumi za evaluaciju elektronskog poslovanja platnih sistema
Kriterijum Definicija Dimenzije Mere
Sekvencijalnost Mogu se postizati samo u sledu.
Akvizivija Poruke se šalju onim redom kojim se kreiraju (da/ne)
Distribucija Poruke se prihvataju onim redom kojim se šalju (da/ne)
Pretprocesiranje Poruke se pretprocesiraju onim redom kojim se primaju (da/ne)
Procesiranje Poruke se procesiraju onim redom kojim se pretprocesiraju (da/ne)
Originalnost Prihvatljivo je samo originalno.
Autorizovanost Poruka koja je prihvaćena pravilno je potpisana (da/ne)
Kvalifikovanost Poruka koja je prihvaćena neizmenjena je (da/ne)
Odgovornost Poruka koja je stigla zabeležena je bez obzira da li je ispravna (da/ne)
Kapacitivnost
Prihvatljivo je obraditi prosečni
dnevni obim u jedinici mere
manjoj od dana.
Transport Moguće je procesirati šestostruki dnevni obim u toku jednog sata (da/ne)
Akvizicija Moguće je procesirati dnevni obim u toku jednog sata (da/ne)
Distribucija Moguće je procesirati trostruki dnevni obim u toku jednog sata (da/ne)
Sledljivost
Registraciono telo zadovoljava
kriterijum prijema, obrade i
slanja svih zahteva – kao da se
za svaku promenu (poruku ili
transakciju) zahteva i
odgovarajući izveštaj i o poruci
i o transakciji.
Pristupačnost Moguće je dobiti odgovor na sve zahteve o svim porukama i transakcijama (da/ne)
Jednostavnost Jasno i lako za upotrebu. Upotreba Jednostavnost u upotrebi
Tabela 17. Korisnički kriterijumi za evaluaciju elektronskog poslovanja platnih sistema
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 203
6 Primena i implementacija interoperabilng EPPS modela
6.1 Arhitektura predloženog sistema
Postoji mnogo nivoa perspektiva saradnje (kolaboracije), na primer Centralna banka kao
odgovoran, autorizovan i kvalifikovan učesnik čini svoj kolaboracioni prostor. Drugi
nivo kolaboracionog prostora poslovne saradnje je prostor lokalnih banaka koji čine
sistem elektronskog poslovanja platnih sistema bez konekcije sa drugim centralnim
bankama, prikazanim na slici 99.
Slika 99. Primeri kolaboracionih perspektiva različitih
nivoa u elektronskom poslovanju platnih sistema
U finansijskoj industriji je veoma uočljivo da su svi učesnici povezani sa jednim super
učesnikom koji koordinira ostale [165]. Sistemi u finansijskim organizacijama su strogo
hijerarhijski definisani bez šuma i lakše je uočiti hijerarhijsku zavisnost jer se radi o
izuzetno značajnom aspektu, finansijama, od kojih sve počinje i sve se završava [27].
Takav je slučaj i u ostalim sistemima, ali mnogo manje uočljivo, a negde i sama
zakonska regulativa nije tako dobro definisana kao u slučaju finansijske industrije.
Drugi pogled je prikazan na slici 100. Slika pokazuje topologiju i dekompoziciju
sistema i može se pokazati analizom i matematičkim modelom da su segmenti u svim
sistemima ekvivalentni, da su segmenti koji se odnose na osnovnu delatnost jednaki, a
da se razlikuju samo oni koji se odnose na poverene poslove, odnosno samo na one
segmente za koje je sistem ekskluzivno odgovoran, autorizovan i kvalifikovan. Na slici
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 204
100. prikazan je jedan takav sistem banaka od kojih svaka kao podsistem mora da ima
na svom nivou kao standardne komponente validator sintakse, semantike i validator
poslovnih pravila, ali i sve ostale koji spadaju u osnovnu delatnost banke, kao i ostale
sisteme koji podržavaju poslovne procese banke.
Prostor saradnje banke
Banka
Sistem Sistem
2 n
System x
Validator
semantike
Validator
poslovnih
pravila
2 3
...
...
Validator
sintakse
Sistem
1
1
Slika 100. Drugačiji pogled na sistem
To pokazuje kako se može realizovati, na primer, osnovni set standardnih elemenata
platnog sistema i to u RTGS centru, bankama i kod klijenata. Slika 101. prikazuje
osnovni konglomerat - gradivnu jedinicu, a slika 102. prikazuje kako se od njega
sačinjava platni sistem.
Slika 101. Osnovni sklop standardnih elemenata RTGS sistema
Slika 102. Grupisanje konglomerata gradivnih jedinica po nivoima
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 205
Navedena realizacija platnog sistema nije karakteristična samo za platne sisteme. I ostali
Message Oriented Systems (MOS) [10] imaju iste fenomenološke elemente:
• postoji potreba za velikim obimom razmene poruka;
• postoji struktura podređenih i nadređenih sistema sa super sistemom;
• postoje veze sa drugim MOS;
• akvizicija poruka se vrši sa veoma širokog geografskog područja;
• distribucija poruka se vrši na veoma široko geografsko područje;
• akvizicija i distribucija se vrše kroz zadate nivoe odgovornosti;
• poruke za razmenu informacija o poslu su standardizovane od strane institucija
za globalnu standardizaciju;
• poruke za razmenu informacija sadrže informacije za adresiranje i procesiranje;
• standardi poruka su bazirani na XML-u;
• osnovni sklop standardnih elemenata je kao i za platne sisteme, slika 101;
• grupisanje gradivnih jedinica se vrši kao i za platne sisteme, slika 102;
• sisteme međusobno samo razlikuju zadati formati, informacije za procesiranje i
komponente za konkretno izvršavanje procesiranja.
Na osnovu prethodno navedenog i činjenice da je rasprostranjenost MOS u savremenom
društvu veoma velika, od sistema za platni promet, pa do sistema za SMS mobilnu
naplatu parkiranja u velikim gradovima priloženi radni model sistema pokazuje da je
moguće izgraditi savremen i moderan sistem koji bi zadovoljio sve potrebne zahteve.
Tabela 18. prikazuje komparativne prednosti razvoja softvera framework-om u odnosu
na uobičajeni razvoj softvera, kao i ideal kome se teži prilikom razvoja softvera. Na
osnovu prethodnog sledi da se razvojem prihvaćene strukture i arhitekture realnog
sistema, opisane u prethodnom i ovom paragrafu, možemo približiti idealnim
osobinama IT sistema u funkciji podrške poslovnim procesima.
Uobičajeni razvoj softvera Razvoj framework-a Ideal
Specifično za aplikaciju Specifično za domen Nezavisno od domena
Ima kratak životni ciklus Produžen životni ciklus za 2-3 puta Stabilno u dužem vremenskom okviru
Teško za održavanje
funkcionalnosti
Teško za dodavanje, modifikaciju,
zamenu, uvećanje, izmenu ili
pripajanje funkcionalnosti
Lako za dodavanje, modifikaciju,
zamenu, uvećanje, izmenu ili pripajanje
funkcionalnosti
Proizvod je samo jedna
aplikativna primena
Proizvod je nekoliko specifičnih
aplikativnih primena iz jednog domena
Proizvod je neograničen broj
aplikativnih primena
Nije skalabilno Ograničene mogućnosti skalabilnosti Lako za skaliranje u mnogo smerova
Visoki troškovi razvoja Visoki troškovi razvoja Troškovi razvoja niski i raspoređeni
kroz vreme
Ne može da se prilagođava Može da bude prilagodljivo Prilagodljivo
Nema integracije Dozvoljava ograničenu integraciju Neograničena integracija
Nije proširivo Ograničeno proširivo Neograničeno proširivo
Ograničene mogućnosti Proračunate mogućosti Neograničene mogućnosti
Zahteva mnogo resursa Zahteva ograničene resurse Zahteva manje zahtevne resurse
Nema izolovane aplikativne
logike
Ograničena izolacija aplikativne logike Kompletna izolacija aplikativne logike
Visoki troškovi održavanja Razumni troškovi održavanja Minimalni troškovi održavanja
Nije stabilno Nije stabilno Stabilno
Koncentriše se na aplikativnu
logiku
Koncentriše se na grupu aplikativne
logike
Sastoji se od osnovnih znanja,
mogućnosti da ispuni njihove ciljeve,
vođeno neograničenom aplikativnom
logikom
Bez konfiguracije i
rekonfiguracije
Ograničena konfiguracija i
rekonfiguracija
Neograničena konfiguracija i
rekonfiguracija
Tabela 18. Neke razlike između načina razvoja softvera
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 206
Integracija platnih sistema putem poruka korišćenjem odgovarajućih protokola je
bezbedna, pouzdana, i u potpunosti zadovoljava potrebe takvih sistema. Dugi niz godina
na taj način vrši se razmena poruka u finansijskoj industriji. Paterni povezani za
razmenu poruka detaljno su specificirani u knjizi Enterprise Integration Patterns [90] i
sastoje se od modula čija je blok-šema prikazana na slici 103:
• Extract ;
• Send;
• Transport;
• Receive;
• Load;
• Process.
Slika 103. Blok-šema sistema za razmenu poruka
Uočeni su sistemi bazirani na standardnim adresibilnim porukama u globalnom platnom
sistemu na različitim organizacionim nivoima koji se mogu integrisati upotrebom
jednog ili više sistema za razmenu poruka.
Navedeni model je pojednostavljen prikaz hibridnog sistema za real time i odložene
Credit Transfer i Direct Debit transakcije. Model pojašnjava sistem koji je moguće
izgraditi i ističe mogućnosti tako kompleksnog sistema da bi se bolje razumeo kao
kompaktna celina. Navedenim modelom se vizuelno prikazuju osobine koje smo želeli
da postignemo, definisana je struktura i ponašanje sistema, on predstavlja uzor koji
pokazuje kako budući realan sistem treba konstruisati.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 207
6.2 Aktivnosti razvoja sistema
Standard za analizu, zadavanje i implementaciju poslovnih sistema podržanih
informacionim tehnologijama koji se predlaže u ovom radu rešava niz problema
povezanih sa odgovornošću, autorizacijom i kvalifikovanošću različitih subjekata koje
poslovni sistem sadrži. Jasno se razdvajaju uloga i zadaci u analizi, zadavanju i
implementaciji tehnologa posla koji treba da se podrži sa informacionim tehnologijama,
od tehnologa sa IT znanjima [53].
Primeri su i zadavanje procesa od strane tehnologa posla koje se opisuje u Operativnim
pravilima i opisivanje struktura podataka u XML šemama od strane IT tehnologa.
Operativnim pravilima se zadaje ponašanje sistema, uzevši u obzir standardne osobine
koje treba da ispune. Tehničko uputstvo determiniše strukturu sistema, a termin plan
definiše periodiku procesa sistema (učestalost dešavanja). Dokument Format i namena
poruka ima zadatak da povezuje ponašanje sa strukturom, odnosno operativna pravila sa
tehničkim uputstvom. Šeme i instance poruka su praktični artifakti koji mogu da služe
za implementaciju konkretnih kategorija u sistemu (formi, interfejsa, struktura za
prihvat konkretnih instanci sistema). Šeme poruka proističu iz dokumenta Tehničko
uputstvo i Poslovna pravila. Šeme poruka se materijalizuju u XML formatu. U sebi
sadrže informacije o strukturi dokumenata i osnovnim ograničenjima nad
odgovarajućim skupovima podataka. Instance poruka se operativno koriste prilikom
realizacije sistema i praktičnih provera pretpostavki tokom analize i implementacije
sistema. Strukture podataka mogu da budu kompleksne i instance služe za provere
osnovnih implementacionih pretpostavki. Šeme poruka i instance poruka služe kao
osnova za generisanje artefakata elemenata sistema. Navedeni dokumenti predstavljaju
ontološku osnovu sistema.
Slika 104. Pravila i uputstva iz Priloga 1 sa XML šemama i primerima
Za izradu svakog dokumenta potrebno je sprovesti zasebnu analizu nekom od
raspoloživih metodologija. Navedeni dokumenti predstavljaju i osnovne dokumente
potrebna nadležnim organima za odobravanje rada sistema i procesa koji su na taj način
zadati. Navedeni dokumenati su neophodan, ali i dovoljan uslov za započinjanje i
realizaciju funkcionalne specifikacije kao prvog koraka implementacije sistema [17].
Predstavljeni dokumenti su zadati industrijskim standardima, zakonskom regulativom,
normativnim aktima i drugim raznorodnim standardima koje treba uzeti u obzir
prilikom analize potrebne za njihovu izradu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 208
Slika 105. Relaciona šema generisana iz paos.004.001.01 XML šeme sa sajta
Standardna šema za predmetnu oblast može se naći na sajtu organizacije koja definiše
pravila, recimo za direktno zaduženje, na sajtu Udruženja banaka Srbije (Slika 104.).
Slika 106. Import šeme iz MySQL baze podataka u alat Protege
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 209
Izaberimo kao primer šemu paos.004.001.01.xsd. Koristi se za promenu statusa
instrukcije direktnog zaduženja i instrukcije za refundaciju koja se odnosi na
uključenje/isključenje ovih instrukcija iz ciklusa kliringa. Generiše je banka
dužnika/banka poverioca i dostavlja procesoru.
Slika 107. Graf automatski kreirane ontologije importom iz baze podataka
Slika 108. Kreirana ontologija i umetnuti REA elementi sa povezanim znanjem o
klasama
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 210
Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih
instrukcija kojima se menja status u ciklusu kliringa i tela poruke (Transaction
Information) koje nosi informacije o pojedinačnim instrukcijama kojima se menja status
u ciklusu kliringa. Korišćenjem alata xsd2db [192] dobija se relaciona šema poruke, kao
što je to prikazano na slici 105 [108].
Primenom alata DBConvert relaciona šema se iz MSSQL server baze konvertuje u
MySQL bazu podataka, iz tehničkih razloga jer alat koji će se kasnije koristi ne
podržava MS SQL server [122]. Koristeći alat Protege importujemo šemu preslikanu u
MySQL [223], kao što je prikazano na slici 106 [35].
Kreiranjem grafa dobija se reprezentacija ontologije, prikazana na slici 107.
Dodavanjem REA elemenata kreiranoj ontologiji i znanja o odnosima klasa
(superklasa/potklasa) dobijamo ontologiju prikazanu na slici 108.
Na dobijenu ontologiju može biti primenjena REA proširena ontologija na način kako je
to u prethodnom paragrafu opisano, na primer sa lokacijom ili ugovorenom obavezom.
6.2.1 Kreiranje lokalnih ontologija i domenske ontologije
Ontologije se bave fenomenima kao što su uopštenje vremena, prostora i uzročnost ili
domena u određenom domenu i mogu se primeniti u elektronskom poslovanju i
metodologijama modelovanja [79]. Ontologije, kao formalni opis objekata, njihovih
osobina i odnosa u određenom domenu eksplicitno su razumljive i za čoveka i računar.
Ontološkim pristupom se postiže interoperabilnost i konzistentnost u modelu i
obogaćuje dizajn modela sa domena znanja [89]. Svaka poslovna transakcija je praćena
sa jednom ili više finansijskih transakcija, pa tako standard ISO 15944-4:2007 definiše
ontološko okruženje za specifikaciju koncepata i relacija uključenih u poslovne
transakcije i scenarije nazvane Resource-Event-Agent (REA) ontologijom [29]. REA
opisuje punu ekonomsku razmenu vrednosti u kolaborativnom prostoru kao definisanu
poslovnu transakciju. REA može da se upotrebi kao ontološki okvir za uvođenje
osnovnih entiteta i odnosa koji su uključeni i u poslovne transakcije i scenarije za
modelovanje interoperabilnih sistema elektronskog poslovanja platnih sistema.
Platni sistemi u svakoj ekonomiji imaju ključnu ulogu [203] jer obezbeđuju mehanizme
uz pomoć kojih se vrši izvršenje finansijskih transakcija. U svim segmentima je prisutna
raznolikost standarda: hardver, softver, kadrovi, organizacija, podaci, standardi za
poruke. Platni sistemi, po vertikali, od centralne banke, preko klirinških kuća, banaka i
drugih finansijskih organizacija, do korporativnih i Retail korisnika moraju da budu u
međusobnoj interakciji [15] i interakciji sa drugim sistemima koji prate finansijsku
razmenu – kao dualnu REA transakciju [10].
U platnim sistemima korišćenje poruka ima ulogu na nivou razmene podataka, odražava
se na aplikativne modele sistema i operacije u sistemu izazvane događajem [102]. Na
nivou razmene poruka transportni mehanizam omogućava korišćenje posebnih modula
za razmenu poruka i njihovu obradu. Upotrebom sistema za razmenu poruka ostvaruje
se pouzdanost u komunikaciji, transparentnost u odnosu na programske jezike i
platforme, postiže se asinhronost koja omogućava modulima nezavisnost obavljanja
operacija bez gubljenja vremena na čekanje izvršenja operacija drugih modula. Postiže
se i mogućnost tjuniranja vremena obrade u odnosu na kapacitete, odstranjuju se
zaglušenja i onemogućavanje rada modula prouzrokovanih prevelikim brojem poziva
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 211
operacija modula. Interoperabilnost se postiže korišćenjem standardizovanih sistema
poruka, transportnih sistema za njihovu razmenu, a omogućava učesnicima standardan
pristup operacijama sa finansijskim i poslovnim transakcijama. Koordinacija između
učesnika u platnom prometu unutar države je suštinska za postizanje konzistentnosti i
efikasnosti elektronskog poslovanja. Postiže se standardizacijom na svim nivoima [47].
Upotreba globalnih finansijskih standarda u domenu platnih sistema unapređuje
konzistentnost i efikasnost elektronskog poslovanja i doprinosi unapređenju sistema za
elektronsko poslovanje i drugih sistema. Glavni faktor uspešne implementacije platnih
sistema na državnom i međunarodnom nivou predstavlja uspostavljanje višeslojne
interoperabilnosti elektronskog poslovanja u skladu sa globalnim standardima.
Platni sistemi u procesu elektronskog poslovanja [104] u interakciji su sa različitim
poslovnim sistemima učesnika [162]. Poslovni sistemi učesnika podržavaju veliki broj
korisnika i poslovnih procesa sa specifičnim zahtevima [78]. Osnovni problem je
heterogenost poslovnih procesa, podataka i korišćenih IT tehnologija. Razmena
finansijskih transakcija elektronskim putem je prevladavajuća. Standardizacija u
domenu modeliranja platnih sistema, koja će biti razmatrana, treba da doprinese većoj
efikasnosti ostalih sistema elektronskog poslovanja i interoperabilnosti elektronskog
poslovanja učesnika. Registraciono telo koje se predlaže u ovom radu ima zadatak da
arhivira poruke i potvrde prijema i da na taj način za treća lica, na specijalan zahtev,
recimo potrebe veštačenja, učini poslovne procese elektronskog poslovanja sledljivim i
neporecivim.
Slika 109. REA, Lista ekonomskih agenata
Na slici 109. prikazani su ekonomski agenati platnog sistema jedne REA ontologije
[219]. Kao ekonomski agent prikazan je i Message_Transporter sistem odgovoran,
autorizovan i kvalifikovan za proces razmene poruka. Predstavljeni su na istom nivou
pravno i fizičko lice kao Retail_Person jer u iniciranju transakcija imaju istu ulogu,
razlikuje se samo zakonska osnova koja je, kad se prikažu na ovaj način transparentna u
odnosu na iniciranje transakcije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 212
Slika 110. REA, Lista ekonomskih događaja
U ontologiji prikazanoj na slici 110. korišćeni su događaji inicirani porukama različitog
tipa, koji mogu biti: Creating (Add) za kreiranje nove instance objekta, Inquiry za
pribavljanje informacija o stanju određenog objekta, Submit koji je informativan i ne
zahteva određene privilegije, Modification za izmenu instance ili objekta, Cancellation
za otkazivanje postojeće instance objekta, Renewal za obnavljanje instance ili
postojećeg objekta, Reinstatement za instanciranje postojećeg objekta, Reissue da
prepiše instancu od postojećeg objekta, Query (Synchronization) da obezbedi instancu
specifičnog objekta od strane Servisa provajdera usluge.
U do sada korišćenoj REA ontologiji, ekonomski resursi su platna instrukcija, platna
transakcija i platni instrument. Instrumenti plaćanja determinišu tip platnih instrukcija
koje će biti upotrebljene prilikom njihove realizacije, platne transakcije koje će biti
izvršene, kao i način na koji će se izvršenje obaviti.
Slika 111. REA, Lista ekonomskih resursa
Kod platnih instrukcija, na slici 111. prikazani su standardi ISO15022 (MT) [208] i
ISO20022 sa nekoliko vrsta platnih instrukcija. Prikazana ontologija prati logiku zadatih
standarda i verzije standarda. Platne transakcije koje su predstavljene su odložene
transakcije i transakcije u realnom vremenu, i predstavljaju ekstrahovane platne
transakcije iz platnih instrukcija. Izborom odgovarajućih agenata, resursa, Event-a iz
prikazane ontologije, po finansijskoj vertikali (inicijator plaćanja, banka, agent/klirinška
kuća ili druga finansijska organizacija, sistem centralne banke) vrši se izbor: standarda
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 213
poruka, sistema za iniciranje plaćanja, sistema za razmenu, sistema za pretprocesiranje i
sistema za procesiranje. Sve klase su potklase osnovne klase Thing. R-E-A klase su
Resource, Event i Agent. Korišćen je koncept poslovne kolaboracije, gde se razmena
vrednosti vrši putem Message_Transportera. Navedene klase, sa svojim potklasama
prikazane su na slici 112. Economic agenti su finansijske institucije, inicijatori plaćanja,
koji su predstavljani kao Retail_Person i medijator za prenos poruka.
Slika 112. Predstavnici klase „Thing“ i njihove potklase domenske ontologije
Agenti su odgovorni za rukovanje objektima sistema koji su u njihovom vlasništvu i
inicijatori su događaja u sistemu, dakle oni koriste resurse i iniciraju događaje. Agenti u
sistemu su učesnici iz finansijskih standarda, na primer ISO20022 ili ISO15022.
Message_Transporter je takođe određen da bude agent jer je odgovoran, autorizovan i
kvalifikovan za specijalizovano rukovanje objektima, odnosno za slanje, rutiranje i
prijem finansijskih transakcija koje su zapakovane u platne instrukcije, tj. za rukovanje
objektima nad kojima mu je predata jurisdikcija.
Message_Transporter u ručno-manipulativnim sistemima bila bi osoba koja bi obavljala
poslove dostave sa zapisom o primopredaji pošiljke, baš kao što je to u ovom slučaju.
Sistem Message_Transporter je specijalizovana elektronska pisarnica za predmete
posebne namene. Banka kreditora i banka debtora predstavljene su kao dva agenta jer su
im po poslovima koji su im dodeljeni suštinski različiti poslovni procesi, skupovi
podataka i način na koji se oni distribuiraju. Ista stvar je i sa agentima plaćanja,
agentima koji imaju zadatak da proslede ili one koji su samo posrednici u transakcijama.
Centralna banka i klirinška kuća vrše finalno procesiranje [42], klirinška kuća na nivou
poravnanja finansijskih transakcija [28], a centralna banka [33] za bruto poravnanje u
realnom vremenu. Događaji su sve pojave mogućih finansijskih operacija [140], [154]
koje mogu da se obavljaju. Ekonomski resursi su svi objekti koji se javljaju u polovnim
procesima elektronskog poslovanja platnih sistema. Kao i za agenta i događaj, u
ekonomske resurse se preslikavaju svi standardizovani objekti u dostupnim standardima
finansijske industrije, u ovom slučaju ISO15022 i ISO20022. Sve poruke, koje u sebi
nose platne instrukcije, tipovi standardizovanih transakcija, i standardizovani platni
instrumenti klasifikovani su u ekonomske resurse. Po pitanju strukture, resursi su
nosioci. Standardizovane strukture podataka, struktura klasa iz ISO20022 poruke
Udruženja banaka Srbije (pacs.003.001.01), preslikavaju se u strukture ontologije.
Debtor i Creditor su Retail_Person koja je predstavljena kao ekonomski agent. Lokalna
ontologija se izvodi iz domenske izborom odgovarajućih klasa, kao što je to prikazano
na slici 113 za inicijalizaciju transakcije direktnog zaduženja.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 214
Slika 113. Izvođenje lokalne ontologije izborom odgovarajućih klasa
6.2.2 Razvoj scenarija
Scenario razvoja i implementacije sistema elektronskog poslovanja platnih sistema
sastoji se od izbora standarda, segmenta standarda koji se odnosi na zadatu oblast
poslovanja, izbora nivoa na kom se vrši implementacija i razvoja i implementacije
izabranom metodologijom [19]. Može se pokazati da je za sisteme zadate
standardizovanim adresibilnim porukama sa poslovnom logikom scenario razvoja i
implementacije isti [40]. Ukoliko neki sistem nije zadat standardizovanim adresibilnim
porukama, može se pre procesa razvoja i implementacije izvršiti odgovarajuća
standardizacija i razvoj i implementacija će se svesti na prethodni slučaj.
6.2.2.1 Izbor standarda
Izbor standarda kod elektronskog poslovanja vrši finansijska institucija koja se nalazi na
najvišem nivou; uobičajeno je da standarde zadaje i propisuje njihovu upotrebu
centralna banka za sve nivoe finansijskih institucija [76]. Posredno se vrši i zadavanje
putem regulative i standardizacija Retail nivoa,odnosno nivoa za pravna i fizička lica.
Prilikom izbora standarda vodi se računa o postojećim standardima koji su u opticaju i
rizicima uvođenja željenog standarda. Rizici su izraženi na takav način da obuhvataju
kreditni rizik, rizik likvidnosti, operativni rizik i sistemski rizik.
6.2.2.2 Izbor segmenta standarda
Standardi platnih sistema obuhvataju uvek više segmenata elektronskog poslovanja
platnih sistema i nije uobičajeno zbog velikih rizika da se vrši implementacija svih
segmenata istovremeno. U odnosu na segment poslovanja vrši se analiza objekata u
sistemu i poruka koje su povezane sa tim objektima. Poruke u sebi nose događaje za
kreiranje novih instanci objekata u sistemu, za izmenu objekata u sistemu, za storno
objekata u sistemu (operacija brisanja instanci objekata u finansijskoj industriji ne
postoji, već instance koje treba da budu obrisane bivaju označene sa „obrisan“) i razne
vrste pogleda na sistem koje se, takođe, obavljaju porukom i na zahtev. U odnosu na
objekte, vrši se izbor standardizovanih poruka, poruke se grupišu u procesne celine koje
će biti zasebno realizovane. Razlika kod implementacije je u funkcionalnostima
procesiranja, ostali segmenti su isti i realizuju se jednom i zajednički su resurs za sve
grupisane procese.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 215
6.2.2.3 Izbor nivoa
Izbor nivoa je bitan samo u segmentima za nivo koji spadaju u njegovu isključivu
nadležnost:
• Retail;
• nivo banke;
• nivo finansijske institucije;
• nivo agenta;
• nivo klirinške kuće;
• nivo centralne banke;
• nivo finansijske institucije za poravnanje Foreign Exchange - FX instrukcija.
Razlika između nivoa može biti u načinu izuzimanja sredstava sa računa (recimo da se
određenom računu izuzmu dve sume, jedna koja je inicirana i druga koja prestavlja
naknadu za izvršenu uslugu procesiranja inicirane transakcije), obaveze izveštavanja
zainteresovanih strana na određen način, operacija koje treba da budu obavljene da bi
mogla da se izvrši naplata usluga i generisanje knjigovodstvenih stavki, načina puštanja
transakcija. Recimo u bankama postoji tačka sinhronizacije poslovanja ili upravljanje sa
likvidnošću, gde se sve transakcije ili samo deo transakcija povremeno ili stalno
zadržavaju u odnosu na količinu sredstava kojima banka raspolaže, a takav je slučaj i u
drugim finansijskim sistemima. Samo izuzimanje sa računa, saldiranje, poravnanje i
druge operacije iste su u svim sistemima na svim nivoima , vrše se nad istim objektima i
na isti način.
6.2.2.4 Razvoj po nivoima
Na svim nivoima komponente sistema u nastavku su jednake:
• transport poruke;
• prijem poruke;
• pretprocesiranje poruke;
• postprocesiranje poruke;
• korišćenje servisa Registracionog tela.
Razlika se pojavljuje isključivo u modulu za procesiranje koji treba da se posebno
razvija za sve nivoe prema profilu institucije i njenim proizvodima i uslugama koje
pruže svojim klijentima. Već prilikom zadavanja standarda ili proučavanjem već
zadatog standarda potrebno je uraditi odgovarajuću analizu i determinisati modele koje
treba razviti i implementirati, kako od strane finansijske institucije, tako i od
proizvođača rešenja.
6.2.3 Ključni indikatori performansi
Postoje dve kategorije PKI koje mogu da budu razmatrane u elektronskom poslovanju
platnih sistema [115]:
• PKI sistema
• Standardni elementi PKI poslovanja.
Lernerov prikaz sistema [111], slika 114, prikazuje sistem i sredinu. Sredina u slučaju
elektronskog poslovanja platnih sistema je unija drugih sistema elektronskog
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 216
poslovanja, jedan od njih je nadređeni, neki su na istom nivou, dok su drugi podređeni
sistemi [184]. Na istu sliku nailazimo i prilikom strukturne sistem analize sistema (na
primer na konteksnom SSA dijagramu); nalazimo da sistem sa sredinom razmenjuje
informacije preko interfejsa, nadređenog sistema, ravnopravnih i podređenog sistema.
Jedan sistem drugom predaje informacije bitne za izvršavanje upravljačkih radnji i za
upravljača i upravljanje sistemom [156]. I drugi sistem prima informacije (indikatore
potrebne za upravljanje, iz kojih za svaki sistem posebno mogu da se izdvoje
odgovarajući PKI), koje su takođe bitne i iniciraju izvršenje upravljačkih radnji [221],
pa odatle sledi da uvek postoji i drugi sistem koji je dualan onom koji smo inicijalno
posmatrali i da svaki sistem ima svoj dualan sistem: jedan nadređeni i drugi podređeni,
odnosno upravljani i upravljački.
Slika 114. Lerner: Sistem i sredina
Y – ulazna dejstva, X – izlazna dejstva
Upravljački sistemi koriste u značajnoj meri one upravljačke informacije koje su
indicirane sa PKI. Skupovi informacija [190] koji razmenjuju upravljani i upravljački
sistem u cilju obavljanja osnovne delatnosti i upravljanja funkcionišu na principu
razmene potpunog sistema poruka, od kojih je jedan deo vlasništvo upravljanog sistema
a drugi sistema koji upravlja. Pošto su sistemi poruka i vlasništvo jednog i drugog
sistema, oba sistema moraju da budu sposobna za razmenu i procesiranje poruka i iz
jednog i iz drugog sistema, pa samim tim moraju da imaju istu strukturu. Oni veštački
mogu da imaju drugu pojavnost, odnosno da na različit način procesiraju i predstavljaju
elemente istih poruka, i to ne prestavlja optimalno rešenje. Odatle sledi da oba navedena
sistema moraju da imaju istu strukturu. Elementi elektronskog poslovanja u najvećoj
meri su u direktnoj zavisnosti od upravljačkih PKI, kompoziti su i sačinjeni od jednog
ili više upravljačkih PKI, ali su lakše merljivi [46]. Za elektronsko poslovanje platnih
sistema za merenje performansi od značaja su:
• kvalitet;
• troškovi;
• prilagodljivost;
• potražnja;
• brzina;
• inovativnost servisa.
6.2.4 Izbor metodologije razvoja i implementacije
Cilj projektovanja je, najčešće, idealna varijanta informacionog sistema. U tu svrhu se
koristi veliki broj različitih metoda. U ovom poglavlju će biti razmatrani različiti aspekti
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 217
optimizacije procesa projektovanja i izbora strategije projektovanja informacionih
sistema i jedan od mogućih pristupa optimalnom projektovanju informacionih sistema.
Mnogobrojne knjige i radovi posvećeni su pitanju optimizacije. Njihovi autori su
uglavnom matematičari, a njihova osnovna tema su matematički aspekti postavljanja i
rešavanja zadataka optimizacije. Savremena teorija optimizacije pokušava da
uvođenjem novih metoda odgovori na zahteve stručnjaka iz različitih oblasti, nažalost sa
polovičnim uspehom. Naime, formalne metode ne odražavaju realnu situaciju u kojoj se
nalaze projektanti, tako da postoji sve veća potreba za novim i boljim metodama koje bi
omogućile optimizaciju samog procesa projektovanja. Pored velikog broja metoda za
projektovanje informacionih sistema, ne postoji efektivna formula za izračunavanje
optimalne strategije u izboru i primeni u projektovanju informacionih sistema. U
najboljem slučaju prisutne su samo naznake prednosti i mana pojedinih metoda
projektovanja, bez dubljeg uvida u problem optimalnosti projektovanja informacionih
sistema.
Sa matematičkog stanovišta, problem optimizacije svodi se na sledeće: data je funkcija
F(X) za koju treba pronaći maksimum, a da pri tome X zadovoljava uslov A(X)<=B.
Pritom X i B treba posmatrati kao višedimenzione vektore, a F i A kao funkcije nad
vektorima, bez ikakvih daljih ograničenja. Pojedine vrednosti u vektoru predstavljaju
vrednosti parametara koji utiču na optimalnost odabrane funkcije. Ako izaberemo
odgovarajuća ograničenja za tip funkcije F(X) i dodamo odgovarajuća ograničenja na
skup dozvoljenih vrednosti promenljive X, dobijamo pojedine zadatke optimizacije koji
su u opštem slučaju rešeni i imaju odgovarajuće nazive i metode za rešavanje.
Opisno definišimo specijalni slučaj problema optimizacije procedure projektovanja
informacionog sistema. Definišimo najpre ciljnu funkciju procedure projektovanja
informacionog sistema: F(X) možemo da iskažemo numerički, kao finansijski rezultat
projektovanja, realizacije i implementacije zadatog informacionog sistema. Ukoliko
posmatramo već projektovani i implementirani informacioni sistem vrednost ciljne
funkcije (i meru optimalnsti) vrlo grubo možemo da izrazimo na sledeći način kao u
formuli (4):
(4) F(X)=A(X)-B(X)
gde je A(X) finansijski rezultat primene informacionog sistema u toku njegovog
životnog ciklusa, a B(X) ukupni troškovi njegove primene. Za poređenje različitih
varijanti Xi dovoljno je izvršiti procenu vrednosti F(Xi) i jednostavno izabrati
najpovoljniju. Ukoliko projektujemo novi informacioni sistem, problem je što u
trenutku izbora strategije projektovanja ne postoji dovoljno informacija za rešavanje
problema. Tada moramo da obratimo posebnu pažnju i na vrednost troškova
projektovanja sistema. Ali ni ova vrednost ne obuhvata samo cenu izrade projekta.
Treba imati u vidu i izgubljenu dobit u toku projektovanja i realizacije projekta (faktor
vreme) i naročito mogućnost neuspeha (izraženu preko verovatnoće uspeha projekta ili
još bolje preko raspodele verovatnoće uspeha projekta u odnosu na vreme i stepen
realizacije projekta). U slučaju neuspeha treba uračunati troškove projektovanja i
realizacije sledeće varijante projekta. Funkcija cilja, dosta pojednostavljena, u ovom
slučaju dobija oblik kao u formuli (5):
(5) F(X)=(A(X)-B(X) - C(X))*p(X-) - (B(X)+C(X)+F(X1))*(1-p(X))
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 218
gde su C(X) troškovi projektovanja informacionog sistema X, p(X) verovatnoća
uspešne realizacije, a X1 nova varijanta, koju moramo da projektujemo u slučaju
neuspeha. Očigledno, zanemarili smo moguće komplikacije sa delimičnim uspehom i
raspodelom verovatnoće uspeha, odnosno delimičnog uspeha u vremenu. Kada na
komplikovanu ciljnu funkciju dodamo niz ograničenja koja se odnose na različite
aspekte kao što su vreme, finansije, hardver, softver, kadrovi, standardi i spisak želja
investitora, dobijamo zadatak čije bi teorijsko rešavanje, blago rečeno, zahtevalo
ogromne resurse i neograničeno vreme uz neizvestan uspeh .
Slika 115. Ciljna funkcija i ograničenja
Na slici 115. prikazana je grubo pojednostavljena prezentacija ciljne funkcije i
ograničenja procedure projektovanja informacionog sistema. Osenčena oblast na slici su
dozvoljeni pristupi projektovanju informacionih sistema. Oko tačke L nalaze se
optimalni pristupi projektovanju.
Pošto smo zaključili da matematičko razmatranje problema optimizacije projektovanja
informacionih sistema može da bude strahovito komplikovano i da nije svrsishodno,
pokušaćemo da problem rešimo procenom dejstva pojedinih ograničenja. Procena je da,
u stvari, bolji ukupan rezultat daje informacioni sistem u okviru zadatih ograničenja,
koji se brzo i sigurno projektuje i realizuje, čak i ukoliko sam za sebe nije optimalan u
odnosu na „savršen“ informacioni sistem, za koji je vreme projektovanja veće i
verovatnoća uspešne realizacije manja. Za optimalnost informacionog sistema, takođe,
veliki značaj ima njegova prilagodljivost novonastalim situacijama i standardima.
Sa stanovišta naručioca, postaje očigledno da idealno rešenje, koje samo za sebe daje i
najbolji rezultat, ukoliko uzmemo u obzir i sam proces projektovanja, ne mora da bude,
i najčešće nije, optimalno. I sa ovog stanovišta, nameće se ideja da je vrlo blizu
optimuma svaka metoda koja brzo i uz minimalni rizik daje zadovoljavajuće rešenje,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 219
koje se uz to može efikasno prilagođavati novim zahtevima. Pritom naročito treba imati
u vidu još jedan skup ograničenja: skup relevantnih standarda koji se odnose na oblast
primene informacionog sistema i/ili na tehnička rešenja koja treba primeniti.
Standardnim metodama najveći problem predstavlja faza prikupljanja i analize zahteva.
Metode u kojima se intervjuima i sličnim istraživanjima utvrđuju potrebe pre svega su
izuzetno spore (vreme je novac), a zatim i vrlo neprecizne. Često dobijamo masu
protivrečnih, terminološki neusklađenih i po važnosti neizbalansiranih zahteva. Pored
gubitka na vremenu, tokom projektovanja velika je verovatnoća da i sama realizacija
potraje neplanirano dugo i/ili da se završi neuspehom. (Odgovarajući statistički podaci o
uspehu projekata mogu se utvrditi i može im se manje ili više verovati).
Standard Standard Standard
POZICIJE VREDNOSTI
Pozicija
vrednosti
Pozicija
vrednosti
Entitet
Entitet
Atribut
Atribut
Veza
Slika 116. Od standarda do implementacije
Drugu krajnost predstavljaju RAD metode, koje kroz saradnju sa krajnjim korisnikom,
odnosno tehnologom posla, brzo daju prototip koji se dalje razvija ili napušta. Sa
stanovišta vremena, situacija je bolja ukoliko projekat uspe, ali je zato verovatnoća
neuspeha prototipa velika. Posebno je velika opasnost da se dobije samo delimično
rešenje problema, koje se teško može dovršiti ili prilagoditi novonastalim situacijama.
Osnovni problem je analiza sistema, u kojoj korisnik često može da odmogne namećući
svoje „želje“ umesto stvarnih potreba. Pretpostavka je da je pravi pristup analiza
standarda koji se odnose na posmatrani sistem i pozicija vrednosti koje ti standardi
prate. Standardima se određuju pozicije vrednosti koje se prate, način njihovog
menjanja, način kontrole i eksploatacije podataka o pozicijama vrednosti, kao i način
odlučivanja u sistemu.
Tabelom 19. data je komparativna analiza faza razvoja sistema po nekim prihvaćenim
metodologijama sa predloženim pristupom. Uočljivo je da RAD-CADM daje prototip
koji može da bude zadovoljavajući (ali ne mora, što RAD svrstava u grupaciju
„rizičnih” metoda), a da aplikacija dobijena našim pristupom mora da bude
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 220
zadovoljavajuća jer proističe iz standarda poslovanja. Analiza je sačinjena u predistoriji
sistema tako da je u predloženom pristupu dovoljna konstruktivna analiza standarda iz
koje proističe definisan fizički model podataka nad kojim se razvija aplikativni nivo.
Odabrani skup pozicija vrednosti koji se prati direktno determiniše implementaciju
informacionog sistema, uzevši u obzir zadate odluke i standarde (slika 116.). On je
determinisan u svakoj fazi implementacije sem predistorije sistema jer u fazi analize
standarda postoji odluka na osnovu standarda (taj standard je uglavnom maksimiziranje
dobiti od rada informacionog sistema) za utvrđivanje redosleda važnosti pozicija
vrednosti po nekom kriterijumu. Na osnovu tog redosleda, u zavisnosti od
raspoloživosti resursa informacionog sistema i sistema uopšte (na primer raspoloživost
finansijskih sredstava, raspoloživosti kadrova i sl. ) pristupa se analizi standarda
pojedinih pozicija vrednosti u sledu. Na taj način smo obezbedili i mogućnost
parcijalnog pokrivanja poslovnih procesa. Nakon toga, taj deo informacionog sistema
možemo realizovati definisanjem fizičkog modela podataka, eventualnom migracijom
podataka, razvojem aplikacija i implementacijom.
• u fazi definisanja fizičkog modela podataka nije neophodna parcelizacija, izuzev
možda kod izuzetno velikih sistema, sa velikom distribuiranošću podataka i
drugim sličnim pretpostavkama;
• migracija podataka takođe može da se razmatra u prethodnom svetlu, no ona je
uglavnom čvrsto definisana prirodom podataka i tabelama entiteta
ekstrahovanim iz odgovarajućih pozicija vrednosti;
• razvoj aplikacija je čvrsto determinisan pozicijama vrednosti koje aplikacije
prate;
• implementacija čvrsto je determinisana prirodom pozicija vrednosti i za
implementaciju važi slično kao i za analizu standarda.
CADM RAD – CADM Predloženi pristup
Predistorija sistema
Utvrđivanje strategije Utvrđivanje strategije
Priprema analize
Analiza Analiza Analiza standarda
Priprema dizajna
Dizajn
Razvoj
Definisanje fizičkog modela podataka Definisanje fizičkog modela podataka
Migracija podataka Migracija podataka
Izrada prototipa Razvoj aplikacija
Dokumentovanje
Testiranje Testiranje
Implementacija Implementacija Implementacija
Održavanje Održavanje
Tabela 19. Komparacija predloženog pristupa sa CADM i RAD-CADM
metodologijama
Sličan način razmišljanja može se primeniti i u drugim segmentima vezanim za
informacioni sistem i na taj način mogu se sistematski razrešiti neki elementi (u odnosu
na pet navedenih procesa na slici 116.) u predistoriji sistema.
Ukoliko je cilj sagraditi idealan informacioni sistem, projektovanje informacionog
sistema može da bude dugotrajan proces kome, skoro izvesno, nismo sposobni da
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 221
sagledamo kraj. Takav informacioni sistem je poželjan, ali nije realan sa stanovišta
projektovanja jer se u traganju za idealnim gubi dragoceno vreme, a samim tim i
realnost implementacije i eksploatacije. Pri izboru metodologije projektovanja, svakako
treba uzeti u obzir optimalnost procedure projektovanja informacionih sistema.
6.3 Projektni zahtevi
Postoji izražena potreba za kontrolom i upravljanjem platnim sistemom, od samoga
početka – od trenutka kada se zadaju početni poslovni uslovi za rad sistema, pa do
dokumentovanja podataka o sistemu i podataka o radu ovih sistema velike složenosti.
Platni sistemi su u interakciji sa odgovarajućim sistemima na drugim nivoima koji
takođe imaju svoju veliku složenost [36]. Upravljanje podređenim sistemima je
posredno, preko pravila definisanih od strane nadređenog sistema. Pravila moraju da
budu takva da se prenose po dubini na sve podređene sisteme, i na one koji nisu pod
direktnom jurisdikcijom glavnog upravnog sistema. Interakcija između sistema mora da
bude po predviđenom protokolu koji ima svoje visoke zahteve, koji ne smeju da budu
narušeni ni po koju cenu, jer se radi o izuzetno važnim sistemima. Sistemi moraju da
rade u realnom vremenu, u predviđeno radno vreme, bez obzira na uslove poslovanja, sa
podacima koji moraju da budu neporecivi. Platni sistemi, bez obzira na nivo u
hijerarhijskoj strukturi na kome se nalaze, treba da budu nadogradivi sa novim
poslovnim procesima bez narušavanja stabilnosti rada postojećih poslovnih procesa.
Platni sistemi moraju da budu u interakciji sa različitim drugim postojećim platnim
sistemima, kao i da poseduju odgovarajuću adaptibilnost komunikacije u odnosu na
nove platne sisteme sa kojima treba da komuniciraju. Platni sistemi, bez obzira na
poslovni nivo na kome se nalaze, moraju da sadrže elemente koji omogućavaju rad sa
globalnim korisnicima. Takođe, treba da budu izgrađeni u što je moguće većoj meri na
bazi standarda (čak i po cenu uvođenja novih standarda) uključujući i permanentno
otkrivanje standardnih elemenata i njihovu standardizaciju. Prelazak na novi platni
sistem nad istim domenom treba da bude moguć, odnosno platni sistem ne sme da bude
zasnovan na takvim elementima koji će onemogućiti prelazak na novi sistem. Iako su
platni sistemi složeni, pažljivom analizom mogu se uočiti standardni elementi koji se
mogu izgraditi i implementirati na različite ekvivalentne načine, od strane različitih
proizvođača, sa različitim performansama i to bez gubitka predviđenih funkcionalnosti.
Rešavanje složenosti platnih sistema i njihovo upravljanje može da se reši korišćenjem
osobina rekurzije. Razmena informacija u okviru platnog sistema i sa okolinom platnog
sistema može da bude putem protokola, a da kao osnovna jedinica za razmenu
informacija (komunikaciju) bude poruka sa definisanim klasama u odnosu na vrstu
upotrebe informacija sadržanih u porukama. Na sadašnjem nivou razvoja IT industrije,
postoje različite vrste alata predviđenih za razvoj i distribuciju sistema. Alatima,
prisutnim na tržištu, ukoliko slični a potrebni za razvoj platnih sistema ne postoje, mogu
se na lak način izraditi odgovarajući novi.
Osnovni zahtevi koji se postavljaju pred platni sistem jesu:
• nezavisnost rešenja od domena korišćenja;
• stabilnost u dužem vremenskom okviru;
• mogućnost lakog dodavanja, mogućnost modifikacija, zamena, uvećanja,
izmene ili pripajanja funkcionalnosti;
• lakoća skaliranja u mnogo smerova;
• da troškovi razvoja budu niski i raspoređeni kroz vreme;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 222
• prilagodljivost;
• neograničenost integracije;
• neograničenost proširivosti;
• da zahteva ograničene ili manje zahtevne resurse;
• da ima kompletno izolovanu aplikativnu logiku;
• minimalnost troškova održavanja;
• stabilnost;
• neograničenost konfiguracije i rekonfiguracije;
• dokumentovanost izrade sistema;
• dokumentovanost rada sistema;
6.3.1 Projektni zadatak
Opis funkcionalnih i nefunkcionalnih zahteva koji se propisuju za jedan ovakav sistem
prikazan je na primeru specifikacije zahteva za Credit Transfers. European Payment
Council (EPC) u skladu sa jedinstvenim sistemom za plaćanje 8 marta 2006. godine
odobrila je SEPA CREDIT TRANSFER SCHEME RULEBOOK, verziju 2.0 pod šifrom
EPC125-05. Rulebook je iskorišćen za formiranje spiska funkcionalnih i
nefunkcionalnih zahteva potrebnih za formiranje specifikacije sistema koji bi bio u
skladu sa SEPA Credit Transfers-om.
Spisak nefunkcionalnih i funkcionalnih zahteva nije ni na koji način strukturiran i
sačinjen je onim redom kojim su se zahtevi pojavljivali.
Ovaj dokument sadrži i spisak aktora u sistemu radi definisanja i lakšeg razumevanja
funkcionalnosti i nefunkcionalnosti.
Ovaj dokument sadrži i model, i to predstavljen na onaj način na koji ga vidi EPC i koji
može da predstavlja polaznu osnovu za izgradnju konceptualnog modela sistema.
• Nalogodavac (Originator) je korisnik koji inicira Credit Transfers
instrukcijama upućenim svojoj banci. Sredstva za ovako definisan Credit
Transfers biti će dostupna u smislu zaduženja za specificirani račun za plaćanje
čiji je vlasnik nalogodavac.
• Banka nalogodavca (Originator Bank) je učesnik koji prihvata instrukcije za
Credit Transfers od nalogodavca i radi po instrukcijama plaćanja izvršavajući
plaćanje u korist banke primaoca i računa primaoca, u skladu sa informacijama
obezbeđenim putem instrukcija i u skladu sa odredbama.
• Banka primaoca (Beneficary Bank) je učesnik koji prima instrukcije za Credit
Transfers od banke nalogodavca i odobrava račun primaoca u skladu sa
informacijama obezbeđenih putem instrukcija i u skladu sa odredbama.
• Primalac (Beneficiary) je korisnik identifikovan sa instrukcijama Credit
Transfers-a koji prima sredstva u smislu odobrenja na svom računu za plaćanje.
• Mehanizam za kliring i poravnanje (Clearing and Settlement Mechanisms -
CSM) je takav da uključuje servise za poravnanje i plaćanje kao što je
automatska klirinška kuća ili drugi mehanizam, kao što je međubankarsko
poravnanje, poravnanje u okviru grupe, bilateralno ili multilateralno poravnanje,
aranžman u okviru grupe među učesnicima i drugi ugovoreni načini
kompenzacije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 223
• Banka posrednik (Intermediary Bank) nudi posrednički servis između banke
nalogodavca i banke primaoca u slučaju kada banka nalogodavca nije direktni
učesnik CSM-a.
Pred izvođača se postavlja i sledeća tehnička specifikacija:
Tehnička specifikacija koju izvođač mora da ispuni
Tehnički zahtevi sistema su skalabilnost, adaptibilnost i proširljivost, fleksibilnost,
poverljivost i integritet.
Skalabilnost
• sistem se mora implementirati da bi se obezbedio (saglasno dizajnu) visok nivo
skalabilnosti, a posebno sa aspekta uvećanog obima podataka u postojećim
bazama podataka, prenos informacija, uvećanje broja raspoloživih servisa i
uvećanje broja korisnika servisa;
• obezbeđivanje skalabilnosti ne treba uticati na održavanje traženih nivoa
sigurnosti, raspoloživosti i performansi.
Povećanje poslovnog opterećenja sistema primarno moglo bi da bude prouzrokovano
od:
• povećanja količine informacija u postojećim bazama podataka informatičkih
sistema koje postoje u institucijama uključenih u sistem;
• povećanja broja transakcija;
• povećanja broja servisa;
• povećanja složenost transakcija;
• povećanje kompleksnosti servisa;
• povećanje broja korisnika (krajnjih korisnika ili drugih sistema).
Sistem mora biti implementiran na takav način da omogući povećanje kapaciteta
procesiranja proporcionalno radnom potencijalu, bez promena u arhitekturi.
Adaptiabilnost i proširivost
Pojam adaptiabilnost podrazumeva sposobnost lake modifikacije postojećih
funkcionalnosti u jednom sistemu. Proširivost podrazumeva sposobnost lakog
dodavanja novih funkcionalnosti u jednom sistemu. Dizajn sistema obezbeđuje da se
adaptiabilnost i proširivost ne dese po cenu opadanja sistemskih performansi
svakodnevnog rada. Izvođač treba detaljno da elaborira kako će da implementira sledeće
zahteve:
• dodavanje novih usluga (servisne registre);
• dodavanje novih tipova podataka (mogući su multimedijski i biometrijski
podaci);
• dodavanje novih meta opisa;
• dodavanje novih korisnika i uloga;
• dodavanje novih servisa koji potiču sa jednog sistema za pružanje usluga;
• dodavanje novih servisa koji potiču sa vise sistema za pružanje usluga;
• kreiranje novih servisa koji predstavljaju kombinaciju postojećih servisa;
• implementacija polisa i pristup servisima;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 224
• implementacija polisa i pristup podacima preko korišćenja servisa.
Fleksibilnost
Termin fleksibilnost definiše sposobnost obezbeđivanja usluga različitim korisnicima
(korisnik, grupe korisnika, glupe korisnika i aplikacija) sa nekoliko različitih načina za
dobijanje podataka. Fleksibilnost sistema se obezbeđuje preko mogućnosti da se koriste
srodni servisi više sistema za pružanje usluga (ukoliko takvi postoje). Izvođač treba
detaljno da elaborira kako će mapirati sledeće elemente u konkretnom rešenju:
• tipovi korisnika;
• servisi omogućeni u sistemu;
• procesi koji postoje u institucijama;
• različiti servisi za različite kategorije (tipove) korisnika;
• vidovi pristupa i/ili servisa za spoljašnje aplikacije (korisnike).
Integritet
Integritet informacija podrazumeva da se iste informacije i podaci tretiraju na isti način
u sistemu, odnosno da ne postoji mogućnost za različito tumačenje iste informacije. U
dizajn sistema su predviđeni medijatorski interfejsi koji treba da izvrše prilagođavanje
formata podataka preko njihove konverzije u XML šemu. Uvek kad postoje, treba da se
upotrebljavaju standardi za razmenu podataka. Izvođači treba da navedu koje standarde
za razmenu podataka (multimedija, biometrija i slično) koriste u svom rešenju. Izvođač
treba detaljno da elaborira kako će obezbediti da podaci koji se koriste budu identično
interpretirani i mapirani sa podacima dostavljenim iz različitih sistema za pružanje
usluga.
Sigurnosna potraživanja sistema interoperabilnosti
Sigurnosne, odnosno bezbednosne zahteve interoperabilnosti koji su definisani u
standardu ISO 17799, Sistem za upravljanje sa sigurnosnom informacijama. Ovaj
standard pokazuje sigurnost IT sistema kao rezultat dizajniranja, sprovođenja,
rukovođenja i kontinuiranog unapređenja.
Sigurnost informacija: moraju se primenjivati sigurnosne polise i periodično revidirati i
ažurirati u odnosu na rizik za narušavanje sigurnosti. Polise su definisane sa:
• opisom strana involviranih u servisu: korisnici, administratori, rukovodioci i
kontrolna tela;
• uloge i odgovornosti strana uključenih u obezbeđivanje servisa sa aspekta
primene i upravljanje polisama; uloge i odgovornosti mora da su jasno
definisane, identifikovane i periodično kontrolisane.
Kao podršku polisama, izvođači moraju obezbediti mogućnost definisanja aplikativne
podrške operativnim procedurama, koje prenose principe sigurnosne politike u praksi (u
različitim tehnološkim sredinama, za različite korisnike i sistemske operatore). Glavne
operativne procedure su:
• procedure koje omogućavaju prikladnu zaštitu, snimanje zaštitnih kopija i
arhiviranje definisanih servisa, koji će obezbediti mogućnost za obnavljanje
dostupnosti servisima nakon eventualnih prekida u radu;
• procedure za monitoring i kontrolu svih nivoa infrastrukture moraju biti
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 225
povezane sa postupcima za verifikaciju i kontrolu, što omogućuje otkrivanje i
sleđenje preuzetih operacija pri korišćenju servisa;
• procedure za spravljanje sa nedozvoljenim zahtevima za korišćenje usluge i
prikladne reakcije u slučaju prestupa ili problema sigurnosti sistema;
• procedure za autorizaciju i pristup sistemu, kao i procedura za kreiranje,
upravljanje i brisanje korisnika;
• procedura za primenu kriptografske zaštite; jasno se mora definisati :
o gde, za koje poruke i kad treba koristiti kriptografsku zaštitu;
o kako se upravlja ključevima kriptografske zaštite;
o kako reagovati u slučaju problema sa zaštićenim porukama ili pri
gubljenju sertifikata ili ključeva za kriptografsku zaštitu;
• procedure za povezivanje prema postojećim informacionim sistemima u
institucijama; postupak mora uključivati i definisanje osnovnih nivoa sigurnosti,
periodične provere i zaštitne mere koje treba preduzeti.
• servisi su predmet kontrole i moraju obezbediti način za sleđenje porekla i prava
korisnika servisa; pri tome treba voditi računa o:
o regulisanju dostupnosti usluga spoljašnjim telima;
o opisu domena bezbednosti u saglasnosti sa nacionalnim i internim
sigurnosnim regulativama:
polisa nacionalnog nivoa, polisa određene institucije i slično;
klasifikacija informacija i odgovornosti u skladu sa evropskim
bezbednosnim regulativama;
savet Evropske unije;
definisanje prava pristupa i ograničavanje pristupa podacima;
definisanje bazičnog nivoa bezbednosti (politike poverenja) koje
se primenjuje na sve strane koje komuniciraju sa sistemom za
interoperabilnost elektronskog poslovanja platnih sistema.
Moraju se obezbediti postupci za centralnu evidenciju koji obezbeđuju periodičan
monitoring, uključujući upravljanje alarmima, pri korišćenju servisa. Važno je
napomenuti da evidentiranje ne obuhvata same podatke, nego samo korisnike servisa,
tip servisa i metaopisa servisa. Aktivnosti koje treba da se evidentiraju uključuju:
• sva potraživanja za korišćenje servisa;
• sve odgovore na potraživanje i uspešne i neuspešne;
• meta opis servisa;
• sve ostale komunikacije između sistema za pružanje servisa;
• sva logovanja korisnika i sve izvršene događaje, kao i neuspešna ili neovlašćena
logovanja.
Centralna evidencija mora omogućiti administratorima da slede aktivnosti po vremenu
njihovog izvršenja i da identifikuju korisnike koji su izvršili svaku pojedinačnu
aktivnost, i po potrebi, pomoći ovim korisnicima da identifikuju krajnje korisnike. Zbog
toga što se nijedna aktivnost ne može izvršiti ukoliko se ne može evidentirati, sistem
evidentiranja mora uvek biti na raspolaganju i mora predvideti sekundarno/bekap
skladištenje podataka za evidenciju. Podaci za evidenciju se ne mogu modifikovati.
Podaci za evidenciju se ne mogu brisati pre zakonskog datuma isticanja važnosti.
Evidencija mora biti raspoloživa jednu godinu i treba se arhivirati najmanje dve godine.
Svaki korisnik mora biti u mogućnosti da pregleda evidenciju svih aktivnosti izvršenih
sa njegove strane ili aktivnosti izvršenih na njegovim podacima. Možda će trebati da se
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 226
evidencija transakcije korisnika vrati korisniku pa zbog toga treba obezbediti mere za
pojednostavljenja ovog zadatka. Evidencija se isto tako može koristiti i u statističke
ciljeve. Moraju se razviti funkcije ili alati za izveštavanje i analizu kako bi se obezbedili
izuzeci u upotrebi i obradive informacije recenzentima.
Autentifikacija
Za smanjivanje rizika od neovlašćenog pristupa, potrebno je obezbediti mogućnost
primene jakog sistema za autentifikaciju za određene tipove ili uloge korisnika. Takva
autentifikacija se odvija preko primene „autentifikacije u dva nivoa” koja se bazira na
nečemu što „posedujete” i „nešto sto korisnici znaju”. Preporučena infrastruktura takve
autentifikacije sadrži: hardverski čip (token) za potvrđivanje identiteta i lozinke. Tokeni
su obično predstavljeni kao mobilne inteligentne kartice ili čipovi, koji nezavisno
čuvaju i kreiraju informacije sa funkcijom potvrđivanja. Ovi uređaji moraju biti
zaštićeni od kopiranja i neovlašćenog rukovanja. Oni onemogućuju čitanje informacija
sadržanih u uređaju (predstavljaju uređaje sa zaštitom protiv neovlašćenog rukovanja).
Kontrola pristupa
Kontrola pristupa se mora zasnovani na „potrebnim informacijama”, tako da pristup
treba ograničiti na oblast potrebnu za izvršavanje radnih zadataka za pojedinačne
korisničke uloge. Pravo pristupa svih korisnika mora se konfigurisati na bazi uloga i
profila koji se upravljaju centralno. Izvođač mora obezbediti mogućnost definisanja
aplikativne podrške za monitoring i pregledanje pristupa, sa mogućnošću periodičnih
izveštaja za iskorišćavanje prava pristupa.
Enkripcija podataka
Izvođač treba da obezbedi mogućnost kriptografske zaštite na nivou poruke koja će se
primeniti kao rezultat aktiviranja određene sigurnosne polise. Pri tome, mora se izvršiti
potvrda autentičnosti učesnika u procesu razmene poruka.
6.3.2 Funkcionalni zahtevi
Na osnovu analize dokumenta EPC125-05 SEPA Credit Transfers Scheme Rulebook,
sistem treba da zadovolji sledeće funkcionalne zahteve:
• da nalogodavac kompletira instrukcije Credit Transfersa;
• da nalogodavac pošalje instrukcije Credit Transfersa;
• da se instrukcija pošalje na način dogovoren između nalogodavca i njegove
banke;
• da elementi koji moraju da budu obezbeđeni od strane nalogodavca budu
sledeći:
01 IBAN pošiljaoca kome će sredstva biti zadužena Credit
Transfers instrukcijom;
02 Ime pošiljaoca;
03 Adresa pošiljaoca;
04 Iznos transakcije u Evrima;
05 Informacije o doznaci od strane pošiljaoca primaocu sredstava
u okviru Credit Transfers instrukcije;
07 Zahtevani dan izvršenja instrukcije;
10 Identifikacioni kod pošiljaoca;
20 IBAN primaoca koji će biti odobren;
21 Ime primaoca;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 227
22 Adresa primaoca;
23 BIC banke primaoca;
24 Identifikacioni kod primaoca;
41 Referenca pošiljaočeve Credit Transfers transakcije,
• da banka nalogodavca primi potrebne informacije za inicijaciju Credit
Transfers-a;
• da banka nalogodavca proveri informacije za inicijacije Credit Transfers-a;
• da banka nalogodavca dopuni instrukcije uslovima potrebnim za njihovo
procesiranje;
• da banka nalogodavca uključi autentifikaciju instrukcije;
• da banka nalogodavca proveri format BIC-a i IBAN-a;
• da banka nalogodavca proveri prihvatljivost BIC-a i IBAN-a;
• da banka nalogodavca na zadati dan izvršenja zaduži račun nalogodavca;
• da nakon zaduženja računa nalogodavca pošalje Credit Transfers instrukcije
obezbeđujući prijem od strane banke primaoca preko odgovarajućeg Credit
Transfers mehanizma i to najranije na zadati dan zaduženja a najkasnije dva
dana od zadatog dana zaduženja u skladu sa pravilima Credit Transfers
mehanizma;
• da elementi koji se obezbeđuju za slanje ka Credit Transfers mehanizmu budu
sledeći:
01 IBAN pošiljaoca kome će sredstva biti zadužena Credit
Transfers instrukcijom;
02 Ime pošiljaoca;
03 Adresa pošiljaoca (opciono);
04 Iznos transakcije u evrima;
05 Informacije o doznaci (opciono);
06 BIC banke pošiljaoca;
10 Identifikacioni kod pošiljaoca (opciono);
20 IBAN primaoca;
21 Ime primaoca;
22 Adresa primaoca (opciono);
23 BIC banke primaoca;
24 Identifikacioni kod primaoca (opciono);
40 Identifikacioni kod elektronske SEPA Credit Transfers šeme;
41 Pošiljaočeva referenca Credit Transfers transakcije (opciono);
42 Datum izvršavanja Credit Transfers instrukcije;
43 Referenca Credit Transfers poruke primaočeve banke
(opciono),
• da Credit Transfers mehanizam pošalje poruku banci primaoca;
• da Credit Transfers mehanizam izvrši Credit Transfersa u punoj vrednosti
najkasnije dva dana od zadatog datuma izvršenja kao deo procesa za poravnanje
i plaćanje u skladu sa pravilima i ugovorenim modalitetima;
• da banka primaoca primi poruku o Credit Transfersu najkasnije dva dana od
zadatog dana izvršenja;
• da banka primaoca proveri poruku o Credit Transfers-u;
• da banka primaoca odobri račun primaoca;
• da obezbedi informacije primaocu na osnovu ugovora između primaoca i banke i
to najkasnije jedan dan nakon izvršenja (znači najkasnije 3 dana od zadatog
datuma izvršenja, izuzev u slučaju zakonskih ograničenja povezanih sa pranjem
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 228
novca i finansiranja terorističkih aktivnosti i ukoliko treći dan nakon zadatog
datuma izvršenja nije radni dan):
02 Ime pošiljaoca;
04 Iznos transakcije u Evrima;
05 Informacije o doznaci;
10 Identifikacioni kod pošiljaoca;
20 Primaočev IBAN;
21 Ime primaoca;
24 Identifikacioni kod primaoca;
41 T Pošiljaočeva referenca Credit Transfers transakcije;
42 Datum izvršenja Credit Transfers instrukcije(opciono),
• da banka nalogodavca ili kredit transfer mehanizam odbije Credit Transfers
ukoliko nije prihvaćen za normalno izvršenje pre međubankarskog poravnanja,
• da, ukoliko je Credit Transfers u trenutku kada je nalogodavac poslao
instrukcije banci nalogodavca, banka nalogodavca mora da obavesti samo
nalogodavca o razlogu zbog koga nije prihvaćen Credit Transfers;
• da, ukoliko je odbijanje izvršenja učinjeno u međubankarskom prostoru poruka
mora da sadrži sledeće podatke:
R1 tip „R” poruke;
R2 Identifikacija tipa strane koja inicira “R” poruku;
R3 Kod razloga neprihvatanja Credit Transfers-a;
R4 Datum izvršenja za „odbijena“ ili „vraćena“;
R5 Specifična referenca banke koja inicira odbijenicu/povratnicu;
Tačna kopija svih primljenih atributa poruke koja je
odbijena/vraćena,
• da transferovana vrednost u odbijanju bude istovetna originalnoj vrednosti
navedenoj u instrukcijama za Credit Transfers;
• da poruka o odbijanju Credit Transfers-a bude poslata istim putem kojim je i
stigla instrukcija za Credit Transfers;
• da nema podataka koji su pridodati originalnom Credit Transfers-u;
• da ima relevantnih podataka o inicijalnom Credit Transfers-u dovoljnih da se
vrši veštačenje ukoliko je potrebno;
• da se inicijalni Credit Transfers identifikuje sa originalnom referencom banke
nalogodavca;
• da poruka o odbijanju Credit Transfers-a sadrži i kod razloga odbijanja Credit
Transfers-a;
• da poruka o odbijanju bude poslata istog dana ili narednog radnog dana banke;
• da poruka o povraćaju bude inicirana od strane banke primaoca ukoliko nije
moguće njeno izvršenje iz nekog razloga kao što su pogrešan broj računa, račun
ugašen i slično sa konsekvencama da račun primaoca ne može da bude odobren
za sumu navedenu u originalnoj poruci nalogodavca;
• da transferovana vrednost povraćaja bude istovetna originalnoj vrednosti
navedenoj u instrukcijama za Credit Transfers;
• da poruka o povraćaju Credit Transfersa bude poslata istim putem kojim je i
stigla instrukcija za Credit Transfers ili da zainteresovane strane ugovore
posebne mehanizme razmene koji mogu da se razlikuju od originalnih;
• da nema podataka koji su pridodati originalnom Credit Transfers-u;
• da ima relevantnih podataka o inicijalnom Credit Transfers-u dovoljnih da se
vrši veštačenje ukoliko je potrebno;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 229
• da se inicijalni Credit Transfers identifikuje sa originalnom referencom banke
nalogodavca;
• da poruka o povraćaju Credit Transfers-a sadrži i kod razloga odbijanja Credit
Transfers-a;
• da poruka o odbijanju bude poslata istog dana ili narednog radnog dana banke
nakon izvršenog poravnanja;
• da poruka o odbijanju inicirana od strane banke primaoca mora biti poslata banci
nalogodavca najkasnije u okviru tri radna dana banke nakon zadatog dana
izvršenja.
6.3.3 Ostali zahtevi
Na osnovu analize dokumenta EPC125-05 SEPA Credit Transfers Scheme Rulebook,
sistem treba da zadovolji sledeće nefunkcionalne zahteve:
• da otkloni razlike nacionalnih i vangraničnih efekata u SEPA zoni;
• da učini SEPA plaćanja efektnim kao u nacionalnom okruženju;
• da SEPA Credit transfers bude automatizovan;
• da bude baziran na otvorenim standardima;
• da bude baziran na najboljim iskustvima vezanim za STP (Straight-through
processing - procesiranje bez ijedne izmene originalne inicijalne forme/zapisa
transakcije);
• da omogući najviše bezbednosne standarde;
• da ukloni faktore zastoja u harmonizaciji standarda i prakse;
• da smanji rizik,
• da smanji troškove;
• da poveća stepen iskorišćenja resursa;
• da omogući dalji razvoj sistema na bazi zdrave konkurencije na tržištu platnih
servisa;
• da uspostavi uslove za nuđenje servisa korisnicima;
• da Credit Transfers bude realizovan po SEPA EPC125-05, EPC170/05 CSM
Framework i EPC029-06;
• da bude namenjena za banke;
• da bude namenjen za infrastrukturne provajdere koji podržavaju operacije
bazirane na tržišnim principima;
• da su jasno razgraničena prava i obaveze učesnika;
• da su poruke bazirane na otvorenim industrijskim standardima;
• da plaćanja budu izvršena za pun originalni iznos;
• da nalogodavac i primalac budu odgovorni za svoje vlastite troškove;
• mogućnost pune dostupnosti računa primaoca u okviru SEPA;
• da proizvodi bazirani na šemi obezbede šansu da se izdaju i primaju nalozi u
SEPA;
• da postoji maksimalno garantovano vreme izvršenja (3 dana);
• da koristi prihvaćene standarde na STP bazi;
• da se odbijanje i vraćanje može obaviti na predvidljiv način;
• da se odbijanje i vraćanje može obaviti automatizovano;
• da učesnici mogu izabrati najbolji i najjeftiniji način rutiranja transakcija;
• da izgradi ugovorene cikluse procesiranja;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 230
• da podrži i druga rešenja plaćanja, posebno RTGS (Real Time Gross Settlement)
i RTNS (Real Time Net Settlement) za urgentna plaćanja i plaćanja preko limita;
• da bude u okviru SEPA po definiciji EPC (25 zemalja EU članica i Island,
Lihtenštajn, Norveška i Švajcarska);
• da bude u valuti EURO u SEPA a računi da budu u EURO ili drugoj valuti –
banka nalogodavca/primaoca je odgovorna za adekvatnu konverziju;
• da budu visokodostupan;
• da poštuje diskreciju nalogodavca i primaoca;
• da obezbedi 140 karaktera koji mogu biti i strukturirani za međusobno
automatsko poravnanje nalogodavca i primaoca.
6.4 Analiza zahteva
Cilj analize je da se opiše poslovni model jednog primera platnog sistema nad kojim će
se moći izvršiti generalizacija i uočiti poslovni procesi ili funkcije platnih sistema koji
se po svojoj prirodi razlikuju od jedne do druge vrste platnog sistema [24], [10]. Uočene
razlike između platnih sistema tada se mogu grupisati u jedan modul da bi se dobila
struktura opšte namene ili definisati pojedinačno ukoliko se vrši komponovanje platnog
sistema posebne namene. Time se ispunjava tvrdnja da se sistemi složeni kao sistemi za
platni promet mogu razložiti na standardne elemente koji se mogu implementirati na
različite ekvivalentne načine.
6.4.1 Specifikacija CT
Credit transfers sistem se odvija distribuirano na tri nivoa, kako je to već naglašeno u
razmatranju EPC modela za Credit transfers.
Legenda:
Credit Transfers: transfer sredstava
Credit Transfers Initiation: započinjanje transfera sredstava
Retail System: sistem „na malo“
Bank’s Retail Credit Transfer System: sistem banke „na malo“ za transfer sredstava
Retail Reporting: izveštavanje iz sistema „na malo“
Credit Transfers Clearing & Settlement: kliring i poravnanje transfera sredstava
Bank’s Processor Credit Transfer System: sistem banke za transfer sredstava procesoru
Processor’s Neto System: procesorov neto sistem
Procesor’s Reporting: izveštavanje procesora
RTGS Settlement: RTGS poravnanje
Procesor’s Bruto system: procesorov bruto sistem
RTGS Reporting: RTGS izveštavanje
Slika 117. Credit Transfers kontekst dijagram, dva najviša nivoa
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 231
Prvi nivo je kod Retail korisnika, proces 1.1 na slici 117, i povezan je sa procesima
inicijacije Credit transfers-a, kao i kod banke gde se nalazi deo sistema koji je zadužen
za procese povezane sa Retail korisnicima. Drugi deo procesa se nalazi u procesu 2,
naznačen sa 2.1, i on se bavi procesima koji su orijentisani ka nadređenim institucijama
za procesiranje. Sada je vidljiv gap između dva dela sistema koji se nalaze u banci: dela
koji je orijentisan ka podređenom Retail delu sistema i dela koji je orijentisan ka
nadređenom delu platnog sistema, odnosno nadređenim institucijama. Gap se odgleda u
tome da deo sistema ka podređenim institucijama ima zadatak da izvrši što veći broj
transakcija, da bude prijemčiv za korisnike, da izlazi u susret korisnicima u
diskutabilnim situacijama i da ih razrešava u njihovu korist, da bude marketinški
orijentisan prema korisnicima da bi se realizovao što veći broj transakcija koji će sistem
u banci moći da naplati.
Sistem koji je orijentisan prema nadređenoj instituciji nalazi se u situaciji da izvrši samo
najneophodniji deo transakcija, da pronađe diskutabilne transakcije i da ih vrati na
reviziju zbog rizika troška koji bi pogrešna transakcija mogla da izazove, da bude
pesimistički orijentisan prema nadređenoj instituciji koja obračunava svaku transakciju,
pa tako da pokušava da optimizuje transakcije grupišući ih u veći broj, čekajući da ih se
nakupi što više pre realizacije. Čak i realizaciju, deo sistema u banci koji je orijentisan
prema nadređenoj instituciji, pokušava da izvrši što kasnije, u poslednjem trenutku, jer
se na taj način iz banke plasira minimalna količina sredstava, a to znači više para koje
ostaju u banci. Slična paradigma je i za procese 2.3 i 3.1 u delu platnog sistema koji se
nalazi u procesorskoj kući, na primer u Automated Clearing House. Navedeni procesi i
njihov osnovni položaj u platnom sistemu prikazani su na slici 117. Procesi izveštavanja
su vezani za zakonom regulisane izveštaje kao i pogled koji vlasnik sistema nalazi
potrebnim prilikom korišćenja sistema.
Standardi su još uvek zadati na engleskom jeziku. U Srbiji i danas postoji veoma malo
standarda koji su prevedeni. Ukoliko bi analize bile vršene isključivo na srpskom jeziku
izgubio bi se u mnogim slučajevima kontekst standarda na engleskom jeziku. Iz tog
razloga, analiza koja je urađena u ovom radu na slikama je prikazana na engleskom
jeziku i za svaku sliku data je i odgovarajuća legenda koja ima za cilj da uvede termine
koji su uobičajeni na srpskom jeziku. Na sajtu Narodne banke Srbije ne postoji rečnik
osnovnih termina na stranim jezicima sa zadatim službenim prevodom na srpski jezik.
Retail sistem, odnosno proces 1, prikazan je na slici na slici 118. Proces 1.1.1. Payment
preparation može da bude izvršen i ručno, što je obično slučaj kod fizičkih lica i manjih
pravnih subjekata, dok se kod ostalih pravnih lica taj deo ne izvršava ručno. Ti procesi
mogu biti podržani mnogim na tržištu prisutnim ekvivalentnim proizvodima. Oni su
ekvivalentni jer im u odnosu na isti skup zadatih transakcija mora biti, kao izlaz, isti
skup platnih poruka.
Proces 1.1.2. Payment realization sastoji se od standardnih proceduralnih procesa, kao
što su verifikacija informacija za plaćanje, priprema platne poruke, interakcija sa
platnim sistemom poređenje poruke sa odgovorom na nju, verifikacija plaćanja koji su u
odnosu na sistem poruka isto tako ekvivalentni jer im ulazi i izlazi moraju biti isti. Ulazi
u proces moraju da budu isti jer konačan rezultat jeste standardna poruka koja sadrži
tačno determinisane informacije u sebi, a izlaz je sama ta poruka koja bez obzira na
vrstu komponenata koje je proizvode mora biti ista. Interesantna je i fenomenologija
[167], [168] procesa 1.1.1, za koji može da se pokaže da ima analogone sa RTGS
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 232
sistemom, kao i kasnije u procesima 1.2.2. i 2.2.3. i 3.1.3, što može biti predmet nekog
narednog istraživanja.
Legenda [28]:
Retail Systemc sistem „na malo“
Payment Preparation: priprema plaćanja
Provision of payment under agreement: obezbeđivanje plaćanja po ugovoru
Provision of goods: obezbeđivanje dobara
Provision of services: obezbeđivanje servisa
Requirement to move money: potreba za angažovanjem sredstava
Accounting Reporting: izveštavanje knjigovodstva
Payment Realization: realizacija plaćanje
Verification of payment information: provera podataka za plaćanje
Preparing payment message: priprema poruke za plaćanje
Ineraction with payment services: interakcija sa platnim servisom
Customer Credit Transfer Initiation: klijentska inicijacija transfera sredstava
Payment Cancelation Request: zahtev za otkazivanjem plaćanja
Customer Payment Reversal: povraćaj plaćanja klijentu
Payment Status Report: izveštaj o statusu plaćanja
Comparsion Payment message with response: poređenje poruke za plaćanje sa odgovorom
Verification of Payment: verifikacija plaćanja
Payment Realization Reporting: izveštavanje o realizaciji plaćanja
Slika 118. Retail sistem
Proces 1.2. Bank’s Retail Credit Transfers System započinje proverom inicijalnih
parametara sistema koje je zadala nadređena institucije i koji mogu da se sastoje od
promenljivih parametara sistema u odnosu na trenutnu situaciju u čitavom sistemu. Na
ovaj način se postiže poželjna povratna sprega u sistemu, odnosno upravljačka funkcija
nadređene institucije, koja je objašnjena u poglavlju 1.1.1.
Ukoliko ne bi postojao ovaj automatizovani proces, podređena institucija bi bila u prilici
da ne izvršava svoje zakonskim ili podzakonskim aktima regulisane obaveze i mogla bi
da ugrozi svoje postojanje. Poređenjem slike 117. i slike 118. možemo uočiti određeni
broj procesa koji se ponavljaju i koji su po svojoj funkcionalnosti istovetni. U pitanju su
osnovni procesi Interaction with payment services (1.1.2.3. i 1.2.2.) sa svojim
podprocesima.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 233
Legenda:
Bank’s Retail Credit Transfer System: sistem banke „na malo“ za transfer sredstava
Confirmation of Initial System Parameters: potvrđivanje inicijalnih sistemskih parametara
Interaction with Payment Services: interakcija sa platnim servisom
Payment Document Cheking: provera platnih dokumenata
Customer Credit Transfer Initiation: inicijacija klijentovog transfera sredstava
Payment Cancelation Request: zahtev za otkazivanje plaćanja
Customer Payment Reversal: povraćaj plaćanja klijentu
Response Managing: upravljanje odgovorom
Payment Status Report: izveštaj o statusu plaćanja
Bank’s Retail Credit Transfer ToCore Connection: veza transfera sredstava banke „na malo“ i kor sistema
Bank’s Retail Credit Transfer Monitoring: monitoring transfera sredstava banke „na malo“
Bank’s Retail Credit Transfer Reporting: izveštavanje o transferu sredstava banke „na malo“
Slika 119. Retail Credit Transfers sistem banke
Legenda:
Bank’s processor Credit Transfer System: sistem banke za transfer sredstava procesoru
Confirmation of Initial System Parameters: potvrda inicijalnih sistemskih parametara
Payment Document Checking: provera platnih dokumenata
Customer Credit Transfer: klijentov transfer sredstava
Payment Cancelation: otkazivanje plaćanja
Customer Payment Reversal: povraćaj plaćanja klijentu
Response Managing: upravljanje odgovorom
Payment Status Report: izveštaj o statusu plaćanja
Interaction with Clearing Services: interakcija sa servisima kliringa
Bank’s Processor Credit Transfer ToCore Connecting: veza transfera sredstava kor sistema banke i procesora
Bank’s Processor Credit Transfer Monitoring: monitoring transfera sredstava banke procesoru
Bank’s Processor Credit Transfer Reporting: izveštavanje o transferu sredstava banke procesoru
Slika 120. Credit Transfers sistem procesora banke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 234
Legenda:
Processor’s Neto System: procesorov neto sistem
Confirmation of Initial System Parameters: potvrda inicijalnih sistemskih parametara
Processor Neto Pre-processing: procesorovo neto pretprocesiranje
Interaction with Core Processing Services: interakcija sa kor servisima procesiranja
Payment Document Checking: provera platnih dokumenata
Customer Credit Transfer: klijentov transfer sredstava
Payment Cancelation: otkazivanje plaćanja
Customer Payment Reversal: povraćaj plaćanja klijentu
Response Managing: upravljanje odgovorom
Payment Status Report: izveštaj o statusu plaćanja
Processor Credit Transfer Monitoring: procesorov monitoring transfera sredstava
Processor Credit Transfer Reporting: procesorovo izveštavanje o transferu sredstava
Slika 121. Procesorov neto sistem
Legenda:
Processor’s Bruto System: procesorov bruto sistem
Confirmation of Initial System Parameters: potvrda inicijalnih sistemskih parametara
Interaction with Processor Neto Services: interakcija sa procesorovim neto servisima
Interaction with Bruto Services: interakcija sa bruto servisima
Payment Document Checking: provera platnih dokumenata
Payment Transfer: transfer plaćanja
Payment Cancelation: otkazivanje plaćanja
Customer payment Reversal: povraćaj plaćanja klijentu
Response Managing: upravljanje odgovorom
Payment Status Report: izveštaj o statusu plaćanja
Processor Bruto System Monitoring: monitoring procesorovog bruto sistema
Processor Bruto System Reporting: izveštavanje o procesorovom bruto sistemu
Slika 122. Procesorov bruto sistem
Poređenjem slika 119, 120, 121 i 122. možemo takođe uočiti procese na nivou banke,
procesora i bruto sistema, koji se ponavljaju i koji su po svojoj funkcionalnosti potpuno
isti. Proces Confirmation of Initial System parameters je na svim nivoima isti.
Interakcija sa nadređenim sistemom takođe, ali procesi na različitim nivoima imaju
različite nazive jer se naredni sistem sa kojim je u interakciji drugačije naziva. U pitanju
su sledeći procesi: 2.1.2. Interaction with Clearing Services, 2.2.3. Interaction with
Core Procesing Services i 3.1.3 Interaction with Bruto Services. Isti slučaj je i sa
procesima monitoringa na različitim nivoima: 2.1.4., 2.2.4. i 3.1.4. Takva situacija je i
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 235
sa procesima za reporting: 2.1.5, 2.2.5, i 3.1.5. Procesi interakcije (2.1.2, 2.2.3. i 3.1.3.)
na svim nivoima imaju istu strukturu.
Generalizacija prva dva nivoa: Na osnovu razmatranja u prethodnom poglavlju i
uzevši u obzir da za svaku transakciju, bez obzira na vrstu, postoji inicijacija, kliring i
na kraju poravnanje, može se izvršiti generalizacija, po vrsti transakcija koje se
procesiraju, odnosno po instrumentu plaćanja koji se koristi, kao što je to prikazano na
slici 123. Dakle, bez obzira koji se instrument plaćanja koristio (Credit Transfers,
direktno zaduženje, kartice) sled procesa i njihov odnos bio bi isti.
Legenda:
Payment System: platni sistem
Initiation: inicijacija
Retail System: sistema „na malo“
Bank’s Retail System: sistem banke „na malo“
Reporting: izveštavanje
Clearing & Settlement: kliring i poravnanje
Bank’s Processor System: sistem banke ka procesoru
Processor’s System: procesorov sistem
Reporting: izveštavanje
RTGS Settlement: RTGS poravnanje
Processor’s Bruto System: procesorov bruto sistem
RTGS Reporting: RTGS izveštavanje
Slika 123. Generalizacija prva dva nivoa
Mogućnost generalizacije po dubini procesa, odnosno po definisanim nivoima
elektronskog poslovanja platnih sistema, može se pokazati na primeru kredit trasfer
procesa jedinstvene evropske platne zone (SEPA Credit Transfers). SEPA Credit
Transfers Scheme RuleBook determiniše kontekst i prostor u kome se odvijaju servisi
koji obezbeđuju Credit Transfers procese. Prostor se u prvom redu specijalizuje na tri
osnovna: prostor u kome se odvijaju procesi Credit Transfers inicijacijacije, prostor
neto poravnanja/izvršavanja plaćanja i prostor konačnog bruto poravnanja. Proces
započinje kompletiranjem i prosleđivanjem Credit Transfers instrukcija od strane
nalogodavca, nastavlja prihvatanjem instrukcija za neto poravnanje i plaćanje, a
završava sa bruto poravnanjem učesnika - banaka i prosleđivanjem odgovarajućih
poruka o realizaciji od sistema za bruto poravnanje pa do učesnika - nalogodavca i
korisnika. Institucije mogu da budu: deo sistema u banci prema Retail korisnicima - kao
banka, deo sistema u banci prema procesoru - kao deo sistema od banke prema
procesoru, procesorov deo sistema prema banci - kao procesorov neto sistem i
procesorov deo sistema prema sistemu za bruto poravnanje. Strukturnom sistem
analizom može se doći do prostih procesa, a zatim se može izvršiti njihova
generalizacija. Iz navedenog razmatranja sledi da je savladavanje složenosti platnih
sistema moguće rešiti upotrebom osobina rekurzije opisane matematički modelom,
objašnjenim u ovom radu, i po dubini – nivoima sistema. Na taj način se savladava i
složenost upravljanja platnim sistemom.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 236
6.4.2 Saradnja između učesnika
Mandat predstavlja ugovornu relaciju između poverioca (Creditor) i dužnika (Debtor),
kojom dužnik svojim potpisom daje: 1. Poveriocu svoj pristanak i ovlašćuje ga da
inicira transakcije direktnog zaduženja (direct debit transakcije) koje će rezultirati
zaduženjem dužnikovog računa, a sve u skladu sa pravilima definisanim SEPA Direct
Debit Scheme Rulebook-om i detaljima potpisanog Mandata; 2. Banci dužnika svoj
pristanak da deluje po takvim instrukcijama, a sve u skladu sa pravilima definisanim
SEPA DirectDebit Scheme Rulebook-om.
Analizom mandata za SEPA Direct Debit, odnosno ugovora, može se doći do rezultata
koji imaju eksplicitan uticaj i na sve ostale mandate koji se sklapaju u platnom sistemu i
za ostale procese.
Osnovna forma postojanja mandata koju predviđa Europen Payment Concil - EPC jeste
papirni dokument, koji je fizički potpisan od strane dužnika. SEPA Direct Debit Scheme
Rulebook-om EPC predvideo je i postojanje mandata u elektronskoj formi, pri čemu
dokument koji predstavlja mandat mora biti kreiran i potpisan na siguran način. Bez
obzira u kojoj je formi, mandat mora da sadrži obavezan pravni tekst, kao i imena strana
koje su potpisnice mandata.
Sam proces uspostavljanja mandata može otpočeti nakon registracije poverioca i pre
upućivanja prve transakcije za direktno zaduženje (Direct Debit Collection). Inicijativa
za uspostavljanje mandata može biti pokrenuta od obe zainteresovane strane, poverioca
ili dužnika. Poverilac može da ponudi dužniku mogućnost popunjavanja mandata
elektronskim putem, uključujući pritom i obezbeđivanje elektronskog potpisivanja
mandata zbog osobine neporecivosti elektronskog dokumenta. Pravila koja se odnose na
uspostavljanje mandata elektronskim putem specificirana su u SEPA Direct Debit
Rulebooku.
EPC je početkom 2007. godine utvrdio da regulativa postupaka sa mandatima [146] nije
na odgovarajući način uspostavljana [71], [67]. Zbog toga je početak korišćenja
instrumenta plaćanja Direct Debit odložen. Već sa slike 124. gde je predstavljeno
uspostavljanje mandata, vidljivo je da ne postoji regulativa koja bi ponovno uspostavila
odnose između učesnika ukoliko bi elektronski mandati bili kompromitovani. Zaključak
je izveden iz opšteg postupanja sa dokumentima u papirnom obliku, gde postoji
nezavisna treća institucija koja služi za skladištenje originala koji bi u slučaju spora bio
dokaz (u Srbiji su to sudovi gde se skladište originali potpisanih ugovora) i postupanja u
slučaju elektronskih dokumenata koji imaju relativno mali životni vek zbog mogućnosti
razbijanja potpisa i nemogućnosti poređenja jer ne postoji institucija koja bi skladištila
elektronski potpisane originale koji bi se koristili u slučaju spora. Dedukcijom se može
pokazati da i druge ugovore između učesnika prati ista problematika, i u papirnom i
elektronskom obliku, i da bi se, ukoliko se reši problem za jedan slučaj, on mogao
koristiti i za ostale. Na taj način bi se mogle regulisati i sve vrste ugovora između banke
i klijenta, banke i procesorske kuće i slično. To bi bila mogućnost za redefinisanje
poslovnih procesa koji su sada uobičajeni, uvođenje novih servisa i bankarskih
proizvoda. Komponenta ili podsistem za poslovni proces upravljanja mandatima bila bi
standardna.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 237
Legenda:
Creditor: dužnik
Creditor Bank: dužnikova banka
Clearing and Settlement: kliring i poravnanje
Deptor Bank: poveriočeva banka
Deptor: poverilac
Archiving and Dematerialisation: arhiviranje i dematerijalizacija
Send Mandate with each Instruction: slanje mandata sa svakom instrukcijom
AOS: dodatni opcioni servisi (Additional Option Services)
Issuing of Paper Mandate: izdavanje papirnog ugovora
Electronic Mandate: elektronski ugovor
Slika 124. EPC: Uspostavljanje mandata
6.4.3 Specifikacija sistema za razmenu poruka
Realizacija platnog sistema nije karakteristična samo za platne sisteme jer i ostali
Message Oriented Systems (MOS) imaju iste fenomenološke elemente [52]:
• postoji potreba za velikim obimom razmene poruka;
• postoji struktura podređenih i nadređenih sistema sa supersistemom,
• postoje veze sa drugim MOS;
• akvizicija poruka se vrši sa veoma širokog geografskog područja;
• distribucija poruka se vrši na veoma široko geografsko područje;
• akvizicija i distribucija se vrše kroz zadate institucionalizovane nivoe
odgovornosti;
• poruke za razmenu informacija o poslu standardizovane su od strane institucija
za globalnu standardizaciju;
• poruke za razmenu informacija sadrže informacije za adresiranje i procesiranje;
• standardi poruka su bazirani na XML-u;
• osnovni sklop standardnih elemenata je kao i za platne sisteme, slika 3;
• grupisanje konglomerata gradivnih jedinica vrši se kao i za platne sisteme, slika
4;
• sisteme međusobno samo razlikuju zadati formati, informacije za procesiranje i
komponente za konkretno izvršavanje procesiranja.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 238
Na osnovu prethodnog i činjenice da je rasprostranjenost MOS u savremenom društvu
veoma velika, od sistema za platni promet, pa do sistema za SMS mobilnu naplatu
parkiranja u velikim gradovima, priloženi radni model sistema pokazuje da je moguće
izgraditi savremen i moderan sistem koji bi zadovoljio sve potrebne zahteve [233].
Bus je podsistem koji se koristi za transfer podataka između aplikativnih komponenata
u jednom računarskom sistemu ili između aplikativnih komponenata različitih
računarskih sistema. Razmena poruka korišćenjem Message Bus-a vrši se na pouzdan
način uz pomoć različitih i prilagodljivih formata poruka. Prenos može biti i asinhron i
to je rešenje u situaciji kada distribuirani sistemi nisu u mogućnosti uvek da budu
dostupni. Enterprise Service Bus (ESB) predstavlja okruženje sačinjeno da unapredi
sofisticiranu povezanost između servisa. Ono ustanovljava međusloj za
pretprocesiranje, koje pomaže da se prevaziđe određen skup problema povezanih sa
pouzdanošću, skalabilnošću i nejednakošću po pitanju komunikacionih mogućnosti.
ESB je sačinjen od niza uzoraka kao što su: asinhroni red čekanja, posrednik servisa
(transformacija modela podataka, transformacija formata podataka, premošćavanje
protokola), rutiranje, pouzdan prenos poruka, centralizacija polisa, centralizacija pravila
i prenos poruka iniciranih događajima. Razmena potrebnih informacija između
navedenih učesnika, odnosno integracija platnih sistema putem poruka korišćenjem
odgovarajućih protokola bezbedna je , pouzdana, i u potpunosti zadovoljava potrebe
takvih sistema. Dugi niz godina na taj način se vrši razmena poruka na taj način u
finansijskoj industriji. Uočeni su sistemi baziranih na standardnim adresibilnim
porukama u globalnom platnom sistemu na različitim organizacionim nivoima koji se
mogu integrisati upotrebom jednog ili više sistema za razmenu poruka.
Glavni razlog postojanja transportnih sistema poruka jeste smanjenje kompleksnosti
veza između aplikativnih sistema.
Svaki finansijski sistem se sastoji od sledećih učesnika:
• supersistema – nadređenog centra;
• procesorskog sistema nad kojima supersistem ima nadležnost;
• strukture mreža subordinate sistema - učesnika u „saobraćaju“.
Svaki od učesnika poseduje jednoznačne instance elektronskih dokumenata koji su
učestvovali ili koji će učestvovati u poslovnim procesima. Jedan od poslovnih procesa
je i prenos elektronskih poruka, odnosno elektronskih dokumenata, od jednog učesnika
do drugog uz pomoć aplikativnog srednjeg sloja. Nad elektronskim dokumentima
vlasništvo imaju supersistem [131] (podaci upravnog centra i podaci o procesiranju u
procesorskom sistemu), procesorski sistem (podaci procesorskog sistema i podaci o
procesiranju poruka subordinate sistema) i podaci subordinate sistema. Nabrojane
grupe podataka čine jedinstvenu celinu. Moraju da se čuvaju zadati vremenski period. U
slučaju nedostatka, na bilo kom nivou, nekog elektronskog dokumenta (ili skupa
elektronskih dokumenata) dolazi do ozbiljnog narušavanja elemenata finansijskog
sistema koji se balansiraju pravnom i kaznenom regulativom. Neposedovanje
elektronskih dokumenata, njihovo uništavanje ili nehatno rukovanje u većini slučajeva
predstavlja ozbiljan krivični akt. Postoji mnogo različitih načina da se poruka prenese sa
jedne lokacije na drugu. Jedan od načina je i korišćenje SWIFT servisne mreže koja je
namenjena za takvu vrstu poslova. Dugi niz godina SWIFT je imao monopol u ovoj
oblasti, ali razvojem informacionih tehnologija postalo je moguće izgraditi isti takav
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 239
sistem od strane nezavisnih institucija i kompanija i na taj naćin omogućiti nezavisnost
platnih sistema od SWIFT organizacije. Platni sistemi ranijih generacija imali su svoje
načine za transport, koji su bili slabih performansi i jedva zadovoljavali potrebe za
razmenom poruka. Primer za to je RTGS sistem u NBR Makedoniji, koji je početkom
2000. godine radio sa ograničenjem - 3000 poruka na dan. U naredna dva poglavlja
prikazana su dva savremena sistema za razmenu platnih poruka.
Saga SEP transportni sistem
Saga SEP transportni sistem [166] je baziran na Windows Communication Framework-
u. WCF je Microsoft-ovo okruženje (framework) za razvoj zaštićenih, pouzdanih,
transakcionih i interoperabilnih distribuiranih aplikacija. WCF inkorporira programski
model koji koristi „kontrolisani” kod za razvoj unificiranih WEB servisa i drugih
distribuiranih sistema koji mogu međusobno komunicirati. WCF se fokusira na
povezivanje XML sa programima razvijenim pod Microsoft podržanim razvojnim
jezicima VB.NET i C#. Da bi podržao tu međujezičku komunikaciju, WCF koristi
Extensible Simple Object Access Protocol (SOAP).
Servisno orijentisana arhitektura [69] Saga SEP transportnog sistema je u suštini skup
servisa koji komuniciraju jedni sa drugima i mogu uključiti prostu primopredaju
podataka, ali i uključiti dva ili više povezanih servisa da bi se izvršila neka aktivnost.
Slika 125. prikazuje osnovu servisno orjentisane arhitekture. Korisnik servisa šalje
zahtev isporučiocu servisa. Na taj zahtev isporučilac servisa vraća adekvatan odgovor
korisniku servisa. Zahtev i odgovarajući odgovor se ostvaruju preko konekcije koja je
na neki način determinisana i koju obe strane mogu da razumeju. Interesantno je da
isporučilac servisa može da bude i korisnik servisa.
Isporučilac
servisa
Korisnik
servisa
Odgovor na zahtev
Zahtev za servis
Konekcija
Slika 125. Osnova servisno orijentisane arhitekture
Saga SEP transportni sistem je projektovan da obezbedi sigurnu, dostupnu i efikasnu
razmenu poruka, baziranih na SWIFT-u i drugim industrijskim standardima između
učesnika u sistemu. Sistem može da bude zamena sa vlasničkom (jeftinijom) mrežom za
saobraćaj koji se odvija putem SWIFT mreže. Sistem je implementiran u Udruženju
banaka Srbije - Klirinškoj instituciji banaka [214], [13] (UBS KIB) i OTP banka Srbije.
Sistem je modularan, dostupan, stabilan, skalabilan, sa odgovarajućim bezbednosnim
mehanizmima i sa visokim performansama. Baziran je na Microsoft tehnologijama i one
minimizuju operativni rizik od korišćenih tehnologija pošto su svi ostali sistemi u klasi
realizovani drugim tehnologijama koje nisu bazirane na Microsoft proizvodima. Pred
sistem su postavljeni i zahtevi koji se odnose na njegovu širu upotrebnu vrednost, u
smislu:
- mogućnosti transparentnog korišćenja nezavisno od geopolitičke ili bilo koje
druge konfiguracije učesnika;
- neograničavanja samo na domene finansijske industrije;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 240
- mogućnosti da budu uključeni i srodni procesi podržani prihvaćenim standardom
za specifikaciju poruka;
- da se mogu podržati i svi ostali sistemi bazirani na komunikaciji i razmeni
standardnih poruka koje u sebi sadrže informacije o adresi primaoca i
poslovnom procesu koji treba da se obavi na lokaciji prijema.
Tabela 20. prikazuje uobičajene projektne zahteve koji se postavljaju pred jedan ovakav
sistem i opis na koji način su oni ispunjeni u rešenju implementiranom u UBS KIB-u.
R.br. Projektni zahtev Opis ispunjenih zahteva
1. Dostupnost 24 časa x 7 dana u nedelji
2. Bezbednost Sigurnost bazirana na upotrebi sertifikata javnih ključeva (Microsoft Enterprise CA sa infrastrukturom javnih ključeva - PKI)
3. Performanse Testiran na 500k transakcija na sat (frame relay 512k)
4. Stabilnost Verzija 1.0 prve godine rada imala “zero down time”
5. Modularanost
Mogu se dodavati moduli opšte i specijalne namene u slučaju proširenja seta
funkcionalnih zahteva, na primer za dostavu poruka sistemu za procesiranje
poruka direct debita, prinudne naplate, kliringa naloga ili nekog drugog
sistema za procesiranje.
6. Skalabilnost U slučaju potrebe, radi proširenja kapaciteta, može se dodati odgovarajući broj hardverskih komponenata
Tabela 20. Osnovni projektni zahtevi i njihova ispunjenost
Saga SEP transportni sistem omogućava:
a.) širok opseg slobode definisanja pristupnih kanala;
b.) različite vrste procesiranja;
c.) dodavanje proizvoljnih programskih biblioteka posebne i opšte namene;
d.) mogućnost definisanja arhitekture koja je po teorijskim standardima na
visokom mestu;
e.) uvođenje vrlo širokog spektra konfiguracionih parametara za determinisanje
sistema u cilju postizanja vrlo jake povratne sprege sa mogućom promenljivom
okolinom sistema;
f.) slobodom definisanja komunikacije sa zahtevanim eksternim sistemima
putem primopredaje servisa;
g.) definisanja proizvoljnog workflow mehanizma;
h.) mogućnost reakcije na podražaje bilo unutar sistema ili van njega planiranim
događajima iz nekog izvora.
Funkcionalnosti koje sistem ispunjava su sledeće:
1. transport SWIFT poruka i ostalih definisanih standardnih dokumenata;
2. razmena poruka putem sistema foldera, MSMQ ili putem odgovarajućih
aplikativnih adaptera;
3. predvalidacija poruka (prva tri bloka SWIFT poruke);
4. digitalno potpisivanje svake poruke i provera potpisa na ishodištu;
5. pet modova transporta (sinhrono - asinhrona kombinacija sa predajnikom i
prijemnikom i odgovarajućom potvrdom prijema – ACK / NAK), kao i fire
& forget mehanizam (streaming mode);
6. rutiranje poruka kroz predefinisane rute;
7. arhiviranje poruka;
8. postojanje aplikativnih komponenti za monitoring predaje/prijema.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 241
Navedene funkcionalnosti sistema izdvojene su kao najkarakterističnije i
najinteresantnije u odnosu na tehnologije finansijske industrije.
Sistem je nezavisan od komunikacione infrastrukture. Postoje primeri iz prakse
(prouzrokovani elementarnom nepogodom) gde je komunikacija obavljana sa mobilnih
uređaja bez ikakvog dodatnog obaveštavanja ostalih učesnika o izmeni fizičkog načina
obavljanja komunikacije. Jedini zahtev za komunikaciju je da su učesnici URL
adresibilni. Moguća je integracija u sve poznate sisteme za razmenu poruka.
Bezbednost je bazirana na PKI infrastrukturi. To daje garanciju da će svaka poruka stići
neizmenjena i sa dokazom o poreklu. Postoji opcija koja kriptuje kanale za
komunikaciju. PKI infrastruktura je podržana od strane Microsoft CA servera.
Projektovani koncepti su verifikovani u Microsoft Technology Center (EMEA) u
Kopenhagenu u Danskoj marta 2005. Testiranje u Microsoft Tehnology centru je
ugovoreno i ima za cilj da dokaže da je Transportni sistem v3.0 sposoban da zadovolji
potrebe za prenosom dokumenata za procesiranje i najvećih zemalja kao što su EU,
Rusija, Brazil, Kina, Indija ili Sjedinjene Američke Države.
Sistem je baziran na WCF arhitekturi i prikazan na slici 126. Osnovna odlika ove
arhitekture jeste kompozibilnost (nadgradivost). Ova arhitektura omogućava
inkrementalan razvoj veb-servisa kroz pojedinačne zahteve (sigurnost, pouzdanost,
pridruživanje paketa - attachments, filtriranje). Svaki od ovih zahteva rešava se
izolovano od drugih, što znatno pojednostavljuje razvoj. Konkretna implementacija
realizuje BUS arhitekturu. Servis bus reprezentuje logičku konekciju međusobno
povezanih sistema. Istovremeno omogućava razdvajanje nivoa poslovne logike od
komunikacionog nivoa. Osnovne odlike sistema su:
1. potpuna konfigurabilnost sistema (Configuration procesor);
2. servisi bazirani na WCF tehnologiji;
3. servis loader and manager;
4. inicijalan set procesora poruka (message sender, receiver);
5. ugrađen sistem za automatsko arhiviranje poruka;
6. store manager;
7. konfigurabilni servis preprocesori, postprocesori i filteri;
8. konfigurabilni servis adapteri;
9. jednostavno proširenje funkcionalnosti (dodavanje novih servisa);
10. ugrađeni security mehanizmi.
Slika 126. Arhitektura eMessaging Transport System Service BUS-a [166]
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 242
U okviru servisa za prijem i slanje poruka realizovani su sledeći načini prijema poruka:
sinhroni prijem, asinhroni prijem, Fire & Forget (prijem bez odgovora). Fizički kanali /
protokoli za prenos podataka definišu se preko konfiguracije, tj. procesori poruka su
apsolutno nezavisni od protokola komunikacije. Sistem je testiran na sledeće protokole
prenosa podataka: HTTP, HTTPS (SSL), TCP/IP, MSMQ, Message PIPE.
Realizovani sistem konzistentno primenjuje WCF security mehanizme koji obuhvataju:
message layer security za autentifikaciju poruka, transport layer security za
poverljivost, upotreba X509v3 sertifikata kao security tokena, direct / brokered
autentikaciju. Na aplikativnom nivou primenjuje se dodatna zaštita kao na primer:
kriptološka zaštita sadržaja, međusobna autentikacija krajnjih učesnika.
OpenAMQ
Osnovni podaci OpenAMQ sistema iMatix korporacije:
• Proizvođač
iMatix korporacija
• Zasnovanost na besplatnom softveru
GNU besplatni alati i programski jezici, model-oriented
programming (MOP) alati iMatix korporacije i jezici iMatix
korporacije
• Tekuća verzija softvera
1.2c4. (15.10.2007.)
• Broj verzija OpenAMQ realizovanih i testiranih pre verzije 1.0d0:
55
• Prva linija koda napisana:
02.10.2004.
• Veličina upoterbljene iMatix tehnologije:
524,133 linija C/C++ koda
• Veličina OpenAMQ osnovnog proizvoda:
309,656 linija C/C++ koda, 10,537 linija MOP koda
• Procenat OpenAMQ koji je generisan iz modela:
99.79%
• Najveća brzina zabeležena na jednoprocesorskoj mašini:
40,000 poruka/sekundi (poruke od 500 bajta)
• Najveća brzina zabeležena na višeprocesorskoj mašini:
140,000 poruka/sekundi (poruke od 500 bajta)
• Teorijski limit na gigabitskoj mreži:
512,000 poruka/sekundi (poruke od 500 bajta)
• Prvi dan produkcije sa transportom podataka kroz OpenAMQ:
09.05.2006 (JPMorganChase)
• Maksimalni broj poruka u toku dana po jednoj aplikaciji:
100,000,000 (JPMorganChase)
Samo 0.21% OpenAMQ od 310k linija C koda je pisano rukom. Ostatak je generisan iz
modela, korišćenjem iMatix Model Oriented Programming (MOP). MOP prevodi XML
modele visokog nivoa u izvršni kod. Modeli koji su korišćeni su sledeći: state
machines, class systems, grammars i metamodele. Umetanjem jednog modela u drugi,
dobijaju se modeli koji su sposobni za pravljenje novih modela koji proizvode
odgovarajući izvršni kod koji ima veoma mali procenat grešaka sa izuzetno malim
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 243
konvencionalnim troškovima izrade. OpenAMQ je oslonjen na nekoliko tehnoloških
nivoa od kojih je najviši ASL Abstract Server Language. ASL je alat koji je izgrađen
specijalno da prihvati AMQP gramatiku (Advanced Message Queue Protocol) i
automatski je preobraćuje u okruženja za izradu klijenata i servera. Uzimajući
odgovarajući AMQP protokol ispisan kao ASL model, u nekoliko sekundi dobija se
potpuna izvršna verzija klijenta, fremwork za server, veliki deo potrebne
dokumentacije.
Glavne osobine OpenAMQ sistema su:
• ekonomičnost (jeftina ili besplatna licenca moguće ga je izvršavati na
proizvoljnom operativnom sistemu, prosta instalacija i konfiguracija, jeftina
administracija, prost interfejs);
• dostupnost svim korisnicima (iziskuje male troškove, kompatibilan sa
aplikativnim sistemima na bilo kom jeziku i bilo kojoj tehnologiji, ne zauzima
puno resursa i pogodan je za uređaje ograničenog kapaciteta);
• koristnost (koristi se za rešavanje svakodnevnih problema u korporacijskim
sistemima korišćenjem store and forward, publish – subscribe, multicasting i
ostalih messaging mehanizama);
• kvalitet servisa (prihvata veliku količinu poruka ograničenu samo lokalnim fajl
sistemima, može da garantuje maksimalno vreme isporuke za specifične servise,
može da garantuje minimalni propusni opseg za specifične servise, može da
rukuje sa greškama na praktičan način);
• sofisticiranost (može da se prihvati i složenih zadataka kao što je rutiranje
poruke po adresi primaoca, sadržaju, izračunatoj vrednosti, individualnoj
aplikaciji, grupi aplikacija, privremenim ili stalnim nadimcima, jedinicama u
okviru grupe i slično, radi nad više virtuelnih mreža nad jednom fizičkom
mrežom, recimo razvojno, produkciono i testno okruženje, dozvoljava enkripciju
i potpisivanje sadržaja kada je to potrebno);
• može da pobudi proces koji je zadužen za prihvatanje određenih podataka;
• može da se integriše sa workflow sistemima.
OpenAMQ podržava različite messeging arhitekture:
• Store-and-forward sa više čitača i pisača;
• distribuciju transakcija sa više čitača i pisača;
• publish-subscribe sa više čitača i pisača;
• rutiranje bazirano na sadržaju sa više čitača i pisača;
• transfer fajlova uz pomoć reda za čekanje sa više čitača i pisača;
• point-to-point veze između dva izvora;
• distribuciju marketinških podataka sa više izvora i mnogo čitača.
Kod OpenAMQ sistema pretpostavka je da klijenti mogu da adresiraju server direktno.
Serveri ne mogu da adresiraju klijente.
Iz analize osnovnih funkcionalnih oblasti slede sledeći podržani varijeteti:
• veličina poruke može da varira od veoma malih do veoma velikih;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 244
• poruka može da sadrži aplikativne podatke, fajlove, i druge sadržaje kao što su
kontinualni podaci – strimovi;
• zahtev za dostupnost, od veoma niske do veoma visoke dostupnosti;
• zahtev za vremenom potrebnim za pobuđivanje u opsegu od nevažno do
kritično;
• model za rutiranje može da podrži više različitih načina kao što su primalac sa
jednim imenom, rutiranje bazirano na sadržaju i drugi;
• modeli distribucije podataka na više različitih načina.
Poređenje sistema za transport poruka
Saga SEP transportni sistem i OpenAMQ sistem svakako su dva veoma različita
proizvoda bazirana na drastično različitim tehnologijama. Međutim, njihove funkcije su
potpuno iste, i u izgradnji platnog sistema bismo mogli bi se ravnopravno koristiti i
jedan i drugi jer su Saga SEP transportni sistem i OpenAMQ anološki isti. Možemo
primetiti da je i način na koji se sistemi realizuju veoma različit: dok se OpenAMQ, u
viskom procentu, dobija generisanjem iz modela, dotle Saga SEP koristi Windows
Communication Framework sa odgovarajućim funkcijama i na takav, vrlo lak način
dostiže visoku složenost i upotrebnu vrednost sistema.
6.4.4 Primena ontologija u analizi
Ontološki domenski model pokazuje da je struktura stabilna, da, ukoliko se uvodi nova
verzija objekta, u modelu perzistiraju i sve prethodne verzije, a samo poslovna pravila
determinišu koji objekti su važeći u sistemu. Generički model koristi činjenicu da su
objekti ne samo „stabilni“ u jednom konkretnom sistemu (stabilni u smislu da se bitnije
ne menjaju čak i kada se funkcije sistema i zahtevi za informacijama u sistemu
menjaju), već i u čitavoj klasi srodnih sistema [189]. Domenska ontologija [43]
pokazuje da je čitav skup objekata visokog nivoa apstrakcije (generičkih objekata
derivacijom iz REA Resursa) isti u različitim poslovnim sistemima, pa oni treba da
posluže kao osnova za razvoj modela podataka i ponašanja (procesa – derivacijom iz
REA Event-a).
Sa druge strane (Slika 127.), u skupu objekata poslovnog sistema postoji skup
nezavisnih objekata (objekata koji pripadaju nivou poslovnog subjekta u sistemu
elektronskog poslovanja platnih sistema ili REA Agenata), čije postojanje nije
uslovljeno postojanjem nekog drugog objekata u sistemu. Tipovi takvih objekata se
mogu tretirati kao nezavisno promenljive koordinatne ose, a njihova pojavljivanja kao
tačke na tim osama, jednog apstraktnog n-dimenzionog prostora koga nazivamo
apstraktni prostor poslovanja [211]. Pri tome smatra se da je pojavljivanje nekog
objekta predstavljeno njegovim ključem (ili, još bolje surogatom ključa, identifikatorom
koga dodeljuje sistem kad god se neko novo pojavljivanje kreira), a atributi ovih
objekata su funkcije definisane u odgovarajućim tačkama posmatrane koordinatne ose.
Očigledno je da pojavljivanja agregacija, koje se predstavljaju Dekartovim proizvodom
tipova (skupova) objekata, određuju tačke u prostoru poslovanja (van koordinatnih osa)
u kojima su definisane neke druge funkcije - atributi agregacija.
Domenska ontologija pokazuje da bazni atributi, atributi koji se ne mogu izvesti iz
drugih atributa u sistemu, predstavljaju samo jedan skup informacija preko kojih se prati
ponašanje poslovnog sistema. Iz njih se različitim obradama podataka mogu izvesti i
mnoge druge. Osim izvođenja koja se mogu vršiti nad skupovima ili podskupovima
pojavljivanja osnovnih objekata i agregacija, veze između objekata u modelu definišu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 245
ostale tačke u poslovnom prostoru u kojima se ovakva izvođenja mogu vršiti, a sami
algoritmi obrade funkcije izvođenja.
N
E
Z
A
V
I
S
N
E
O
S
E
PROSTOR POSLOVANJA
E1
E2
En
V1
V2
AG1
AG2
ALG
IZV
BAZNI IZVEDENI
S
ATRIBUTI
Legenda
E1, E2, ..., En – objekti sistema
AG1, AG2 - agregacije objekata
V1, V1 – veze objekata
ALG.IZV – algoritam izvođenja poslovne funkcije
BAZNI – osnovni objekti
IZVEDENI – izvedeni objekti
S – specijalizacija
Slika 127. Generički model EPPS
Imajući u vidu apstraktni model i neke generičke objekte poslovnih sistema, razvoj
modela elektronskog poslovanja platnih sistema zasnovanog na ontologijama odvija se
kroz:
• izbor generičkih objekata;
• rasčlanu generičkih objekata;
• specijalizacija, generisanje hijerarhije podtipova;
o definisanje strukture objekata;
o definisanje baznih atributa objekata;
o definisanje osnovnih agregacija i njihova rasčlana;
• definisanje veza između osnovnih objekata i agregacija;
• analiza funkcija sistema (poslovnih procesa) sa ciljem da se otkriju dodatni
objekti, agregacije, atributi i veze izvođenja, odnosno da se izvrši dalja rasčlana
sistema.
Ovakav pristup je omogućio da se na specifičan, strukturiran način izvede i analiza
poslovnih procesa, kao i odnosa poslovnih procesa i objekata (klasa podataka), na
osnovu čega je određena opšta arhitektura informacionog sistema. Naime, agregacije
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 246
objekata relativno visokog nivoa generalizacije predstavljaju složene objekte koji su
glavni objekti posmatranja u sistemu elektronskog poslovanja platnih sistema [119].
6.4.5 Obezbeđenje interoperabilnosti
Interoperabilnost je i preduslov i olakšavajući faktor elektronskog poslovanja platnih
sistema za efikasno pružanje usluga, kojim se rešava potreba za:
• saradnjom između platnih sistema i ostalih finansijskih institucija, kao i pravnih
i fizičkih lica na nacionalnom i međunarodnom nivou;
• razmenom informacija radi ispunjenja poslovnih obaveza ili zakonskih uslova;
• razmenom i ponovnom upotrebom informacija radi povećanja efikasnosti i
smanjenja opterećenja na finansijske institucije, pravna i fizička lica.
Okvir interoperabilnosti je definisan nad skupom standarda finansijske industrije i
smernica centralne banke koji opisuju način na koji finansijske organizacije, pravna i
fizička lica moraju uzajamno poslovati. Jednom ustanovljena, interoperabilnost se
vremenom, izmenom standarda usklađuje i prilagođava promenama zakonske
regulative, tehnologija, standarda i administrativnih zahteva [64], [63].
Referentni izvor za područje interoperabilnosti u finansijskoj industriji jeste svakako
dokument ISO20022 1-5: 2004, standard koji ima kao jedan cilj i konvergenciju svih
standarda platnih sistema ka jedinstvenom koji će obezbediti olakšanu implementaciju i
interakciju svih sistema elektronskog poslovanja platnih sistema.
Narodna banka Srbije, Udruženje banaka Srbije, banke i druge finansijske institucije,
kao i pravna lica u Srbiji prate preporuke evropskih i svetskih institucija za
standardizaciju u cilju sinhronizacije sa nacionalnim i svetskim sistemima elektronskog
poslovanja platnih sistema drugih evropskih i svetskih zemalja. Iz tog razloga za ovaj
rad jesu kao osnova relevantnih preporuka osnov uzeti dokumenti ISO20022 standarda i
Evropski okvir interoperabilnosti, kao i modeli koji interoperabilnost i obezbeđuju.
6.4.6 Rezultati analize
Logička arhitektura sistema predstavlja stabilnu osnovu za razvoj sistema i omogućava
sistemu da bude realizovan kao dovoljno fleksibilan kako bi uspešno odgovorio na
funkcionalne, organizacione, tehnološke i druge promene u okruženju i samom sistemu.
Time omogućava ne samo automatizaciju poslovnih procesa, već i njihovo unapređenje.
Kao što je prikazano na slici 128, sistem je modularan i mapiranjem na odgovarajuće
fizičke čvorove obezbeđuje se povećanje performansi jednostavnim dodavanjem i/ili
zamenom komponenata. Ovaj sistem se može funkcionalno podeliti u sledeće celine:
• komponente poslovne logike;
o proces Framework;
o domain Framework;
• portal, monitoring i administracija;
• izveštavanje;
• relacioni sistem za upravljanje bazom podataka;
• transportni sistem;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 247
• adapteri za druge sisteme za razmenu poruka;
• CA struktura;
• registraciono telo.
Kod planiranja razvoja i kreiranja arhitekture sistema pošlo se od osnovnih zahteva koji
su postavljeni pred projekat, a to su potpuno ispunjenje funkcionalnih zahteva, kao i
visoka raspoloživost, visoke performanse, pouzdanost i skalabilnost. Sistem je
zamišljen kao visokodostupan, što podrazumeva operativnu funkcionalnost sistema koja
je vrlo blizu ili jednaka 100% radnog vremena. U pogledu performansi sistema
postavljen je zahtev za obradom od minimalno 50.000 dolaznih i 50.000 odlaznih
poruka na sat, što višestruko prevazilazi trenutne potrebe prosečne procesorske kuće, a
što je u skladu sa planovima za budućnost procesorske kuće. U pogledu skalabilnosti
rešen je zahtev da se povećanje kapaciteta/performansi sistema može lako ostvariti
umnožavanjem postojećih delova sistema (npr. dodavanjem novih servera).
Slika 128. Logička arhitektura EPPS sistema
Kao metodologija razvoja sistema može biti izabran Dymanic System Development
Method, koji u svojoj osnovi može da prati agilni iterativno-inkrementalni životni ciklus
razvoja [199]. Ovako definisana metodologija je kombinovana sa savremenim
dostignućima u oblasti razvoja kompleksnih IS, prvenstveno u domenu višeslojne
arhitekture zasnovane na distribuiranim komponentama i servisima.
Process framework predstavlja komponentu kojom se definiše funkcije (ponašanje)
sistema, a realizovana je tako da omogući formalan opis poslovnih procesa. Moguća je i
promena opisa poslovnog procesa. Mogu se definisati i uslovi koji utiču na tok
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 248
poslovnog procesa u vreme izvršavanja. Orkestracije se koriste za izvršavanje aktivnosti
posmatranog procesa.
Domain framework [32] definiše strukturu sistema. Može biti realizovan kroz sledeće
komponente: rečnik IS (skladište modela i pravila transformacije), predefinisanu
softversku arhitekturu (dizajn budućih aplikacija) i generator koda (automatizovana
implementacija transformacija). Na ovaj način omogućeno je da se model koji opisuje
neki poslovni domen automatizovano transformiše na odgovarajuću ciljnu platformu.
Portal, OffLine aplikacija, monitoring i administracija su aplikacije koje omogućavaju
laku interakciju sa sistemom. Portal aplikacija omogućava adekvatan prijem, odnosno
ekspediciju dokumenata i njihovo evidentiranje, kao i potrebne procedure za izvršavanje
zadatih operacija nad dokumentima. OffLine aplikacija omogućava adekvatan prijem,
odnosno ekspediciju dokumenata i njihovo evidentiranje (slično portal aplikaciji), ali sa
svim svojim funkcionalnostima determinisanim u odnosu na komunikacioni kanal koji
je samo povremeno propustan. Real time aplikacija za monitoring omogućava korisniku
da u realnom vremenu prikazuje zadate setove podataka o stanju sistema koji su u tom
trenutku za njega bitni. Na pregledan način i lakim izborom detalja (na primer klikom
miša na određenu oblast) monitoring omogućava da se sagledaju i odgovarajuće
informacije koje se nalaze raspoređeni hijerarhijski ispod detalja. Administrator sistema
može da sprovede zahteve izmenom sistema, koji proizilaze iz funkcionalnih ili
aplikativnih razloga preko sistema za administraciju.
Izveštavanje može biti implementirano korišćenjem Microsoft SQL Server Reporting
Service-a. Reporting services dozvoljavaju centralizovano upravljanje, laku proširivost,
skalabilnost, kao i veliku sigurnost podataka, interaktivne, proaktivne i pasivne izveštaje
koji se mogu dobiti u više različitih izlaznih formata kao što su HTML, EXCEL, WEB
ARCHIVE, ACROBAT(PDF) FILES, TIFF, CSV, XML file with report data. Imaju
ugrađenu podršku za generisanje izveštaja iz velikog broja izvora podataka. Svi izveštaji
kao i resource fajlovi koji mogu biti postavljeni na report server, organizovani su u
logičnu hijerarhiju foldera iznad koje je proširivi, na rolama zasnovan security sistem
koji je integrisan sa computer/domain userima i grupama [200].
Baza podataka je deo sistema koji treba da omogući visoku dostupnost, pouzdanost i
visoke performance. Dostupnost se odnosi na procenat vremena u kom je sistem
dostupan za korisnika. Ona može da se postiže zaštitom sistema od padova,
obezbeđivanjem redundantnosti sistema u slučaju padova i segmentacijom sistema. SQL
Server 2012 i Windows 2008 nude više rešenja za ostvarivanje ovih zahteva: Failover
klastering, Database mirroring, Log shiping, replikacija podataka, SQL Server
federations.
Transportni sistem može da bude realizovan kao vlasnička mreža za razmenu poruka.
Ne postoji ograničenje po pitanju sadržaja; naime, mogu se definisati i drugi sadržaji,
uključujući i prenos binarnih fajlova između učesnika. Prilikom razmatranja ovog
sistema treba uzeti u obzir osobine sistema, kao što su brzina implementacije, lakoća
primene i održavanja rešenja, skalabilnost, bezbednosna infrastruktura zasnovana na
industrijskim standardima, cross-platform podrška i zadovoljavajuće performanse, kao i
generalna servisno orijentisana arhitektura sistema, što zavisi isključivo od zahteva za
instalaciju sistema.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 249
6.5 Servisi za procesiranje
Da bi biro za procesiranje korektno izvršavao dodeljene mu servise, mora se voditi
računa i o sajtu na rezervnoj lokaciji, rezervnim komunikacionim resursima i sličnim
aspektima sistema. Servisi procesorske kuće su povezani sa razmenom poruka ili sa
servisima procesiranja. U nastavku će biti samo nabrojani neki od mogućih najvažnijih
servisa koje procesorska kuća može da ponudi: rutiranje poruka, notifikacija prijema
procesora (ACK/NAK), identifikacija učesnika i njegovo logovanje na sistem,
autentifikacija učesnika putem kvalifikovanog elektronskog potpisa, prenos
enkriptovanih podataka, adresiranje sa ograničenjem prijema, verifikacija sintakse,
verifikacija semantike, verifikacija poslovnih pravila, notifikacija da je poruka
isporučena primaocu (ACK2/NAK2), skladištenje indentifikacionih i adresnih podataka,
funkcionalnih i komercijalnih podataka o proizvodima, Veb-servisi prikaza na
interfejsu, servisi podrške i trajnog arhiviranja poruka.
Slika 129. Uvođenje novih funkcionalnosti u EPPS sistem
Funkcionalnosti enkripcije poruke ili njenog dela na nivou razmene poruke je veoma
značajan servis kada učesnik ne želi da bilo ko, bez obzira na ugovorene obaveze
tajnosti, ima mogućnost da sistematski neovlašćeno prikuplja podatke. Ograničenje
prijema, takođe, može da se prezentuje kao servis. Podrazumeva izradu baze podataka
učesnika i tabele ko sa kim može da komunicira. Uvid u ovu bazu, preko odgovarajućeg
interfejsa, treba da ima sistem za razmenu komponenata i administrativna konzola
procesora. Notifikacija ACK2 i NAK2 kao servis obaveštava pošiljaoca poruke da je
primalac poruke fizički primio poruku. Formiranje baze podataka o proizvodima i
pristup putem veb-interfejsa takođe se može ponuditi kao servis. Pored pretraga
informacija o proizvodima, kao servis se može ponuditi i pružanje usluga formiranja i
čuvanja poruka, pregledanje vezanih sadržaja, eventualno konvertovanje dokumenata,
slanje dokumenata i drugo.
Problem uvođenja novih poruka u sistem i njihovo procesiranje u sistemu može da se
automatizuje i na taj način dogovori životni ciklus elemenata sistema: uvođenje novih
funkcionalnosti u sistem, izmena starih funkcionalnosti uvođenjem verzija poruka,
ukidanje funkcionalnosti ukidanjem odgovarajućih poruka u sistemu, slika 129.
Nadređeni sistem šalje XML instancu, odnosno poruku sa sadržajem podređenom
sistemu. Sistem proverava da li je dobijeni fajl XML instanca, da li je verzija šeme po
kojoj je kreirana instanca poznata sistemu i vrši ostale potrebne provere, kao na primer,
da li je instanca od poznatog učesnika, da li je dobar potpis i slično. Ukoliko je već
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 250
registrovana, odobrena i implementirana šema, odnosno verzija šeme, XML instanca se
učitava u bazu podataka i izvršavaju se nad njom zadate operacije. Ukoliko nije, traži se
u instanci po kojoj je šemi kreirana instanca. Šema sa zadatim imenom u instanci
pronalazi se na zadatoj lokaciji koja je takođe navedena u instanci i odatle se preuzima.
Na osnovu preuzete šeme generišu se upozorenje administratoru sistema da je stigla
instanca koja nije podržana u sistemu. Administrator, na osnovu dokumenata o
uvođenju nove šeme:
• daje nalog za generisanje baze (aplikacija - pogled na bazu sa pristiglim xsd
šemama koje nisu odobrene - samo jedno pojavljivanje šeme sa istim
nazivom);
• daje nalog za generisanje baze iz XML šeme;
• po kreiranju šeme daje nalog za kreiranje *.dll-a za učitavanje instanci u
kreiranu šemu baze podataka (alat ima mogućnost da za generisanu bazu
sam pronađe podrazumevano - default mapiranje);
• administrator određuje gde će takva instanca da se učitava (podrazumevanu -
default šemu za tu instancu) - u aplikaciji ima informaciju da je generisana
baza i *.dll;
• odobrava da se učitavaju instance te šeme;
• učitava sve postojeće instance šeme u bazu za pretprocesiranje;
• šalje nadređenom sistemu poruku da je izvršeno uspešno prihvatanje nove
instance za pretprocesiranje.
Slika 130. camt.008.002.01.xsd shema na ISO20022 sajtu sa instancom
Instance koje pristižu preko sistema za razmenu u ovom trenutku sve mogu da se
prihvataju na pretprocesiranje. Nakon toga, na osnovu dokumenta o uvođenju nove
šeme, administrator dodaje odgovarajuće operacije za prihvatanje instance iz sistema za
pretprocesiranje u sistem za procesiranje i odgovarajuće operacije za prihvatanje
instance za procesiranje, i šalje nadređenom sistemu poruku da je izvršeno uspešno
prihvatanje nove instance za procesiranje. Spremišta za procesiranje i operacije moraju
da budu predefinisana po dokumentima koje je nadređeni sistem prosledio podređenom
sistemu u procesu uvođenja nove zakonske regulative, novih normativa, pravila ili
slično. Na ovaj način omogućava se i da proizvoljan broj verzija jedne vrste poruka
bude u opticaju, što zavisi od učesnika koji zadaje pravila u sistemu.
U narednom tekstu je opis jednog od načina na koji može da se iskoriste elementi za
standardizaciju u generisanju elemenata sistema uz pomoć alata koji su prisutni na
tržištu ili kao open source. Ovo će biti prikazano na jednom opštem primeru koji u sebi
sadrži sve potrebne elemente da se zaključi da je to moguće i za ostale slučajeve.
Pođimo od osnovnog materijala – xsd šeme koja se nalazi na ISO20022 sajtu. U ovom
primeru će biti korišćena šema RequestToCancelPayment (camt.008.002.01.xsd) sa
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 251
svojom odgovarajućom instancom, kao što je prikazano na slici 130. Izgled šeme je
prikazan u alatu Altova XMLSpy [3] na slici 131. Alexis Smirnov [192] je pokazao kako
se unificiraju objekti i relaciona struktura podataka uz pomoć XDS šeme kao osnove
objektno-relacionog mapiranja, t.j način na koji se može kreirati struktura baze podataka
uz pomoć XSD fajla. Na slici 132. je pikazan alat XSD2DB Alexis Smirnova i grupe
autora (može se na internetu pronaći izvršna verzija kao i izvorni kod [192]) koji je
primenjen na RequestToCancelPayment šemu . Šeme koje su preuzete od ISO20022
organizacije nisu normalizovani XML dokumenti [108], pa postoje dve solucije u
korišćenju alata: 1. izvršiti normalizaciju XML dokumenta, pa kreirati konceptualni
model baze podataka ili 2. kreirati bazu iz postojeće XSD šeme i normalizaciju baze
podataka izvršiti naknadno. Slika 132. prikazuje gde alat može da se preuzme,
mogućnosti alata, od čega je kreirana struktura baze podataka i na koji način je kreirana
struktura baze podataka.
Slika 131. Struktura XSD šeme zahteva za otkazivanje plaćanja
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 252
Slika 132. Kreiranje modela baze podataka alatom korišćenjem XSD šeme
Slika 133. Model baze podataka kreiran XSD2DB alatom
Model baze podataka, prikazan na slici 133. nije normalizovan i potrebno je izvršiti
korekcije i normalizaciju da bi se dobio model zadovoljavajućih karakteristika.
Poređenjem strukture XSD šeme sa slike 131. i modela baze podataka sa slike 133,
može se izvršiti poređenje struktura.
Ukoliko imamo XSD šemu i odgovarajuću strukturu baze podataka, moguće je uz
pomoć alata doći do aplikativne strukture za unos, izmenu i brisanje odgovarajućih
instanci u bazi podataka. U tu svrhu može da se iskoristi alat Altova MapForce [3], u
kome ćemo izvršiti mapiranje xsd strukture u strukturu baze podataka.
Mapiranje camt.008.002.01.xsd strukture u strukturu baze podataka sa slike 133.
prikazano je na slici 134. Iz mapiranih struktura može da se generiše odgovarajuća
aplikativna struktura u više programskih jezika, kao što je to prikazano na slici 135. za
generisanje izvornog koda u C# [182] programskom jeziku, na slici 136. je prikazano
uspešno generisanje koda. Prilikom generisanja korišćena je informacija o instanci sa
ISO20022 sajta, camt.008.002.01.xml u kojoj se nalaze testni podaci.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 253
Slika 134. Mapiranje XSD šeme i šeme baze podataka
Slika 135. Izbor programskog jezika za generisanje koda za pristup bazi
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 254
Slika 136. Uspešno generisana aplikativna struktura
Startovanjem konzolne aplikacije vrši se ažuriranje baze podataka i slika 137. prikazuje
uspešan unos camt.008.002.01.xml instance u strukturu baze podataka.
Slika 137. Uspešno ažuriranje baze podataka camt.008.002.01.xml instancom
Izvorni kod Altova MapForce alatom generisane testne konzolne aplikacije izgleda
ovako:
using System;
using System.Collections;
using System.Data;
using Altova.Types;
using Altova.Functions;
namespace Mapping
{
public class MappingConsole
{
public static void Main(string[] args)
{
Console.Out.WriteLine("Mapping Application");
try
{
TraceTargetConsole ttc = new TraceTargetConsole();
MappingMapToUniversalDB MappingMapToUniversalDBObject = new MappingMapToUniversalDB();
MappingMapToUniversalDBObject.RegisterTraceTarget(ttc); MappingMapToUniversalDBObject.Run(
"C:/Documents and Settings/Slobodan/Desktop/xsd2db/xsd2db/bin/Release/camt.008.002.01.xml",
"Provider=SQLOLEDB.1; Data Source=SOLARIS; Initial Catalog=UniversalDB;Integrated Security=SSPI;Persist Security
Info=False;"); Console.Out.WriteLine("Finished");
}
catch (Altova.UserException ue)
{
Console.Out.Write("USER EXCEPTION: "); Console.Out.WriteLine( ue.Message ); System.Environment.Exit(1);
}
catch (Exception e)
{
Console.Out.Write("ERROR: "); Console.Out.WriteLine( e.Message ); Console.Out.WriteLine( e.StackTrace );
System.Environment.Exit(1);
}
}
}
class TraceTargetConsole : Altova.TraceTarget { public void WriteTrace(string info) { Console.Out.WriteLine(info);
}
}
}
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 255
U generisanoj testnoj konzolnoj aplikaciji nalazi se kod koji može da se koristi u bilo
kom aplikativnom sistemu za rad sa bazom podataka nad kojom je konstruisan. Na isti
način se može postupiti i za sve ostale šeme date na ISO20022 sajtu, kao i za druge xsd
strukture.
Ovaj primer pokazuje da je moguće od xsd strukture, kojima se vrši zadavanje
standarda, korišćenjem dostupnih alata doći do elemenata sistema koji imaju
zadovoljavajuće karakteristike. Svi dobijeni elementi platnog sistema koji su opisani
postoje u mnogim verzijama, sa posebnim osobinama na tržištu. Dobijeni elementi
predstavljaju odličnu osnovu za razvoj projekta, ali i polazište za izgradnju novih,
karakterističnih alata koji bi u još većoj meri mogli da automatizuju razvoj aplikativnih
elemenata platnih sistema.
Procesiranje transakcija u elektronskom poslovanju platnih sistema implementira se na
način koji je opisan u primeru RTGS procesiranja. Tabela Stanja RTGS sistema sadrži u
sebi informacije o stanjima računa banaka u RTGS sistemu. To su računi na koje se vrši
priliv i odliv sredstava kada se izvršavaju transakcije Retail korisnika banaka. Prilikom
rada RTGS sistema moguće je da dođe do unakrsnog zaključavanja računa odnosno do
pojave Greed Locka. Rešenje je primena nekog od Greed Lock Resolution algoritma. Na
tabeli Stanja postavljen je triger. Triger nad tabelom Stanja ima zadatak da, kada se
promeni stanje na računu pokuša da izvrši još jednu transakciju koja je u bazi podataka
zapisana sa stanjem „na čekanju za izvršenje zbog nedostatka sredstava“. Taj pokušaj
izvršenja transakcije vrši se nad računom na kome su dodata sredstva, tako da postoji
šansa da zbog priliva na račun one transakcije koje nisu mogle da se izvrše postanu
izvršive. Na taj način se redukuje broj transakcija koje ne bi bile realizovane zbog
nedostatka sredstava na računima banaka. Smanjuje se i verovatnoća unakrsnog
zaključavanja računa i povećava verovatnoća situacije ukoliko bi neke transakcije koje
čekaju na red bile izvršene na ovaj način, da red za čekanje bude smanjen ili prazan.
Izvorni kod trigera nad tabelom dat je u Prilogu 9.
Navedeni triger je primer elementa koji služi za jednu od funkcija procesiranja. I ostali
elementi sistema za procesiranje mogu da se izvedu u istoj tehnici, ali moguće je istu
stvar uraditi i na više drugih načina. Kada je poruka stigla u sistem i kada je zabeležena
u bazu, završen je jedan segment poslova vezanih za procesiranje. Tačka kada je poruka
zabeležena u bazu može biti tačka prekida, kada se ostali procesi koji su potrebni da se
odigraju mogu odvijati asinhrono u odnosu na nju, ali može da bude i tačka u kojoj se
procesi nastavljaju događati kontinuirano, bez prekida, tako da se sve ostale potrebne
radnje moraju izvršavati sinhrono. Izvršeno je laboratorijsko ispitivanje da bi se utvrdilo
da li je bolje da procesi koji slede budu nezavisni od prethodnih, odnosno asinhroni, ili
da budu u kontinualnom sledu, odnosno sinhroni. Zaključak je da je bolja osobina
asinhronosti procesa i da je bolje da sistem ima što više asinhronih tačaka prekida.
Procesiranje se odvija nezavisno po segmentima, i u slučaju da dođe do prekida procesa,
mogu se i sa nekim drugim elementom za procesiranje izvršiti procesi koji nedostaju.
Ukoliko je ambijent za procesiranje nestabilan, postojaće manji broj grešaka o kojima se
vodi računa. Dugački procesni lanci moraju da imaju mnogo komfornije uslove u
kojima se odvijaju i imaju duži životni vek, čime se povećava verovatnoća negativnog
delovanja ambijentalnih uslova. Ukoliko postoji veliki broj dugoživućih lanaca procesa,
oni zauzimaju značajno više životnog prostora od istog broja kratkoživučih, asinhronih
procesa.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 256
6.6 Primena rešenja
U ovom poglavlju analiziran je značaj informacionih tehnologija, interoperabilnosti i
sigurnosti u elektronskom poslovanju platnih sistema i njihova kolaboracija sa
sistemima lanaca snabdevanja, standardnim sistemima posebne namene, sistemima
drugih finansijskih organizacija, kao i sistemima koji čine osnovu koja omogućava
doslednu i zakonski ispravnu kolaboraciju svih sistema.
6.6.1 Komponente sistema
Kompanija Dunav osiguranje a.d.o. u svojim poslovnim procesima u interakciji je sa
mnoštvom raznorodnih sistema bez kojih ne bi bilo moguće ostvariti poslovni uspeh i
paletu proizvoda koje jedno savremeno osiguravajuće društvo treba da ponudi tržištu.
Svaka poslovna transakcija Kompanije praćena je sa jednom ili više finansijskih
transakcija. Poslovne transakcije i sa pravnim i fizičkim licima u svim segmentima
poslovanja obavljaju se na način koji je do sada bio uobičajen u praksi u Srbiji, koja
preovladava u poslovnim procesima osiguravajućih društava.
Slika 138. Učesnici i osnovni potprocesi u procesu prijave štete
Uvođenjem sistema za direktna zaduženja u Udruženju banaka Srbije stvorena je
osnova za inovaciju proizvoda, ali i načina poslovanja. Finansijske transakcije se
obavljaju sistemom elektronskog bankarstva i ne postoji mogućnost iniciranja
transakcija sa unosnog mesta gde nastaju podaci, već se naknadno, na osnovu
informacija u informacionom sistemu, vrši uparivanje transakcija sa rezultatima
poslovnih transakcija. Na taj način se troše resursi i vreme poslovnih transakcija nije
predvidivo. Standardi u finansijskoj industriji osiguravajućih društava omogućavaju i
Retail i korporativnim klijentima da izvrše naručivanje proizvoda osiguravajućeg
društva kao i svaki drugi proizvod korišćenjem savremenih informacionih tehnologija
[101] i da na taj način da učine tačnijim i bržim procese koji prate poslovne procese
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 257
osiguravanja i reosiguranja. Standardi lanaca snabdevanja daju mogućnost da se, kao i
za sve ostale proizvode potreban materijal, alat i rezervni delovi proizašli iz sistema za
procenu, mogu na brz i efikasan način standardnim porukama naručiti i pratiti izvršenje.
Sistem za autorizaciju i očuvanje konzistentnosti poruka i podataka u njima, kao i telo
za registraciju poruka čuvaju konzistentnost podataka i procesa i na taj način
omogućavaju izvršavanje poslovnih procesa u okvirima zakonske regulative.
Pored nabrojanih transakcija u procesu koji je prikazan na slici 138, nisu prikazane
finansijske transakcije od interesa, među kojima su i: kupovina osiguranja, troškovi
izdavanja zapisnika MUP-a oštećeniku i KDO-u, troškovi izrade vrednosti štete na
osnovu specifikacije, troškovi banke za uslugu sklapanja mandata za DA i mandata za
auto servis, troškovi iniciranja finansijske transakcije putem eBankinga (za Autoservis i
DA), troškovi banke za izvršenje finansijske transakcije direktnog zaduženja, troškovi
UBS za bruto poravnanje i drugi.
Slika 139. Dekompozicija složenog procesa
Svaki od navedenih procesa složen je najmanje od sledećih procesa, prikazanih na slici
139: provere potpisa, skladištenja u Dunav arhivu po protokolu Dunav arhive kao tela
za registraciju poruka i navedenog toka. Iz ovoga sledi da Dunav arhiva kao telo za
registraciju poruka mora da bude vlasnik, da adresiranje podrazumeva automatsko
rutiranje poruke ka Dunav arhivi koja poruku u jednoj transakciji skladišti, priprema za
slanje i šalje učesniku na koga je poruka adresirana.
6.6.2 Realizacija sistema
6.6.2.1 Realizacija sistema lanaca snabdevanja
Poslovni partneri u svakom segmentu specijalizovani su za odgovarajući segment
poslovanja. Danas je veoma retko da se proizvođači bave i distribucijom; u nekim
oblastima, kao što je u farmaciji, u nekim zemljama proizvođač ne sme da se bavi i
prodajom lekova na malo i slično. Klirinška kuća je specijalizovana da vodi računa o
potrebnim resursima za transport i procesiranje standardizovanih poruka, iz mnoštva
kombinacija koje se nude nekim standardom klirinška kuća propisuje podstandard, ona
vodi računa o svim aspektima sistema: dokumentima sistema, standardima,
metodologiji, tehnologiji, organizaciji, kadrovima, sistemskom softveru i hardveru.
Klirinška kuća može da bude neprofitna organizacija. Primer za takav vid organizacije
je SWIFT ili profitna organizacija, kao što je na primer Udruženje banaka Srbije. U oba
slučaja, procesorska kuća organizuje svoje poslove u skladu sa Operativnim pravilima,
dokumentom Format i namena poruka i Tehničkim uputstvom. Uz navedena
dokumenta, softverske module za slanje i prijem poruka, klirinške kuće sve češće
determinišu i druge elemente sistema: sertifikate potrebne za potpisivanje i kriptovanje
sadržaja, odgovarajuće XML šeme i pripadajuće im modele.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 258
U većini slučajeva partneri žele da budu povezani sa klirinškom kućom i da razmenjuju
poruke putem opisane infrastrukture klirinške kuće. Da bi ustanovila konzistentnu
razmenu, klirinška kuća obezbeđuju potrebne resurse uključujući i potrebne mrežne
resurse, softverske module za slanje i primanje standardnih poruka, odgovarajuće
rutiranje poruka, procesiranje i skladištenje podataka o partnerima, proizvodima i
katalozima, mogućnost pretrage dozvoljenih skupova onlajn, na sajtu procesorske kuće,
kao i da neki manji poslovni sistemi mogu da zadovolje i ostale potrebe pri pretrazi i
zboru partnera, proizvoda ili kataloga.
Prvi način komunikacije jeste da klijent može da adresira (pošalje poruku) samo
klirinšku kuću. Klirinška kuća može, u zavisnosti od sadržaja poruke i ovlašćenja, da
izvrši odgovarajuće procesiranje koje može da uključi i slanje poruke nekom drugom
svom participantu.
Drugi način komunikacije možemo da definišemo kao komunikaciju između klirinških
kuća, gde jedna klirinška kuća može da adresira drugu klirinšku kuću. Pri tome jedna
klirinška kuća ne može direktno da adresira klijente druge klirinške kuće, već klirinška
kuća koja prima poruku može da izvrši odgovarajuće procesiranje koje može da uključi
i slanje poruke svom participantu.
Treći način komunikacije uključuje i prvi i drugi. Na taj način, klijent jedne klirinške
kuće dobija mogućnost adresiranja klijenta druge klirinške kuće. I klirinška kuća dobija
mogućnost adresiranja klijenata druge klirinške kuće. Na ovaj način dobija se
konzistentan adresni prostor učesnika u razmeni poruka u lancu snabdevanja.
Proces prerade (procesiranja) poruka sastoji se od sledećih aktivnosti: pribavljanja i
provere administrativnih privilegija za pristup ulaznim podacima, skladištenja ulaznih
informacija, primene tehnološkog procesa obrade , odgovarajućeg broja operacija,
skladištenja izlaznih informacija i davanja administrativnih privilegija za pristup
izlaznim podacima.
Slika 140. Izbor šeme u dokument kreatoru Sylus Studi-a
Navedeni proces je tretiran kao bilo koji tehnološki proces, na primer iz mašinske
industrije. Postojanje XSD (XML Schema Definition ili skraćeno XSD je XML bazirani
jezik koji se koristi da opiše i kontroliše sadržaj XML dokumenata) šema determiniše
skladišta ulaznih podataka i na taj način determiniše i elemente sistema (klase i relacije
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 259
između njih), što može da se iskoristi za pisanje sekvenci operacija tehnologije
potrebnih za izradu modula za procesiranje.
Realizacija sistema lanca snabdevanja vrši se na isti način kao i realizacija sistema za
Credit Transfers [21]. Na slici 140. je predstavljen dokument kreator u XML alatu Sylus
Studio [202]. U kartici XML Editor može se izabrati EANCOM to XML Schema opcija.
Na taj način omogućavamo kreiranje XSD šeme sa odgovarajućom strukturom u koju
može da se mapira struktura izabrane standardne EANCOM poruke.
Klikom na taster OK dobija se mogućnost izbora verzije standarda poruke i vrsta
poruke. U polju za izbor nalazi se svih 49 mogućih definisanih poruka. Postoji
mogućnost još nekih opcija za kreiranje ako se izvrši izbor kao na slici 141.
Slika 141. Izbor verzije željene EANCOM poruke
Nakon izvršenog kreiranja XSD sheme i uklanjanja jednog opcionog noda, dobija se
struktura kao što je to prikazano na slici 142. Kreirana XSD shema može da se mapira
sa originalnom EANCOM porukom uz pomoć koje je generisana.
Slika 142. Generisana struktura XSD šeme
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 260
Na osnovu XSD sheme moguće je izvršiti kreiranje baze podataka XSD2DB alatom.
Kreirana baza podataka može da se mapira šemom iz koje je generisana.
Iz prethodnog sledi da bilo koja EANCOM 2002 poruka lanca snabdevanja može da se
mapira sa odgovarajućom šemom baze podataka, koja je nastala na način koji je
prethodno opisan i prikazan na slici 143. Postojećim alatima moguće je generisati i
odgovarajuće dinamičke biblioteke za insertovanje poruka u bazu i ekstrahovanje
poruka iz baze. Iz prethodnog sledi da sve EANCOM 2002 poruke koje su primljene i
koje se šalju mogu biti uskladištene u bazi podataka i nad njima se mogu vršiti
odgovarajuće operacije koje su indukovane poslovnim zahtevima. Navedeni elementi
mogu se generisati za potrebe procesorske kuće ili preduzeća.
U procesorskoj kući se generiše data pool koji je centralizovano mesto na kome se
skladište informacije o partnerima, njihovim proizvodima ili servisima i odgovarajućim
katalozima. Slična preslikavanja i elementi sistema generišu se i kod participanata za
njihove potrebe.
Slika 143. Mapiranje šeme poruke sa bazom podataka
Danas se u praksi javlja veliki, gotovo nepremostiv problem u preduzećima - mapiranje
iz, uglavnom sopstvenog formata, u neki standardan format. Pokazuje se da je jedan
takav, gotovo trivijalan problem, prerastao u veliki i nepremostiv problem
umnožavanjem broja mapiranja. Bez korišćenja alata, ovo često prestavlja veliki zahvat,
od same analize problema, pa do implementacije. Danas je praksa da se od primene
ovakvih sistema odustaje već prilikom analize ovakvih koraka.
6.6.2.2 Realizacija Eurotax sistema
Zahtev kompanije „Dunav osiguranje“ jeste da se izvrši centralizacija podataka procene
šteta na osnovu programa Eurotax EMU koji će omogućiti centralizaciju podataka
vezanih za pružanje usluge procene štete na motornim vozilima kao i omogućavanje
arhiviranja dokumentacije nastale prilikom procene, omogućavanje arhiviranja raznih
dokumenata vezanih za procenu štete na arhivskom serveru kompanije a vrši se i
formiranje baze podataka na osnovu podataka iz Eurotaxa koja služi kao osnova za
formiranje raznih vrsta pregleda i izveštaja. Postoji mogućnost povezivanja sa
projektima prijave i likvidacije šteta, kao i sa projektom rezervacije šteta.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 261
Implementirani su sledeći moduli, prikazani na slici 144: Modul za povezivanje sa
Eurotaxom sistemom u EU, modul šifarnika sa vrstama, modelima i tipovima vozila,
delovima automobila, modul za pohranjivanje podataka o proceni štete, modul za
povezivanje sa arhivskim serverom Dunav Arhiva za arhiviranje raznih vrsta
dokumenata, fotografija i xml-ova, modul za povezivanje sa postojećim modulima za
prijavu, rezervaciju i likvidaciju šteta informacionog sistema Kompanije Dunav
osiguranje.
Slika 144. Sistema za centralizaciju procene štete
i arhiviranje pripadajuće dokumentacije
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 262
Trenutno se program Eurotax koristi na oko 50 lokacija, procena šteta se radi za potrebe
kompanije Dunav osiguranje i uslužno za druga pravna i fizička lica, slika 144. Procene
se sastoje od standardne dokumentacije zadate zakonskom regulativom, obračunima,
kalkulacijama i fotografijama oštećenih automobila koji se čuvaju u Dunav arhivi, sa
mogućnošću uvida od strane rukovodilaca ili drugih procenitelja. Svaka procena dobija
svoju referentnu oznaku. Procena štete se može vršiti pre i posle prijave štete u sistemu
Kompanije. Povezivanje sa prijavom se može izvršiti preko internog referentnog broja –
unosi se mašinski broj prijavljene štete. Dokumenti koji se eksportuju iz Eurotax
sistema i koji se prikupljaju prilikom procene šteta su: zapisnik o oštećenju vozila,
kalkulacija, obračun o visini štete, fotografije oštećenog automobila, skenirane vozačke
i saobraćajne dozvole, zapisnici MUP-a, evropski izveštaji. Procena štete se može vršiti
više puta i svaka kalkulacija se vodi pod istim referentnim brojem procene i novim
brojem kalkulacije.
Pošto se podaci čuvaju centralizovano, postoji mogućnost uvida u procenu štete od
strane rukovodstva ili drugih procenitelja radi kontrole. Moguće je uraditi dodatnu
procenu od strane drugih procenitelja sa svake lokacije procene štete i omogućeno je
praćenje rada procenitelja i dobijanje izveštaja vezanih za njihov rad. Moguć je uvid u
sve procene urađene u Dunav osiguranju i mogućnost praćenja rada procenitelja.
Stvoren je okvir za formiranje raznih izveštaja o procenama, oštećenim delovima, kao i
mogućnost povezivanja sa prijavom, rezervacijom i likvidacijom štete.
6.6.2.3 Realizacija sistema osiguranja
Trendovi u razmeni podataka u sistemima, pa i sistemima osiguranja, jesu u
obezbeđivanju razvoja adekvatnih otvorenih standarda za razmenu poslovnih
dokumenata na iskustvima standarda i neprofitnih organizacija kao što je u finansijskoj
industriji SWIFT organizacija. U industriji osiguranja takav primer je i organizacija
ACORD [1]. ACORD (Association for Cooperative Operations Research and
Development) je globalna, neprofitna organizacija koja razvija standarde u službi
industrije osiguranja i odgovarajućih industrijskih finansijskih servisa. ACORD-ova
misija je da pospeši dogovore u razvoju otvorenih standarda podataka i formi standarda.
ACORD članov čine veliki broj osiguravajućih i reosiguravajućih kompanija, agenata i
brokera, proizvođača softvera i pripadajućih industrija širom sveta. ACORD ima cilj da
obezbedi razmenu podataka između različitih platformi i inplementacionih standarda,
odnosno na standardima za razmenu informacija između sistema i partnera. ACORD
Standards and services utvrđuje standarde za kvalitet podataka i njihovu
transparentnost, što rezultuje većom efikasnošću i proširenjem tržišta na kojima je
zastupljen XML.
ACORD XML pokriva i zahteve u realnom vremenu u odnosu na poslove sa poslovnim
transakcijama korišćenjem klijent-server okruženja kroz adekvatne sisteme poruka.
ACORD XML obezbeđuje željeni otvoren i efikasan način transfera strukturiranih
podataka između aplikativnih sistema i partnera. Najveća korist od uvođenja
elektronske razmene podataka u osiguranju jeste tačnost i pravovremenost informacija.
Postiže se mogućnost i sledljivosti proizvoda, kao i povećavanje različitih pozitivnih
ekonomskih aspekata korišćenjem elektronske razmene dokumenata, pogotovu ukoliko
je elektronska razmena centralizovana preko biroa za procesiranje.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 263
Zakonska regulativa u većini zemalja ima tendenciju da se prilagodi novim
informacionim tehnologijama koje mogu da se uvedu u poslovanje, pa i u poslovne
procese kompanija koje se bave osiguranjem. Važni aspekti su definisani ili se definišu
u mnogim zemljama u okviru zakonskih regulativa povezanih sa elektronskim potpisom
[136], digitalnim dokumentima [144] i elektronskim poslovanjem.
U skladu sa zakonskom regulativom, razvija se i svest o uzorcima koji mogu da budu
korišćeni da bi se informatički podržalo takvo poslovanje. Razvijen je čitav niz uzoraka
za integraciju [90], od kojih je jedan i Dokument Message uzorak [14], pa je čak i
savremena arhitektura [85] servisno orijentisana, prilagođena sadašnjim saznanjima i
novim standardima.
Uvođenje standarda ACORD podrazumeva tri osnovna koraka sa svojim potprocesima:
organizacioni, funkcionalni i tehnički korak, kako je prikazano u tabeli 21. Razvijen je i
ACORD Framework koji je skup od pet modela potrebnih za razvoj ACORD standarda.
ACORD Framework se sastoji od poslovnog rečnika, informacionog modela sa
odgovarajućim konceptima koji sadrži i model podataka, modela komponenata i
poslovnog modela, prikazanih na slici 145. Vrši se standardizacija „servisa poslovnih
procesa”, i to tako što se ne mora kreirati ACORD poruka za svaki proces koji se
definiše prateći servis orjentisanu arhitekturu da se mogu kreirati vlastite poruke
bazirane na ACORD XML standardu podataka u svrhu razmene podataka između
procesa.
U nameri standardizacije podataka baziranih na UML metodologiji modeliranja,
ACORD se opredelio za metodologiju “Core Component” razvijenu od strane
UN/CEFACT kao kompatibilnu osnovu za razvoj ACORD rečnika podataka.
UN/CEFACT [218], OASIS/UBL [157] i ostale organizacije za razvoj standarda
napravile su značajan napredak radeći zajedno na jedinstvenom imenovanju i pravilima
izrade (odnosno na UML NDR - Universal Business Language, Naming and Design
Rules) pristupa koji postavlja XML standarde podataka za generisanje skupa pravila
standarda direktno iz Core Component modela. ACORD poslovna poruka je skup
elemenata i/ili agregata, koji se prosleđuju od klijenta ka serveru kao zahtev (Request
Message) ili od servera ka klijentu kao odgovor (Response Message). Poruka sa
odgovorom je tipičan nadskup zahteva koji sadrži odgovor zajedno sa zahtevom. Tipovi
poruka se definišu ACORD specifikacijom i podržavaju sledeće poslovne transakcije:
• Add ACORD poruka se koristi za kreiranje nove instance objekta;
• Inquiry ACORD poruka se koristi za pribavljanje kvota za objekat ili
informaciju o stanju određenog objekta;
• Submit ACORD poruka se koristi za prosleđivanje podataka i razlikuje se od
Add poruke po tome što poruka Submit informativna i ne zahteva određene
privilegije;
• Modification ACORD poruka se koristi da izmeni instancu ili objekat;
• Cancellation ACORD poruka se koristi za otkazivanje ili otkazivanje
zanavljanja postojeće instance objekta;
• Renewal ACORD poruka se koristi za obnavljanje instance ili postojećeg
objekta;
• Reinstatement ACORD poruka se koristi da ponovo instancira postojeći
objekat;
• Reissue ACORD poruka se koristi da prepiše instancu od postojećeg objekta;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 264
• Synchronization ACORD poruka se koristi da obezbedi instancu specifičnog
objekta od strane servis provajdera usluge.
PROCES OPIS
Organizacioni
procesi
Provera ciljeva.
Proglašavanje internog lidera u svakoj organizacionoj jedinici.
Uključivanje poslovnih i IT kadrova u svakom od koraka procesa.
Definisanje zajedničkih rokova sa poslovnim subjektima i internim i eksternim.
Utvrđivanje zajedničkih radnih i statusnih sastanaka.
Utvrđivanje potrebnih resursa i zahteva za praćenje.
Funkcionalni
procesi
Definisanje područja implementacije (tipova poruka, transakcija, LOB itd).
Razvoj poslovnog slučaja.
Razvoj funkcionalne specifikacije koja uključuje dijagrame tokova, specifične
fičere, zahteve za podacima očekivanja i slično.
Validiranje i sinhronizaciju potreba za podacima..
Identifikacija svih poslovnih entiteta.
Praćenje zavisnosti i utvrđivanje svih promena sa svim uključenim stranama u
komunikaciji.
Odlučivanje o potrebnim inicijalnim konverzijama podataka.
Definisanje potrebnog nivoa informacija za mapiranje podataka.
Mapiranje potrebnih podataka.
Specificiranje procesa automatizacije (potpuno automatizovanje, validacija
korisnika, kontrole itd).
Pažljivo preispitivanje ACORD preporuka, uputstava za implementaciju u smislu
obaveznih polja, kurseva za razmenu i poslovnih pravila.
Definisanje prava, autorizacije i načina pristupa nestrukturiranim informacijama.
Identifikacija vlasnika prava i zaštite u svakoj organizaciji.
Dogovor oko kriterijuma prihvatanja.
Dogovor oko korekcije procesa.
Tehnički
procesi
Dogovor oko standarda.
Usaglašavanje oko verzije protokola (poruka, SOAP/Web profila servisa i drugih
sličnih aspekata).
Dogovor oko načina na koji se pristupa nestrukturiranim podacima (skladište
dokumenata, FTP itd).
Tri faze isporuke:
1. Test faza na specifičnom okruženju.
2. Pilot faza sa radom na tradicionalni način - u papirnoj formi i sa XML porukama.
3. Produkcina faza samo sa XML porukama.
Tabela 21. Osnovni koraci za uvođenje standarda
Standard ACORD definiše strukturu poruke koja je predstavljena na slici 146. ACORD
poruke se mogu podeliti i po oblastima kojima pripadaju, po odgovarajućim područjima
za koje se vrši standardizacija poslovnih procesa. Podela po područjima ACORD
standardizacije prikazana je na slici 147.
Slika 145. ACORD Framework za razvoj standarda
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 265
Standard Akord opisuje i osnovne segmente razvoja i standardizacije koji se mogu
primeniti u kreiranju biroa za procesiranje sa ACORD ili drugim standardom za poruke.
Definisane poruke i segmentirani razvoj pokrivaju sve potrebne poslovne procese za
određeni poddomen i mogućnost za započinjanje komunikacije u smislu razmene
osnovnih informacija o poslovnim transakcijama ili onima koje ih opisuju.
Standardizacija indukuje i potrebu za razvoj i uspostavljanje sigurnog puta za
komunikaciju, uz pomoć kojega bi mogla da se vrši razmena potrebnih informacija sa
valjanim mehanizmima povratne sprege, na nivou fizičke razmene putem
komunikacionog kanala i na nivou poslovne komunikacije, odnosno potrebu za
korišćenjem specijalizovanog sistema za razmenu standardizovanih poslovnih poruka.
Slika 146. Struktura ACORD poruke
Slika 147. Područja ACORD standardizacije
ACORD Messaging Library (AML)
AML Architecture
ACORD Web Services Profile (AWSP)
Catastrophe Exposure Data Standards
Data Model
Information Model
Product Schema
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 266
6.6.2.4 Dunav arhiva registraciono telo
Kod planiranja razvoja i kreiranja arhitekture sistema Dunav arhive pošlo se od
osnovnih zahteva koji su postavljeni pred projekat, a to su potpuno ispunjenje zadatih
funkcionalnih zahteva impliciranih zakonskom regulativom, kao i visoka raspoloživost,
visoke performanse, pouzdanost i skalabilnost. U pogledu performansi sistema
postavljen je zahtev za obradom većeg broja konkurentnih zahteva za pregledanje
podataka u arhivi. U pogledu skalabilnosti postavljen je zahtev da se povećanje
kapaciteta/performansi sistema može lako ostvariti umnožavanjem postojećih delova
sistema (npr. dodavanjem novih servera).
Sistem je realizovan u troslojnoj softverskoj arhitekturi. Slojevi arhitekture su:
• korisnički interfejs koji se sastoji od prikaza logičkih celina sistema: Pregled
arhive, Pretraga, Administracija;
• sloj poslovne logike sistema koji na osnovu korisničkog zahteva filtrira tražene
podatke i prezentuje ih korisničkom interfejsu;
• sloj podataka koji je predstavljen sa sistemom za upravljanje relacionom bazom
podataka; na slici 149 predstavljen je dijagram baze podataka.
Aplikativni podsistem zadužen za import podataka u bazu realizovan je u vidu klijent-
server aplikacije i predstavlja važan segment jer omogućava automatizovani import
podataka u bazu. Na slici 148. prikazana je logička arhitektura sistema.
Slika 148. Logička arhitektura sistema Dunav arhiva
Za realizaciju korisničkog interfejsa korišćena je tehnologija ExtJS verzije 3.3. ExtJS
predstavlja javascript bazirani framework koji svojim širokim spektrom mogućnosti
omogućava kreiranje modernog i intuitivnog korisničkog interfejsa. Kao klijentska
aplikacija može se koristi bilo koji od opšteprihvaćenih, veb-browsera koji podržava
javascript. Korišćenje ExtJS-a za kreiranje korisničkog interfejsa omogućilo je punu
nezavisnost od veb-browser-a i klijentskog operativnog sistema. Za komunikaciju
između korisničkog interfejsa i sloja poslovne logike koriste se AJAX pozivi. Na taj
način se postiže maksimalna brzina prikaza podataka na korisničkom interfesju pošto se
na ovaj način osvežavaju delovi korisničkog interfesja koji su se menjali.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 267
Sloj poslovne logike realizovan je korišćenjem PHP tehnologije. PHP je izabran zbog
svoje portabilnosti i visokih performansi koje pruža, bez obzira na kom operativnom
sistemu radi (Linux,Widows). Za realizaciju ovog projekta korišćena je verzija 5.3 sa
standardnim setom klasa i funkcija. Za komunikaciju između sloja poslovne logike i
sistema za upravljanje bazom podataka korišćen je Microsoft PHP-SQL driver.
Korišćenje ovog driver-a daje najbolje performanse u komunikaciji sloja poslovne
logike sa bazom.
Aplikacija za import podataka kreirana je u .Net tehnologiji kao Windows klijentska
aplikacija. Aplikaciju će prevashodno koristiti operateri, čija će dužnost biti učitavanje
podatka u sistem. Aplikacija je kreirana iz više koraka:
• prvo je na osnovu usvojene XSD šeme kreirana pomoćna baza podataka; ovo
je urađeno uz pomoć open source softver XSD2DB
(http://xsd2db.sourceforge.net/), koji kreira SQL Server bazu podataka;
• uz pomoć softvera Altova Map Force kreirana baza podataka mapira se
šemom iz koje je kreirana; navedeni alat ima mogućnost kreiranja .Net C#
aplikacije koje će vršiti učitavanje XML instance kreirane na osnovu XSD
šeme u pomoćnu bazu podataka;
• ručna dorada kreiranog C# koda, kako bi se obezbedilo višestruko korišćenje
aplikacije i visok stepen automatizacije procesa; u ovom koraku su odrađene
i ostale funkcionalnosti aplikacije, koje pokrivaju ceo proces importa
podataka.
Masovni import arhivističke građe koji se isporučuje od isporučioca skenirane građe i
odgovarajućih metapodataka podeljen je u sledeće opracije:
• onemoguće se dolazni servisi, odnosno Apache web server kako bi bio
onemogućen pristup produkciji preko veb-aplikacije Dunav arhiva;
• uradi se backup produkcione baze podataka sa aktuelnim stanjem;
• uradi se privremena deaktivacija indexa na najbitnijim tabelama Dokument i
DokumentAtribut;
• izvrši se import metapodataka u inicijalnu bazu podataka; u ovom koraku se vrši
import iz XML fajla sa metapodacima u pomoćnu bazu podataka;
• vrši se verifikacija učitanih podataka:
o proverava se da li učitani podaci ispunjavaju definisana poslovna pravila
(učitani podaci sadrže sve šifarne podatke koji su već registrovani u
produkcionoj bazi, vreme skeniranja dokumenata nije starije od vremena
preuzimanja dokumentacije i druge provere poslovne logike);
o markiranje podataka koji ne ispunjavaju poslovna pravila;
o generisanje statističkog izveštaja koji kazuje o podacima koji ne
ispunjavaju poslovna pravila;
o operater na osnovu generisanog izveštaja odlučuje dali su podaci iz
privremene baze spremni za selidbu u produkcionu bazu i, ako jesu,
pokreće ovu akciju;
• nakon uspešne gornje akcije pokreće se kopiranje samih skeniranih podataka na
produkcioni server;
• uradi se rebuild i ponovna aktivacija svih index-a na najbitnijim tabelama
Dokument i DokumentAtribut na produkcionoj bazi.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 268
Zahtevi koje ovaj deo sistema treba da zadovolji jesu visoka dostupnost, pouzdanost i
velike performanse. Dostupnost se odnosi na procenat vremena u kom je sistem
dostupan za korisnika. Ona se postiže zaštitom sistema od padova, obezbeđivanjem
redundantnosti sistema u slučaju padova i segmentacijom sistema. SQL Server 2008 R2
i Windows 2008 R2 [51] nude više rešenja za ostvarivanje ovih zahteva. Database
mirroring se koristi za kreiranje konzistentne, sinhronizovane standby baze podataka.
Omogućava geografsku redudansu, zajedno sa enkripcijom mrežnog saobraćaja.
Database failover je gotovo trenutan (manje od tri sekunde). SQL Server 2008 podržava
tri database mirroring konfiguracije:
• asinhroni mirroring;
• sinhroni mirroring sa automatskim failover-om;
• sinhroni mirroring bez automatskog failover-a.
Koristi se i Log shipping koji predstavlja proces bekapovanja transaction log-a na
primarnom serveru i njegovo kopiranje na standby server, tako da, u slučaju otkaza
primarnog servera, standby server može da preuzme njegovu ulogu, za kreiranje
geografski udaljene standby baze podataka. Predstavlja jednostavno rešenje. Nedostatak
je što se postupak oporavka ne može obaviti potpuno automatski.
Da bi ovakav sistem odgovorio na zahteve u pogledu pouzdanosti, dostupnosti i
performansi, potrebno je vrlo precizno definisati njegove kapacitete. Planiranje
kapaciteta predstavlja proces definisanja potrebnog hardvera koji će moći da podrži
očekivano opterećenje sistema. Prilikom definisanja potrebnog kapaciteta sistema, treba
obratiti pažnju na sledeće:
• performanse koje se žele postići;
• planirano opterećene sistema;
• dizajn aplikacija (način pristupa podacima).
Prilikom planiranja kapaciteta u pogledu diskova treba obratiti pažnju na sledeće:
• izbor odgovarajućeg RAID nivoa utiče značajno na performanse prilikom
pisanja i čitanja podataka; kod slučajnog pristupa (čitanja), najbolje
performanse se postižu sa RAID 0 i RAID 10 nivoom; kod slučajnog upisa,
najbolje performanse se postižu sa RAID 0 nivoom;
• izbor RAID nivoa direktno utiče na broj ulazno/izlaznih operacija za
transakciju;
• broj diskova je važniji nego ukupna veličina storage-a; veći broj diskova (u
RAID-u) može značajno da poveća performanse sistema;
• prilikom utvrđivanja broja diskova, uzeti u obzir dve glavne komponente:
o operativni sistem (WIN 2008 R2) i SQL Server 2008 R2;
o baze podataka;
o broj potrebnih diskova za baze podataka zavisi od prostora koji je
potreban za smeštanje podataka i nivoa performansi koji se želi
postići; prostor koji svaka baza podataka zauzima, predstavlja sumu:
• potrebnog prostora za transaction log;
• potrebnog prostora za podatke;
• potrebnog prostora za indekse;
• potrebnog prostora za privremene podatke;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 269
Prilikom planiranja kapaciteta memorije treba obratiti pažnju na sledeće:
• kod sistema za upravljanje podacima memorija predstavlja veoma bitan
faktor; ovde važi opšte pravilo da što više memorije sistem ima to bolje
funkcioniše;
• minimum memory = (system memory) + (user memory) + (database process
memory)
System memory predstavlja količinu memorije koju zauzima OS i SQL Server.
User memory predstavlja količinu memorije za sve konkurentne korisnike (oko 500 KB
po jednom korisniku).
Database process memory = log area + database cache.
Cache size = (cache block size) * (number of blocks in cache).
Prilikom planiranja kapaciteta procesora treba obratiti pažnju na sledeće:
• sistemi za upravljanje bazama podataka predstavljaju procesorski veoma
intenzivne aplikacije;
• na osnovu odgovarajućih parametara izračunati zauzetost (opterećenost)
procesora; na osnovu proračunate zauzetosti, definisati potreban broj
procesora tako da opterećenost svakog pojedinačnog procesora ne bude veća
od definisane gornje granice (opterećenost procesora ne bi trebalo da bude
veća od 75 %).
Radi obezbeđivanja sigurnosti podataka, potrebno je minimum jednom dnevno praviti
backup baze. Ukoliko se poseduje neki namenski backup software može se praviti i
inkrementalni backup. Prilikom svakog novog punjenja baze podacima, potrebno je
napraviti full - backup baze, zatim napraviti restore baze radi provere backup-a i nakon
verifikacije backup-a pristupiti učitavanju novog seta podataka. Periodično (jednom
mesečno) testirati backup i restore plan na testnom okruženju.
Prilikom realizacije hardverske strukture sistema korišćeno je odgovarajuće virtuelno
okruženje. Za postizanje maksimalnih performansi baza podataka i arhivirani podaci
(slike) su smešteni na storage-u koji je pravilno profilisan u skladu sa zahtevim i
načinom rada aplikacije. Za mrežno povezivanje obezbeđena su dva interfesja od 1Gb/s
koji su povezani u „team” čime bi se obezbedila veća pouzdanost i dostupnost sistema,
kao i veći mrežni protok.
Za potrebe rada aplikacije su obezbeđeni serveri sledećih karakteristika:
Hardware.
• CPU – 2 jezgra sa min 2GHz x64;
• RAM – 16GB;
• HDD – 40GB za instalaciju operativnog sisitema SQL-a (prostor za bazu i
smeštanje podataka, potrebnio je obezbediti dovoljno prosotora u skladu sa
veličinom arhiva uz definisanje adekvatne rezerve za budući rast);
• Network – 2 x 1Gb/s interfejs.
Sistemski softver.
Win. server 2008 R2 SE - x64, SQL server 2008 R2 SE, x64, Lamp server 1.7.3
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 270
Slika 149. Dijagram baze podataka sa ključevima i bez predstavljanja atributa
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 271
6.6.2.5 Fizička arhitektura klirinške kuće
Sistem je realizovan sa Hewlet Packard, APC i Cisco hardverskim komponentama. Na
osnovu proračuna i procene ustanovljena je hardverska struktura koja bi u potpunosti i
na optimalan način zadovoljila potrebe sistema. Predloženi sistem se sastoji od tri
podsistema: Produkcionog sistema, Rezervnog sistema i Testnog sistema, što u
potpunosti zadovoljava stroge uslove sistema u finansijskoj industriji. Sistem je
realizovan da bude izbegnuta pojava single point of failure na pimarnoj i rezervnoj
lokaciji. Testni sistem ima zadatak za proveru funkcionalnosti komponenata sistema
tokom životnog ciklusa produkcionog sistema.
Na slici 150. predstavljena je jedna od mogućih realizacija Produkcionog sistema. Pored
ove, moguće su i druge fizičke realizacije sistema, što zavisi od poslovne politike
vlasnika i propisanih sistemskih normi. Radne stanice koje pristupaju portalu sistema za
administraciju i monitoring nalaze se u posebnoj demilitarizovanoj zoni. Fajl adapter se
nalazi u istoj demilitarizovanoj zoni koja na slici nosi naziv Workstations. Banke koje
pristupaju sistemu su na komunikacionoj infrastrukturi u zoni koja je na slici nazvana
Outside što treba da označi da se svi korisnici koji pristupaju na taj način smatraju
potencijalno opasnim po sistem.
U posebnoj demilitarizovanoj zoni Inside 2 nalaze se aplikativni serveri koji su od
ostalog dela sistema odvojeni firewall-om na kome je postavljana maksimalna moguća
zaštita. Transportne komponente su smeštene na servere Transport 1 i Transport 2 zbog
svoje specifične uloge primopredaje sadržaja u dve zone. Prema spoljašnosti su u
DMZ1 u koju mogu da se prime poslati fajlovi iz Outside zone a prema DMZ2 sa
drugim komunikacionim resursima vrši se predaja sistemu. Na taj način se postiže filter,
koga je veoma teško proći, pošto je jedini sadržaj koji može da prođe verifikovana i
autorizovana adresibilna poruka koja sadrži poslovnu logiku. U najzaštićenijoj zoni
nalaze se sistemi za procesiranje i skladištenje, kao i ostali pomoćni sistemi
(redundantni domen kontroleri, certifikaciono telo i nodovi prema testom, rezervnom i
sajtu u slučaju nemogućnosti rada primarnog sajta u katastrofalnim uslovima). Disaster
sajt ima posebno planiranu komunikacionu i serversku infrastrukturu.
Sistem za kliring čekova [215] pušten je u produkciju 09.05.2005. godine i prve godine
u radu imao je zero downtime, što dodatno potvrđuje visokopouzdan i efikasan rad
sistema.
Iz svega iskazanog sledi da se realizacija SEPA platnog sistema, recimo za Credit
Transfers, korišćenjem navedenih standardnih komponenata sistema, sa stanovišta
procesiranja poruka, uz korišćenje odgovarajućih definisanih ISO 20022 šema se svodi
na definisanje PDWF i DDF specifikacija koje opisuju Credit Transfers po
dokumentima:
• SEPA CREDIT TRANSFERS, SCHEME ROOLBOOK, Doc: EPC125-05
(Version 2.0. Approoved);
• Credit Transfers and Direct Debits, Messge Flows UNIFI (ISO 20022), July
2006.;
• Payments Standards – Clearing and Settlement, UNIFI (ISO 20022) Message
Definition Report (Approved by UNIFI Payment SEG on June 2006. – Edition
July 2006.).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 272
Slika 150. Moguća struktura i međuzavisnost
hardverskih komponenata produkcionog sistema
Sa stanovišta ostalih elemenata sistema, sprovedena je standardna procedura
implementacije potrebnih resursa. Ukoliko je već postojala implementacija nekog
drugog SEPA platnog sistema (recimo Direct Debit ili implementacija SEPA Cards
Frameworka), onda je samo potrebno izvršiti eventualnu dopunu resursa (na primer
hardverski – servera zbog moguće ili željene povećane potrebe procesorske snage) i
implementirati komponente Credit Transfersa. Isto tako moguća je implementacija e-
invoicinga kada budu bili u SEPA programu.
Polazišta od kojih se utvrđuje SEPA kompatibilnost dati su u Prilogu 7: „Ispunjenost
EPC regulative“, kao i ispunjenost osnovnih principa banke za međunarodna poravnanja
(BIS) koje sistematski važni sistemi moraju da ispune i koji su dati u Osnovnim
principima za evro platne sisteme na malo.
Prilikom realizacije klase SEPA platnih sistema, dobija se niz komplementarnih
prednosti, standardizovan razvoj i interoperabilnost elektronskog poslovanja platnih
sistema.
6.7 Analiza postignutih rezultata modelom
Za platne sisteme u Srbiji od izvanrednog značaja je interoperabilnost sa globalnim
međunarodnim standardima. Do sada su razmatrani samo aspekti sa stanovišta
finansijske industrije, međutim, postoje i drugi, sa stanovišta IT industrije.
Kvalifikacijom platnih sistema, koji su izrađeni od strane domaćih IT kompanija, u red
kompatibilnih sa svetskim standardima, umnogome se povećavaju izvozne šanse na
globalno tržište. To je od izvanrednog značaja za prodor domaćih ideja u oblasti IT
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 273
industrije van naših granica. Do sada nije bilo nikakvih ispoljavanja naše IT industrije u
tom smislu, a pretpostavka je da u tom domenu struktura IT eksperata sa našeg područja
ima šta da prikaže. Kvalifikacija domaćih platnih sistema kao kompatabilnih sa
globalnim standardima ima još jedan aspekt koji je od velikog značaja. On se odnosi na
pružanje usluga procesiranja subjektima u regionu, ali i šire. Na taj način, koristeći
svoje geopolitičke prednosti, industrijski segment koji bi se bavio procesiranjem zauzeo
bi značajno mesto u društveno-ekonomskom pogledu. Ukoliko bi došlo do takve
afirmacije, razmere efekta bi se mogle meriti sa onim koji ima tradicionalno bankarstvo
u Švajcarskoj, automobilska industrija u Nemačkoj i slično. Potrebno je naglasiti da
prodor u IT sektor koji se bavi sistemima finansijske industrije nije lak. I vremenski je
relativno dug. Na osnovu iskustava uspešnih svetskih kompanija, put do uspeha u tom
domenu meri se decenijama.
Generalni aspekti koji čine interoperabilnom SEPA klirinšku kuću Udruženja banaka
Srbije - Klirinšku instituciju banaka jesu:
• izgrađen je platni sistem nad adekvatnim skupom ISO standarda;
• sistem se uklapa u SEPA viziju;
• sistem se uklapa u SEPA Delivery Plan (EPC timing and milestones);
• dobija se mogućnost pouzdane izgradnje adekvatne infrastrukture nakon
uspostavljanja celokupnih normativa određene oblasti u finansijskoj industriji
što je jedan od postulata EPC-a;
• data je mogućnost izbora isporučioca IT podrške u smislu koji promoviše EPC
(Promotion of the optimal balance between cooperation and competition);
• minimiziraju se ulaganja kod korisnika u adaptiranje ili migraciju;
• postoji mogućnost potpune pokrivenosti tržišta plaćanja;
• postignuta je IT transparentnost u odnosu na finansijski sistem koji se želi
realizovati;
• prirodna i adekvatna raspodela rola i odgovornosti za delove finansijskih sistema
u okviru kompaktnih celina determinisanih zakonskim normama;
• velika prilagodljivost sistema za procesiranje bazirano na transportnom sistemu,
DDF, PDWF i BizTalk-u sa A4SWIFT-om;
• sistemi za transport i procesiranje ostavljaju mogućnost za buduću nadgradnju
koja zavisi isključivo od opcija implementacije i stepena razvoja tehnologije;
• mogućnost prenosa tehnologije prostim prenosom adekvatnih standardnih znanja
iz propisanih oblasti;
• mogućnost uvođenja inovacija u finansijskoj industriji.
Elementi interoperabilnosti kod transporta poruka
Adekvatna transportna infrastruktura uopšte, u svim privrednim oblastima je osnova na
kojoj mogu da se grade uspešni i produktivni sistemi. Transportnu infrastrukturu u
oblasti finansijke industrije predstavljaju sistemi koji su sposobni da na siguran,
bezbedan, neporeciv, lak, brz i jeftin način prenesu finansijske informacije sa jedne
tačke finansijskog polja na drugu tačku. Izgrađeni sistem ima sledeće elemente SEPA
kompatibilnosti:
• izgrađen je vlasnički transportni sistem za prenos determinisanih poruka;
• izgrađeni vlasnički transportni sistem u sebi sadrži sve potrebne elemente za
međusobnu komunikaciju između supersistema i subordinate sistema na
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 274
standardnim resursima koji obezbeđuju mogućnost komunikacije, kao i
mogućnost korišćenja mobilne i satelitske komunikacione infrastrukture;
• transportni sistem obezbeđuje i rutiranje poruka po zadatim šemama za rutiranje
poruka;
• transportni sistem sadrži mogućnost izgradnje simetričnih i asimetričnih
codera/decodera koji obezbeđuju različite procese potrebne prilikom transporta
poruke kod sendera/receivera;
• transportni sistem je obezbeđen savremenim sistemima za bezbednost i zaštitu
kanala i podataka;
• sistem za bezbednost i zaštitu podataka omogućio je višestepeno potpisivanje
sadržaja u odnosu na vlasništvo nad podacima kao i u odnosu na role u sistemu;
• transportni sistem omogućio je LEGO efekat, što ga čini visokopristupačnim u
izgradnji mreža za transport poruka, ali i adaptivnim u odnosu na okolnosti koje
mogu da nastupe u toku produkcije (geopolitičke izmene, organizacione izmene,
strukturne promene sistema);
• transportni sistem nije zavisan od bilo koje strukture (vlasničke strukture,
geopolitičke i ostalih mogućih struktura), zavisan je jedino od organizacione
strukure koju propisuje nadležni organ (SEPA, centralna banka države, banka);
• mogućnost izgradnje novih korporativnih, bankarskih, centralno bankarskih,
državnih i međudržavnih transportnih mreža sa odgovarajućim centrima za
procesiranje, ali i integraciju adekvatnih postojećih sistema;
• mogućnost komunikacije entiteta sa nodovima sistema, kao i entiteta
međusobno, bez obzira na nacionalnu pozicioniranost ali u okvirima koje zadaju
odgovarajući odgovorni autoriteti predmetne oblasti.
Elementi interoperabilnosti kod pretprocesiranja i procesiranja
Sistemi za procesiranje zadovoljavaju sledeće elemente SEPA interoperabilnosti:
• koriste se definisane SEPA šeme ili adaptirane custom šeme uz adekvatnu
konverziju u odnosu na ciljni sistem (receiver);
• moguća je izgradnja dodatnih logičkih podsistema zadate namene koji
zadovoljavaju posebne aspekte ili lokalne osobenosti, što je izričit zahtev za
kompatibilnost;
• sistem za procesiranje omogućava efekat slagalice što ga čini adaptivnim u
odnosu na okolnosti koje mogu da nastupe u toku produkcije (definisanje novih
primena sistema, promena namene ili dopuna funkcionalnosti realnog sistema);
• mogućnost adaptiranja sistema na ostale regionalne/lokalne sisteme za
procesiranje.
6.7.1 Eksperiment u klirinškoj kući
Postavljeni zadatak za eksperiment: napraviti fizički model sistema (prototip) koji će
dokazati da je moguće izgraditi sistem baziran na standardnim adresibilnim porukama,
koji sadrži i elemente izrađene različitim vrstama alata prisutnim na tržištu, kao i javno
dostupnim alatima koji su izrađeni za specijalnu namenu, za potrebe izvršavanja poruka
više sistema, određenim jednim standardom: kredit transfer (u realnom veremenu ili
odložen) i direct debit, odnosno tri sistema u jednom: RTGS, credit transfer i direct
debit; sistem izvesti jednom porukom, a potrebno je opisati i sve prateće poruke koje iz
osnovne poruke proističu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 275
Opis rešenja: Banka šalje poruke sa odgovarajućom naznakom u tagu 113 bloka 3.
Ukoliko je tag 113 manji od 0100, onda poruka pripada RTGS sistemu i to tako da,
ukoliko je vrednost između 0050 i 0100, poruka se odbija ukoliko nema sredstava za
izvršenje; ukoliko je vrednost taga 113 manja od 0050, onda se poruka smešta u red za
čekanje dok se ne steknu uslovi za njeno izvršenje ili do njenog opoziva. Ukoliko je
vrednost taga 0100, onda je poruka kreditna i pripada kliring sistemu, a njeno izvršenje
se obavlja po pravilima kliringa. Ukoliko je vrednost tag 113 jednaka 0101, onda je
poruka debitna i pripada kliring sistemu, a njeno izvršenje se obavlja po pravilima
kliringa. Nizovi „{1:F01“, „{2:“, „{3:“, „{4:“ su oznake blokova. Tag „:20:“ je
referenca poruke, a u tagu „:23:“ je oznaka da li je transakcija inicirana od korisnika
sredstava ili od dužnika. Ukoliko je vrednost ovog taga CREDIT inicijator transakcije je
dužnik. Tag „:21:“ predstavlja referencu transakcije u okviru poruke, a tag „:32B:“
iznos transakcije u okviru instrukcije, dok tag „:32A:“ predstavlja sumu transakcija.
Tagovi „:26T:“, „:71A:“ imaju konstatne vrednosti u slučaju standarda u Republici
Srbiji. Ostali elementi prva tri bloka su po pravilima NBS. Kod prva dva primera imamo
da su tagovi „:50K:“ - račun nalogodavca (dužnika), „:59:“ - račun korisnika, a u sva tri
primera da su tagovi „:53A:“, odnosno „:54A:“ računi banke nalogodavca, odnosno
banke korisnika. Kod trećeg primera imamo da tagovi „:50K:“ i „:59:“ sadrže
informacije o računima nalogodavca i klijenta.
Primeri realnih poruka primenjenih u ekserimentu
Primer 1: MT102 real time („brza dvojka“ Narodne banke Srbije)
{1:F01KOBBRSBGAXXX1234123456}{2:I102NBSRRSBDXIPSN}{3:{113: 0030}}{4:
:20:8921600003495641
:23:CREDIT
:26T:REF
:71A:SHA
:21:08700081623194
:32B:RSD2083,33
:50K:/160000000000734948
Jedinstvo d.o.o.
DUNAVSKA 15
Kladovo
:59:/205000000002006630
STR KOMISION XXL
Beograd
:70:SIF-241
:77B:Obustave iz zarada
:32A:100112RSD2083,33
:53A:/D/908000000001600187
DBDBRSBG
:54A:/908000000002050170
KOBBRSBG
-}
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 276
Primer 2: MT102 credit transfer
{1:F01SBPORSBGAXXX1234123456}{2:I102NBSRRSBDXIPSN}{3:{113: 0100}}
:20:8921600003495772
:23:CREDIT
:26T:REF
:71A:SHA
:21:08700081658015
:32B:RSD20000,00
:50K:/160000000004209779
RADNJA DOO
GOSPODARA VUCICA 45
Beograd
:59:/200004350010200082
JP PTT SRBIJA
BEOGRAD
:70:SIF-221
PBO-974210111180000811
:77B:Avans za postanske usluge
:32A:100112RSD20000,00
:53A:/D/908000000001600187
DBDBRSBG
:54A:/908000000002000118
SBPORSBG
-}
Primer 3: MT102 direct debit (kliring čekova)
{1:F01KUBKRS22AXXX1234123456}{2:I102NBSRRSBDXIPSN}{3:{113: 0101}}{4:
:20:890335000964511c
:23:CHQB
:26T:REF
:71A:SHA
:21:668145
:32B:RSD2350,00
:50K:/908000000003250157
NONAME
:59:335000000000377388
STR KOMISION, JOVIIC JANKO
:70:SIF-283
PBZ-0000004243101
PBO-1705073351700
REF-
:77B:ISPLATA PO CEKU
NON
TRN-0300100010929
:32A:070517RSD2350,00
:53A:/C/908000000003350164
MBSORS22
:54A:/D/908000000003250157
KUBKRS22
:72:/BNF/
-}
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 277
Navedeni eksperiment je izveden na prototipu koji je prikazan na Tehničkom fakultetu u
Novom Sadu.
Posledice rezultata eksperimenta su sledeći:
• uvedena je real time transakcija u RTGS sistem u Srbiji korišćenjem MT102
poruke koja je standardom predviđena za kliring, odnosno odloženo izvršenje;
• kliring čekova se obavlja porukom MT102 za credit transfer je direct debit
sistem jer transakcije inicira poverilac, pa samim tim ima mogućnost da
procesira i credit transfer poruke;
Adaptacijom sistema za kliring čekova uvođenjem još jedne klase operacija u sistem,
dobija se mogućnost procesiranja i real-time transakcija posredstvom RTGS sistema
Narodne banke Srbije.
6.7.2 Rezultati empirijskih merenja
Laboratorijska merenja na podsistemu za razmenu poruka i podsistemu za procesiranje
pokazala su da mogu da zadovolje različite zahteve u odnosu na sposobnost
komunikacionog kanala i broja transakcija koje sistem treba da obradi.
Prvo su vršena merenja koja bi pokazala zavisnost performansi od broja udaljenih
korisnika. Pokazalo se da je uticaj na performanse pet udaljenih korisnika koji
istovremeno konstantno šalju poruke sa finansijskim transakcijama veličine 10 kb kroz
Frame Relay link od 64 kb/s prema centralnoj lokaciji manji od 3%. Sa 25 udaljenih
korisnika uticaj na performanse sistema nije se drastično povećao, do 5% smanjenja
performansi. Na 40 udaljenih korisnika procenat uticaja na performanse sistema
povećao se ali je poraslo procesorsko zauzeće servera na centralnoj lokaciji.
Dodavanjem još jednog servera na centralnoj lokaciji za procesiranje uticaj na
performanse vratio se na pogoršanje performansi za 5%. Poboljšanjem komunikacione
sposobnosti Frame Relay komunikacione infrastrukture povećao se obrađeni broj
transakcija, ali su odnosi ostali približno isti. Isti rezultat je postignut i uvođenjem po
pet korisnika sa komunikacionom sposobnošću od 4 kb/s, 16 kb/s, 32 kb/s, 64 kb/s i 128
kb/s. Rezultati navode na zaključak da se dodavanjem servera na centralnoj lokaciji
može rešiti pad performansi procesiranja, a da se povećanjem komunikacionih
kapaciteta rešava problem željenog broja finansijskih transakcija. Posebno je potrebno
navesti da je vrednost finansijskih transakcija već sa jednim udaljenim korisnikom
dostizala monetarne kapacitete snažnijih monetarnih sistema sa Real Time
transakcijama u vremenskom periodu od osam radnih sati sistema. Republika Srbija
dnevno retko prelazi 1.000.000 Real Time i odloženih transakcija. Naknadno opisana
merenja vršena su sa jednom udaljenom stanicom i jednim serverom na centralnoj
lokaciji da bi se videla sposobnost sistema za prenos i procesiranje poruka. Ogled koji je
nadalje vršen podrazumevao je sledeće: potpisivanje poruke na udaljenoj lokaciji i
slanje potpisane poruke sa prijemom ACK/NAK poruke, na centralnoj lokaciji prihvat
poruke, proveru potpisa, pripremanje i vraćanje ACK/NAK poruke, skladištenje poruke
u centralnu bazu podataka, parsiranje i proveru finansijske transakcije (semantiku
poruke i proveru poslovnih pravila), skladištenje finansijske transakcije u bazu podataka
za procesiranje, formiranje, potpisivanje i slanje poruke prihvatanja na obradu i poruke
sa rezultatima obrade, kao i formiranje, potpisivanje i slanje poruku drugoj strani u
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 278
finansijskoj transakciji. Za inicijalizaciju poslovnog procesa korišćena je hibridna
MT102 (Real Time) poruka ISO15022 standarda.
Slika 151. Zavisnost broja transakcija u poruci i propusnog opsega (msg/h)
Slika 151. daje prikaz zavisnosti broja poruka, broja finansijskih transakcija (FT) u
porukama u odnosu na propusnu moć komunikacionog kanala. Apscisa je broj
finansijskih transakcija po poruci, ordinata je broj poruka na sat (msg/h). Jasno je da je
broj prosleđenih poruka proporcionalan kapacitetu komunikacionog kanala, bez obzira
na veličinu poruka. Pri prosleđivanju poruka sa manjim brojem transakcija razlika u
broju poruka je veća nego pri prosleđivanju poruka u kojima je pakovan veći broj
transakcija u zavisnosti od propusne moći kanala. Jasno je da, iako je manji broj poruka,
veći je ukupan broj finansijskih transakcija ukoliko je pakovano više finansijskih
transakcija po poruci, i da je veći stepen iskorišćenja kanala ukoliko poruke sadrže više
finansijskih transakcija. Na apscisi je dat i prosečan broj finansijskih transakcija za
svaku veličinu poruke. Povećanjem broja transakcija po poruci, do određene granice, i
povećanjem komunikacione sposobnosti kanala postiže se optimalni kapacitet potreban
za razmenu elektronskih dokumenata. Na slici 152. na ordinati je prikazan broj poruka
na sat i prikazano merenje u odnosu na veličinu poruke i komunikacionu sposobnost
kanala.
Slika 152. Količina transportovanih finansijskih transakcija (FT)
u zavisnosti od propusnog opsega i veličine poruka
Na slici 153. izdvojeni su rezultati šest merenja sa porukama sa fiksiranih 100 FT i 130
FT u zavisnosti od propusnog opsega komunikacionog kanala. Apscisa je
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 279
komunikaciona sposobnost kanala, a ordinata broj finansijskih transakcija na sat (FT/h).
Pakovanjem od 130 FT na komunikacionom linku od 512 kb/s u toku jednog sata
izmereno je oko pola miliona FT.
Slika 153. Količina transportovanih finansijskih transakcija
u zavisnosti od veličine i propusnog opsega FR (FT/h)
Rezultati merenja na slikama 151. - 153. poslužili su bankama u Srbiji da odrede kakve
kapacitete komunikacione infrastrukture treba zakupiti za poslove sa klirinškom kućom.
6.7.3 Statistika rada sistema Udruženja banaka Srbije
U ovom poglavlju je prikazana statistika rada sistema „Serbian Clearing House“ u
produkciji. Statistika je prikazana u RSD (dinarima Republike Srbije), dok je autor ovog
rada bio odgovoran za njegovo funkcionisanje.
Broj transakcija u toku prve godine (od 09.05.2005. do 09.05.2006.) posle nove godine
izašla je nova zakonska regulativa koja je ograničila upotrebu čekova za odloženo
plaćanje na više meseci. Otuda i pad u 2006. godini, prikazan na slici 154.
Slika 154. Broj finansijskih transakcija po godinama
Slika 155. pokazuje odnos finansijskih transakcija po finansijskom obimu i u odnosu na
sliku 156. Nije toliko izražen pad u 2006 godini jer je srednja vrednost transakcije
očigledno povećana i na taj način ublažen zakonski okvir koji je smanjio broj
finansijskih transakcija. Na slici 155. vidljivo je da se u poslednje tri praćene godine
iznos transakcija gotovo izjednačio u obimu u odnosu na prvu godinu rada sistema.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 280
Slika 155. Iznos u RSD transakcija sa čekovima po godinama
Na slici 156. prikazan je rad u prvih 12 meseci rada sistema. Vidi se drastičan pad
realizovanih finansijskih transakcija od meseca januara 2006 godine i da je broj
transakcija, uvođenjem nove zakonske regulative, sveden na trećinu.
Slika 156. Broj čekova u prvih 12 meseci rada sistema
Slika 157. prikazuje da je do pada u finansijskom obimu transakcija na trećinu došlo u
periodima decembar 2005. godine i januar 2006. godine i da je u januaru sveden na
trećinu.
Slika 157. Iznos u RSD transakcija sa čekovima u prvih 12 meseci rada
Sistem je projektovan da ubrzo nakon puštanja u produkciju za kliring čekova preuzme
optimalno i dnevno oko 250.000 finansijskih transakcija - platnih naloga čija vrednost
ne prelazi 5.000 RSD. Pošto se to u međuvremenu nije desilo, u produkciji je sistem bio
uposlen samo 3%. Da je sistem bio optimalno korišćen od puštanja u produkciju od
09.05.2005. do 31.12.2010., broj finansijskih transakcija bio bi 817 miliona sa
finansijskom vrednošću oko 2.500 milijardi RSD. Projektovani maksimalan broj
finansijskih transakcija koje sistem može da obradi iznosio bi oko dve milijarde u
navedenih šest godina a očekivana vrednost finansijskih transakcija bila bi oko 6.000
milijardi RSD (tabela 22.).
UBS KIB
(od 05.2005 do 12.2010)
Procenat
projektovanog
kapaciteta
Broj finansijskih
transakcija
(u milionima)
Finansijska vrednost
transakcija
(u milionima RSD)
Uposlenost u produkciji 3% 61 182,772
Optimalni kapacitet 40% 817 2,436,955
Maksimalni kapacitet 100% 2041 6,092,388
Tabela 22. Statistika klirinške kuće Udruženja banaka Srbije*
(* Objavljeno od strane Udruženja banaka Srbije na izlaganju na bankarskom skupu BankInfo 2006 na Paliću)
6.7.4 Simulaciona analiza
Testiranje transportne komponente i sistema za pretprocesiranje, procesiranje i
postprocesiranje vršeno je simulacijom sistema, zbog potrebe da se odredi garantovana,
potrebna i dovoljna brzina (propusni opseg) linka za prenos SWIFT poruka koji
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 281
pojedinačne banke trebaju da zakupe prema Klirinškoj instituciji banaka - KIB-u,
propusnog opsega i sistema za obradu u KIB-u.
Za potrebe testiranja korišćena su dva računara i FR link. Računari su simulirali
klijentsku (banke) i serversku (KIB) stranu sistema. FR link su simulirali par Cisco 805
routera uvezanih back-to-back. Na taj način je dobijen kontrolisani propusni opseg.
Testiranje je vršeno za različite veličine poruka (broj čekova u poruci) i različite
propusne moći linka. Na početku testa ustanovljeno je da i za najveće kapacitete linka
prema KIB-u sistem za obradu KIB-a može da procesira u realnom vremenu i da test
može da se nastavi samo menjanjem parametara sistema za transport poruka. Testiran je
transport poruka male dužine (od 1KB do 8KB) i poruka srednje dužine (24KB i
32KB).Testirani su sledeći parametri transporta:
• broj prenetih poruka u toku jednog sata;
• količina prenetih poruka (u MB) za vreme od jednog sata.
Pojedinačni rezultati testa predstavljeni su u dokumentu o redovnom testiranju
transportne komponente, sa obeleženim mestom, datumom i vremenom testiranja, kao i
sa potpisom izvođača testa i rukovodioca projekta.
Početni uslovi testa specificirani su server i klijenti, kao i specifikacija odgovarajuće
komunikacione infrastrukture:
• Server: Celeron 1.8 GHz; 1.00 GB RAM;
• Client: Pentium III 1.2 GHz; 256 MB RAM;
• FR 32 KBPS;
• HTTPS.
Specificirani parametri svakog pojedinačnog testa su:
• br. čekova;
• br. poruka;
• br. ciklusa;
• veličina poruke u KB.
Beleženi su očekivani rezultati testa, tok testiranja sa vremenom početka i vremenom
završetka svakog pojedinačnog testa, kao i rezultati svakog pojedinačnog testa po
pitanju vremena potrebnog da se opit izvrši, kao i veličini materijala, odnosno podataka
koje je potrebno transportovati sa klijentskih radnih stanica, pretprocesirati, procesirati i
distribuirati sve potrebne odgovore za zahtevane transakcije. Zaključak se sastojao od
brzine obrade u broju poruka, odnosno transakcija na sat, kao i veličine postignutog
opsega procesiranja u megabajtima.
Kako bi dobijeni rezultati bili što pregledniji, podaci su smešteni u tabele i predstavljeni
graficima. Sastavljena su dva dokumenta. Prvi dokument predstavlja tabelarne rezultate
testiranja za poruke male dužine u serijama velike dužine (1000 poruka). Drugi
dokument predstavlja tabelarne rezultate testiranja poruka srednje dužine u velikim
serijama (2000 poruka).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 282
Na osnovu testiranja i predstavljenih rezultata i grafika, može se jednostavno odrediti
potreban propusni opseg linka u zavisnosti od iskazanih potreba finansijskih institucija.
Iz rezultata testova se vidi da je moguć izbor iz spektra mogućih linkova u odnosu na
način na koji banka predviđa da pakuje svoje poruke (broj čekova po poruci) i
mogućnost izbora FR linkova u odnosu na kvalitet usluga u odnosu na cenu koju KIB
želi da ponudi bankama.
Rezultati testova naživo (u realnim uslovima) iz banaka prema KIB-u na realnom FR
linku pokazali su sledeće:
1. prilikom testiranja jedne banke na FR 64 kbps (LHB banka) dobijeni su
sledeći rezultati : brzina transporta je preko 10.000 poruka srednje dužine (80 čekova u
poruci) u toku jednog sata;
2. prilikom testiranja dve banke na FR 64 kbps (LHB banka i Delta banka)
dobijeni su sledeći rezultati : brzina transporta je preko 15.000 poruka srednje dužine
(80 čekova u poruci) u toku jednog sata na strani KIB-a – odnosno, po približno 8.000
poruka iz svake banke; do rezultata se došlo tako sto su sa dve lokacije (iz dve banke)
poslate serije poruka istovremeno i merena je brzina prijema poruka u KIB-u.
Do rezultata 1 i 2 smo došli eksperimentalnim putem i to na linku kod koga nije
kontrolisana propusna moć pa je u ovom slučaju zbog stanja na FR mreži dozvoljavana
maksimalna moguća propuusnost od strane Telekoma.
Rezultat testa je preporuka bankama za angažovanje FR linkova:
• banke sa malim intenzitetom saobraćaja
FR 32 kbps uz prilagođavanje slanja u vremenu i broja čekova u poruci;
• banke sa sednjim intenzitetom saobraćaja
FR 32 kbps uz prilagođavanje slanja u vremenu i broja čekova u poruci;
• banke sa velikim intenzitetom saobraćaja
FR 64 kbps uz prilagođavanje slanja u vremenu i broja čekova u poruci;
• KIB
na strani KIB-a preporučeno je da se uspostavljaju 2-megabitni linkovi do FR
mreže, i to jedan više od minimalnih zahteva zbog balansiranja saobraćaja,
redundantnosti i efikasnijeg iskorišćenja slobodnih resursa FR mreže.
6.7.5 Implementaciona analiza
Predloženo rešenje je implementirano u Udruženju banaka Srbije na dva sistema:
sistema za kliring čekova i sistema direktnog zaduženja. Implementirano je na Microsoft
platfomi i „Sebian clearing house“ i prvo je rešenje klirinške kuće (ACH) koje je u
svetu implementirano na Microsoft tehnologijama. U novembru 2005. godine je dobilo
nagradu “European Banking Technology Award 2005” britanskog časopisa „Banking
technology“, od eminentnih stručnjaka najvećih evropskih banaka i finansijskih
korporacija: McKinsey & Company, Deutche Bank, Royal Bank of Scotland, BNP
Paribas i JPMorgan.
Korišćene implementacione tehnologije su: Windows operativni sistemi, Windows
Communication Foundation Framework, Internet Information Services, MS SQL
Server, MS BizTalk Server, Microsoft alati i razvojna okruženja. Svi alati i razvojna
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 283
okruženja pružaju raznovrsne mogućnosti i omogućavaju kombinovanje u realizaciji
složenih scenarija integracije uz komforne korisničke interfejse Zaključak je da
Microsoft tehnologije omogućavaju razvoj softverskih komponenti koje međusobno
odlično sarađuju i da je Micrsofot platforma pogodna zarazvoj aplikativnih sistema i
rešenja iz oblasti elektronskog poslovanja platnih sistema.
6.7.6 Analiza efekata primene i fleksibilnosti modela
Analiza efekata primene i fleksibilnosti modela integracije elektronskog poslovanja
platnih sistema obuhvata sledeće aspekte analize:
• analiza efekata primene predloženog rešenja integracije na elektronsko
poslovanje učesnika u procesima platnih sistema;
• analiza zahteva rešenja u pogledu hardverske i softverske infrastrukture;
• analiza stepena fleksibilnosti predloženog modela i mogućnosti prilagođavanja
novim zahtevima;
Najznačajniji efekat primene predloženog rešenja integracije elektronskog poslovanja
platnih sistema jeste efikasnije, pouzdanije i semantički interoperabilno elektronsko
poslovanje oslonjeno na standard ISO/IEC 15944-4 2007. Primena predloženog modela
integracije unapređuje efikasnost elektronskog poslovanja na taj način što se
standardizuje zadavanje, implementacija i eksploatacija u automatizovanoj razmeni
podataka putem standardizovanih adresibilnih poruka sa poslovnom logikom. Primena
standardizovanih komponenata je osnovni efekat primene predloženog rešenja
integracije, što kao posledicu ima i propratne efekte. Najznačajniji propratni efekti su:
olakšana mogućnost integracije sa drugim poslovnim sistema elektronskog poslovanja,
standardizovano uvođenje novih funkcionalnosti i novih sistema elektronskog
poslovanja, smanjenje angažovanja resursa na realizaciji i smanjenje angažovanja
sredstava potrebnih za realizaciju.
Važna osobina predloženog modela integracije elektronskog poslovanja platnih sistema
jeste pouzdanost i skoro potpuna eliminacija grešaka tokom razmene i procesiranja
podataka. Predloženi model podrazumeva standardizovanu razmenu podataka,
standardizovano pretprocesiranje i procesiranje po dokumentima koja propisuje
nadređeni sistem, a koji je u krajnjoj instanci propisan od strane jednog supersistema
koji je u svom domenu odgovoran za pravilno funkcionisanje svih podsistema i koji je
nadležan za propisivanje načina ažuriranja i razmene podataka.
Predloženo rešenje omogućava semantički interoperabilno elektronsko poslovanje
platnih sistema zasnovanih na Resurs – Event – Agent standardu ISO/IEC 15944-4
2007, jer je bazirano na zajedničkom informacionom modelu. Zajednički informacioni
model zasnovan je na zajedničkom modelu podataka. Zajednički model podataka
razvijen je na bazi zajedničkog deljenog rečnika i domenske ontologije. Domenska
ontologija je osnov za konzistentno tumačenje značenja metapodataka i vrednosti
podataka.
U pogledu hardverske i softverske infrastrukture, predloženo rešenje podrazumeva
korišćenje informacione infrastrukture standardizovane arhitekture prilagodljive
savremenim paradigmama kao što jesu infrastruktura privatnog i javnog oblaka,
virtualizacija, razvoj rešenja agilnim metodologijama. To znači da korisnici
predloženog rešenja nisu u obavezi da nabavljaju dodatni hardver, kao ni da kupuju
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 284
softverske licence, već da sigurne servise mogu pribavljati i od specijalizovanih
procesorskih agenata. Servisno orijentisana arhitektura, na kojoj je bazirano rešenje,
omogućava integrisanje aplikacija razvijenih na različitim platformama. Zaključak je da
predloženo rešenje ne zahteva razvoj novih lokalnih aplikacija i baza podataka, već
naprotiv – omogućava korišćenje postojećih informacionih sistema i upotrebu
standardizovanih komponenata elektronskog poslovanja platnih sistema.
Predloženo rešenje poseduje visok stepen fleksibilnosti i nije unapred determinisano
brojem učesnika u integracijama elektronskog poslovanja platnih sistema. Fleksibilnost
je osnovna karakteristika servisno orijentisane arhitekture na kojoj je ovo rešenje
zasnovano. Kako postojeće, tako i nove lokalne aplikacije mogu koristiti ovo rešenje,
dodavanjem reference na odgovarajući servis, inicijalizovanjem i korišćenjem servisa iz
oblaka.
6.7.7 Poređenje sa drugim rešenjima
U ovom rešenju i način zadavanja sistema jasno je determinisan dokumentima opisanim
u poglavlju 5.5. U odnosu na druga rešenja, jasno su izdvojeni transport za akviziciju i
distribuciju podataka, pretporocesiranje i procesiranje i odnosu na te aspekte jesno
determinisana arhitektura rešenja sa svim ostalim aspektima kao što su skalabilnost i
redudantnost. Svaki segment modela predloženog rešenja može biti implementiran sa
nekom od adekvatnih tehnologija i metodologja zbog standardizacije načina zadavanja i
funkcionalnosti komponenata sistema, što nije slučaj sa drugim rešenjima.
U poređenju sa drugim rešenjima, predloženi model je jedini koji je baziran na
Microsoft tehnologijama, ali koji može da bude realizovan i na drugim dostupnim
tehnologijama na tržištu.
Predloženi model, u odnosu na druga rešenja, ima najkraći period implementacije.
Standardni period implementacije za ovakve sisteme je od šest meseci do godinu dana,
dok predloženi model može, pri prvoj implementaciji, da bude implementiran u roku od
tri meseca, dok se implementacija svakog sledećeg sistema elektronskog poslovanja
može izvesti u roku od mesec dana.
U poređenju sa ostalim sistemima elektronskog poslovanja platnih sistema, predloženi
model ima mogućnost da bude primenjen na jedinstvenoj strategiji organizacione
jedinice (preduzeća, banke ili druge finansijske organizacije, centralne banke ili
državnog organa) radi jedinstvenog uređenja prostora elektronskog poslovanja platnih
sistema, ali i ostalih sistema elektronskog poslovanja koji su zasnovani na
standardizovanim adresabilnim porukama koje sadrže poslovnu logiku.
6.7.8 Evalauacija predloženog modela interoperabilnog elektronskog
poslovanja platnih sistema
Liste kriterijuma za evaluaciju elektronskog poslovanja platnih sistema prikazane su u
tabelama 15, 16 i 17, a u tabelama 23, 24. i 25. je evaulacija elektronskog polovanja
platnih sistema na osnovu tih kriterijuma. Predloženo rešenje prevazilazi tri kategorije
prepreka interoperabilnosti poslovnih sistema: konceptualne, tehnološke i
organizacione.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 285
Konceptualne prepreke se odnose na sintaksne i semantičke razlike informacija koje se
razmenjuju, a koji se razrešavaju standardizacijom zadavanja sistema, poslovnih poruka
i objedinjavanjem različitih modela podataka u jedinstveni ontološki domenski model.
Tehnološke barijere se odnose na usklađivanje informacionih tehnologija, koji su rešene
standardizacijom modela poslovnih procesa za razmenu, pretprocesiranje i procesiranje
podataka elektronskog poslovanja platnih sistema. Organizacione barijere su rešene
definisanjem odgovornosti i nadležnosti koje proističu iz zakonskog okvira u jasno
determinisanim sistemima putem dokumenata opisanih u poglavlju 5.5.
Kriterijum Ispunjenost
Interoperabilnost
Sistemi su potpuno u stanju da komuniciraju međusobno, isključivo od
zakonske regulative zavisi ko sa kim sme da komunicira. U komunikaciji se
koriste standardni ili standardizovani formati podataka zasnovanih na XML-
u.
Modularna
kompozitnost
Sistem se sastoji od softverskih komponenata koje su kreirane sa
mogućnošću za ponovnu upotrebu i deljenje. Iste komponente za iste
funkcionalnosti se koriste u svim sistemima po nivoima, od super sistema do
sistema za podršku elektronskom poslovanju pravnih i fizičkih lica. Svaka
komponenta sistema se može koristiti u drugim sistemima elektronskog
poslovanja za istu funkcionalnost.
Pouzdanost
Obim u kome se može očekivati da sistem obavlja svoju funkciju zavisi
isključivo od velikog porasta obima saobraćaja – broja poslovnih poruka.
Činjenica da je došlo do velikog neplaniranog porasta saobraćaja nije
negativan aspekt sa stanovišta poslovanja, indikator je drastičnog porasta
poslovnih pokazatelja, a samim tim i profita, pa je ulaganje u proširenje
sistema pozitivan događaj. Osnovni faktor pouzdanosti je starost hardverskih
i komunikacionih komponenata te da bi prekid rada bio minimalan, potrebno
je planovima nabavke predvideti njihovo redovno obnavljanje. Prekidi rada
mogu da se tolerišu ukoliko se dogodi neki na nivou meseca i to ne duži od
nekoliko minuta, izuzev u uslovima elementarne nepogode – katastrofalnim
uslovima kada prekid rada može da se meri satima.
Dostupnost
Vreme u kome je sistem spreman da obavlja zahtevane funkcionalnosti meri
se u procentima u odnosu na prekide u radu, dostupnost sistema se meri sa
99.99 (četiri devetke), a sistema za bruto poravnanje u realnom vremenu
trebalo bi da bude ne manje od 99.999 (pet devetki) i bolje.
Bezbednost
Poruke u sistemu mogu da šalju samo učesnici registrovani od strane
nadređenog sistema. Neautorizovane poruke u sistemu mogu samo da
pošalju učesnici – podređeni sistemi. Svaka poruka nadređenog sistema
smatra se autorizovanom. Ukoliko je u sistem moguće ubaciti veći broj
neautorizovanih poruku, sistem se smatra nesigurnim. Broj pokušaja koji je
veći od broja zadatog pravilima nadređenog sistema jeste diskvalifikujući za
podređeni sistem i to je mehanizam za odbranu sistema od neautorizovanih
poruka. Čak i slanje velikog broja kopija iste autorizovane poruke smatra se
narušavanjem bezbednosti i sistem koji ih šalje diskvalifikuje se iz
saobraćaja. Svako slanje neautorizovane poruke mora se od strane pošiljaoca
detaljno obrazložiti nadređenom sistemu. Retail sistemi imaju mehanizme
koji isključuju slanje neautorizovanih poruka.
Performantnost
Obim u kome se može očekivati izvršenje određenog broja transakcija, zbog
skalabilnosti sistema, sa stanovišta poslovnog procesa nije ograničen. Već sa
procesorima koji se ugrađuju u kancelarijske radne stanice postiže se
nekoliko stotina hiljada transakcija na sat. Sistem je projektovan tako da
može da prihvati od tri do četiri miliona finansijskih transakcija bruto
sistema u realnom vremenu, što može da zadovolji RTGS sistem Narodne
banke Srbije u narednom petogodišnjem periodu.
Tabela 23. Tehnološka evaluacija elektronskog poslovanja platnih sistema
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 286
Kriterijum Ispunjenost
Stabilnost
servisa
Stabilno u dužem vremenskom okviru, broj izmena sistema u vremenskom
okviru je mali jer se komponente sistema konfigurišu za postojeće
funkcionalnosti, a nove funkcionalnosti se dodaju plug and play komponentama
sistema bez prekida rada sistema. Sve komponente sistema su redudantne i ne
postoji single point of failure tako da postoji mogućnost da se izvrši popravka
sistema bez prekida rada.
Nezavisnost
Nezavisnost od domena primenom izolovane aplikativne logike koja se odnosi
na opšte funkcionalnosti, čime se postiže nezavisnost od domena primene. Broj
različitih primena zavisi isključivo od broja poslovnih sistema elektronskog
poslovanja na koje se primenjuje; izvršena je izolacija aplikativne logike i
primena poslovnih pravila koje su parametri sistema, dok je količina direktno
implementirane logike samo na komponentama za koje je to neophodno zbog
postizanja performansi sistema. Sistem, osim primene za elektronsko
poslovanje platnih sistema, ima primenu i u drugim sistemima koji su bazirani
na standardizovanim adresabilnim porukama koje u sebi sadrže poslovnu
logiku.
Proširivost
Lako za dodavanje, modifikaciju, zamenu, uvećanje, izmenu ili pripajanje
funkcionalnosti jer se za izmene vrši u najvećem broju slučajeva podešavanjem
konfiguracionih parametrara. U ostalim slučajevima se vrši dodavanje
funkcionalnosti komponentama za čiju primenu nije potrebno vršiti prekid rada
sistema. Dodavanje novi komponenata baze podataka vrši se u odnosu na novu
verziju poruka koje se primenjuju u sistemu kreiranjem novih objekata, stari
objekti ostaju da žive u neizmenjenom obliku dok god je važeća verzija poruka
koje sistem podržava. Proširivanje sistema u smislu povećanja moći
procesiranja vrši se dodavanjem hardverskih komponenata na način kako je to
predviđeno fizičkom arhitekturom sistema pošto su komponente sistema
skalabilne. Zbog navedenih prednosti sistema, cena izmena na sistemu je
minimalna.
Primenljivost
Funkcionalnosti sistema su determinisane dokumentima sistema opisanim u
poglavlju 5.5., cena primene.je izuzetno niska jer se podešavanje sistema vrši
kroz konfiguraciju parametara, a broj primena zavisi od broja standardizovanih
poslovnih sistema koji su determinisani dokumentima sistema. Cena u odnosu
na broj aplikativnih primena i količina potrebnih resursa za primenu smanjuje
se brojem podržanih poslovnih sistema elektronskog poslovanja. Ukupna cena
resursa za primenu sa licencama je reda veličine pola miliona evra po sajtu
(primarni sajt, back up sajt, dizaster sajt).
Skalabilnost
Sistem je lak za skaliranje, poslovi oko skaliranja se svode na osnovne
administrativne i manipulativne radnje čime se broj transakcija koje mogu biti
prihvaćene od strane sistema može umnogostručiti.
Ekonomičnost
Troškovi razvoja i održavanja su niski i raspoređeni kroz vreme, u zavisnosti od
načina puštanja servisa i ekonomskih prinosa u eksploataciji, te se na taj način
može rasporediti u vremenskom periodu. Prilog 8. pokazuje ekonomsku
isplativnost u odnosu na broj poruka koje su direktno proporcionalne sa brojem
puštenih servisa sistema
Tabela 24. Poslovna evaluacija elektronskog poslovanja platnih sistema
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 287
Kriterijum Ispunjenost
Sekvencijalnost
Poruke se mogu slati samo u sledu. Poruke se šalju onim redom kojim se
kreiraju, prihvataju onim redom kojim se šalju, pretprocesiraju onim redom
kojim se primaju i procesiraju onim redom kojim se pretprocesiraju
Originalnost Poruka koja je prihvaćena pravilno je potpisana, poruka koja je prihvaćena neizmenjena je i zabeležena bez obzira da li je ispravna
Kapacitivnost
Po pitanju transporta, moguće je procesirati šestostruki dnevni obim u toku
jednog sata. Moguće je procesirati dnevni obim u toku jednog sata, a po
pitanju distribucije u transportu moguće je procesirati trostruki dnevni obim
u toku jednog sata
Sledljivost
Registraciono telo zadovoljava kriterijum prijema, obrade i slanja svih
zahteva – kao da se za svaku promenu (poruku ili transakciju) zahteva i
odgovarajući izveštaj i o poruci i o transakciji. Moguće je dobiti odgovor na
sve zahteve o svim porukama i transakcijama
Jednostavnost
Jasno i lako za upotrebu. Jednostavnost u upotrebi ogleda se i u činjenici da
je dovoljno da korisnik može odgovarajućim alatom da proizvede fajl sa
standardizovanom adresabilnom porukom koja sadrži poslovnu logiku koji
se spušta u sistem foldera
Tabela 25. Korisnička evaluacija elektronskog poslovanja platnih sistema
Na osnovu prethodnog može se konstatovati da je definisani metod integracije
interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
primenljiv i da je model efikasan.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 288
7 Naučni i stručni doprinosi
Najznačajniji doprinos ove disertacije ogleda se u razvoju modela interoperabilnog
elektronskog poslovanja platnog sistema zasnovanog na standardizovanom ontološkom
modelu podataka i procesa u poslovno orjentisanoj arhitekturi koji poboljšava
performanse poslovnih procesa. Originalnost se ogleda u definisanju metodološkog
okvira modeliranja i integracije platnih sistema, baziranih na standardizovanom
ontološkom modelu podataka, procesa u poslovno orjentisanoj arhitekturi i u definisanju
metodološkog okvira akvizicije, pretprocesiranja, procesiranja i distribucije podataka za
finansijske sisteme elektronskog poslovanja interoperabilnih sa ostalim elektronskim
poslovnim sistemima.
Kao finalni rezultat istraživanja, razvijeni model je primenjen na realnim sistemima i
omogućava brzu i fleksibilnu interakciju putem elektronskih dokumenata u obliku
standardizovanih poslovnih poruka, što poboljšava interakciju poslovnih procesa,
kolaboraciju sistema koji učestvuju u poslovnim procesima i povećava pouzdanost rada
sistema.
Primenjeni model poboljšava mogućnosti praćenja tokova podataka i na taj način utiče
na povećanje mogućnosti upravljanja poslovnim procesima i sistemima.
Naučni doprinos rada ogleda se u:
• Sistematizaciji i analizi postojećih modela koji daju rešenje za elektronsko
poslovanje platnih sistema;
• Definisanju metodološkog okvira standardizacije organizacije podataka i
procesa za model interoperabilnih platnih sistema zasnovanih na ontologijama, i
to sledećim dokumentima: Operativnim pravilima, Formatom i namenom
poruka, Terminskim planom, Tehničkim uputstvom, Poslovnim pravilima,
šemama i instancama poruka;
• Definisanju metodološkog okvira za standardizaciju modela interoperabilnih
platnih sistema zasnovanih na ontologijama i primeni predloženog
metodološkog okvira za razvoj ostalih sistema elektronskog poslovanja;
• Definisanju okvira za determinisanje domenske ontologije interoperabilnih
sistema elektronskog poslovanja;
• Razvoju originalnog modela interoperabilnog elektronskog poslovanja platnog
sistema zasnovanog na ontologijama i dobijenog standardizacijom organizacije
podataka i poslovnih procesa;
• Razvoju originalnog modela za akviziciju i distribuciju, pretprocesiranje,
procesiranje i postprocesiranje poruka interoperabilnog elektronskog poslovanja
platnih sistema zasnovanih na ontologijama i poslovnih procesa interoperabilnog
elektronskog poslovanja uopšte;
• Razvoju uopštenog modela poruke i modela poslovnog pravila sadržanog u
poruci;
• Razvoju matematičkog modela elektronskog poslovanja platnih sistema;
• Razvoju domenske ontologije platnih sistema zasnovane na ISO15944-4:2007
međunarodnom standardu;
• Primeni Resource–Event–Agent ontologija u inetroperabilnom elektronskom
poslovanju platnih sistema;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 289
• Definisanju okvira za primenu Resource-Event-Agent ontologija u
interoperabilnom elektronskom poslovanju;
• Razvoju, sistematizaciji i detaljnoj analizi implementacije procesa
interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na
ontologijama;
• Razvoju modela Registracionog tela za sledljivost poslovnih procesa i validaciju
podataka povezanih sa poslovnim procesom.
Rad na ovoj disertaciji rezultovao je i nizom stručnih doprinosa, od kojih su najvažniji:
• Analiza i identifikacija najvažnijih problema koji otežavaju elektronsko
poslovanje platnih sistema u Republici Srbiji;
• Metoda za implementaciju predloženog modela interoperabilnog elektronskog
poslovanja platnih sistema u Srbiji;
• Metoda projektovanja i realizacije interoperabilnih sistema elektronskog
poslovanja u Srbiji;
• Standardizovani projektni zadatak sistema elektronskog poslovanja platnih
sistema;
• Standardizovani pristup realizaciji projektnog zadatka implementacije sistema
elektronskog poslovanja platnih sistema;
• Rešenje za kliring finansijskih transakcija nezavisno od instrumenata plaćanja;
• Rešenje za poravnanje finansijskih transakcija nezavisno od instrumenata
plaćanja;
• Razvoj modela kliringa nezavisnog od instrumenta plaćanja;
• Rešenje interoperabilnog elektronskog poslovanja platnog sistema sa
mogućnošću primene i u drugim oblastima elektronskog poslovanja;
• Rešenje tela za registraciju poruka i verifikaciju poslate poruke i potvrde
prijema;
• Rešenje za standardizaciju poslovnih poruka u segmentima poslovanja za koje
nije izvršena standardizacija;
• Rešenje za standardizaciju akvizicije i distribucije podataka u sistemima
elektronskog poslovanja;
• Prezentovanje primene rezultata u drugim segmentima elektronskog poslovanja
koji mogu da se standardizuju primenom adresibilnih poruka sa poslovnom
logikom, među kojima su i meteorološki sistemi;
• Analiza zarada nastalih primenom elektronskog poslovanja;
• Rezultati istraživanja koja daju eksplicitan doprinos standardizaciji
implementacije sistema elektronskog poslovanja;
• Adaptibilni, fleksibilni, proširivi, skalabilni model koji omogućava integritet
poslovnih procesa i podataka.
Rezultati istraživanja realizovanih u okviru ove doktorske disertacije objavljeni su u
više radova u časopisima i saopšteni na naučnim skupovima i to:
Radovi objavljeni u časopisu međunarodnog značaja na SCI listi:
1. S. Babić, Z. Anđelković, D. Barać, Z. Bogdanović, M. Despotović-Zrakić, Model of
Interoperable e-Business of Payment Systems Based on Ontologies, - Metalurgia
International, no. 2-2013, pp. 150-155, 2013 (IF=0.084) (ISSN: 1582-2214).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 290
2. J. Lukić, S. Babić, A. Labus, A. Milić, B. Radenković, Building Business
Intelligence System for B2B e-Business Using KPI, - Metalurgia International, рад
прихваћен за објављивање, (IF=0.084) (ISSN 1582–2214).
3. S. Babić, Z. Andjelković, N. Lekić, The Clearinghouse - A Pattern for Supply Chain
Information Exchange, - Actual Problems of Economics, рад прихваћен за
објављивање, (IF=0.039) (ISSN 1993-6788).
Rad u vodećem časopisu nacionalnog značaja:
1. S. Babić, Z. Anđelković, Distribuirane baze podataka, -Info Science, JISA info :
časopis za informatiku, računarstvo i telekomunikacije Jugoslovenskog
informatičkog saveza, 1/1995, pp. 28-31, 1995, (ISSN: 0354-5334).
Radovi saopšteni na skupu međunarodnog značaja štampani u celini:
1. S. Babić, Z. Anđelković, V. Manić, Z. Stević, Evropski standardi platnih poruka kao
osnov razvoja sistema kliringa naloga, -Naučno-stručni Simpozijum INFOTEH®-
JAHORINA, Jahorina, Republika Srpska, 26.-28. mart 2008.
2. S. Babić, Struktura i tipovi adresibilnih standardizovanih poruka koje u sebi sadrže
poslovnu logiku, -17. telekomunikacioni forum TELFOR 2009, Beograd, Republika
Srbija, 24.-26. novembar 2009.
3. S. Babić, B. Milosavljević, Z. Anđelković, Implementacija sistema lanaca
snabdevanja, -Naučno-stručni Simpozijum INFOTEH®-JAHORINA, Jahorina,
Republika Srpska, 17. - 19. mart 2010.
Radovi saopšteni na skupu nacionalnog značaja štampani u celini:
1. S. Babić, Z. Anđelković, Upravljanje implementacijom IT sistema za podršku
poslovnim procesima, -VII Majska konferencija o strategijskom menadžmentu sa
međunarodnim učešćem, Zaječar, Republika Srbija, 26.-28. maj 2011. pp. 931-944.
2. S. Babić, B. Milosavljević, Z. Anđelković, Korišćenje uzorka document message u
integraciji poslovnih sistema, -YU Info XVI konferencija iz oblasti informacionih i
komunikacionih tehnologija, Kopaonik, Republika Srbija, 03.-06. mart 2010.
3. R. Petković, S. Babić, SAGA SEP transportni sistem u finansijskoj industriji, -
Bankinfo XIII savetovanje informatičara u bankama, Palić, Republika Srbija, 08.-
10. novembar 2006.
4. S. Babić, I. Bojičić, I. Tamburić, Realizacija platnih sistema korišćenjem
standardnih aplikativnih komponenti, -XIII Infofest Festival informatičkih
dostignuća, Budva, Crna Gora, 24.-30. septembar 2006.
5. R. Pavićević, B. Tončić, S. Babić, Metodološki aspekti razvoja informacionog
sistema Narodne banke Jugoslavije, -XVII naučno stručni skup InfoTech, Vrnjačka
banja, Republika Srbija, 20.-23. juni 2000.
6. R. Pavićević, S. Babić, Informacioni sistemi u bankarstvu i centralni bankarski
sistem, -Infofest Festival informatičkih dostignuća, Budva, Crna Gora, 26.
septembar - 02. oktobar 1999.
7. M. Matić, M. Remović, S. Babić, MDB Editor Teodora, -YU Info XVI konferencija
iz oblasti informacionih i komunikacionih tehnologija, Kopaonik, Republika Srbija,
24.-26. mart 1998.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 291
8. M. Matić, M. Remović, S. Babić, Upis i nastava u srednjem obrazovanju -
Programski paket UNA u IS-u tehničke škole Beograd – Železnik, -XII naučno-
stručni skup Infotech, Vrnjačka banja, Republika Srbija, 16.-20. juni 1997.
9. A. Ninković, S. Babić, Računarske mreže i BBS sistemi, vrste i mogućnosti
upotrebe, -44. Sabor psihologa Srbije, Institut za kriminološka i sociološka
istraživanja, primena računara i mreže u psihologiji, Vrnjačka Banja, Republika
Srbija 15.-19- maj1996.
10. Z. Anđelković, S. Babić, Bezbednost i zaštita podataka u zdravstvu - multimedijalno
izlaganje rada, -Medistat, Aranđelovac, Republika Srbija, juni 1996.
11. S. Babić, Početna iskustva u primeni AS/400 u poslovnim procesima u Lola
Korporaciji a.d., -SINFON Studentski radovi u informatici i računarskim naukama,
Zlatibor, Republika Srbija, 29. oktobar – 02. novembar 1994.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 292
8 Buduća istraživanja
Istraživanje započeto u okviru ove teze rezultovalo je modelom interoperabilnog
elektronskog poslovanja platnih sistema zasnovanih na ontologijama. Model pokazuje
da je moguća primena i u drugim segmentima elektronskog poslovanja kako bi se
obezbedila interoperabilnost elektronskog poslovanja. Skup budućih istraživanja
proisteklih iz rezultata ovog rada jeste:
• razvoj okvira za standardizaciju arhitekture poslovnih procesa različitih
domena u okviru poslovnog sistema (na primer preduzeća ili države)
zasnovanog na razmeni adresibilnih poruka koje sadrže poslovnu logiku;
• izolacija objekata i procesa različitih domena jednog poslovnog sistema,
tipizacija njihovih odnosa, strukturiranje poslovne logike poruke u odnosu na
tipove objekata i procesa različitih domena i mogućnost standardizacije na
nivou poslovnog sistema;
• fenomenološka analogija disparatnih sistema zasnovanih na adresibilnim
porukama koje sadrže poslovnu logiku;
• definisanje arhivističkih kategorija i primena metoda arhivistike u cilju
standardizacije i optimizacije poslovnih procesa arhiviranja poslovne
dokumentacije poslovnih procesa, odnosno adresibilnih poruka koje sadrže
poslovnu logiku;
• strukturiranje poslovnih sistema u odnosu na standardizovanu dokumentaciju
poslovnih procesa, odnosno adresibilnih poruka koje sadrže poslovnu logiku i
sa tog stanovišta izrade domenske ontologije koja bi dokazala neopravdanost
postojanja domenskih registracionih tela i dokazala jedinstvenost centralnog
registracionog tela poslovnog sistema nad svim domenima u sistemu.
Istraživanje na postizanju interoperabilnog modela elektronskog poslovanja platnih
sistema pokazalo je da uvođenje globalnih standarda u razmeni poslovnih informacija sa
domaćim i stranim poslovnim subjektima omogućava širenje palete inoviranih
proizvoda elektronskog poslovanja koji mogu da se ponude tržištu, kao što je korišćenje
automata u poslovnim procesima izdavanja polisa obaveznog osiguranja.
Semantička interoperabilnost poslovnih sistema koja se postiže na nivou podataka,
servisa i poslovnih procesa uz razvijenu domensku ontologiju elektronskog poslovanja
platnih sistema daje osnovu da buduća istraživanja u oblasti automatizacije prevođenja
ontologija u šeme podataka mogu dati rezultate koji bi u oblasti razvoja zajedničkih
informacionih modela elektronskog poslovanja doprineli standardizaciji razvoja
informacionih sistema elektronskog poslovanja.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 293
9 Zaključak
Model interoperabilnog elektronskog poslovanja platnog sistema zasnovan na
standardizovanom ontološkom modelu podataka i procesa, predložen u tezi, omogućava
unapređenje procesa elektronskog poslovanja platnih sistema. Unapređenja modela
ogledaju se u: implementaciji standarda finansijske industrije i ostalih segmenata
elektronskog poslovanja, oblasti primene savremenih modela platnih sistema i u drugim
oblastima, u procesima transporta poruka elektronskog poslovanja, u procesiranju
poruka elektronskog poslovanja, domenu primene uniformisanja modela sa
distribuiranim funkcionalnostima, implementaciji savremenih tehnologija.
Predloženi model prati brz razvoj savremenih informacionih tehnologija i diktira
komponentni razvoj, obezbeđuje mogućnost da se izvrši brza implementacija
komponenata u postojeće informacione sisteme. Definisanjem modela za integraciju
razvijenih i buduće razvijenih softverskih komponenata omogućena je brza
implementacija i primena novih tehnologija.
Pored razmatranja o platnim sistemima, informacija o razvoju i eksploataciji platnih
sistema, predmet proučavanja teze je predviđanje načina funkcionisanja platnih sistema
u budućnosti, metodologija zadavanja rešavanja problema, čime je rad obuhvatio razvoj
generičkog modela platnog sistema za transport, prijema platnih poruka,
pretprocesiranje i procesiranja finansijskih instrukcija i transakcija sadržanih u njima.
Obuhvaćeno je i generisanje aplikativnih komponenata i komponenata baze podataka iz
definicija koje nude savremeni standardi, korišćenjem dostupnih alata nad objavljenim i
javno dostupnim elementima finansijskih standarda i pokazano da se komponente
dobijene na taj način mogu koristiti u produkciji. Time je obezbeđeno tehničko i
tehnološko unapređenje podrške poslovnim procesima koje podržavaju sistemi za
elektronsko poslovanje platnih sistema kao i njihova brza implementacija. Prikazano je
da se platni sistemi različitih nivoa se sastoje od standardnih ekvivalentnih elemenata u
rekurzivnoj strukturi.
U okviru disertacije prikazana je informatička organizacija procesorske kuće sa
poslovima registracionog tela, koje je u ovom radu definisano, koja bi se bavila
elektronskom razmenom podataka i procesiranjem poslovnih zahteva. Takav servisni
centar, baziran na rezultatima ovoga rada, mogao bi, osim platnih poruka, da procesira i
poruke drugih realnih sistema koji su bazirani na adresibilnim porukama koje u sebi
sadrže informacije potrebne za procesiranje.
Na bazi predloženog modela integracije elektronskog poslovanja platnih sistema
zasnovanog na ontologijama projektovano je originalno rešenje integracije platnih
sistema. Realizacija se sastojala iz utvrđivanja domenske ontologije platnih sistema, i
primene metodologije zadavanja sistema detaljno opisanim dokumentima potrebnim za
definisanje sistema, kreiranje baze podataka, dinamičkih biblioteka i komponenata
sistema, definisanja načina distribucije komponenata i poslovnih pravila sistema.
Razvoj i testiranje primera rešenja integracije pokazali su da se interoperabilnost
elektronskog poslovanja platnih sistema može uspešno ostvariti predloženom
integracijom. Na osnovu rezultata tokom eksperimentalne analize predloženog rešenja i
primene u produkciji, izvršena je verifikacija i primena predloženog modela. Predloženo
rešenje je našlo primenu u praksi koja se ogleda u uspešnosti klirinških sistema
Udruženja banaka Srbije za kliring čekova i direktno zaduženje.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 294
Predloženim modelom utvrđeno je postizanje interoperabilnosti na sintaksnom i
semantičkom nivou. Eksperiment je pokazao da predloženo rešenje nudi visok stepen
efektivnosti i efikasnosti, a zasnovanost na standardizovanim komponentama i
zadovoljavajući stepen ekonomičnosti.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 295
10 Literatura
[1] Acord Standards. ACORD. Retrived date of access 15.03.2013. from
https://www.acord.org/standards/Pages/default.aspx
[2] Alentron A. et all (2005). Designing Large Value Payment Systems: An Agent -
based approach, Computing in Economics and Finance 2005 396, Society for
Computational Economics.
[3] Altova Map Force. (2012). MapForce – Graphical Data Mapping, Conversion,
and Integration Tool. Retrived date of access 23.09.2012. from:
http://www.altova.com/mapforce.html
[4] AMQP Protocol Specification (2013). Retrived date of access 05.03.2013. from:
http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf
[5] Aničić N. (2001). Strukturna sistemska analiza i XML kao osnove za razvoj
savremenih višeslojnih arhitektura poslovnih objekata. Magistarski rad, Fakultet
organizacionih nauka, Univerzitet u Beogradu.
[6] Aničić N., Ivezić N. (2007). Semantic-based Enterprise Application Integration
Standards, Journal International Journal of Manufacturing Technology and
Management, Publisher Inderscience Enterprises Ltd, ISSN 1368-2148 (Print),
ISSN 1741-5195 (Online).
[7] Anuradha G. et all (2004). From ontology to Relational Databases, Conceptual
Modeling for Advanced Application Domains, Lecture Notes in Computer
Science, 2004, Vol. 3289/2004, 278-289, DOI: 10.1007/978-3-540-30466-1_26.
[8] Apostolou D, Stojanović Lj., Pariente T.,, CasasJ, Papadakis P. (2005).
Configuring e-govermnment services using ontologies, The European Journal
for the Informatics Professional, VI(6), (pp.55-62).
[9] Arsanjani A., (2001). Rule Pattern Language 2001: A Pattern Language for
Adaptive Manners and Scalable Business Rule Design and Construction.
TOOLS '01 Proceedings of the 39th International Conference and Exhibition on
Technology of Object-Oriented Languages and Systems. Page 370. IEEE
Computer Society Washington, DC, USA.
[10] Asgeirsson, H. (2001). The development of payment systems and settlement
systems. Monetary bulletin 2001/4, Central Bank of Iceland, [Electronic
version]. Retrived date of access 14.07.2012. from:
http://www.sedlabanki.is/uploads/files/MB014_8.pdf
[11] Asit D., Johnson R., & Carrato T. (2008). SOA service reuse by design.
Proceedings of the 2nd international workshop on Systems development in SOA
environments SDSOA 08 (pp. 25-28).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 296
[12] Asseco (2013). Banking software. Retrived date of access 05.03.2013.from:
http://asseco.com/see/offer/banking-software/show/6
[13] Association of Serbian Banks (2006). Case Study: Association of Serbian
Banks Reduces Gyro Clearing of Cheques to Less Than
One Hour. Retrived date of access 23.09.2012:
http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=1
000003651
[14] Babić S. (2009). Struktura i tipovi adresibilnih standardizovanih poruka koje u
sebi sadrže poslovnu logiku. Telfor. Beograd.
[15] Babić S., Andjelković Z., Lekić N., (2013). The Clearinghouse - A Pattern for
Supply Chain Information Exchange. Actual problems of economics, ISSN
1993/6788.
[16] Babić S., Anđelković Z. (2011). Upravljanje implementacijom IT sistema za
podršku poslovnim procesima, VII Majska konferencija o strategijskom
menadžmentu sa međunarodnim učešćem, (pp. 931-944). Zaječar.
[17] Babić S., Anđelković Z., Barać D., Bogdanović Z., Despotović-Zrakić M.
(2013). Model of Interoperable e-Business of Payment Systems Based on
Ontologies. Metalurgia International. 18(2). ISSN: 1582-2214.
[18] Babić S., Anđelković Z., Manić V., Stević Z., (2008). Evropski standardi platnih
poruka kao osnov razvoja sistema kliringa naloga, Infoteh, Vol. 7, Jahorina.
[19] Babić S., Bojičić I., Tamburić I. (2006). Realizacija platnih sistema korišćenjem
standardnih aplikativnih komponenti, Infofest, , Budva.
[20] Babić S., Milosavljević B., Anđelković Z. (2010). Korišćenje uzorka document
message u integraciji poslovnih sistema, YU Info. Kopaonik.
[21] Babić S., Milosavljević B., Anđelković Z. (2010). Implementacija sistema
lanaca snabdevanja, Infoteh. Jahorina.
[22] Babić, S. & Anđelković, Z., (1995). Distribuirane baze podataka, Lola -
planiranje i informatika Info Science, 3(1), (pp. 28-31). Beograd.
[23] Bank for International Settlements – BIS (2001). Core Principles for
Sistematically Inportant Payment Systems. ISBN: 92-9131-610-5. Retrived date
of access 15.03.2013. from: http://www.bis.org/publ/cpss43.htm
[24] Bank of Canada (2007).Modelling Payment Systems: A review of the literature,
Bank of Canada Working Paper. 2007-28, ISSN 1701-9397 2007.
[25] Barać D. (2011). Razvoj modela i servisa portala za adaptivno elektronsko
obrazovanje. Doktorska Disertacija. Fakultet organizacionih nauka, Univerzitet
u Beogradu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 297
[26] Benjamin J., Voigt J. (2004). Dynamic System Development Method, Zürich,
Switzerland, S99-728-123, Department of Information Technology, University
of Zurich, Zurich. Retrived date of access 23.09.2012. from:
https://files.ifi.uzh.ch/rerg/amadeus/teaching/seminars/seminar_ws0304/14_Voi
gt_DSMD_Ausarbeitung.pdf
[27] BIAN Banking Industry Architecture Network (2009). Arcitecture
Framework&Foundation, v1.0, The BIAN Metamodel. Retrived date of access
14.07.2012. from: http://bian.org/participate/bian-working-groups/architecture/
[28] BIS. (2001). A glossary of terms used in payments and settlement systems.
Bank for International Settlements, ISBN 92-9131-609-1.
[29] Blommestein, F. (2006). REA as an e-business ontology, Faculty of
Management and Organization. Retrived date of access 14.07.2012. from:
http://www.itu.dk/people/hessellund/REA2006/papers/VanBlommestein.pdf
[30] Bloomberg J. & Schmelzer R. (2006). Service Orient or Be Doomed! How
Service Orientation Will Change Your Business. Hoboken, New Jersey: John
Wiley & Sons, Inc. ISBN: 978-0471768586.
[31] Böhm B., Gewald N., Herold G., Wißmann D., (2006). Patterns in data
modeling and the dynamic extension pattern as example, IADIS International
Conference e-Society 2006. ISBN: 972-8924-16-X ©. Retrived date of access
14.07.2012. from: www.iadis.net/dl/final_uploads/200604S113.pdf
[32] Bojičić I. (2004). Rečnik podataka kao alat za opis i razvoj informacionog
sistema. Magistarski rad. Fakultet organizacionih nauka, univerzitet u Beogradu.
[33] Bradić-Martinović A., (2011). Platni sistemi u procesima evropskih integracija
– zemlje zapadnog Balkana, Doktorska disertacija, Beogradska bankarska
akademija, Fakultet za bankarstvo, osiguranje i finansije, Univerzitet Union u
Beogradu.
[34] Brickley, D. & Guha, R.V., (2009). RDF Vocabulary Description Language 1.0:
RDF Schema B. McBride, ed. W3C Recommendation. Retrived date of access
14.07.2012. from: http://www.w3.org/TR/rdf-schema/
[35] Bumans, G., (2010). Mapping between Relational Databases and OWL
Ontolggies: an Example, Scientific Papers, Universitiy of Latvia, 756, 99-117,
Computer Science and information Technologies
[36] Capie F. at all (2005). Institutional change in the payment systems by electronic
money innovations: Implications for monetary policy. Research report, Institute
of techonology assessment of the austrian academy of sciences. Vienna.
[37] Centralna banka Bosne i Hercegovine. (2012). Objašnjenje termina korištenih u
Platnom sistemu i sistemu poravnanja. Retrived date of access 15.12.2012. from:
http://www.cbbh.ba/index.php?id=6&lang=bs
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 298
[38] Chen P. (1976). The Entity-Relationship Model-Toward a Unified Data view.
Acm Transaction on Database Systems. Masachusetts Institute of Technology.
[39] Cingil I., Dogac A., Sevinac E, CosarA (2000). Dynamic Modification of XML
Documents: External Aplication Invocation from XML, ACM SIGecom
Exchanges, 1(1), doi: 10.1145/844302.844304, ACM New York.
[40] Clark C. at all (2004). Global Electronic Payments. Federal Reserve
Bank of Chicago. . Retrived date of access 23.09.2012. from:
www.frbatlanta.org/news/CONFEREN/payments04/Clark.doc
[41] Coleman G., Verbruggen R. (1998). A quality software process for rapid
application development. Software Quality Journal 7(2). (pp. 107-122).
[42] Committee on Payment and Settlement Systems (2007). Payment systems
in Serbia, Retrived date of access 14.07.2012. from
http://www.bis.org/publ/cpss79.htm
[43] Cranefield S., Pan J. (2007). Bridging the gap between the model-driven
architecture and ontology engineering. International Journal of Human-
Computer Studies, Elsevier. 65(7), (pp. 595–609).
[44] Cullot, N., Ghavi, R. & Yetongnon, K., (2007). DB2OL: a tool for Automatic
Database to Ontolgy Mapping, 15th Italian Symposium on Advanced Database
Systems, SEBD-2007 . (pp. 491-494).
[45] Cummins A. (2009). The Business Side of SO. SOA in Healthcare
Conference. Retrived date of access 15.03.2013. from:
http://www.omg.org/news/meetings/workshops/SOA-HC/presentations-09/02-
07_Cummins.pdf
[46] Čubra N. (1977). Kibernetika u rukovođenju razvojem oružanih snaga, Beograd.
UDK 007:355.1.001.6
[47] Dadić, J., Labus, A., Simić, K., Radenković, B.& Despotović-Zrakić, M.,
(2012). A Model For Structuring Information Resources in E-Government,
Innovative Issues and Approaches in Social Sciences, 5(2), 104-117, ISSN
1855-0541.
[48] Dag-Inge F.(2009). Mobile, internet and electronic payments: The key to
unlocking the full potential of the internal payments market. Journal of
Payments Strategy Systems 3(1). (pp. 60-70).
[49] Damarks Nationalbank (2012). Payment systems in Denmark.
Retrived date of access 15.03.2013. from:
http://www.nationalbanken.dk/dnuk/Tasks.nsf/side/Payment_systems!OpenDoc
ument
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 299
[50] Danish Agency for Digitisation (2013). OIO architecture framework Retrived
date of access 23.09.2012: http://www.digst.dk/Servicemenu/English/IT-
Architecture-and-Standards/OIO-architecture-framework
[51] Danseglio M., Robbie A. (2005). Windows server 2003 Security Cookbook.
O’Reilly, ISBN 0-596-00753-1.
[52] David M. Kristol, Steven H. Low, Nicholas F. (1994). Maxemchuk
Anonymous Internet Mercantile Protocol, AT&T Bell
Labaratories. Retrived date of access 05.03.2013.from:
http://www.oxfordreference.com/view/10.1093/oi/authority.2011080309541531
2
[53] DeMarco T. (1978). Structured Analysis and System Specification, Yourdon
Computing Press, ISBN-10: 0138543801, ISBN-13: 978-0138543808
[54] EANCOM 2002 Syntax 4 based on UN/EDIFACT D.01B Syntax 4 (2012), EDI
Standards Manual, Retrived date of access 23.09.2012. from:
http://www.gs1.se/EANCOM_2002/ean02s4/index.htm
[55] EDIFACT (2012), Introducing UN/EDIFACT, Retrived date of access
23.09.2012. from: http://www.unece.org/trade/untdid/welcome.html
[56] Erdman M., Studer R. (2001). How to structure and access XML documents
with ontologies, Data & Knowledge Engineering. Elsevier. 36(3). (pp.317–335).
[57] Erl T. (2009). SOA Design Patterns, Prentice Hall PTR, ISBN-10: 0136135161,
ISBN-13: 978-0136135166.
[58] eSEE AGENDA + ZA RAZVOJ INFORMACIONOG DRUŠTVA U
JIE 2007-2012, Vlada Republike Srbije, Uprava za Digitalnu
agendu - Ministarstvo kulture, informisanja i informacionog društva
Retrived date of access 23.09.2012. from:
http://www.uzda.gov.rs/FileSystem/SiteDocuments/strategije/eSEE_Agenda_plu
s.pdf
[59] EstIF (2006). Retrived date of access 23.09.2012. from:
http://www.riso.ee/en/information-policy/interoperability
[60] ETSI (2013). Interoperability. Retrived date of access 23.09.2012. from:
http://www.etsi.org/standards/interoperability
[61] European Commision (2007). Payment Services Directive (PSD), DIRECTIVE
2007/64/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 13 November 2007 on payment services in the internal market
amending Directives 97/7/EC, 2002/65/EC, 2005/60/EC and
2006/48/EC and repealing Directive 97/5/EC, Official Journal
of the EU, Retrived date of access 23.09.2012. from:
http://ec.europa.eu/internal_market/payments/framework/psd_en.htm
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 300
[62] European Commission (2011). eGovernment in the Nethelands.
Retrived date of access 15.12.2012.
http://www.epractice.eu/files/eGovernmentTheNetherlands.pdf
[63] European Commission IDABC (2004). The European Interoperability
Framework (EIF) Version 1.0, Retrived date of access 23.09.2012. from:
http://ec.europa.eu/idabc/servlets/Docd552.pdf?id=19529
[64] European Commission IDABC (2007) Gartner and the European Interoperability
Framework (version 2.0), Retrived date of access 23.09.2012. from:
http://gotze.eu/2007/07/17/gartner-and-the-european-interoperability-
framework-20/
[65] European Commission IDABC (2008) Draft document as basis for
EIF 2.0 Retrived date of access 23.09.2012. from:
http://ec.europa.eu/idabc/servlets/Docb0db.pdf
[66] European Payment Council (2002). White Paper Euroland: Our Single
Payment Area!. Retrived date of access 23.09.2012. from:
http://www.europeanpaymentscouncil.eu/knowledge_bank_download.cfm?file=
SEPA Whitepaper 0520021.pdf
[67] European Payment Council (2012). EPC016-06 Risk Mitigation in
the SEPA Direct Debit Scheme Version 7 Approved. Retrived
date of access 15.03.2013. from:
http://www.europeanpaymentscouncil.eu/knowledge_bank_download.cfm?file=
EPC016-06 Core SDD RB V7.0 Approved.pdf
[68] European Payment Council (2012). ISO 20022 Message Standards (SEPA Data
Formats). Retrived date of access 23.09.2012. from:
http://www.europeanpaymentscouncil.eu/content.cfm?page=iso_20022_message
_standards_(sepa_data_format)_sepa_direct_debit
[69] European Payment Council (2012). SEPA Legal and Regulatory Framework
Retrived date of access 23.09.2012. from:
http://www.europeanpaymentscouncil.eu/content.cfm?page=sepa_legal_and_reg
ulatory_framework
[70] European Payment Council (2012). SEPA Scheme Management.
Retrived date of access 23.09.2012. from:
http://www.europeanpaymentscouncil.eu/content.cfm?page=what_is_the_smc_o
f_the_epc
[71] European Payment Council (2012).SEPA Direct Debit Scheme (SDD Core)
Retrived date of access 23.09.2012. from:
http://www.europeanpaymentscouncil.eu/content.cfm?page=sepa_direct_debit_(
sdd)
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 301
[72] Fecko M., Lott C. (2005). XML -Based requirements engineering for an
electronic clearinghouse, Information and Software Technology, 47(13), (pp.
841–858).
[73] Fisher M., Gali H., Hauswirth M. (2002). Towards a Generalized
Payment model for internet services. Technical Univesrity of
Vienna. Retrived date of access 23.09.2012. from:
http://lsirpeople.epfl.ch/hauswirth/papers/GeneralizedPayment.pdf
[74] Fit, T.-technology (1999). Web-based information systems success: a
measurment model of technology acceptance and fit. Management. Retrived
date of access 23.09.2012. from: http://www.mendeley.com/research/webbased-
information-systems-success-measurement-model-technology-acceptance-fit/
[75] Fitzgerald A.M. & Pappalardo K.M. (2009). Moving towards open standards.
SCRIPTed - A Journal of Law, Technology & Society. 6(2), (pp. 467-483).
[76] Gaillard R., (2001). Global Perspectives on financial systems interoperability.
Diplôme post grade en informatique et organisation, Anné académique 2000-
2001. Université de Lausanne. France.
[77] Ghawi, R. & Cullot, N., 2007. Database-to-Ontology Mapping Generation
for Semantic Interoperability. Knowledge Creation Diffusion
Utilization, p.8. Retrived date of access 23.09.2012. from:
http://raji.ghawi.free.fr/files/publications/InterDB07-Ghawi.pdf
[78] Green, P.F. & Rosemann, M. (2005). Business Systems Analysis with
Ontologies ISBN: 9781591403395
[79] Gruber, T. (2009). Encyclopedia of Database Systems, Ontology, Part 15, 1963-
1965, DOI: 10.1007/978-0-387-39940-9_1318, Springer
[80] Gruber, T. R., (1995). Toward Principles for the Design of Ontologies Used for
Knowledge Sharing. International Journal Human-Computer Studies. 43(5-
6).(pp.907-928).
[81] GS1 (2012), The Global Language of Business, Retrived date of access
23.09.2012. from: http:// www.gs1.org
[82] GS1 Srbija i Crna Gora (2006). Opšti GS1 priručnik, 8. izdanje. GTIN
8600000000219
[83] Guido L. Geerts, William E. McCarthy (2001). Using object templates from the
REA accounting model to engineer business processes and task, The Review of
Business Information Systems, 5(4).
[84] Guido L. Geerts, William E. McCarthy (2002). An ontological analysys of the
economic primitives of the extended-REA enterprise information architecture,
International Journal of Accounting Information Systems, 3(1) (pp.1–16).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 302
[85] Gyani J., Murti P (2005). A Pattern Language for Online Share Trading,
EuroPLoP 2005 Conference. Retrived date of access 23.09.2012. from:
http://www.hillside.net/europlop/europlop2005/workshops/WG4.doc
[86] Hallam P. (1995). Electronic Payment Schemes, World Wide Web
Consortium, Retrived date of access 23.09.2012. from:
http://www.w3.org/ECommerce/roadmap.html
[87] Hayes, P. J. (1985). The Second Naive Physics Manifesto, Computation &
intelligence, American Association for Artificial Intelligence Menlo Park, CA,
USA ©1995. (pp. 567-585). ISBN:0-262-62101-0
[88] Heikkinen P. (2009). A framework for evaluting mobile payments,
Bank of Finland, Retrived date of access 23.09.2012:
http://www.suomenpankki.fi/fi/julkaisut/selvitykset_ja_raportit/bof_online/Docu
ments/BoF_Online_2_2009.pdf
[89] Henninger S., Padmapriya A. (2006), An Ontology-Base Metamodel for
Software Patterns. DigitalCommons@University of Nebraska - Lincoln, CSE
Technical reports, TR-UNL-CSE-2006-00005.
[90] Hohpe G., Woolf B. (2004). Enterprise IntegrationPatterns: Designing, Building,
and Deploying Messaging Solutions. Addison-Wesley Professional. ISBN-10:
0321200683, ISBN-13: 978-0321200686
[91] Hong Kong Commerce and Economic Development (2007). Retrived date of
access 23.09.2012. from: http://www.digital21.gov.hk/download/2008D21S-
booklet-en.pdf
[92] Hussain Z. et al. (2009). Ibm Programming and User-Centered Design: Lessons
Learned.. Agile Processes in Software Engineering and Extreme Programming
31.3 (pp. 174-179).
[93] IBM Corporation (2004). Patterns: Service-Oriented Architecture and Web
Services, IBM RedBooks. Retrived date of access 23.09.2012. from:
http://www.redbooks.ibm.com/abstracts/sg246303.html
[94] IBM Corporation (2009). IBM payment Framework for Financial Services,
Retrived date of access 23.09.2012. from: http://www-
05.ibm.com/de/financialservices/pdf/payments_framework.pdf
[95] Iivarinen T. (2004). BOFIT Large Value payment Systems - Principles and
recent and future developments, Bank of Finland discusion papers. Retrived
date of access 23.09.2012. from:
http://www.suomenpankki.fi/en/julkaisut/tutkimukset/keskustelualoitteet/Pages/
dp2004_13.aspx?hl=large value payment systems
[96] ISO (2007). ISO 13616 Financial services - International bank account number
(IBAN). ). Retrived date of access 23.09.2012. from:
http://www.swift.com/dsp/resources/documents/IBAN_Registry.pdf
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 303
[97] ISO (2009). ISO 9362 Bank Identifier Codes (BIC). Retrived date of access
23.09.2012. from: http://www.iso.org/iso/catalogue_detail?csnumber=52017
[98] ISO20022 (2012), ISO 20022 Universal financial industry message scheme,
Retrived date of access 23.09.2012. from: http://www.iso20022.org/
[99] ISO20022 (2012). Full catalogue of ISO20022 messages, Retrived date of access
23.09.2012. from: http://www.iso20022.org/full_catalogue.page
[100] IST (2006) Enterprise Interoperability - Research Roadmap, Retrived date of
access 23.09.2012. from: http://cordis.europa.eu/ist/ict-ent-net/ei-
roadmap_en.htm
[101] Jacob B., Janson D, Mark O., Marras F. (2002). Linux and Branch Banking,
IBM. SG24-6909-00, Retrived date of access 14.07.2012. from:
www.redbooks.ibm.com/redbooks/pdfs/sg246909.pdf
[102] Johnson, R.E. (1997). Components, frameworks, Patterns, SSR '97 Proceedings
of the 1997 symposium on Software reusability, (pp. 10 – 17), ACM New York,
ISBN:0-89791-945-9. NY. USA.
[103] Kemsley S. (2007). Business Process Modeling, Tibco, Retrived date
of access 23.09.2012: http://www.tibco.com/multimedia/business-process-
modelling_tcm8-2404.pdf
[104] Keong W., Guanghao Y., Eo-peng L. (2000) Heterogeneous Product Description
in Electronic Commerce, ACM SIGecom Exchanges, 1(1), doi:
10.1145/844302.844305, ACM New York.
[105] Koeppl T. et all (2007). A Dynamic model of payment system, Federal Reserve
Bank of Philadelphia, USA. Retrived date of access 23.09.2012. from:
http://www.unc.edu/depts/econ/workshops/kmtReStud.pdf
[106] Koeppl T., Monnet C.,Temzelides T. (2007). Building Service - oriented
banking Solutions with the IBM Banking Industry models and Rational SDP,
IBM, IBM Form Number REDP-4232-00.
[107] Lane D., Coffin R.(2006). A Practical Guide to Seven Agile
Methodologies, Part 1. Retrived date of access 15.03.2013. from:
http://www.devx.com/architect/Article/32761
[108] Lazarević B. at all (2003). Baze podataka, Univerzitet u Beogradu, Fakultet
organizacionih nauka, Beograd. ISBN 86-80239-96-8
[109] Lei H. (). Settlement in Modern Network Based Payment Infrastructure -
Description and Prototype of the E-Settlement Model. Bank of
Finland, Retrived date of access 23.09.2012. from:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=342361
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 304
[110] Leinonen H. (2000). Re-enginerring Payment Systems for the e-World, Bank of
Finland, 12/2000. Retrived date of access 23.09.2012. from:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=315000
[111] Lerner A. (1975). Principi kibernetike. Izdavačko-informativni centar. OCLC
Number: 439657118
[112] Lester B., Millard S., Willson M. (2005). Optimal settlement rules
for payment systems, Federal Reserve Bank of New
York. Retrived date of access 14.07.2012. from:
www.newyorkfed.org/research/conference/2006/Econ_Payments/Lester_Millard
_Willison.pdf
[113] Lietaer B (2011). The Future of Money. Retrived date of access 14.07.2012.
from:http://files.uniteddiversity.com/Money_and_Economics/The_Future_of_M
oney-Bernard_Lietaer.pdf
[114] Lopez F.(2002). Overview of methodologies for building ontologies, The
Knowledge Engineering Review, 17(2). (pp. 129 – 156).
[115] Lukić J., Babić S., Labus A., Milić A., Radenković B. (2013). Building Business
Intelligence System for B2B e-Business Using KPI. Metalurgia International,
18(3). ISSN: 1582-2214.
[116] McCarthy, J. Circumscription (1980). A Form of Non-Monotonic Reasoning,
Artificial Intelligence, 5(13): (pp. 27-39).
[117] McGuinness, D. L. & van Harmelen, F. (2004). OWL Web Ontology Language.
W3C Recommendation . Retrived date of access 23.09.2012. from:
http://www.w3.org/TR/owl-features/
[118] Medjahed, B., et al. (2003). Business-to-business interactions: issues and
enabling technologies. The VLDB Journal, 12(1). (pp. 59-85).
[119] Meijer E., Schulte W. (2003). Unifying Tables, Object and Documents,
Microsoft Corporation. Retrived date of access 23.09.2012. from:
http://research.microsoft.com/~emeijer/Papers/XS.pdf
[120] Melao N. (2009). e-Business Processes and e-Business Process Modelling: A
State-of-Art Overview, International Journal of Services Technology and
Management, 11(3). (pp. 293-322).
[121] Merriam-Webster dictionary (2012), Clearinghouse, Retrived date of access
23.09.2012. from: http://www.merriam-webster.com/dictionary/clearinghouse
[122] Microsoft (2012). MS SQL Server 2012. Retrived date of access 23.09.2012.
from: http://www.microsoft.com/sqlserver/
[123] Miller, P. (2000). Interoperability. What is it and Why should I want it? Ariadne
Magazine, Issue 24, University of Bath. UK
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 305
[124] Milojković J., (2011). Interoperabilnost u elektronskom poslovanju statističkih
sistema, Doktorska disertacija. Fakultet organizacionih nauka, Univerzitet u
Baogradu, Beograd.
[125] Morten L. B., Soramaki K. (2001). Gridlock Resolution in Interbank Payment
Systems, Bank of Finland, ISBN 951-686-720-0, Helsinki.
[126] Mos A. et al. (2008). Multi-layer perspectives and spaces in SOA. Proceedings
of the 2nd international workshop on Systems development in SOA environments
SDSOA 08:69.
[127] Nakamura H., Johnson R. (1998). Adaptive framework for the REA Accounting
Model. OOPSLA’98, Workshop on Business Object Design and Implementation
IV. Vancouver, British Columbia, Canada.
[128] Narodna banka Srbije (2013). Propisi iz oblasti poslova platnog sistema.
Retrived date of access 15.03.2013. from:
http://www.nbs.rs/internet/latinica/20/index_plp.html
[129] Narodna banka Srbije. (2004). Odluka o elektronskom načinu obavljanja platnog
prometa. Službeni glasnik RS. br. 57/2004.
[130] Narodna banka Srbije. (2004). Odluka o jedinstvenoj strukturi za identifikaciju i
klasifikaciju računa i o planu računa za obavljanje platnog prometa kod banke
Službeni glasnik RS. br. 57/2004.
[131] Narodna banka Srbije. (2004). Odluka o načinu vršenja kontrole platnog
prometa kod banaka Službeni glasnik RS. br. 57/2004.
[132] Narodna banka Srbije. (2004). Odluka o obavljanju međubankarskog obračuna
čekova po tekućim računima građana Službeni glasnik RS. br. 72/2004.
[133] Narodna banka Srbije. (2004). Odluka o obliku, sadržini i načinu korišćenja
jedinstvenih instrumenata platnog prometa Službeni glasnik RS. br.57/2004,
82/2004.
[134] Narodna banka Srbije. (2004). Odluka o obračunu i kliringu i o funkcionisanju
obračunskih računa banaka kod Narodne banke Srbije Službeni glasnik RS. br.
57/2004.
[135] Narodna banka Srbije. (2004). Operativna pravila za obračun u realnom
vremenu po bruto principu. Službeni glasnik RS. br. 57/2004.
[136] Narodna banka Srbije. (2004). Zakon o elektronskom potpisu, Službeni glasnik
Republike Srbije. broj 135/2004.
[137] Narodna banka Srbije. (2005). Odluka o bližim uslovima i načinu davanja i
oduzimanja bankama licence za obavljanje platnog prometa. Službeni glasnik
RS. br.57/2004, 33/2005.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 306
[138] Narodna banka Srbije. (2005). Odluka o određivanju poslova koje može da
obavlja agent i uslovima za obavljanje tih poslova Službeni glasnik RS. br.
57/2004, 33/2005.
[139] Narodna banka Srbije. (2007). Odluka o međubankarskom kliringu plaćanja u
devizama Službeni glasnik RS. br. 31/2007, 93/2007.
[140] Narodna banka Srbije. (2007). Odluka o obavljanju platnog prometa po osnovu
direktnog zaduženja, Službeni glasnik RS. бр. 31/2007.
[141] Narodna banka Srbije. (2009). Odluka o načinu nadgledanja platnih klirinških i
obračunskih sistema Službeni glasnik RS. br. 46/2009.
[142] Narodna banka Srbije. (2009). Odluka o obavljanju obračuna i poravnanja
platnih Službeni glasnik RS. br. 4/2009.
[143] Narodna banka Srbije. (2009). Odluka o uslovima i načinu otvaranja, vođenja i
gašenja računa kod banke Službeni glasnik RS. br. 33/2005, 25/2009.
[144] Narodna banka Srbije. (2009). Zakon o elektronskom dokumentu, Službeni
glasnik Republike Srbije. broj 51/2009.
[145] Narodna banka Srbije. (2010). Odluka o obavljanju kliringa i obračuna direktnih
zaduženja po osnovu ovlašćenja Službeni glasnik RS. br. 6/2010.
[146] Narodna banka Srbije. (2010). Odluka o opštim pravilima za obavljanje
direktnih zaduženja po osnovu ovlašćenja Službeni glasnik RS. br. 6/2010,
/ispravka 12/2010/.
[147] Narodna banka Srbije. (2010). Odluku o vrsti podataka koje banke dostavljaju
Narodnoj banci Srbije i o načinu i rokovima dostavljanja tih podataka Službeni
glasnik RS. br. 81/2010.
[148] Narodna banka Srbije. (2010). Zakon o bankama,prečišćeni tekst sačinjen na
osnovu teksta Zakona o bankama („Službeni glasnik RS“, br. 107/2005) i
njegovih izmena i dopuna objavljenih u „Službenom glasniku RS“, br. 91/2010.
[149] Narodna banka Srbije. (2011). Odluka o načinu obavljanja platnog prometa
preko novčanog računa centralnog registra, depoa i kliringa hartija od vrednosti
Službeni glasnik RS. br. 89/2011.
[150] Narodna banka Srbije. (2011). Zakon o platnom prometu, prečišćeni tekst
sačinjen na osnovu teksta Zakona o platnom prometu (Službeni list SRJ, br.
3/2002) i njegovih izmena i dopuna objavljenih u Službenom listu SRJ, br.
5/2003 i Službenom glasniku RS, br. 43/2004, 62/2006 i 31/2011.
[151] Narodna banka Srbije. (2012). Zakon o izmenama i dopunama Zakona o
Narodnoj banci Srbije. Službeni glasnik Republike Srbije, br. 76/2012.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 307
[152] Narodna banka Srbije. (2012). Zakon o Narodnoj banci Srbije, prečišćeni tekst
sačinjen na osnovu teksta Zakona o Narodnoj banci Srbije (Službeni glasnik RS,
br. 72/2003) i njegovih izmena i dopuna objavljenih u Službenom glasniku RS,
br, 55/2004, 85/2005 – dr.zakon, 44/2010 i 76/2012.
[153] Naujok K.D. (2009) Illumonus. Retrived date of access 23.09.2012. from:
http://www.illumonus.com/business-modeling-methodology
[154] NBS (2012). Uputstvo o formatu i nameni poruka za razmenu podataka u
obavljanju poslova platnog prometa. Retrived date of access 23.09.2012. from:
http://www.nbs.yu/export/internet/latinica/20/plp/piu_razmena_podataka.pdf
[155] Neches, R., Fikes, R. E., Finin, T., Gruber, T. R., Patil, R., Senator, T., &
Swartout, W. R. (1991). Enabling technology for knowledge sharing. AI
Magazine, 12(3) (pp 16-36).
[156] Norbert Viner (1973). Kibernetika i društvo, ljudska upotreba ljudskih bića, II
izdanje, Nolit. Beograd.
[157] OASIS (2011). Universal Business Language Specifications, Retrived date of
access 15.12.2012. from: http://ubl.xml.org/wiki/ubl-specifications
[158] Object Management Group (2010). Model Driven Message Interoperability
(MDMI), Version 1.0, OMG Document Number: formal/2010-09-01, Retrived
date of access 15.12.2012. from: www.omg.org/spec/MDMI/1.0
[159] OMG Electronic Payments Interoperability Working Group (2004). Request for
information on electronic payment interoperability, OMG Document:
Finance/2004-04-06. Retrived date of access 15.12.2012. from:
http://fdtf.omg.org/wg-payments.html
[160] Oracle (2008). Sun Java System Message Queue 4.3 Documentation Center.
Oracle. Retrived date of access 15.03.2013. from:
http://docs.oracle.com/cd/E19575-01/820-6425/fxjbo/index.html
[161] Park, K.P.K., Kim, G.K.G. & Crovella, M., (1996). On the relationship between
file sizes, transport protocols, and self-similar network traffic.
Proceedings of 1996 International Conference on Network Protocols
ICNP96. (pp.171-180). Retrived date of access 23.09.2012:
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=564935
[162] Paunović, L., Simić, K., Dadić, J., Jovanić, B. & Barać D. (2012). The Impact
of Applying the Concept of the Semantic Web in E-Government, Innovative
Issues and Approaches in Social Sciences. 5(2), (pp. 161-179). ISSN 1855-0541.
[163] Pavićević R., Tončić B., Babić S. (2000). Metodološki aspekti razvoja
informacionog sistema Narodne banke Jugoslavije. Infotech. Vrnjačka banja.
[164] Pavićević R.,Babić S., (1999). Informacioni sistemi u bankarstvu i centralni
bankarski sistem. Infofest. Budva.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 308
[165] Payment Systems in Denmark (2005). Danmarks Nationalbank, ISBN 87-
87251-50-7, ISBN 87-87251-51-5. Retrived date of access 23.09.2012:
http://www.nationalbanken.dk/DNUK/Publications.nsf/side/Payment_Systems_i
n_Denmark_publ/$file/index.html
[166] Petković R., Babić S. (2006).SAGA SEP transportni sistem u finansijskoj
industriji, Bankinfo. Palić.
[167] Petrović M., (1998). Elementi matematičke fenomenologije, Sabrana dela, kniga
7. BIGZ, ISBN 86-17-06419-6.
[168] Petrović M., (1998). Matematička fenomenologija, Sabrana dela, kniga 6, BIGZ,
ISBN 86-17-06414-5.
[169] Petrović T., Petrov V., Šaponjić B. (2012). Telenorov data centar.
Retrived date of access 23.09.2012. from:
http://www.telekomunikacije.rs/aktuelni_broj/tatjana_petrovic_
valentin_petrov,_biljana_saponjic:_telenorov_data_centar.371.html
[170] Pintar D. (2009). Model uslužno orijentirane arhitekture za stvarnovremensko
skladištenje podataka zasnovan na metapodacima. Doktorska disertacija.
Fakultet elektrotehnike i računarstva, Zagreb.
[171] Pleskonjić D., Maček N., Đorđević B., Carić M. (2007). Sigurnost računarskih
sistema i mreža. Mikro knjiga. ISBN: 978-86-7555-305-2.
[172] Ponisio M., Rossi G. (2001). XML Patterns, Retrived date of access 23.09.2012.
from:http://hillside.net/plop/plop2001/accepted_submissions/PLoP2001/mlponis
io0/PLoP2001_mlponisio0_3.pdf
[173] Popović S (2012). Model interoperabilnosti sistema elektronskog poslovanja
zasnovan na servisno orijentisanom razvoju softvera. Doktorska disertacija.
Univerzitet Singidunum, Beograd.
[174] Prof. Jazayeri M. (2003). A Systematic Approach to the Development of Event-
Based Applications. Dissertation.Technischen Universit¨at Wien, Fakult¨at f¨ur
Technische Naturwissenschaften und Informatik. Retrived date of access
23.09.2012: http://www.inf.usi.ch/jazayeri/theses/PascalFenkam.pdf
[175] Prof.dr.sc. Kalpić D. sa grupom autora (2009). Studija
normizacije u e-Poslovanju. Fakultet elektrotehnike i računarstva.
Zagreb. Retrived date of access 23.09.2012:
http://www.zpr.fer.hr/zpr/Portals/0/Isporuka1Faza01_7_Uvez.pdf
[176] Proizvodi i usluge, Halkom Srbija, Retrived date
of access 23.09.2012: http://www.halcom.rs/index.php?section=2#Q
[177] Rankov S. (2003). Model direktnog zaduženja u plaćanjima - primena SWIFT
poruke M104, Udruženje banaka Srbije, COBISS.SR-ID 109903884, Beograd.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 309
[178] Rankov S. (2007). Platni sistemi u Japanu. Udruženje banaka Srbije. Retrived
date of access 23.09.2012. from: http://www.ubs-
asb.com/Portals/0/Casopis/2007/3_4/UBS-Bankarstvo-3-4-2007-Rankov.pdf
[179] Rankov S. (2007). Modeli sistema velikih plaćanja u bankarskoj praksi EU,
Udruženje banaka Srbije, UDK-336.71 (4-672EU), Beograd.
[180] Rankov S. (2007). Sistemi velikih plaćanja u svetskoj bankarskoj industriji,
Udruženje banaka Srbije, ISBN 987-86-7080-016-8, Beograd.
[181] Richards M., Monson-Haefel R., Chappell D. (2009). Java Message Service.
O'Reilly, ISBN 978-0-596-00068-4.
[182] Robinson S. et all (2010). C#, CET & Wrox Press Ltd. ISBN 86-7991-157-7
[183] Rosengard J. et alll (2004). Ontological Representation of Software patterns,
Published in the proceedings of KES'04, Lecture Notes in Computer Science,
vol. 3215 (pp. 31-37). Springer-Verlag. Retrived date of access 23.09.2012.
from: http://w2.syronex.com/jmr/research/publications/2004/ontology-pattern/
[184] Ross A. (1957). An introduction to Cybernetics, Chapman & Hall, Second
Impression. USA
[185] Sawar B., Karypis G., Konstan J., Riedl J. (2000). Analysis of Recommedation
Algorithms for E-Commerce, ACM Conference on Electronic Commerce (EC-
00), 1-58113-272-7/00/0010. Minneapolis, Minnesota.
[186] Schaler, R., 2005. Communication as a key to global business. IPCC 2005
Proceedings International Professional Communication Conference
2005, p.1-10. Retrived date of access 23.09.2012:
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1494153
[187] Schiemenz B, (2002). Managing Complexity by Recursion, Philipps-University
Marburg, Am Plan 2, 35032 Marburg, Germany, Cybernetics And Systems 2002
Wien, S.(pp. 475 – 479). Retrived date of access 14.07.2012. from
http://www.gwu.edu/~rpsol/conf2002/Schiemenz.doc
[188] Sesera L. (2008). Fundamentals Banking Patterns, Proceeding, PLoP '08
Proceedings of the 15th Conference on Pattern Languages of Programs, Article
No. 16, ACM New York, NY. v
http://hillside.net/plop/2008/papers/PLoP2008_27_Sesera.pdf
[189] Shafeed A., Saxena V (2008) Domain-Driven Arcitecture for object-orijented
Software System, Ubiquitous Computing and Communication Journal, ISSN
1992-8424. Retrived date of access 23.09.2012:
http://www.ubicc.org/files/pdf/dd_architecture_updated_209.pdf
[190] Shannon C.E. (1948). A Mathematical Theory of Communication, Reprinted
with corrections from the Bell Systems Technical Journal, 27.(pp. 379-423), &
(pp. 623-656).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 310
[191] Siricharoen W (2009). Ontology Modeling and Object Modeling in Software
Engineering, International Journal of Software Engineering and its
Applications. 3(1).
[192] Smirnov A. (2012). XSD2DB. Retrived date of access 23.09.2012. from
http://xsd2db.sourceforge.net/
[193] Smirnov A., Pashkin M., Chilov N., Levashova T., Krizhanovsky A. (2003).
High-Level Business Intelligence Service in Networked Organizations. e-
Business Research Forum eBRF 2003. Tampere, Finland, September 23-25,
2003. Pp. 37-39.
[194] Smirnov A., Retrived date of access 15.03.2013. from
http://radio.weblogs.com/0112946/stories/2003/04/29/unifyingObjectAndRelati
onalDataStructures.html
[195] Smith, B. and Welty, C. (2001). Ontology---towards a new synthesis.
Proceedings of the International Conference on Formal Ontology in Information
Systems (FOIS2001). ACM Press.
[196] Source, Open (2009). “Open Source Tools to measure software complexity.”
Science Journal 1(2): 127-137. Print.
[197] Sowa, J. F. (1984). Conceptual Structures. Information Processing in Mind and
Machine, Reading, MA: Addison Wesley.
[198] Stankić R., (2008). Elektronsko poslovanje, Centar za izdavačku delatnost
ekonomskog fakulteta u Beogradu, ISBN: 978-86-403-0988-2. Beograd.
[99] Stapleton J. (2003). DSDM: Business Focused Development. Pearson
Education. ISBN: 978-0321112248
[200] Stephens R., Ronald R. Plew, SQL, Kompjuter biblioteka SAMS Publishing.
ISNB 86-7310-022-1.
[201] Strategija razvoja informacionog društva u Republici Srbiji do 2020. ("Sl.
glasnik RS", br. 51/2010). Retrived date of access 23.09.2012:
http://paragraf.rs/propisi/strategija_razvoja_informacionog_drustva_u_republici
_srbiji.html
[202] Stylus Studio (2012), XML Productivity through Innovation. Retrived date of
access 23.09.2012: from: http://www.stylusstudio.com/
[203] Sumanjeet S. (2009). Emergance of payment systems in the age of electronic
comerce: the state of art, Global Journal of International Business
Research, 1933-3471 Retrived date of access 23.09.2012:
http://ssrn.com/abstract=1536620
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 311
[204] Suzie A., Holsapple C. (2002). Knowledge Management as a key for e-business
Competitiveness: From the Knowledge Chain to KM udits. The Journal of
Computer Information Systems. 42(5) (pp.19-26). Stillwater, U.S.
[205] SWIFT (2007). Message Format Validation Rules (MFVR 2007). Standards
Release Guide 2007 (SRG 2007).
[206] SWIFT (2012). FileAct Secure, reliable and cost-effective transfer of files.
Retrived date of access 15.03.2013. from:
http://www.swift.com/products_services/by_type/messaging/fileact_overview
[207] SWIFT (2012). Messaging. Retrived date of access 15.03.2013. from:
http://www.swift.com/products_services/by_type/messaging/index?lang=en
[208] SWIFT (2012). Standards MT Release 2012.
[209] SWIFT User Handbooks (2012). Society for Worldwide Interbank Financial
Telecommunication, Retrived date of access 23.09.2012. from:
https://www2.swift.com/uhbonline/books/hub/uhbmultifacet.htm
[210] SWIFT, Industry initiatives, Retrived date of access 15.03.2013. from:
http://www.swift.com/products_services/industry_initiatives/index?lang=en
[211] Tudorache T. (2006). Employing Ontologies for an Improved Development
process in Colaborative Engineering, Tehnički univerztet u Berlinu, Berlin,
Germany.
[212] Turban E., King D.,Viehland D., and Lee J (2008). Electronic Commerce 2008:
A Managerial Perspective. Upper Saddle River, New Jersey: Prentice-Hall.
ISBN-13: 9780132243315
[213] TWIST – the Standards. The Transaction Workflow Innovation Standards Team
(TWIST). Retrived date of access 23.09.2012. from:
http://twiststandards.org/the-standard/
[214] Udruženje banaka Srbije (2009). Direct Debit u Srbiji. Retrived date of access
23.09.2012: http://www.ubs-asb.com/Default.aspx?tabid=421
[215] Udruženje banaka Srbije (2009). Međubankarski kliring čekova Pravni osnov i
uputstva. Retrived date of access 15.12.2012. from: http://www.ubs-
asb.com/Default.aspx?tabid=425
[216] UK govtalk (2004).Data Standards. Retrived date of access 14.07.2012. from:
http://webarchive.nationalarchives.gov.uk/20100407120701/govtalk.gov.uk/sche
masstandards/datastandards.asp
[217] UK online (2004). e-Government Interoperability Framework Version 6.0 (E-
GIF). Retrived date of access 23.09.2012. from:
http://edina.ac.uk/projects/interoperability/e-gif-v6-0_.pdf
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 312
[218] UN/CEFACT (2012). Standards. Retrived date of access 23.09.2012. from:
http://www.unece.org/cefact/
[219] Vandenbossche, P.E.A. (2007). A Pattern for Global Payment Optimization via
REA Ontology, REA-25 Special Track II – REA Business Patterns, REA-25
Enterprise Model Conference, June 13-15, Newark, Delaware.
[220] Vasković V. (2007). Sistemi plaćanja u elektronskom poslovanju, Fakultet
Organizacionih Nauka, Beograd.
[221] Viner N. (1975). Kibernetika, Informativni centar studenata, Beograd.
[222] Vysniauskas E., Nemuraite L. (1994). Transforming ontology representation
from OWL to relational database. Proceedings of the Eleventh International
Conference on Machine Learning, (pp. 333—343)
[223] Vysniauskas, E. & Nemuraite, L., (2009). Mapping of OWL Ontology concepts
to RDB Schemas. 15th International Conference on Information and Software
Technologies. Kaunas, Lithuania, ISSN 2029-0063
[224] W3C (2001). W3C Semantic Web Activity, Retrived date of access 14.07.2012.
from http://www.w3.org/2001/sw/
[225] W3C, Retrived date of access 23.09.2012. from: http:// www.w3.org
[226] White House (2012). Federal Enterprise Architecture (FEA), Retrived date of
access 23.09.2012. from: http://www.whitehouse.gov/omb/e-gov/fea/
[227] Wilde, Erik (2005). Semantische Interoperabilität von XML Schemas. XML
Web Services Magazin 2. (pp35-38).
[228] Williams L. (2007). A Survey to Agile Development Methodologies. Retrived
date of access 15.03.2013. from
http://agile.csc.ncsu.edu/SEMaterials/AgileMethods.pdf
[229] World Wide Web Consortiu (2010). XML essentials. XML Technology.
Retrived date of access 23.09.2012. from :
http://www.w3.org/standards/xml/core
[230] Ying-Chen L. (2010). A Model to Evaluate the Effectiveness of
Collaborative Online Learning Teams – Self-Disclosure and Social
Exchange. International Journal of Cyber Society and Education.3(2).(pp.117-
132). Retrived date of access 23.09.2012. from: http://www.academic-
journals.org/ojs2/index.php/IJCSE/article/view/912/48
[231] Yoder J. (2012). A Framework to Build Financial Models.
Retrived date of access 14.07.2012. from:
http://www.joeyoder.com/research/frameworks/financial-model-framework
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 313
[232] Zelm M., & Kosanke K. (2007). Standardisation in Interoperability, in IMS
Workshop, Zurich. Retrived date of access 23.09.2012. presentation from:
ftp://ftp.cordis.europa.eu/pub/ims/docs/2-8-zelm.pdf
[233] Zika J. (2007). Remittances: the service provider perspective. Thesis M.A.
Institute of Economic Studies, Faculty of Social Sciences, Charles Ubiversitz in
Prague, Czech Republic.
[234] Živković A., Stankić R., Krstić B. (2010). Bankarsko poslovanje i platni
promet. Centar za izdavačku delatnost ekonomskog fakulteta u Beogradu.
ISBN: 978-86-403-1088-8. Beograd.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 314
11 Spisak slika
Slika 1. Uprošćena slika elektronskog poslovanja ........................................................................ 9
Slika 2. Radovi u smeru sadejstva i konvergencije u standardizaciji XML poruka .................... 26
Slika 3. ISO20022 repozitorijum sa rečnikom podataka ............................................................. 27
Slika 4. Tri osnovna nivoa interoperabilnosti ............................................................................. 32
Slika 5. Model procesa zaštite resursa ........................................................................................ 40
Slika 6. Primer instrumenata za plaćanja: nalozi za uplatu, isplatu, prenos i naplatu ................. 43
Slika 7. Prikaz skupa servisa i portala elektronskih instrumenata plaćanja ................................ 44
Slika 8. Nacionalni platni sistem ................................................................................................. 44
Slika 9. Pregled sistema za razmenu vrednosti ........................................................................... 45
Slika 10. Troslojna arhitektura Antegra BI sistema [12] ............................................................. 47
Slika 11. Veza Antegra BI sistema sa eksternim sistemima [12] ................................................ 48
Slika 12. XML model podataka .................................................................................................. 85
Slika 13. Grafički simbol za predstavljanje elementa ................................................................. 90
Slika 14. Grafički simbol za predstavljanje opcionog elementa ................................................. 90
Slika 15. Grafički simbol za predstavljanje elementa koji se ponavlja ....................................... 90
Slika 16. Grafički simbol za predstavljanje konektora sekvence ................................................ 91
Slika 17. Grafički simbol za predstavljanje konektora izbora ..................................................... 91
Slika 18. Primer grafičkog predstavljanja kompleksnog tipa ...................................................... 91
Slika 19. Grafička predstava kompleksnog tipa koji se koristi u definicijama ........................... 92
Slika 20. Struktura TWIST XML poruke .................................................................................... 92
Slika 21. Struktura zaglavlja TWIST XML poruke .................................................................... 93
Slika 22. Struktura elementa ConversationIdentification ........................................................... 94
Slika 23. Struktura grupa poslova na koje poruka može da se odnosi ........................................ 94
Slika 24. Tipovi kolaboracije ...................................................................................................... 98
Slika 25. Faze projekta [105] .................................................................................................... 108
Slika 26. Extreme programming procesi ................................................................................... 109
Slika 27. Model višeslojne logičke arhitekture SOA [124] ....................................................... 113
Slika 28. Arhitektura SOAP poruke [124] ................................................................................ 116
Slika 29. WSDL opis veb-servisa [124] .................................................................................... 117
Slika 30. Povezivanje različitih platformi i tehnologija pomoću SOA i veb-servisa [124] ...... 119
Slika 31. Arhitektura veb-servisa [124] .................................................................................... 120
Slika 32. Stek protokola veb servisa [124] ................................................................................ 121
Slika 33. Sigurnosni standardi za veb servise: Referentni model [124] .................................... 124
Slika 34. Veb-servis – sigurnosna arhitektura [124] ................................................................. 126
Slika 35. Koreografija i orkestracija [124] ................................................................................ 130
Slika 36. WSCI interfejs i veb-servis [124] .............................................................................. 131
Slika 37. BPEL4WS proces i partneri ....................................................................................... 132
Slika 38. Arhitektura semantičkog vebaa sa preporukama W3C za standarde. ........................ 134
Slika 39. Integracija preko jedne zajedničke ontologije ............................................................ 138
Slika 40. Integracija zasnovana na višestrukim ontologijama................................................... 139
Slika 41. Hibridni ontološki pristup integraciji ......................................................................... 140
Slika 42. Sažeti model EPPS ..................................................................................................... 141
Slika 43. Poslovni procesi plaćanja: Legalizacija ..................................................................... 143
Slika 44. Stvaranje zakonskog okruženja za primenu instrumenata platnog prometa ............. 144
Slika 45. Stvaranje poslovnog okruženja za primenu instrumenata platnog prometa .............. 144
Slika 46. Poslovni procesi plaćanja: Priprema za izvršenje FT................................................. 145
Slika 47. Priprema za izvršenje finansijskih transakcija ........................................................... 145
Slika 48. Poslovni procesi plaćanja: Akvizicija informacija o FT ............................................ 146
Slika 49. Akvizicija informacija o FT ....................................................................................... 147
Slika 50. Poslovni procesi plaćanja: Pretprocesiranje FT ......................................................... 148
Slika 51. Pretprocesiranje finansijskih transakcija .................................................................... 148
Slika 52. Poslovni procesi plaćanja: Procesiranje FT ............................................................... 149
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 315
Slika 53. Procesiranje finansijske transakcije ........................................................................... 150
Slika 54. Poslovni procesi plaćanja: Procesiranje FT ............................................................... 150
Slika 55. Procesiranje finansijske transakcije ........................................................................... 151
Slika 56. Poslovni procesi plaćanja: Priprema za distribuciju .................................................. 151
Slika 57. Poslovni procesi plaćanja: Prosleđivanje poruke ....................................................... 152
Slika 58. Priprema za distribuciju i prosleđivanje poruke ......................................................... 152
Slika 59. Struktura modela EPPS .............................................................................................. 153
Slika 60. Interakcija EPPS sa drugim osnovnim sistemima ...................................................... 154
Slika 61. Struktura finansijske poruke ...................................................................................... 155
Slika 62. XML struktura modela poruke ................................................................................... 157
Slika 63. XML struktura modela poruke – grafički prikaz ....................................................... 158
Slika 64. XML struktura modela poruke, telo poruke ............................................................... 158
Slika 65. XML struktura modela poslovnog pravila u strukturi poruke .................................... 159
Slika 66. Primer konkretnog poslovnog pravila u poruci .......................................................... 159
Slika 67. Relaciona šema poruke sa poslovnim pravilom ......................................................... 160
Slika 68. EPC Model Credit Transfers-a iz knjige pravila [98] ................................................ 162
Slika 69. Osnovni tok procesa Direktno zaduženje [98] ........................................................... 164
Slika 70. Ugovorena interakcija učesnika u procesima direktnog zaduženja [98] .................... 167
Slika 71. Primeri rekurzivnih modela ....................................................................................... 167
Slika 72. Rekurzivna struktura finansijskog tržišta u Srbiji ...................................................... 167
Slika 73. Rekurzivna struktura finansijskog tržišta u Srbiji, prikazana u tabelarnom obliku .. 168
Slika 74. Grafički prikaz modela sistema najnižeg nivoa ......................................................... 169
Slika 75. Grafički prikaz modela sistema n-tog nivoa .............................................................. 169
Slika 76. Primer opisa pozicije EmailAddress u ISO20022 tehničkom uputstvu .................... 173
Slika 77. Osnovna REA ontologija [219] .................................................................................. 175
Slika 78. REA ontologija sa obavezom (angažovanjem) [219] ................................................ 175
Slika 79. REA ontologija sa tipovima [219] ............................................................................. 176
Slika 80. Poslovni transakcioni model - osnovni elementi ....................................................... 178
Slika 81. UML reprezentacija slike 80. ..................................................................................... 178
Slika 82. Poslovni transakcioni model: klase ograničenja ........................................................ 179
Slika 83. Prenos datoteka .......................................................................................................... 184
Slika 84. Deljenje baze podataka .............................................................................................. 185
Slika 85. Integracija udaljenim pozivom procedure .................................................................. 186
Slika 86. Sistem za razmenu poruka ......................................................................................... 186
Slika 87. Model Message Orijented Middleware-a ................................................................... 189
Slika 88. Perzistentni model ...................................................................................................... 189
Slika 89. Perzistentnost i sinhronost u komunikaciji ................................................................ 190
Slika 90. Tranzijentnost i sinhronost u komunikaciji ................................................................ 190
Slika 91. Tranzijentna sinhrona komunikacija bazirana na isporuci i potvrdi .......................... 190
Slika 92. Model redova za čekanje ............................................................................................ 191
Slika 93. Uopštena arhitektura modela redova za čekanje ........................................................ 191
Slika 94. Broker poruka ............................................................................................................ 192
Slika 95. Document Message uzorak ........................................................................................ 193
Slika 96. Uvođenje novih funkcionalnosti u sistem .................................................................. 195
Slika 97. Šema za izbor sistema za realizaciju .......................................................................... 198
Slika 98. Proces evaluacije sistema elektronskog poslovanja platnih sistema .......................... 201
Slika 99. Primeri kolaboracionih perspektiva različitih nivoa u EPPS ..................................... 203
Slika 100. Drugačiji pogled na sistem ....................................................................................... 204
Slika 101. Osnovni sklop standardnih elemenata RTGS sistema.............................................. 204
Slika 102. Grupisanje konglomerata gradivnih jedinica po nivoima ........................................ 204
Slika 103. Blok-šema sistema za razmenu poruka .................................................................... 206
Slika 104. Pravila i uputstva iz Priloga 1 sa XML šemama i primerima .................................. 207
Slika 105. Relaciona šema generisana iz paos.004.001.01 XML šeme sa sajta ........................ 208
Slika 106. Import šeme iz MySQL baze podataka u alat Protege ............................................. 208
Slika 107. Graf automatski kreirane ontologije importom iz baze podataka ............................ 209
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 316
Slika 108. Kreirana ontologija i umetnuti REA elementi sa povezanim znanjem o klasama ... 209
Slika 109. REA, Lista ekonomskih agenata .............................................................................. 211
Slika 110. REA, Lista ekonomskih događaja ............................................................................ 212
Slika 111. REA, Lista ekonomskih resursa ............................................................................... 212
Slika 112. Predstavnici klase „Thing“ i njihove potklase domenske ontologije ....................... 213
Slika 113. Izvođenje lokalne ontologije izborom odgovarajućih klasa ..................................... 214
Slika 114. Lerner: Sistem i sredina ........................................................................................... 216
Slika 115. Ciljna funkcija i ograničenja .................................................................................... 218
Slika 116. Od standarda do implementacije .............................................................................. 219
Slika 117. Credit Transfers kontekst dijagram, dva najviša nivoa ............................................ 230
Slika 118. Retail sistem ............................................................................................................. 232
Slika 119. Retail Credit Transfers sistem banke ....................................................................... 233
Slika 120. Credit Transfers sistem procesora banke ................................................................. 233
Slika 121. Procesorov neto sistem ............................................................................................. 234
Slika 122. Procesorov bruto sistem ........................................................................................... 234
Slika 123. Generalizacija prva dva nivoa .................................................................................. 235
Slika 124. EPC: Uspostavljanje mandata .................................................................................. 237
Slika 125. Osnova servisno orijentisane arhitekture ................................................................. 239
Slika 126. Arhitektura eMessaging Transport System Service BUS-a [166] ............................ 241
Slika 127. Generički model EPPS ............................................................................................. 245
Slika 128. Logička arhitektura EPPS sistema ........................................................................... 247
Slika 129. Uvođenje novih funkcionalnosti u EPPS sistem ...................................................... 249
Slika 130. camt.008.002.01.xsd shema na ISO20022 sajtu sa instancom ................................. 250
Slika 131. Struktura XSD šeme zahteva za otkazivanje plaćanja ............................................. 251
Slika 132. Kreiranje modela baze podataka alatom korišćenjem XSD šeme ............................ 252
Slika 133. Model baze podataka kreiran XSD2DB alatom ....................................................... 252
Slika 134. Mapiranje XSD šeme i šeme baze podataka ............................................................ 253
Slika 135. Izbor programskog jezika za generisanje koda za pristup bazi ................................ 253
Slika 136. Uspešno generisana aplikativna struktura ................................................................ 254
Slika 137. Uspešno ažuriranje baze podataka camt.008.002.01.xml instancom ....................... 254
Slika 138. Učesnici i osnovni potprocesi u procesu prijave štete.............................................. 256
Slika 139. Dekompozicija složenog procesa ............................................................................. 257
Slika 140. Izbor šeme u dokument kreatoru Sylus Studi-a ....................................................... 258
Slika 141. Izbor verzije željene EANCOM poruke ................................................................... 259
Slika 142. Generisana struktura XSD šeme .............................................................................. 259
Slika 143. Mapiranje šeme poruke sa bazom podataka ............................................................. 260
Slika 144. Sistema za centralizaciju procene štete i arhiviranje pripadajuće dokumentacije ... 261
Slika 145. ACORD Framework za razvoj standarda ................................................................ 264
Slika 146. Struktura ACORD poruke ........................................................................................ 265
Slika 147. Područja ACORD standardizacije............................................................................ 265
Slika 148. Logička arhitektura sistema Dunav arhiva ............................................................... 266
Slika 149. Dijagram baze podataka sa ključevima i bez predstavljanja atributa ....................... 270
Slika 150. Moguća struktura i međuzavisnost hardverskih komponenata ................................ 272
Slika 151. Zavisnost broja transakcija u poruci i propusnog opsega (msg/h) ........................... 278
Slika 152. Količina transportovanih finansijskih transakcija (FT) ............................................ 278
Slika 153. Količina transportovanih finansijskih transakcija .................................................... 279
Slika 154. Broj finansijskih transakcija po godinama ............................................................... 279
Slika 155. Iznos u RSD transakcija sa čekovima po godinama ................................................ 280
Slika 156. Broj čekova u prvih 12 meseci rada sistema ............................................................ 280
Slika 157. Iznos u RSD transakcija sa čekovima u prvih 12 meseci rada ................................. 280
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 317
12 Spisak tabela
Tabela 1. Rizici kod sistema za poravnanje ................................................................................ 47
Tabela 2. Osnovne inicijative na globalnom tržištu plaćanja [48] .............................................. 51
Tabela 3. Važnije organizacije sa globalnim uticajem u finansijskoj industriji .......................... 52
Tabela 4. Platne poruke UNIFI formata za poslovne procese plaćanja ...................................... 60
Tabela 5. EPC osnovni set poruka .............................................................................................. 61
Tabela 6. EPC osnovni set poruka sa definisanim dodatnim opcionim servisima ...................... 61
Tabela 7. Kvantitativni indikatori za sisteme malih plaćanja u RS ............................................. 78
Tabela 8. Specifikacije i standardi za rešavanje sigurnosti SOA [124] .................................... 125
Tabela 9. Pretnje i veb-servis standardi koji pružaju zaštitu od njih [228] ............................... 128
Tabela 10. Vrsta dokumenata i odgovornost za izradu ............................................................. 171
Tabela 11. Ontološki kriterijumi i REA ntologija ..................................................................... 177
Tabela 12. Poređenje metodologija: ISO, REA i UN/CEFACT ............................................... 177
Tabela 13. Načini integracije .................................................................................................... 184
Tabela 14. Proces prerade (procesiranja) poruka ...................................................................... 196
Tabela 15. Tehnološki kriterijumi za evaluaciju elektronskog poslovanja platnih sistema ...... 202
Tabela 16. Poslovni kriterijumi za evaluaciju elektronskog poslovanja platnih sistema .......... 202
Tabela 17. Korisnički kriterijumi za evaluaciju elektronskog poslovanja platnih sistema ....... 202
Tabela 18. Neke razlike između načina razvoja softvera .......................................................... 205
Tabela 19. Komparacija predloženog pristupa sa CADM i RAD-CADM metodologijama ..... 220
Tabela 20. Osnovni projektni zahtevi i njihova ispunjenost ..................................................... 240
Tabela 21. Osnovni koraci za uvođenje standarda .................................................................... 264
Tabela 22. Statistika klirinške kuće Udruženja banaka Srbije* ................................................ 280
Tabela 23. Tehnološka evaluacija elektronskog poslovanja platnih sistema ............................ 285
Tabela 24. Poslovna evaluacija elektronskog poslovanja platnih sistema ................................ 286
Tabela 25. Korisnička evaluacija elektronskog poslovanja platnih sistema ............................. 287
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 318
13 Prilozi
Prilog 1:
OPERATIVNA PRAVILA
ZA REALIZACIJU KLIRINGA I OBRAČUNA
PO OSNOVU DIREKTNIH ZADUŽENJA
1. Osnovne odredbe
1.1. U skladu sa stavom 1. tačke 1. Odluke o obavljanju platnog prometa po osnovu direktnih zaduženja
(Službeni glasnik RS, br. 31/2007, u daljem tekstu: Odluka), direktnim zaduženjem se smatraju
transakcije koje inicira Poverilac na osnovu dospelih hartija od vrednosti, menica ili ovlašćenja koje
Dužnik daje svojoj banci i svom Poveriocu u skladu sa članom 4. stav 4. Zakona o platnom prometu (u
daljem tekstu: Direktna zaduženja).
1.2. Osnovi iz tačke 1.1. ovih Operativnih pravila predstavljaju ovlašćenja izdata od strane Dužnika (u
daljem tekstu: Mandat) na osnovu kojih Poverilac može da inicira transakcije za naplatu prema uslovima
navedenim u njima, u skladu sa nacionalnom šemom direktnog zaduženja definisanom od strane Narodne
banke Srbije.
1.3. Direktna zaduženja se realizuju u međubankarskom obračunu koji u skladu sa stavom 1. tačke 3.
Odluke može obavljati pravno lice koje je osposobljeno za poslove kliringa i sa kojim učesnici zaključe
ugovor o kliringu čiji su sastavni deo Operativna pravila (u daljem tekstu: Procesor).
1.4. Učesnici kliringa iz tačke 1.3. ovih Operativnih pravila (u daljem tekstu: Učesnici) mogu biti:
a) Banke iz člana 2. Tačka 10. Odredba pod a) Zakona o platnom prometu, koje poseduju
dozvolu za rad Narodne banke Srbije
b) Ministarstvo finansija – Uprava za trezor
1.5. U skladu sa tačkom 1. Odluke, kliringom se smatra izračunavanje multilateralnih neto pozicija za
učesnike u kliringu, nastalih po osnovu podnetih instrukcija Direktnog zaduženja (u daljem tekstu:
Kliring).
1.6. U skladu sa tačkom 2. Odluke, u Kliringu se mogu izvršavati nalozi Direktnog zaduženja čiji su
pojedinačni iznosi do 1.000.000,00 dinara
1.7. U skladu sa tačkom 5. Odluke, obračun direktnih zaduženja se vrši kao neto obračun izračunatih
multilateralnih neto pozicija preko računa koji se vode kod Narodne banke Srbije (u daljem tekstu:
Obračun) i to:
a) za Banke, preko žiro računa banaka u RTGS sistemu;
b) za Ministarstvo finansija – Uprava za trezor, preko konsolidovanog računa trezora Republike
Srbije u RTGS sistemu;
c) za Procesora, preko obračunskog računa otvorenog u skladu sa Zakonom o platnom prometu i
stavom 2. tačke 5. Odluke.
1.8. Kliring i Obračun se izvršavaju ciklično (u daljem tekstu: ciklus Kliringa), u terminima definisanim
Operativnim pravilima Procesora.
1.9. U skladu sa tačkom 6. Odluke, Kliring i Obračun direktnih zaduženja se vrši prema odredbama
Odluke i u skladu sa Operativnim pravilima za RTGS sistem koja utvrđuje Narodna banka Srbije i
Operativnim pravilima Procesora.
1.10. U skladu sa tačkom 7. Odluke, Udruženje banaka Srbije u svojstvu Procesora, ovim Operativnim
pravilima utvrđuje:
A. Način i uslove za priključenje u Kliring
B. Mere zaštite i odgovornosti učesnika u Kliringu
C. Podatke i poruke u sistemu Kliringa
D. Način realizacije ciklusa Kliringa i obezbeđenja Obračuna
E. Način realizacije Obračuna
F. Sistem obaveštavanja
G. Način rešavanja reklamacija
H. Terminski plan Kliringa
I. Uslove za isključenje iz Kliringa
J. Naknade za poslove Kliringa
2.0 Uslovi i način priključenja
2.1. Uslovi za priključenje Učesnika u Kliring su:
a) da bude učesnik RTGS sistema;
b) da prijavi bankarski kod za identifikaciju (BIC kod) koji koriste u RTGS sistemu;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 319
c) da ispunjava tehničke uslove i standarde za povezivanje, utvrđene uputstvom Narodne banke
Srbije za primenu odluke kojom se uređuje elektronski način obavljanja platnog prometa;
d) da je povezan na mrežu Procesora;
e) da prijavi lica ovlašćena za kontakt sa Procesorom po poslovima Kliringom;
f) da zaključi ugovor sa Procesorom kojim prihvata Operativna pravila;
g) da Procesoru i Narodnoj banci Srbije dostavi ovlašćenje na osnovu koga Procesor može po
osnovu Obračuna da vrši zaduženja njegovog računa u RTGS sistemu.
2.2. Odluku o priključenju Učesnika u Kliring donosi Procesor na osnovu podnetog zahteva za
priključenje overenog pečatom i potpisanog od strane lica ovlašćenog za zastupanje i ispunjenja uslova iz
tačke 2.1. ovih Operativnih pravila.
3. Mere zaštite i odgovornosti
3.1. Mere zaštite koje su Učesnici su dužni obezbede pri realizaciji Direktnih zaduženja se odnose na:
a) Fizičku kontrolu pristupa računarskim resursima koji služe za priključenje na mrežu
Procesora;
b) Zaštićenu administraciju hardverskih i softverskih sistema namenjenih realizaciji Direktnih
zaduženja;
c) Kontrolu operacija, obrade i pristupa podacima vezanim za realizaciji Direktnih zaduženja,
prema standardima definisanim aktima Učesnika za sprovođenje mera unutrašnje kontrole;
d) Primenu drugih mera u skladu sa dobrim poslovnim običajima i praksom.
3.2. Učesnici su dužni da Procesoru prijave najmanje po jednog zaposlenog za poslove:
a) Administratora sistema, zaduženog za primenu mera zaštiti koje obuhvataju:
- Administraciju komunikacionih resursa koji služe za bezbedno priključenje i rad u mreži
Procesora;
- Realizaciju platnog prometa u skladu sa uputstvom o elektronskom obavljanju platnog prometa
koje donosi Narodna banka Srbije;
- Sproveđenje odluke Procesora o privremenom isključenju Učesnika iz Kliringa, odnosno o
njihovom uključenju u Kliring
b) Ovlašćeno lice, zaduženo za definisanje i realizaciju procedura i operacija vezanih za Direktna
zaduženja koje obuhvataju:
- Definisanje procedura za sprovođenje transakcija Direktnog zaduženja u skladu sa zakonskim
propisima i ovim Operativnim pravilima, i njihovu realizaciju
- Kontrolu operacija vezanih za Direktna zaduženja, u skladu sa definisanim procedurama;
- Podnošenje informacija o maksimalnom iznosu do koga Učesnik učestvuje u Kliringu;
- Podnošenje i rešavanje reklamacija po transakcijama Direktnih zaduženja.
3.3. Učesnici su odgovorni za verodostojnost, kodiranje i sadržaj poslatih poruka, njihovo slanje u skladu
sa terminskim planom Kliringa, kao i za svaki propust svojih Administratora sistema i Ovlašćenih lica.
3.4. Svaki propust u primeni mera zaštite iz tačke 3. ovih Operativnih pravila od strane Učesnika može
biti osnov za nadoknadu nastale štete ostalim Učesnicima Kliringa. Nesporan finansijski gubitak
Učesnika u kliringu, pod kojim se u smislu ovih Oprativnih pravila podrazumeva iznos realizovanih
transakcija Direktnog zaduženja, uzrokovan propustima u primeni mera zaštite drugih Učesnika,
nadoknađuje Učesnik koji je svojim propustima u primeni mera zaštite uzrokovao nastanak finansijskog
gubitka, a realizuje Procesor u ciklusu Kliringa transakcijama za povraćaj sredstava (Return).
4. Podaci i poruke u sistemu Kliringa
4.1. Uputstvom o nameni i formatu poruka za sistem Kliringa i Obračuna po Direktnim zaduženjima koje
je dato u Prilogu 1. ovih Operativnih pravila (u daljem tekstu: Uputstvo), na osnovama tehnologije i
pravila u SEPA (Single Euro Payments Area) okruženju je definisan set instrukcija i poruka za realizaciju
Direktnih zaduženja, razmenu informacija o ciklusu Kliringa i Obračuna, njihov sadržaj, format i namena.
Razmena poruka sa instrukcijama Direktnog zaduženja i informacijama o Kliringu i Obračunu se vrši
putem mreže Procesora.
4.2. Razmena poruka za realizaciju Obračuna se vrši putem mreže Narodne banke Srbije, na način i u
formatu definisanim od strane RTGS sistema, sa nezavisnim ulazno/izlaznim kanalima i elementima
zaštite.
5. Način realizacije ciklusa Kliringa i obezbeđenja Obračuna
5.1. Neto pozicija u ciklusu Kliringa predstavlja razliku u finansijskom iznosu između sume iznosa
podnetih (prilivi) i sume iznosa primljenih (odlivi) instrukcija Direktnog zaduženja (u daljem tekstu: Neto
pozicija), koja se obračunava na nivou svakog Učesnika i može biti pozitivna (više priliva nego odliva),
negativna (više odliva nego priliva) i nulta.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 320
5.2. Za obezbeđenje Obračuna, koristi se informacija o maksimalnom iznosu zaduženja Učesnika u
kliringu (u daljem tekstu: Limit zaduženja), a koju svaki Učesnik dostavlja Procesoru pre početka
ciklusa Kliringa.
Učesnik može menjati Limit zaduženja u bilo kom trenutku, pri čemu je važeći poslednji dostavljeni
Limit zaduženja.
5.3. Obaveza svakog Učesnika je da obezbedi na računu u RTGS sistemu dovoljno sredstava za
realizaciju negativne Neto pozicije, odnosno da dostavljanjem Limita zaduženja u skladu sa stanjem na
računu u RTGS sistemu, obezbedi da njegova negativna Neto pozicija bude realizovana u Obračunu.
5.4. Za svakog Učesnika kod koga je negativna Neto pozicija veća od Limita zaduženja, Procesor vrši
odbijanje instrukcija Direktnog zaduženja koje se odnose na zaduženje njegovog računa, prema iznosu
zaduženja (od najmanjeg ka najvećem), a do nivoa negativne Neto pozicije jednake ili manje od Limita
zaduženja, uz ponavljanje ciklusa Kliringa bez odbijenih instrukcija Direktnog zaduženja.
5.5. Procesor vrši verifikaciju ciklusa Kliringa, proverom usklađenosti negativne Neto pozicije svakog
Učesnika sa stanjem na njegovom računu u RTGS sistemu.
Učesnici koji nemaju dovoljno sredstava na računu u RTGS sistemu za realizaciju negativne Neto
pozicije se isključuju iz ciklusa Kliringa, uz odbijanje instrukcija Direktnih zaduženja koja se odnose na
tog Učesnika i ponavljanje ciklusa Kliringa.
5.6. Ciklus Kliringa Procesor realizuje jednom dnevno, nakon zatvaranja RTGS sistema za prijem naloga
za plaćanje, po pravilu sa instrukcijama Direktnog zaduženja čije je dospeće narednog dana, a Obračun po
ovom ciklusu Kliringa Procesor realizuje na dan dospeća, odmah po otvaranju RTGS sistema za prijem
naloga za plaćanje.
6. Način realizacije Obračuna
6.1. Procesor vrši realizaciju Obračuna za verifikovani ciklus Kliringa preko svog obračunskog računa u
RTGS sistemu, ispostavljanjem naloga za zaduženje računa Učesnika sa negativnom Neto pozicijom u
ciklusu Kliringa (u korist obračunskog računa Procesora) i naloga za odobrenje računa Učesnika sa
pozitivnom Neto pozicijom u ciklusu Kliringa (na teret obračunskog računa Procesora).
6.2. Procesor prvo ispostavlja sve naloge za izvršenje negativnih Neto pozicija (zaduženje računa
Učesnika u RTGS sistemu), a nakon njihove realizacije, Procesor ispostavlja sve naloge za izvršenje
pozitivne Neto pozicije (odobrenje računa Učesnika u RTGS sistemu).
7. Sistem obaveštavanja
7.1. Obaveza Procesora je obaveštavanje Učesnika najmanje o:
a) Promenama statusa Učesnika (Isključenje/uključenje)
b) Validnosti primljenih poruka
c) Odbijanju instrukcija Direktnog zaduženja
d) Neto poziciji u ciklusu Kliringa
e) Ostvarenom prometu u ciklusu Kliringa
f) Realizovanim instrukcijama Direktnim zaduženjima
Set poruka za obaveštavanje Učesnika, njihov sadržaj, format i namena, definisan je Uputstvom koje je
dato u Prilogu 1. ovih Operativnih pravila.
7.2. Obaveza Učesnika je obaveštavanje Procesora najmanje o:
a) Promeni statusa Učesnika u sistemu Kliringa (Isključenje/uključenje)
b) Limitima zaduženja
c) Odbijanju instrukcija Direktnog zaduženja
Set poruka za obaveštavanje Procesora, njihov sadržaj, format i namena, definisan je Uputstvom koje je
dato u Prilogu 1. ovih Operativnih pravila.
7.3. Banke dužnika je obavezna da na osnovu dobijene instrukcije direktnog zaduženja koja u
elektronskom obliku sadrži nalog za naplatu i ovlašćenje koje je dužnik ispostavio poveriocu, inicira
postupak prinudne naplate u slučaju nemogućnosti realizacije zaduženja zbog nedostatka raspoloživih
sredstava na računu dužnika i/ili blokade računa dužnika, a prema tački 6. Odluke o sprovođenju prinudne
naplate sa računa klijenta.
Set poruka za iniciranje prinudne naplate, njihov sadržaj, format i namena, definiše svojim odlukama i
uputstvima Narodna banka Srbije.
7.4. Narodna banka Srbije i Procesor razmenjuju informacije od značaja za realizaciju Obračuna i
stabilnost platnog sistema u koje spadaju o:
a) Promene statusa Učesnika u sistemu Kliringa (Isključenje/uključenje)
b) Promene statusa Učesnika u RTGS sistemu (blokade/deblokade)
c) Informacije o usklađenosti negativne Neto pozicije Učesnika u ciklusu Kliringa sa stanjem na
računu u RTGS sistemu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 321
d) Informacije o nerealizovanju instrukcija Direktnih zaduženja zbog nedostatka sredstava na
računu Učesnika u RTGS sistemu
e) Drugi događaji od značaja za stabilnost platnog sistema
Način razmene informacija između Narodne banke Srbije i Procesora definiše Narodna banka Srbije.
8. Način rešavanja reklamacija
8.1. Reklamacije po realizovanim ili nerealizovanim instrukcijama Direktnog zaduženja u ciklusu
Kliringa i Obračuna, a koje se odnose na propuste nastale u ciklusu Kliringa ili Obračuna, podnose se
Procesoru u roku od 10 dana od dana završetka ciklusa Kliringa i Obračuna.
Odluku i rešenje po ovim reklamacijama donosi posebna komisija koju formira Procesor, a u kojoj pored
članova iz redova Procesora mogu participirati i članovi iz redova Učesnika. Komisija za rešavanje
reklamacija može postojati kao stalno telo pri Procesoru, koje pri konstituisanju donosi Pravilnik o radu
kojim se definiše sastav, dužina mandata članova, način rada i donošenja odluka (u daljem tekstu:
Komisija).
Komisija donosi Odluku i rešenja po reklamaciji u roku od 10 dana od dana podnošenja reklamacije.
Odluka Komisije predstavlja osnov za izvršenje instrukcija Direktnog zadužena kojima se vrši povraćaj
sredstava (Return), u skladu sa Uputstvom datim u Prilogu 1. ovih Operativnih pravila.
8.2. Sporove i reklamacije po realizovanim ili nerealizovanim instrukcijama Direktnog zaduženja u
ciklusu Kliringa i Obračuna, a koje se odnose na propuste učinjene od strane Učesnika, rešavaju
međusobno Učesnici. Za ekpertizu i rešavanje ovih sporova i reklamacija, Učesnici mogu takođe koristiti
usluge Komisije, pri čemu se angažovanjem Komisije obavezuju za prihvatanje njene Odluke po
nastalom sporu.
Sporazum Učesnika ili Odluka Komisije predstavlja osnov za izvršenje instrukcija Direktnog zadužena
kojima se vrši povraćaj sredstava (Return), u skladu sa Uputstvom datim u Prilogu 1. ovih Operativnih
pravila ili plaćanja od strana banke poverioca.
8.3. Reklamacije po realizovanim ili nerealizovanim instrukcijama Direktnog zaduženja u ciklusu
Kliringa i Obračuna, a koje se odnose na sporne i različito tumačene osnove naplate (mandate) od strane
Dužnika i Poverioca, rešavaju međusobno Dužnik i Poverilac.
Sporazum Dužnika i Poverioca predstavlja osnov za izvršenje instrukcija Direktnog zaduženja kojim se
vrši povraćaj sredstava od strane Poverioca (Reversal) u skladu sa Uputstvom datim u Prilogu 1. ovih
Operativnih pravila.
9. Terminski plan Kliringa
9.1. Kliring i Obračun se obavlja svakog radnog dana kojima se u smislu ovih Operativnih pravila ne
smatraju subota, nedelja i dani državnih i verskih praznika koji su proglašeni neradnim danima.
9.2. Kliring i Obračun se ne mogu obavljati danima u kojima ne radi RTGS sistem, bez obzira na razloge
zbog kojih RTGS sistem ne radi.
9.3. Dnevni terminski plan Kliringa i Obračuna mora uvek biti usklađen sa dnevnim terminskim planom
RTGS sistema koji donosi Narodna banka Srbije.
9.4. Radno vreme, kao i dnevni terminski plan Kliringa i Obračuna su definisani Terminskim planom za
sistem Kliringa i Obračuna po Direktnim zaduženjima koji je dat u Prilogu 2. ovih Operativnih pravila (u
daljem tekstu: Terminski plan)
9.5. Procesor može, po potrebi, povremeno i privremeno promeniti Terminski plan, o čemu je dužan da
obavesti sve Učesnike i Narodnu banku Srbije
9.6. Procesor može vršiti i trajne promene Terminskog plana, a obavezno pri promeni dnevnog
terminskog planom RTGS sistema sa kojim uvek mora biti usklađen.
10. Uslovi isključenja Učesnika iz Kliringa
10.1.Učesnik u Kliringu može biti privremeno ili trajno isključen iz Kliringa.
10.2. Učesnik u Kliringu može biti privremeno isključen iz Kliringa:
a) Ukoliko ne postupa u skladu sa Ugovorom o učešću u Kliringu i Obračunu koji je zaključio sa
Procesorom
b) Ukoliko ne primenjuje mere zaštiti predviđene tačkom 3. ovih Operativnih pravila
c) Ukoliko nema dovoljno sredstava na računu u RTGS sistemu za realizaciju negativne Neto
pozicije obracunate u ciklusa Kliringa
d) Ukoliko u kratkom vremenskom intervalu (do 7 dana) višekratno (više od jednom) nema
dovoljno sredstava na računu u RTGS sistemu za realizaciju negativne Neto pozicije obračunate
u ciklusima Kliringa
e) Ukoliko u kratkom vremenskom intervalu (do 7 dana) višekratno (više od jednom)
postavljenim Limitom zaduženja implicira odbijanje instrukcija Direktnog zaduženja
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 322
f) Ukoliko neopravdano odbije izvršenje instrukcija Direktnog zaduženja po reklamaciji drugog
Učesnika
g) Ukoliko neprihvata zahtev Procesora ili drugog Učesnika upućenog preko Procesora za
zajedničkom ekspertizom po reklamacijama ili ućešće u ekpertizi.
h) Ukoliko neprihvata rezultate zajedničke ekspertize po reklamacijama, do konačnog rešenja
spora.
i) Ukoliko ne postupa u skladu sa drugim tačkama Operativnih pravila
j) Ukoliko Procesor utvrdi sa Učesnik izaziva tehničke probleme u radu Kliringa
10.3. Odluku o privremenom isključenju iz Kliringa i Obračuna donosi Procesor, koji o tome odmah
obaveštava ostale Učesnike.
Odluka Procesora o privremenom isključenju Učesnika iz Kliringa i Obračuna obavezno sadrži razloge
isključenja, eventualne preduzete mere od strane Procesora i uslove za ponovno uključenje Učesnike sa
rokom za njihovo ispunjenje.
Ispunjenjem uslova navedenih u Odluci Procesora o privremenom isključenju Učesnika iz Kliringa i
Obračuna u predviđenom roku, Učesnik se ponovo uključuje u Kliring i Obračun, o čemu Procesor
odmah obaveštava ostale Učesnike
Neispunjenje uslova za ponovno uključenje ili istekom roka, stiču se uslovi za trajno isključenje Učesnika
iz Kliringa i Obračuna
10.4. Učesnik u Kliring može biti trajno isključen iz Kliringa:
a) Ukoliko se ustanovi da Učesnik ne ispunjava ili više ne ispunjava bilo koji od uslova za
priključenje u Kliring navedenih u tački 2.1 ovih Operativnih pravila,
b) U slučaju višestrukog, uzastopnog privremenog isključenje kojim se izazivaju smetnje u
funkcionisanju sistema Kliringa i Obračuna,
c) U slučaju neispunjenja uslova ili protekom roka navedenog u Odluci Procesora o
privremenom isključenju Učesnika iz Kliringa i Obračuna
d) Raskidom Ugovora o učešću u Kliringu i Obračunu potpisanog između Učesnika i Procesora
10.5. Odluku o trajnom isključenju iz Kliringa i Obračuna donosi Procesor, koji o tome odmah
obaveštava ostale Učesnike.
Odluka Procesora o trajnom isključenju Učesnika iz Kliringa i Obračuna obavezno sadrži razloge
isključenja, eventualne preduzete mere od strane Procesora.
Po trajnom isključenju Učesnika iz Kliringa i Obračuna, Procesor će pokrenuti postupak za raskid
Ugovora o učešću u Kliringu i Obračunu potpisanog između Učesnika i Procesora, ukoliko to Učesnik
nije učinio.
Ponovno uključenje Učesnika u Kliring je moguće sprovođenjem ponovo postupka za priključenje
definisanog u tački 2. ovih Operativnih pravila
11. Naknada za poslove Kliringa
11.1. Za pružanje usluga Kliringa i Obračuna po Direktnim zaduženjima, Procesor naplaćuje naknadu
prema tarifi za izvršene usluge koju definiše internim aktom (Odluka o tarifama usluga) i koja predstavlja
sastavni deo Ugovora o učešću u Kliringu i Obračunu potpisanog između Učesnika i Procesora.
12. Dodatni servisi Kliringa
12.1. Procesor može u okviru dodatnih opcionih servisa (AOS - Additional Optional Service) ponuditi
Učesnicima preuzimanje pojedinih prava i obaveza, vođenja evidencija i izveštavanja, u skladu sa
unapred definisanim pravilima prihvaćenim od strane Učesnika i Procesora.
13. Završne odredbe
13.1. Procesor može menjati ova Operativna pravila u cilju unapređenja poslova Direktnog zaduženja i
usaglašavanja sa domaćim i međunarodnim standardima u tom domenu, uz saglasnost Narodne banke
Srbije za izmene koje se odnose na usklađenost sa RTGS i ukupnim platnim sistemom.
13.2. O svim izmenama ovih Operativnih pravila, Procesor je dužan da obavesti Učesnike najmanje 15
(petnaest) dana pre stupanja na snagu tih izmena, osim za izmene kojima se ispravljaju uočene
nepravilnosti u funkcionisanju sistema, koje stupaju na snagu odmah i moraju se sprovesti u najkraćem
mogućem vremenu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 323
Prilog 2.
UPUTSTVO O NAMENI I FORMATU PORUKA I TEHNOLOŠKA PRAVILA
SISTEMA KLIRINGA I OBRAČUNA PO DIREKTNIM ZADUŽENJIMA
1. U Č E S N I C I
Učesnici u Direktnim zaduženjima su:
A) Dužnik (Debtor) је lice, fizičko ili pravno, koje izdaje Mandat (ovlašćenje) svome Poveriocu
(Creditor) da ugovorenog dana ili u datom periodu izvrši naplatu definisanog/ih iznosa sa
njegovog računa, u skladu sa uslovima navedenim u ovlašćenju.
B) Poverilac (Creditor) је lice, fizičko ili pravno, koje inicira Direktno zaduženje računa
Dužnika na osnovu i u skladu sa uslovima navedenim u primljenom Mandatu (ovlašćenju).
C) Banka poverioca (Creditor Bank) je banka u kome je račun Poverioca i predstavlja Učesnika
u sistemu kliringa.
D) Banka dužnika (Debtor Bank) je banka u kome je račun Dužnika i predstavlja Učesnika u
sistemu kliringa.
E) Procesor je pravno lice koje je u svojstvu klirinške kuće (ACH - Automatic Clearing House)
odgovorno za sprovođenje mehanizma obračuna multilateralne pozicije banaka Učenika u
sistemu kliringa i njegove realizacije u RTGS sistemu Narodne banke (CSMs - Clearing and
Settlement Mechanisms).
2. P R A V A I O B A V E Z E U Č E S N I K A
2.1. Obaveza Dužnika je da dostavi Poveriocu personalizovan, verifikovan Mandat.
2.2. Odgovornost za popunjenost obaveznog seta Mandata, jedinstvenost identifikacije Mandata i
potpunost pravnog teksta nosi Poverilac.
2.3. Poverilac je dužan da čuva (skladišti) Mandat u originalnom obliku i sa nepromenjenim sadržajem.
2.4. Dužnik je obavezan da pre dospeća obaveze, podnese svojoj banci Mandat ili drugi vid ovlašenja
(saglasnosti) za izvršenje zaduženje njegovog računa dogovorenog sa bankom, koji sadrži jednoznačnu
identifikaciju Mandata i sve elemente za pravilno i nedvosmisleno identifikovanje uslova svake
pojedinačne naplata.
2.5. Poverilac i dužnik mogu da pre dospeća obaveze, podnesu svojim bankama Mandat sa zahtevom za
njegovo evidentiranje u Registru mandata kod Procesora.
2.6. Banka dužnika i/ili banka poverioca mogu Procesoru podneti zahtev za evidentiranje Mandata u
Registar mandata, izmenu Mandata i povlačenje Mandata (banka dužnika samo u slučajevima
predviđenim zakonskim propisima – stečaj ili likvidacija pravnog lica, smrt preduzetnika i dr.), prema
uslovima i u rokovima koji su definisani ovim Uputstvom.
2.7. Procesor evidentira i čuva Mandat u Registru mandata u dematerijalizovanom obliku, sa istom
važnošću kao i verifikovani Mandat u izvornom obliku.
Banka dužnika i banka poverioca su odgovorni za potpunu usklađenost sadržaja Mandata u izvornom
obliku i u dematerijalizovanom obliku podnetom Procesori za evidentiranje u Registru mandata.
Evidentiranjem u Registru mandata, banka dužnika i banka poverioca, odnosno dužnik i poverilac
prihvataju neporecivost njegovog izdavanja i evidentiranog sadržaja.
2.8. Pri prodnošenju zahteva za evidentiranje Mandata u Registar mandata od strane banke poverioca,
Procesor je dužan da obavesti banku dužnika o zahtevu za evidentiranje.
Dužnik, odnosno banka dužnika može odbiti zahtev za evidentiranje Mandata.
U slučaju eksplicitnog neprihvatanja, odnosno neodbijanja Mandata od strane banke dužnika u rokovima
predviđenim ovim Uputstvom, Procesor će smatrati Mandat odbijenim.
2.9. Pri podnošenju zahteva za evidentiranje Mandata u Registar mandata od strane banke dužnika,
Procesor će Mandat odmah uključuje u evidenciju Registra mandata, a banku poverioca obavestiti o
evidentiranom Mandatu.
2.10. Dužnik i poverilac, odnosno banka dužnika i banka poverioca su dužni da svaku izmenu sadržaja i
statusa Mandata evidentiranih u Registru mandata takođe evidentiraju u Registru mandata, pre
ispostavljanja naloga za naplatu koji je u skladu sa izmenjenim Mandatom.
2.11. Procesor je dužan da o zahtevu za izmenu sadržaja Mandata obavesti banku drugog učesnika, koja
može odbiti izmenu Mandata.
U slučaju eksplicitnog neprihvatanja, odnosno neodbijanja zahteva za izmenu Mandata u rokovima
predviđenim ovim Uputstvom, Procesor će smatrati izmenu Mandata odbijenom.
2.12. Zahtev za evidentiranje izmene sadržaja Mandata u Registru mandata, pored izmenjenih elemenata
mora sadržati i sve druge, neizmenjene podatke i informacije iz originalnog Mandata.
U Registru mandata važeći sadržaj Mandata je sadržaj evidentiran poslednjom izmenom Mandata.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 324
2.13. Povlačenje Mandata se može odnositi samo na povlačenje osnovnog Mandat koje obuhvata i
povlačenje svih aneksa tog Mandata.
2.14. Pri podnošenju zahteva za povlačenje Mandata od strane banke dužnika, ukoliko je zahtev podnet u
skladu sa zakonskim propisima kojima je predviđena mogućnost povlačenja, Procesor će odmah u
evidenciji Registra mandata promeniti status mandata (Mandat povučen), a banku poverioca obavestiti o
povlačenju Mandata.
Odogovornost za ispunjenost zakonskih uslova za povlačenje Mandata, snosi banka dužnika.
2.15. Pri podnošenju zahteva za povlačenje Mandata od strane banke poverioca, Procesor će odmah u
evidenciji Registra mandata promeniti status mandata (Mandat povučen), a banku dužnika obavestiti o
povlačenju Mandata.
2.16. Procesor je dužan da o svim odbijenim zahtevima za evidentiranje i izmenu Mandata odmah
obavesti podnosioca zahteva, na način predviđen ovim Uputstvom.
2.17. Za Mandate u kojima se ista banka javlja i kao banka dužnika i kao banka poverioca, sa stanovišta
ovih servisa, Procesor će smatrati primarnom njenu ulogu banke dužnika.
2.18. Procesor je dužan da po instrukcijama zaduženja (Collection) ispostavljenim po Mandatima koji su
evidentirani u Registru mandata izvrši dodatne kontrole u skladu ovim Uputstvom.
2.19. Poverilac je dužan da Nalog za naplatu ispostavi u potpunosti prema uslovima navedenim u
Mandatu i u rokovima predviđenim za Direktno zaduženje koji su definisani Operativnim pravilima.
Banka Poverioca može prihvatiti na realizaciju i Nalog za naplatu koji nije podnet u rokovima
predviđenim za Direktno zaduženje definisanim Operativnim pravilima, ali ne snosi odgovornost za
odbijanje instrukcije zaduženja (Collection-a) od strane Dužnika, odnosno banke dužnika po osnovu
kašnjenja.
2.20. Banka Poverioca je odgovorna za proveru usklađenosti podataka iz Mandata i ispostavljenog
Naloga za naplatu, kao i za generisanje i registrovanje instrukcije zaduženja (Collection) u skladu sa
podnetim Mandatom i Nalogom za naplatu.
2.21. Procesor je dužan da obavesti Banku Dužnika o svakoj ispostavljenoj instrukciji zaduženja
(Collection).
2.22. Ukoliko je Dužnik dostavio svojoj banci Mandat ili drugi vid ovlašćenja (saglasnosti) za izvršenje
zaduženja njegovog računa, račun nije u blokadi i na računu Dužnika ima dovoljno sredstava za
realizaciju instrukcije zaduženja (Collection), Banka Dužnika je dužna da izvrši ispostavljenu instrukciju,
pri čemu može izvršiti rezervaciju ili zaduženje iznosa za naplatu iz instrukcije zaduženja (Collection) sa
računa Dužnika, neposredno pre realizacije ciklusa Kliringa.
2.23. Ukoliko Dužnik pre termina predviđenog za realizaciju ciklusa Kliringa nije dostavio banci Mandat
ili drugi vid ovlašenja (saglasnosti) za izvršenje zaduženje njegovog računa, ili je račun Dužnika blokiran
po bilo kom osnovu iniciranom od strane odgovarajuće organizacije za sprovođenje postupka prinudne
naplate, ili na računu Dužnika nema ili nema dovoljno sredstava za realizaciju instrukcije zaduženja,
Banka dužnika je dužna da odbije instrukciju zaduženja (Collection), obaveznim obveštavanjem
Procesora o odbijanju, u skladu sa ovim Uputstvom.
Banka Dužnika ne mora odbiti instrukciju zaduženja (Collection) zbog nedostatka sredstava na računu
Dužnika ili bilo kojih drugih razloga koji su vezani za poslovni odnos banke sa Dužnikom (kreditiranje
klijenta, generalno ovlašćenje sa naknadnom dostavom pojedinačnog i dr.), pri čemu taj poslovni odnos
ne može dalje biti osnov za povraćaj sredstava po realizovanoj instrukciji zaduženja (Collection).
U slučaju odbijanja instrukcija zaduženja (Collection) zbog nedostatka raspoloživih sredstava na računu
dužnika i/ili blokade računa dužnika, Banka dužnika je dužna da inicira postupak prinudne naplate u
skladu sa zakonskim propisima.
2.24. U slučaju eksplicitnog neodbijanja ispostavljene instrukcije zaduženja (Collection) od strane Banke
Dužnika u rokovima predviđenim Operativnim pravilima i ovim Uputstvom, Procesor će smatrati
instrukciju zaduženja (Collection) prihvaćenom i uključiti je u ciklus Kliringa.
2.25. Procesor je dužan da o svim odbijenim i nerealizovanim instrukcijama zaduženja (Collection),
odmah obavesti banku poverioca i banku dužnika, na način predviđen ovim Uputstvom
2.26. Procesor je dužan da po završetku Kliringa i Obračuna dostavi informaciju Učesnicima o svi
realizovanim instrukcijama zaduženja (Collection), na način predviđen ovim Uputstvom
2.27. Učesnici su dužni da za realizaciju instrukcija zaduženja (Collection) obezbede dovoljno sredstava
na svojim računima u RTGS sistemu, kao i da usklađuju stanje računima u RTGS sistemu sa Limitom
zaduženja evidentiranog kod Procesoru, a koje su Učesnici dostavili Procesoru u skladu sa Operativnim
pravilima i ovim Uputstvom.
2.28. Učesnici su dužni da u slučajevima reklamacija predviđenim Operatinom pravilima, prihvate rešenja
Komisije za reklamacije kao osnov za izvršenje Direktnog zadužena kojim se vrši povraćaj sredstava
(Return) ili plaćanja od strana banke poverioca (Reversal), u skladu sa ovim Uputstvom. Direktna
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 325
zaduženja po rešenjima Komisije za reklamacije, Procesor uključuje u ciklus Kliringa bez dodatnih
ovlašćenja i verifikacije od strane Učesnika.
2.29. Procesor može ponuditi, a Učesnici pojedinačni ili zajedno prihvatiti, preuzimanje pojedinih prava i
obaveza definisanih Operativnim pravilima i ovim Uputstvom, prema unapred definisanim pravilima i
uslovima dogovorenim između Učesnika i Procesora.
3. S T R U K T U R A P O D A T A K A
3.1. Struktura podataka Mandata
3.1.1. Ugovorni odnos između Dužnika i Poverioca predstavlja pravni osnov za davanje Mandata kojim
Dužnik ovlašćuje svoga Poverioca da ugovorenog dana ili u datom periodu, jednokratno (one-off) ili
višekratno (recurrent) izvrši naplatu definisanog iznosa ili različitih iznosa sa njegovog računa prema
mehanizmu za obračun obaveze dužnika i u skladu sa uslovima navedenim u Mandatu.
3.1.2. Mandat potpisano i overeno od strane ovlašćenog lica Dužnika predstavlja personalizovani,
verifikovani Mandat Poveriocu za podnošenje instrukcija Direktnog zaduženja (u daljem tekstu: Mandat).
3.1.3. Osnovni elementi Mandata su definisani DS-01 strukturom SEPA pravila (papirni oblik), odnosno
Mandata u dematerijalizovanom obliku DS-02 strukturom SEPA pravila (elektronski oblik):
Element Mandata Mandatory/Optional
1. Jedinstveni identifikator Mandata. M
2. ID Dužnika (matični broj) M
3. Naziv Dužnika M
4. Adresa Dužnika M
5. Sedište Dužnika (poštanski broj i grad) M
6. Kod države rezidencije Dužnika (za Srbiju: RS) M
7. ID Poverioca (matični broj) M
8. Naziv Poverioca M
9. Adresa Poverioca M
10. Sedište Poverioca (poštanski broj i grad) M
11. Kod države rezidencije Poverioca (za Srbiju: RS) M
12. Broj računa Dužnika M
13. Naziv Banke Dužnika O
14. BIC Banke Dužnika M
15. Referenca Dužnika (poziv na broj Dužnika) O
16. Broj osnovnog ugovora (na osnovu koga je izdat Mandat) O
17. Pravni tekst M
18. Oznaka tipa Mandata (jednokratan, višekratan) M
19. Informacije za dodatne servise (AOS) O
20. Datum potpisa (ispostavljanja) Mandata (verifikovanog) M
21. Mesto potpisa Mandata M
22. Potpis Mandata (matični podaci ovlašćenog lica Dužnika i potpis) M
3.1.4. Elementi Mandata koji se odnose na dodatni servis evidentiranja mandata u Registru mandata
(Informacije za dodatne servise) su:
Datum dospeća prve
obaveze M
Dospeće prve obaveze. Ne može biti starije od datuma
ispostavljanja mandata niti mlađe od datuma isteka mandata
Datum isteka Mandata O
Datum kada prestaju obaveze dužnika po mandatu. Ne može biti
stariji od datuma ispostavljanja mandata niti od datuma dospeća
prve obaveze.
Broj obaveza po mandatu O Ukupan broj ugovorenih obaveza (maksimalan broj naloga za naplatu koje poverilac može podneti po mandatu)
Metrika dospeća O Dan/Mesec/Godina
Periodika dospeća u
datoj metrici O Broj kojim se definiše periodika dospeća u datoj metrici
Fiksni datumi dospeća O Fiksni datumi dospeća (osim prvog)
Period tolerancije O Period tolerancije dospeća u zadatoj metrici iskazan u danima (može biti „+“, „-“ ili „+-„)
Iznos plaćanja O Maksimalan iznos plaćanja koji se može javiti u nalogu zaduženja.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 326
Za jednokratne mandate je jednak ukupnom iznosu.
Za višekratne mandate sa jednakim iznosima obaveza,
predstavlja iznos pojedinačne obaveze.
Ukupan iznos plaćanja
po mandatu O Ukupan iznos plaćanja po mandatu
Valuta M Šifra valute iz ugovora
Kursna lista O Kurna lista NBS, banke i dr.
Vrsta kursa O Kupovni/srednji/prodajni
Dodatni uslovi plaćanja O Dodatni, nestruktuirani uslovi naplate
Povlačenje Mandata O Indikator povlačenja Mandata (od strane poverioca, odnosno dužnika u skladu sa zakonskim propisima)
Uslovi povlačenja O Nestruktuirani uslovi opozivosti Mandata (od strane poverioca)
3.1.5. Mandat može biti ispostavljen u papirnom ili elektronskom obliku.
3.1.6. Elemente zaštite i elektronski potpis Mandata ispostavljenog u elektronskom obliku utvrđuju
Dužnik i Poverilac, međusobno.
3.1.7. Osnovna pravila u vezi sa formom i sadržinom Mandata ispostavljenog u papirnom obliku:
- Jedinstveni identifikator Mandata je obavezni element Mandata, opredeljuje ga Poverilac koji je
dužan da obezbedi njegovu jedinstvenost (na nivou Poverioca);
- Nazivi polja u Mandatu (elemenata Mandata) moraju biti na najmanje jednom, a na najviše tri
jezika koja se koriste u zemlju rezidencije Dužnika;
- Mandat mora sadržati standardno zaglavlje: „Direct Debit Mandate“.
- Poleđina Mandata ne sme sadržati informacije koje se mogu pogrešno protumačiti kao deo
Mandata. Poleđina Manadata može sadržati isti tekst kao i prednja strana Mandata, ali na
drugom jeziku;
- Pravni tekst u Mandatu mora biti jasno izdvojen.
3.1.8. Procesor može definisati kao deo tehničkog uputstva, sadržaj i format obrasca Mandata u papirnom
obliku, a Učesnici u kliringu prihvatiti njegovu upotrebu (Prilog 3. Sadržaj i format Mandata u papirnom
obliku).
Ukoliko pravni tekst u Mandatu nije moguće upisati u predviđeni prostor prihvaćenog formata obrasca
Mandata zbog njegove dužine, može se dati u prilogu Mandata uz referisanje na prilog u delu Mandata
predviđenom za pravni tekst.
3.1.9. U okviru pružanja dodatnih usluga (AOS) Procesor može formirati i voditi Registar mandata u koji
banke dužnika i poverioca mogu u svakom trenutku životnog ciklusa Mandata (i pre prvog ili jedinog
dospeća) evidentirati Mandate svojih klijenata. Sadržaj poruka, njihova struktura i atributi za realizaciju
dodatnih servisa vođenja Registra mandata kao i tehničko uputstvo za primenu i način dostavljanja
poruka, definiše Procesor i stavlja na raspolaganje svim Učesnicima
3.1.10. Mandat se evidentira i čuva u Registru mandata u dematerijalizovanom obliku.
3.1.11. Mandata koji se registruje u Registru mandata se jedinstveno identifikuje na nivou identifikacije
poverioca (CreditorId) i identifikacije mandata (MandateId).
3.1.12. Jedistvenost identifikacije mandata obezbeđuje Poverilac.
Poverilac može preneti svoju obavezu obezbeđenja jedinstvenosti identifikacije Mandata na drugo pravno
lice (svoju banku, banku dužnika i dr.) pri čemu se identifikacija tog pravnog lica može navesti u strukturi
identifikatora mandata (MandateId) nakon, u tom slučaju, obavezne „-“ (npr: 1234-07123415, gde je
1234 identifikacija mandata, 07123415 identifikacija pravnog lica koje je izdali identifikaciju mandata i
garantuje njegovu jedinstvenost na nivou poverioca).
3.1.13. Odgovornost za validnost Mandata kao i ispravnost podataka iz Mandata koje Učesnici
dostavljaju Procesoru za upis u Registar mandata snose Učesnici.
3.2. Struktura podataka Naloga za naplatu
3.2.1. Struktura podataka kojom Poverilac inicira Direktno zaduženje u svojoj banci je definisana DS-03
strukturom SEPA pravila i sastoji se od podataka iz Mandata (struktura DS-02) i elemenata Naloga za
naplatu koji su definisani od strane Narodne Banke Srbije, Odlukom o obliku, sadržini i načinu korišćenja
jedinstvenih instrumenata platnog prometa (Nalog za naplatu):
Elementi Naloga za naplatu Mandatory/Optional
1. Način izvršenja (inicijalno nalozi naplate nisu hitni) O
2. ID Dužnika M
3. Naziv Dužnika M
4. Adresa Dužnika O
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 327
5. ID Poverioca M
6. Naziv Poverioca M
7. Adresa Poverioca O
8. Broj računa Poverioca po IBAN standardu M
9. Broj računa Dužnika po IBAN standardu M
10. Oznaka valute (za domaću valutu: RSD) M
11. Iznos zaduženja M
12. Svrha plaćanja M
13. Šifra plaćanja, u skladu sa vrstom ugovornog odnosa M
14. Model poziva na broj zaduženja M
15. Referenca Dužnika koja predstavlja Poziva na broj zaduženja M
16. Model poziva na broj odobrenja O
17. Referenca Poverioca koja predstavlja Poziva na broj odobrenja O
18. Mesto podnošenja naloga M
19. Datum podnošenja naloga M
20. Datum realizacije (datum valute) M
21. Overa naloga M
3.2.2. Nalog za naplatu može biti ispostavljen u papirnom ili elektronskom obliku.
3.2.3. Elemente zaštite i elektronski potpis Naloga za naplatu i Mandata ispostavljenog u elektronskom
obliku utvrđuju Poverilac i Banka Poverioca, međusobno.
3.2.4. Osnovna pravila u vezi sa formom i sadržinom Naloga za naplatu ispostavljenog u papirnom
obliku:
- Sadržaj i format Naloga za naplatu u papirnom obliku je definisan Odlukom o obliku, sadržini i
načinu korišćenja jedinstvenih instrumenata platnog prometa (NBS);
- Jedinstveni identifikator Naloga za naplatu (ID transakcije) je obavezni element Naloga za
naplatu, opredeljuje ga Banka Poverioca koja je dužna da obezbedi njegovu jedinstvenost na
nivou Banke Poverioca;
3.3. Struktura podataka instrukcije direktnog zaduženja
3.3.1. Struktura podataka kojom Banka Poverioca inicira Direktno zaduženje kod Procesora je definisana
DS-04 strukturom SEPA pravila (Collection) i predstavlja set dematerijalizovanih podata iz struktura
podataka DS-02 i DS-03:
Elementi instrukcije Mandatory/Optional
1. ID Direct Debit šeme (SerbianDDCollection) M
2. Datum realizacije (datum valute) M
3. ID transakcije M
4. Oznaka tipa transakcije u odnosu na tip Mandata
(one-off; first; last; reccurent) M
5. Iznos zaduženja M
6. Oznaka valute (za domaću valutu: RSD) M
7. Iznos obaveze u originalnoj (ugovorenoj) valuti O
8. Oznaka originalne valute O
9. Kurs za preračun iz originalne valute u valutu plaćanja O
10. Jedinstveni identifikator Mandata (ili Aneksa) po kome se
ispostavlja Collection (na nivou Poverioca). M
11. Datum ispostavljanja Mandata (verifikovanog) M
12. Jedinstveni identifikator originalnog Mandata (ukoliko se
Collection ispostavlja po Aneksu). O
13. ID Poverioca (matični broj) M
14. Naziv Poverioca M
15. Adresa Poverioca O
16. Sedište Poverioca (poštanski broj i grad) O
17. Kod države rezidencije Poverioca (za Srbiju: RS) M
18. Broj računa Poverioca po IBAN standardu M
19. BIC Banke Poverioca M
20. ID Dužnika (matični broj) M
21. Naziv Dužnika M
22. Adresa Dužnika O
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 328
23. Sedište Dužnika (poštanski broj i grad) O
24. Kod države rezidencije Dužnika (za Srbiju: RS) M
25. Broj računa Dužnika po IBAN standardu M
26. BIC Banke Dužnika M
26. Svrha plaćanja, M
27. Referenca Poverioca koja predstavlja Poziva na broj odobrenja O
28. Referenca Dužnika koja predstavlja Poziva na broj zaduženja M
29. Referenca dokumenta ili naziv dokumenta predviđen Mandatom O
30. Dodatna obrazloženja zaduženja O
3.3.2. Instrukcija zaduženja (Collection) predstavlja elektronski oblik Naloga za naplatu i Mandata koji je
dužnik predao svome poveriocu i svojoj banci.
3.4. Struktura podataka za odbijanje i storno instrukcija Direktnog zaduženja
3.4.1. Struktura podataka za kojom se vrši odbijanje instrukcije Direktnog zaduženja (Reject) i storniranje
realizovane instrukcije Direktnog zaduženja (Return ili Refund) po osnovu ustanovljene greške,
definisana je DS-05 strukturom SEPA pravila:
Elementi instrukcije Mandatory/Optional
1. ID instrukcije M
2. ID originalne instrukcije zaduženja (Collection) M
3. Tip instrukcije (Reject, Return, Refund Collection) M
4. Oznaka inicijatora instrukcije (Banka Dužnika, Banka Poverioca
ili Procesor za Reject, Banka Dužnika za Return i Dužnika za
Refund)
M
5. Kod razloga neprihvatanja instrukcije zaduženja M
6. Datum realizacije instrukcije (za Return i Refund) M
7. Kopija svih atrubuta originalne instrukcije (struktura DS-04) M
3.5. Struktura podataka za povraćaj sredstava
3.5.1. Struktura podataka za iniciranje povraćaja sredstava od strane Poverioca ili Banke Poverioca po
osnovu ustanovljene greške u realizovanoj instrukciji Direktnog zaduženjima (Reversal), definisana je
DS-07 strukturom SEPA pravila:
Elementi instrukcije Mandatory/Optional
1. ID Reversal instrukcije M
2. ID originalne instrukcije zaduženja (Collection) M
3. Oznaka inicijatora Reversal instrukcije (Poverilca ili Banka
Poverioca) M
4. Broj računa Poverioca iz originalne instrukcije po IBAN
standardu M
5. BIC Banke Poverioca iz originalne M
6. Datum realizacije Reversal instrukcije (datum valute) M
7. Iznos za povraćaj Reversal instrukcijom M
8. Oznaka valute (za domaću valutu: RSD) M
9. Iznos za povraćaj u ugovorenoj valuti O
10. Oznaka ugovorene valute O
11. Kurs za preračun iz ugovorene valute u valutu plaćanja O
12. Kod razloga povraćaj M
13. Kopija svih atrubuta originalne instrukcije (struktura DS-04) M
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 329
T O K O V I
3.6. Tokovi realizacije instrukcije direktnog zaduženja
3.7. Tokovi evidentiranja Mandata
4. P R O C E S I
4.1. Osnovni procesi Direktnih zaduženja (definisani SEPA pravilima)
Proces SEPA oznaka
1. Mandate Issuing – Izdavanje Mandata PR-01
2. Mandate Amendment – Izmena Mandata putem Aneksa PR-02
3. Mandate Cancellation – Povlačenje Mandata PR-03
4. Direct Debit – Realizacija Direktnog zaduženja PR-04
5. Reversal – Povraćaj sredstava PR-05
4.1.1. Osnovni koraci u procesu Izdavanja Mandata (PR-01)
Oznaka
koraka Korak
Mandatory/
Optional
PT-01.01 Generisanje, verifikacija Mandata od strane dužnika u
papirnom obliku i dostavljanje poveriocu
М
PT-01.02 Generisanje, verifikacija i razmena Mandata između dužnika i
poverioca u elektronskom obliku
М
PT-01.01a Dostavljanje Mandata banci dužnika od strane dužnika M
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 330
PT-01.02a
PT-01.03 Skladištenje (čuvanje) Mandata od strane poverioca М
PT-01.06a Dostavljanje Mandata procesoru od strane banke poverioca O
PT-01.06b Dostavljanje Mandata procesoru od strane banke dužnika O
PT-01.07 Dostavljanje informacija o Mandatu banci dužnika od strane
Procesora
O
PT-01.08 Odbijanje Mandata od strana banke dužnika O
PT-01.09a Evidentiranje Mandata u Registru mandata Procesora O
PT-01.09b Dostavljanje informacija o odbijanju Mandata banci poverioca
od strane Procesora
O
4.1.2. Osnovni koraci u procesu Izmene Mandata (PR-02)
Oznaka
koraka Korak
Mandatory/
Optional
PT-02.01 Generisanje, verifikacija Aneksa Mandata (Amendment) od
strane dužnika u papirnom obliku ili elektronskom obliku i
dostavljanje poveriocu
М
PT-02.01a
Dostavljanje Aneksa Mandata banci dužnika od strane dužnika
M
PT-02.02 Skladištenje Aneksa Mandata od strane poverioca М
PT-02.06a Dostavljanje Aneksa Mandata Procesoru od strane banke
poverioca
O
PT-02.06b Dostavljanje Aneksa Mandata Procesoru od strane banke
dužnika
O
PT-02.07 Dostavljanje informacija o Aneksu Mandata drugom učesniku
(banci dužnika ili banci poverioca)
O
PT-02.08 Odbijanje Aneksa Mandata od strana drugog učesnika (banke
dužnika ili banke poverioca)
O
PT-02.09a Evidentiranje Aneksa Mandata u Registru mandata O
PT-02.09b Dostavljanje informacija o odbijanju Aneksa Mandata banci
podnosiocu (banci dužnika ili banci poverioca)
O
4.1.3. Osnovni koraci u procesu Povlačenja Mandata (PR-03)
Oznaka
koraka Korak
Mandatory/
Optional
PT-03.01 Povlačenje Mandata od strane dužnika u papirnom ili
elektronskom obliku i dostavljanje poveriocu
М
PT-03.01a Dostavljanje informacije o povlačenju Mandata banci dužnika od
strane dužnika (Refusals)
M
PT-03.02 Skladištenje informacije o povlačenju Mandata od strane
poverioca
М
PT-03.06a Dostavljanje informacije o povlačenju Mandata Procesoru od
strane banke poverioca
M
PT-01.06b Dostavljanje informacije o povlačenju Mandata Procesoru od
strane banke dužnika
M
PT-01.07 Dostavljanje informacije o povlačenju Mandata drugom učesniku
od strane Procesora
M
PT-01.08 Evidentiranje promene statusa Mandata u Registru mandata
Procesora
M
PT-01.09 Dostavljanje informacija o odbijanju promene statusa Mandata
banci dužnika od strane Procesora
M
4.1.4. Osnovni koraci u procesu Direktnog zaduženja (PR-04)
Oznaka
koraka Korak
Mandatory/
Optional
PT-04.01 Generisanje Naloga za naplatu od strane Poverioca. М
PT-04.02 Obaveštenje o datumu i iznosu dospeća obaveze. Obaveštenje
upućuje Poverilac Dužniku.
О
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 331
PT-04.02bis Podnošenje instrukcije za neizvršenjem Direktnog zaduženja,
od strane Dužnika svojoj banci (Refusal)
O
PT-04.03 Ispostavljanje Naloga za naplatu i Mandata, od strane
Poverioca svojoj banci
М
PT-04.04 Odbijanje Naloga za naplatu od strane Banke Poverioca, zbog
neispravnosti iz tehničkih razloga i povraćaj Poveriocu
(Reject)
O
PT-04.05 Generisanje instrukcije Direktnog zaduženja (Collection) od
strane Banke Poverioca i podnošenje Procesoru
М
PT-04.06 Odbijanje Collection od strane Procesora, zbog neispravnosti
iz tehničkih razloga i povraćaj Banci Poverioca (Reject)
О
PT-04.07 Ispostavljanje instrukcije Direktnog zaduženja, od strane
Procesora Banci Dužnika (Collection)
М
PT-04.08 Odbijanje Collection od strane Banke Dužnika, zbog
neispravnosti iz tehničkih razloga i povraćaj Procesoru
(Reject)
О
PT-04.08a Potvrda prihvatanja Collection od strane Banke Dužnika O
PT-04.09 Zaduženje računa Dužnika od strane njegove banke po osnovu
instrukcije Direktnog zaduženja
М
PT-04.10 Podnošenje instrukcije za storniranje realizovane instrukcije
Direknog zaduženja, od strane Banke Dužnika Procesoru, po
osnovu međubankarske reklamacije (Return)
O
PT-04.11
Podnošenje instrukcije za storniranje realizovane instrukcije
Direknog zaduženja, od strane Procesora Banci Poverioca, po
osnovu međubankarske reklamacije (Return)
О
PT-04.12 Zaduženje računa Poverioca od strane njegove banke po
osnovu instrukcije za storniranje realizovane instrukcije
Direktnog zaduženja ispostavljene po međubankarskoj
reklamaciji (Return)
О
PT-04.13 Dužnik i Poverilac samostalno, bez uključenja banaka,
rešavaju sporove koji mogu nastati zbog različitog tumačenja
Mandata i neslaganja sa uslovima realizacije zaduženja
О
PT-04.14 Ukoliko je rešenje spora između Dužnika u Poverioca
postignuto sporazumom kojim je predviđena dodatna naplata
od strane Poverioca, ona se može realizovati podnošenjem od
strane Poverioca svojoj banci sporazuma koji predstavlja
aneks Mandat ili novi Mandati (Collection).
O
PT-04.15 Ukoliko je rešenje spora između Dužnika u Poverioca
postignuto sporazumom kojim je predviđeno vraćanje
sredstava Dužniku, on se može realizovati podnošenjem od
strane Dužnika svojoj banci sporazuma koji predstavlja aneksa
Mandata (Refund) ili novog Mandata (Collection) .
О
PT-04.16 U postupku vraćanja sredstava Dužniku, Banka Dužnika
upućuje Procesoru instrukciju za storniranje realizovane
instrukcije zaduženja i povraćaj sredstava (Refund)
О
PT-04.17 Povraćaj sredstava se može izvršiti i na inicijativu Poverioca
pri čemu Banka Poverioca podnosi Procesoru Instrukciju za
povraćaj sredstava (Reversal)
О
PT-04.18 Pre ispostavljanja instrukcije za povraćaj sredstava Banka
Poverioca vrši zaduženje računa Poverioca (Reversal)
О
4.1.5. Osnovni koraci u procesu Povraćaja sredstava (PR-05)
Oznaka
koraka Korak
Mandatory/
Optional
PT-05.01 Generisanje Naloga za plaćanje od strane Poverioca i ispostavljenje
Banci Poverioca.
М
PT-05.02 Zaduženje računa Poverioca, generisanje instrukcije za povraćaja
sredstava (Reversal) od strane Banke Poverioca i njeno
ispostavljanje Procesoru.
M
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 332
PT-05.03 Uključenje ispostavljene instrukcije za povraćaj sredstava u Kliring
i Obračun, od strane Procesora (CSMs)
М
PT-05.04 Odobrenje računa Dužnika od strane Banke Dužnika po izvršenom
Kliringu i Obračunu
M
4.2. Procesi za rešavanje izuzetaka i reklamacija
4.2.1. Ukoliko se u procesima Direktnog zaduženja detektuje bilo kakav problem koji nije iz domena
normalnog toka realizacije instrukcije Direktnog zaduženja (izuzetak), potrebno je pokrenuti odgovarajući
proces za rešavanje izuzetka i to:
Naziv procesa Opis
1. Revocation Zahtev za povlačenje Instrukcije Direktnog zaduženja, pre izvršenja ciklusa
Kliringa koji podnosi Poverilac svojoj Banci.
2. Request for
cancellation
Zahtev za povlačenje Instrukcije Direktnog zaduženja, pre izvršenja ciklusa
Kliringa, koji podnosi Banka Poverioca Procesoru
3. Refusal Zahtev Dužnika za neizvršenjem instrukcije Direktnog zaduženja iniciran pre
ciklusa Kliringa, ispostavljen od strane Dužnika, Banci Dužnika, po opozivim
Mandatima.
Po ovom zahtevu Banka Dužnika je dužna da odbije sve instrukcije Direktnog
zaduženje ispostavljene posle ispostavljanja Refusal zahteva (Reject). Na sve
instrukcije Direktnog zaduženja koje su realizovane pre ispostavljanja Refusal
zahteva, ovaj zahtev nema uticaja.
Dužnik može ispostaviti Refusal zahtev kada su ispunjeni uslovi predviđeni
zakonskim propisima (stečaj, likvidacija, smrt i dr.).
4. Reject Odbijanje ispostavljene instrukcije Direktnog zaduženja pre ciklusa Kliringa i
Obračuna zbog:
Tehničkih razloga koji obuhvataju pogrešan format podataka, pogrešnu dužinu
podataka, neispravne kontrolne cifre i dr.
Nemogućnosti realizacije instrukcije Direktnog zaduženja iz razloga koji su
razumljivi i prihvatljivi učesnicima (pre svega Dužniku i Poveriocu), a koji
obuhvataju nedostatak sredstava na računu Dužnika, blokadu računa Dužnika i
dr.
Podnetog zahteva Dužnika za neizvršenjem instrukcije Direktnog zaduženja
(Refusal)
Realizuje se dostavljanjem međubankarske instrukcije za odbijanje instrukcije
Direktnog zaduženja.
5. Return Storniranje realizovane Instrukcije Direktnog zaduženja, nakon izvršenja
instrukcije u ciklusu Kliringa i Obračuna, a po osnovu međubankarske
reklamacije podnete u roku od 10 dana od dana izvršenja međubankarskog
Obračuna.
Realizuje se ispostavljenjem instrukcije za storniranje instrukcije Direktnog
zaduženja od strane Banke Dužnika.
6. Refund Storniranje realizovane Instrukcije Direktnog zaduženja, nakon izvršenja
instrukcije u ciklusu Kliringa i Obračuna, a po osnovu reklamacije i
sporazuma Dužnika i Poverioca.
Realizuje se ispostavljenjem instrukcije za storniranje instrukcije Direktnog
zaduženja od strane Banke Dužnika.
7. Reversal Povraćaj sredstava nakon izvršenja instrukcije u ciklusu Kliringa i Obračuna,
od strane Poverioca (ili Banke Poverioca), a po osnovu ustanovljene greške
Poverioca (ili Banke Poverioca).
Realizuje se ispostavljanjem instrukcije za povraćaj sredstava po realizovanoj
instrukciji Direktnog zaduženja.
4.2.2. Postupak reklamacije na realizovane instrukcije Direktnog zaduženja odnosi se na:
- Reklamacije na ciklus Kliringa i Obračuna
o Obuhvataju reklamacije na Direktna zaduženja realizovana ili nerealizovana u ciklusu
Kliringa i Obračuna, a koje se odnose na propuste nastale u samom ciklusu Kliringa ili
Obračuna.
o Podnose se Procesoru u roku od 10 dana od dana završetka ciklusa Kliringa i Obračuna.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 333
o Odluku i rešenje po ovim reklamacijama donosi posebna komisija formirana u skladu sa
Operativnim pravilima.
o Realizuju se Return procesom na osnovu odluke Komisije, a pokreće ga Procesor.
- Međubankarske reklamacije
o Obuhvataju sporove i reklamacije na Direktna zaduženja realizovana ili nerealizovana u
ciklusu Kliringa i Obračuna, a koja se odnose na propuste učinjene od strane Učesnika i
rešavaju ih međusobno Učesnici.
o Učesnici mogu za ekspertizu i rešavanje sporova koristiti usluge posebna komisija
formirane u skladu sa Operativnim pravilima, pri čemu se angažovanjem Komisije
obavezuju za prihvatanje njene odluke po nastalom sporu.
o Realizuju se Return procesom na osnovu sporazuma Učesnika ili odluke Komisije, a
pokreće ga Banka Dužnika ili Reversal procesom koji pokreće Banka Poverioca.
- Reklamacije između Dužnika i Poverioca
o Obuhvataju nejasna, sporna i različita tumačenja sadržaja Mandata od strane Dužnika i
Poverioca i rešavaju ih međusobno Dužnik i Poverilac
o Realizuju na osnovu sporazuma Dužnika i Poverioca, Refund procesom koji pokreće
Banka Dužnika ili Reversal procesom koji pokreće Banka Poverioca.
5. P O R U K E
5.1. Poruke za realizaciju instrukcija Direktnog zaduženja
Poruka Oznaka poruke Oznaka strukture
1. Međubankarska instrukcija za odbijanje instrukcije Direktnog zaduženja (Reject) pacs.002.001.02 DS-05
2. Međubankarska instrukcija Direktnog zaduženja (Collection) pacs.003.001.01 DS-04
3. Međubankarska instrukcija za storniranje realizovane
instrukcije Direktnog zaduženja (Return/Refund) pacs.004.001.01 DS-05
4. Međubankarska instrukcija za povraćaj sredstava po
realizovanoj instrukciji Direktnog zaduženja (Reversal) pacs.007.001.01 DS-07
5.2. Poruke za međubankarski obračun.
Za realizaciju međubankarskog obračuna u RTGS sistemu Procesor generiše i šalje poruke MT202 u
SWIFT formatu, a u skladu sa tehničkim pravilima koja definiše Narodna banka Srbije
5.3. Ostale poruke Direktnog zaduženja:
Poruka Oznaka poruke
1. Zahtev za povlačenje instrukcije Direktnog zaduženja (Request and cancellation) paos.002.001.01
2. Izvod obračunskog računa Učesnika u Kliringu (Balance) paos.003.001.01
3. Upit u status instrukcije Direktnog zaduženja (Collection Query) paos.006.001.01
4. Odgovor na upit (Collection Response) paos.007.001.01
5. Informacija o neto poziciji Učesnika u ciklusu Kliringa (Confirmation) paos.008.001.01
6. Zahtev za postavljanje Limita zaduženja Učesnika (Limit) paos.009.001.01
5.4. Administratorske poruke
Poruka Oznaka poruke
1. Administratorska obaveštenje o sintaksnoj i tehničkoj neispravnosti
poruke koja ne uključuju kontrole predviđene poslovnim pravilima admi.002.001.01
2. Administratorska obaveštenja opšteg tipa (početak kliringa, kraj
kliringa i dr.) admi.004.001.01
5.5. Poruka transportnog nivoa
Poruka Oznaka poruke
1. Potvrda uspešanog/neuspešnog prijema poruke ACKNAK
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 334
5.6. Poruke za realizaciju dodatnih servisa vođenja Registra mandata
Poruka Oznaka poruke
1. Instrukcija za evidentiranje Mandata i izmenu Mandata u Registru mandata mndt.001.001.01
2. Instrukcija za povlačenje Mandata iz Registra mandata mndt.002.001.01
3. Instrukcija za odbijanje instrukcija za evidentiranje i izmenu Mandata. mndt.003.001.01
4. Instrukcija za prihvatanje instrukcija za evidentiranje i izmenu Mandata mndt.004.001.01
5. Zahtev za povlačenje instrukcija za evidentiranje, izmenu i povlačenje
Mandata (postojeće) mndt.005.001.01
6. Upit u sadržaj Registra mandata mndt.006.001.01
7. Odgovor na upit mndt.007.001.01
5.7. Sadržaj poruka, njihova struktura i atributi, kao i tehničko uputstvo za primenu i način dostavljanja
poruka, definiše Procesor i stavlja na raspolaganje svim Učesnicima.
5.8. Komunikaciju i način dostavljanja informacija, instrukcija, naloga i dokumenata između banaka i
njihovih klijenata (dužnici i poverioci) definišu banke i njihovi klijenti međusobno, uz preporuku da
koriste strukture i poruke predviđene SEPA pravilima (npr. poruke tipa pain.xxx.xxx.xx)
6. T E H N O L O Š K A P R A V I L A
6.1. Tehnološka pravila Registra mandata
6.1.1. Registrovanje Mandata
6.1.1.1. Banka dužnika i/ili banka poverioca može da podnese Procesoru zahtev za evidentiranje Mandata
u Registar mandata u svakom trenutku njegovog životnog ciklusa, slanjem poruke sa instrukcijom za
evidentiranje Mandata (mndt.001.001.01).
6.1.1.2. Instrukcija za evidentiranje Mandata će biti odbijena od strane Procesora ukoliko je Mandat već
evidentiran u Registru mandata, u bilo kom statusu.
6.1.1.3. Svaki zahtev za evidentiranje Mandata upućen od strane banke poverioca, Procesor je dužan da
uputi banci dužnika (originalnu instrukciju iz poruke mndt.001.001.01).
6.1.1.3.1. U roku od 2 (dva) radna dana od dana dostavljanja instrukcije za evidentiranje Mandata, banka
dužnika može:
- prihvatiti Mandat slanjem Procesoru poruke sa instrukcijom za prihvatanje Mandata
(mndt.004.001.01) na osnovu koje Procesor odmah evidentira Mandat u Registar mandata, a
banku poverioca obaveštava o registrovanom Mandatu upućivanjem originalne instrukcije za
prihvatanje Mandata (mndt.004.001.01)
- eksplicitno odbiti Mandat slanjem poruke sa instrukcijom za odbijanje (mndt.003.001.01), koju
Procesor odmah prosleđuje banci poverioca.
6.1.1.3.2. U slučaju da u roku od 2 (dva) radna dana od dana dostavljanja instrukcije za evidentiranje
Mandata banka dužnika ne izvrši prihvatanje ili odbijanje Mandata, Procesor će smatrati Mandat
implicitno odbijenim i generisati i poslati banci poverioca instrukciju za odbijanje (mndt.003.001.01) sa
obrazloženjem odbijanja.
6.1.1.3.3. Period od 2 (dva) radna dana podrazumeva dva puna poslovna dana do početka klirinškog
ciklusa u poslovnom dana u kome ističe rok za eksplicitno prihvatanje, odnosno odbijanje mandata.
6.1.1.4. Instrukcije za evidentiranje Mandata upućene od strane banke dužnika, Procesor odmah
evidentira u Registar mandata, a banku poverioca obaveštava o registrovanom Mandatu upućivanjem
originalne instrukcije za evidentiranje Mandata (mndt.001.001.01).
6.1.2. Izmena sadržaja Mandata
6.1.2.1. Izmene sadržaja Mandata se mogu odnositi na uslove, ograničenja i prava definisana Mandatom,
a nikako na izmenu dužnika i poverioca.
6.1.2.2. Banka dužnika i/ili banka poverioca mogu da podnesu Procesoru zahtev za evidentiranje izmene
sadržaja Mandata u Registar mandata u svakom trenutku njegovog životnog ciklusa, slanjem poruke sa
instrukcijom za evidentiranje izmene Mandata (mndt.001.001.01).
6.1.2.3. Instrukcija za izmenu sadržaja Mandata, pored izmenjenih elemenata, mora sadržati i sve druge,
neizmenjene podatke i informacije iz originalnog Mandata.
U Registru mandata jedini važeći Mandat je Mandata evidentiran kroz poslednju instrukciju za izmenu
Mandata..
6.1.2.4. Instrukcija za izmenu Mandata (mndt.001.001.01) će biti odbijena od strane Procesora ukoliko:
- Mandat nije evidentiran u Registru mandata
- Mandat je evidentiran u Registru mandata, ali je u neodgovarajućem statusu (nije aktivan)
- Izmena Mandata se odnosi na izmenu dužnika i/ili poverioca
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 335
- Postoji neusklađenost datuma potpisa aneksa sa datumom potpisa originalnog mandata, odnosno
prethodnog aneksa.
- Ukupan broj zaduženja predviđen izmenom Mandata je manji od broja realizovanih zaduženja
- Ukupan iznos zaduženja predviđen izmenom Mandata je manji od ukupno realizovanog iznosa
zaduženja
- Izmenom Mandata je predviđena promena bilo kog kontrolnog elementa koji nije moguće
primeniti od momenta izmene Mandata.
6.1.2.5. Za svaku izmenu sadržaja Mandata moraju biti saglasni i dužnik i poverilac, odnosno banka
dužnika i banka poverioca.
6.1.2.6. Svaki zahtev za izmenu Mandata podnet od strane banke dužnika ili banke poverioca, Procesor je
dužan da uputi drugoj banci (koja nije podnela zahtev) slanjem originalne instrukcije iz poruke
mndt.001.001.01.
6.1.2.6.1. U roku od 2 (dva) radna dana od dana dostavljanja instrukcije za izmenu Mandata, prijemna
banka može:
- prihvatiti izmenu Mandat slanjem Procesoru poruke sa instrukcijom za prihvatanje izmene
Mandata (mndt.004.001.01) na osnovu koje Procesor odmah evidentira izmenu Mandata u
Registar mandata, a banku koja je ispostavila zahtev za evidentiranjem izmene Mandata,
obaveštava upućivanjem originalne instrukcije za prihvatanje izmene Mandata
(mndt.004.001.01).
- eksplicitno odbiti izmenu Mandat slanjem poruke sa instrukcijom za odbijanje
(mndt.003.001.01), koju Procesor odmah prosleđuje banci koja je ispostavila zahtev za
evidentiranjem izmene Mandata.
6.1.2.6.2. U slučaju da u roku od 2 (dva) radna dana od dana dostavljanja instrukcije za evidentiranje
izmene Mandata banka primalac ne izvrši prihvatanje ili odbijanje izmene Mandata, Procesor će smatrati
izmenu Mandat implicitno odbijenom i generisati i poslati banci koja je ispostavila zahtev za
evidentiranjem izmene Mandata instrukciju za odbijanje (mndt.003.001.01) sa obrazloženjem odbijanja.
6.1.2.6.3. Period od 2 (dva) radna dana podrazumeva dva puna poslovna dana, do termina predviđenog za
početak klirinškog ciklusa u poslovnom dana u kome ističe rok za eksplicitno prihvatanje, odnosno
odbijanje izmene mandata.
6.1.2.7. U procesu realizacije izmene Mandata, do uključenja izmene Mandata u Registar mandata, važeći
(aktivan) je postojeći Mandata.
6.1.3. Povlačenje Mandata
6.1.3.1. Zahtev za povlačenje Mandata iz Registra mandata se može odnositi samo na osnovni Mandat, a
nikako na povlačenje aneksa. Povlačenje Mandata obuhvata i povlačenje svih aneksa tog Mandata.
6.1.3.2. Banka dužnika i/ili banka poverioca mogu da podnesu Procesoru zahtev za povlačenjem Mandata
u svakom trenutku njegovog životnog ciklusa, slanjem poruke sa instrukcijom za povlačenjem Mandata
(mndt.002.001.01).
Banka dužnika može podneti Procesoru zahtev za povlačenjem Mandata samo u slučajevima predviđenim
zakonom.
6.1.3.3. Instrukcija za povlačenje Mandata (mndt.002.001.01) će biti odbijena od strane Procesora
ukoliko:
- Mandat nije evidentiran u Registru mandata
- Mandat je evidentiran u Registru mandata, ali je u neodgovarajućem statusu (osnovni Mandat ili
poslednji Aneksa nije aktivan)
- Zahtev za povlačenje se odnosi na Aneks, a ne na osnovni Mandat
6.1.3.4. Instrukcije za povlačenje Mandata upućene od strane banke poverioca ili banke dužnika, Procesor
odmah realizuje povlačenjem Mandata iz Registra mandata, a drugu banku obaveštava o povlačenju
Mandata upućivanjem originalne instrukcije za povlačenje Mandata (mndt.002.001.01).
6.1.3.5. U procesu realizacije povlačenja Mandata, do povlačenja Mandata iz Registra mandata, Mandat
je u važećem statusu (aktivan).
6.1.4. Povlačenje instrukcije za evidentiranje, izmenu i povlačenje Mandata
6.1.4.1. Podnosilac instrukcije za evidentiranje, izmenu i povlačenje Mandata može bez obrazloženja
izvršiti povlačenje ispostavljene instrukcije (Request and cancellation), dostavljanjem Procesoru poruke
mndt.005.001.01.
6.1.4.2. Instrukcija za povlačenje instrukcije (mndt.005.001.01) će biti odbijena od strane Procesora
ukoliko je instrukcija za koju je podnet zahtev za povlačenje već realizovana.
6.1.4.3. O povučenoj instrukciji Procesor obaveštava učesnika kome je upućena originalna instrukcija
koja je povučena, dostavljanjem originalne instrukcije za povlačenje mndt.005.001.01.
6.1.5. Upit u Registar mandata
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 336
6.1.5.1. Svaki Učesnik u Kliringu može u toku poslovnog dana, osim u vremenu predviđenom za
realizaciju cilkusa Kliringa i Obračuna, od Procesora dobiti informacije o Mandatima u Registru mandata.
6.1.5.2. Upit se inicira generisanjem poruke mndt.006.001.01 od strane Učesnika i njenim dostavljenjem
Procesoru.
6.1.5.3. Procesor realizuje upit na osnovu trenutnog stanja u evidenciji Registra mandata, shodno
tehničkim mogućnostima u najkraćem mogućem roku, generisanjem poruke mndt.007.001.01 i
dostavljenjem Učesniku koji je inicirao upit.
6.1.6. Izveštavanje po instrukcijama Registra mandata
6.1.6.1. Procesor je dužan da administratorskom porukom admi.002.001.01 (sa specificiranim razlozima
odbijanja) odmah odbije u celosti poruku sa instrukcijama za Registar mandata zbog:
- tehničkih razloga koji obuhvataju pogrešan format ili strukturu poruke, eventualna tehnička
ograničenja veličine poruke i sl.;
- razloga koji su vezani za neispravnosti podataka u zaglavlju poruke.
6.1.6.2. Procesor je dužan da porukom mndt.003.001.01 (sa specificiranim razlozima odbijanja) odbije
pojedinačne instrukcije za Registar mandata koje ne zadovolje kontrole definisane tehničkim uputstvom,
a koje obuhvataju:
- tehničke razloga (pogrešan format podataka, neispravne kontrolne cifre i sl.);
- kontrole koje proističu iz ugovorenih dodatnih servisa Procesora.
Odbijene instrukcije zaduženja, Procesor označava u originalnoj poruci, u skladu sa Tehničkim
uputstvom, pre dostave originalne poruke drugoj banci.
6.2. Tehnološka pravila za realizaciju instrukcija direktnog zaduženja
6.2.1. Evidentiranje instrukcije direktnog zaduženja kod Banke Poverioca
6.2.1.1. Poverilac ispostavlja svojoj banci Nalog za naplatu zajedno sa Mandatom najmanje:
- 4 (četiri) dana pre dospeća obaveze Dužnika za jednokratne Mandate i prvog dospeća po
višekratnim Mandatima
- 3 (tri) dana pre dospeća obaveze Dužnika za ostala dospeća (osim prvog) po višekratnim
Mandatima.
- 2 (dva) dana pre dospeća obaveze Dužnika za Mandate koji su evidentirani u Registru mandata
Procesora i/ili u nespornom posedu Banke dužnika.
Način dostavljanja Mandata i Naloga za naplatu definišu međusobno Banka Poverioca i Poverilac.
6.2.1.2. Banka Poverioca može prihvatiti na realizaciju i Nalog za naplatu koji nije podnet u rokovima
definisanim Operativnim pravilima, ali ne snosi odgovornost za odbijanje instrukcije zaduženja
(Collection) od strane Dužnika po osnovu kašnjenja.
6.2.1.3. Banka Poverioca proverava usklađenost podataka iz verifikovanog Mandata i ispostavljenog
Naloga za naplatu i generiše instrukciju zaduženja (Collection) u skladu sa njima.
6.2.1.4. Banka Poverioca ispostavlja Procesoru instrukciju zaduženja (Collection), dostavljanjem poruke
pacs.003.001.01 najviše 15 (petnaest) dana pre datuma njenog dospeća, a najmanje:
- 3 (tri) dana pre dospeća obaveze Dužnika za jednokratne Mandate i prvog dospeća po
višekratnim Mandatima,
- 2 (dva) dana pre dospeća obaveze Dužnika za ostala dospeća (osim prvog) po višekratnim
Mandatima,
- 1 (jedan) dan pre dospeća obaveze Dužnika za Mandate koji su evidentirani u Registru mandata
Procesora i/ili u nespornom posedu Banke dužnika
Dostavljanjanje instrukcije zaduženja (Collection) Banka Poverioca vrši u skladu sa Terminskim planom
Procesora
6.2.1.5. Banka Poverioca može na zahtev Poverioca (Revocation), bez obrazloženja izvršiti povlačenje
(Request and cancellation) ispostavljene instrukcije zaduženja (Collection), dostavljanjem Procesoru
poruke paos.002.001.01, do termina predviđenog Terminskim planom za realizaciju ciklusa Kliringa za
datum naveden u instrukciji zaduženja (Collection). Procesor će izvršiti zahtev Banke Poverioca za
povlačenje instrukcije zaduženja (Collection), bez obzira na njegov trenutni status (prihvaćenost od strane
Banke dužnika).
O povučenoj instrukciji Procesor obaveštava Banku Dužnika dostavljanjem originalne instrukcije za
povlačenje paos.002.001.01.
6.2.2. Evidentiranje instrukcije direktnog zaduženja kod Procesora
6.2.2.1. Procesor evidentira instrukciju zaduženja (Collection) i ispostavlja je Banci Dužnika
dostavljanjem originalne poruke pacs.003.001.01 najmanje:
- 2 (dva) dana pre dospeća obaveze Dužnika za jednokratne Mandate i prvog dospeća po
višekratnim Mandatima,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 337
- 1 (jedan) dan pre dospeća obaveze Dužnika za ostala dospeća (osim prvog) po višekratnim
Mandatima i za Mandate koji su evidentirani u Registru mandata Procesora i/ili u nespornom
posedu Banke dužnika.
6.2.2.2. Procesor je dužan da administratorskom porukom admi.002.001.01 odmah odbije sve instrukcije
zaduženja (Collection), odnosno poruku u celosti, u zbog:
- razloga koji su vezani za neispravnosti podataka u zaglavlju poruke (neispravni računi Banke
dužnika ili Banke poverioca, status računa Banke Dužnika i/ili Banke Poverioca kod Procesora i
u RTGS sistemu, a koji obuhvataju blokadu računa Banke Dužnika i/ili Banke Poverioca,
isključenje iz kliringa Banke Dužnika i/ili Banke Poverioca, neispravne kontrolne sume i sl.)
- drugih, tehničkih razloga koji obuhvataju pogrešan format ili strukturu poruke, eventualna
tehnička ograničenja veličine poruke i sl.
6.2.2.3. Procesor je dužan da porukom pacs.002.001.02 (Reject) odbije one instrukcije zaduženja
(Collection) koje ne zadovolje kontrole definisane tehničkim uputstvom, a koje obuhvataju:
- tehničke razloga (pogrešan format podataka, neispravne kontrolne cifre i sl.)
- kontrole koje proističu iz ugovorenih dodatnih servisa Procesora
Odbijene instrukcije zaduženja, Procesor označava u originalnoj poruci, u skladu sa Tehničkim
uputstvom, pre dostave originalne poruke banci Dužnika.
6.2.2.4. Procesor može na osnovu informacija u Registru mandata pružiti učesnicima dodatne sevise u
realizaciji direktnih zaduženja koji se odnose na:
- Kontrolu Mandata u Registru mandata (evidentiranosti i statusa)
- Kontrolu usklađenosti sadržaja instrukcije direktnog zaduženja (Collection) sa struktuiranim
informacijama iz dematerijalizovanog oblika Mandata, evidentiranim u Registru mandata
6.2.2.4.1. Kontrola Mandata u Registru mandata (evidentiranosti i statusa) obuhvata:
- Kontrolu postojanja Mandata u evidenciji Registra mandata
- Ukoliko Mandat nije evidentiran u Registru mandata Procesora, realizacija instrukcije direktnog
zaduženja će biri sprovedena prema tehnološkom postupku definisanom Osnovnim uputstvom.
- Ukoliko je Mandat registrovan u evidenciji Registra mandata, vrši se kontrola statusa Mandata
- Ukoliko Mandat nije u aktivnom statusu, Procesor će odbiti podnetu instrukciju direktnog
zaduženja (Collection) slanjem podnosiocu Reject instrukcije.
- Ukoliko je Mandat evidentiran u Registru mandata i u aktivnom statusu, Procesor će izvršiti
kontrolu usklađenosti sadržaja instrukcije direktnog zaduženja (Collection) sa evidentiranim
Mandatom.
6.2.2.4.2. Kontrola usklađenosti sadržaja instrukcije direktnog zaduženja i evidentiranog Mandata
obuhvata:
- Kontrolu dužnika i poverioca.
o Provera usklađenosti podataka o dužniku i poveriocu.
- Kontrolu datuma dospeća.
o Datum dospeća iz instrukcije zaduženja ne može biti manji od datuma dospeća prvog
zaduženja niti veći od datuma isteka mandata definisanog u evidentiranom Mandatu.
o Datum dospeća iz instrukcije zaduženja mora biti u skladu sa datom metrikom, odnosno
sa fiksnim datumom dospeća, uz poštovanje nivoa tolerancije, definisanog u
evidentiranom Mandatu.
- Kontrolu ugovorne valute.
o Ugovorna valuta u instrukciji zaduženja mora biti usklađena sa ugovornom valutom
definisanom u evidentiranom Mandatu.
o Preračun u valutu plaćanja (RSD) u instrukciji zaduženja mora biti izvršen prema
pravilima (kurs, kursna lista) definisanim u evidentiranom Mandatu.
- Kontrolu iznosa zaduženja.
o Iznos zaduženja iz instrukcije zaduženja ne može bii veći od iznosa maksimalnog
pojedinačnog zaduženja definisanog u evidentiranom Mandatu
o Ukupan iznos realizovanih zaduženja po Mandatu sa uključenim iznosom zaduženja iz
instrukcije zaduženja ne može biti veći od ukupnog iznosa zaduženja definisanog u
evidentiranom Mandatu
6.2.2.5. Kontrola se vrši na osnovu struktuiranih podataka Mandata koji su evidentirani u Registru
mandata.
Za opcione podatke koji nisu dati u Mandatu, kontrola se ne vrši.
6.2.2.6. Kontrole instrukcija zaduženja na osnovu informacija iz Registra mandata je opciona, što znači da
učesnik, u svojstvu banke dužnika, može izabrati da li želi:
- Samostalno vršenje svih kontrola (statusa i usklađenosti Mandata i instrukcije zaduženja)
nezavisno od evidentiranosti u Registru mandata;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 338
- Potpunu kontrolu Procesora, koja podrazumeva odbijanje instrukcija koje ne zadovoljavaju
kontrolu usklađenosti Mandata i instrukcije zaduženja za Mandate evidentirane u Registru
mandata odbijanje i odbijanje svih instrukcija po Mandatima koji nisu evidentirani u Registru
mandata;
- Parcijalnu kontrolu Procesora, koja podrazumeva odbijanje instrukcija koje ne zadovoljavaju
kontrola usklađenosti Mandata i instrukcije zaduženja, za Mandate evidentirane u Registru
mandata i dostavljanje učesniku instrukcija po Mandatima koji nisu evidentirani u Registru
mandata.
6.2.2.7. Procesor je dužan da uključi u ciklus Kliringa sve instrukcije Direktnog zaduženja koje nisu
odbijene.
6.2.3. Evidentiranje instrukcije direktnog zaduženja kod Banke Dužnika
6.2.3.1. Banka Dužnika evidentira Collection i obaveštava svog klijenta – Dužnika o dospelom
Collection-u.
Obaveznost obaveštavanja o dospelom Collection-u, način i rokove obaveštavanja Dužnika od strane
Banke Dužnika, definišu Banka Dužnika i Dužnik međusobno.
6.2.3.2. Dužnik može dostaviti Banci Dužnika zahtev za neizvršenje instrukcije Direktnog zaduženja
(Refusal), sa obrazloženjem i zakonskim osnovom za opoziv Mandata, do termina predviđenog za
realizaciju ciklusa Kliringa za datum naveden u Collection-u, odnosno do termina predviđenog poslovnim
terminskom planom Banke Dužnika koji mora biti usklađen sa terminskim planom Procesora.
6.2.3.3. Banka dužnika može odbiti realizaciju Direktnog zaduženja po Collection-u (Reject)
dostavljanjem Procesoru poruke pacs.002.001.02 do termina predviđenog terminskim planom za
realizaciju ciklisa Kliringa za datum naveden u Collection-u zbog:
- nemogućnosti realizacije Collection-a iz razloga koji su vezani račun Dužnika, a koji obuhvataju
blokadu računa Dužnika i nedostatak sredstava na računu Dužnika.
- podnetog zahteva Dužnika za neizvršenjem instrukcije Direktnog zaduženja zbog opoziva
Mandata (Refusal)
- drugih, tehničkih razloga koji obuhvataju pogrešan format podataka, neispravne kontrolne cifre i
sl.
Ukoliko Banka Dužnika ne obavesti Procesora o odbijanju Collection-a, smatra se da je Collection
prihvaćen i može biti uključen u ciklus Kliringa.
6.2.3.4. Banka dužnika je dužna da u slučaju nemogućnosti realizacije instrukcije direktnog zaduženja
(Collection) zbog nedostatka sredstava i/ili blokade računa dužnika (Reject), inicira proces prinudne
naplate u skladu sa zakonskim propisima, slanjem odgovarajuće poruke organizaciji za sprovođenje
postupka prinudne naplate (poruka MT998 kao omotnica za poruku sopstvenog formata SMT710) sa
podacima iz instrukcije zaduženja (Collection).
6.2.4. Izveštavanje po instrukcijama direktnog zaduženja
6.2.4.1. Procesor može odbiti realizaciju instrukcija Direktnog zaduženja zbog:
- odbijanja Banke dužnika da realizacije Direktno zaduženja po Collection-u (Reject banke
dužnika)
- nemogućnosti realizacije Collection-a iz razloga koji su vezani za račun Banke dužnika kod
Procesora i u RTGS sistemu, a koji obuhvataju nedostatak sredstava na računu Banke dužnika,
blokadu računa Banke dužnika, nedovoljnog Limita, isključenja iz kliringa Banke dužnika i dr.
- nemogućnosti realizacije Collection-a iz razloga koji su vezani za status računa Banke poverioca
kod Procesora i u RTGS sistemu, a koji obuhvataju blokadu računa Banke poverioca, isključenje
iz kliringa Banke poverioca i dr.
6.2.4.2. Procesor je dužan da pre realizacije ciklusa Kliringa dostavi učesnicima poruke pacs.002.001.02
sa obaveštenjem o odbijanju instrukcija Direktnog zaduženja, za sve Collectione koji nisu uključeni u
ciklus Kliringa za datum naveden u Collection-u.
6.2.4.3. Procesor je dužan da po izvršenom ciklusu Kliringa, a pre realizacije obračuna u RTGS sistemu,
obavesti Učesnike o neto pozicijama u kliringu dostavljanjem poruke paos.008.001.01 (Confirmation).
6.2.4.4. Procesor je dužan da nakon izvršenog Obračuna u RTGS sistemu, obavesti Učesnike o svim
realizovanim Direktnim zaduženjima preko obračunskog računa Učesnika koji se vodi kod Procesora,
dostavljanjem Učesnicima kliringa poruke paos.003.001.01 sa izvodom obračunskog računa (Balance).
6.3. Tehnološka pravila za realizaciju ciklus Kliringa i Obračuna
6.3.1. Ciklus Kliringa za instrukcije Direktnog zaduženja čije je dospeće narednog dana Procesor
sprovodi jednom dnevno u skladu sa Terminskim planom za Kliring i Obračun po Direktnim
zaduženjima, a nakon zatvaranja RTGS sistema za prijem naloga za plaćanje.
6.3.2. Učesnici u kliringu i obračunu su dužni da obezbede Procesoru informaciju o maksimalnom iznosu
zaduženja njihovog računa u RTGS sistemu (u daljem tekstu: Limit zaduženja).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 339
6.3.3. Dostavljanje Limita zaduženja Procesoru, Učesnici vrše porukom paos.009.001.01.
Važeći Limit zaduženja, koji Procesor koristi u ciklusu Kliringa, je Limit zaduženja dostavljen u
poslednjoj paos.009.001.01 poruci.
6.3.4. Razlika u finansijskom iznosu između sume iznosa podnetih (prilivi) i sume iznosa primljenih
(odlivi) instrukcija Direktnog zaduženja sa računa klijenata jednog Učesnika predstavlja njegovu Neto
poziciju koja može biti pozitivna (više priliva nego odliva), negativna (više odliva nego priliva) i nulta
(jednako odliva i priliva).
Učesnici su dužni da obezbede na računu u RTGS sistemu dovoljno sredstava za realizaciju negativne
Neto pozicije, odnosno da dostavljanjem Limita zaduženja u skladu sa stanjem na računu u RTGS
sistemu, obezbede da njegova negativna Neto pozicija bude realizovana u Obračunu.
6.3.5. Procesor sprovodi ciklus Kliringa u sledećim koracima:
- Izračunavanje Neto pozicija.
o Vrši se na nivou obračunskih računa Učesnika u kliringu, njihovim zaduženjem i
odobrenjem u skladu sa svakom verifikovanom instrukcijom zaduženja. Stanje
obračunskog računa Učesnika po završetku obračuna predstavlja njegovu Neto poziciju.
- Primena Limita zaduženja.
o Za svakog Učesnika kod koga je negativna Neto pozicija veća od Limita zaduženja,
Procesor vrši odbijanje instrukcija zaduženja koje se odnose na zaduženje njegovog
računa, prema iznosu zaduženja (od najvećeg ka najmanjem), a do nivoa negativne
Neto pozicije jednake ili manje od Limita zaduženja, uz ponavljanje ciklusa Kliringa
(korak pod a., bez odbijenih instrukcija Direktnog zaduženja).
o odbijenim Direktnim zaduženjima Procesor odmah obaveštava učesnike slanjem poruka
pacs.002.001.02 (Reject)
- Verifikacija ciklusa Kliringa.
o Procesor vrši verifikaciju ciklusa Kliringa na taj način što za svakog Učesnika sa
negativnom Neto pozicijom u kliringu (u koracima pod a. i b.) obezbeđuje od RTGS
sistema potvrdu da na njegovom računu u RTGS sistemu ima dovoljno sredstava za
realizaciju obračunate negativne Neto pozicije.
o Procesor isključuje iz ciklusa Kliringa svakog Učesnika koji nema dovoljno sredstava
na računu u RTGS sistemu za realizaciju obračunate negativne Neto pozicije, vrši
odbijanje svih instrukcija Direktnog zaduženja koje se odnose na njega (zaduženja i
odobrenja), uz ponavljanje ciklusa Kliringa (korak pod a., bez odbijenih instrukcija
Direktnog zaduženja).
o odbijenim Direktnim zaduženjima Procesor odmah obaveštava Banke Poverioca
slanjem poruka pacs.002.001.02 (Reject Collection)
6.3.6. Obračun za verifikovani ciklus Kliringa, Procesor sprovodi na dan dospeća, odmah po otvaranju
RTGS sistema za prijem naloga za plaćanje.
6.3.7. Procesor realizuje Obračun preko svog obračunskog računa i računa Učesnika u RTGS sistemu,
porukama MT202 u swift formatu definisanim ovim Uputstvom, koje dostavlja i realizuje u RTGS
sistemu u sledećem redosledu:
- Sve poruke za realizaciju negativne Neto pozicije, kojima se vrši zaduženje računa Učesnika sa
negativnom Neto pozicijom u ciklusu Kliringa i odobrenje obračunskog računa Procesora
- Sve poruke za realizaciju pozitivne Neto pozicije, kojima se vrši zaduženje obračunskog računa
Procesora i odobrenje računa Učesnika sa pozitivnom Neto pozicijom u ciklusu Kliringa.
6.4. Tehnološka pravila za realizaciju izuzetaka i reklamacija
6.4.1. Po ustanovljenoj grešci u realizovanoj instrukciji Direktnog zaduženja, povraćaj sredstava sa
računa Poverioca i/ili Banke Poverioca mogu inicirati:
- Poverilac ili Banka Poverioca, u bilo kom trenutku nakon ciklusa Kliringa i Obračuna u kome je
realizovana instrukcija Direktnog zaduženja (Reversal).
o Povraćaj sredstava se realizuje generisanjem pacs.007.001.01 od strane Banke
Poverioca i njenim slanjem Procesoru koji je uključuje u odgovarajući ciklus Kliringa.
- Procesor, po odluci Komisije za rešavanje reklamacija koje se odnose na propuste nastale u
ciklusu Kliringa i Obračuna, i međubankarske reklamacije, podnete u roku od 10 dana od dana
ciklusa Kliringa i Obračuna u kome je realizovana instrukcija Direktnog zaduženja (Return).
o Povraćaj sredstava se realizuje generisanjem poruke pacs.004.001.01 od strane
Procesora i njenim uključenjem u odgovarajući ciklus Kliringa.
- Dužnik ili Banka Dužnika, na osnovu sporazuma Dužnika i Poverioca ili Banke Dužnika i Banke
Poverioca u bilo kom trenutku nakon ciklusa Kliringa i Obračuna u kome je realizovana
instrukcija Direktnog zaduženja (Refund).
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 340
o Povraćaj sredstava se realizuje generisanjem pacs.004.001.01 od strane Banke Dužnika
i njenim slanjem Procesoru koji je uključuje u odgovarajući ciklus Kliringa po istom
tehnološkom postupku koji se primenjuje za Collection (pacs.003.001.01), sa
izmenjenim ulogama učesnika (Poverilac:Dužnik, Banka Poverioca:Banka Dužnika).
6.4.2. Procesor je dužan da evidentira instrukcije za realizaciju izuzetaka i reklamacija.
6.4.3. Procesor je dužan da administratorskom porukom adm.002.001.01 odmah odbije sve instrukcije za
realizaciju izuzetaka i reklamacija, odnosno primljene poruke u celosti, u zbog:
- razloga koji su vezani za neispravnosti podataka u zaglavlju poruke (neispravni računi Banke
dužnika ili Banke poverioca, status računa Banke Dužnika i/ili Banke Poverioca kod Procesora i
u RTGS sistemu, a koji obuhvataju blokadu računa Banke Dužnika i/ili Banke Poverioca,
isključenje iz kliringa Banke Dužnika i/ili Banke Poverioca, neispravne kontrolne sume i sl.)
- drugih, tehničkih razloga koji obuhvataju pogrešan format ili strukturu poruke, evevntualna
tehnička ograničenja veličine poruke i sl.
6.4.4. Procesor je dužan da porukom pacs.002.001.02 (Reject) odmah odbije one za realizaciju izuzetaka
i reklamacija koje ne zadovolje kontrole definisane tehničkim uputstvom, a koje obuhvataju:
- tehničke razloga (pogrešan format podataka, neispravne kontrolne cifre i sl.)
- kontrole koje proističu iz ugovorenih dodatnih servisa Procesora
Odbijene instrukcije zaduženja, Procesor označava u originalnoj poruci, u skladu sa Tehničkim
uputstvom, pre dostave originalne poruke drugom učesniku.
6.5. Ostali servisi
6.5.1. Svaki Učesnik u Kliringu može u toku poslovnog dana, osim u vremenu predviđenom za realizaciju
cilkusa Kliringa i Obračuna, od Procesora dobiti informacije o podnetim instrukcijama Direktnog
zaduženja u kojima se Učesnik javlja u svojstvu Dužnika, Banke Dužnika, Poverioca ili Banke Poverioca.
Upit se inicira generisanjem poruke paos.006.001.01 od strane Učesnika i njenim dostavljenjem
Procesoru (Collection Query).
6.5.2. Procesor realizuje upit, shodno tehničkim mogućnostima u najkraćem mogućem roku,
generisanjem poruke paos.007.001.01 i dostavljenjem Učesniku koji je inicirao upit (Collection
Response).
6.5.3. Procesor može u okviru dodatnih opcionih servisa (AOS - Additional Optional Service) ponuditi
Učesnicima pružanje i drugih usluga (vođenje evidencija, izveštavanje klijenata i dr.) u skladu sa unapred
definisanim pravilima prihvaćenim od strane Učesnika i Procesora.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 341
Prilog 3:
TERMINSKI PLAN ZA SISTEM KLIRINGA I OBRAČUNA PO DIREKTNIM
ZADUŽENJIMA
Radno vreme Kliringa i Obračuna
Radno vreme Procesora za realizaciju poslova kliringa i obračuna po Direktnim zaduženjima je od 8.00
do 22.00 časova.
Dnevni terminski plan Kliringa i Obračuna
Dnevni terminski plan rada Procesora za prijem i slanje poruka, Kliring i realizaciju Obračuna u RTGS
sistemu je:
Opis poslovnog procesa
Oznaka
poruke
Dnevni
termin
realizacije
Razmena poruka sa instrukcijama Direktnog zaduženja, za uključenje
u ciklus Kliringa koji se odnosi na dospeća narednog dana
pacs.003.001.01
pacs.004.001.01
pacs.007.001.01
09.00 – 17.00
Razmena poruka sa instrukcijama Direktnog zaduženja, za uključenje
u ciklus Kliringa koji se odnosi na dospeća ostalih dana posle
narednog dana, a najduže 15 dana pre dospeća
pacs.003.001.01
pacs.004.001.01
pacs.007.001.01
09.00 – 19.00
Razmene poruka za povlačenje podnetih instrukcija Direktnog
zaduženja
paos.002.001.01 09.00 – 18.00
Razmene poruka za odbijanje instrukcija Direktnog zaduženja paos.002.001.02 09.00 – 18.00
Razmena porukama za upit u status instrukcija od strane Učesnika i
odgovor Procesora
paos.006.001.01
paos.007.001.01
09.00 – 19.00
Dostava poruka za promenu/postavljanje Limita zaduženja Učesnika paos.009.001.01 09.00 – 19.00
Realizacija ciklusa Kliringa za instrukcije sa dospećem narednog dana,
koja obuhvata i proveru usaglašenosti Limita zaduženja i negativne
Neto pozicije Učesnika sa stanjem na računu Učesnika u RTGS
sistemu
19.00 – 21.00
Dostava poruka sa informacijama o neto poziciji Učesnika u ciklusu
Kliringa realizovanom za tekući dan kao datum dospeća, a pre
realizacije Obračuna
paos.008.001.01 08.00 – 09.00
Realizacija Obračuna u RTGS sistemu po ciklusu Kliringa
realizovanom za tekući dan kao datum dospeća
MT202 09.00 – 10.00
Dostava izvoda obračunskog računa Učesnika u ciklusu Kliringa
realizovanom za tekući dan kao datum dospeća, u danu u kome je
realizovan Obračun
paos.003.001.01 10.00 – 12.00
Dostava administrativnih poruka Procesora admi.002.001.01
admi.004.001.01
08.00 – 21.00
Procesor može započeti obračun u ciklusu Kliringa po završetku prijema naloga za plaćanje u RTGS
sistemu, što znači da će u slučaju produženja rada RTGS sistema za prijem naloga za plaćanje, dnevni
terminski plan rada Procesora u delu realizacije ciklusa Kliringa biti pomeren za vreme produženja rada
RTGS sistema.
Dnevni terminski plan za dodatne servise
Dnevni terminski plan rada Procesora sa Registrom mandata je:
Opis poslovnog procesa Oznaka Poruke
Dnevni termin
realizacije
Razmena poruka sa instrukcijama za evidentiranje i
izmenu Mandata u Registru mandata
mndt.001.001.01 09.00 – 17.00
Razmene poruka za povlačenje Mandata iz Registra
mandata
mndt.002.001.01 09.00 – 17.00
Razmene poruka za odbijanje instrukcija za
evidentiranje i izmenu Mandata
mndt.003.001.02 09.00 – 18.00
Razmene poruka za prihvatanje i izmenu Mandata mndt.004.001.01 09.00 – 18.00
Razmene poruka za povlačenje podnetih instrukcija mndt.005.001.01 09.00 – 18.00
Razmena poruka za upit u sadržaj Registra mandata od
strane Učesnika i odgovor Procesora
mndt.006.001.01
mndt.007.001.01
09.00 – 18.00
Dostava administrativnih poruka Procesora admi.002.001.01 09.00 – 19.00
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 342
Prilog 4.
M A N D A T, Sadrzaj i forma
SEPA Direct Debit Mandate Broj ovlašćenja:
__________________
Broj ugovora:
__________________
Potpisom ove forme dužnik daje ovlašćenje:
(A) Poveriocu da ispostavi instrukciju za zaduženje računa dužnika u skladu sa uslovima navedenim u
ovlašćenju;
(B) Banci dužnika da zadužuje račun dužnika u skladu sa instrukcijama poverioca, sa pravom da izvrši
rezervaciju potrebnih sredstava na računu dužnika pre realizacije međubankarskog plaćanja.
Prava dužnika i poverioca koja se odnose na reklamacije po osnovu realizovanih plaćanja, kao i rokovi i
način povraćaj sredstava su definisani Operativnim pravilima za realizaciju direktnih zaduženja koja se
mogu dobiti od banke.
D U Ž N I K: _________________________________________________________________
Sedište i adresa: _________________________________________________________________
Matični broj: __________________________ Poreski broj:
_________________________
POVERILAC: _________________________________________________________________
Sedište i adresa: _________________________________________________________________
Matični broj: __________________________ Poreski broj:
_________________________
USLOVI PLAĆANJA
Datum dospeća prve obaveze: _______________ Datum isteka ovlašćenja:
______________
Ukupan broj obaveza po ovlašćenju: _________ Periodika dospeća:
___________________
Ukupni iznos obaveza po ovlašćenju: ___________________ Šifra valute:
______________
Iznos pojedinačnih obaveza: _________________________ Šifra valute:
______________
DODATNI USLOVI DOSPEĆA: _________________________________________________
_________________________________________________________________________________
OPOZIVOST I USLOVI OPOZIVOSTI OVLAŠĆENJA:
Neopozivo do datuma isteka, osim u slučajevima predviđenih zakonom.
BANKA DUŽNIKA: _____________________________________________________________
BROJ RAČUNA DUŽNIKA: ____________________________________________________
Datum izdavanja ovlašćenja: __________________
IZDAVALAC OVLAŠĆENJA BANKA DUŽNIKA
_____potpis ovl. lica i pečat dužnika________ __ potpis ovl. lica i pečat banke
dužnika___
Ime, prezime i JMBG ovl. lica dužnika Ime i prezime ovl. lica i BIC banke
dužnika
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 343
Prilog 5:
TEHNIČKO UPUTSTVO
ZA PORUKE DIREKTNOG ZADUŽENJA
PORUKA pacs.003.001.01 COLLECTION
Struktura: SerbianCollection
• Koristi se za iniciranje i izvršenje transakcija direktnog zaduženja
• Generiše je banka poverioca i Ispostavlja procesoru
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transkacija
direktnog zaduženja iz poruke i tela poruke (Transaction Information) koje nosi informacije o
pojedinačnim transakcijama direktnog zaduženja koje banka inicira.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis i poslovna pravila
1.0 M 1 + Header GroupHeader20 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke.
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke.
1.5 M 1 + + NumberTransaction Max15NumericText Ukupan broj transakcija u
poruci
1.7 M 1 + + TotalAmount EuroMax15Amount Ukupan iznos transakcija
u poruci
1.7 M 1 + + + Amount Decimal, 15,2 Ukupan iznos transakcija
u poruci
1.7 M 1 + + + Currency Code EuroCurrencyCode Kod domaće valute: RSD
1.8 M 1 + + SettlementDate ISODate Datum međubankarskog
obračuna
1.9 M 1 + + SettlementInformation SettlementInformation
12
Informacije o obračunu
1.10 M 1 + + + SettlementMethodCode SettlementMethod2Co
de
Vrednost: CLRG
1.12 M 1 + + + ClearingSystem ClearingSystemIdentific
ation1Choice
Identifikacija klirinškog
sistema
1.13 M 1 + + + + ClearingSystemIdentificat
ion
CashClearingSystem3
Code
Vrednost: KIB
1.15 M 1 + + PaymentTypeInformation PaymentTypeInformat
ion
Informacije o tipu platnog
servisa
1.17 M 1 + + + ServiceLevel ServiceLevelIdentifica
tion
Identifikacija platnog
servisa
1.18 M 1 + + + + ServiceCode ServiceLevelCode Vrednost: SEPA
1.26 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.26 M 1 + + + AgentId FinancialInstitutionIden
tification4
Identifikacija pošiljaoca
poruke
1.26 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.27 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.27 M 1 + + + AgentId FinancialInstitutionIden
tification4
Identifikacija primaoca
poruke
1.27 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation DirectDebitTransactio
nInformation5
Telo poruke instrukcije
zaduženja
2.1 M 1 + + PaymentId PaymentIdentificatio
n2
Identifikatori plaćanja
2.1 M 1 + + + EndToEndId Max35Text Poziv na broj Poverioca
ili „NONPROVIDED“.
2.1 M 1 + + + TransactionId Max35Text Jedinstveni Id transakcije
podnosioca instrukcije.
2.2 M 1 + + PaymentType PaymentTypeInformati
on8
Tip plaćanja
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 344
2.11 M 1 + + + SequenceType SequenceType1Code Vrednosti:
FRST,RECR,FINL,ONEO
2.12 M 1 + + + CategoryPurpose CategoryPurposeCode Vrednosti:
02 – za ovlašćenje
definisana od strane
banaka na nivou UBS
03 – za ostala ugovorna
ovlašćenja
2.13 M 1 + + SettlementAmount EuroMax15Amount Iznos transakcije
2.13 M 1 + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti
2.13 M 1 + + + CurrencyCode EuroCurrencyCode Kod domaće valute: RSD
2.15 O 0-1 + + InstructedAmount CurrencyAndAmount Iznos transakcije,
ugovorena valuta
2.15 O 0-1 + + + Amount Decimal, 9,2 Ugovoreni iznos zaduženja
2.15 O 0-1 + + + CurrencyCode CurrencyCode Kod ugovorene valute
2.16 O 0-1 + + ExchangeRate BaseOneRate Kurs ugovorene valute
2.17 M 1 + + ChargeBearerCode ChargeBearerType2C
ode
Vrednost: SLEV
2.19 M 1 + + RequestedDate ISODate Datum dospeća
(DueDate)
2.20 M 1 + + DirectDebitTransaction DirectDebitTransacti
on4
Informacija o direktnom
zaduženju
2.21 M 1 + + + MandateInformation MandateRelatedInforma
tion4
Informacije o mandatu
2.22 M 1 + + + + MandateId Max35Text Identifikacija mandata ili
aneksa
2.23 M 1 + + + + DateSignature ISODate Datum potpisivanja
mandata/aneks
2.24 M 1 + + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa: TRUE,
FALSE
2.25 O 0-1 + + + + AmendmentInformation AmendmentInformatio
nDetails4
Informacije o osnovnom
mandatu
2.26 O 0-1 + + + + + OriginalMandatId Max35Text Identifikator osnovnog
mandata
2.40 M 1 + + + CreditorIdInformation CreditorIdentificationIn
formation
Informacija o identifikaciji
creditora
2.40 M 1 + + + + CreditorId Max35Text Id Poverioca, matični broj
ili Jmbg
2.43 M 1 + + Creditor PartyIdentification13 Poverilac
2.43 M 1 + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-2 + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + CreditorAccount CashAccount8 Broj računa poverioca
2.44 M 1 + + + AccountId AccountIdentification
2
Identifikacija računa
poverioca
2.44 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + AgentId FinancialInstitutionIden
tification4
Identifikacija banke
poverioca
2.43 M 1 + + + + BICAgent BIC Identifier BIC banke poverioca
2.47 O 0-1 + + UltimateCreditor Institution2 Pravni subjekt
2.47 O 0-1 + + + Identification InstitutionIdentificatio
n
Identifikacija pravnog
subjekta
2.47 O 0-1 + + + + OrganisationId PIBIdentifier PIB poverioca, Obavezno
za pravne subjekte, Za
preduzetnike JMBG
2.57 M 1 + + Debtor PartyIdentification19 Dužnika
2.57 M 1 + + + DebtorId Max35Text Id dužnika, matični broj ili
Jmbg
2.57 M 1 + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa dužnika
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 345
2.57 O 0-2 + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + AccountId AccountIdentification
2
Identifikacija računa
dužnika
2.58 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + AgentId FinancialInstitutionIden
tification4
Identifikacija banke
dužnika
2.59 M 1 + + + + BICAgent BIC Identifier BIC banke dužnika
2.61 O 0-1 + + UltimateDebtor Institution2 Pravni subjekt
2.61 O 0-1 + + + Identification InstitutionIdentificatio
n
Identifikacija pravnog
subjekta
2.61 O 0-1 + + + + OrganisationId PIBIdentifier PIB dužnika
Obavezno za pravne
subjekte
Za preduzetnike JMBG
2.62 M 1 + + Purpose Purpose1Choice Informacija o svrsi
plaćanja
2.62 M 1 + + + Purport Max35Text Svrhe plaćanja sa šifrom
plaćanja :
XXX–svrha plaćanja
2.81 O 0-1 + + RemmitanceInformation RemittanceInformati
on3
Informacije o plaćanju
2.82 O 0-1 + + + UnstructuredRemmitance Max140Text Nestruktuirane informacije
o plaćanju
2.83 O 0-1 + + + StructuredRemmitance StructuredRemittanceIn
formation6
Struktuirane informacije o
plaćanju
2.84 O 0-1 + + + + ReferredDocument ReferredDocumentInf
ormation1
Dokumentovanje plaćanja
2.84 O 0-1 + + + + + DocumentType ReferredDocumentTy
pe1
Dokument
2.84 O 0-1 + + + + + + Purport Max35Text Naziv dokumenta
2.97 O 0-1 + + + + CreditorReference CreditorReferenceInfo
rmation1
Referisanje poverioca na
identifikator dužnika
2.97 O 0-1 + + + + + ReferenceType CreditorReferenceTyp
e1
Referenca
2.97 O 0-1 + + + + + + Purport Max35Text Poziv na broj dužnika
2.105 O 0-1 + + + + AdditionalRemmitanc Max140Text Dodatne informacije o
plaćanju
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od SettlementDate
1.5 NumberTransaction Veći od nule.
Broj instrukcija u poruci, odnosno broj ponavljanja
TransactionInformation
1.7 TotalAmount .Amount Suma iznosa transakcija, odnosno
suma SettlementAmount iz svake instrukcija
1.7 TotalAmount . Currency Code Vrednost: RSD
1.8 SettlementDate Veći od tekućeg datuma, a manji od tekućeg datuma+16 dana
1.10 SettlementMethodCode Vrednost: CLRG
1.13 ClearingSystemIdentification Vrednost: KIB
1.26 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.27 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.1 PaymentId. EndToEndId Predstavlja ID Collection instrukcije koji generiše Poverilac i
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 346
preko koga Poverilac identifikuje transakciju. Ukoliko
Poverilac ne podnese ovaj ID svojoj banci, vrednost je
„NONPROVIDED“.
Strukturapoziva na broj poverioca u domaćem platnom
prometu:
MMPPPPPPPPPPPPPPPPPPPP, gde je:
MM – model poziva na broj sa vrednošću 97 ili „ „
PPPPPPPPPPPPPPPPPPPP – poziv na broj poverioca.
Kontrola strukture ili vrednosti „NONPROVIDED“.
2.1 PaymentId. TransactionId Predstavlja ID Collection instrukcije koji generiše banka
Poverioca i preko koga banka Poverioca identifikuje
transakciju.
Maksimalna dužina: Max32Text., osim u slučaju greške
kada je Max35Text.
U slučaju odbijanja instrukcije od strane Procesora zbog
ustanovljene greške (Reject procesora), drugom učesniku se
dostavlja Iinstrukcije u kojoj TransactionId započinje sa
ERR+originalni TransactionId
2.11 PaymentType.SequenceType Vrednosti: FRST, RECR, FINL, ONEO
FRST – prvo plaćanje po višestrukom mandatu
RECR – ostala plaćanja po višestrukom mandatu osim prvog i
poslednjeg
FINL – poslednje plaćanje po višestrukom mandatu
ONEO – plaćanje po jednostukom mandatu
2.12 PaymentType.CategoryPurpo
se
Vrednosti: 02, 03
02 – za ovlašćenja kao osnov naplate koja su u posedu banke
dužnika (poseban tip mandata definisan na od strane banaka na
nivou UBS,)
03 – za ostala ugovorna ovlašćenja kao osnov naplate (opšti tip
mandata)
2.13 SettlementAmount. Amount Veći od nule
2.13 SettlementAmount.
CurrencyCode Vrednost: RSD
2.15 InstructedAmount. Amount Veći od nule.
Moguća eventualna kontrola (po zahtevu) preračuna u domaću
valutu:
InstructedAmount* ExchangeRate=
SettlementAmount.Amount
2.15 InstructedAmount.
CurrencyCode
Moguća eventualna kontrola (po zahtevu) da je kod valute iz
šifarnika dozvoljenih valuta
2.16 ExchangeRate Veći od nule
2.17 ChargeBearerCode Vrednost: SLEV
2.19 RequestedDate Manji ili jednak SettlementDate. Uobičajeno, jednak datumu
međubankarskog obračuna (SettlementDate), ali može biti i
manji od njega u slučaju da je mandatom dozvoljena naplata
u periodu od više dana od datuma dospeća
2.22 MandateId Jedinstveni identifikator mandata ili aneksa koji generiše
Poverilac i obezbeđuje njegovu jedinstvenost (na nivou
Poverioca).
Struktura mandata ID:
a) Identifikacija mandata ili aneksa-Identifikacija
pravnog lica koje je izdalo identifikaciju mandata ili
aneksa i garantuje njegovu jedinstvenost na nvou
Poverioca, ili
b) Identifikacija mandata ili aneksa (bez crtice)
2.23 DateSignature Manji od datuma dospeća (RequestedDate)
2.24 AmendmentIndicator TRUE – ukoliko se instrukcija podnosti po osnovu aneksa
mandata
FALSE – ukoliko se instrukcija podnosi po osnovu mandata
2.25 AmendmentInformation Ukoliko je AmendmentIndicator =TRUE, odnosno ukoliko se
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 347
instrukcija podnosi po osnovu aneksa mandata, potrebno je
dati i referencu (ID) osnovnog mandata .
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
2.40 CreditorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku pravnom
licu
JMBG, dužine 13 – ukoliko se radi o Dužniku fizičkom licu
koje obavlja delatnost
Kontrola dužine .
2.43 Creditor. CountryCode Iz šifarnika država
2.44 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun
(fiksna vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke poverioca
(CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.45 CreditorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.47 UltimateCreditor.Identificatio
n .OrganisationId
PIB pravnog subjekta poverioca
Kontrola: Dužina 9 (za pravna lica) ili 13 (za preduzetnike)
znakova
2.57 DebtorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku pravnom
licu
JMBG, dužine 13 – ukoliko se radi o Dužniku fizičkom licu
koje obavlja delatnost
Kontrola dužine .
2.57 Debtor. CountryCode Iz šifarnika država
2.58 DebtorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun
(fiksna vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.59 DebtorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.61 UltimateDebtor.Identification
.OrganisationId
PIB pravnog subjekta dužnika
Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike)
znakova
2.62 Purpose. Purport Strukturasvrhe plaćanja sa šifrom plaćanja u domaćem
platnom prometu:
XXX–svrha plaćanja,gde je:
XXX - Šifra plaćanja je opredeljena šifarnikom NBS
Svrha plaćanja – predstavlja tekstualni opis svrhe plaćanja
Kontrola strukture i (po zahtevu) šifre plaćanja iz propisanog
šifarnika plaćanja
2.82 UnstructuredRemmitance Predstavlja tekstualni opis informacija o plaćanju koji
obuhvata potvrdu ispunjenosti uslova za realizaciju plaćanja
navedenih u mandatu.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 348
2.84 ReferredDocument. Purport Naziv dokumenta kojim se dokumentuje ispunjenost uslova
za realizaciju plaćanja navedenih u mandatu
2.97 CreditorReference. Purport Referisanje Poverioca na identifikaciju Dužnika
Predstavlja ID Collection instrukcije koji generiše Dužnik i
preko koga Dužnik identifikuje transakciju. Strukturapoziva
na brojdužnika u domaćem platnom prometu:
MMPPPPPPPPPPPPPPPPPPPP, gde je:
MM – model poziva na broj sa vrednošću 97 ili „ „
PPPPPPPPPPPPPPPPPPPP – poziv na broj dužnika.
Kontrola strukture ili vrednosti „NONPROVIDED“.
2.105 AdditionalRemmitance Druge struktuirane informacije dogovorene od strane
Dužnika i Poverioca koje služe za dokumentovanje
ispunjenosti uslova za realizaciju plaćanja navedenih u
mandatu
PORUKA pacs.004.001.01 RETURN/REFUND
Struktura: SerbianReturn
• Koristi se za iniciranje i izvršenje storniranja realizovane transakcija direktnog zaduženja kojim se
vrši povraćaj sredstava
• Generiše je banka dužnika i Ispostavlja procesoru ili procesor
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija za
storniranje realizovanih direktnog zaduženja iz poruke i tela poruke (Transaction Information) koje
nosi informacije o pojedinačnim transakcijama za storniranje realizovanih direktnih zaduženja koje
banka inicira.
• Struktura poruke:
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader21 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.5 M 1 + + NumberTransaction Max15NumericText Ukupan broj
transakcija u poruci
1.8 M 1 + + TotalAmount EuroMax15Amount Ukupan iznos
transakcija u poruci
1.8 M 1 + + + Amount Decimal, 15,2 Ukupan iznos
transakcija u poruci
1.8 M 1 + + + Currency Code EuroCurrencyCode Kod domaće valute:
RSD
1.9 M 1 + + SettlementDate ISODate Datum
međubankarskog
obračuna
1.10 M 1 + + SettlementInformation SettlementInformatio
n11
Informacije o
obračunu
1.11 M 1 + + + SettlementMethodCode SettlementMethod2C
ode
Vrednost: CLRG
1.12 M 1 + + + ClearingSystem ClearingSystemIdentifi
cation1Choice
Identifikacija
klirinškog sistema
1.13 M 1 + + + + ClearingSystemIdentific
ation
CashClearingSystem
3Code
Vrednost: KIB
1.22 M 1 + + InstructingAgent FinancialInstitution
2
Pošiljalac poruke
1.22 M 1 + + + AgentId FinancialInstitutionIde
ntification4
Identifikacija
pošiljaoca poruke
1.22 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca
poruke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 349
1.23 M 1 + + InstructedAgent FinancialInstitution
2
Primalac poruke
1.23 M 1 + + + AgentId FinancialInstitutionIde
ntification4
Identifikacija
primaoca poruke
1.23 M 1 + + + + BICAgent BICIdentifier BIC primaoca
poruke
3.0 M 1-n + TransactionInformation PaymentTransactionInf
ormation13
Telo poruke za
Return/Refund
3.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije
podnosioca
instrukcije
3.2 M 1 + + OriginalTransactionInformatio
n
OriginalGroupInform
ation8
Identifikacija
originalne poruke
3.3 M 1 + + + OriginalMessageId Max35Text Jedinstveni
identifikator
originalne poruke
3.4 M 1 + + + OriginalMessageName Max35Text Naziv originalne
instrukcije.
Vrednost:
pacs.003.001.01
3.5 O 0-1 + + + OriginalCreationDate ISODateTime Datum kreiranja
originalne poruke
3.7 M 1 + + OriginalEndToEndId Max35Text Poziv na broj
Poverioca iz
originalne
instrukcije
3.8 M 1 + + OriginalTransactionId Max35Text Id transakcije banke
Poverioca iz
originalne
instrukcije
3.9 M 1 + + OriginalSettlementAmount EuroMax15Amount Iznos transakcije iz
originalne
instrukcije.
3.9 M 1 + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti iz
originalne
instrukcije
3.9 M 1 + + + CurrencyCode EuroCurrencyCode Kod domaće valute
iz originalne
instrukcije: RSD
3.10 M 1 + + ReturnedSettlementAmount EuroMax15Amount Iznos sredstava za
povraćaj
transakcijom
Return/Refund
3.10 M 1 + + + Amount Decimal, 15,2 Iznos za povraćaj u
domaćoj valuti
3.10 M 1 + + + CurrencyCode EuroCurrencyCode Kod domaće valute:
RSD
3.19 M 1-n + + ReturnReasonInformation ReturnReasonInfor
mation4
Informacije o
razlozima
povraćaja
3.20 M 1 + + + ReturnOriginator PartyIdentification14 Identifikacija
podnosioca
instrukcije za
povraćaj:
BIC banke za Return
Naziv dužnika za
Refund
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 350
3.20 {or + + + + OriginatorId PartyOrganisation1C
hoice
Identifikacija
banke podnosioca
Return instrukciju
3.20 M 1 + + + + + Originator OrganisationIdentificat
ion3
Identifikacija
banke podnosioca
3.20 M 1 + + + + + + BICOriginator BICIdentifier BIC banke
podnosioca
3.20 or} + + + + OriginatorName Max35Text Naziv Dužnika koji
inicira povraćaj sa
Refund instrukcijom
3.21 M 1 + + + ReturnReason ReturnReason3Choic
e
Kodirani razlog za
povraćaj
3.22 M 1 + + + + ReasonCode TransactionReturnRea
son5Code
Kod razloga za
povraćaj
3.24 O 0-n + + + AdditionalReasonInformatio
n
Max105Text Dodatno
obrazloženje za
povraćaj
3.25 M 1 + + OriginalTransactionReference
OriginalTransaction
Reference7
Podaci iz originalne
instrukcije
3.32 M 1 + + + SettlementDate ISODate Datum
međubankarskog
obračuna
originalne
transakcije
3.34 M 1 + + + RequestedDate ISODate Datum dospeća
(DueDate) iz
originalne
transakcije
3.35 M 1 + + + CreditorIdInformation CreditorIdentificationI
nformation
Informacija o
identifikaciji
Poverioca iz
originalne instrukcije
3.35 M 1 + + + + CreditorId Max35Text Id Poverioca,
matični broj ili Jmbg
iz originalne
instrukcije.
3.48 M 1 + + + PaymentType PaymentTypeInformati
on9
Tip plaćanja iz
originalne
instrukcije
3.48 M 1 + + + + SequenceType SequenceType1Code Kod tipa plaćanja iz
originalne
instrukcije
3.49 M 1 + + + + CategoryPurpose CategoryPurposeCod
e
Vrednosti:
02 – za ovlašćenje
definisana od strane
banaka na nivou
UBS
03 – za ostala
ugovorna ovlašćenja
3.60 M 1 + + + MandateInformation MandateRelatedInform
ation4
Informacije o
mandatu ili aneksu
iz originalne
instrukcije
3.60 M 1 + + + + MandateId Max35Text Identifikacija
mandata ili aneksa iz
originalne
instrukcije
3.60 M 1 + + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa
iz originalne
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 351
instrukcije
3.60 M 1 + + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa iz
originalne
instrukcije
3.60 O 0-1 + + + + AmendmentInformation AmendmentInformati
onDetails4
Informacije o
osnovnom mandatu
iz originalne
instrukcije
3.60 O 0-1 + + + + + OriginalMandateId Max35Text Identifikator
osnovnog mandata
iz originalne
instrukcije
3.79 O 0-1 + + + RemmitanceInformation RemittanceInformati
on3
Informacije o
plaćanju
RemmitanceInform
ation iz originalne
Collection
instrukcije
(svi atributi iz
originalne
instrukcija).
3.79 O 0-1 + + + + UnstructuredRemmitanc
e
Max140Text Nestruktuirane
informacije o
plaćanju
3.79 O 0-1 + + + + StructuredRemmitance StructuredRemittanceI
nformation6
Struktuirane
informacije o
plaćanju
3.79 O 0-1 + + + + + ReferredDocument ReferredDocumentIn
formation1
Dokumentovanje
plaćanja
3.79 O 0-1 + + + + + + DocumentType ReferredDocumentTy
pe1
Dokument
3.79 O 0-1 + + + + + + + Purport Max35Text Naziv dokumenta
3.79 O 0-1 + + + + + CreditorReference Creditor Reference
Information1
Referisanje
poverioca na
identifikator dužnika
3.79 O 0-1 + + + + + + ReferenceType CreditorReferenceTy
pe1
Referenca
3.79 O 0-1 + + + + + + + Purport Max35Text Poziv na broj
dužnika
3.79 O 0-1 + + + + + AdditionalRemmitan
ce
Max140Text Dodatne informacije
o plaćanju
3.105 M 1 + + + Debtor PartyIdentification19 Dužnika iz
originalne
instrukcije
(svi atributi iz
originalne
instrukcija)
3.105 M 1 + + + + DebtorId Max35Text ID dužnika, matični
broj ili Jmbg iz
originalne
instrukcije
3.105 M 1 + + + + Name Max70Text Naziv dužnika iz
originalne
instrukcije
3.105 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
dužnika iz
originalne
instrukcije
3.105 O 0-2 + + + + + Address Max70Text Adresa dužnika iz
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 352
originalne
instrukcije
3.105 M 1 + + + + + CountryCode CountryCode Kod države dužnika
iz originalne
instrukcije
3.106 M 1 + + + DebtorAccount CashAccount8 Broj računa
dužnika iz
originalne
instrukcije
3.106 M 1 + + + + AccountId AccountIdentification
2
Identifikacija
računa dužnika iz
originalne
instrukcije
3.106 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika iz
originalne
instrukcije
3.107 M 1 + + + DebtorAgent FinancialInstitution2 Banka dužnika iz
originalne
instrukcije
3.107 M 1 + + + + AgentId FinancialInstitutionIde
ntification4
Identifikacija banke
dužnika iz originalne
instrukcije
3.107 M 1 + + + + + BICAgent BIC Identifier BIC banke dužnika
iz originalne
instrukcije
3.108 O 0-1 + + + UltimateDebtor Institution2 Pravni subjekt
3.108 O 0-1 + + + + Identification InstitutionIdentificati
on
Identifikacija
pravnog subjekta
3.108 O 0-1 + + + + + OrganisationId PIBIdentifier PIB dužnika
Obavezno za pravne
subjekte
Za preduzetnike
JMBG
3.111 M 1 + + + Creditor PartyIdentification13 Poverilac iz
originalne
instrukcije
(svi atributi iz
originalne
instrukcija)
3.111 M 1 + + + + Name Max70Text Ime poverioca iz
originalne
instrukcije
3.111 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
poverioca iz
originalne
instrukcije
3.111 O 0-2 + + + + + Address Max70Text Adresa poverioca iz
originalne
instrukcije
3.111 M 1 + + + + + CountryCode CountryCode Kod države
poverioca iz
originalne
instrukcije
3.112 M 1 + + + CreditorAccount CashAccount8 Broj računa
poverioca iz
originalne
instrukcije
3.112 M 1 + + + + AccountId AccountIdentification
2
Identifikacija
računa poverioca iz
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 353
originalne
instrukcije
3.112 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca iz
originalne
instrukcije
3.109 M 1 + + + CreditorAgent FinancialInstitution2 Banka poverioca iz
originalne
instrukcije
3.109 M 1 + + + + AgentId FinancialInstitutionIde
ntification4
Identifikacija banke
poverioca iz
originalne
instrukcije
3.109 M 1 + + + + + BICAgent BIC Identifier BIC banke poverioca
iz originalne
instrukcije
3.113 O 0-1 + + + UltimateCreditor Institution2 Pravni subjekt
3.113 O 0-1 + + + + Identification InstitutionIdentificati
on
Identifikacija
pravnog subjekta
3.113 O 0-1 + + + + + OrganisationId PIBIdentifier PIB poverioca
Obavezno za pravne
subjekte
Za preduzetnike
JMBG
Specifikacija ISO kodova za Return/Refund transakcije:
ISO kod Opis ISO kod Opis
AC01 Pogrešan broj računa BE07 Pogrešna adresa dužnika
AC04 Račun zatvoren DT01 Pogrešan datum
AC06 Račun blokiran ED01 Ne postoji korespodentna banka
AG01 Transakcija zabranjena ED03 Traženo stanje
AG02 Pogrešan kod banke MD01 Nema validnog mandata
AM01 Nula iznos MD02 Pogrešne informacije o mandatu
AM02 Nedopušten račun MD03 Pogrešan format podatka o razlozima
AM03 Nedopuštena valuta MD04 Pogrešan format podataka za indikatore
AM04 Nedovoljno sredstava MD06 Dužnik je podneo Refunda zahtev
AM05 Dupliran nalog MD07 Dužnik je umro
AM06 Premali iznos MS02 Nije naveden razlog od strane dužnika
AM07 Blokiran iznos MS03 Nije naveden razlog od strane banke
AM09 Pogrešan iznos NARR Opisno
AM10 Pogrešna kontrolna suma RC01 Pogrešan identifikator banke
BE01 Nesaglasan krajnji korisnik RF01 Referenca transakcije nije jedinstvena
BE04 Pogrešna adresa poverioca TM01 Cutt off time (istek vremena)
BE05 Neprepoznat poverilac ED05 Greška u obračunu
BE06 Neprepoznat dužnik RR01 Razlozi regulatora (procesora)
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od SettlementDate
1.5 NumberTransaction Veći od nule.
Broj instrukcija u poruci, odnosno broj ponavljanja
TransactionInformation
1.8 TotalAmount .Amount Suma iznosa transakcija, odnosno
suma RetrnedSettlementAmount iz svake instrukcija
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 354
1.8 TotalAmount . Currency Code Vrednost: RSD
1.9 SettlementDate Veći od tekućeg datuma, a manji od tekućeg datuma+16
dana
1.11 SettlementMethodCode Vrednost: CLRG
1.13 ClearingSystemIdentification Vrednost: KIB
1.22 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.23 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
3.1 TransactionId Predstavlja ID Return/Refund instrukcije koji generiše banka
Dužnika i preko koga banka Dužnika identifikuje transakciju
Maksimalna dužina: Max32Text., osim u slučaju greške
kada je Max35Text.
U slučaju odbijanja instrukcije od strane Procesora zbog
ustanovljene greške (Reject procesora), drugom učesniku se
dostavlja instrukcije u kojoj TransactionId započinje sa
ERR+originalni TransactionId
3.3 OriginalMessageId MessageId iz Header-a poruke u kojoj se nalazila originalna
Collection instrukcija.
Predstavlja jedinstveni identifikator poruke u kojoj se
nalazila originalna Collection instrukcija.
Kontrola postojanja poruke u evidenciji procesora
3.4 OriginalMessageName Vrednost: pacs.003.001.01
3.5 OriginalCreationDate CreationDate iz Header-a poruke u kojoj se nalazila
originalna Collection instrukcija
3.7 OriginalEndToEndId EndToEndID iz originalne Collection instrukcije.
Predstavlja ID originalne Collection instrukcije koji je
generisao Poverilac.
3.8 OriginalTransactionId TransactionID iz originalne Collection instrukcije.
Predstavlja ID originalne Collection instrukcije koji je
generisala banka Poverioca
Kontrola postojanja instrukcije u evidenciji procesora
3.9 OriginalSettlementAmount.
Amount
SettlementAmount iz originalne Collection instrukcije.
Kontrola iznosa originalne transakcije koji je realizovan u
kliringu, u evidenciji procesora
3.9 OriginalSettlementAmount.
CurrencyCode Vrednost: RSD
3.10 ReturnedSettlementAmount.
Amount
Uobičajeno, jednak iznosu OriginalSettlementAmount
Može biti i različit u slučaju da je to predviđeno i dozvoljeno
mandatom
3.10 ReturnedSettlementAmount.
CurrencyCode Vrednost: RSD
3.20 ReturnOriginator
3.20 ReturnOriginator.
BICOriginator
Podnosilac instrukcije može biti Banka Dužnika, za Return
instrukciju, koja se identifikuje svojim BIC-om i Dužnik, za
Refund instrukcije, koji se identifikuje svojim nazivom.
BIC banke dužnika mora biti u evidenciji aktivnih učesnika
kliringa za direktna zaduženja
3.22 ReturnReason. ReasonCode Kontrola koda razloga povraćaja u šifarniku kodova
povraćaja
3.24 AdditionalReasonInformation Ukoliko šifrirani kod razloga povraćaja ne objašnjava
dovoljno razloge za povraćaja, može se zadati i njegov
tekstualni opis.
3.32 OriginalTransactionReference
. SettlementDate
SettlementDate iz Header-a poruke u kojoj se nalazila
originalna Collection instrukcija
Kontrola SettlementDate iz originalne instrukcije, u
evidenciji procesora
3.34 OriginalTransactionReference
. RequestedDate RequestedDate iz originalne Collection instrukcije
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 355
3.35 CreditorIdInformation.
CreditorId CreditorId iz originalne Collection instrukcije.
3.48 PaymentType.
SequenceType
SequenceType iz originalne Collection instrukcije:
FRST – prvo plaćanje po višestrukom mandatu
RECR – ostala plaćanja po višestrukom mandatu osim prvog i
poslednjeg
FINL – poslednje plaćanje po višestrukom mandatu
ONEO – plaćanje po jednostukom mandatu
3.49 PaymentType.CategoryPurpo
se
Vrednosti: 02, 03
02 – za ovlašćenja kao osnov naplate koja su u posedu banke
dužnika (poseban tip mandata definisan na od strane banaka
na nivou UBS,)
03 – za ostala ugovorna ovlašćenja kao osnov naplate (opšti
tip mandata)
3.60 MandateInformation .
MandateId MandateId iz originalne Collection instrukcije
3.60 MandateInformation .
DateSignature DateSignature iz originalne Collection instrukcije
3.60 MandateInformation .
AmendmentIndicator AmendmentIndicator iz originalne Collection instrukcije
3.60 MandateInformation .
OriginalMandateId
AmendmentInformation iz originalne Collection instrukcije.
ID osnovnog mandata ukoliko je AmendmentIndicator iz
originalne Collection instrukcije=TRUE
3.79 RemmitanceInformation RemmitanceInformation iz originalne Collection instrukcije
3.105 Debtor Debtor iz originalne Collection instrukcije
3.106 DebtorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun
(fiksna vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
3.107 DebtorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
3.108 UltimateDebtor.Identification
.OrganisationId
PIB pravnog subjekta dužnika
Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike)
znakova
3.111 Creditor Creditor iz originalne Collection instrukcije (svi atributi iz
originalne instrukcija)
3.112 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun
(fiksna vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke poverioca
(CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
3.109 CreditorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
3.113 UltimateCreditor.Identificatio
n .OrganisationId
PIB pravnog subjekta poverioca
Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike)
znakova
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 356
PORUKA pacs.007.001.01 REVERSAL
Struktura: SerbianReversal
• Koristi se za povraćaj sredstava po realizovanoj transakciji direktnog zaduženja
• Generiše je banka poverioca i ispostavlja procesoru
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija
direktnog zaduženja za povraćaj sredstava iz poruke i tela poruke (Transaction Information) koje nosi
informacije o pojedinačnim transakcijama za povraćaj sredstava koje inicira banka.
• Struktura poruke:
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader22 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.5 M 1 + + NumberTransaction Max15NumericText Ukupan broj transakcija
u poruci
1.7 M 1 + + GroupReserval TrueFalseIndicator Indikator grupnog
vraćanja sa
1.8 M 1 + + TotalAmount EuroMax15Amount Ukupan iznos
transakcija u poruci
1.8 M 1 + + + Amount Decimal, 15,2 Ukupan iznos
transakcija u poruci
1.8 M 1 + + + Currency Code EuroCurrencyCode Kod domaće valute: RSD
1.9 M 1 + + SettlementDate ISODate Datum
međubankarskog
obračuna
1.10 M 1 + + SettlementInformation SettlementInformati
on11
Informacije o obračunu
1.11 M 1 + + + SettlementMethodCode SettlementMethod2
Code
Vrednost: CLRG
1.12 M 1 + + + ClearingSystem ClearingSystemIdenti
fication1Choice
Identifikacija klirinškog
sistema
1.13 M 1 + + + + ClearingSystemIdentific
ation
CashClearingSystem
3Code
Vrednost: KIB
1.22 M 1 + + InstructingAgent FinancialInstitutio
n2
Pošiljalac poruke
1.22 M 1 + + + AgentId FinancialInstitutionId
entification4
Identifikacija pošiljaoca
poruke
1.22 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.23 M 1 + + InstructedAgent FinancialInstitutio
n2
Primalac poruke
1.23 M 1 + + + AgentId FinancialInstitutionId
entification4
Identifikacija primaoca
poruke
1.23 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
3.0 M 1-n + TransactionInformation PaymentTransactionIn
formation14
Telo poruke za
Reversal
3.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije podnosioca
instrukcije
3.4 M 1 + + OriginalEndToEndId Max35Text Poziv na broj Poverioca
iz originalne instrukcije
3.5 M 1 + + OriginalTransactionId Max35Text Id transakcije banke
Poverioca iz originalne
instrukcije
3.6 M 1 + + OriginalSettlementAmount EuroMax15Amount Iznos transakcije iz
originalne instrukcije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 357
3.6 M 1 + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti iz
originalne instrukcije
3.6 M 1 + + + CurrencyCode EuroCurrencyCode Kod domaće valute iz
originalne instrukcije:
RSD
3.7 M 1 + + ReversedSettlementAmount EuroMx15Amount Iznos sredstava za
povraćaj transakcijom
Reversal
3.7 M 1 + + + Amount Decimal, 15,2 Iznos za povraćaj u
domaćoj valuti
3.7 M 1 + + + CurrencyCode EuroCurrencyCode Kod domaće valute: RSD
3.16 M 1-n + + ReversalReasonInformation ReversalReasonInf
ormation4
Informacije o
razlozima povraćaja
3.17 M 1 + + + ReversalOriginator PartyIdntification14 Identifikacija podnosioca
instrukcije za povraćaj:
BIC banke ili Id
poverioca
3.17 {or + + + + OriginatorId PartyOrganisation1C
hoice
Identifikacija banke
podnosioca Reversal
instrukciju
3.17 M 1 + + + + + Originator OrganisationIdentifi
cation3
Identifikacija banke
podnosioca
3.17 M 1 + + + + + + BICOriginator BICIdentifier BIC banke podnosioca
3.17 or} + + + + OriginatorName Max35Text Naziv Poverioca koji
inicira povraćaj sa
Reversal instrukcijom
3.18 M 1 + + + ReversalReason ReturnRson3Choice Kodirani razlog za
povraćaj
3.19 M 1 + + + + ReasonCode TransactionReturnRe
ason2Code
Kod razloga za povraćaj
3.21 O 0-1 + + + AdditionalReasonInformatio
n
Max105Text Dodatno obrazloženje
za povraćaj
3.22 M 1 + + OriginalTransactionReference
OriginalTransaction
Reference7
Podaci iz originalne
instrukcije
3.29 M 1 + + + SettlementDate ISODate Datum
međubankarskog
obračuna originalne
transakcije
3.31 M 1 + + + RequestedDate ISODate Datum dospeća
(DueDate) iz originalne
transakcije
3.32 M 1 + + + CreditorIdInformation CreditorIdentification
Information
Informacija o
identifikaciji Poverioca iz
originalsne instrukcije
3.32 M 1 + + + + CreditorId Max35Text Id Poverioca, matični
broj ili Jmbg iz
originalne instrukcije.
3.45 M 1 + + + PaymentType PaymentTypeInforma
tion9
Tip plaćanja iz
originalne instrukcije
3.45 M 1 + + + + SequenceType SequnceType1Code Kod tipa plaćanja iz
originalne instrukcije
3.46 M 1 + + + + CategoryPurpose CategryPrposeCode Vrednosti:
02 – za ovlašćenje
definisana od strane
banaka na nivou UBS
03 – za ostala ugovorna
ovlašćenja
3.57 M 1 + + + MandateInformation MandateRelatedInfor Informacije o mandatu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 358
mation4 ili aneksu iz originalne
instrukcije
3.57 M 1 + + + + MandateId Max35Text Identifikacija mandata ili
aneksa iz originalne
instrukcije
3.57 M 1 + + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa iz
originalne instrukcije
3.57 M 1 + + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa iz
originalne instrukcije
3.57 O 0-1 + + + + AmendmentInformation AmendmentInformat
ionDetails4
Informacije o osnovnom
mandatu iz originalne
instrukcije
3.57 O 0-1 + + + + + OriginalMandateId Max35Text Identifikator osnovnog
mandata iz originalne
instrukcije
3.76 O 0-1 + + + RemmitanceInformation RemitncInfrmation3 Informacije o plaćanju
3.76 O 0-1 + + + + UnstructuredRemmitanc
e
Max140Text Nestruktuirane
informacije o plaćanju
3.76 O 0-1 + + + + StructuredRemmitance StructuredRemittance
Information6
Struktuirane informacije
o plaćanju
3.76 O 0-1 + + + + + ReferredDocument ReferredDocument
Information1
Dokumentovanje
plaćanja
3.76 O 0-1 + + + + + + DocumentType ReferredDocument
Type1
Dokument
3.76 O 0-1 + + + + + + + Purport Max35Text Naziv dokumenta
3.76 O 0-1 + + + + + CreditorReference CreditorReference
Information1
Referisanje poverioca na
identifikator dužnika
3.76 O 0-1 + + + + + + ReferenceType CreditorReference
Type1
Referenca
3.76 O 0-1 + + + + + + + Purport Max35Text Poziv na broj dužnika
3.76 O 0-1 + + + + + AdditionalRemmitan
ce
Max140Text Dodatne informacije o
plaćanju
3.102 M 1 + + + Debtor PartyIdntification19 Dužnika iz originalne
instrukcije
3.102 M 1 + + + + DebtorId Max35Text ID dužnika, matični broj
ili Jmbg iz originalne
instrukcije
3.102 M 1 + + + + Name Max70Text Naziv dužnika iz
originalne instrukcije
3.102 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
dužnika iz originalne
instrukcije
3.102 O 0-2 + + + + + Address Max70Text Adresa dužnika iz
originalne instrukcije
3.102 M 1 + + + + + CountryCode CountryCode Kod države dužnika iz
originalne instrukcije
3.103 M 1 + + + DebtorAccount CashAccount8 Broj računa dužnika iz
originalne instrukcije
3.103 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
dužnika iz originalne
instrukcije
3.103 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika iz originalne
instrukcije
3.104 M 1 + + + DebtorAgent FinancialInstitution2 Banka dužnika iz
originalne instrukcije
3.104 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika iz originalne
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 359
instrukcije
3.104 M 1 + + + + + BICAgent BIC Identifier BIC banke dužnika iz
originalne instrukcije
3.105 O 0-1 + + + UltimateDebtor Institution2 Pravni subjekt
3.105 O 0-1 + + + + Identification Institution
Identification
Identifikacija pravnog
subjekta
3.105 O 0-1 + + + + + OrganisationId PIBIdentifier PIB dužnika
Obavezno za pravne
subjekte
Za preduzetnike JMBG
3.108 M 1 + + + Creditor Party
Identification13
Poverilac iz originalne
instrukcije
3.108 M 1 + + + + Name Max70Text Ime poverioca iz
originalne instrukcije
3.108 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
poverioca iz originalne
instrukcije
3.108 O 0-2 + + + + + Address Max70Text Adresa poverioca iz
originalne instrukcije
3.108 M 1 + + + + + CountryCode CountryCode Kod države poverioca iz
originalne instrukcije
3.109 M 1 + + + CreditorAccount CashAccount8 Broj računa poverioca
iz originalne instrukcije
3.109 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
poverioca iz originalne
instrukcije
3.109 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca iz originalne
instrukcije
3.106 M 1 + + + CreditorAgent FinancialInstitution2 Banka poverioca iz
originalne instrukcije
3.106 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca iz originalne
instrukcije
3.106 M 1 + + + + + BICAgent BIC Identifier BIC banke poverioca iz
originalne instrukcije
3.110 O 0-1 + + + UltimateCreditor Institution2 Pravni subjekt
3.110 O 0-1 + + + + Identification Institution
Identification
Identifikacija pravnog
subjekta
3.110 O 0-1 + + + + + OrganisationId PIBIdentifier PIB poverioca
Obavezno za pravne
subjekte
Za preduzetnike JMBG
Specifikacija ISO kodova za Reversal transakcije:
ISO kod Opis ISO kod Opis
AC04 Račun zatvoren MD05 Instrukcija nije dospela
AG02 Pogrešan kod banke MS02 Nije naveden razlog od strane dužnika
AM05 Dupliran nalog MS03 Nije naveden razlog od strane banke
MD01 Nema validnog mandata
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od SettlementDate
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 360
1.5 NumberTransaction Veći od nule.
Broj instrukcija u poruci, odnosno broj ponavljanja
TransactionInformation
1.7 GroupReserval Vrednost: FALSE
1.8 TotalAmount .Amount Suma iznosa transakcija, odnosno
suma ReversedSettlementAmount iz svake instrukcija
1.8 TotalAmount . Currency Code Vrednost: RSD
1.9 SettlementDate Veći od tekućeg datuma, a manji od tekućeg datuma+16 dana
1.11 SettlementMethodCode Vrednost: CLRG
1.13 ClearingSystemIdentification Vrednost: KIB
1.22 InstructingAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.23 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
3.1 TransactionId Predstavlja ID Reversal instrukcije koji generiše banka
Poverioca i preko koga banka Poverioca identifikuje
transakciju
Maksimalna dužina: Max32Text., osim u slučaju greške kada
je Max35Text.
U slučaju odbijanja instrukcije od strane Procesora zbog
ustanovljene greške (Reject procesora), drugom učesniku se
dostavlja instrukcije u kojoj TransactionId započinje sa
ERR+originalni TransactionId
3.4 OriginalEndToEndId Predstavlja ID Reversal instrukcije koji generiše banka
Poverioca i preko koga banka Poverioca identifikuje
transakciju
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
3.5 OriginalTransactionId TransactionID iz originalne Collection instrukcije.
Predstavlja ID originalne Collection instrukcije koji je generisala
banka Poverioca.
Kontrola postojanja instrukcije u evidenciji porcesora
3.6 OriginalSettlementAmount.
Amount
SettlementAmount iz originalne Collection instrukcije.
Iznos originalne Collection instrukcije.
Kontrola iznosa originalne transakcije koji je realizovan u
kliringu, u evidenciji procesora
3.6 OriginalSettlementAmount.
CurrencyCode Vrednost:RSD
3.7 ReversedSettlementAmount.
Amount
Uobičajeno, jednak OriginalSettlementAmount,
ali može biti i različit u slučaju da je to predviđeno i
dozvoljeno mandatom
3.7 ReversedSettlementAmount.
CurrencyCode Vrednost:RSD
3.17 ReversalOriginator.
BICOriginator
Podnosilac instrukcije može biti:
- Banka Poverioca koja se identifikuje svojim BIC-om
- Poverilac, koji se identifikuje svojim nazivom.
Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
3.19 ReversalReason. ReasonCode Kontrola koda razloga povraćaja u šifarniku kodova povraćaja
3.21 AdditionalReasonInformation Ukoliko šifrirani kod razloga povraćaja ne objašnjava dovoljno
razloge za povraćaja, može se zadati i njegov tekstualni opis.
3.29
OriginalTransactionReference
. SettlementDate
SettlementDate iz Header-a poruke u kojoj se nalazila
originalna Collection instrukcija
Kontrola SettlementDate iz originalne instrukcije, u evidenciji
procesora
3.31 OriginalTransactionReference
. RequestedDate RequestedDate iz originalne Collection instrukcije
3.32 CreditorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku pravnom
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 361
licu
JMBG, dužine 13 – ukoliko se radi o Dužniku fizičkom licu
koje obavlja delatnost
Kontrola dužine .
3.45 PaymentType. SequenceType SequenceType iz originalne Collection instrukcije:
FRST – prvo plaćanje po višestrukom mandatu
RECR – ostala plaćanja po višestrukom mandatu osim prvog i
poslednjeg
FINL – poslednje plaćanje po višestrukom mandatu
ONEO – plaćanje po jednostukom mandatu
3.46 PaymentType.Category
Purpose
Vrednosti: 02, 03
02 – za ovlašćenja kao osnov naplate koja su u posedu banke
dužnika (poseban tip mandata definisan na od strane banaka na
nivou UBS,)
03 – za ostala ugovorna ovlašćenja kao osnov naplate (opšti tip
mandata)
3.57 MandateInformation .
MandateId MandateId iz originalne Collection instrukcije
3.57 MandateInformation .
DateSignature DateSignature iz originalne Collection instrukcije
3.57 MandateInformation .
AmendmentIndicator AmendmentIndicator iz originalne Collection instrukcije
3.57 MandateInformation .
OriginalMandateId
AmendmentInformation iz originalne Collection instrukcije.
ID osnovnog mandata ukoliko je AmendmentIndicator iz
originalne Collection instrukcije=TRUE
3.76 RemmitanceInformation RemmitanceInformation iz originalne Collection instrukcije
3.102 Debtor Debtor iz originalne Collection instrukcije
3.103 DebtorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
3.104 DebtorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
3.105 UltimateDebtor.Identification
.OrganisationId
PIB pravnog subjekta dužnika
Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike)
znakova
3.108 Creditor Creditor iz originalne Collection instrukcije (svi atributi iz
originalne instrukcija)
3.109 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke poverioca
(CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
3.106 CreditorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
3.110 UltimatCreditor.Identification
.OrganisationId
PIB pravnog subjekta poverioca, Kontrola: dužina 9 (za pravna
lica) ili 13 (za preduzetnike) znakova
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 362
PORUKA pacs.002.001.02 REJECT
Struktura: SerbianStatus
• Koristi se za odbijanje transakcija direktnog zaduženja (nerealizovanih)
• Generiše je banka dužnika i Ispostavlja procesoru ili procesor
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija
direktnog zaduženja koje se odbijaju iz poruke i tela poruke (Transaction Information) koje nosi
informacije o pojedinačnim transakcijama direktnog zaduženja koje se odbijaju (nerealizovanim).
• Struktura poruke:
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader12 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.7 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.7 M 1 + + + AgentId FinancialInstitutionId
entification4
Identifikacija
pošiljaoca poruke
1.7 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca
poruke
1.8 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.8 M 1 + + + AgentId FinancialInstitutionId
entification4
Identifikacija
primaoca poruke
1.8 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
3.0 M 1-n + TransactionInformation PaymentTransactio
nInformation12
Telo poruke
instrukcije
odbijanja (Reject)
3.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije
podnosioca
instrukcije
3.4 M 1 + + OriginalEndToEndId Max35Text Poziv na broj
poverioca iz originalne
instrukcije
3.5 M 1 + + OriginalTransactionId Max35Text Id transakcije banke
Poverioca iz originalne
instrukcije
3.6 M 1 + + TransactionStatus TransactionIndividua
lStatus2Code
Vrednost: RJCT
3.7 M 1 + + StatusReasonInformation StatusReasonInfor
mation4
Informacije o
razlozima odbijanja
3.8 M 1 + + + StatusOriginator Party
Identification14
Identifikacija
inicijatora odbijanja
instrukcije (banka,
Procesor ili Dužnik)
3.8 {or + + + + OriginatorId PartyOrganisation1
Choice
Identifikacija
inicijatora odbijanja
instrukcije (banka ili
Procesor)
3.8 M 1 + + + + + Originator Organisation
Identification3
Identifikacija
inicijatora odbijanja
instrukcije (banka ili
Procesor)
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 363
3.8 M 1 + + + + + + BICOriginator BICIdentifier BIC banke ili
Procesora, inicijatora
odbijanja instrukcije
3.8 or} + + + + OriginatorName Max35Text Naziv Dužnika
inicijatora odbijanje
instrukcije
3.9 M 1 + + + StatusReason StatusReason3
Choice
Kodirani razlog za
odbijanje instrukcije
3.10 M 1 + + + + StatusCode TransactionReturnRe
ason4Code
Kod razloga za
odbijanje instrukcije
3.12 O 0-1
+ + + AdditionalReasonInformatio
n
Max105Text Dodatno obrazloženje
za odbijanje
instrukcije.
3.17 M 1 + + OriginalTransactionReference
OriginalTransaction
Reference8
Podaci iz originalne
instrukcije
3.18 M 1 + + + OriginalSettlementAmount EuroMax15Amount Iznos transakcije iz
originalne instrukcije.
3.18 M 1 + + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti iz
originalne instrukcije
3.18 M 1 + + + + CurrencyCode EuroCurrencyCode Kod domaće valute iz
originalne instrukcije
3.24 M 1 + + + SettlementDate ISODate Datum
međubankarskog
obračuna originalne
transakcije
3.26 M 1 + + + RequestedDate ISODate Datum dospeća
(DueDate) iz
originalne transakcije
3.27 M 1 + + + CreditorIdInformation CreditorIdentification
Information
Informacija o
identifikaciji Poverioca
iz originalne instrukcije
3.27 M 1 + + + + CreditorId Max35Text Id Poverioca, matični
broj ili Jmbg iz
originalne instrukcije.
3.40 M 1 + + + PaymentType PaymentType
Information9
Tip plaćanja iz
originalne instrukcije
3.48 M 1 + + + + SequenceType SequenceType1
Code
Kod tipa plaćanja iz
originalne instrukcije
3.49 M 1 + + + + CategoryPurpose CategoryPurpose
Code
Vrednosti:
02 – za ovlašćenje
definisana od strane
banaka na nivou UBS
03 – za ostala
ugovorna ovlašćenja
3.52 M 1 + + + MandateInformation MandateRelated
Information4
Informacije o
mandatu ili aneksu iz
originalne instrukcije
3.52 M 1 + + + + MandateId Max35Text Identifikacija mandata
ili aneksa iz originalne
instrukcije
3.52 M 1 + + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa iz
originalne instrukcije
3.52 M 1 + + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa iz
originalne instrukcije
3.52 O 0-1 + + + + AmendmentInformation Amendment
InformationDetails4
Informacije o
osnovnom mandatu iz
originalne instrukcije
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 364
3.52 O 0-1 + + + + + OriginalMandateId Max35Text Identifikator
osnovnog mandata iz
originalne instrukcije
3.71 O 0-1 + + + RemmitanceInformation Remittance
Information3
Informacije o
plaćanju
3.71 O 0-1 + + + + UnstructuredRemmitanc
e
Max140Text Nestruktuirane
informacije o plaćanju
3.71 O 0-1 + + + + StructuredRemmitance StructuredRemittance
Information6
Struktuirane
informacije o plaćanju
3.71 O 0-1 + + + + + ReferredDocument ReferredDocument
Information1
Dokumentovanje
plaćanja
3.71 O 0-1 + + + + + + DocumentType ReferredDocument
Type1
Dokument
3.71 O 0-1 + + + + + + + Purport Max35Text Naziv dokumenta
3.71 O 0-1 + + + + + CreditorReference Creditor Reference
Information1
Referisanje poverioca
na identifikator
dužnika
3.71 O 0-1 + + + + + + ReferenceType CreditorReference
Type1
Referenca
3.71 O 0-1 + + + + + + + Purport Max35Text Poziv na broj dužnika
3.71 O 0-1 + + + + + AdditionalRemmitan
ce
Max140Text Dodatne informacije o
plaćanju
3.97 M 1 + + + Debtor Party
Identification19
Dužnika iz originalne
instrukcije
3.97 M 1 + + + + DebtorId Max35Text ID dužnika, matični
broj ili Jmbg iz
originalne instrukcije
3.97 M 1 + + + + Name Max70Text Naziv dužnika iz
originalne instrukcije
3.97 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
dužnika iz originalne
instrukcije
3.97 O 0-2 + + + + + Address Max70Text Adresa dužnika iz
originalne instrukcije
3.97 M 1 + + + + + CountryCode CountryCode Kod države dužnika iz
originalne instrukcije
3.98 M 1 + + + DebtorAccount CashAccount8 Broj računa dužnika
iz originalne
instrukcije
3.98 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
dužnika iz originalne
instrukcije
3.98 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika iz originalne
instrukcije
3.99 M 1 + + + DebtorAgent Financial
Institution2
Banka dužnika iz
originalne instrukcije
3.99 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika iz originalne
instrukcije
3.99 M 1 + + + + + BICAgent BIC Identifier BIC banke dužnika iz
originalne instrukcije
3.100 O 0-1 + + + UltimateDebtor Institution2 Pravni subjekt
3.100 O 0-1 + + + + Identification Institution
Identification
Identifikacija pravnog
subjekta
3.100 O 0-1 + + + + + OrganisationId PIBIdentifier PIB dužnika
Obavezno za pravne
subjekte
Za preduzetnike
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 365
JMBG
3.103 M 1 + + + Creditor Party
Identification13
Poverilac iz
originalne instrukcije.
3.103 M 1 + + + + Name Max70Text Ime poverioca iz
originalne instrukcije
3.103 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
poverioca iz
originalne instrukcije
3.103 O 0-2 + + + + + Address Max70Text Adresa poverioca iz
originalne instrukcije
3.103 M 1 + + + + + CountryCode CountryCode Kod države poverioca
iz originalne
instrukcije
3.104 M 1 + + + CreditorAccount CashAccount8 Broj računa
poverioca iz
originalne instrukcije
3.104 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
poverioca iz
originalne instrukcije
3.104 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca iz
originalne instrukcije
3.101 M 1 + + + CreditorAgent Financial
Institution2
Banka poverioca iz
originalne instrukcije
3.101 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca iz originalne
instrukcije
3.101 M 1 + + + + + BICAgent BICIdentifier BIC banke poverioca
iz originalne
instrukcije
3.105 O 0-1 + + + UltimateCreditor Institution2 Pravni subjekt
3.105 O 0-1 + + + + Identification Institution
Identification
Identifikacija pravnog
subjekta
3.105 O 0-1 + + + + + OrganisationId PIBIdentifier PIB poverioca
Obavezno za pravne
subjekte
Za preduzetnike
JMBG
Specifikacija ISO kodova za Reject transakcije:
ISO kod Opis ISO kod Opis
AC01 Pogrešan broj računa BE07 Pogrešna adresa dužnika
AC04 Račun zatvoren DT01 Pogrešan datum
AC06 Račun blokiran ED01 Ne postoji korespodentna banka
AG01 Transakcija zabranjena ED03 Traženo stanje
AG02 Pogrešan kod banke MD01 Nema validnog mandata
AM01 Nula iznos MD02 Pogrešne informacije o mandatu
AM02 Nedopušten račun MD03 Pogrešan format podatka o razlozima
AM03 Nedopuštena valuta MD04 Pogrešan format podataka za indikatore
AM04 Nedovoljno sredstava MD06 Dužnik je podneo Refunda zahtev
AM05 Dupliran nalog MD07 Dužnik je umro
AM06 Premali iznos MS02 Nije naveden razlog od strane dužnika
AM07 Blokiran iznos MS03 Nije naveden razlog od strane banke
AM09 Pogrešan iznos NARR Opisno
AM10 Pogrešna kontrolna suma RC01 Pogrešan identifikator banke
BE01 Nesaglasan krajnji korisnik RF01 Referenca transakcije nije jedinstvena
BE04 Pogrešna adresa poverioca TM01 Cutt off time (istek vremena)
BE06 Neprepoznat dužnik RR01 Razlozi regulatora (procesora)
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 366
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem
platnom prometu, kontrolu vršiti prema usvojenom
standardu
1.2 CreationDate Manji ili jednak od tekućeg datume
1.7 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za
direktna zaduženja
1.8 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za
direktna zaduženja
3.1 TransactionId Predstavlja ID Return instrukcije koji generiše banka
Dužnika za odbijanje Collection instrukcije, odnosno
banka Poverioca za odbijanje Return/Refund
instrukcija
3.4 OriginalEndToEndId EndToEndID iz originalne Collection instrukcije.
Predstavlja ID originalne Collection instrukcije koji je
generisao Poverilac, odnosno „NONPROVIDED“ za
originalnu Return/Refund instrukciju
3.5 OriginalTransactionId TransactionId iz originalne Collection instrukcije.
Predstavlja ID originalne Collection instrukcije koji je
generisala banka Poverioca,
odnosno originalne Return/Refund instrukcije koji je
generisala banka Dužnika
Kontrola postojanja instrukcije u evidenciji procesora
3.6 TransactionStatus Vrednost: RJCT
3. 8 StatusOriginator.
BICOriginator
Podnosilac instrukcije može biti:
- Banka Poverioca, Banka Dužnika ili Procesor, koji se
identifikuju BIC-om
- Dužnik, koji se identifikuje svojim nazivom
Mora biti u evidenciji aktivnih učesnika kliringa za
direktna zaduženja
3.10 StatusReason. StatusCode Kontrola koda razloga povraćaja u šifarniku kodova
odbijanja
3.12 AdditionalReasonInformation Ukoliko šifrirani kod razloga odbijanja ne objašnjava
dovoljno razloge odbijanja, može se zadati i njegov
tekstualni opis.
3.18 OriginalSettlementAmount.
Amount
SettlementAmount iz originalne Collection instrukcije,
odnosno .
ReturnSettlementAmount iz Return/Refund
instrukcije.
Veći od nule
3.18 OriginalSettlementAmount.
CurrencyCode Vrednost: RSD
3.24 OriginalTransactionReference
.SettlementDate
SettlementDate iz Header-a poruke u kojoj se nalazila
originalna instrukcija
Kontrola SettlementDate iz originalne instrukcije, u
evidenciji procesora
3.26 OriginalTransactionReference
.RequestedDate RequestedDate iz originalne Collection instrukcije
3.27 CreditorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku
pravnom licu
JMBG, dužine 13 – ukoliko se radi o Dužniku
fizičkom licu koje obavlja delatnost
Kontrola dužine .
3.48 PaymentType. SequenceType SequenceType iz originalne Collection instrukcije:
FRST – prvo plaćanje po višestrukom mandatu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 367
RECR – ostala plaćanja po višestrukom mandatu osim
prvog i poslednjeg
FINL – poslednje plaćanje po višestrukom mandatu
ONEO – plaćanje po jednostukom mandatu
3.49 PaymentType.Category
Purpose
Vrednosti: 02, 03
02 – za ovlašćenja kao osnov naplate koja su u posedu
banke dužnika (poseban tip mandata definisan na od
strane banaka na nivou UBS,)
03 – za ostala ugovorna ovlašćenja kao osnov naplate
(opšti tip mandata)
3.52 MandateInformation .
MandateId MandatId iz originalne instrukcije
3.52 MandateInformation .
DateSignature DateSignature iz originalne instrukcije
3.52 MandateInformation .
AmendmentIndicator AmendmentIndicator iz originalne instrukcije
3.52 MandateInformation .
OriginalMandateId
AmendmentInformation iz originalne instrukcije.
ID osnovnog mandata ukoliko je
AmendmentIndicator iz originalne instrukcije=TRUE
3.71 RemmitanceInformation RemmitanceInformation iz originalne Collection
instrukcije
3.97 Debtor Debtor iz originalne Collection instrukcije
3.98 DebtorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN
račun (fiksna vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države
(DD) i kontrolnog broja (KK)
3.99 DebtorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za
direktna zaduženja
3.100 UltimateDebtor.Identification
.OrganisationId
PIB pravnog subjekta dužnika
Kontrola: dužina 9 (za pravna lica) ili 13 (za
preduzetnike) znakova
3.103 Creditor Creditor iz originalne Collection instrukcije (svi
atributi iz originalne instrukcija)
3.104 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN
račun (fiksna vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke
poverioca (CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države
(DD) i kontrolnog broja (KK)
3.101 CreditorAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za
direktna zaduženja
3.105 UltimateCreditor.
Identification .OrganisationId
PIB pravnog subjekta poverioca
Kontrola: dužina 9 (za pravna lica) ili 13 (za
preduzetnike) znakova
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 368
PORUKA paos.002.001.01 REQUEST&CANCELLATION
Struktura: SerbianCancel
• Koristi se za povlačenje ispostavljnih transakcija direktnog zaduženja (nerealizovanih)
• Generiše je banka koja je ispostavila transakciju direktnog zaduženja i dostavlja procesoru
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija
direktnog zaduženja koje se povlače iz poruke i tela poruke (Transaction Information) koje nosi
informacije o pojedinačnim transakcijama direktnog zaduženja koje se povlače (nerealizovanim).
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation TransactionInformati
onCancel
Telo poruke za
povlačenje poruke ili
pojedinačne instrukcije
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije podnosioca
instrukcije
2.2 M 1 + + OriginalTransactionInform
ation
OriginalTransaction
Information2
Identifikacija originalne
poruke
2.3 M 1 + + + OriginalMessageId Max35Text Jedinstveni
identifikator originalne
poruke
2.4 M 1 + + + OriginalMessageNam
e
Max35Text Naziv originalne
poruke
(pacs.xxx.xxx.xx) .
2.5 O 0-1 + + + OriginalCreationDate ISODateTime Datum kreiranja
originalne poruke
2.6 O 0-n + + OriginalTransactionId Max35Text Id transakcije banke
podnosioca instrukcije iz
originalne instrukcije
2.7 M 1 + + TransactionStatus TransactionIndividual
Status2Code
Vrednost: CNCL
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od tekućeg datume
1.3 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.4 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 369
2.1 TransactionId Predstavlja ID Reques&Cancellation instrukcije koji generiše
banka koja je uputila originalnu instrukciju
2.3 OriginalMessageId MessageId iz Header-a poruke u kojoj se nalazila originalna
instrukcija.
Predstavljajedinstveni identifikator poruke u kojoj se nalazi
originalna instrukcije
Kontrola postojanja poruke u evidenciji procesora
2.4 OriginalMessageName Može biti:
pacs.003.001.01, za povlačenje Collection instrukcije
pacs.004.001.01, za povlačenje Return/Refund instrukcija
pacs.007.001.01, za povlačenje Reversal instrukcija
2.5 OriginalCreationDate CreationDate iz Header-a poruke u kojoj se nalazila originalna
instrukcija
2.6 OriginalTransactionId TransactionID iz originalne instrukcije.
Predstavlja ID originalne instrukcije koja se povlači
Kontrola postojanja instrukcije u evidenciji procesora
2.7 TransactionStatus Vrednost: CNCL
PORUKA paos.003.001.01 BALANCE
Struktura: SerbianBalance
• Izvod obračunskog računa učesnika u kliringu
• Generiše je procesor i dostavlja bankama učesnicima.
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija
direktnog zaduženja koje se nalaze u izvodu i tela poruke (Transaction Information) koje nosi
informacije o pojedinačnim transakcijama direktnog zaduženja koje su realizovane preko
obračunskog računa banke učesnika u klirinškom ciklusu.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation Transaction
InfrmationBalance
Telo poruke za izvod
obračunskog računa
učesnika u kliringu
2.1 M 1 + + BalanceId Max35Text Idetifikator izvoda,
jedinstven na nivou
učesnika i poslovne
godine
2.2 M 1 + + LastPage YesNoIndicator Indikator poslednje
poruke (TRUE) ukoliko
se izvod šalje u više
poruka
2.3 M 1 + + SettlementDate ISODate Datum
međubankarskog
obračuna
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 370
2.4 M 1 + + SettlementInformation Settlement
Information
Informacije o obračunu
2.4 M 1 + + + SettlementMethodCode SettlementMethod2
Code
Vrednost: CLRG
2.5 M 1-n + + ClearingCycle ClearingCycle Informacije o ciklusu
kliringa
2.6 M 1 + + + ClearinCycleId Max16Text Identifikacija klirinškog
ciklusa
2.7 M 1 + + + Trn Max16Text Identifator poruke
MT202 kojom je
realizovana neto pozicija
učesnika
2.8 O 0-n + + + BalanceLine BalanceLine Realizovane transakcije
2.9 M 1 + + + + MessageIdentification Message
Identification
Identifikacija poruke
2.10 M 1 + + + + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
2.11 M 1 + + + + + MessageName Max35Text Naziv poruke
(pacs.xxx.xxx.xx)
2.12 M 1 + + + + + CreationDate ISODateTime Datum kreiranja poruke
2.13 M 1 + + + + + InstructingAgent Financial
Institution2
Pošiljalac poruke
2.13 M 1 + + + + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
2.13 M 1 + + + + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
2.14 M 1 + + + + + InstructedAgent Financial
Institution2
Primalac poruke
2.14 M 1 + + + + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
2.14 M 1 + + + + + + + BICAgent BICIdentifier BIC primaoca poruke
2.15 M 1 + + + + OriginalTransactionId Max35Text Id transakcije podnosioca
2.16 M 1 + + + + SettlementType SettlementType Vrsta transakcije u
odnosu na račun
Učesnika: CREDIT,
DEBIT
2.17 M 1 + + + + SettlementAmount EuroMax15
Amount
Iznos transakcije
2.17 M 1 + + + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti
2.17 M 1 + + + + + CurrencyCode EuroCurrencyCode Kod domaće valute:RSD
2.18 M 1 + + + + DebtorAccount CashAccount8 Broj računa zaduženja
2.18 M 1 + + + + + AccountId Account
Identification2
Identifikacija broja
računa zaduženja
2.18 M 1 + + + + + + IBANAccount IBANIdentifier IBAN broj računa
zaduženja
2.19 M 1 + + + + CreditorAccount CashAccount8 Broj računa odobrenja
2.19 M 1 + + + + + AccountId Account
Identification2
Identifikacija računa
odobrenja
2.19 M 1 + + + + + + IBANAccount IBANIdentifier IBAN broj računa
odobrenja
2.20 M 1 + + + + StructuredRemmitance Structured
Remmitance1
Struktuirane informacije
o plaćanju
2.21 O 0-1 + + + + + Purpose Purpose1Choice Informacija o svrsi
plaćanja
2.21 O 0-1 + + + + + + Purport Max35Text Svrha plaćanja iz
instrukcije zaduženja
2.22 O 0-1 + + + + + ReasonInformation ReasonInformation Razlog povraćaja za
transakcije Return/
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 371
Refund i Reversal
2.22 O 0-1 + + + + + + Reason Reason3Choice Kodirani razlog
povraćaja
2.22 O 0-1 + + + + + + + ReasonCode Transaction
ReasonCode
Kod razloga povraćaja
2.23 O 0-1 + + + + UnstructuredRemmita
nce
Max140Text Nestruktuirane
informacije o plaćanju
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Jednak tekućem datumu
1.3 InstructingAgent. BICAgent BIC Procesora
1.4 InstructedAgent. BICAgent Mora biti u evidenciji učesnika kliringa za direktna zaduženja
2.1 BalanceId ID izvoda koji generiše Procesor, jedinstven na nivou
učesnika u toku godine.
Struktura identifikatora: BIC+godina+redni broj izvoda u
godini
2.2 LastPage Ukoliko se izvod upućuje učesniku u jednoj poruci, vrednost je
TRUE.
Ukoliko se izvod upućuje učesniku u više poruka, samo
poslednja sadrži vrednost TRUE, a ostale vrednost FALSE.
2.3 SettlementDate Datum u kome je realizovan međubankarski obračun.
Manji ili jednak tekućem datumu
2.4 SettlementMethodCode Vrednost: CRLG
2.6 ClearinCycleId ID klirinškog ciklusa koji generiše Procesor i mora biti
jedinstven na nivou dana.
Struktura identifikatora: Datum+redni broj u toku dana
2.7 Trn ID swift poruke MT202 kojom je u RTGS sistemu
realizovana neto pozicija učesnika u klirinškom krugu
ClearingCycleID
2.10 MessageId MessageID iz Header-a poruke u kojoj se nalazila realizovana
instrukcija u kliringu
Predstavlja jedinstveni identifikator poruke u kojoj se nalazila
instrukcija
2.11 MessageName Može biti:
pacs.003.001.01, za Collection instrukcije
pacs.004.001.01, za Return/Refund instrukcija
pacs.007.001.01, za Reversal instrukcija
2.12 CreationDate CreationDate iz Header-a poruke u kojoj se nalazila
realiizovana instrukcija u kliringu
2.13 InstructingAgent.BICAgent InstructingAgent iz Header-a poruke u kojoj se nalazila
realiizovana instrukcija u kliringu
2.14 InstructedAgent. BICAgent InstructedAgent iz Header-a poruke u kojoj se nalazila
realiizovana instrukcija u kliringu
2.15 OriginalTransactionId TransactionID iz Collection, Return/Refund i Reversal
instrukcije.
Predstavlja ID instrukcije koja je realizovana u kliringu.
2.16 SettlementType - DEBIT za zaduženje računa učesnika
- CREDIT za odobrenje računa učesnika
2.17 SettlementAmount. Amount Predstavlja iznos zaduženja ili odobrenja računa učesnika i to:
- Settlement Amount, iz Collection instrukcija
- ReturnSettlementAmount, iz Return/Refund instrukcija
- Reversed SettlementAmount, iz Reversal instrukcija
2.17 SettlementAmount.
CurrencyCode Vrednost: RSD
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 372
2.18 DebtorAccount.
IBANAccount
Broj računa konačnog zaduženja i to:
- DebtorAccount, iz Collection instrukcija
- Creditor Account, iz Return/Refund instrukcija
- Creditor Account, iz Reversal instrukcija
2.19 CreditorAccount.
IBANAccount
Broj računa konačnog odobrenja i to:
- Creditor Account, iz Collection instrukcija
- DebtorAccount, iz Return/Refund instrukcija
- DebtorAccount, iz Reversal instrukcija
2.21 Purpose. Purport Purport (2.62) iz Collection instrukcije
2.22 Reason. ReasonCode ReasonCode (3.22 za Return/Refund, odnosno 3.19 za
Reversal instrukcije)
2.23 UnstructuredRemmitance UnstructuredRemmitance (2,82 za Collection, 3.79 za
Return/Refund, odnosno 3.76 za Reversal instrukcije)
Napomena: Nije potrebno vršiti dodatne kontrole sadržaja poruke, s obzirom da procesor kreira ove
poruke na osnovu već kontrolisanih podataka iz instrukcija.
PORUKA paos.006.001.01 COLLECTION QUERY
Struktura: SerbianQuery
• Zahtev za realizaciju upita u transakcije direktnog zaduženja koje se odnose na obračunski račun
pošiljaoca poruke
• Generiše je banka – učesnik u kliringu i dostavlja procesoru.
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije upita i tela poruke
(Transaction Information) koje sadrži uslove za upit u transakcije direktnog zaduženja koje su
(ne)realizovane preko obračunskog računa učesnika u klirinškom ciklusu – podnosioca upita.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation Transaction
InformationQuery
Telo poruke za
povlačenje poruke ili
pojedinačne instrukcije
2.1 M 1 + + TransactionId Max35Text Jedinstveni identifikator
upita
2.2 O 0-1 + + MessageIdentification Message
Identification
Identifikacija poruke
Upiti po proruci, odnosno:
- Za konkretnu poruku
(MessageID)
- Za poruke određenog
tipa (MessageName)
- Po datumu kreiranja
poruke, za određeni dan
(CreationDate)
- U datom periodu
realizacije
(SettlementPeriod)
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 373
- Za konkretnog
pošiljaoca
(InstructingAgent)
- Za konkretnog primaoca
(InstructedAgent)
2.3 O 0-1 + + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
2.4 O 0-1 + + + MessageName Max35Text Naziv poruke
(pacs.xxx.xxx.xx)
2.5 O 0-1 + + + CreationDate ISODateTime Datum kreiranja poruke
2.6 O 0-1 + + + SettlementPeriod Period Period međubankarskog
obračuna
2.6 O 0-1 + + + + SettlementDateFirst ISODate Datum od
2.6 O 0-1 + + + + SettlementDateLast ISODate Datum do
2.7 O 0-1 + + + InstructingAgent Financial
Institution2
Pošiljalac poruke
2.7 O 0-1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
2.7 O 0-1 + + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
2.8 O 0-1 + + + InstructedAgent Financial
Institution2
Primalac poruke
2.8 O 0-1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
2.8 O 0-1 + + + + + BICAgent BICIdentifier BIC primaoca poruke
2.9 O 0-1 + + OriginalTransactionId Max35Text Id transakcije podnosioca
Upiti po instrukciji za
konkretnu instrukciju
2.10 O 0-1 + + SettlementType SettlementType Vrsta transakcije u odnosu
na račun Učesnika:
CREDIT, DEBIT
Upit u instrukcije kojima
se zadužuje ili odobrava
račun učesnika
2.11 O 0-1 + + BetweenAmount MinMaxAmount Raspon iznosa transakcija
Upit u transakcije koje su u
datom rasponu iznosa
2.11 O 0-1 + + + MinAmount EuroMax15
Amount
Minimalni iznos
transakcije
2.11 O 0-1 + + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti
2.11 O 0-1 + + + + CurrencyCode EuroCurrencyCode Kod domaće valute
2.11 O 0-1 + + + MaxAmount EuroMax15
Amount
Maksimalni iznos
transakcije
2.11 O 0-1 + + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti
2.11 O 0-1 + + + + CurrencyCode EuroCurrencyCode Kod domaće valute
2.12 O 0-1 + + DebtorAccount CashAccount8 Broj računa zaduženja
Upit u transakcije za datog
dužnika (podnosilac upita
predstavlja banku
poverioca)
2.12 O 0-1 + + + AccountId Account
Identification2
Identifikacija broja računa
zaduženja
2.12 O 0-1 + + + + IBANAccount IBANIdentifier IBAN broj računa
zaduženja
2.13 O 0-1 + + CreditorAccount CashAccount8 Broj računa odobrenja
Upit u transakcije za datog
poverioca (podnosilac
upita predstavlja banku
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 374
dužnika)
2.13 O 0-1 + + + AccountId Account
Identification2
Identifikacija računa
odobrenja
2.13 O 0-1 + + + + IBANAccount IBANIdentifier IBAN broj računa
odobrenja
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Jednak tekućem datumu
1.3 InstructingAgent. BICAgent Mora biti u evidenciji učesnika kliringa za direktna zaduženja
1.4 InstructedAgent. BICAgent BIC Procesora
2.1 TransactionId Predstavlja ID upita koji generiše banka koja je uputila upit
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
Napomena: Nije potrebno vršiti dodatne kontrole sadržaja poruke, s obzirom da će rezultat upita (odgovor
procesora) biti u skladu sa „kvalitetom“ podataka u upitu
PORUKA paos.007.001.01 COLLECTION RESPONSE
Struktura: SerbianResponse
• Odgovor na upit
• Generiše procesor i dostavlja banci koja je podnela zahtev za realizacijom upita (paos.006.001.01
COLLECTION QUERY).
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije upita i tela poruke
(Transaction Information) koje sadrži transakcije direktnog zaduženja koje zadovoljavaju uslove
postavljenog upita.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation TransactionInforma
tionCollection
Response
Odgovor na postavljeni
upit
2.1 M 1 + + TransactionId Max35Text Jedinstveni
identifikator odgovora
na upit
2.2 M 1 + + OriginalTransactionId Max35Text Id transakcije
podnosioca upita iz
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 375
originalne instrukcije
2.3 O 0-n + + QueryResponse QueryAnd
Response
Odgovor na upit
2.4 M 1 + + + OriginalTransactionInfor
mation
OriginalTransaction
Information
Identifikacija originalne
poruke
2.5 M 1 + + + + OriginalMessageId Max35Text Jedinstveni
identifikator originalne
poruke
2.6 M 1 + + + + OriginalMessageName Max35Text Naziv originalne
poruke
(pacs.xxx.xxx.xx)
2.7 O 0-1 + + + + OriginalCreationDate ISODateTime Datum kreiranja
originalne poruke
2.8 M 1 + + + OriginalTransactionId Max35Text Id transakcije banke
podnosioca instrukcije iz
originalne instrukcije
2.9 M 1 + + + TransactionStatus TransactionIndividua
lStatus2Code
Status transakcije iz
internog šifarnika
Procesora
2.10 M 1 + + + OriginalTransactionInfor
mation
Transaction
Information3
Telo poruke za
instrukcije
pacs.xxx.xxx.xx
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Jednak tekućem datumu
1.3 InstructingAgent. BICAgent BIC Procesora
1.4 InstructedAgent. BICAgent Mora biti u evidenciji učesnika kliringa za direktna zaduženja
2.1 TransactionId Predstavlja ID odgovora na upita koji generiše Procesor
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
2.2 OriginalTransactionId TransactionId iz Collection Query poruke
Napomena: Nije potrebno vršiti dodatne kontrole sadržaja poruke, s obzirom da rezultat upita (odgovor
procesora) predstavljaju već kontrolisani podaci iz instrukcija.
PORUKA paos.008.001.01 CONFIRMATION
Struktura: SerbianConfirmation
• Informacija o neto poziciji Učesnika u ciklusu Kliringa
• Generiše je procesor i dostavlja bankama učesnicima uklirinškom ciklusu.
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije o neto poziciji i tela
poruke (Transaction Information) koje sadrži neto poziciju banke.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.3 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution Identifikacija
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 376
Identification4 pošiljaoca poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation Transaction
Information
Confirmation
Telo poruke za
dostavljanje
infromacije o neto
poziciji učesnika u
kliringu
2.1 M 1 + + SettlementDate ISODate Datum
međubankarskog
obračuna
2.2 M 1 + + SettlementInformation Settlement
Information9
Informacije o obračunu
2.2 M 1 + + + SettlementMethodCode SettlementMethod2
Code
Vrednost: CLRG
2.3 M 1 + + ClearinCycleId Max16Text Identifikacija
klirinškog ciklusa
2.4 M 1 + + TRN Max16Text Identifator swift poruke
MT202 za realizaciju
Neto pozicija učesnika u
kliringu
2.5 M 1 + + CreditType SettlementCredit
Information
Transakcije odobrenja
2.5 M 1 + + + SettlementAmount EuroMax15Amount Iznos transakcija
odobrenja
2.5 M 1 + + + + Amount Decimal, 15,2 Iznos transakcija
odobrenja u domaćoj
valuti
2.5 M 1 + + + + CurrencyCode EuroCurrencyCode Kod domaće valute
2.6 M 1 + + DebitType SettlementDebit
Information
Transakcije zaduženja
2.6 M 1 + + + SettlementAmount EuroMax15Amount Iznos transakcija
zaduženja
2.6 M 1 + + + + Amount Decimal, 15,2 Iznos transakcija
zaduženja u domaćoj
valuti
2.6 M 1 + + + + CurrencyCode EuroCurrencyCode Kod domaće valute
2.7 M 1 + + SettlementType SettlementType Tip transakcije u odnosu
na neto poziciju računa
Učesnika u kliringu:
CREDIT, DEBIT
2.8 M 1 + + InterbankSettlementAmount EuroMax15Amount Iznos transakcije u
međubankarskom
obračunu
2.8 M 1 + + + Amount Decimal, 15,2 Iznos transakcije u
domaćoj valuti
2.8 M 1 + + + CurrencyCode EuroCurrencyCode Kod domaće valute
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Jednak tekućem datumu
1.3 InstructingAgent.BICAgent BIC Procesora
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 377
1.4 InstructedAgent. BICAgent Mora biti u evidenciji učesnika kliringa za direktna zaduženja
2.1 SettlementDate Datum obračuna.
Mora biti manji ili jednak od tekućem datumu
2.2 SettlementMethodCode Vrednost:CLRG
2.3 ClearinCycleId Kontrola klirnškog ciklusa u evidenciji Procesora
2.4 TRN Kontrola identifikatora SWIFT poruke u evidenciji Procesora
2.5 CreditType. Amount Suma svih odobrenja obračunskog računa učesnika u kliringu
2.5 CreditType. CurrencyCode Vrednost: RSD
2.6 DebitType. Amount Suma svih zaduženja obračunskog računa učesnika u kliringu
2.6 DebitType. CurrencyCode Vrednost: RSD
2.7 SettlementType Vrednosti:
- CREDIT, ukoliko je CreditType. Amount veći ili jednak od
DebitType.Amount
- DEBIT, ukoliko je CreditType. Amount manji od
DebitType.Amount
2.8 InterbankSettlementAmount.
Amount
Apsolutna vrednost razlike:CreditType. Amount-
DebitType.Amount
2.8 InterbankSettlementAmount.
CurrencyCode Vrednost: RSD
PORUKA paos.009.001.01 LIMIT
Struktura: SerbianLimit
• Zahtev za postavljanje Limita zaduženja do koga banka može biti zadužena u klirinškom ciklusu
• Generišu je banke učesnici u kliringu i dostavljaju procesoru.
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije o limitu zaduženja i
tela poruke (Transaction Information) koje sadrži Limit zaduženja.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation Transaction
InformationLimit
Telo poruke za
dostavljanje Limita
zaduženja računa
Učesnika u kliringu
2.1 M 1 + + Account CashAccount8 Broj računa učesnika u
RTGS sistemu za učesnik
postavlja Limit zaduženja
2.1 M 1 + + + AccountId AccountIdentification2 Identifikacija broja računa
2.1 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
2.2 M 1 + + LimitAmount EuroMax15Amount Limit
2.2 M 1 + + + Amount Decimal, 15,2 Iznos limita u domaćoj
valuti
2.2 M 1 + + + CurrencyCode EuroCurrencyCode Kod domaće valute: RSD
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 378
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Jednak tekućem datumu
1.3 InstructingAgent.BICAgent Mora biti u evidenciji učesnika kliringa za direktna zaduženja
1.4 InstructedAgent. BICAgent BIC Procesora
2.1 Account. IBANAccount Žiro račun učesnika u RTGS sistemu, evidentiran kod procesora
2.2 LimitAmount. Amount Veći ili jednak nuli
2.2 LimitAmount.
CurrencyCode Vrednost: RSD
PORUKA admi.002.001.01 administrativna poruka
• Obaveštenje o odbijanju prethodno primljene poruke, koje procesorski sistem šalje pošiljaocu
poruke i sadrži specifične informacije o razlozima odbijanja.
• Generiše je procesor i dostavlja učesniku u kliringu - pošiljaocu poruke.
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije i tela poruke (Rsn)
koje sadrži specifične informacije o razlozima odbijanja.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + Rsn RejectionReason2 Opis razloga odbijanja
2.1 M 1 + + Ref Max35Text Referenca
2.2 M 1 + + RjctgPtyRsn Max35Text Razlog odbijamja
poruke
2.3 O 0-
1
+ + RjctnDtTm ISODateTime Vreme i datum
odbijanja poruke
2.4 O 0-
1
+ + ErrLctn Max35Text Greška
2.5 O 0-
1
+ + RsnDesc Max350Text Opis razloga
2.6 O 0-
1
+ + AddtlData Max20000Text Dodatni podaci
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
2.0 Rsn Informacije o odbijanju poruke
2.1 Ref Referenca koja identifikuje poruku koja se odbija
2.2 RjctgPtyRsn Razlog odbijanja poruke, minimalna dužina 1, maksimalna 35
karaktera
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 379
2.3 RjctnDtTm Vreme i datum generisanja poruke za odbijanje
2.4 ErrLctn Mesto u poruci na kojem je konstatovana greška zbog koje se
poruka odbija
2.5 RsnDesc Opis razloga odbijanja, maksimalno 350 karaktera
2.6 AddtlData Dodatno obrazloženje odbijanja, maksimalna 20.000 karaktera
PORUKA admi.004.001.01 poruka za notifikaciju
• Obaveštenje o pojavi događaja u sistemu
• Generiše je procesor i dostavlja učesnicima u kliringu.
• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije i tela poruke (EvtInf)
koje sadrži informaciju participantima o događaju koji su se pojavili u sistemu.
• Struktura poruke:
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader122 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
3.0 M 1 + EvtInf Event1 Informacija o
događaju
3.1 M 1 + + EvtCd Max4Alpha
NumericText
Definisani kod
događaja
3.2 O 0-1 + + EvtParam Max35Text Parametri događaja
3.3 O 0-1 + + EvtDesc Max350Text Opis događaja
3.4 O 0-1 + + EvtTm ISODateTime Vreme događaja
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
3.0 EvtInf Detaljne informacije o događaju u sistemu
3.1 EvtCd Kod događaja definisan od strane KIB-a u formatu [a-zA-Z0-
9]{1,4}
3.2 EvtParam Parametri dodađaja definisani od strane KIB-a, maksimalno 35
karaktera
3.3 EvtDesc Ops događaja, maksimalna 350 karaktera
3.4 EvtTm Datum i vreme generisanja poruke o događaju
PORUKA MT202
• Za realizaciju međubankarskog obračuna u RTGS sistemu
• Generiše je procesor i dostavlja RTGS sistemu po završenom ciklusu Kliringa
• U zavisnosti od neto pozicije učesnika u kliringu, realizuje naplatu odnosno plaćanje na račun
Učesnika u kliringu
• Struktura poruke:
Polje Element poruke Kardinalnost
113 Poslovni prioritet M 1
20 Referenca pošiljoca M 1
21 Povezana referenca M 1
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 380
32А Datum valute, šifra valute,iznos M 1
53А /D/račun BIC
M 1
58А /C/račun BIC
M 1
72 Slobodan element M 1
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
113 Poslovni prioritet U bloku 3, vrednost: „0011“
20 Referenca pošiljoca Referenca Procesora
21 Povezana referenca Vrednost: „NONREF”
32А
Datum valute, šifra
valute,
iznos
Datum valute (u formatu ggmmdd): datum realizacije obračuna po
kliringu
Šifra valute: RSD
Iznos (u formatu sa dva decimalna mesta i zarez kao celobrojni
separator): iznos obračunate neto pozicicije učesnika u kliringu
53А /D/račun BIC
• Za realizaciju negativne neto pozicije, račun i BIC učesnika sa
negativnom neto pozicijom
• Za realizaciju pozitivne neto pozicije, račun i BIC Procesora
58А /C/račun BIC
• Za realizaciju negativne neto pozicij, račun i BIC Procesora
• Za realizaciju pozitivne neto pozicije, račun i BIC učesnika sa
pozitivnom neto pozicijom
72 Slobodan element
Struktura elmenta:
:72:/BNF/PBZ-
//PBO-
//SIF-283-DirectDebit+identifikacija ciklusa Kliringa
PORUKA mndt.001.001.01 MANDATE
Struktura: SerbianMandateEvidence
• Koristi se za evidentiranje i izmenu sadržaja Mandata. Generišu je i ispostavljaju Procesoru banke
koje koriste dodatni servis vođenja Registra mandata
• Ukoliko se koristi kao instrukcija za evidendtiranje Mandata, element AmendmentIndicator ima
vrednost FALSE
• Ukoliko se koristi kao instrukcija za izmenu sadržaja Mandata, element AmendmentIndicator ima
vrednost TRUE, a element OrgMandateId vrednost identifikatora osnovnog mandata
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader1 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke.
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke.
1.26 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.26 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.26 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.27 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.27 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.27 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation Transaction
Information3
Telo poruke za
evidentiranje
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 381
Mandata
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije podnosioca
instrukcije.
2.8 M 1 + + MandateInformation MandateInformation3 Informacije o mandatu
2.9 O 0-1 + + + ContractId Max35Text Broj ugovora po kome je
izdat mandat
2.10 M 1 + + + MandateType MandateType
Information8
Tip mandata
2.11 M 1 + + + + SequenceType SequenceType1Code Vrednosti: RECR,
ONEO
2.22 M 1 + + + MandateId Max35Text Identifikacija mandata ili
aneksa
2.23 M 1 + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa
2.24 M 1 + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
(izmena mandata)
2.25 O 0-1 + + + AmendmentInformation AmendmentInformation
Details4
Informacije o osnovnom
mandatu
2.26 O 0-1 + + + + OrgMandateId Max35Text Identifikator osnovnog
mandata
2.43 M 1 + + Creditor PartyIdentification13 Poverilac
2.43 M 1 + + + CreditorId Max35Text Id poverioca, matični
broj ili Jmbg
2.43 M 1 + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-2 + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + CreditorAccount CashAccount8 Broj računa poverioca
2.44 M 1 + + + AccountId Account
Identification2
Identifikacija računa
poverioca
2.44 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca
2.43 M 1 + + + + BICAgent BICIdentifier BIC banke poverioca
2.57 M 1 + + Debtor PartyIdentification19 Dužnika
2.57 M 1 + + + DebtorId Max35Text Id dužnika, matični broj
ili Jmbg
2.57 M 1 + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
dužnika
2.57 O 0-2 + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + AccountId Account
Identification2
Identifikacija računa
dužnika
2.58 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika
2.59 M 1 + + + + BICAgent BICIdentifier BIC banke dužnika
2.81 O 0-1 + + RemmitanceInformation Remittance
Information3
Informacije o
plaćanju
2.82 O 0-n + + + UnstructuredRemmitance Max140Text Nestruktuirane
informacije o plaćanju
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 382
2.83 M 1 + + + StructuredRemmitance StructuredRemittance
Information6
Struktuirane informacije
o plaćanju
2.84 M 1 + + + + FirstCollectionDate ISODate Datum kada može da
bude realizovana prvo
zaduženje
2.84 O 0-1 + + + + FinalCollectionDate ISODate Datum do koga može
da bude izvršavano
poslednje zaduženje
(Datum isteka
mandata)
2,85 M 1 + + + + Revocation Revocation
Identification1
Opozivost Mandata
2.85 M 1 + + + + + RevocationIndicator TrueFalseIndicator Indikator opozivosti
Mandata
2.85 O 0-1 + + + + + Conditional Max140Text Uslovi opoziva Mandata
2.86 M 1 + + + + NumberOfCollection Max15NumericText Maksimalni broj obaveza
po mandatu
2.87 M 1 + + + + TotalAmount EuroMax9Amount Ukupan iznos zaduženja
po mandatu.
2.87 M 1 + + + + + Amount Decimal, 9,2 Ukupan iznos plaćanja.
2.87 M 1 + + + + + CurrencyCode EuroCurrencyCode Kod valute (RSD)
2.88 O 0-1 + + + + Frequency Metric FrequencyMetric Metrika dospeća
2.88 M 1 + + + + + Frequency Code FrequencyCode Kodirana metrika
dospeća:
DAIL, za dan,
MNTH, za mesec
YEAR, za godinu
2.88 M 1 + + + + + Periodic Max15NumericText Periodika dospeća u
datoj metrici
2.89 O 0-n + + + + FixedReqDate ISODate Fiksni datumi dospeća
(DueDate)
2.90 O 0-1 + + + + Tolerancy Tolerancy Period tolerancije
dospeća u danima
2.90 M 1 + + + + + TolerancySign TolerancySign Kodirani znak perioda
tolerancije:
PLS, po dospeću
(PLUS)
MNS, pre dospeća
(MINUS)
BTH, pre i posle
dospeća (BOTH)
2.90 M 1 + + + + + TolerancyValue Max15NumericText Broj dana tolerancije u
dospeću
2.91 O 0-1 + + + + DebitAmount EuroMax9Amount Maksimalni iznos u
jednom nalogu
zaduženja (collection)
2.91 M 1 + + + + + Amount Decimal, 9,2 Iznos plaćanja.
2.91 M 1 + + + + + CurrencyCode EuroCurrencyCode Kod valute( RSD)
2.92 O 0-1 + + + + Exchange Exchange Valutni uslovi plaćanja
2.92 M 1 + + + + + CurrencyCode CurrencyCode Kod valute plaćanja
2.92 M 1 + + + + + ExchangeRate BaseOnRate Kurs ugovorene valute:
SEL – prodajni kurs
MID – srednji kurs
BUY – kupovni kurs
2.92 M 1 + + + + + Exchange list BaseOnList Vrednosti :
NBS – za kursnu listu
Narodne banke
BANK – za kursnu listu
banke (nije osnov za
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 383
kontrolu Procesora)
2.97 O 0-1 + + + + CreditorReference CreditorReference
Information1
Referisanje poverioca na
Identifikator dužnika
2.97 O 0-1 + + + + + ReferenceType CreditorReference
Type1
Referenca
2.97 O 0-1 + + + + + + Purport Max35Text Poziv na broj dužnika
2.105 O 0-1 + + + + AdditionalRemmitance Max140Text Dodatne informacije o
plaćanju
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od tekućeg datuma
1.26 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.27 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.1 TransactionId Predstavlja ID instrukcije za evidentiranje ili izmenu Mandata
koji generiše banka pošiljalac preko koga identifikuje transakciju
Maksimalna dužina: Max32Text., osim u slučaju greške kada je
Max35Text.
U slučaju odbijanja instrukcije od strane Procesora zbog
ustanovljene greške, drugom učesniku se dostavlja Iinstrukcije
u kojoj TransactionId započinje sa ERR+originalni
TransactionId
2.11 SequenceType Vrednosti: RECR, ONEO
RECR – mandat s više dospeća
ONEO – mandat sa jednim dospećem
2.22 MandateId Jedinstveni identifikator mandata ili aneksa koji generiše Poverilac
i obezbeđuje njegovu jedinstvenost (na nivou Poverioca).
Struktura MandateId:
Identifikacija mandata ili aneksa-Identifikacija pravnog
lica koje je izdalo identifikaciju mandata ili aneksa i
garantuje njegovu jedinstvenost na nvou Poverioca, ili
Identifikacija mandata ili aneksa (bez crtice)
2.23 DateSignature Manji ili jednak od datuma kreiranja poruke CreationDate.
Za izmenu mandata (AmendmentIndicator=TRUE) mora biti veći
ili jednak poslednjem važećem amandmanu osnovnog mandata
(u statusu ACTV)
2.24 AmendmentIndicator TRUE – ukoliko se instrukcija podnosti po osnovu aneksa
mandata
FALSE – ukoliko se instrukcija podnosi po osnovu mandata
2.26 OrgMandateId Jedisntveni identifikator osnovnog mandata koji se menja.
Mora postojati u Registru mandata.
Poslednji važeći aneks ovog osnovnog mandata mora biti u
aktivnom statusu ACTV
2.43 Creditor.CreditorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Poveriocu pravnom
licu
JMBG, dužine 13 – ukoliko se radi o Poveriocu fizičkom licu koje
obavlja delatnost
Kontrola dužine.
2.43 Creditor. CountryCode Iz šifarnika država
2.44 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 384
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke poverioca
(CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.45 CreditorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.57 Debtor.DebtorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku pravnom licu
JMBG, dužine 13 – ukoliko se radi o Dužniku fizičkom licu koje
obavlja delatnost
Kontrola dužine .
2.57 Debtor. CountryCode Iz šifarnika država
2.58 DebtorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.59 DebtorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.84 FirstCollectionDate Datum kada može da bude realizovano prvo zaduženje
Kontrola se vrši kod evidentiranja osnovnog mandata i to: ne
može biti manji od datuma potpisa osnovnog mandata
(DateSignature).
2.84 FinalCollectionDate Datum isteka Mandata – datum do koga može da bude
realizovano poslednje zaduženje
Ne može biti manji od datuma prvog zaduženja
(FirstCollectionDate) niti manji od datuma potpisa mandata ili
aneksa mandata (DateSignature)
2.85 RevocationIndicator Indikator opozivosti mandata:
True – opoziv mandat
False – neopoziv mandat
2.85 Revocation.Conditional Dodatni opis uslova opoziva
2.86 NumberOfCollection Maksimalni broj obaveza po mandatu
Ako je dat, mora biti veći od nule i ne može biti manji od ukupnog
broja zadatih fiksnih dospeća i broja dospeća po zadatoj metrici do
zadatog datuma poslednjeg zaduženja.
Ukoliko se menja aneksom mandata, ne može biti manji od broja
realizovanih dospeća po mandatu u evidenciji Procesora
2.87 TotalAmount.Amount Ukupan iznos zaduženja po mandatu
Ako je dat, mora biti veći od nule i veći od zadatog maksimalnog
iznosa u jednom nalogu zaduženja (DebitAmount.Amount).
Ukoliko se menja aneksom mandata, ne može biti manji od
ukupnog iznosa realizovanih dospeća po mandatu
2.87 TotalAmount.CurrencyCode Kod valute u kojoj je dat ukupan iznos zaduženja po mandatu.
Mora biti RSD i jednak kao i kod valute maksimalnog iznosa po
jednom zaduženju (DebitAmount. CurrencyCode).
2.88 Frequency Code Kodirana metrika dospeća:
DAIL, za dan,
MNTH, za mesec
YEAR, za godinu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 385
2.88 Periodic Broj koji predstavlja periodiku dospeća u datoj metrici.
Ako je dat mora biti veći od nule.
2.89 FixedReqDate Fiksni datumi dospeća (DueDate)
2.90 TolerancySign Kodirani znak perioda tolerancije:
PLS, po dospeću (PLUS)
MNS, pre dospeća (MINUS)
BTH, pre i posle dospeća (BOTH)
2.90 TolerancyValue Broj dana tolerancije u dospeću
Ako je dat mora biti veći od nule.
2.91 DebitAmount.Amount Maksimalni iznos u jednom nalogu zaduženja (collection)
Ako je dat, mora biti veći od nule i ne sme biti veći od ukupnog
iznosa zaduženja po mandatu (TotalAmount.Amount).
2.91 DebitAmount. CurrencyCode Kod valute maksimalnog iznosa po jednom zaduženju.
Mora bitiRSD.
2.92 Exchange.CurrencyCode Kod ugovorene valute.
Zadaje se ukoliko se razlikuje od koda valute plaćanja (RSD) i ne
može se menjati aneksom (druga ugovorena valuta)
Moguća eventualna kontrola da je kod valute iz šifarnika
dozvoljenih valuta
2.92 Exchange.ExchangeRate Kurs za preračun iz ugovorene valute u valutu plaćanja (RSD):
SEL – prodajni kurs
MID – srednji kurs
BUY – kupovni kurs
2.92 Exchange.Exchange list Oznaka kursne liste koja se pprimenjuje u preračunu iz ugovorene
valute u valutu plaćanja (RSD):
NBS – za kursnu listu Narodne banke (može biti osnov za kontrolu
Collection-a od strane Procesora)
BANK – za kursnu listu banke (nije osnov za kontrolu Collection-
a od strane Procesora)
2.97 CreditorReference. Purport Identifikator na koji se referiše Poverilac pri ispostavljanju
instrukcije direktnog zaduženja. Ovaj identifikator generiše
Dužnik preko koga Dužnik identifikuje transakciju.
Strukturapoziva na brojdužnika u domaćem platnom prometu:
MMPPPPPPPPPPPPPPPPPPPP, gde je:
MM – model poziva na broj sa vrednošću 97 ili „ „
PPPPPPPPPPPPPPPPPPPP – poziv na broj dužnika.
Kontrola strukture ili vrednosti „NONPROVIDED“.
2.105 AdditionalRemmitance Druge struktuirane informacije dogovorene od strane Dužnika i
Poverioca koje služe za dokumentovanje ispunjenosti uslova za
realizaciju plaćanja navedenih u mandatu, a koje Procesor ne
kontroliše
PORUKA mndt.002.001.01 REMOVE MANDATE
Struktura: SerbianMandateRemove
• Koristi se za povlačenje Mandata. Generišu je i ispostavljaju Procesoru banke koje koriste dodatni
servis vođenja Registra mandata
• Element MandateStatus ima vrednost REMO
Index Kardinalnost Element poruke Tip Opis i poslovna pravila
1.0 M 1 + Header GroupHeader1 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke.
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke.
1.26 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.26 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 386
1.26 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.27 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.27 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.27 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation Transaction
Information3
Telo poruke za
evidentiranje Mandata
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id transakcije
podnosioca instrukcije.
2.8 M 1 + + MandateInformation Mandate
Information3
Informacije o mandatu
2.9 O 0-1 + + + ContractId Max35Text Broj ugovora po kome je
izdat mandat
2.10 M 1 + + + MandateType MandateType
Information8
Tip mandata
2.11 M 1 + + + + SequenceType SequenceType1Code Vrednosti: RECR, ONEO
2.22 M 1 + + + MandateId Max35Text Identifikacija mandata
2.23 M 1 + + + DateSignature ISODate Datum potpisivanja
mandata
2.43 M 1 + + Creditor Party
Identification13
Poverilac
2.43 M 1 + + + CreditorId Max35Text Id poverioca, matični broj
ili Jmbg
2.43 M 1 + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-2 + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + CreditorAccount CashAccount8 Broj računa poverioca
2.44 M 1 + + + AccountId Account
Identification2
Identifikacija računa
poverioca
2.44 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca
2.43 M 1 + + + + BICAgent BICIdentifier BIC banke poverioca
2.57 M 1 + + Debtor Party
Identification19
Dužnika
2.57 M 1 + + + DebtorId Max35Text Id dužnika, matični broj ili
Jmbg
2.57 M 1 + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa dužnika
2.57 O 0-2 + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + AccountId Account
Identification2
Identifikacija računa
dužnika
2.58 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika
2.59 M 1 + + + + BICAgent BICIdentifier BIC banke dužnika
2.60 M 1 + + MandateStatus MandateIndividual
Status2Code
Vrednosti: REMO
2.105 O 0-1
+ + AdditionalReasonInformation Max105Text Dodatno obrazloženje za
povlačenje mandata
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 387
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od tekućeg datuma
1.26 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.27 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.1 TransactionId Predstavlja ID instrukcije za povlačenje Mandata koji generiše
banka pošiljalac i preko koga identifikuje transakciju
Maksimalna dužina: Max32Text., osim u slučaju greške kada je
Max35Text.
U slučaju odbijanja instrukcije od strane Procesora zbog
ustanovljene greške, drugom učesniku se dostavlja Iinstrukcije u
kojoj TransactionId započinje sa ERR+originalni TransactionId
2.9 ContractId Broj ugovora po kome je izdat mandat
2.11 SequenceType Vrednosti: RECR, ONEO
RECR – mandat s više dospeća
ONEO – mandat sa jednim dospećem
2.22 MandateId Jedinstveni identifikator mandata koji se povlači.
Pri povlačenju mandata mora biti identifikator osnovnog mandata
(ne aneksa) koji postoji u Registru mandata, i poslednji aneks (ili
osnovni mandata) mora biti aktivan (status ACTV)
2.43 Creditor.CreditorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Poveriocu pravnom licu
JMBG, dužine 13 – ukoliko se radi o Poveriocu fizičkom licu koje
obavlja delatnost
Kontrola dužine.
2.43 Creditor. CountryCode Iz šifarnika država
2.44 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke poverioca
(CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.45 CreditorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.57 Debtor.DebtorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku pravnom licu
JMBG, dužine 13 – ukoliko se radi o Dužniku fizičkom licu koje
obavlja delatnost
Kontrola dužine .
2.57 Debtor. CountryCode Iz šifarnika država
2.58 DebtorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 388
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.59 DebtorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.60 MandateStatus Vrednosti: REMO, za povlačenje mandata
2.105 AdditionalReasonInformation Tekstualni opis razloga povlačenja mandata
PORUKA mndt.003.001.01 REJECT MANDATE
Struktura: SerbianMandateReject
• Koristi se za odbijanje instrukcija za evidentiranje, izmenu i povlačenje Mandata, pri čemu element
OriginalMessageName ima vrednost tipa instrukcije koja se odbija (mndt.001.001.01 ili
mndt.002.001.01)
• Generišu je i ispostavljaju banke koje koriste dodatni servis vođenja Registra mandata, odnosno
Procesor na osnovu izvršenih kontrola.
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader2 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.7 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.7 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.7 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca
poruke
1.8 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.8 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
primaoca poruke
1.8 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation TransactionInformation Telo poruke
instrukcije
odbijanja(Reject)
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije
podnosioca
instrukcije
2.2 M 1 + + OriginalTransactionInformati
on
OriginalTransactionInfo
rmation
Identifikacija
originalne poruke
2.3 M 1 + + + OriginalMessageId Max35Text Jedinstveni
identifikator
originalne poruke
2.4 M 1 + + + OriginalMessageName Max35Text Naziv originalne
poruke
(mndt.xxx.xxx.xx).
2.6 M 1 + + OriginalTransactionId Max35Text Id originalne
instrukcije
2.7 M 1 + + TransactionStatus TransactionIndividual
Status2Code
Vrednost: RJCT
2.8 M 1 + + MandateInformation MandateInformation3 Informacije o
mandatu
2.9 O 0-1 + + + ContractId Max35Text Broj ugovora po kome
je izdat
2.10 M 1 + + + MandateType MandateType
Information8
Tip mandata
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 389
2.11 M 1 + + + + SequenceType SequenceType1Code Vrednosti: RECR,
ONEO
2.22 M 1 + + + MandateId Max35Text Identifikacija mandata
2.23 M 1 + + + DateSignature ISODate Datum potpisivanja
mandata
2.24 M 1 + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
(izmena mandata)
2.25 O 0-1 + + + AmendmentInformation AmendmentInformation
Details4
Informacije o
osnovnom mandatu
2.26 O 0-1 + + + + OrgMandateId Max35Text Identifikator
osnovnog mandata
2.43 M 1 + + Creditor PartyIdentification13 Poverilac
2.43 M 1 + + + CreditorId Max35Text Id poverioca, matični
broj ili Jmbg
2.43 M 1 + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-2 + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + CreditorAccount CashAccount8 Broj računa
poverioca
2.44 M 1 + + + AccountId AccountIdentification2 Identifikacija računa
poverioca
2.44 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca
2.43 M 1 + + + + BICAgent BICIdentifier BIC banke poverioca
2.57 M 1 + + Debtor PartyIdentification19 Dužnika
2.57 M 1 + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.57 M 1 + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
dužnika
2.57 O 0-2 + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + AccountId AccountIdentification2 Identifikacija računa
dužnika
2.58 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika
2.59 M 1 + + + + BICAgent BICIdentifier BIC banke dužnika
2.70 M 1 + + StatusReasonInformation StatusReason
Information4
Informacije o
razlozima odbijanja
instrukcije
2.71 M 1 + + + StatusOriginator PartyIdentification14 Identifikacija
inicijatora odbijanja
instrukcije- banka,
ugovorna strana
2.72 M 1 + + + + OriginatorId FinancialInstitution3 Identifikacija banke
inicijatora odbijanja
instrukcije
2.72 M 1 + + + + + Originator FinancialInstitution
Identification4
Identifikacija banke
inicijatora odbijanja
instrukcije
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 390
2.72 M 1 + + + + + + BICOriginator BICIdentifier BIC banke,
inicijatora odbijanja
instrukcije
2.73 M 1 + + + + OriginatorName Max35Text Naziv ugovorne strane
koja odbija instrukciju
2.90 M 1 + + + StatusReason ReturnReason3Choice Kodirani razlog
odbijanja instrukcije
2.91 M 1 + + + + StatusCode TransactionReturn
Reason5Code
Kod razloga odbijanja
instrukcije
2.105 O 0-1
+ + + AdditionalReasonInformat
ion
Max105Text Dodatno obrazloženje
za odbijanje
instrukcije.
Specifikacija ISO kodova za Reject transakcije:
ISO
kod
Opis ISO
kod
Opis
AC01 Pogrešan broj računa BE07 Pogrešna adresa dužnika
AC04 Račun zatvoren DT01 Pogrešan datum
AC06 Račun blokiran ED01 Ne postoji korespodentna banka
AG01 Transakcija
zabranjena
ED03 Traženo stanje
AG02 Pogrešan kod banke MD01 Nema validnog mandata
AM01 Nula iznos MD02 Pogrešne informacije o mandatu
AM02 Nedopušten račun MD03 Pogrešan format podatka o razlozima
AM03 Pogrešna valuta MD04 Pogrešan format podataka za indikatore
AM04 Nedovoljno sredstava MD06 Dužnik je podneo Refunda zahtev
AM05 Dupliran nalog MD07 Dužnik je umro
AM06 Premali iznos MS02 Nije naveden razlog od strane dužnika
AM07 Blokiran iznos MS03 Nije naveden razlog od strane banke
AM09 Pogrešan iznos NARR Opisno
AM10 Pogrešna kontrolna
suma
RC01 Pogrešan identifikator banke
BE01 Nesaglasan krajnji
korisnik
RF01 Referenca transakcije nije jedinstvena
BE04 Pogrešna adresa
poverioca
TM01 Cutt off time (istek vremena)
BE05 Neprepoznat
poverilac
ED05 Greška u obračunu
BE06 Neprepoznat dužnik RR01 Razlozi regulatora (procesora)
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca. U slučaju
standardizacije identifikatora u domaćem platnom prometu,
kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od tekućeg datume
1.7 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.8 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.1 TransactionId Predstavlja ID Reject instrukcije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 391
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
2.3 OriginalMessageId Jedinstveni identifikator originalne poruke
2.4 OriginalMessageName Naziv originalne poruke:
Vrednosti: mndt.001.001.01 i mndt.002.001.01
2.6 OriginalTransactionId TransactionId iz originalne instrukcije koja se odbija.
Kontrola postojanja instrukcije u evidenciji procesora za
navedeni OriginalMessageName, OriginalMessageId i
OriginalTransactionId
2.7 TransactionStatus Vrednost: RJCT
2.9 ContractId Broj ugovora po kome je izdat mandat
Kontrola vrednosti koja mora biti jednaka u originalnoj
instrukciji koja se odbija
2.11 SequenceType Vrednosti: RECR, ONEO
RECR – mandat s više dospeća
ONEO – mandat sa jednim dospećem
2.22 MandateId Jedinstveni identifikator mandata ili amandmana na koji se odnosi
instrukcija koja se odbija.
Kontrola vrednosti koja mora biti jednaka u originalnoj instrukciji
koja se odbija.
2.43 Creditor.CreditorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Poveriocu pravnom
licu
JMBG, dužine 13 – ukoliko se radi o Poveriocu fizičkom licu
koje obavlja delatnost
Kontrola dužine.
2.43 Creditor. CountryCode Iz šifarnika država
2.44 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke poverioca
(CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.45 CreditorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.57 Debtor.DebtorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku pravnom licu
JMBG, dužine 13 – ukoliko se radi o Dužniku fizičkom licu koje
obavlja delatnost
Kontrola dužine .
2.57 Debtor. CountryCode Iz šifarnika država
2.58 DebtorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.59 DebtorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.72 StatusOriginator. Inicijatori odbijanja mogu biti Banka Poverioca, Banka Dužnika
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 392
BICOriginator ili Procesor, koji se identifikuju BIC-om i koji mora biti u
evidenciji aktivnih učesnika kliringa za direktna zaduženja.
(Inicijatori mogu biti i Dužnik ili Poverilac, koji se identifikuju
svojim nazivom, ali se ne vrši kontrola od strane Procesora)
2.91 StatusReason. StatusCode Kontrola koda razloga odbijanja u šifarniku kodova odbijanja
2.105 AdditionalReasonInformation Ukoliko šifrirani kod razloga odbijanja ne objašnjava dovoljno
razloge odbijanja, može se zadati i njegov tekstualni opis.
PORUKA mndt.004.001.01 ACCEPT MANDATE
Struktura: SerbianMandateAccept
• Koristi se za eksplicitno prihvatanje instrukcija za evidentiranje, izmenu i povlačenje Mandata
• Element OriginalMessageName ima vrednost tipa instrukcije koja se prihvata (mndt.001.001.01 ili
mndt.002.001.01)
• Generišu je i ispostavljaju banke koje koriste dodatni servis vođenja Registra mandata, odnosno
Procesor na osnovu izvršenih kontrola.
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader2 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.7 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.7 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.7 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.8 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.8 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.8 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation Transaction
Information
Telo poruke
instrukcije
prihvatanja (Accept)
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije podnosioca
instrukcije
2.2 M 1 + + OriginalTransactionInformation OriginalTransaction
Information
Identifikacija originalne
poruke
2.3 M 1 + + + OriginalMessageId Max35Text Jedinstveni identifikator
originalne poruke
2.4 M 1 + + + OriginalMessageName Max35Text Naziv originalne poruke
(mndt.xxx.xxx.xx).
2.6 M 1 + + OriginalTransactionId Max35Text Id originalne instrukcije
2.7 M 1 + + TransactionStatus TransactionIndividual
Status2Code
Vrednost: ACPT
2.8 M 1 + + MandateInformation Mandate
Information3
Informacije o mandatu
2.9 O 0-1 + + + ContractId Max35Text Broj ugovora po kome je
izdat mandat
2.10 M 1 + + + MandateType MandateType
Information8
Tip mandata
2.11 M 1 + + + + SequenceType SequenceType1Code Vrednosti: RECR,
ONEO
2.22 M 1 + + + MandateId Max35Text Identifikacija mandata
2.23 M 1 + + + DateSignature ISODate Datum potpisivanja
mandata
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 393
2.24 M 1 + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
(izmena mandata)
2.25 O 0-1 + + + AmendmentInformation Amendment
InformationDetails4
Informacije o osnovnom
mandatu
2.26 O 0-1 + + + + OrgMandateId Max35Text Identifikator osnovnog
mandata
2.43 M 1 + + Creditor Party
Identification13
Poverilac
2.43 M 1 + + + CreditorId Max35Text Id poverioca, matični
broj ili Jmbg
2.43 M 1 + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-2 + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + CreditorAccount CashAccount8 Broj računa poverioca
2.44 M 1 + + + AccountId Account
Identification2
Identifikacija računa
poverioca
2.44 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca
2.43 M 1 + + + + BICAgent BICIdentifier BIC banke poverioca
2.57 M 1 + + Debtor Party
Identification19
Dužnika
2.57 M 1 + + + DebtorId Max35Text Id dužnika, matični broj
ili Jmbg
2.57 M 1 + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
dužnika
2.57 O 0-2 + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + AccountId Account
Identification2
Identifikacija računa
dužnika
2.58 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika
2.59 M 1 + + + + BICAgent BICIdentifier BIC banke dužnika
2.70 M 1 + + StatusReasonInformation StatusReasonInfor
mation4
Informacije o
razlozima prihvatanja
2.71 M 1 + + + StatusOriginator Party
Identification14
Identifikacija inicijatora
prihvatanja instrukcije
(banke i ugovorne strane)
2.72 M 1 + + + + OriginatorId FinancialInstitution3 Identifikacija banke
inicijatora prihvatanja
instrukcije
2.72 M 1 + + + + + Originator FinancialInstitution
Identification4
Identifikacija banke
inicijatora prihvatanja
instrukcije
2.72 M 1 + + + + + + BICOriginator BICIdentifier BIC banke, inicijatora
prihvatanja instrukcije
2.73 M 1 + + + + OriginatorName Max35Text Naziv ugovorne strane
koja prihvata instrukciju
2.105 O 0-1
+ + + AdditionalReasonInformati
on
Max105Text Dodatno obrazloženje
za prihvanje instrukcije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 394
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od tekućeg datume
1.7 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.8 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.1 TransactionId Predstavlja ID Reject instrukcije.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
2.3 OriginalMessageId Jedinstveni identifikator originalne poruke
2.4 OriginalMessageName Naziv originalne poruke:
Vrednosti: mndt.001.001.01 i mndt.002.001.01
2.6 OriginalTransactionId TransactionId iz originalne instrukcije koja se prihvata.
Kontrola postojanja instrukcije u evidenciji procesora za
navedeni OriginalMessageName, OriginalMessageId i
OriginalTransactionId
2.7 TransactionStatus Vrednost: ACPT
2.9 ContractId Broj ugovora po kome je izdat mandat
Kontrola vrednosti koja mora biti jednaka u originalnoj
instrukciji koja se prihvata
2.11 SequenceType Vrednosti: RECR, ONEO
RECR – mandat s više dospeća
ONEO – mandat sa jednim dospećem
2.22 MandateId Jedinstveni identifikator mandata na koji se odnosi instrukcija
koja se prihvata.
Kontrola vrednosti koja mora biti jednaka u originalnoj instrukciji
koja se prihvata
2.43 Creditor.CreditorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Poveriocu pravnom
licu
JMBG, dužine 13 – ukoliko se radi o Poveriocu fizičkom licu
koje obavlja delatnost
Kontrola dužine.
2.43 Creditor. CountryCode Iz šifarnika država
2.44 CreditorAccount.
IBANAccount
Struktura broja računa u domaćem platnom prometu:
DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke poverioca
(CreditorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.45 CreditorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.57 Debtor.DebtorId Struktura identifikatora u domaćem platnom prometu:
Matični broj, dužine 8 – ukoliko se radi o Dužniku pravnom licu
JMBG, dužine 13 – ukoliko se radi o Dužniku fizičkom licu koje
obavlja delatnost
Kontrola dužine .
2.57 Debtor. CountryCode Iz šifarnika država
2.58 DebtorAccount. Struktura broja računa u domaćem platnom prometu:
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 395
IBANAccount DDKKBBBnnnnnnnnnnnnnKB
Gde je:
DD – oznaka države (fiksna vrednost RS za Srbiju)
KK – kontrolni broj po modelu 97 za ceo IBAN račun (fiksna
vrednost 35 za Srbiju)
BBB – šifra banke koja odgovara BIC-u banke dužnika
(DebtorAgent)
nnnnnnnnnnnnn - broj računa
KB – kontrolni broj za broj računa bez oznake države (DD) i
kontrolnog broja (KK)
2.59 DebtorAgent.BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.72 StatusOriginator.
BICOriginator
Inicijatori prihvtanja mogu biti Banka Poverioca, Banka Dužnika
ili Procesor, koji se identifikuju BIC-om i koji mora biti u
evidenciji aktivnih učesnika kliringa za direktna zaduženja.
(Inicijatori mogu biti i Dužnik ili Poverilac, koji se identifikuju
svojim nazivom, ali se ne vrši kontrola od strane Procesora)
2.105 AdditionalReasonInformation Može se zadati tekstualni opis razloga prihvatnja (bez kontrole
Procesora)
PORUKA mndt.005.001.01REQUEST&CANCELLATION
Struktura: SerbianCancel
• Koristi se za povlačenje instrukcija za evidentiranje, izmenu i povlačenje Mandata (pojedinačno ili
celih poruka).
• Element OriginalMessageName ima vrednost tipa instrukcije koja se povlači (mndt.001.001.01 ili
mndt.002.001.01)
• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata, pre
realizacije instrukcije koja se povlači.
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation Transaction
Information
Telo poruke za
povlačenje poruke ili
pojedinačne instrukcije
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id transakcije
podnosioca instrukcije
2.2 M 1 + + OriginalTransactionInformation OriginalTransaction
Information
Identifikacija originalne
poruke
2.3 M 1 + + + OriginalMessageId Max35Text Jedinstveni identifikator
originalne poruke
2.4 M 1 + + + OriginalMessageName Max35Text Naziv originalne poruke.
2.5 O 0-1 + + + OriginalCreationDate ISODateTime Datum kreiranja
originalne poruke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 396
2.6 O 0-n + + OriginalTransactionId Max35Text Id transakcije banke
podnosioca instrukcije iz
originalne instrukcije
2.7 M 1 + + TransactionStatus TrnsactionIndividual
Status2Code
Vrednost: CNCL
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Manji ili jednak od tekućeg datume
1.3 InstructingAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
1.4 InstructedAgent. BICAgent Mora biti u evidenciji aktivnih učesnika kliringa za direktna
zaduženja
2.1 TransactionId Predstavlja ID Reques&Cancellation instrukcije koji generiše
banka koja je uputila originalnu instrukciju
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
2.3 OriginalMessageId MessageId iz Header-a poruke u kojoj se nalazila originalna
instrukcija.
Predstavljajedinstveni identifikator poruke u kojoj se nalazi
originalna instrukcije
Kontrola postojanja poruke u evidenciji procesora
2.4 OriginalMessageName Može biti:
mndt.001.001.01, za povlačenje instrukcije Mandate
mndt.002.001.01, za povlačenje instrukcije Remove Mandate
2.5 OriginalCreationDate CreationDate iz Header-a poruke u kojoj se nalazila originalna
instrukcija
2.6 OriginalTransactionId TransactionID iz originalne instrukcije koja se povlači
Kontrola postojanja instrukcije u evidenciji procesora
2.7 TransactionStatus Vrednost: CNCL
PORUKA mndt.006.001.01 MANDATE QUERY
Struktura: SerbianMandateQuery
• Koristi se za ispostavljanje zahteva za dobijanjem informacija o mandatu evidentiranih u Registru
mandata.
• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata.
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation Transaction
Information
Telo poruke za upit u
Registar mandata
2.1 M 1 + + TransactionId Max35Text Jedinstveni identifikator
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 397
upita
2.2 O 0-n + + Mandate MandateIdentification Identifikacija mandata ili
aneksa
Upit za dati mandat ili
aneks
2.2 O 0-1 + + + MandateId Max35Text Identifikacija mandata ili
aneksa
2.2 O 0-1 + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
2.3 O 0-1 + + MandateStatus MandateIndividual
Status2Code
Status mandata
Upit po statusu mandata
2.4 O 0-n + + Creditor PartyIdentification13 Poverilac
Upit po poveriocu
2.4 O 0-1 + + + CreditorId Max35Text Id dužnika, matični broj ili
Jmbg
2.4 O 0-1 + + + Name Max70Text Ime poverioca
2.5 O 0-n + + CreditorAccount CashAccount8 Broj računa poverioca
Upit po broju računa
poverioca
2.5 O 0-1 + + + AccountId AccountIdentification2 Identifikacija računa
poverioca
2.5 O 0-1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.6 O 0-n + + CreditorAgent FinancialInstitution3 Banka poverioca
Upit po banci poverioca
2.6 O 0-1 + + + AgentId FinancialInstitution
Identification5
Identifikacija banke
poverioca
2.6 O 0-1 + + + + BICAgent BIC Identifier BIC banke poverioca
2. 7 O 0-n + + Debtor PartyIdentification19 Dužnika
Upit po dužniku
2.7 O 0-1 + + + DebtorId Max35Text Id dužnika, matični broj ili
Jmbg
2.7 O 0-1 + + + Name Max70Text Ime dužnika
2.8 O 0-n + + DebtorAccount CashAccount8 Broj računa dužnika
Upit po računu dužnika
2.8 O 0-1 + + + AccountId AccountIdentification2 Identifikacija računa
dužnika
2.8 O 0-1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.9 O 0-n + + DebtorAgent FinancialInstitution3 Banka dužnika
Upit po banci dužnika
2.9 O 0-1 + + + AgentId FinancialInstitution
Identification5
Identifikacija banke
dužnika
2.9 O 0-1 + + + + BICAgent BIC Identifier BIC banke dužnika
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca
1.2 CreationDate Jednak tekućem datumu
1.3 InstructingAgent. BICAgent Mora biti u evidenciji učesnika kliringa za direktna zaduženja
1.4 InstructedAgent. BICAgent BIC Procesora
2.1 TransactionId Predstavlja ID upita koji generiše banka koja je uputila upit
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
2.4 CreditorId Id poverioca, matični broj ili Jmbg
Mora postojati ili identifikacija poverioca ili identifikacija
dužnika (2.7)
2.7 DebtorId Id dužnika, matični broj ili Jmbg
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 398
Mora postojati ili identifikacija dužnika ili identifikacija
poverioca (2.4)
Napomena: Nije potrebno vršiti dodatne kontrole sadržaja poruke, s obzirom da će rezultat upita (odgovor
procesora) biti u skladu sa „kvalitetom“ podataka u upitu
PORUKA mndt.007.001.01 MANDATE RESPONSE
Struktura: SerbianMandateResponse
• Koristi se za davanje odgovora na podneti zahtev za dobijanjem informacija o mandatu evidentiranih
u Registru mandata.
• Generišu ih i ispostavljaju Procesoru, banke koje koriste dodatni servis vođenja Registra mandata i
koje su podnele zahtev za dobijanjem informacija o mandatu .
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca
poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
primaoca poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca
poruke
2.0 M 1 + TransactionInformation Transaction
Information
Odgovor na
postavljeni upit
2.1 M 1 + + TransactionId Max35Text Jedinstveni
identifikator odgovora
na upit
2.2 M 1 + + OriginalTransactionId Max35Text Id transakcije
podnosioca upita iz
originalne instrukcije
2.3 O 0-n + + QueryResponse QueryAndResponse Odgovor na upit
2.4 M 1 + + + MandateStatus MandateIndividual
Status2Code
Status mandata iz
internog šifarnika
Procesora
2.5 M 1 + + + MandateInformation Mandate
Information3
Informacije o
mandatu
2.6 O 0-1 + + + + ContractId Max35Text Broj ugovora po
kome je izdat mandat
2.10 M 1 + + + + MandateType MandateType
Information8
Tip mandata
2.11 M 1 + + + + + SequenceType SequenceType1Code Vrednosti: RECR,
ONEO
2.22 M 1 + + + + MandatId Max35Text Identifikacija mandata
ili aneksa
2.23 M 1 + + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa
2.24 M 1 + + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
(izmena mandata)
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 399
2.25 O 0-1 + + + + AmendmentInformation Amendment
InformationDetails4
Informacije o
osnovnom mandatu
2.26 O 0-1 + + + + + OrgMandateId Max35Text Identifikator
osnovnog mandata
2.43 M 1 + + + Creditor Party
Identification13
Poverilac
2.43 M 1 + + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.43 M 1 + + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-2 + + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + + CreditorAccount CashAccount8 Broj računa
poverioca
2.44 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
poverioca
2.44 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca
2.43 M 1 + + + + + BICAgent BIC Identifier BIC banke poverioca
2.57 M 1 + + + Debtor Party
Identification19
Dužnika
2.57 M 1 + + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.57 M 1 + + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
dužnika
2.57 O 0-2 + + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
dužnika
2.58 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika
2.59 M 1 + + + + + BICAgent BIC Identifier BIC banke dužnika
2.81 O 0-1 + + + RemmitanceInformation Remittance
Information3
Informacije o
plaćanju
2.82 O 0-n + + + + UnstructuredRemmitance Max140Text Nestruktuirane
informacije o plaćanju
2.83 M 1 + + + + StructuredRemmitance StructuredRemittance
Information6
Struktuirane
informacije o plaćanju
2.84 M 1 + + + + + FirstCollectionDate ISODate Datum kada može da
bude realizovana
prvo zaduženje
2.84 O 0-1 + + + + + FinalCollectionDate ISODate Datum do koga
može da bude
izvršavana poslednje
zaduženje (Datum
isteka Mandata)
2.85 M 1 + + + + + Revocation Revocation
Identification1
Opozivost Mandata
2.85 M 1 + + + + + + RevocationIndicator TrueFalseIndicator Indikator opozivosti
Mandata
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 400
2.85 O 0-1 + + + + + + Conditional Max140Text Uslovi opoziva
Mandata
2.86 M 1 + + + + + NumberOfCollection Max15NumericText Maksimalni broj
obaveza po mandatu
2.87 M 1 + + + + + TotalAmount EuroMax9Amount Ukupan iznos
zaduženja po mandatu
2.87 M 1 + + + + + + Amount Decimal, 9,2 Ukupan iznos
plaćanja.
2.87 M 1 + + + + + + CurrencyCode EuroCurrencyCode Kod valute
2.88 O 0-1 + + + + + Frequency Metric FrequencyMetric Metrika dospeća
2.88 M 1 + + + + + + Frequency Code FrequencyCode Kodirana metrika
dospeća:
DAIL, za dan,
MNTH, za mesec
YEAR, za godinu
2.88 M 1 + + + + + + Periodic Max15NumericText Periodika dospeća u
datoj metrici
2.89 O 0-n + + + + + FixedReqDate ISODate Fiksni datumi
dospeća (DueDate)
2.90 O 0-1 + + + + + Tolerancy Tolerancy Period tolerancije
dospeća u danima
2.91 M 1 + + + + + + TolerancySign TolerancySign Kodirani znak
perioda tolerancije:
PLS, po dospeću
(PLUS)
MNS, pre dospeća
(MINUS)
BTH, pre i posle
dospeća (BOTH)
2.91 M 1 + + + + + + TolerancyValue Max15NumericText Broj dana tolerancije
u dospeću
2.92 O 0-1 + + + + + DebitAmount EuroMax9Amount Maksimalni iznos u
jednom nalogu
zaduženja (collection)
2.92 M 1 + + + + + + Amount Decimal, 9,2 Iznos plaćanja.
2.92 M 1 + + + + + + CurrencyCode EuroCurrencyCode Kod valute
2.93 O 0-1 + + + + + Exchange Exchange Valutni uslovi
plaćanja
2.93 M 1 + + + + + + CurrencyCode CurrencyCode Kod valute plaćanja
2.93 M 1 + + + + + + ExchangeRate BaseOnRate Kurs ugovorene
valute:
SEL – prodajni kurs
MID – srednji kurs
BUY – kupovni kurs
2.93 M 1 + + + + + + Exchange list BaseOnList Vrednosti :
NBS – za kursnu listu
Narodne banke
BANK – za kursnu
listu banke (nije
osnov za kontrolu
Procesora)
2.97 O 0-1 + + + + + CreditorReference CreditorReferenc
Information1
Identifikator dužnika
2.97 O 0-1 + + + + + + ReferenceType CreditorReference
Type1
Referenca
2.97 O 0-1 + + + + + + + Purport Max35Text Poziv na broj
dužnika
2.105 O 0-1 + + + + + AdditionalRemmitance Max140Text Dodatne informacije o
plaćanju
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 401
POSLOVNA PRAVILA
Index Element poruke Poslovna pravila
1.1 MessageId U sistemu je jedinstven na nivou pošiljaoca.
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
1.2 CreationDate Jednak tekućem datumu
1.3 InstructingAgent.BICAgent BIC Procesora
1.4 InstructedAgent. BICAgent Mora biti u evidenciji učesnika kliringa za direktna zaduženja
2.1 TransactionId Predstavlja ID upita koji generiše banka koja je uputila upit
U slučaju standardizacije identifikatora u domaćem platnom
prometu, kontrolu vršiti prema usvojenom standardu
Napomena: Nije potrebno vršiti dodatne kontrole sadržaja poruke, s obzirom da će rezultat upita (odgovor
procesora) biti u skladu sa „kvalitetom“ podataka u upitu
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 402
Prilog 6.
TEHNIČKO UPUTSTVO
ZA REALIZACIJU DODATNIH SERVISA DIREKTNOG ZADUŽENJA
Jun, 2008. godine
PORUKA mndt.001.001.01 MANDATE
Struktura: SerbianMandateEvidence
• Koristi se za evidentiranje i izmenu sadržaja Mandata. Generišu je i ispostavljaju Procesoru banke
koje koriste dodatni servis vođenja Registra mandata
• Ukoliko se koristi kao instrukcija za evidendtiranje Mandata, element AmendmentIndicator ima
vrednost FALSE
• Ukoliko se koristi kao instrukcija za izmenu sadržaja Mandata, element AmendmentIndicator ima
vrednost TRUE, a element OrgMandateId vrednost identifikatora osnovnog mandata
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader1 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke.
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke.
1.26 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.26 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.26 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.27 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.27 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
primaoca poruke
1.27 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation Transaction
Information3
Telo poruke za
evidentiranje
Mandata
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije
podnosioca
instrukcije.
2.2 M 1 + + MandatInformation MandateInformation3 Informacije o
mandatu
2.3 O 0-1 + + + ContractId Max35Text Broj ugovora po kome
je izdat mandat
2.10 M 1 + + + MandateType MandateType
Information8
Tip mandata
2.11 M 1 + + + + SequenceType SequenceType1Code Vrednosti: RECR,
ONEO
2.22 M 1 + + + MandatId Max35Text Identifikacija mandata
ili aneksa
2.23 M 1 + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa
2.24 M 1 + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
(izmena mandata)
2.25 O 0-1 + + + AmendmentInformation Amendment
InformationDetails4
Informacije o
osnovnom mandatu
2.26 O 0-1 + + + + OrgMandateId Max35Text Identifikator
osnovnog mandata
2.43 M 1 + + Creditor PartyIdentification13 Poverilac
2.43 M 1 + + + CreditorId Max35Text Id poverioca, matični
broj ili Jmbg
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 403
2.43 M 1 + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-5 + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + CreditorAccount CashAccount8 Broj računa poverioca
2.44 M 1 + + + AccountId Account
Identification2
Identifikacija računa
poverioca
2.44 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca
2.43 M 1 + + + + BICAgent BICIdentifier BIC banke poverioca
2.57 M 1 + + Debtor PartyIdentification19 Dužnika
2.57 M 1 + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.57 M 1 + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + PostAddress PostalAddress4 Poštanska adresa
dužnika
2.57 O 0-5 + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + AccountId Account
Identification2
Identifikacija računa
dužnika
2.58 M 1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika
2.59 M 1 + + + + BICAgent BICIdentifier BIC banke dužnika
2.81 O 0-1 + + RemmitanceInformation Remittance
Information3
Informacije o
plaćanju
2.82 O 0-n + + + UnstructuredRemmitance Max140Text Nestruktuirane
informacije o plaćanju
2.83 M 1 + + + StructuredRemmitance StructuredRemittance
Information6
Struktuirane
informacije o plaćanju
2.84 M 1 + + + + FirstCollectionDate ISODate Datum kada može da
bude realizovana prvo
zaduženje
2.85 O 0-1 + + + + FinalCollectionDate ISODate Datum do koga može
da bude izvršavana
poslednje zaduženje
2.86 M 1 + + + + NumberOfCollection Max15NumericText Maksimalni broj
obaveza po mandatu
2.87 M 1 + + + + TotalAmount EuroMax9Amount Ukupan iznos
zaduženja po mandatu.
2.87 M 1 + + + + + Amount Decimal, 9,2 Ukupan iznos
plaćanja.
2.87 M 1 + + + + + CurrencyCode EuroCurrencyCode Kod valute
2.88 O 0-1 + + + + Frequency Metric FrequencyMetric Metrika dospeća
2.88 M 1 + + + + + Frequency Code FrequencyCode Kodirana metrika
dospeća:
DAIL, za dan,
MNTH, za mesec
YEAR, za godinu
2.88 M 1 + + + + + Periodic Max15NumericText Periodika dospeća u
datoj metrici
2.89 O 0-n + + + + FixedReqDate ISODate Fiksni datumi dospeća
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 404
(DueDate)
2.90 O 0-1 + + + + Tolerancy Tolerancy Period tolerancije
dospeća u danima
2.90 M 1 + + + + + TolerancySign TolerancySign Kodirani znak perioda
tolerancije:
PLS, po dospeću
(PLUS)
MNS, pre dospeća
(MINUS)
BTH, pre i posle
dospeća (BOTH)
2.90 M 1 + + + + + TolerancyValue Max15NumericText Broj dana tolerancije u
dospeću
2.91 O 0-1 + + + + DebitAmount EuroMax9Amount Maksimalni iznos u
jednom nalogu
zaduženja (collection)
2.91 M 1 + + + + + Amount Decimal, 9,2 Iznos plaćanja.
2.91 M 1 + + + + + CurrencyCode EuroCurrencyCode Kod valute
2.92 O 0-1 + + + + Exchange Exchange Valutni uslovi plaćanja
2.92 M 1 + + + + + CurrencyCode CurrencyCode Kod valute plaćanja
2.92 M 1 + + + + + ExchangeRate BaseOnRate Kurs ugovorene valute:
SEL – prodajni kurs
MID – srednji kurs
BUY – kupovni kurs
2.92 M 1 + + + + + Exchange list BaseOnList Vrednosti :
NBS – za kursnu listu
Narodne banke
BANK – za kursnu
listu banke (nije osnov
za kontrolu Procesora)
2.97 O 0-1 + + + + CreditorReference CreditorReference
Information1
Referisanje poverioca
na Identifikator
dužnika
2.97 O 0-1 + + + + + ReferenceType CreditorReference
Type1
Referenca
2.97 O 0-1 + + + + + + Purport Max35Text Poziv na broj dužnika
2.105 O 0-1 + + + + AdditionalRemmitance Max140Text Dodatne informacije o
plaćanju
PORUKA mndt.002.001.01 STATUS MANDATE
Struktura: SerbianMandateStatus
• Koristi se za povlačenje Mandata i potvrdu aktivnog statusa Mandata. Generišu je i ispostavljaju
Procesoru banke koje koriste dodatni servis vođenja Registra mandata
• Ukoliko se koristi kao instrukcija za povlačenje Mandata, element MandateStatus ima vrednost
CANCEL
• Ukoliko se koristi kao instrukcija za prihvatanje evidetiranja, odnosno izmene Mandata, element
MandateStatus ima vrednost LIVE
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader1 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke.
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke.
1.26 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 405
1.26 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.26 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.27 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.27 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
primaoca poruke
1.27 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation Transaction
Information3
Telo poruke za
evidentiranje
Mandata
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije
podnosioca
instrukcije.
2.2 M 1 + + MandatInformation Mandate
Information3
Informacije o
mandatu
2.3 O 0-1 + + + ContractId Max35Text Broj ugovora po kome
je izdat mandat
2.10 M 1 + + + MandateType MandateType
Information8
Tip mandata
2.11 M 1 + + + + SequenceType SequenceType1Code Vrednosti: RECR,
ONEO
2.22 M 1 + + + MandatId Max35Text Identifikacija mandata
ili aneksa
2.23 M 1 + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa
2.24 M 1 + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
(izmena mandata)
2.25 O 0-1 + + + AmendmentInformation Amendment
InformationDetails4
Informacije o
osnovnom mandatu
2.26 O 0-1 + + + + OrgMandateId Max35Text Identifikator
osnovnog mandata
2.43 M 1 + + Creditor Party
Identification13
Poverilac
2.43 M 1 + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.57 M 1 + + Debtor Party
Identification19
Dužnika
2.57 M 1 + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.60 M 1 + + MandateStatus MandateIndividual
Status2Code
Vrednosti:
CANCEL, za
povlačenje mandata
LIVE, za potvrdu
prihvatanja mandata i
izmene mandata
2.92 O 0-1
+ + AdditionalReasonInformation Max105Text Dodatno obrazloženje
za promenu statusa
mandata
PORUKA mndt.003.001.01 REJECT MANDATE
Struktura: SerbianMandateReject
• Koristi se za odbijanje instrukcija za evidentiranje, izmenu i povlačenje Mandata, pri čemu element
OriginalMessageName ima vrednost tipa instrukcije koja se odbija (mndt.001.001.01 ili
mndt.002.001.01)
• Generišu je i ispostavljaju banke koje koriste dodatni servis vođenja Registra mandata, odnosno
Procesor na osnovu izvršenih kontrola.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 406
Index Kardinalnost Element poruke Tip
Opis i poslovna
pravila
1.0 M 1 + Header GroupHeader2 Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.7 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.7 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.7 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.8 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.8 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.8 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
3.0 M 1-n + TransactionInformation Transaction
Information
Telo poruke
instrukcije odbijanja
(Reject)
3.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije podnosioca
instrukcije
3.2 M 1 + + OriginalTransactionInformation OrginalTtansaction
Information
Identifikacija originalne
poruke
3.3 M 1 + + + OriginalMessageId Max35Text Jedinstveni
identifikator originalne
poruke
3.4 M 1 + + + OriginalMessageName Max35Text Naziv originalne
poruke
(mndt.xxx.xxx.xx).
3.5 M 1 + + OriginalTransactionId Max35Text Id originalne instrukcije
3.6 M 1 + + TransactionStatus TrnsactonIndividual
Status2Code
Vrednost: RJCT
3.7 M 1 + + StatusReasonInformation StatusReason
Information4
Informacije o
razlozima odbijanja
3.8 M 1 + + + StatusOriginator Party
Identification14
Identifikacija inicijatora
odbijanja instrukcije
(banke ili ugovorne
strane)
3.8 M 1 + + + + OriginatorId Financial
Institution3
Identifikacija
inicijatora odbijanja
instrukcije (banke)
3.8 M 1 + + + + + Originator FinancialInstitution
Identification4
Identifikacija
inicijatora odbijanja
instrukcije (banke)
3.8 M 1 + + + + + + BICOriginator BICIdentifier BIC banke, inicijatora
odbijanja instrukcije
3.8 M 1 + + + + OriginatorName Max35Text Naziv inicijatora
odbijanje instrukcije
3.9 M 1 + + + StatusReason ReturnReason3
Choice
Kodirani razlog za
odbijanje instrukcije
3.10 M 1 + + + + StatusCode TransactionReturn
Reason5Code
Kod razloga za odbijanje
instrukcije
3.12 O 0-1
+ + + AdditionalReasonInformation Max105Text Dodatno obrazloženje
za odbijanje
instrukcije.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 407
Specifikacija ISO kodova za Reject transakcije:
ISO kod Opis ISO kod Opis
AC01 Pogrešan broj računa BE07 Pogrešna adresa dužnika
AC04 Račun zatvoren DT01 Pogrešan datum
AC06 Račun blokiran ED01 Ne postoji korespodentna banka
AG01 Transakcija zabranjena ED03 Traženo stanje
AG02 Pogrešan kod banke MD01 Nema validnog mandata
AM01 Nula iznos MD02 Pogrešne informacije o mandatu
AM02 Nedopušten račun MD03 Pogrešan format podatka o razlozima
AM03 Pogrešna valuta MD04 Pogrešan format podataka za indikatore
AM04 Nedovoljno sredstava MD06 Dužnik je podneo Refunda zahtev
AM05 Dupliran nalog MD07 Dužnik je umro
AM06 Premali iznos MS02 Nije naveden razlog od strane dužnika
AM07 Blokiran iznos MS03 Nije naveden razlog od strane banke
AM09 Pogrešan iznos NARR Opisno
AM10 Pogrešna kontrolna suma RC01 Pogrešan identifikator banke
BE01 Nesaglasan krajnji korisnik RF01 Referenca transakcije nije jedinstvena
BE04 Pogrešna adresa poverioca TM01 Cutt off time (istek vremena)
BE05 Neprepoznat poverilac ED05 Greška u obračunu
BE06 Neprepoznat dužnik RR01 Razlozi regulatora (procesora)
PORUKA paos.004.001.01 REQUEST&CANCELLATION
Struktura: SerbianCancel
• Koristi se za povlačenje instrukcija za evidentiranje, izmenu i povlačenje Mandata, pri čemu element
OriginalMessageName ima vrednost tipa instrukcije koja se povlači.
• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata, pre
realizacije instrukcije koja se povlači.
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1-n + TransactionInformation Transaction
Information
Telo poruke za
povlačenje poruke ili
pojedinačne instrukcije
2.1 M 1 + + TransactionId Max35Text Jedinstveni Id
transakcije podnosioca
instrukcije
2.2 M 1 + + OriginalTransactionInformation OriginalGroup
Information2
Identifikacija originalne
poruke
2.3 M 1 + + + OriginalMessageId Max35Text Jedinstveni identifikator
originalne poruke
2.4 M 1 + + + OriginalMessageName Max35Text Naziv originalne
poruke.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 408
2.5 O 0-1 + + + OriginalCreationDate ISODateTime Datum kreiranja
originalne poruke
2.6 O 0-n + + OriginalTransactionId Max35Text Id transakcije banke
podnosioca instrukcije iz
originalne instrukcije
2.7 M 1 + + TransactionStatus TrnsactonIndividual
Status2Code
Vrednost: CNCL
PORUKA mndt.004.001.01 MANDATE QUERY
Struktura: SerbianMandateQuery
• Koristi se za ispostavljanje zahteva za dobijanjem informacija o mandatu evidentiranih u Registru
mandata.
• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata.
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni identifikator
poruke koji formira
pošiljalac poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja poruke
1.3 M 1 + + InstructingAgent FinancialInstitution2 Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija pošiljaoca
poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent FinancialInstitution2 Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija primaoca
poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation Transaction
Information
Telo poruke za upit u
Registar mandata
2.1 M 1 + + TransactionId Max35Text Jedinstveni identifikator
upita
2.2 O 0-n + + Mandate MandateIdentification Identifikacija mandata
ili aneksa
Upit za dati mandat ili
aneks
2.2 O 0-1 + + + MandatId Max35Text Identifikacija mandata ili
aneksa
2.2 O 0-1 + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
2.3 O 0-1 + + MandateStatus MandateIndividual
Status2Code
Status mandata
Upit po statusu mandata
2.4 O 0-n + + Creditor PartyIdentification13 Poverilac
Upit po poveriocu
2.4 O 0-1 + + + DebtorId Max35Text Id dužnika, matični broj ili
Jmbg
2.4 O 0-1 + + + Name Max70Text Ime poverioca
2.5 O 0-n + + CreditorAccount CashAccount8 Broj računa poverioca
Upit po broju računa
poverioca
2.5 O 0-1 + + + AccountId Account
Identification2
Identifikacija računa
poverioca
2.5 O 0-1 + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.6 O 0-n + + CreditorAgent FinancialInstitution3 Banka poverioca
Upit po banci poverioca
2.6 O 0-1 + + + AgentId FinancialInstitution
Identification5
Identifikacija banke
poverioca
2.6 O 0-1 + + + + BICAgent BIC Identifier BIC banke poverioca
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 409
2. 7 O 0-n + + Debtor PartyIdentification19 Dužnika
Upit po dužniku
2.7 O 0-1 + + + DebtorId Max35Text Id dužnika, matični broj ili
Jmbg
2.7 O 0-1 + + + Name Max70Text Ime dužnika
2.8 O 0-n + + DebtorAccount CashAccount8 Broj računa dužnika
Upit po računu dužnika
2.8 O 0-1 + + + AccountId Account
Identification2
Identifikacija računa
dužnika
2.8 O 0-1 + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.9 O 0-n + + DebtorAgent FinancialInstitution3 Banka dužnika
Upit po banci dužnika
2.9 O 0-1 + + + AgentId FinancialInstitution
Identification5
Identifikacija banke
dužnika
2.9 O 0-1 + + + + BICAgent BIC Identifier BIC banke dužnika
PORUKA mndt.005.001.01 MANDATE RESPONSE
Struktura: SerbianMandateResponse
• Koristi se za davanje odgovora na podneti zahtev za dobijanjem informacija o mandatu evidentiranih
u Registru mandata.
• Generišu ih i ispostavljaju Procesoru, banke koje koriste dodatni servis vođenja Registra mandata i
koje su podnele zahtev za dobijanjem informacija o mandatu .
Index Kardinalnost Element poruke Tip Opis
1.0 M 1 + Header GroupHeader Zaglavlje poruke
1.1 M 1 + + MessageId Max35Text Jedinstveni
identifikator poruke
koji formira pošiljalac
poruke
1.2 M 1 + + CreationDate ISODateTime Datum kreiranja
poruke
1.3 M 1 + + InstructingAgent Financial
Institution2
Pošiljalac poruke
1.3 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
pošiljaoca poruke
1.3 M 1 + + + + BICAgent BICIdentifier BIC pošiljaoca poruke
1.4 M 1 + + InstructedAgent Financial
Institution2
Primalac poruke
1.4 M 1 + + + AgentId FinancialInstitution
Identification4
Identifikacija
primaoca poruke
1.4 M 1 + + + + BICAgent BICIdentifier BIC primaoca poruke
2.0 M 1 + TransactionInformation Transaction
Information
Odgovor na
postavljeni upit
2.1 M 1 + + TransactionId Max35Text Jedinstveni
identifikator odgovora
na upit
2.2 M 1 + + OriginalTransactionId Max35Text Id transakcije
podnosioca upita iz
originalne instrukcije
2.3 O 0-n + + QueryResponse QueryAndResponse Odgovor na upit
2.4 M 1 + + + MandateStatus MandateIndividual
Status2Code
Status mandata iz
internog šifarnika
Procesora
2.5 M 1 + + + MandatInformation Mandate
Information3
Informacije o
mandatu
2.6 O 0-1 + + + + ContractId Max35Text Broj ugovora po kome
je izdat mandat
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 410
2.10 M 1 + + + + MandateType MandateType
Information8
Tip mandata
2.11 M 1 + + + + + SequenceType SequenceType1Code Vrednosti: RECR,
ONEO
2.22 M 1 + + + + MandatId Max35Text Identifikacija mandata
ili aneksa
2.23 M 1 + + + + DateSignature ISODate Datum potpisivanja
mandata ili aneksa
2.24 M 1 + + + + AmendmentIndicator TrueFalseIndicator Indikator aneksa
(izmena mandata)
2.25 O 0-1 + + + + AmendmentInformation AmndmntInformation
Details4
Informacije o
osnovnom mandatu
2.26 O 0-1 + + + + + OrgMandateId Max35Text Identifikator
osnovnog mandata
2.43 M 1 + + + Creditor Party
Identification13
Poverilac
2.43 M 1 + + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.43 M 1 + + + + Name Max70Text Ime poverioca
2.43 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
poverioca
2.43 O 0-5 + + + + + Address Max70Text Adresa poverioca
2.43 M 1 + + + + + CountryCode CountryCode Kod države poverioca
2.44 M 1 + + + CreditorAccount CashAccount8 Broj računa poverioca
2.44 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
poverioca
2.44 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
poverioca
2.45 M 1 + + + CreditorAgent FinancialInstitution2 Banka poverioca
2.45 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
poverioca
2.43 M 1 + + + + + BICAgent BIC Identifier BIC banke poverioca
2.57 M 1 + + + Debtor Party
Identification19
Dužnika
2.57 M 1 + + + + DebtorId Max35Text Id dužnika, matični
broj ili Jmbg
2.57 M 1 + + + + Name Max70Text Ime dužnika
2.57 O 0-1 + + + + PostAddress PostalAddress4 Poštanska adresa
dužnika
2.57 O 0-5 + + + + + Address Max70Text Adresa dužnika
2.57 M 1 + + + + + CountryCode CountryCode Kod države dužnika
2.58 M 1 + + + DebtorAccount CashAccount8 Broj računa dužnika
2.58 M 1 + + + + AccountId Account
Identification2
Identifikacija računa
dužnika
2.58 M 1 + + + + + IBANAccount IBANIdentifier IBAN broj računa
dužnika
2.59 M 1 + + + DebtorAgent FinancialInstitution2 Banka dužnika
2.59 M 1 + + + + AgentId FinancialInstitution
Identification4
Identifikacija banke
dužnika
2.59 M 1 + + + + + BICAgent BIC Identifier BIC banke dužnika
2.81 O 0-1 + + + RemmitanceInformation Remittance
Information3
Informacije o
plaćanju
2.82 O 0-n + + + + UnstructuredRemmitance Max140Text Nestruktuirane
informacije o plaćanju
2.83 M 1 + + + + StructuredRemmitance StructuredRemittance
Information6
Struktuirane
informacije o plaćanju
2.84 M 1 + + + + + FirstCollectionDate ISODate Datum kada može da
bude realizovana prvo
zaduženje
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 411
2.85 O 0-1 + + + + + FinalCollectionDate ISODate Datum do koga može
da bude izvršavana
poslednje zaduženje
2.86 M 1 + + + + + NumberOfCollection Max15NumericText Maksimalni broj
obaveza po mandatu
2.87 M 1 + + + + + TotalAmount EuroMax9Amount Ukupan iznos
zaduženja po mandatu.
2.87 M 1 + + + + + + Amount Decimal, 9,2 Ukupan iznos
plaćanja.
2.87 M 1 + + + + + + CurrencyCode EuroCurrencyCode Kod valute
2.88 O 0-1 + + + + + Frequency Metric FrequencyMetric Metrika dospeća
2.88 M 1 + + + + + + Frequency Code FrequencyCode Kodirana metrika
dospeća:
DAIL, za dan,
MNTH, za mesec
YEAR, za godinu
2.88 M 1 + + + + + + Periodic Max15NumericText Periodika dospeća u
datoj metrici
2.89 O 0-n + + + + + FixedReqDate ISODate Fiksni datumi dospeća
(DueDate)
2.90 O 0-1 + + + + + Tolerancy Tolerancy Period tolerancije
dospeća u danima
2.91 M 1 + + + + + + TolerancySign TolerancySign Kodirani znak perioda
tolerancije:
PLS, po dospeću
(PLUS)
MNS, pre dospeća
(MINUS)
BTH, pre i posle
dospeća (BOTH)
2.91 M 1 + + + + + + TolerancyValue Max15NumericText Broj dana tolerancije u
dospeću
2.92 O 0-1 + + + + + DebitAmount EuroMax9Amount Maksimalni iznos u
jednom nalogu
zaduženja (collection)
2.92 M 1 + + + + + + Amount Decimal, 9,2 Iznos plaćanja.
2.92 M 1 + + + + + + CurrencyCode EuroCurrencyCode Kod valute
2.93 O 0-1 + + + + + Exchange Exchange Valutni uslovi plaćanja
2.93 M 1 + + + + + + CurrencyCode CurrencyCode Kod valute plaćanja
2.93 M 1 + + + + + + ExchangeRate BaseOnRate Kurs ugovorene valute:
SEL – prodajni kurs
MID – srednji kurs
BUY – kupovni kurs
2.93 M 1 + + + + + + Exchange list BaseOnList Vrednosti :
NBS – za kursnu listu
Narodne banke
BANK – za kursnu
listu banke (nije osnov
za kontrolu Procesora)
2.97 O 0-1 + + + + + CreditorReference CreditorReference
Information1
Identifikator dužnika
2.97 O 0-1 + + + + + + ReferenceType CreditorReference
Type1
Referenca
2.97 O 0-1 + + + + + + + Purport Max35Text Poziv na broj dužnika
2.10 O 0-1 + + + + + AdditionalRemitance Max140Text Dodatne informacije o
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 412
PORUKA OMOTNICA ZA PORUKE SOPSTVENOG FORMATA
SWIFT PORUKA MT998 KAO OMOTNICA
Struktura: SWIFT poruka MT998
• Koristi se kao omotnica za poruke sopstvenog formata u sistemu Narodne banke Srbije
Raspored elemenata:
Polje Element poruke Obavezno Napomena
20 Referenca poruke Da TRN
12 Podtip poruke Da Podtip poruke
77E Sadržaj omotnice poruke koji odgovara
navedenom podtipu poruke sopstvenog
formata
Da U sistemu Narodne banke Srvije sadržaj
omotnice u poruci sopstvenog formata
čine samo unapred standardizovana
polja
59A BIC primaoca Da
54A BIC pošiljaoca
21 Povezana referenca
Ostala polja po SWIFT standardu
ukoliko se koriste u konkretnoj poruci
sopstvenog formata
79 Polja sopstvenog formata U prvom redu obavezno samo crtica,
polja sopstvenog formata nemaju dve
tačke na početku
Napomena: Poslovna pravila su definisana od strane Narodne banka Srbije.
PORUKA SMT710 SOPSTVENOG FORMATA
Struktura: Poruka sopstvenog formata u sistemu Narodne banke Srbije
• Koristi se za obaveštenje Službe za prinudnu naplatu o nerealizovanom osnovu (mandatu) i prenos
podataka o osnovu za blokiranje računa dužnika sa zadatim matičnim brojem.
• Generišu ih i ispostavljaju Procesor u slučaju da je instrukcija direktnog zaduženja odbijena od strane
banke dužnika zbog blokade računa dužnika i/ili nedostatka raspoloživih sredstava za realizaciju
zaduženja.
Raspored elemenata u polju :79 omotnice MT998:
Polje Element poruke Obavezno Napomena
71010: Broj računa (počinje „slešom“) Broj računa na koji glasi blokada
71020: Naziv računa Naziv računa na koji glasi blokada
(ukoliko je poznat), max. 35 karaktera
71030: Matični broj vlasnika računa da Obavezno, s obzirom da se blokada vrši po
matićnom broju dužnika
71040: Poreski identifikacioni broj
vlasnika (PIB)
da Obavezno
71051: Tip dokumenta da 02 – hartije od vrednosti
03 – ostali osnovi
71052: Datum i vreme prijema da U formatu: YYMMDD HH:MM:SS
71053: Datum dospeća da U formatu: YYMMDD
71054: Prioritet da 01 do 10
71056: Iznos za izvršenje (nenaplaćeni
iznos), odnosno zabranu
raspolaganja
da
71059: Broj sa dokumenta, sudski broj
rešenja
da Max. 35 karaktera
Podaci o blokadi, polja iz poruke
MT103 (57A, 59, 70 i 72) koja
treba da se izvrši da bi prinudna
naplata bila sprovedena
Polja su označena sa 57A:, 59:, 70: i 72:
57A: Račun i BIC banke čiji se račun
odobrava (u kojoj je korisnikov
račun) u formatu:
/C/račun banke ili /račun banke
da Mora da se slaže sa vodećim brojem
računa u tagu 59.
Kose crte i scovo C su deo sintakse
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 413
BIC
59: Bez opcija
/račun korisnika
naziv i adresa
da Račun je obavezan, a kosa crta je deo
sintakse za označavanje računa
70: Šifra plaćanja, poziv na broj
zaduženja i poziv na broj
odobrenja.
Elementi se označavaju
prefiksima koji su crticama
odvojeni od sadržaja
Pozivi na broj imaju sa leve strane
pridružene odgovarajuće modele,
tako da ukupna dužna ne prelazi
22 karaktera:
SIF-(šifra plaćanja)
PBZ-(poziv na broj zaduženja)
PBO-(poziv na broj odobrenja)
Da Primer:
:70:SIF-111
PBZ-97123456ABC
PBO-97123AFG14
REF-456789
72: Svrha plaćanja, do 105 karaktera
U prvom redu /BNF/, a u ostalim
redovima //
Najviše 4 reda
da Primer:
:72:/BNF/UPLATA PO
//FAKTURI 123AFG14,
//RAZLIKA ZA MAJ
71070: Ukoliko je zabranjeno
raspolaganje - datum do koga je
zabranjeno ili reč TRAJNO
ukoliko nije oročeno, a prazno
ukoliko je u pitanju prinudna
naplata
71090: Datum promene da U formatu: YYMMDD
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 414
Prilog 7:
Ispunjenost regulative evropskog saveta za plaćanja
Sistem ispunjava zakonsku regulativu propisanu od strane evropskog saveta za plaćanja
EPC ako je u skladu sa sledećim:
R.Br. Tekst
1. Uvodjenje/Izmena
zakonskog okvira
Evropski parlament pozdravlja inicijativu Komisije da ustanovi zakonske
preduslove za uspostavljanje zone sa jedinstvenim sistemom plaćanja u radu sa
stanovništvom; naznačava, međutim, da nacionalna pravila moraju da budu
formulisana na takav način da ne ugrožavaju efikasnost nacionalnih sistema i
procedura.
2. Instrumenti plaćanja Uzima u obzir da je neophodno obezbediti paket praktičnih, povoljnih, postojanih i predvidljivih načina plaćanja.
3. Upoznavanje sa
budućim slučajevima
korišćenja
Zahteva od komisije da (što ranije / pre svega ) sačini ekonomsku studiju kroz
koju se sagledava i razjašnjava koliki je ulog, i koje mogućnosti mogu da budu
odabrane, imajući u vidu, pored ostalog, infrastrukturu, međupovezanost i inter-
bankarstvo.
4. Ograničenja lokalnih
regulativa
Razmatra se, imajući u vidu da je trenutna situacija u evropskoj platnoj sferi
nezadovoljavajuća, da se na tehničkom nivou preduzmu neophodne zakonske
mere da bi se uspostavio efikasan i efektan evropski platni sistem.
5. Transparentnost
zahtevanog sistema
Ostaje pri tom, da iz gore navedenog proizilazi da institucije Unije treba da
jasno predstave svoje namere i plan (raspored) implementacije, kao i da
privredni deoničari treba da nadgledaju implementaciju.
6. Usitnjavanje i
ukrupnjavanje
Zauzima stav da dobri poslovni običaji i pravila koja uređuju rad institucija koje
pružaju platne usluge treba da budu sačinjena uniformnije na evropskom nivou
u cilju obezbeđenja uslova za ravnopravnu konkurenciju; zauzima stav da dalje
usitnjavanje regulative o dobrim poslovnim običajima ili samanjenje standarda
kojim isti podležu, mora da bude sprečeno; zauzima stav da u interesu svih
zainteresovanih strana (potrošači, trgovci, i banke), novi status institucija koje
pružaju platne usluge ne sme da dovde do pogoršanja u fizičkoj, osmišljenoj,
finansijskoj i ekonomskoj sigurnosti sredstava plaćanja, prisutnih na tržištu.
7. Monopolizam
Poziva komisiju da pomno prati trendove koncentracije među ponuđačima
platežnih usluga; primetno je da u nekim oblastima, na pr. Kreditnih kartica,
tržištem dominira manji broj preduzeća; nameće se stav da pružanje platežnih
usluga (transferi novca, sredstva prekoračenja) zahteva visok nivo stručnosti i
odgovornosti u odnosu na potrošače, što upućuje na to da platežne usluge
stanovništvu mogu da pružaju isključivo službeno nadzirane firme.
8. Propisana pravila u
sistemu
Pozdravlja nameru komisije da uključi sva spoljna i unutrašnja plaćanja u
zakonski okvir; predlaže da se okvir zakonskog delokruga od 2006-te proširi na
sva plaćanja unutar EU do iznosa od 50000 EUR; poziva na jedinstvena pravila
za regulisanje transakcija koje se izvršavaju u drugim evropskim valutama.
9. Sigurnost
Smatra da je neophodno promovisati zakonsku postojanost i tehničku sigurnost
plaćanja u evro zoni, imajući u vidu da potrošači s pravom očekuju da će u istoj
meri biti zaštićeni na unutrašnjem tržištu kao što su to u njihovim matičnim
državama.
10. 11. Inovacije
Pozdravlja namere Evropske bankarske industrije kao i Komisije, da se
uspostavi pan-evropska direktno-debitna šema.
Ostaje pri stavu da, u pogledu sektora bankovnih kartica, u kojem je
prekogranična delatnost vrlo zadovoljavajuća, jedan od prioriteta treba da bude i
uvođenje nove generacije smart kartica, i to u potpunosti i bez kašnjenja, u cilju
obezbeđenja veće sigurnosti pomenutih kartica na celovitom području Unije.
12. Izveštavanje
Smatra za neophodno da se najbitnije informacije bankovnim klijentima pružaju
na sažet i lako razumljiv način, ocenjujući pri tom da su, od strane Unije
predloženi kompleksni zahtevi u pružanju informacija i da su kao takvi trenutno
preobimni i nepraktični.
13. Komunikacioni kanali
Imajući u vidu da je potrošačka mobilnost u suštinskom interesu zdrave
konkurencije; poziva Bankarsku industriju da podnese predloge za
standardizovanu razmenu podataka (na pr: poslovnici, direktna zaduženja) u
cilju olakšanja procedure premeštanja klijentskih računa (naloga); odbacuje
evropske odredbe o maksimalnoj naknadi za zatvaranje računa (naloga) i
insistira na potpunoj transparentnosti kada su u pitanju ovakve naknade.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 415
14. 17.18. Životni ciklusi
Zagovara, u interesu zakonske postojanosti i materijalno povoljnog procesiranja
platnih naloga, mogućnost rane neopozivosti (na pr: pre nego što je transfer
inicijalizovan) platnih naloga koji su direktno upućeni entitetu za pružanje
platnih usluga (na pr: transferi); predlaže takvo rešenje za slučajeve direktnog
debitnog plaćanja, da postoji mogućnost da se isti opozovu u dužem periodu, pre
svega kada iznos koji treba platiti iz bilo kojih razloga ne može da bude
naznačen u vreme izdavanja platnog naloga.
Odbacuje preporuke da se lično učešće klijenata ograniči na EUR 150 u
slučajevima neovlašćenih transakcija (na pr: ukradena kreditna kartica), i to
kada klijenti nisu ispunili svoju obavezu da o tome pruže obaveštenje; insistira
se, radije, na ohrabrivanju lične odgovornosti klijenata, kao i da je potrebno
obezbediti takva rešenja koja bi omogućila blokiranje platnih kartica na
celokupnoj teritoriji EU, putem jedinstvenog telefonskog broja.
Zagovara rešenje da se zakonskim okvirom ustoliči princip po kojem bi,
bez obzira na korišćeni način plaćanja, celokupan iznos naznačen u
platnom nalogu bio prebačen na račun (nalog) primaoca, bez ikakvih
odbitaka, sem ukoliko primalac nije eksplicitno postigao drugačiji
sporazum sa svojom bankom, u kom slučaju, iznos i tip odbitka treba da
bude jasno naznačen primaocu.
15. Razgraničenje
odgovornosti
Pozdravlja stremljenja u promovisanju trgovine na distancu i Internet prodaje;
odbacuje odgovornost institucija koje obezbeđuju platne usluge, u slučajevima
sporova između prodavaca i kupaca, međutim, ipak radije insistira na jasnom
razgraničenju između bazičnih transakcija i plaćanja, bilo kroz postulate
odgovornosti ili pak kroz proširenje klijentskog prava opoziva; smatra da razvoj
(opcionalnih) sigurnosnih sistema (na pr: kroz namenske račune) treba prepustiti
samom tržištu.
16. Sledljivost
Smatra da institucija koja obezbeđuje platne usluge treba da bude odgovorna za
tačno i pravovremeno izvršenje platnih naloga kako je to regulisano državnim
zakonima zemalja članica, kao i da bude obavezna da to i dokaže, već čim se
klijentski platni nalog nađe u njenom posedu; odbacuje bilo kakvo proširenje
stroge odgovornosti; mišljenja je, ipak, da u okviru zakonskog odnosa sa
klijentom, a u pogledu grešaka u selekciji, odgovornost pomenute institucije
treba proširiti i na druge firme u lancu kao i na tehničke kapacitete koje koristi;
predlaže da kroz internu regulativu, bankovne asocijacije, mrežne operatere i
trgovce usvoji proceduru za pravovremeno razjašnjenje pitanja interne
odgovornosti; smatra da procenjivanje odgovornosti u vezi sa posledičnim
štetama i višom silom treba da bude prepušteno nacionalnim jurisdikcijama.
19. Fleksibilnost
Pozdravlja predlog Komisije, u pogledu Specijalne Preporuke VII, da se EU
definiše kao integrisani zakonski okvir; zauzima stav, međutim, da granične
vrednosti moraju da budu uvedene za gotovinske transfere; primećuje da je
tehnički neizvodljivo sačiniti efektne rizik-orjentisane procedure za
identifikaciju transfera kojima nedostaju podaci o poreklu inicijalizatora.
20. Upoznavanje sa
rizicima
Podstiče bankarsku industriju da kontinuirano unapređuje bezbednost
on-line bankarstva, u saradnji sa sektorom informacionih tehnologija i
nadzornim vlastima, kao i da klijentima pruži smislene i razumljive
informacije o potencijalnim rizicima i neophodnoj predostrožnosti.
21. Poravnanje
Pozdravlja sve pokušaje alternativnog rešenja sporova koji mogu da
doprinesu izbegavanju dugotrajnih parnica; smatra da ukoliko se putem
dobrovoljne rasprave sporovi ipak ne razreše u razumnom vremenu, kao
i da se ne može obezbediti efektna žalbena procedura ili obeštećenje za
klijente, bude neophodno da se rešenje sporova obavezno obavlja u
okviru zemalja članica, kao i na evropskom nivou;
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 416
Prilog 8:
Ekonomska opravdanost uvođenja platnog sistema
Uporedna tabela sa procenom prihoda platnog sistema u odnosu na broj procesiranih
poruka u toku jedne godine prema broju poruka i broju transakcija u prvoj vrsti
objavljenih od strane Udruženja banaka Srbije na bankarskom skupu BankInfo 2012 na
Paliću:
Tabela 1. Finansijska očekivanja u odnosu na broj poruka na godišnjem nivou
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 417
Prilog 9:
Triger nad tabelom stanja.
Triger nad tabelom Stanja ima zadatak kada se promeni stanje na računu pokuša da
izvrši još jednu transakciju koja je u bazi podataka zapisana sa stanjem „na čekanju za
izvršenje zbog nedostatka sredstava“.
CREATE TRIGGER [dbo].[FirstOnStanja]
ON [dbo].[Stanja] after
UPDATE AS
declare
@Racun varchar(50), @PocetnoStanje money, @ZakljucanCredit bit, @ZakljucanDebit
bit, @Stanje money, @Datum datetime, @Pom integer, @IDTransakcije varchar(50),
@RacunDugujeTransakcije varchar(30), @RacunPotrazujeTransakcije varchar(30),
@DatumTransakcije datetime, @IznosTransakcije money, @IDPorukeTransakcije
varchar(50), @Prioritet char(4), @PrioritetTransakcije char(4), StatusTransakcije
varchar(10), @MTTipTransakcije char(3), @TRNPorukeTransakcije char(12),
@TRNDatumTransakcije char(6), @Poruka varchar(50), @StanjeA money, @StanjeB
money, @IDPoruke
varchar(50), @Racun1 varchar(30), @Racun2 varchar(30), @PrioritetN int, @MT76
varchar(72), @MT77A varchar(72), @StatusRGSa varchar(18)
SELECT @StatusRGSa = StatusRGSa FROM BrojPoruke
if(@StatusRGSa='1')
BEGIN
if((select trigger_nestlevel()) < 25)
begin
select @Racun = Racun,
@PocetnoStanje = PocetnoStanje,
@ZakljucanCredit = ZakljucanCredit,
@ZakljucanDebit = ZakljucanDebit,
@Stanje = Stanje,
@Datum = Datum FROM inserted
select @Pom = count(*)
from Transakcije
where RacunDuguje = @Racun and Status = '20'
if(@Pom > 0)
begin
select top 1 @Poruka = IDPoruke
from Transakcije
where RacunDuguje = @Racun and Status = '20'
order by Prioritet, Brojac asc
select top 1
@RacunDugujeTransakcije = RacunDuguje,
@RacunPotrazujeTransakcije = RacunPotrazuje,
@DatumTransakcije = Datum,
@IznosTransakcije = Iznos,
@IDPorukeTransakcije = IDPoruke,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 418
@PrioritetTransakcije = Prioritet,
@StatusTransakcije = Status,
@MTTipTransakcije = MTTip
from Transakcije
where IDPoruke = @Poruka
select @StanjeA = Stanje
from Stanja
where Racun = @RacunDugujeTransakcije and Datum =
@Datum
select @StanjeA = @StanjeA - @IznosTransakcije
if(@StanjeA<0)
begin
select @Prioritet = Prioritet from Transakcije where IDPoruke =
@Poruka
select @Prioritet = substring(@Prioritet, 3, 4)
select @PrioritetN=convert(integer, @Prioritet)
if (@Prioritet>90)
begin
update Transakcije set Status = '99' where IDPoruke =
@IDPoruke
set @MT76 = 'Prioritet > 90 i stanje < 0'
set @MT77A = @MT76 --
if(@MTTipTransakcije=102)
begin
select @TRNPorukeTransakcije = s20,
@TRNDatumTransakcije =
substring(s32A, 1,6)
from MT102Arhiva
where IDMT102=@IDPorukeTransakcije
end
if(@MTTipTransakcije=103)
begin
select @TRNPorukeTransakcije = s20,
@TRNDatumTransakcije =
substring(s32A, 1,6)
from MT103Arhiva
where IDMT103=@IDPorukeTransakcije
end
if(@MTTipTransakcije=202)
begin
select @TRNPorukeTransakcije = s20,
@TRNDatumTransakcije =
substring(s32A, 1,6)
from MT202Arhiva
where IDMT202=@IDPorukeTransakcije
end
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 419
exec dbo.MTResponse196
@MTTipTransakcije, @IDPorukeTransakcije,
@TRNPorukeTransakcije,
@TRNDatumTransakcije,
@MT76, @MT77A
if (@MTTipTransakcije='102')
begin
update dbo.MT102Arhiva
set StatusP = @MT76 where
IDMT102=@IDPoruke
end
if (@MTTipTransakcije='103')
begin
update dbo.MT103Arhiva
set StatusP = @MT76 where
IDMT103=@IDPoruke
end
if (@MTTipTransakcije='202')
begin
update dbo.MT202Arhiva
set StatusP = @MT76 where
IDMT202=@IDPoruke
end
end
end
else
begin
update Transakcije set Status = '90' where IDPoruke = @Poruka
select @StanjeA = Duguje
from Stanja
where Racun = @RacunDugujeTransakcije and Datum =
@Datum
select @StanjeA = @StanjeA + @IznosTransakcije
select @StanjeB = Potrazuje
from Stanja
where Racun = @RacunPotrazujeTransakcije and Datum
= @Datum
select @StanjeB = @StanjeB + @IznosTransakcije
update Stanja set Duguje = @StanjeA
where Racun = @RacunDugujeTransakcije and Datum =
@Datum
update Stanja set Potrazuje = @StanjeB
where Racun = @RacunPotrazujeTransakcije and Datum
= @Datum
set @MT76 = 'PLACANJE JE REALIZOVANO'
set @MT77A = @MT76 --
if(@MTTipTransakcije=102)
begin
select @TRNPorukeTransakcije = s20,
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 420
@TRNDatumTransakcije = substring(s32A, 1,6)
from MT102Arhiva
where IDMT102=@IDPorukeTransakcije
end
if(@MTTipTransakcije=103)
begin
select @TRNPorukeTransakcije = s20,
@TRNDatumTransakcije = substring(s32A, 1,6)
from MT103Arhiva
where IDMT103=@IDPorukeTransakcije
end
if(@MTTipTransakcije=202)
begin
select @TRNPorukeTransakcije = s20,
@TRNDatumTransakcije = substring(s32A, 1,6)
from MT202Arhiva
where IDMT202=@IDPorukeTransakcije
end
exec dbo.MTResponse900
@MTTipTransakcije, @IDPorukeTransakcije,
@TRNPorukeTransakcije, @TRNDatumTransakcije
exec dbo.MTResponse910
@MTTipTransakcije, @IDPorukeTransakcije,
@TRNPorukeTransakcije, @TRNDatumTransakcije
exec dbo.MTResponseRoute
@MTTipTransakcije, @IDPorukeTransakcije,
@TRNPorukeTransakcije, @TRNDatumTransakcije
if (@MTTipTransakcije='102')
begin
update dbo.MT102Arhiva set StatusP = @MT76
where IDMT102=@IDPoruke
end
if (@MTTipTransakcije='103')
begin
update dbo.MT103Arhiva set StatusP = @MT76
where IDMT103=@IDPoruke
end
if (@MTTipTransakcije='202')
begin
update dbo.MT202Arhiva set StatusP = @MT76
where IDMT202=@IDPoruke
end
end
end
end
END
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 421
Prilog 10:
Biografija autora
Slobodan Babić je rođen 22.06.1959 godine u Prijedoru, BiH. Osnovnu školu i
gimnaziju je završio Beogradu. Na Matematičkom fakultetu u Beogradu je diplomirao
na smeru Numerička matematika sa kibernetikom 1993 godine. Poslediplomske studije
upisao je na Tehničkom fakultetu u Boru 2005/06. godine. Magistarsku tezu pod
nazivom „Razvoj platnih sistema baziranih na ISO20022 XML standardu sa osvrtom na
jedinstvenu evropsku platnu zonu“ odbranio je 2008 godine i stekao akademski naziv
Magistar nauka u naučnoj oblasti Industrijska informatika. Individualni je član tima
međunarodne organizacije TWIST (The Transaction Workflow Innovation Standards
Team) za standardizaciju finansijskih lanaca snabdevanja sa sedištem u Londonu,
Engleska. Osnivač je Udruženja poslovnih informatičara – IIBA Serbia Chapter u
Beogradu, ogranka Internacionalnog instituta za poslovnu analizu (IIBA) sa sedištem u
Torontu, Kanada.
Po završetku osnovnih studija prvo radno iskustvo kao diplomirani matematičar u
informatici je stekao u “LOLA KORPORACIJI A.D.” na razvoju generalnog
informacionog sistema Korporacije u saradnji sa timom Fakulteta organizacionih nauka.
U Opštini Čukarica je počeo da radi kao sistem analitičar od 1997 godine gde radi na
studiji razvoja informacionog sistema opštine, uspostavljanju sigurnosnih i drugih
standarda, vođenju projekta razvoja lokalne mrežne infrastrukture, vođenju i učešću u
projektima razvoja aplikativnih rešenja za potrebe opštine.
Nakon toga 1999 godine prelazi u Narodnu banku Jugoslavije gde radi na rešavanju
„problema 2000 godine“, aplikativnom rešenju za monetarni sektor (praćenju tokova
novca), učestvuje u telu za definisanje metodologije razvoja informatičkih rešenja NBS
i komisiji za uvođenje novog sistema platnog prometa.
U Sagu d.o.o. Beograd prelazi 2002 godine na poslove analitičara i rukovodioca
projekata za platne sisteme gde inicira razvoj platnih sistema baziranih na SWIFT MT
[210] i ISO20022 [101] sistemima poruka i učestvuje kao poslovni analitičar i
rukovodilac projekta na razvoju e-Banking i drugih sistema.
U Kompaniju Dunav osiguranje a.d.o. prelazi 2010. godine na poziciju direktora
Sektora za obradu podataka i održavanje. Učestvuje aktivno na projektima uvođenja
arhivističkog sistema kompanije, sistema za izdavanje polisa autoodgovornosti po novoj
zakonskoj regulativi kao i na sistemu za evidenciju distribuiranih informatičkih resursa
kompanije. Trenutno je na poziciji direktora Sektora za sistemsku podršku u
Informatičkoj funkciji Kompanije Dunav osiguranje a.d.o.
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 422
Prilog 11.
Izjava o autorstvu
Potpisani Slobodan N. Babić
broj indeksa
Izjavljujem
da je doktorska disertacija pod naslovom
MODEL INTEROPERABILNOG ELEKTRONSKOG POSLOVANJA PLATNIH
SISTEMA ZASNOVANIH NA ONTOLOGIJAMA
• rezultat sopstvenog istraživačkog rada,
• da predložena disertacija u celini ni u delovima nije bila predložena za dobijanje
bilo koje diplome prema studijskim programima drugih visokoškolskih
ustanova,
• da su rezultati korektno navedeni i
• da nisam kršio autorska prava i koristio intelektualnu svojinu drugih lica.
Potpis doktoranda
U Beogradu, ________________________
_________________________
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 423
Prilog 12.
Izjava o istovetnosti štampane i elektronske verzije
doktorskog rada
Ime i prezime autora Slobodan Babić
Naslov rada MODEL INTEROPERABILNOG ELEKTRONSKOG POSLOVANJA
PLATNIH SITEMA ZASNOVANIH NA ONTOLOGIJAMA
Mentor Prof. dr Marijana Despotović-Zrakić
Potpisani Slobodan N. Babić
Izjavljujem da je štampana verzija mog doktorskog rada istovetna elektronskoj verziji
koju sam predao za objavljivanje na portalu Digitalnog repozitorijuma Univerziteta u
Beogradu.
Dozvoljavam da se objave moji lični podaci vezani za dobijanje akademskog zvanja
doktora nauka, kao što su ime i prezime, godina i mesto rođenja i datum odbrane rada.
Ovi lični podaci mogu se objaviti na mrežnim stranicama digitalne biblioteke, u
elektronskom katalogu i u publikacijama Univerziteta u Beogradu.
Potpis doktoranda
U Beogradu, ________________________
_________________________
Doktorska disertacija: Мodel interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama
Slobodan Babić | Fakultet organizacionih nauka 424
Prilog 13.
Izjava o korišćenju
Ovlašćujem Univerzitetsku biblioteku „Svetozar Marković“ da u Digitalni repozitorijum
Univerziteta u Beogradu unese moju doktorsku disertaciju pod naslovom:
MODEL INTEROPERABILNOGELEKTRONSKOG POSLOVANJA PLATNIH
SISTEMA ZASNOVANIH NA ONTOLOGIJAMA koja je moje autorsko delo.
Disertaciju sa svim prilozima predao sam u elektronskom formatu pogodnom za trajno
arhiviranje.
Moju doktorsku disertaciju pohranjenu u Digitalni repozitorijum Univerziteta u
Beogradu mogu da koriste svi koji poštuju odredbe sadržane u odabranom tipu licence
Kreativne zajednice (Creative Commons) za koju sam se odlučio.
1. Autorstvo
2. Autorstvo - nekomercijalno
3. Autorstvo – nekomercijalno – bez prerade
4. Autorstvo – nekomercijalno – deliti pod istim uslovima
5. Autorstvo – bez prerade
6. Autorstvo – deliti pod istim uslovima
(Molimo da zaokružite samo jednu od šest ponuđenih licenci, kratak opis licenci dat je
na poleđini lista).
Potpis doktoranda
U Beogradu, ________________________
____________________