Projektni zadatak za predmetXML i Web servisi

generacija 2015.

Scenario u kome se odvija komunikacija izmeu razliitih informacionih sistema obuhvata sledee tipove uesnika:1. firma - preduzee koje prodaje/kupuje robu ili prua/koristi usluge2. banka - posebna vrsta preduzea preko koga se odvija platni promet3. centralna banka (CB) banka preko koje se vri meubankarski platni promet. Kod nas je to Narodna banka Srbije. Preko nje se odvijaju sledei naini prenosa sredstava u meubankarskom platnom prometu:

RTGS (Real Time Gross Settlement) za iznose vee ili jednake 250.000 RSD kao i za iznose sa indikatorom hitno.

Clearing & Settlement za iznose manje od 250.000 RSD

Za potrebe projektnog zadatka razmatra se ukupno pet uesnika: Firma A, koja ima otvorene raune u Banci C, zatim Firma B, koja ima otvorene raune u Banci D, i CB za meubankarski platni promet. (Napomena: meubankarski platni promet u praksi funkcionie na neto sloeniji nain. Za potrebe ovog zadatka posmatraemo pojednostavljeni sistem. Format poruka koje se razmenjuju sa CB sistemom propisan je uredbama i uputstvima NBS). NAPOMENA: Projektni zadatak je potrebno realizovati tako da programski kod bude nezavisan od broja banaka i firmi u sistemu.

1. Komunikacija izmeu uesnika

1.1. Slanje fakturaFirme A i B poslovno sarauju. Svaka firma za isporuene robe ili pruene usluge drugoj firmi

1 / 16

Firma BFirma A

Banka C Banka D

slanje faktura

nalo

g za

pla

anj

e

preu

zim

anje

izvo

da

preu

zim

anje

izvo

da

nalo

g za

pla

anj

e

CB

RTGS

/Clear

ing&S

ettlem

ent

nalog

RTGS/Clearing&Settlement

nalog

ispostavlja raun (fakturu). Faktura se sastoji iz zaglavlja i jedne ili vie stavki. Zaglavlje fakture obuhvata sledee podatke:

Polje Tip Veliina

ID poruke String 50

Naziv dobavljaa String 255

Adresa dobavljaa String 255

PIB dobavljaa String 11

Naziv kupca String 55

Adresa kupca String 55

PIB kupca String 11

Broj rauna Number 6

Datum rauna Date

Vrednost robe Decimal 15,2

Vrednost usluga Decimal 15,2

Ukupno roba i usluge Decimal 15,2

Ukupan rabat Decimal 15,2

Ukupan porez Decimal 15,2

Oznaka valute String 3

Iznos za uplatu Decimal 15,2

Uplata na raun String 18

Datum valute Date

Stavka fakture obuhvata sledee podatke:Polje Tip Veliina

Redni broj Number 3

Naziv robe ili usluge String 120

Koliina Decimal 10,2

Jedinica mere String 6

Jedinina cena Decimal 10,2

Vrednost Decimal 12,2

Procenat rabata Decimal 5,2

Iznos rabata Decimal 12,2

Umanjeno za rabat Decimal 12,2

Ukupan porez Decimal 12,2

1.2. Slanje naloga za plaanjeFirma koja plaa drugoj firmi za primljenu robu ili usluge (po osnovu fakture) obraa se svojoj banci (kod koje ima otvoren raun) sa nalogom za plaanje. Nalog za plaanje obuhvata sledee podatke:

2 / 16

Polje Tip Veliina

ID poruke String 50

Dunik - nalogodavac String 255

Svrha plaanja String 255

Primalac - poverilac String 255

Datum naloga Date

Datum valute Date

Raun dunika String 18

Model zaduenja Number 2

Poziv na broj zaduenja

String 20

Raun poverioca String 18

Model odobrenja Number 2

Poziv na broj odobrenja

Number 20

Iznos Decimal 15,2

Oznaka valute String 3

Hitno Boolean

1.3. Preuzimanje izvodaRadi evidentiranja uplata na svoj raun, firma se obraa banci sa zahtevom za dobijanje izvoda za traeni datum. Zahtev za dobijanje izvoda obuhvata sledee podatke:

3 / 16

