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, ________________________ ____________________