Polje Tip Veliina

Broj rauna String 18

Datum Date

Redni broj preseka Number 2

Izvod se potencijalno sastoji od velikog broja stavki pa su stavke grupisane u preseke (numerisane od 1 na vie). Na jedan zahtev firme banka dostavlja jedan presek. Dobijanje izvoda za traeni datum se svodi na preuzimanje jednog ili vie preseka. Presek se sastoji iz zaglavlja i stavki. Zaglavlje preseka obuhvata sledee podatke:

Polje Tip Veliina

Broj rauna String 18

Datum naloga Date

Broj preseka Number 2

Prethodno stanje Decimal 15,2

Broj promena u korist Number 6

Ukupno u korist Decimal 15,2

Broj promena na teret Number 6

Ukupno na teret Decimal 15,2

Novo stanje Decimal 15,2

Stavka preseka obuhvata sledee podatke:

Polje Tip Veliina

Dunik - nalogodavac String 255

Svrha plaanja String 255

Primalac - poverilac String 255

Datum naloga Date

Datum valute Date

Raun dunika String 18

Model zaduenja Number 2

Poziv na broj zaduenja

String 20

Raun poverioca String 18

Model odobrenja Number 2

Poziv na broj odobrenja

String 20

Iznos Decimal 15,2

Smer Char 1

4 / 16

1.4. Meubankarski promet Prilikom izvrenja plaanja, ukoliko Firma A i Firma B imaju raun u istoj banci, banka moe odmah da prebaci sredstva sa jednog rauna na drugi. Ukoliko Firma A ima raun u Banci C, a Firma B ima raun u Banci D, i Firma A poalje nalog za plaanje Firmi B, tada se plaanje odvija preko CB.

1.4.1. Meubankarski promet - RTGSUkoliko je iznos za plaanje vei ili jednak od 250 000 RSD ili ako je nalog oznaen kao hitan za meubankarsko plaanje se koristi RTGS model. Odmah po prijemu naloga za plaanje, Banka C izvri rezervaciju sredstava na raunu svog klijenta i potom alje RTGS-nalog (poruka MT103) CB-u. Po prijemu ove poruke CB vri prenos sredstava sa obraunskog rauna banke C na obraunski raun banke B. Potom CB alje banci C poruku o zaduenju (poruka MT900), a banci D prosleuje RTGS nalog (poruka MT103) i poruku o odobrenju (poruka MT910). Banka C prima poruku MT900 i zaduuje raun klijenta (skida novac sa rauna). Banka D prima poruke MT103 i MT910 i odobrava sredstva klijentu (uplauje mu iznos na raun).

Struktura RTGS naloga (MT103) je sledea:Polje Naziv Veliina

ID poruke String 50

SWIFT kod banke dunika String 8

Obraunski raun banke dunika String 18

SWIFT kod banke poverioca String 8

Obraunski raun banke poverioca

String 18

Dunik - nalogodavac String 255

Svrha plaanja String 255

Primalac - poverilac String 255

Datum naloga Date

Datum valute Date

Raun dunika String 18

Model zaduenja Number 2

Poziv na broj zaduenja String 20

Raun poverioca String 18

Model odobrenja Number 2

Poziv na broj odobrenja String 20

Iznos Decimal 15,2

ifra valute String 3

5 / 16

Banka C Banka D

CBMT910M

T900

MT103

MT103

Struktura poruke o zaduenju (MT900) je sledea:

Polje Naziv Veliina

ID poruke String 50

SWIFT kod banke dunika

String 8

Obraunski raun banke dunika

String 20

ID poruke naloga(MT102 ili MT103)

String 50

Datum valute Date

Iznos Decimal 15,2

ifra valute String 3

Struktura poruke o odobrenju (MT910) je sledea:

Polje Naziv Veliina

ID poruke String 50

SWIFT kod banke poverioca

String 8

Obraunski raun banke poverioca

String 20

ID poruke naloga(MT102 ili MT103)

String 50

Datum valute Date

Iznos Decimal 15,2

ifra valute String 3

1.4.1. Meubankarski promet Clearing & SettlementUkoliko je iznos za plaanje manji od 250.000 RSD za meubankarsko plaanje se koristi Clearing & Settlement model. Odmah po prijemu naloga za plaanje, Banka C izvri rezervaciju sredstava na raunu svog klijenta. Potom banka C periodino alje naloge za grupna plaanja u kliringu (poruka MT102) CB-u. Ovaj nalog (poruka MT102) sastoji se od pojedinanih naloga za plaanje koje je od prethodnog do tekueg klirinkog ciklusa primila banka C. Svaki pojedinani nalog u poruci MT102 mora biti manji od 250.000 RSD i sva plaanja navedena u poruci MT102 moraju biti upuena klijentima jedne banke. CB prima odreeni period MT102 poruke od svih banaka i onda vri bileteralni neto obraun izmeu obraunskih rauna banaka. Potom CB alje banci C poruku o zaduenju (poruka MT900), a banci D prosleuje poruku MT102 i poruku o odobrenju (poruka MT910). Banka C prima poruku MT900 i zaduuje raune klijenata (skida novac sa rauna). Banka D prima poruke MT102 i MT910 i odobrava sredstva klijentima (uplauje klijentima odgovarajui iznos na raun).

6 / 16

Struktura naloga za grupna plaanja u kliringu (MT102) je sledea:

Polje Naziv Veliina

ID poruke String 50

SWIFT kod banke dunika String 8

Obraunski raun banke dunika String 18

SWIFT kod banke poverioca String 8

Obraunski raun banke poverioca String 18

Ukupan iznos Decimal 15,2

ifra valute String 3

Datum valute Date

Datum Date

Sekvenca za svako pojedinano plaanje koje je obuhvaeno ovim grupnim nalogom

ID naloga za plaanje String 50

Dunik - nalogodavac String 255

Svrha plaanja String 255

Primalac - poverilac String 255

Datum naloga Date

Raun dunika String 18

Model zaduenja Number 2

Poziv na broj zaduenja String 20

Raun poverioca String 18

Model odobrenja Number 2

Poziv na broj odobrenja String 20

Iznos Decimal 15,2

ifra valute String 3

7 / 16

Banka C Banka D

CBMT910M

T900

MT102

MT102

2. Tehnike karakteristike servisa

2.1. Struktura broja bankarskog raunaBroj bankarskog rauna sastoji se iz 18 cifara, sa sledeim znaenjem:

cifre 1-3: 3-cifrena oznaka banke, koja se registruje kod NBS, cifre 4-16: 13-cifrena oznaka rauna (partije) unutar banke i cifre 17-18: checksum koji se rauna za broj sastavljen od cifara 1-16 po ISO 7064, modul 97

(broj se pomnoi sa 100, podeli sa 97, a ostatak pri deljenju oduzme od 98).

2.2. Struktura SWIFT koda bankeSWIFT kod banke sastoji se iz 8 alfanumerikih znakova sa sledeim znaenjem:

znakovi 1-4: oznaka banke (iskljuivo velika slova) znakovi 5-6: oznaka drave po ISO 3166 (iskljuivo velika slova) znakovi 7-8: oznaka lokacije (velika slova ili cifre)

SWIFT kod moe sadrati jo tri dodatna znaka (velika slova ili cifre) kojima se identifikuje ogranak banke. Ukoliko je vrednost ta tri dodatna znaka 'XXX' podrazumeva se centrala banke. Na primer, Continental Banka iz Novog Sada ima SWIFT kod CONARS22, dok Vojvoanska banka iz Novog Sada ima kod VBUBRS22.

2.3. Stil web servisaSOAP-bazirani web servisi. Komunikacija izmeu banaka i centralne banke, kao i komunikacija izmeu firmi i banaka odvija se putem web servisa i SOAP formata poruka i to Document/literal wrapped stila. (U Apache CXF dokumentaciji oni se nazivaju prosto Document/literal). Specifikacija servisa vri se pomou jezika WSDL, a specifikacija dokumenata koji se razmenjuju vri se pomou XML Schema jezika.

REST-bazirani web servisi. Komunikacija izmeu pojedinanih firmi (u ovom projektu svedena na razmenu faktura) odvija se putem REST-baziranih web servisa. Specifikacija dokumenata koji se razmenjuju, kao i u sluaju SOAP-baziranih web servisa, vri se uz pomo XML Schema jezika.

8 / 16

2.4. Backend aplikacija FirmeBackend aplikacija Firme predstavlja vieslojnu Java EE aplikaciju koja se sastoji iz slojeva prikazanih na sledeem dijagramu (Slika 1):

Aplikacioni sloj Firme treba realizovati kroz tri podsloja (persistence, data access i service layer), a detalji specifini za implementaciju su dati u nastavku.

1. Persistence layera) Predstavlja perzistencioni sloj aplikacije modelovan primenom JAXB tehnologije.b) Za potrebe predmetnog projekta neophodno je implementirati JAXB beanove koji

odgovaraju specifikaciji razmenjivanih poruka, prethodno iskazanih XML Schema jezikom.

2. Data access layera) Predstavlja srednji sloj aplikacije koji omoguava jednostavan pristup podacima

skladitenim u XML bazi podataka.b) Za potrebe predmetnog projekta data access sloj treba implementirati uz pomo SLSB

(Stateless Session Bean) komponenti, primenom EJB tehnologije.c) XML bazi podataka ne pristupati direktno iz SLSB komponenti, ve kroz API koji

enkapsulira REST komunikaciju sa serverom baze.

3. Service layer a) Predstavlja poslednji sloj aplikacije koji definie javno dostupan API implementiranih

funkcionalnosti.b) Za potrebe predmetnog projekta service sloj treba implementirati kao RESTful web servise,

upotrebom JAX-RS tehnologije.c) Specifikacija servisa je data u nastavku.

9 / 16

Slika 1: Troslojna arhitektura backend aplikacije

2.4.1. Specifikacija RESTful web servisaRazmenu faktura izmeu Firmi poslovnih partnera (u ulogama: dobavlja poslovni partner koji izdaje fakturu za isporuenu robu i usluge, i kupac poslovni partner kome je faktura namenjena) treba implementirati upotrebom JAX-RS tehnologije. Za potrebe predmetnog projekta, implementirati servis metode za sledee tipove HTTP zahteva i URL ablona:

1. POST /partneri//fakture/a) Omoguava slanje fakture servisu Firme poslovnog partnera za isporuenu robu i usluge. b) Parametar predstavlja adresu servisa poslovnog partnera koji prima fakuturu.c) Parametar predstavlja PIB poslovnog partnera koji izdaje fakturu.d) Ukoliko dati dobavljac jeste poslovni partner kupca, a faktura je validna i prihvaena,

odgovor je HTTP 201 Created, sa zaglavljem Content-Location: /partneri//fakture/ koje ukazuje na URL novokreirane fakture.

e) U sluaju da dobavlja nije poslovni partner kupca, odgovor je HTTP 403 Forbidden.f) U sluaju neispravne fakture, odgovor je HTTP 400 Bad Request.

2. GET /partneri//fakturea) Omoguava pribavljanje svih faktura koje je izdao dati dobavlja datom kupcu.b) Ukoliko dati dobavljac jeste poslovni partner kupca, odgovor je 200 OK sa kolekcijom

faktura u telu HTTP odgovora.c) U suprotnom sluaju odgovor je HTTP 404 Not Found.

3. GET /partneri//fakture/a) Omoguava pribavljanje date fakture datog dobavljaa. b) Parametar predstavlja identifikator fakture.c) Ukoliko dati dobavlja jeste poslovni partner kupca i postoji data faktura, odgovor je HTTP

200 OK sa konkretnom fakturom u telu HTTP odgovora.d) U suprotnom sluaju odgovor je HTTP 404 Not Found.

4. GET /partneri//fakture//stavkea) Omoguava pribavljanje svih stavki date fakture datog dobavljaa. b) Ukoliko dati dobavlja jeste poslovni partner kupca i postoji data faktura, odgovor je HTTP

200 OK, sa kolekcijom stavki u telu HTTP odgovora.c) U suprotnom sluaju odgovor je HTTP 404 Not Found.

5. POST /partneri//fakture//stavkea) Omoguava dodavanje nove stavke u okviru postojee fakture datog dobavljaa. b) Ukoliko dati dobavljac jeste poslovni partner kupca, a data faktura postoji, odgovor je

HTTP 201 Created, sa zaglavljem Content-Location: /partneri//fakture//stavke/ koje ukazuje na URL novododate stavke.

c) U sluaju da dobavlja nije poslovni partner kupca, odgovor je HTTP 403 Forbidden.d) U sluaju nepostojee fakture, odgovor je HTTP 404 Not Found.e) U sluaju neispravne stavke, odgovor je HTTP 400 Bad Request.

10 / 16

6. GET /partneri//fakture//stavke/a) Omoguava pribavljanje pojedinane stavke date fakture datog dobavljaa. b) Parametar predstavlja redni broj stavke u okviru fakture.c) Ukoliko dati dobavlja jeste poslovni partner kupca, a data stavka u okviru date fakture

postoji, odgovor je HTTP 200 OK sa konkretnom stavkom u telu HTTP odgovora.d) U suprotnom sluaju odgovor je HTTP 404 Not Found.

7. PUT /partneri//fakture//stavke/a) Omoguava izmenu postojee stavke u okviru date fakture datog dobavljaa. b) Ukoliko dati dobavljac jeste poslovni partner kupca, a data stavka u okviru date fakture

postoji, odgovor je HTTP 200 OK. c) U sluaju da dobavlja nije poslovni partner kupca, odgovor je HTTP 403 Forbidden.d) U sluaju nepostojee fakture ili stavke, odgovor je HTTP 404 Not Found.e) U sluaju neispravne stavke, odgovor je HTTP 400 Bad Request.

8. DELETE /partneri//fakture//stavke/a) Omoguava brisanje pojedinane stavke date fakture datog dobavljaa. b) Ukoliko dati dobavlja jeste poslovni partner kupca, a data stavka u okviru date fakture

postoji, odgovor je HTTP 204 No Content.c) U sluaju da dobavlja nije poslovni partner kupca, odgovor je HTTP 403 Forbidden.d) U suprotnom sluaju (faktura ili stavka ne postoji) odgovor je HTTP 404 Not Found.

Podatke o svim poslovnim partnerima, definisanim tabelarnom specifikacijom fakture u okviru poglavlja 1.1 (naziv, adresa, poreski identifikacioni broj PIB i brojevi rauna) kao i podatke o servisima poslovnih partnera (adresa servisa), takoe treba skladititi kao XML dokument u okviru XML baze podataka. Za jednog poslovnog partnera omoguiti postojanje vie rauna.

11 / 16

2.5. Frontend aplikacija FirmeKlijentsku aplikaciju Firme implementirati upotrebom AngularJS frontend tehnologije, koristei kljune JavaScript dizajn ablone (Revealing module i IIFE pattern). Klijentska aplikacija bi trebala da sadri barem one prikaze (view) koji su predstavljeni narednim dijagramom (Slika 2).

U okviru projektnog zadatka neophodno je implementirati po jedan prikaz koji demonstrira svaki od poziva servisa specificiranih u prethodnom poglavlju. Za upravljanje sadrajem prikaza koristiti AngularJS direktive. Realizovati jedan osnovni layout view iz koga e se referencirati ostali prikazi. Na slici 2 data je mapa sajta frontend aplikacije na kojoj su definisani osnovni view-ovi, kao i pravila navigacije izmeu razliitih prikaza. Za potrebe navigacije izmeu razliitih logikih stranica koristiti AngularJS modul ngRoute i ugraene servise koje on prua.

vorovi dijagrama predstavljaju HTML stranice, dok grane izmeu vorova predstavljaju veze od jednog do drugog prikaza. Zbog preglednosti dijagrama, povratne veze izmeu vorova dijagrama nisu prikazane, iako se, kao i veza na index.html stranicu, implicitno podrazumevaju iz svakog prikaza.

1. Index predstavlja poetnu stranicu klijentske aplikacije iz koje je mogue odabrati opcije za prikaz svih faktura koje su izdate datom kupcu, kao i opciju za slanje nove fakture.

2. Invoices stranica omoguava tabelarni prikaz sa mogunou filtriranja po sadraju, kao i sortiranje u opadajuem i rastuem poretku spram odabrane kolone.

3. Create invoice predstavlja stranicu zaduenu za unos i slanje nove fakture.

4. Invoice stranica omoguava detaljan prikaz konkretne fakture. Do ove stranice je mogue doi

12 / 16

Slika 2: Mapa frontend aplikacije

iz prikaza svih faktura, kao i nakon uspenog kreiranja tj. slanja fakture.

5. Items stranica prua tabelarni prikaz svih stavki date fakture. Za stavke fakture omoguiti opciju filtriranja sadraja, kao i sortiranja spram odabranog kriterijuma u oba smera. Sa ovog prikaza mogue je prei na prikaz pojedinane stavke, izvriti brisanje , prei na stranicu za izmenu, kao i dodavanje nove stavke u okviru date fakture.

6. Item stranica je zaduena za detaljan prikaz pojedinane stavke. Do ove stranice se osim iz prikaza svih stavki, dolazi i nakon uspenog dodavanja nove stavke u okviru date fakture.

7. Create item predstavlja stranicu zaduenu za unos i dodavanje nove stavke fakture.

8. Update stranica omoguava izmenu konretne stavke fakture.

U Invoices i Items prikazima, zaduenim za grupni prikaz svih faktura odnosno stavki, omoguiti filtriranje i sortiranje upotrebom AngularJS filtera. Za potrebe filtriranja svih faktura, kao i svih stavki date fakture, realizovati jedno polje za filtriranje po svim vrednostima. Za filtriranje svih faktura omoguiti jo i namenska polja za filtriranje po:

1. Iznosu za uplatu (manje, vee od, jednako unetoj vrednosti)2. Datumu rauna (pre, nakon unetog datuma)3. Datumu valute (pre, nakon unetog datuma)

Za filtriranje svih stavki date fakture omoguiti dodatna namenska polja za filtriranje po:

1. Nazivu robe ili usluge2. Jedinici mere3. Koliini (manje, vee od, jednako unetoj vrednosti)4. Ukupnom iznosu stavke umanjenom za rabat (manje, vee od, jednako unetoj vrednosti)

Kod sortiranja omoguiti sortiranje u oba smera spram odabranog kriterijuma tj. naziva kolone u tabeli prikaza svih faktura, odnosno prikaza svih stavki fakture.

Kontrolere implementirati modularno, potujui SoC (Separation of concerns) princip. Kontrolere grupisati po view-ovima, tako da svaki od kontrolera obrauje zaseban problem. Striktno potujui MVC ablon, u optem sluaju, jedan kontroler bi trebao da upravlja sadrajem jednog view-a, meutim u sluajevima kao to su prikazi za kreiranje i auriranje pojedinane stavke date fakture, opravdano je korienje istog kontrolera od strane vie razliitih prikaza.

Kako bi se rasteretila poslovna logika kontrolera, za potrebe pristupa REST API-u backend aplikacije Firme, implementirati AngularJS servise koji enkapsuliraju komunikaciju klijenta i RESTful web servisa tj. slanje HTTP zahteva i preuzimanje odgovora od servera.

2.6. Skladitenje podatakaKao skladite podataka koristi se native XML baza (kasnije e biti odreeno koja). Alternativno,

13 / 16

studenti koji pohaaju i predmet Poslovna informatika mogu (ali ne moraju) koristiti i relacionu bazu podataka sa emom baze koja je razvijena na tom predmetu.

3. Test scenarioPodaci za testiranje mogu se nalaziti u relacionoj bazi, XML bazi ili tekstualnim datotekama.

1. Fakture:

- Slanje ispravne fakture.

- Slanje fakture sa neisprvnom strukturom (XML ema nije validna).

- Slanje fakture sa neispravnim sadrajem, pri emu je struktura validna (npr. ukupna cena ne odgovara sumi pojedinanih cena).

- Slanje pogrene fakture (faktura je validna, ali nije namenjena za firmu kojoj je poslana).

2. Nalozi za plaanje:

- Slanje ispravnog naloga za plaanje:

a. plaanje na raun unutar iste banke

b. plaanje na raun druge banke

b.1. plaanje na raun druge banke sa iznosom veim od 250 000 RSD

b.2. plaanje na raun druge banke sa iznosom manjim od 250 000 RSD

- Slanje naloga za plaanje sa neispravnom strukturom (XML ema nije validna).

- Slanje naloga za plaanje sa neispravnim sadrajem, pri emu je struktura validna (npr. ukupan iznos ne odgovara sumi pojedinanih iznosa, iznos koji se plaa je vei od iznosa na raunu).

- Slanje neispravnog naloga za plaanje:

a. plaanje na raun unutar iste banke, ali raun ne postoji.

b. plaanje na raun druge banke, ali raun ne postoji.

c. plaanje na raun druge banke, banka ne postoji.

- Plaanje sa nelikvidnog rauna:

a. na raunu klijenta (nalogodavca) nema dovoljno novca za plaanje.

b. raun klijenta (nalogodavca) blokiran.

c. na obraunskom raunu banke nalogodavca kod CB nema dovoljno novca-prekoraen limit.

3. RTGS nalog:

Slanje ispravnog RTGS naloga (MT103).

Slanje RTGS naloga (MT103) sa neispravnim SWIFT kodom.

4. Clearing & Settlement nalog:

14 / 16

Slanje ispravnog clearing & settlement naloga (MT102).

Slanje clearing & settlement naloga (MT102) sa neispravnim SWIFT kodom.

Slanje clearing & settlement naloga (MT102) sa neispravnim ukupnim iznosom.

Slanje clearing & settlement naloga (MT102) sa raunima poverioca u razliitim bankama.

5. Izvodi:

Izvod postoji i ima jedan presek.

Izvod postoji i ima vie preseka.

Izvod ne postoji.

6. RESTful web servisi:

Sluaj slanja fakture u kome dati dobavljac jeste poslovni partner kupca.

Sluaj slanja fakture u kome dati dobavlja nije poslovni partner kupca.

Sluaj slanja nevalidne fakture.

Sluaj preuzimanja svih faktura u kome dati dobavlja jeste poslovni partner kupca.

Sluaj preuzimanja svih faktura u kome dati dobavlja nije poslovni partner kupca.

Sluaj preuzimanja fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj preuzimanja fakture u kome dati dobavlja nije poslovni partner kupca.

Sluaj preuzimanja nepostojee fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj preuzimanja stavki fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj preuzimanja stavki fakture u kome dati dobavlja nije poslovni partner kupca.

Sluaj preuzimanja stavki nepostojee fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj dodavanja stavke fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj dodavanja stavke fakture u kome dati dobavlja nije poslovni partner kupca.

Sluaj dodavanja stavke u nepostojeu fakturu u kome dati dobavlja jeste poslovni partner kupca.

Sluaj dodavanja nevalidne stavke u kome dati dobavlja jeste poslovni partner kupca.

15 / 16

Sluaj preuzimanja stavke fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj preuzimanja stavke fakture u kome dati dobavlja nije poslovni partner kupca.

Sluaj preuzimanja stavke nepostojee fakture ili nepostojee stavke fakture u kome dati dobavlja jeste poslovni partner kupca..

Sluaj izmene stavke fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj izmene stavke fakture u kome dati dobavlja nije poslovni partner kupca.

Sluaj izmene stavke nepostojee fakture ili nepostojee stavke fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj izmene stavke nevalidnom stavkom u kome dati dobavlja jeste poslovni partner kupca.

Sluaj brisanja stavke fakture u kome dati dobavlja jeste poslovni partner kupca.

Sluaj brisanja stavke fakture u kome dati dobavlja nije poslovni partner kupca.

Sluaj brisanja stavke nepostojee fakture ili nepostojee stavke fakture u kome dati dobavlja jeste poslovni partner kupca.

16 / 16

1. Komunikacija izmeu uesnika1.1. Slanje faktura1.2. Slanje naloga za plaanje1.3. Preuzimanje izvoda1.4. Meubankarski promet1.4.1. Meubankarski promet - RTGS1.4.1. Meubankarski promet Clearing & Settlement

2. Tehnike karakteristike servisa2.1. Struktura broja bankarskog rauna2.2. Struktura SWIFT koda banke2.3. Stil web servisa2.4. Backend aplikacija Firme2.4.1. Specifikacija RESTful web servisa2.5. Frontend aplikacija Firme2.6. Skladitenje podataka

3. Test scenario