Jan Matveus PROJEKTI „ÜHTSE EUROMAKSETE …enos.itcollege.ee/~lepikult/diplomitoo/naidistood/Matveus.pdf · REJ - Tagasilükatud SEPA kreeditkorraldus (O-le) - otseliikmele

EESTI INFOTEHNOLOOGIA KOLLEDŽ

Jan Matveus

PROJEKTI „ÜHTSE EUROMAKSETE PIIRKONNA KREEDITKORRALDUSTE

ANALÜÜS“ FIRMA X NÄITEL

Diplomitöö

INFOSÜSTEEMIDE ANALÜÜSI ÕPPEKAVA

Juhendaja: Alar Krist

Konsultant: Martin Luts

Tallinn 2009

2

Autorideklaratsioon

Deklareerin, et käesolev diplomitöö, mis on minu iseseisva töö tulemus, on esitatud Eesti

Infotehnoloogia Kolledž ile lõpudiplomi taotlemiseks infosüsteemide analüüsi erialal.

Diplomitöö alusel ei ole varem eriala lõpudiplomit taotletud.

Autor Jan Matveus ……………………….

(allkiri ja kuupäev)

Töö vastab kehtivatele nõuetele

Juhendaja Alar Krist …………………………

(allkiri ja kuupäev)

3

Sisukord

Autorideklaratsioon......................................................................................................... 2Sisukord .......................................................................................................................... 3Lühendite ja mõistete seletused ....................................................................................... 4Sissejuhatus..................................................................................................................... 61. Ülesande püstitus....................................................................................................... 102. Projekti taust.............................................................................................................. 11

2.1 Huvitatud pooled ................................................................................................. 112.2 Projekti skoop...................................................................................................... 11

3. Kasutatud tehnikad, notatsioon ja arendusvahendid ................................................... 133.1 Analüüsi meetodid ............................................................................................... 133.2 Arhitektuuri meetodid.......................................................................................... 13

4. Lahenduse kirjeldus................................................................................................... 144.1 Ärianalüüsi tulemused ......................................................................................... 14

4.1.1 Ärinõuete analüüs ......................................................................................... 144.1.2 Äriprotsess.................................................................................................... 15

4.2 Süsteemianalüüsi tulemused ................................................................................ 264.2.1 Funktsionaalsed nõuded ................................................................................ 274.2.2 Kasutuslood .................................................................................................. 284.2.3 Mittefunktsionaalsed nõuded......................................................................... 34

4.3 Disaini ja arhitektuuri tulemused.......................................................................... 354.3.1 Valdkonnamudel ........................................................................................... 354.3.2 Klassimudel .................................................................................................. 364.3.3 Andmemudel ................................................................................................ 384.3.4 Arhitektuurimudelid ...................................................................................... 44

5. Kokkuvõte ja järeldused ............................................................................................ 46Kasutatud kirjandus ....................................................................................................... 47Lisad ............................................................................................................................. 47

Lisa X. Detailse kasutusloo näide .......................................................................... 47Lisa X. Väljuva SEPA XML sõnumi olekudiagramm ............................................ 52Lisa X. Saabuva SEPA XML sõnumi olekudiagramm ........................................... 53Lisa X. Andmetabelite kirjeldused ......................................................................... 53

4

Lühendite ja mõistete seletused

Lühend või mõiste Seletus

EPC European Payments Council – Euroopa Maksenõukogu, mis

koostab euromaksetele uusi reegleid.

Eurosüsteem Eurosystem - Euroopa Keskpank ja euroala riikide keskpangad:

vastutab euroala maksesüsteemide tõrgeteta toimimise eest

SEPA Single Euro Payments Area – ühtne euromaksete piirkond, kus

tarbijad, ettevõtted ja teised majandusagendid saavad asukohast

olenemata teha ja vastu võtta riigisiseseid ja piiriüleseid

euromakseid, kasutades ühtseid makseviise ja lähtudes ühtsetest

tingimustest, õigustest ja kohustustest. Liikmed: EL liikmesriigid

+ Island, Liechtenstein, Monaco, Norra ja Šveits.

SEPA skeem SEPA Scheme – konkurentslikus keskkonnas pankadevahelisel

tasemel kokkulepitud SEPA makseviiside määratlemiseks ja

toimimiseks vajalike ärireeglite, tavade ja standardite kogum.

SEPA

kreeditkorraldusskeem

SEPA Credit Transfer Scheme – SEPA kreeditkorraldusskeem

on ühtsetel eeskirjadel põhinev pankadevaheline makseskeem,

mis töötleb eurodes algatatud kreeditkorraldusi. Selles on

määratletud teenuste ühtne tase ja ajakava, millele vastavalt

süsteemis osalev finantseerimisasutus peab kreeditkorralduse

sooritama.

5

Kreeditkorraldus Credit Transfer - kreeditkorraldus on maksja algatatud makse.

Maksja (saaja) panka saadetakse maksekorraldus, millega

antakse vahendid maksja (saaja) panga käsutusse. See võib

toimuda mitme vahendaja kaudu.

Kliiring Clearing – arveldusele eelnev protsess, mis tegeleb

maksekorralduste edastamise, sobitamise ja kinnitamisega. Võib

sisaldada ka maksekorralduste ühildamist ja arveldusele lõpliku

positsiooni määramist.

PE-ACH Pan-European Automated Clearing House – üleeuroopaline

automatiseeritud arvelduste koda: juhtimisreeglitele, maksete

tavadele ning vajalikule tehnilisele platvormile toetuv euro

makseviiside äriplatvorm.

SWIFT

BIC Bank Identifier Code – SWIFTi poolt väljaantav 8 või 11

kohaline ISO kood identifitseerimaks finantstoimingutes

osalevat finantsasutust.

6

Sissejuhatus

Käesoleva töö eesmärk on anda ülevaade autori poolt läbiviidud analüüsist ühtse

euromaksete piirkonna kreeditkorralduste skeemiga liitumiseks, kirjeldades loodavale

süsteemile esitatavaid nõudeid ja analüüsi tulemusena tehtud otsuseid.

Pangasektor käivitas ühtse euromaksete piirkonna (Single Euro Payments Area (SEPA))

projekti 2002. aastal, asutades Euroopa Maksenõukogu (European Payments Council

(EPC)). Põhjuseks erinevused makseviisides, standardites ja jaemaksete töötlemisel

euroala piires. Jaemakseteenuste turgude killustatus takistas uuenduste levikut ja

konkurentsi euroalal, mõjutades lisaks piiriülestele maksetele ka riigisiseste euromaksete

tegemist. Lisaks olid eri riikides kehtestatud erinevad eeskirjad ja nõuded. Eesmärgiks oli

luua ühtne raamistik, mis koondab endasse euromakseid käsitlevad ühtsed eeskirjad,

tavad ja standardid kogu euroalal kasutatavate makselahenduste jaoks, et edendada

Euroopa lõimumist konkurentsivõimelise ja uuendusliku euroala jaemakseteenuste turu

kaudu, kus pakutakse paremat teenusekvaliteeti, tõhusamaid tooteid ning soodsamaid

maksevõimalusi.

Eurosüsteemis loetakse SEPA looduks, kui kõiki euroalal eurodes tehtavaid makseid

käsitletakse riigisiseste maksetena ning riigisiseseid ja piiriüleseid makseid enam ei

eristata. Eurosüsteemi huvi SEPA projekti ja maksesüsteemide üldise lõimimise vastu

tuleneb Euroopa Ühenduse asutamislepingus sätestatud eurosüsteemi ülesandest

edendada maksesüsteemide tõrgeteta toimimist ja tagada finantsstabiilsus.

Eurosüsteemi põhieesmärgiks on kaotada kõik tehnilised, õiguslikud ja ärilised tõkked

praeguste riigisiseste makseturgude vahel ning:

teha SEPA kreedit- ja otsekorralduste skeemid kättesaadavaks kõikidele

kasutajatele,

7

kõrvaldada tehnilised tõkked, mis takistavad maksekaartide piiriülest piiranguteta

kasutamist, ning

tagada, et makseid on võimalik teha terve euroala piires.

Eurosüsteem eeldab, et pikema aja jooksul hakkavad kõik euroala riikide vahelised

maksed toimima sisemaksetena ning neid saab teostada sama turvaliselt ja tõhusalt nagu

praegustes parimates riigisisestes süsteemides. Asjaomased osapooled saavad teha hästi

informeeritud valikuid erinevate SEPA piiriüleste makseviiside vahel. Klientidel on

võimalus ise otsustada, milliseid panku, maksekaarte ja otsekorraldusi kasutada. Ka

finantseerimisasutused valivad ise sobivad maksesüsteemi infrastruktuuri pakkujad ja

kaartide töötlejad. Luues euroalast integreeritud turu, suurendab SEPA konkurentsi ja

võimaldab teenuseosutajatel oma teenuseid pakkuda kogu euroalal.

Euroopa Maksenõukogu on määratlenud kaks makseskeemi – SEPA kreedit- ja

otsekorralduse – ning SEPA kaardimaksete raamistiku. Need SEPA makseviisid

asendavad järk-järgult praegusi riigisiseseid makseviise.

SEPA kreeditkorraldusskeem on ühtsetel eeskirjadel põhinev pankadevaheline

makseskeem, mis töötleb eurodes algatatud kreeditkorraldusi. Selles on määratletud

teenuste ühtne tase ja ajakava, millele vastavalt süsteemis osalev finantseerimisasutus

peab kreeditkorralduse sooritama. SEPA kreeditkorraldussüsteemi põhijooned

Süsteem on kättesaadav kogu SEPA piirkonnas.

Kogu summa krediteeritakse saaja kontole.

Makse suurus ei ole piiratud.

Pankadevaheline maksimaalne arveldusaeg on kaks tööpäeva, saaja arvele

debiteerimist reguleerib makseteenuste direktiiv (Payment Service Directive

(PSD))

Süsteem on eraldatud töötlemise infrastruktuurist.

Konto tunnustena kasutatakse IBANit ja BICi.

Maksete tagasilükkamist ja tagastamist reguleerib ulatuslik eeskirjade kogum.

8

SEPA kreeditkorraldusskeemi osapooli ja nendevahelist suhtlemist kirjeldav

kontekstidiagramm:

class Context Diagram - otseste ja kaudsete liikmete v ahel

Kreeditkorralduse algatus

Kreeditkorralduse vastuvõtt, arveldusedKreeditkorralduse registreerimine, arveldused

Kli iring & arveldamine

PE-ACH

Maksja

Maksja pank (kaudne liige)

Maksja panga otseliige

Saaja panga otseliige

Saaja pank (kaudne liige)

Saaja

Legend:SCT - SEPA kreedi tkorraldusRET - Tagastatud SEPA kreeditkorraldusREJ - Tagasilükatud SEPA kreeditkorraldus(O-le) - otseliikmele(O-lt) - otseli ikmelt(K-le) - kaudsele l i ikmele(K-lt) - kaudsel t li ikmel t

Maksja pank (otsene liige)

Saaja pank (otsene liige)

RET (K-le)«flow»

«flow»

SCT (K-lt)

«flow»

SCT (K-lt)«flow»

«flow»

SCT (K-le)«flow»

SCT (K-le)«flow»

SCT (O-lt)

«flow»

«flow» «flow»

Soov saajale raha kanda

«flow»

RET (O-le)«flow»

RET (K-lt)«flow»

RET (O-lt)«flow»

RET (K-lt)«flow»

RET (K-le)

«flow»

REJ (K-le)«flow»

REJ (K-le)

«flow»

REJ (O-le)

«flow»

SCT (O-le)«flow»

Joonis 0-1. Kontekstidiagramm

Käesolevas töös kirjeldatakse ainult ühe ja esimesena käikuläinud makseskeemi – SEPA

kreeditkorraldusskeemi – kasutuselevõttu firma X näitel.

Autori poolt läbi viidud töö hõlmas SEPA kreeditkorraldusskeemiga liitumiseks vajalike

nõuete selgitamist ja analüüsi, vajalike infrastruktuuri muudatuste kirjeldamist ning

andmemudeli koostamist. Autor on osalenud süsteemianalüütiku ja tarkvaraarendaja rollis

samalaadse projekti realiseerimisel, mis on kasutusel alates 28. jaanuarist, 2008.

Esimene peatükk kirjeldab ülesande püstitust.

9

Teine peatükk annab ülevaate projekti taustast.

Kolmas peatükk annab ülevaate analüüsi käigus kasutatud tehnikatest, notatsioonist ning

arendusvahenditest.

Neljas peatükk annab ülevaate analüüsi ja disaini tulemustel põhinevast lahendusest,

kirjeldades muutunud äriprotsessi ja –reegleid, uue süsteemikomponendi kasutuslugusid

ning arhitektuuri.

Viies peatükk teeb kokkuvõtte ning esitab järeldused tehtud töö kohta.

Töö sisaldab ka ingliskeelset sisukokkuvõtet.

Töö autor soovib tänada lõputöö juhendajat ja konsultanti konstruktiivse tagasiside ja

nõuannete eest, mis aitasid oluliselt kaasa töö valmimisele.

10

1. Ülesande püstitus

Firma X näol on tegemist suuremasse ettevõtete gruppi kuuluva finantsasutusega, kelle

igapäevaste tööülesannete hulka kuulub muuhulgas ka oma klientide kreeditkorralduste

vahendamine. Kuna emafirma on otsustanud liituda SEPA kreeditkorraldusskeemiga, et

pakkuda oma klientidele odavamat, kiiremat ja turvalisemat kreeditkorralduste töötlust ja

samaaegselt saada ise kasu erinevate maksesüsteemide infrastruktuuride pakkujate

konkurentsivõitlusest ning olla esirinnas Euroopa innovaatiliste finantsasutuste seas, siis

laienes see liitumisnõue ka tütarfirmadele. Kuna firma X poolt töödeldavate

kreeditkorralduste hulk ja nendelt teenitava kasumi osakaal on märkimisväärselt suur, siis

tekkis vajadus olemasoleva välismaksete töötlemise süsteemi täiustamise järele, et mitte

kaotada olulist turuosa.

Töö eesmärgiks oli välja selgitada SEPA kreeditkorralduste vahendamiseks ja

töötlemiseks vajalik funktsionaalsus. Töö autor täitis süsteemianalüütiku rolli.

Analüüsi esimeseks ülesandeks oli loodavale süsteemile esitatavate nõuete

väljaselgitamiseks EPC poolt väljaantud SEPA reeglistikku (Rulebook) ja selle

rakendusjuhiseid (Implementation Guidelines) kajastavate dokumentide läbitöötamine.

Teiseks ülesandeks oli välja selgitada süsteemi osapooled, nende kirjeldused ja

vastastikused nõuded.

Kolmandaks ülesandeks oli nõudeid rahuldavate kasutuslugude kirjelduste koostamine ja

tähtsaimate äriobjektide elutsüklite kirjeldamine.

Neljandaks ülesandeks oli kasutuslugudes kirjeldatud funktsionaalsuse realiseerimist

toetava detailse andmemudeli loomine.

11

2. Projekti taust

Projektile eelnes emafirma ja tütarfirmade esindajatest koosnevate töögruppide tihe

koostöö selgitamaks välja SEPA kreeditkorraldusskeemiga liitumise mõju ja vajalike

seotud projektide hulka ja nende eesmärke. Seotud projektidest võib nimetada muudatusi

emafirma süsteemides ja grupiüleselt kasutatavates kreedikorralduste töötlemise

süsteemides.

2.1 Huvitatud pooled

Tabel 2-1Projekti osapooled, esindatud huvid ja osalus projektis

Osapool Huvi Osalus

Emafirma Tagada kogu grupi valmisolekProjekti kontroll ja seotud projektide

koordineerimineTütarfirma

XProjekti teostus

Teised tütarfirmad

Saavutada enda valmisolek SEPA kreeditkorraldusskeemiga

liitumiseksProjekti toetamine, ressursside eraldamine loodava süsteemi

kasutuselevõtuks

2.2 Projekti skoop

Projekti skoobi määratlemisel lepiti kokku, et realiseeritakse ainult miinimumnõuded

SEPA kreeditkorraldusskeemile vastavuse täitmiseks ehk vaadeldakse ainult kohustuslike

andmehulkade kasutust pankadevahelistes sõnumites. Sealhulgas otsustati, et tütarfirmad

osalevad SEPAs kaudse liikmena ja emafirma otseliikmena, mis tähendab vastutuse

võtmist kogu ettevõtete grupi kreeditkorralduste vahendamise korrektsuse eest. See

tähendab, et tütarfirmade hooleks jääb üksikute kreeditkorralduste vahendamine oma

klientide ja emafirma vahel, kes omakorda hoolitseb kõikide kreeditkorralduste kogumise

ja nõuetekohase SEPA infrastruktuuridele edastamise eest. Selline lahendus vähendab

tütarfirmadesse täisfunktsionaalse süsteemi juurutamise ja kasutamisega seotud kulusid,

tagades samaaegselt tütarfirmades kasutatava lihtsustatud süsteemi taaskasutatavust.

12

Projekti käigus ei vaadelda täpsemalt nõudmisi kreeditkorralduste töötlemise süsteemile

ja emafirma sõnumifailide töötlejale ega täpsustata nende kasutuslugusid. Käsitletud ei

ole SEPAs võimalike lisaväärtusväljade (Additional Optional Services (AOS)) kasutamist

(vaadeldakse ainult miinimumnõudeid) ja SEPAs osalevate liikmete kataloogi (SEPA

Directory) kasutamist (kreeditkorralduste töötlemise süsteemi muudatuste projekti osa).

13

3. Kasutatud tehnikad, notatsioon ja arendusvahendid

3.1 Analüüsi meetodid

3.2 Arhitektuuri meetodid

14

4. Lahenduse kirjeldus

Esialgse analüüsi aluseks oli avalik SEPA kreeditkorraldusskeemi reeglistiku versioon 3.2

(SEPA Credit Transfer Scheme Rulebook, EPC125-05), mis oli kinnitatud EPC täiskogu

poolt 24. juunil 2008 ja kehtis ametlikult 02. veebruarist 2009 kuni 01. novembrini 2009,

ning sellejuurde kuuluvad pankadevahelised rakendusjuhised (SEPA Credit Transfer

Scheme Inter-bank Implementation Guidelines, EPC115-06). Analüüsi lõppversioonis on

arvestatud ka uue reeglistiku versiooni 3.3 (kinnitatud EPC täiskogu poolt 30. oktoobril

2009 ja kehtib ametlikult alates 02. novembrist 2009) ja selle rakendusjuhistes kajastatud

muudatustega.

4.1 Ärianalüüsi tulemused

4.1.1 Ärinõuete analüüs

SEPA kreeditkorraldusskeemi reeglistiku analüüsimise käigus selgusid SEPA

kreeditkorralduste töötlemisele esitatud ärinõuded nagu näidatud alljärgneval joonisel:

req Business Requirements

Ärinõuded

+ BUSREQ01: SEPA li ige peab olema kättesaadav läbi PEACH'i

+ BUSREQ02: SEPA li ige peab olema võimeline töötlema väljuvat SEPA kreeditkorraldust

+ BUSREQ03: SEPA li ige peab olema võimeline töötlema tagastamisele kuuluvat saabunud SEPA kreeditkorraldust

+ BUSREQ04: SEPA li ige peab olema võimeline töötlema saabunud SEPA kreeditkorralduse tagastust

+ BUSREQ05: SEPA li ige peab olema võimeline töötlema saabunud SEPA kreeditkorraldust

+ BUSREQ06: SEPA li ige peab olema võimeline töötlema saabunud tagasilükatud SEPA kreeditkorraldust

(from SEPA vastavuse miinimumnõuded)

Joonis 4-1. Ärinõuded

15

BUSREQ01: SEPA liige peab olema kättesaadav läbi PE-ACH'i - SEPAs

osaleja peab olema kõikidele teistele liikmetele kättesaadav läbi kliiring- ja

arveldussüsteemi(de), kas kaudse või otseliikmena.

BUSREQ02: SEPA liige peab olema võimeline töötlema väljuvat SEPA

kreeditkorraldust - SEPAs osaleja peab olema võimeline maksja kliendilt vastu

võtma SEPA tingimustele vastavat kreeditkorraldust ja edastama saaja pangale

läbi SEPA võrgustiku.

BUSREQ03: SEPA liige peab olema võimeline töötlema tagastamisele

kuuluvat saabunud SEPA kreeditkorraldust - SEPAs osaleja peab olema

võimeline töötlema kliendile saabunud SEPA kreeditkorraldust, kui seda pole

võimalik saajale edastada, tagastama maksja pangale läbi SEPA võrgustiku.

BUSREQ04: SEPA liige peab olema võimeline töötlema saabunud SEPA

kreeditkorralduse tagastust - SEPAs osaleja peab olema võimeline töötlema

SEPA võrgustikust saabunud esialgselt kliendilt vastuvõetud ja edastatud, kuid

tagastatud SEPA kreeditkorraldust.

BUSREQ05: SEPA liige peab olema võimeline töötlema saabunud SEPA

kreeditkorraldust - SEPAs osaleja peab olema võimeline töötlema läbi SEPA

võrgustiku kliendile saabunud SEPA kreeditkorraldust.

BUSREQ06: SEPA liige peab olema võimeline töötlema saabunud

tagasilükatud SEPA kreeditkorraldust - SEPAs osaleja peab olema võimeline

töötlema läbi SEPA võrgustiku saabunud esialgselt kliendilt vastuvõetud ja

edastatud, kuid tagasilükatud SEPA kreeditkorraldust.

Väljaselgitatud nõuete mõju äriprotsessile on kirjeldatud alljärgnevas punktis.

4.1.2 Äriprotsess

Kreeditkorralduste töötlemisel eristatakse kahte protsessi: väljuvate kreeditkorralduste

töötlus ja laekuvate kreeditkorralduste töötlus. Järgnevalt on ära toodud mõlema protsessi

üldkirjeldus, nendesse planeeritud muudatused ning muudatusi põhjustanud nõuete

seosed.

Äriprotsessi kirjeldavatel joonistel on kasutatud järgnevat värvilegendi:

16

BPMN Legend

Muutunud protsessi osa

Lisandunud protsessi osa

Mittemuutunud protsessi osa

Legend

Joonis 4-2. Äriprotsessijoonistel kasutatav värvilegend

Väljuva kreeditkorralduse töötlusVäljuva kreeditkorralduse töötlemise äriprotsess on kujutatud alljärgneval joonisel:

BPMN Väljuv a kreeditkorralduse töötl...

Ma

ks

ja p

an

k

«P

oo

l»

Ma

ks

ja

«P

oo

l»

Kreeditkorraldus kliendilt

Töötle väl juvkreeditkorraldus

Väärtuspäeval

Debi teeri maksjakontolt

Edastakreedi tkorraldussaaja pangale

Väljuvkreeditkorraldus

töödeldud

Makse tagastatud

Makse tagasilükatud

Ajal imiidi möödumisel

Töötle tagastatudkreeditkorraldus

Töötle tagasilükatudkreeditkorraldus

Kanna saajale raha

Täidakreedi tkorralduse

andmed

Edastakreedi tkorraldusmaksja pangale

Kreeditkorraldus edastatud

Teavita klientikreeditkorralduse

töölemisetulemusest

Joonis 4-3. Väljuva kreeditkorralduse töötlus

Väljuv kreeditkorraldus saab alguse maksja soovist kanda saajale raha, millest ajendatuna

täidetakse kreeditkorralduse andmed ning edastatakse need maksja pangale. Edastatud

kreeditkorraldust võidakse kindlaks määratud aja jooksul tagastada või tagasi lükata.

Töötle väljuv kreeditkorraldusMaksja panka kliendilt saabunud kreeditkorraldus registreeritakse, määratakse

makseteekond saaja pangani ja määratakse väärtuspäev, millal toimub kreeditkorralduse

summa debiteerimine maksja kontolt ja kreeditkorralduse edastamine saaja pangale.

Muudatus protsessis

17

Kreeditkorralduse vastavusel SEPA tingimustele määratakse kreeditkorralduse

makseteekond läbi SEPA võrgustiku, tavapärase SWIFT võrgustiku asemel. SEPA

tingimustele vastab kreeditkorraldus, kui

Maksevaluuta on euro

Maksetüüp on tavaline või kiir

Kulutüüp on jagatud

Saaja arve on esitatud IBAN formaadis

Saaja panga tunnus on esitatud BIC formaadis

Saaja pank on SEPA võrgustiku kaudu kättesaadav

Muudetud protsessi kirjeldab alljärgnev joonis:

18

BPMN Töötle v älj uv kreeditkorrald...

Vastab SEPA tingimustele?

Määra SEPAmakseteekond

Määra SWIFTmakseteekond

Määrakreeditkorralduse

väärtuspäev

Kontrol likreeditkorraldusevastavust SEPA

tingimustele

SEPA kreedi tkorraldusskeemi reeglistik v3.2

notes- valuuta = euro (EUR)- tüüp = tavaline (N), kii r (U)- kulud = jagatud (SHA)- saaja arve = IBAN- saaja pank = BIC- saaja pank on SEPA kaudu kättesaadav

«trace»

JAH EI

Joonis 4-4. Töötle väljuv kreeditkorraldus

Debiteeri maksja kontoltVäärtuspäeva saabumisel debiteeritakse maksja kliendi kontolt kreeditkorralduse ja

maksja panga teenustasu summa.

Edasta kreeditkorraldus saaja pangalePeale kliendi konto debiteerimist koostatakse vastavalt kreeditkorralduse

makseteekonnale pankadevahelised sõnumid.

Muudatus protsessis

Kreeditkorralduse vastavusel SEPA tingimustele saadetakse kreeditkorraldus läbi SEPA

võrgustiku, tavapärase SWIFT võrgustiku asemel. Muudetud protsessi kirjeldab

alljärgnev joonis:

19

BPMN Edasta kreeditkorraldus saaja pangale

Makseteekond?

Edastakreedi tkorraldus läbi

SEPA

Edastakreeditkorraldus läbi

SWIFTi

BUSREQ02: SEPA li ige peab olema võimeline töötlema väl juvat SEPA kreeditkorraldust

(from Ärinõuded) SWIFTSEPA

Joonis 4-5. Edasta kreeditkorraldus saaja pangale

Käesolevas töös vaadeldakse, kuidas tegevus ’Edasta kreeditkorraldus läbi SEPA’

realiseerib nõuet ’BUSREQ02: SEPA liige peab olema võimeline töötlema väljuvat

SEPA kreeditkorraldust’.

Töötle tagastatud kreeditkorraldusEnne ajalimiidi möödumist on saaja pangal määratud põhjustel õigus temale edastatud

kreeditkorraldus tagastada maksja pangale. SEPA kreeditkorralduse tagastust on võimalik

teha kolme pangapäeva jooksul alates kreeditkorralduse väärtuspäevast. SEPA

kreeditkorraldusskeemiga määratud põhjuste nimekiri on toodud lisas X.

Tagastatud kreeditkorralduse töötlemisel loetakse selle andmed saabunud

pankadevahelisest sõnumist, seostatakse see algselt saadetud kreeditkorraldusega,

vajadusel kontrollitakse andmete vastavust ning krediteeritakse kreeditkorralduse summa

tagasi kliendi kontole.

Muudatus protsessis

Kreeditkorralduse tagastust sisaldav saabunud pankadevaheline sõnum võib tulla nüüd ka

SEPA võrgustikust, lisaks tavapärasele SWIFT võrgustikule. Sõnumist tagastatud

kreeditkorralduse andmete lugemine peab õnnestuma pärituoluvõrgustikust olenemata.

Muudetud protsessi kirjeldab alljärgnev joonis:

20

BPMN Töötle tagastatud kreeditkorraldus

Tagastatud kreeditkorraldus saajapangalt

Valideeri tagastatudkreeditkorraldus

- originaal kreeditkorraldusega seostamine- andmete kontroll

Krediteeri kl iendikontole

Makseteekond?

Loe SEPAstsaabunud

kreeditkorraldusetagastuse andmed

Loe SWIFTistsaabunud

kreeditkorraldusetagastuse andmed

BUSREQ04: SEPA l i ige peab olema võimeline töötlema saabunud SEPA kreeditkorralduse tagastust


Joonis 4-6. Töötle tagastatud kreeditkorraldus

Käesolevas töös vaadeldakse, kuidas tegevus ’Loe SEPAst saabunud kreeditkorralduse

tagastuse andmed’ realiseerib nõuet ’BUSREQ04: SEPA liige peab olema võimeline

töötlema saabunud SEPA kreeditkorralduse tagastust’.

21

Töötle tagasilükatud kreeditkorraldusEnne ajalimiidi möödumist on sõnumeid vahendava(te)l võrgustiku liikme(te)l määratud

põhjustel õigus temale edastatud kreeditkorraldus tagasi lükata. SEPA kreeditkorralduse

tagasilükkamist on SEPA infrastruktuuri kuuluva(te)l kliiring- ja arveldussüsteemi(de)l

võimalik teha hiljemalt järgmise pangapäeva jooksul alates kreeditkorralduse sõnumi

kättesaamisest. SEPA kreeditkorraldusskeemiga määratud põhjuste nimekiri on toodud

lisas X.

Tagasilükatud kreeditkorralduse töötlemisel loetakse selle andmed saabunud

pankadevahelisest sõnumist, seostatakse see algselt saadetud kreeditkorraldusega,

vajadusel kontrollitakse andmete vastavust, korrastatakse ning edastatakse uuesti.

Korrastatud kreeditkorraldus edastatakse täiesti uue sõnumina.

Muudatus protsessis

Tagasilükatud kreeditkorraldust sisaldav saabunud pankadevaheline sõnum võib tulla

nüüd ka SEPA võrgustikust, lisaks tavapärasele SWIFT võrgustikule. Sõnumist

tagasilükatud kreeditkorralduse andmete lugemine peab õnnestuma päritoluvõrgustikust

olenemata. Muudetud protsessi kirjeldab alljärgnev joonis:

22

BPMN Töötle tagasilükatud kreeditkorraldus

Tagasilükatud kreeditkorraldusSEPA infrastruktuurist

Makseteekond?

Loe SEPAstsaabunud

tagasi lükatudkreeditkorralduse

andmed


tagasilükatudkreeditkorralduse

andmed

Valideeritagasi lükatud

kreeditkorraldus

- originaal kreeditkorraldusega seostamine- andmete kontrol l

Korrastakreeditkorralduse

andmed

- kreeditkorralduse tagasi lükkamise põhjus on tavaliselt tehni l ist laadi- vajadusel tuleb muuta * makseteekonda * väärtuspäeva

Edastakreeditkorraldussaaja pangale

BUSREQ06: SEPA l i ige peab olema võimeline töötlema saabunud tagasilükatud SEPA kreeditkorraldust

(from Ärinõuded)

SWIFTSEPA

Joonis 4-7. Töötle tagasilükatud kreeditkorraldus

Käesolevas töös vaadeldakse, kuidas tegevus ’Loe SEPAst saabunud tagasilükatud

kreeditkorralduse andmed’ realiseerib nõuet ’BUSREQ06: SEPA liige peab olema

võimeline töötlema saabunud tagasilükatud SEPA kreeditkorraldust’.

Teavita klienti kreeditkorralduse töötlemise tulemusestKreeditkorralduse töötlemise lõppedes teavitatakse klienti töötlemise tulemusest selleks

ettenähtud korras.

23

Saabuva kreeditkorralduse töötlusSaabuva kreeditkorralduse töötlemise äriprotsess on kujutatud alljärgneval joonisel:

BPMN Saabuva kreeditkorralduse töötl...

Ma

ks

ja p

an

k

«P

oo

l»

Sa

aja

«P

oo

l»

Sa

aja

pa

nk

«P

oo

l»

Kreedi tkorraldusmaksja pangalt

Töötle saabunudkreeditkorraldus

Väärtuspäeval

Kredi teeri saajakontole

Saabunudkreeditkorraldus

töödeldud

Vormistakreeditkorralduse

tagastus

Edastakreeditkorraldusetagastus maksja

pangaleSaabunud kreeditkorraldus

tagastatud maksjapangale

Teavita klientisaabunud

kreeditkorraldusest

Kreedi tkorraldust polevõimal ik saajale edastada

Saabunud kreeditkorraldusedukalt töödeldud

Joonis 4-8. Saabuva kreeditkorralduse töötlus

Saabuva kreeditkorralduse töötlemise protsess algab kui saaja pangani on jõudnud

kreeditkorraldus maksja pangalt. Saabunud kreeditkorraldus võidakse edastada saajale või

tagastada maksja pangale.

Töötle saabunud kreeditkorraldusSaabunud kreeditkorralduse töötlemisel loetakse selle andmed saabunud

pankadevahelisest sõnumist, kontrollitakse kreeditkorralduse täitmise võimalikkust (saaja

on panga klient, kliendi arve ei ole suletud, toimingud kliendi arvega ei ole keelatud, jne)

ning määratakse väärtuspäev, millal toimub kreeditkorralduse summa krediteerimine

kliendi kontole. Kui kreeditkorraldust pole võimalik saajale edastada, suunatakse see

tagastatavaks.

Muudatus protsessis

Kreeditkorraldust sisaldav saabunud pankadevaheline sõnum võib tulla nüüd ka SEPA

võrgustikust, lisaks tavapärasele SWIFT võrgustikule. Sõnumist kreeditkorralduse

andmete lugemine peab õnnestuma päritoluvõrgustikust olenemata. Muudetud protsessi

kirjeldab alljärgnev joonis:

24

BPMN Töötle saabunud kreeditkorraldus

Makseteekond?

Loe SEPAstsaabunud

kreeditkorralduseandmed


kreeditkorralduseandmed

Kontroll ikreeditkorralduse

täi tmise võimalikkust

Kreeditkorralduston võimalik täita?

Määrakreeditkorralduse

väärtuspäev

Saabunud kreeditkorraldus edukalt töödeldud

Suunakreeditkorraldus

tagastuse töötluseks

Kreeditkorraldust polevõimalik saajale

edastada

BUSREQ05: SEPA li ige peab olema võimeline töötlema saabunud SEPA kreeditkorraldust

(from Ärinõuded)

- saajaks märgitud kliendi leidmine- kl iendi arvele krediteerimise lubatuse kontrolljne

EI

JAH

SWIFTSEPA

Joonis 4-9. Töötle saabunud kreeditkorraldus

Käesolevas töös vaadeldakse, kuidas tegevus ’Loe SEPAst saabunud kreeditkorralduse

andmed’ realiseerib nõuet ’BUSREQ05: SEPA liige peab olema võimeline töötlema

saabunud SEPA kreeditkorraldust’.

Krediteeri saaja kontoleVäärtuspäeva saabumisel krediteeritakse saaja kliendi kontole kreeditkorralduse summa.

Saaja panga teenustasu küsitakse hiljem eraldi.

Teavita klienti saabunud kreeditkorraldusestKreeditkorralduse töötlemise lõppedes teavitatakse klienti saabunud kreeditkorraldusest

selleks ettenähtud korras.

25

Vormista kreeditkorralduse tagastusKui kreeditkorraldust pole võimalik saajale edastada, tagastatakse see maksja pangale.

SEPA kreeditkorralduse tagastust on võimalik teha kolme pangapäeva jooksul alates

kreeditkorralduses märgitud väärtuspäevast. Saabunud kreeditkorralduse andmete põhjal

vormistatakse uus väljuv kreeditkorralduse tagastus. Tagastusele tuleb märkida selle

põhjus. SEPA kreeditkorraldusskeemiga määratud põhjuste nimekiri on toodud lisas X.

Muudatus protsessis

SEPA kreeditkorralduse tagastuse puhul peab põhjus olema valitud määratud nimekirjast.

Edasta kreeditkorralduse tagastus maksja pangalePeale kreeditkorralduse tagastuse vormistamist koostatakse vastavalt kreeditkorralduse

makseteekonnale pankadevahelised sõnumid.

Muudatus protsessis

SEPA kreeditkorralduse tagastuse korral saadetakse see läbi SEPA võrgustiku, tavapärase

SWIFT võrgustiku asemel. Muudetud protsessi kirjeldab alljärgnev joonis:

BPMN Edasta kreeditkorralduse tagastus maksja pangale

Tagastatava kreeditkorraldusemakseteekond?

Edastakreeditkorralduse

tagastus läbi SEPA

Edastakreedi tkorralduse

tagastus läbi SWIFTi

BUSREQ03: SEPA li ige peab olema võimeline töötlema tagastamisele kuuluvat saabunud SEPA kreeditkorraldust


Joonis 4-10. Edasta kreeditkorralduse tagastus maksja pangale

Käesolevas töös vaadeldakse, kuidas tegevus ’Edasta kreeditkorralduse tagastus läbi

SEPA’ realiseerib nõuet ’BUSREQ03: SEPA liige peab olema võimeline töötlema

tagastamisele kuuluvat saabunud SEPA kreeditkorraldust’.

26

Kättesaadavus läbi PE-ACHiEsitatud ärinõue ’BUSREQ01: SEPA liige peab olema kättesaadav läbi PE-ACH'i’

otseselt äriprotsessi ei muuda, kuid on eelduseks väljuvate ja saabunud SEPA

kreeditkorralduste töötluseks. Nõude rahuldamiseks sõlmitakse terve grupi nimel

liitumisleping SEPAga ning iga gruppi kuuluva firma nimel eraldi liitumislepingud

valitud kliiringu ja arveldustega tegeleva üleeuroopalise automatiseeritud arvelduskojaga

(Pan-European Automated Clearing House (PE-ACH)), kus emafirma osaleb

otseliikmena ja tütarfirmad kaudsete liikmetena läbi emafirma.

4.2 Süsteemianalüüsi tulemused

Euroopa Maksenõukogu on vastu võtnud ühtse lähenemisviisi standardite

väljatöötamiseks, et automatiseerida kõik eurodes sooritatud maksed. EPC on kehtestanud

ärinõuded andmetele, mida finantsvahendajad peavad üksteisega vahetama. Need nõuded

on avaldatud reeglistikus Rulebooks for SEPA Credit Transfers and Direct Debits. EPC

on jaganud ettevõtetele kehtestatud nõuded loogilisteks andmeosadeks, mis avaldati

väljaandes SEPA Data Model. Rahvusvaheline Standardimisorganisatsioon (ISO) arvestas

need loogilised andmeosad ümber universaalse finantssektori (UNIFI)

sõnumistandarditeks, ehk UNIFI (ISO 20022) XML sõnumistandarditeks. Neil

standarditel põhineb sõnumite saatmine standarditud keeles. EPC on kehtestanud SEPA

rakendusjuhised, milles määratletakse UNIFI sõnumistandardite kasutamine. EPC

otsustas, et pankadevahelises suhtluses on UNIFI standardite kasutamine kohustuslik,

klientide ning pankade vahelises suhtluses aga soovituslik.

Arvestades tütarfirmades puuduvat funktsionaalsust UNIFI sõnumite töötlemiseks ning

projekti skoobis määratletud ülesannet vahendada üksikuid SEPA kreeditkorraldusi

tütarfirmade (kaudsed SEPA liikmed) ja emafirma (otsene SEPA liige) vahel, otsustati

luua eraldi süsteemikomponent selle realiseerimiseks. ’SEPA vahendajaks’ nimetatud

süsteemikomponendile kehtestatud ärinõuetest ja kehtivast praktikast tulenevad

funktsionaalsed nõuded on kirjeldatud järgnevates punktides. UNIFI sõnumistandarditele

vastavaid ja SEPA kreeditkorraldusskeemi rakendusjuhiste alusel koostatud sõnumeid

nimetatakse edaspidi SEPA XML sõnumiteks.

27

4.2.1 Funktsionaalsed nõuded

Süsteemianalüüsi käigus selgusid kahte tüüpi funktsionaalseid nõudedd:

Ärinõuetest tulenevad

o FNCREQ01: Süsteem peab olema võimeline vastu võtma ja salvestama

väljuva SEPA kreeditkorralduse andmeid SEPA XML sõnumina

edastamiseks


väljuva SEPA kreeditkorralduse tagastuse andmeid SEPA XML sõnumina

edastamiseks


SEPA XML sõnumina saabunud tagastatud SEPA kreeditkorralduse

andmeid


SEPA XML sõnumina saabunud SEPA kreeditkorralduse andmeid


SEPA XML sõnumina saabunud tagasilükatud SEPA kreeditkorralduse

andmeid

o FNCREQ06: Süsteem peab olema võimeline moodustama ja edastama

sõnumi tüübile vastavat SEPA XML sõnumit

kehtivast praktikast: pankadevaheliste sõnumite töötlusele esitatavad nõuded

o FNCREQ07: Saadetud SEPA sõnumid peavad saama kinnituse

eduka/ebaeduka edastamise kohta

o FNCREQ08: Saabunud SEPA sõnumit peab olema võimalik töötlusest

kõrvaldada

o FNCREQ09: Veel edastamata SEPA sõnumit peab olema võimalik

tühistada

28

4.2.2 Kasutuslood

Funktsionaalsed nõuded süsteemile on kirjeldatud kasutuslugudena.

Süsteemi aktoridKäesoleva tööga seotud süsteemi aktorid on:

Kreeditkorralduste töötlemise süsteem – süsteemi aktor, mis tegeleb kliendilt saadud ja

kliendile saabunud kreeditkorralduste töötlusega (tütarfirma, kaudne SEPA liige);

Ajaloendur – süsteemi aktor, mille ülesandeks on käivitada perioodilisi protsesse:

eelnevalt määratud kellaaegadel käivitab sõnumite automaattöötluse (registreeritud

väljuvate sõnumite saatmine ja saabunud sõnumite registreerimine);

SEPA sõnumifailide töötleja – süsteemi aktor, mis tegeleb SEPA XML sõnumite

vahendamisega tütarfirma ja SEPA infrastruktuuri vahel (emafirma, otsene SEPA liige).

Kasutuslugude ülevaadeKäesolevas töös on kirjeldatud ainult ’SEPA vahendaja’ kasutuslugusid, ülevaates on ära

näidatud ka seosed seotud süsteemide kasutuslugudega:

29

uc Primary Use Cases

SEPA vahendaja

UC07: Registreeri saabunud SEPA XML

sõnum

Kreeditkorralduste töötlemise süsteem

SEPA sõnumifailide töötleja

UC01: Registreeri v äljuva SEPA

kreeditkorralduse sõnumi andmed

UC02: Registreeri väljuva SEPA

kreeditkorralduse tagastuse sõnumi

andmed

UC03: Moodusta j a saada välj aminev SEPA XML sõnum

Ajaloendur

UC05: Tühista SEPA sõnumi saatmine

UC06: Arhiveeri SEPA sõnum ilma

töötluseta

Loe SEPAst saabunud

kreeditkorralduse tagastuse andmed

Loe SEPAst saabunud

tagasilükatud kreeditkorralduse

andmed

UC04: Registreeri SEPA XML sõnumi töötluse

vastus otseliikmelt

Edasta SEPA XML sõnum kaudsele

liikmele

Võta vastu SEPA XML sõnum kaudselt

liikmelt

Edasta SEPA XML sõnumi vastus

kaudsele liikmele

Edasta kreeditkorraldus läbi

SEPA

Edasta kreeditkorralduse tagastus läbi SEPA

Loe SEPAst saabunud

kreeditkorralduse andmed

UC08: Registreeri saabunud SEPA

kreeditkorralduse sõnumi andmed

UC09: Registreeri saabunud SEPA

kreeditkorralduse tagastuse sõnumi

andmed

UC10: Registreeri saabunud

tagasilükatud SEPA kreeditkorralduse

sõnumi andmed

Töös vaadeldavad kasutuslood

Seotud süsteemide kasutuslood

Legend

«precedes»

«invokes»

«extend»

«precedes»

«include»

«include»

«precedes»

«precedes»

«precedes»

«precedes»

«precedes»

«extend»

«extend»

Joonis 4-11. Kasutuslugude ülevaade

Kasutuslugude lühikirjeldusedKasutuslugude lühikirjeldustes on ära toodud üldine kirjeldus, peastsenaariumi

kokkuvõte, peamised alternatiivsed stsenaariumid ning eel- ja järeltingimused.

Lühikirjelduse eesmärgiks on anda käesolevas töös ülevaade juurutatavast

funktsionaalsusest. Tegelikkuses kasutati projekti funktsionaalsete nõuete kirjeldamisel

detailseid kasutuslugusid, mille näide on toodud lisas X.

UC01: Registreeri väljuva SEPA kreeditkorralduse sõnumi andmed

Üldine kirjeldus

Väljuva kreeditkorralduse andmete kontrollimine ja sõnumi andmete salvestamine.

Peastsenaarium

Kreeditkorralduste töötlemise süsteem edastab korralduse saata väljuv kreeditkorraldus

saaja pangale. Süsteem kontrollib kreeditkorralduse andmete korrektsust ja vastavust

SEPA reeglitele. Süsteem registreerib uue kreeditkorralduse sõnumi.

Alternatiivne stsenaarium

30

Kreeditkorralduse andmed ei vasta SEPA tingimustele. Süsteem tühistab tehtud

muudatused ja tagastab väljakutsujale vea kirjelduse.

Sõnumi andmete salvestamine ebaõnnestub. Süsteem tühistab tehtud muudatused ja

tagastab väljakutsujale vea kirjelduse.

Eeltingimused

Kreeditkorralduste töötlemise süsteem on registreerinud ja aktsepteerinud kliendi poolt

esitatud kreeditkorralduse andmed.

Järeltingimused

Väljuv kreeditkorralduse sõnum staatuses 'Registreeritud' on salvestatud.

UC02: Registreeri väljuva SEPA kreeditkorralduse tagastuse sõnumi andmed

Üldine kirjeldus

Väljuva kreeditkorralduse tagastuse andmete kontrollimine ja sõnumi andmete

salvestamine.

Peastsenaarium

Kreeditkorralduste töötlemise süsteem edastab korralduse saata kreeditülekande tagastus

saaja pangale. Süsteem kontrollib esialgse saabunud kreeditkorralduse olemasolu.

Süsteem kontrollib kreeditkorralduse tagastuse andmete korrektsust ja vastavust SEPA

reeglitele. Süsteem registreerib uue kreeditkorralduse tagastussõnumi.


Esialgne saabunud kreeditkorraldus puudub. Süsteem lõpetab kasutusloo ja tagastab

väljakutsujale vea kirjelduse.

Tagastussõnumi andmete salvestamine ebaõnnestub. Süsteem tühistab tehtud muudatused

ja tagastab väljakutsujale vea kirjelduse.

Eeltingimused

Kreeditkorralduste töötlemise süsteem on töödelnud saabunud kreeditkorralduse ja

määranud selle tagastatavaks.

Järeltingimused

Kreeditkorralduse tagastussõnum staatuses 'Registreeritud' on salvestatud.

UC03: Moodusta ja saada väljaminev SEPA XML sõnum

31

Üldine kirjeldus

Registreeritud väljuvast sõnumist SEPA XML sõnumi moodustamine ja saatmine SEPA

otseliikmele.

Peastsenaarium

Süsteem loob registreeritud sõnumi andmete põhjal sõnumi tüübile vastava SEPA XML

sõnumi. Süsteem kontrollib loodud XML sõnumi õigsust. Süsteem saadab loodud XML

sõnumi SEPA otseliikmele. Loodud füüsilise XML faili koopia arhiveeritakse.


Väljuva sõnumi koostamine või väljasaatmine ebaõnnestub. Süsteem tühistab tehtud

muudatused ja tagastab väljakutsujale vea kirjelduse. Süsteem teavitab tekkinud veast

monitooringut. Väljuva sõnumi staatuseks saab 'Vigane'.

Eeltingimused

Väljuv kreeditkorralduse sõnum on registreeritud.

Järeltingimused

Väljuv sõnum on staatuses 'Saadetud'.

UC04: Registreeri SEPA XML sõnumi töötluse vastus otseliikmelt

Üldine kirjeldus

SEPA otseliikmelt saadetud väljuva SEPA XML sõnumi vastuse registreerimine.

Peastsenaarium

SEPA otseliige saadab süsteemi poolt saadetud väljuva SEPA XML sõnumi kohta

positiivse vastuse. Süsteem leiab saadetud väljuva sõnumi. Süsteem märgib sõnumi

vastuvõetuks.


SEPA otseliige tagastab negatiivse vastuse. Süsteem leiab saadetud väljuva sõnumi.

Süsteem märgib sõnumi tagasilükatuks. Väljuv sõnum saab staatuse 'Tagasilükatud'.

Saadetud väljuvat sõnumit ei leita. Süsteem teavitab monitooringut.

Eeltingimused

Süsteem on koostanud korrektse väljuva SEPA XML sõnumi ja saatnud selle SEPA

otseliikmele. Sõnum on staatuses 'Saadetud'.

Järeltingimused

32

Väljuv sõnum on staatuses 'Vastuvõetud'.

UC05: Tühista SEPA sõnumi saatmine

Üldine kirjeldus

Väljuva registreeritud sõnumi tühistamine enne SEPA XML sõnumi moodustamist ja

saatmist SEPA otseliikmele.

Peastsenaarium

Klient teavitab panka soovist tühistada registreeritud kreeditkorraldus. Kreeditkorralduste

töötlemise süsteemi kasutaja vaatab vastava kreeditkorralduse andmeid ja märgib selle

tühistatuks. Süsteem tühistab väljuva sõnumi saatmise.

Eeltingimused

Väljuv kreeditkorralduse / tagastuse sõnum on registreeritud.

Järeltingimused

Väljuv sõnum on staatuses 'Tühistatud'

UC06: Arhiveeri SEPA sõnum ilma töötluseta

Üldine kirjeldus

Saabunud registreeritud sõnumi arhiveerimine ilma kreeditkorralduste süsteemi poolse

töötluseta.

Peastsenaarium

Kreeditkorraluste töötlemise süsteemi kasutaja on asunud töötlema saabunud

(tagasilükatud) kreeditkorraldust / tagastust. Töötlemisel selgub, et seda juhtumit pole

vaja / võimalik töödelda ja kasutaja määrab sõnumi kõrvaldatavaks töötlemise protsessist.

Süsteem katkestab sõnumi töötluse ja märgib arhiveerituks.

Eeltingimused

Saabunud (tagasilükatud) kreeditkorralduse / tagastuse sõnum on registreeritud.

Järeltingimused

Saabunud sõnum on staatuses 'Arhiveeritud ilma töötluseta'.

UC07: Registreeri saabunud SEPA XML sõnum

Üldine kirjeldus

SEPA otseliikmelt saabunud SEPA XML sõnumi dekomponeerimine ja sõnumi andmete

salvestamine.

33

Peastsenaarium

SEPA otseliige saadab süsteemile SEPA XML sõnumi. Süsteem dekomponeerib sõnumi.

Süsteem salvestab uue saabunud SEPA sõnumi andmed vastavalt sõnumi tüübile

ettenähtud korras. Süsteem märgib sõnumi registreerituks. Saadud füüsiline XML faili

arhiveeritakse. Süsteem kontrollib automaatse töötlusprotsessi valmidust. Süsteem märgib

sõnumi ootamaks automaatset töötlust.


Saabunud SEPA XML sõnumi dekomponeerimine ebaõnnestub. Süsteem lõpetab

kasutusloo. Saadud füüsiline XML fail tõstetakse eraldi kataloogi. Süsteem teavitab

tekkinud veast monitooringut.

Uue saabunud SEPA sõnumi andmete salvestamine ebaõnnestub. Süsteem tühistab tehtud

muudatused. Saadud füüsilist XML faili ei arhiveerita ega tõsteta eraldi kataloogi.

Süsteem teavitab tekkinud veast monitooringut.

Automaatne töötlusprotsess pole võimalik. Süsteem märgib sõnumi ootamaks

käsitsitöötlust.

Järeltingimused

Saabunud sõnumi andmed staatuses 'Ootab automaatset töötlust' on salvestatud.

UC08: Registreeri saabunud SEPA kreeditkorralduse sõnumi andmedSEPA kreeditkorralduse sõnumi andmete salvestamine kasutusloo ’UC07: Registreeri

saabunud SEPA XML sõnum’ baasil.

UC09: Registreeri saabunud SEPA kreeditkorralduse tagastuse sõnumi andmedSEPA kreeditkorralduse tagastuse sõnumi andmete salvestamine kasutusloo ’UC07:

Registreeri saabunud SEPA XML sõnum’ baasil.

UC10: Registreeri saabunud tagasilükatud SEPA kreeditkorralduse sõnumi andmedTagasilükatud SEPA kreeditkorralduse sõnumi andmete salvestamine kasutusloo ’UC07:

Registreeri saabunud SEPA XML sõnum’ baasil.

34

4.2.3 Mittefunktsionaalsed nõuded

Mittefunktsionaalsetele nõuded on varustatud tüübile vastava identifikaatoriga. Kasutatud

on järgmisi mittefunktsionaalsete nõuete tüüpe:

USE – kasutatavus (Usability)

REL – terviklus ja usaldusväärsus (Reliability)

PER – jõudlus ja käideldavus (Performance)

SUP – toetavus (Supportability)

Kasutatavuse nõuded USE01: Võimalusel pakkuda kasutajaliidest korrektsete andmetega väljuvate

sõnumite registreerimiseks.

USE02: Koostada dokumentatsioon süsteemi võimalike seadistuste kohta.

USE03: Sõnumite töötluse käigus tekkivad vead tuleb koheselt edastada

monitooringule, et vähendada kreeditkorralduse täitmise hilinemist.

Tervikluse ja usaldusväärsuse nõuded REL01: Süsteem peab olema kasutatav 99,5% jättes 0,5% (3,6h) korrapärasteks

hooldusteks kord kuus.

REL02: Sõnumis sisalduvad andmed peavad jääma muutumatuks kogu töötluse

vältel ja selle järel.

REL03: Sõnumid peavad olema kättesaadavad vähemalt ühe aasta jooksul peale

nende lõplikku töötlemist.

Jõudlus- ja käideldavusnõuded PER01: Failihoidla peab suutma igapäevaselt mahutama kuni 5000 SEPA XML

sõnumifaili keskmise suurusega 5kB.

PER02: Keskmine sõnumi töötlemiseks kuluv aeg ei tohi olla pikem kui kolm

sekundit.

35

Toetavuse nõuded SUP01: Süsteemi peab olema võimalik seadistada ilma arendustegevuseta.

SUP02: Süsteem peab olema sõltumatu rakendusplatvormist.

4.3 Disaini ja arhitektuuri tulemused

Süsteemi toetava andmemudelini jõudmiseks oli vajalik SEPA kreeditkorraldusskeemi

rakendusjuhiste ja UNIFI sõnumidefinitsioonide raporti (UNIFI (ISO 20022) Message

Definition Report (MDR)) detailne analüüs, mille käigus selgusid süsteemis kasutatavate

miinimumnõuetele vastavate SEPA XML sõnumite struktuur (detailne ülevaade on

toodud lisas X).

Enne lõpliku andmemudeli valmimist koostati analüütilistel eesmärkidel erineva

detailsusega klassimudelid, muutudes üldisemast kirjeldusest täpsema poole.

4.3.1 Valdkonnamudel

Valdkonnamudel loodi SEPA kreeditkorraldusskeemis kasutatavate kohustuslike

sõnumitüüpide ja sõnumites sisalduvate kontseptuaalsete klasside üldiseks kirjeldamiseks.

36

class Domain Objects

Kreeditkorraldus (CreditTransfer)

Osapoole arv e (Party Account)

Osapoole tunnus (Party Identification)

Tagasilükatud kreeditkorraldus

(Reject)

Tagastatud kreeditkorraldus

(Return)

Struktureeritud selgitus (Structured Remittance

Information)

Arveldustehing (Transaction)

SEPA sõnum (SEPA message)

Rahaülekande selgitus (Remittance Information)

Vabas vormis selgitus (Unstructured Remittance

Information)

Osapool (Party)

Maksja vahendaja (Debtor Agent)

Maksja (Debtor)

Saaja (Creditor)

Finantsasutus (Financial Institution)

Juhendav v ahendaja (Instructing Agent)

Juhendatav v ahendaja (Instructed Agent)

Saaja v ahendaja (Creditor Agent)

0..*

identifi tseerub (identified by)1

1..*

sisaldab juhiseid teostamaks (carries instructions of)

1..*

1

li igutab raha (moves money between)

2

1

põhineb (bases on)

0..*

0..*

teenindab (serviced by)

1

1..*

li igub läbi (travels between)

1..*

1

avaldab andmed (issues details of)

0..*

1..*

kuulub (owned by)

1

Joonis 4-12. SEPA kreeditkorraldussõnumite valdkonnamudel

Joonisel 11 kujutatud klassid ning nendevahelised seosed on kirjeldatud nii eesti- kui

inglisekeelsetena, et sujuvalt näidata nende muundumist klassi- ja andmemudelites, mis

on kirjeldatud inglisekeelsetena säilitamaks verbaalset seost SEPA XML

sõnumistruktuuris kasutatavate atribuutide nimedega.

4.3.2 Klassimudel

Klassimudelis kirjeldatakse süsteemi staatilist struktuuri, kus on näidatud klasside

põhilised atribuudid ja klassidevahelised seosed.

Kuigi ainemudel kirjeldab, et ühe SEPA sõnumiga võib liikuda info mitme

arveldustehingu kohta, vaadeldakse süsteemi klassimudelis ja edaspidi selliselt, et üks

sõnum sisaldab ainult ühte arveldustehingut. Selline lähenemine võimaldab kadudeta

süsteemi struktuuri lihtsamalt kirjeldada.

37

Võrreldes ainemudeliga on klassimudelisse lisatud täpsustavamaid klassidevahelisi

seoseid, sõnumite võimalikud suunad, olekud ja ühest olekust teise siirdumist kirjeldavad

sündmused nagu näidatud alljärgneval joonisel:

class System

SingleMessage

CreditTransfer

- purpose: char- chargeBearer: char

Return

- returnSettlementDate: date- returnedSettlementAmount: amount- returnOriginator: char- returnReason: char

Rej ect

- transactionStatus: char- statusOriginator: char- statusReason: char

Transaction

- settlementDate: date- settlementAmount: amount

RemittanceInformation

StructuredInfo

- creditorReference: char- additionalInformation: char

UnstructuredInfo

- remittanceInfo: char

Party

- name: char- address: address

PartyIdentification

- identificationValue: char

«enumeration»MessageStatus

Registered, incoming = IRWaiting for automatic processing = WAWaiting for manual processing = WMProcessed = PErroneous, incoming = IEArchived without processing = HRegistered, outgoing = ORSent = SAccepted = ARejected = RCancel led = CErroneous, outgoing = OE

MessageEv ent

- doneAt: datetime- doneBy: char

EventType

- description: char

«enumeration»MessageDirection

Incoming = IOutgoing = O

FinancialInstitution

- BIC: char

PartyAccount

- IBAN: char

IdentificationStructure

- identificationCode: char- identificationName: char- siblingOrderNumber: int- description: char

1

-creditor

1

1

-creditorAccount

1

0..*

-underlyingTransaction

1

1..*

-eventSubject1

0..*

-parentIdentification 0..1

0..*

-identi ficationInfo

1

0..*

-ownerParty 1

-status 0..1

-relatedMessage0..1

0..*

-type

1

0..*

-ini talStatus 1

1

-invoicer

0..1

1

-invoicee

0..1

1

-debtorAccount

1

1

-ultimateDebtor

0..1

1..*

-transactionInfo 1

1

-ultimateCreditor

0..1

1

-instructingAgent

0..1

1

-instructedAgent

0..1

1

-debtorAgent

1

1

-creditorAgent

1

-direction0..*

-finalStatus 1

1

-debtor

1

Joonis 4-13. Klassimudel

Väljuva ja saabuva sõnumi olekute vahelised siirded on kirjeldatud olekudiagrammidega

lisas X ja X.

Tulenevalt klassidevaheliste üks-ühele seoste muundumisega seose algataja klassi

atribuutideks ja sõnumi alamtüüpe kirjeldavate klasside muundumisega sõnumi päise

jätkuklassideks, koostati juba täpsustatud klassimudel nagu näidatud alljärgneval joonisel:

38

class System2

«enumeration»MessageType

CreditTransfer = CTReject = REJReturn = RET

«enumeration»MessageStatus

Registered, incoming = IRWaiting for automatic processing = WAWaiting for manual processing = WMProcessed = PErroneous, incoming = IEArchived without processing = HRegistered, outgoing = ORSent = SAccepted = ARejected = RCancel led = CErroneous, outgoing = OE

«enumeration»MessageDirection

Incoming = IOutgoing = O

«enumeration»RemittanceInformationType

Structured = SUnstructured = U

SingleMessage

- instructingAgent: FinancialInstitution- instructedAgent: FinancialInstitution

CreditTransfer

- purpose: char- chargeBearer: char

Return

- returnSettlementDate: date- returnedSettlementAmount: amount- returnOriginator: char- returnReason: char

Reject

- transactionStatus: char- statusOriginator: char- statusReason: char

Transaction

- settlementDate: date- settlementAmount: amount- debtorAccount: PartyAccount- creditorAccount: PartyAccount- debtorAgent: FinancialInsti tution- creditorAgent: FinancialInstitution


- unstructuredRemittanceInfo: char

StructuredInfo

- creditorReference: char- additionalInformation: char

Party

- name: char- address: address

PartyIdentification

- identificationValue: char

MessageEvent

- doneAt: datetime- doneBy: char

EventType

- description: char


- identificationCode: char- identificationName: char- siblingOrderNumber: int- description: char

«enumeration»PartyType

Ultimate Debtor = UDDebtor = DCreditor = CUltimate Creditor = UCInvoicer = IRInvoicee = IE

0..1

-remittanceInfo 1

0..1

-relatedMessage0..1

-status

-direction

-type

0..*

-ownerParty 1

0..*

-identificationInfo

1

0..*

-underlyingTransaction

1

1..*

-eventSubject 1

1

-invoicer

0..1

1

-invoicee

0..1

0..*

-parentIdentification 0..1

-type

1..*

-transactionInfo 1

-type

0..*

-ini tialStatus 1

0..*

-finalStatus 1

1

-ul timateDebtor0..1

1

-debtor1

1

-creditor1

1

-ul timateCreditor0..1

0..1

-messageHeader1 0..1

-messageHeader

1

0..1

-messageHeader

1

0..*

-type

1

Joonis 4-14. Täpsustatud klassimudel

Lisaks on kirjeldatud sõnumite, osapoolte ja rahaülekande selgituse võimalikud tüübid.

Sellisel kujul klassimudel oli aluseks detailse andmemudeli loomisel.

4.3.3 Andmemudel

Andmemudelis on kirjeldatud süsteemi toimimist toetavad andmetabelid koos kõikide

SEPA XML sõnumifaili struktuurist pärinevate atribuutidega.

Andmemudel kõikide tabelitega

39

dm Schema (Information Engineering)

MessageType

«column»*PK messageTypeCode: VARCHAR2(5)* name: VARCHAR2(50)

description: VARCHAR2(100)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«PK»+ PK_MessageType(VARCHAR2)

MessageStatus

«column»*PK messageStatusCode: VARCHAR2(2)* name: VARCHAR2(50)

finalFlag: VARCHAR2(1)description: VARCHAR2(100)

* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«PK»+ PK_MessageStatus(VARCHAR2)

MessageHeader

«column»*PK messageHeaderID: LONG*FK messageTypeCode: VARCHAR2(5)*FK messageStatusCode: VARCHAR2(2) FK relatedMessageHeaderID: LONG* messageDi rection: VARCHAR2(1)

relatedPaymentID: VARCHAR2(35)groupMessageIdenti fication: VARCHAR2(35)instructingAgentBIC: VARCHAR2(11)instructedAgentBIC: VARCHAR2(11)

*FK transactionID: LONG* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_messageStatusCode(VARCHAR2)+ FK_messageTypeCode(VARCHAR2)+ FK_relatedMessageHeaderID(LONG)+ FK_transactionID(LONG)

«PK»+ PK_MessageHeader(LONG)

CreditTransfer

«column»*PK creditTransferID: LONG*FK messageHeaderID: LONG

purposeCode: VARCHAR2(35)purposeProprietary: VARCHAR2(35)

* chargeBearerCode: VARCHAR2(10)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_messageHeaderID(LONG)

«PK»+ PK_CreditTransfer(LONG)

MessageCode

«column»*pfK messageCodeType: VARCHAR2(5)*PK messageCodeCode: VARCHAR2(10)

ISOdefinition: VARCHAR2(100)SEPAdefini tion: VARCHAR2(100)

* createdAt: DAT E* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_messageCodeType(VARCHAR2)

«PK»+ PK_MessageCode(VARCHAR2, VARCHAR2)

MessageCodeType

«column»*PK messageCodeType: VARCHAR2(5)* ISOtype: VARCHAR2(30)

ISOdefinition: VARCHAR2(100)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DAT E* lastUpdatedBy: VARCHAR2(50)

«PK»+ PK_MessageCodeType(VARCHAR2)

Reject

«column»*PK rejectID: LONG*FK messageHeaderID: LONG* statusIdentifi cation: VARCHAR2(35)

originalGroupMessageIdentification: VARCHAR2(35)originalNetworkFi leName: VARCHAR2(35)

* originalGroupMessageNameIdentifi cation: VARCHAR2(35)transactionStatusCode: VARCHAR2(10)statusOriginatorName: VARCHAR2(70)statusOriginatorBIC: VARCHAR2(11)statusReasonCode: VARCHAR2(10)statusReasonProprietary: VARCHAR2(35)



«PK»+ PK_Reject(LONG)


«column»*PK identificationCode: VARCHAR2(10)* identificationName: VARCHAR2(50)

parentIdentifi cationCode: VARCHAR2(10)* siblingOrderNumber: NUMBER(3)

description: VARCHAR2(100)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DAT E* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_parentIdenti ficationCode(VARCHAR2)

«PK»+ PK_IdentificationStructure(VARCHAR2)

MessageEvent

«column»*PK messageEventID: LONG*FK messageHeaderID: LONG*FK eventTypeID: LONG* doneAt: DATE* doneBy: VARCHAR2(50)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_eventTypeID(LONG)+ FK_messageHeaderID(LONG)

«PK»+ PK_MessageEvent(LONG)

EventType

«column»*PK eventTypeID: LONG* name: VARCHAR2(50)* initialStatusCode: VARCHAR2(2)* finalStatusCode: VARCHAR2(2)* val idFlag: VARCHAR2(1)


«FK»+ FK_finalStatusCode(VARCHAR2)+ FK_initialStatusCode(VARCHAR2)

«PK»+ PK_EventType(LONG)

Return

«column»*PK returnID: LONG*FK messageHeaderID: LONG* returnIdenti fication: VARCHAR2(35)* settlementDate: DATE* settlementMethod: VARCHAR2(10)

settlementAccountT ype: VARCHAR2(5)settlementAccount: VARCHAR2(34)

* returnedSettlementAmount: NUMBER(11,2)clearingSystemCode: VARCHAR2(10)clearingSystemProprietary: VARCHAR2(35)originalGroupMessageNameIdenti fication: VARCHAR2(35)originalGroupMessageIdentification: VARCHAR2(35)chargeBearer: VARCHAR2(10)returnOriginatorName: VARCHAR2(70)returnOriginatorBIC: VARCHAR2(11)returnReasonCode: VARCHAR2(10)returnReasonProprietary: VARCHAR2(35)



«PK»+ PK_Return(LONG)

Transaction

«column»*PK transactionID: LONG* settlementDate: DATE* settlementMethod: VARCHAR2(10)

settlementAccountType: VARCHAR2(5)settlementAccount: VARCHAR2(34)

* settlementAmount: NUMBER(11,2)instructionIdenti fication: VARCHAR2(35)

* endToEndIdentification: VARCHAR2(35)* transactionIdentifi cation: VARCHAR2(35)

clearingSystemCode: VARCHAR2(10)clearingSystemProprietary: VARCHAR2(35)

* serviceLevelCode: VARCHAR2(10)categoryPurposeCode: VARCHAR2(10)ul timateDebtorPartyID: LONG

* debtorPartyID: LONG* debtorAccountIBAN: VARCHAR2(34)* debtorAgentBIC: VARCHAR2(11)* creditorAgentBIC: VARCHAR2(11)* creditorPartyID: LONG* creditorAccountIBAN: VARCHAR(34)

ul timateCredi torPartyID: LONG* createdAt: DAT E* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_credi torPartyID(LONG)+ FK_debtorPartyID(LONG)+ FK_ultimateCreditorPartyID(LONG)+ FK_ultimateDebtorPartyID(LONG)

«PK»+ PK_Transaction(LONG)


«column»*PK remi ttanceInformationID: LONG* transactionID: LONG* remi ttanceInformationT ype: VARCHAR2(1)* unstructuredRemittanceInformation: VARCHAR2(140)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_transactionID(LONG)

«PK»+ PK_Remi ttanceInformation(LONG)

StructuredRemittanceInformation

«column»*PK structuredRemi ttanceInformationID: LONG*FK remittanceInformationID: LONG

creditorReferenceT ypeCode: VARCHAR2(10)creditorReference: VARCHAR2(35)

FK invoicerPartyID: LONG FK invoiceePartyID: LONG

additionalRemittanceInformation: VARCHAR2(140)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_invoiceePartyID(LONG)+ FK_invoicerPartyID(LONG)+ FK_remittanceInformationID(LONG)

«PK»+ PK_StructuredRemittanceInforma(LONG)

Party

«column»*PK partyID: LONG* partyType: VARCHAR2(2)

name: VARCHAR2(70)addressType: VARCHAR2(10)addressLine1: VARCHAR2(70)addressLine2: VARCHAR2(70)addressLine3: VARCHAR2(70)addressLine4: VARCHAR2(70)addressLine5: VARCHAR2(70)streetName: VARCHAR2(70)bui ldingNumber: VARCHAR2(16)postCode: VARCHAR2(16)townName: VARCHAR2(35)countrySubDivision: VARCHAR2(35)countryCode: VARCHAR2(2)countryOfResidence: VARCHAR2(2)


«PK»+ PK_Party(LONG)

PartyIdentification

«column»*PK partyIdenti ficationID: LONG* partyID: LONG* identificationCode: VARCHAR2(10)* identifi cationValue: VARCHAR2(35)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_identifi cationCode(VARCHAR2)+ FK_partyID(LONG)

«PK»+ PK_PartyIdentification(LONG)

+FK_relatedMessageHeaderID

(relatedMessageHeaderID = messageHeaderID)

«FK»

+PK_MessageHeader

+FK_messageStatusCode

(messageStatusCode = messageStatusCode)

«FK»

+PK_MessageStatus

+FK_messageT ypeCode

(messageTypeCode = messageTypeCode)«FK»

+PK_MessageType

+FK_messageHeaderID

(messageHeaderID = messageHeaderID)«FK»

+PK_MessageHeader

+FK_messageCodeType

(messageCodeType = messageCodeType)

«FK»

+PK_MessageCodeType

+FK_messageHeaderID

(messageHeaderID = messageHeaderID)

«FK»

+PK_MessageHeader

+FK_parentIdenti ficationCode

(parentIdentifi cationCode = identi fi cationCode)

«FK»

+PK_Identi ficationStructure

+FK_messageHeaderID


«FK»

+PK_MessageHeader

+FK_finalStatusCode(finalStatusCode = messageStatusCode)

«FK»

+PK_MessageStatus

+FK_initialStatusCode

(ini tialStatusCode = messageStatusCode)

«FK»

+PK_MessageStatus

+FK_eventTypeID

(eventTypeID = eventTypeID)«FK»

+PK_EventType

+FK_messageHeaderID


«FK»

+PK_MessageHeader

+FK_transactionID

(transactionID = transactionID)

«FK»

+PK_T ransaction

+FK_transactionID


«FK»

+PK_T ransaction

+FK_remittanceInformationID

(remittanceInformationID = remittanceInformationID)

«FK»

+PK_RemittanceInformation

+FK_ul timateDebtorPartyID

(ul timateDebtorPartyID = partyID)

«FK»

+PK_Party

+FK_debtorPartyID

(debtorPartyID = partyID)

«FK»

+PK_Party

+FK_creditorPartyID

(credi torPartyID = partyID)

«FK»

+PK_Party

+FK_ul timateCreditorPartyID

(ultimateCredi torPartyID = partyID)

«FK»

+PK_Party

+FK_invoicerPartyID

(invoicerPartyID = partyID)

«FK»

+PK_Party

+FK_invoiceePartyID

(invoiceePartyID = partyID)

«FK»

+PK_Party

+FK_partyID

(partyID = partyID)

«FK»

+PK_Party

+FK_identificationCode

(identifi cationCode = identi fi cationCode)«FK»

+PK_Identifi cationStructure

40

Ning andmemudel paremaks loetavuseks jagatuna neljale joonisele, mis kujutavad

järgmisi tabeleid ja seoseid:

Sõnumi päis, sõnumi sündmused, staatused, tüübid

Sõnumi päis ja sõnumi tüüpidele vastavad jätkutabelid

Sõnumi päis, arveldustehing, osapool, rahaülekande selgitus

Osapool, osapoole tunnused, sõnumis kasutatavad koodid ja nende tüübid

dm Schema (sõnumi päis, sündmus, staatus, tüüp)

MessageType

«column»*PK messageTypeCode: VARCHAR2(5)* name: VARCHAR2(50)


«PK»+ PK_MessageType(VARCHAR2)

MessageStatus

«column»*PK messageStatusCode: VARCHAR2(2)* name: VARCHAR2(50)

finalFlag: VARCHAR2(1)description: VARCHAR2(100)


«PK»+ PK_MessageStatus(VARCHAR2)

MessageHeader

«column»*PK messageHeaderID: LONG*FK messageTypeCode: VARCHAR2(5)*FK messageStatusCode: VARCHAR2(2) FK relatedMessageHeaderID: LONG* messageDirection: VARCHAR2(1)

relatedPaymentID: VARCHAR2(35)groupMessageIdenti fication: VARCHAR2(35)instructingAgentBIC: VARCHAR2(11)instructedAgentBIC: VARCHAR2(11)




MessageEv ent

«column»*PK messageEventID: LONG*FK messageHeaderID: LONG*FK eventTypeID: LONG* doneAt: DATE* doneBy: VARCHAR2(50)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_eventTypeID(LONG)+ FK_messageHeaderID(LONG)

«PK»+ PK_MessageEvent(LONG)

Ev entType

«column»*PK eventTypeID: LONG* name: VARCHAR2(50)*FK initialStatusCode: VARCHAR2(2)*FK finalStatusCode: VARCHAR2(2)* val idFlag: VARCHAR2(1)


«FK»+ FK_finalStatusCode(VARCHAR2)+ FK_ini tialStatusCode(VARCHAR2)

«PK»+ PK_EventType(LONG)

+FK_finalStatusCode

(finalStatusCode = messageStatusCode)

«FK»+PK_MessageStatus

+FK_initialStatusCode

(initialStatusCode = messageStatusCode)

«FK»+PK_MessageStatus

+FK_eventTypeID

(eventTypeID = eventTypeID)

«FK»

+PK_EventType

+FK_messageHeaderID


«FK»

+PK_MessageHeader

+FK_relatedMessageHeaderID

(relatedMessageHeaderID = messageHeaderID)

«FK»

+PK_MessageHeader

+FK_messageStatusCode

(messageStatusCode = messageStatusCode)

«FK»

+PK_MessageStatus

+FK_messageTypeCode

(messageTypeCode = messageTypeCode)

«FK»

+PK_MessageType

Joonis 4-15. Sõnumi päis, sõnumi sündmused, staatused, tüübid

41

dm Schema (sõnumi päis, j ätkutabel...

MessageHeader


relatedPaymentID: VARCHAR2(35)groupMessageIdentification: VARCHAR2(35)instructingAgentBIC: VARCHAR2(11)instructedAgentBIC: VARCHAR2(11)




CreditTransfer

«column»*PK credi tTransferID: LONG*FK messageHeaderID: LONG

purposeCode: VARCHAR2(35)purposeProprietary: VARCHAR2(35)

* chargeBearerCode: VARCHAR2(10)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)


«PK»+ PK_Credi tTransfer(LONG)

Reject

«column»*PK rejectID: LONG*FK messageHeaderID: LONG* statusIdentification: VARCHAR2(35)

originalGroupMessageIdentification: VARCHAR2(35)originalNetworkFi leName: VARCHAR2(35)

* originalGroupMessageNameIdentification: VARCHAR2(35)transactionStatusCode: VARCHAR2(10)statusOriginatorName: VARCHAR2(70)statusOriginatorBIC: VARCHAR2(11)statusReasonCode: VARCHAR2(10)statusReasonProprietary: VARCHAR2(35)



«PK»+ PK_Reject(LONG)

Return

«column»*PK returnID: LONG*FK messageHeaderID: LONG* returnIdentification: VARCHAR2(35)* settlementDate: DATE* settlementMethod: VARCHAR2(10)


* returnedSettlementAmount: NUMBER(11,2)clearingSystemCode: VARCHAR2(10)clearingSystemProprietary: VARCHAR2(35)originalGroupMessageNameIdentification: VARCHAR2(35)originalGroupMessageIdentification: VARCHAR2(35)chargeBearer: VARCHAR2(10)returnOriginatorName: VARCHAR2(70)returnOriginatorBIC: VARCHAR2(11)returnReasonCode: VARCHAR2(10)returnReasonProprietary: VARCHAR2(35)



«PK»+ PK_Return(LONG)

+FK_messageHeaderID


«FK»

+PK_MessageHeader

+FK_messageHeaderID


«FK»

+PK_MessageHeader

+FK_messageHeaderID


«FK»

+PK_MessageHeader

Joonis 4-16. Sõnumi päis ja sõnumi tüüpidele vastavad jätkutabelid

42

dm Schema (sõnumi päis, arv eldustehing, osapool, selgit...

MessageHeader


relatedPaymentID: VARCHAR2(35)groupMessageIdentification: VARCHAR2(35)instructingAgentBIC: VARCHAR2(11)instructedAgentBIC: VARCHAR2(11)




Transaction

«column»*PK transactionID: LONG* settlementDate: DATE* settlementMethod: VARCHAR2(10)


* settlementAmount: NUMBER(11,2)instructionIdentification: VARCHAR2(35)

* endToEndIdentification: VARCHAR2(35)* transactionIdentification: VARCHAR2(35)

clearingSystemCode: VARCHAR2(10)clearingSystemProprietary: VARCHAR2(35)

* serviceLevelCode: VARCHAR2(10)categoryPurposeCode: VARCHAR2(10)

FK ultimateDebtorPartyID: LONG*FK debtorPartyID: LONG* debtorAccountIBAN: VARCHAR2(34)* debtorAgentBIC: VARCHAR2(11)* creditorAgentBIC: VARCHAR2(11)*FK creditorPartyID: LONG* creditorAccountIBAN: VARCHAR(34) FK ultimateCreditorPartyID: LONG* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_creditorPartyID(LONG)+ FK_debtorPartyID(LONG)+ FK_ultimateCreditorPartyID(LONG)+ FK_ultimateDebtorPartyID(LONG)

«PK»+ PK_Transaction(LONG)


«column»*PK remittanceInformationID: LONG*FK transactionID: LONG* remittanceInformationType: VARCHAR2(1)* unstructuredRemittanceInformation: VARCHAR2(140)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_transactionID(LONG)

«PK»+ PK_RemittanceInformation(LONG)

StructuredRemittanceInformation

«column»*PK structuredRemittanceInformationID: LONG*FK remittanceInformationID: LONG

creditorReferenceTypeCode: VARCHAR2(10)creditorReference: VARCHAR2(35)

FK invoicerPartyID: LONG FK invoiceePartyID: LONG

additionalRemittanceInformation: VARCHAR2(140)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_invoiceePartyID(LONG)+ FK_invoicerPartyID(LONG)+ FK_remittanceInformationID(LONG)

«PK»+ PK_StructuredRemittanceInforma(LONG)

Party


name: VARCHAR2(70)addressType: VARCHAR2(10)addressLine1: VARCHAR2(70)addressLine2: VARCHAR2(70)addressLine3: VARCHAR2(70)addressLine4: VARCHAR2(70)addressLine5: VARCHAR2(70)streetName: VARCHAR2(70)bui ldingNumber: VARCHAR2(16)postCode: VARCHAR2(16)townName: VARCHAR2(35)countrySubDivision: VARCHAR2(35)countryCode: VARCHAR2(2)countryOfResidence: VARCHAR2(2)



+FK_invoiceePartyID

(invoiceePartyID = partyID)

«FK»

+PK_Party

+FK_invoicerPartyID

(invoicerPartyID = partyID)

«FK»

+PK_Party

+FK_ultimateCreditorPartyID

(ul timateCreditorPartyID = partyID)«FK»

+PK_Party

+FK_creditorPartyID

(creditorPartyID = partyID)«FK»

+PK_Party

+FK_debtorPartyID

(debtorPartyID = partyID)

«FK»

+PK_Party

+FK_ultimateDebtorPartyID

(ultimateDebtorPartyID = partyID)«FK»

+PK_Party

+FK_remittanceInformationID

(remittanceInformationID = remittanceInformationID)

«FK»

+PK_RemittanceInformation

+FK_transactionID


«FK»

+PK_Transaction

+FK_transactionID


«FK»

+PK_Transaction

Joonis 4-17. Sõnumi päis, arveldustehing, osapool, rahaülekande selgitus

43

dm Schema (osapool, osapoole tunnus, sõnumikood, sõnumikoodi tüüp)

MessageCode

«column»*pfK messageCodeType: VARCHAR2(5)*PK messageCodeCode: VARCHAR2(10)

ISOdefinition: VARCHAR2(100)SEPAdefinition: VARCHAR2(100)


«FK»+ FK_messageCodeType(VARCHAR2)

«PK»+ PK_MessageCode(VARCHAR2, VARCHAR2)

MessageCodeType

«column»*PK messageCodeType: VARCHAR2(5)* ISOtype: VARCHAR2(30)

ISOdefinition: VARCHAR2(100)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«PK»+ PK_MessageCodeType(VARCHAR2)


«column»*PK identi ficationCode: VARCHAR2(10)* identi ficationName: VARCHAR2(50) FK parentIdentificationCode: VARCHAR2(10)* sibl ingOrderNumber: NUMBER(3)


«FK»+ FK_parentIdenti ficationCode(VARCHAR2)

«PK»+ PK_IdentificationStructure(VARCHAR2)

Party


name: VARCHAR2(70)addressType: VARCHAR2(10)addressLine1: VARCHAR2(70)addressLine2: VARCHAR2(70)addressLine3: VARCHAR2(70)addressLine4: VARCHAR2(70)addressLine5: VARCHAR2(70)streetName: VARCHAR2(70)buildingNumber: VARCHAR2(16)postCode: VARCHAR2(16)townName: VARCHAR2(35)countrySubDivision: VARCHAR2(35)countryCode: VARCHAR2(2)countryOfResidence: VARCHAR2(2)



PartyIdentification

«column»*PK partyIdentificationID: LONG*FK partyID: LONG*FK identificationCode: VARCHAR2(10)* identificationValue: VARCHAR2(35)* createdAt: DATE* createdBy: VARCHAR2(50)* lastUpdatedAt: DATE* lastUpdatedBy: VARCHAR2(50)

«FK»+ FK_identificationCode(VARCHAR2)+ FK_partyID(LONG)

«PK»+ PK_PartyIdentification(LONG)

+FK_parentIdenti ficationCode

(parentIdentificationCode = identificationCode)

«FK»

+PK_IdentificationStructure

+FK_identi ficationCode

(identi ficationCode = identi ficationCode)

«FK»

+PK_IdentificationStructure

+FK_partyID

(partyID = partyID)«FK»

+PK_Party

+FK_messageCodeType

(messageCodeType = messageCodeType)«FK»

+PK_MessageCodeType

Joonis 4-18. Osapool, osapoole tunnused, sõnumis kasutatavad koodid ja nende tüübid

Andmetabelite detailne kirjeldus on antud lisas X.

44

4.3.4 Arhitektuurimudelid

Komponentide sõltuvuse diagrammcmp Component Model

Tütarfirma, kaudne SEPA liige Uus SEPA sõnumeid vahendav komponent Emafirma, otsene SEPA li ige SEPA infrastruktuur

Kreeditkorralduste töötlemise süsteem

Vajatav lii des:SEPAkreeditkorral duse /tagastuseedastamine

Kreeditkorralduste andmebaas

SEPA vahendaja

SEPA sõnumite andmebaas

Pakutav liides:Väl juvakreedi tkorralduse /tagastuse sõnumiregistreerimine

API

Väljuv jada

SEPA sõnumifailide töötleja

PE-ACH

Laekuv jada

Väl juva kreeditkorralduse andmevoog

Saabuva kreeditkorralduse andmevoog

Komponentide sõltuvus

Legend

Kliendid

Arveldamine

Hinnakiri

Failihoidla

Väljuv SEPAXML sõnum

«flow»

«use»

«use»

«delegate»

Väljuv SEPAkreeditkorraldus /tagastus

«flow»

«use»

Väljuv SEPAkreeditkorraldus /tagastus «flow»


«flow»

«use»

Saabuv SEPA XML sõnumifail

«flow»


«flow»

«use»

«use»

«use»Sõnumitöötlusevastus

«flow»

Sõnumitöötlusevastus

«flow»

Sõnumitöötlusevastus

«flow»

Väljuv SEPAkreeditkorraldus /tagastus

«flow»

Saabuv SEPA(tagasilükatud)kreedi tkorral dus/ tagastus

«flow»

SaabuvSEPA XMLsõnum

«flow»

SaabuvSEPA XMLsõnum

«flow»

Saabuv SEPA(tagasilükatud)kreeditkorraldus/ tagastus

«flow»

Saabuv SEPA(tagasi lükatud)kreeditkorraldus /tagastus

«flow»

«use»

Saabuv SEPAXML sõnum

«flow»

Väljuv SEPA XML sõnumifail

«flow»

45

Evitusdiagrammdeployment Deployment Model

«device»Automaatsete protsesside

rakendusserv er

«device»Andmebaasiserver

SEPA sõnumite andmebaas

Kreeditkorralduste andmebaas

SEPA vahendaja

«device»Sõnumijadaserver

Laekuv jada

Väljuv jada

«device»Rakendusserver

Kreeditkorralduste töötlemise server

Kreeditkorralduste töötlemise klient

«device»Failiserver

SEPA sõnumite hoidla

«use»

TCP/IP

*

TCP/IP

1

«use»

«use»

«use»

«use»

OCI

TCP/IP

«use»

JDBC

46

5. Kokkuvõte ja järeldused

Käesolevas töös kirjeldatakse autori poolt läbi viidud analüüsi projektile „Ühtse

euromaksete piirkonna kreeditkorralduste analüüs” firma X näitel. Eesmärgiks oli välja

selgitada SEPA kreeditkorraldusskeemis kaudse liikmena osaleva firma

kreeditkorralduste vahendamist ja töötlemist võimaldav funktsionaalsus.

Töö alguses on antud ülevaade SEPA olemusest, projektiga seotud huvipooltest ning

projekti skoobist. Samuti on kirjeldatud kasutatud tehnikaid ning notatsioone.

Töö põhiosas on kirjeldatud SEPA kreeditkorraldusskeemi poolt esitatavad ärinõuded ja

nende mõju olemasolevale äriprotsessile, ärinõuetest ja kehtivast praktikast tulenevad

funktsionaalsed nõuded ning neid esitavad kasutuslood, detailne andmemudel ning

arhitektuurimudelid.

Võimalikud edasiarendused: sõnumite arhiveerimine, kreeditkorralduse saatmine SWIFT

sõnumina, kui SEPAga ei õnnestu.

47

Summary

Kasutatud kirjandus

Lisad

Lisa X. Detailse kasutusloo näide

UC02: Registreeri väljuva SEPA kreeditkorralduse tagastuse sõnumi andmed

Üldine kirjeldusVäljuva kreeditkorralduse tagastuse andmete kontrollimine ja sõnumi andmete

salvestamine.

Peastsenaarium1. Kreeditkorralduste töötlemise süsteem edastab korralduse saata kreeditülekande

tagastus saaja pangale.

2. Süsteem kontrollib esialgse saabunud kreeditkorralduse olemasolu.

3. Süsteem loeb esialgse saadetud sõnumi andmeid.

4. Süsteem kontrollib, et esialgne sõnum ei ole juba tagastatud.

48

5. Süsteem kontrollib tagastussõnumi andmeid:

5.1. Tagastuse identifikaator on täidetud ja unikaalne

5.2. Tagastuse arvelduskuupäev on täidetud ja väärtus kuulub lubatud vahemikku.

5.3. Tagastatav summa on võrdne esialgse saabunud kreeditkorralduse summaga.

5.4. Tagastuse arveldusmeetod on määratud ja väärtus kuulub lubatud nimistusse.

5.5. Tagastuse algataja andmed on korrektselt täidetud.

5.6. Tagastuse põhjus on täidetud ja väärtus kuulub lubatud nimistusse.

6. Süsteem kopeerib tagastussõnumisse kõik nõutud esialgse kreeditkorralduse andmed.

7. Süsteem salvestab kreeditkorralduse tagastussõnumi andmed.

8. Süsteem märgib sõnumi registreerituks.

9. Süsteem registreerib sõnumiga tehtud sündmuse.

10. Kasutuslugu lõppeb.

Alternatiivne stsenaarium2a. Esialgset saabunud kreeditkorraldust ei leita.

2a1. Süsteem annab vea: "Esialgset kreeditkorraldust ei õnnestu leida!"

2a2. Kasutuslugu lõppeb

4a. Esialgne sõnum on juba tagastatud.

4a1. Süsteem annab vea: "Kreeditkorraldus on juba tagastatud!"

4a2. Kasutuslugu lõppeb.

5a. Tagastuse identifikaator ei ole täidetud.

5a1. Süsteem annab vea: "Tagastuse identifikaator peab olema täidetud!"


49

5b. Tagastuse identifikaator ei ole unikaalne.

5b1. Süsteem annab vea: "Tagastuse identifikaator peab olema unikaalne!"

5b2. Kasutuslugu lõppeb.

5c. Tagastuse arvelduskuupäev ei ole täidetud.

5c1. Süsteem annab vea: "Tagastuse arvelduskuupäev peab olema täidetud!".

5c2. Kasutuslugu lõppeb.

5d. Tagastuse arvelduskuupäev on minevikus.

5d1. Süsteem annab vea: "Tagastuse arvelduskuupäev ei tohi olla minevikus!"

5d2. Kasutuslugu lõppeb.

5e. Tagastuse arvelduskuupäev on kaugemal tulevikus kui X päeva.

5e1. Süsteem annab vea: "Tagastuse arvelduskuupäev on liiga kaugel tulevikus!"

5e2. Kasutuslugu lõppeb.

5f. Tagastatav summa ei ole võrdne esialgselt saabunud kreeditkorralduse summaga.

5f1. Süsteem annab vea: "Tagastatav summa ei klapi esialgse kreeditkorraldusega!"

5f2. Kasutuslugu lõppeb.

5g. Tagastuse arveldusmeetod ei ole määratud.

5g1. Süsteem annab vea: "Tagastuse arveldusmeetod peab olema määratud!"

5g2. Kasutuslugu lõppeb.

5h. Tagastuse arveldusmeetodi väärtus ei kuulu lubatud nimistusse.

5h1. Süsteem annab vea: "Tundmatu tagastuse arveldusmeetod!"

5h2. Kasutuslugu lõppeb.

50

5i. Tagastuse algataja andmed on puudu või ebakorrektselt täidetud.

5i1. Süsteem annab vea: "Tagastuse algataja andmed puudu või ei vasta formaadile!"

5i2. Kasutuslugu lõppeb.

5j. Tagastuse põhjus ei ole täidetud.

5j1. Süsteem annab vea: "Tagastuse põhjus peab olema määratud!"

5j2. Kasutuslugu lõppeb.

5k. Tagastuse põhjus ei kuulu lubatud nimistusse.

5k1. Süsteem annab vea: "Tundmatu tagastuse põhjus!"

5k2. Kasutuslugu lõppeb.

7a. Tagastussõnumi andmed salvestamine ebaõnnestub.

7a1. Süsteem tühistab tehtud muudatused.

7a2. Süsteem annab vea: "Tagastussõnumi andmete salvestamine ebaõnnestus!"


8a. Sõnumi staatuse muutmine ebaõnnestub.


8a2. Süsteem annab vea: "Tagastussõnumi registreerimine ebaõnnestus!"


9. Sõnumiga tehtud sündmuse registreerimine ebaõnnestub.


9a2. Süsteem annab vea: "Tagastussõnumi registreerimissündmuse lisamine

ebaõnnestus!"


51

EeltingimusedKreeditkorralduste töötlemise süsteem on töödelnud saabunud kreeditkorralduse ja

määranud selle tagastatavaks.

JäreltingimusedKreeditkorralduse tagastussõnum staatuses 'Registreeritud' on salvestatud.

52

Lisa X. Väljuva SEPA XML sõnumi olekudiagramm

stm OutgoingMessageLifecycle

Registreeritud

Saadetud Vigane Tühistatud

Vastuv õetud Tagasilükatud

[sõnum tagasilükatud]/teavita monitooringut[sõnum vastuvõetud]

Otseliigesaadab vastuse

Kasutaja tühistab sõnumi enne väljasaatmist

[koostamine või saatmine ebaõnnestus]/teavita monitooringut

[koostamine jasaatmine õnnestus]

Süsteem koostab jasaadab SEPA XMLsõnumi

Sõnumsalvestatakseandmebaasi

Olekute kirjeldused

53

Lisa X. Saabuva SEPA XML sõnumi olekudiagramm

stm IncomingMessageLifecycle

Ootab automaatset töötlust

Arhiv eeritud ilma töötluseta

Töödeldud

Vigane

Ootab käsitsitöötlust

Registreeritud

Süsteem saadab sõnumiautomaattöötlusesse[automaatne töötlus võimal ik]

Süsteem kontrol libautomaatse töötlusevalmidust

Sõnumsalvestatakseandmebaasi

Süsteem saadab sõnumi käsitsi töötlusesse[automaatne töötlus pole võimalik]

Kasutaja saadab sõnumikäsitsi töötlusesse

Kasutajaarhiveerib sõnumiilma töötluseta

Kasutaja töötleb sõnumi käsitsi

[automaattöötlusebaõnnestub]/teavita monitooringut

[automaattöötlus õnnestub]

Süsteem alustab sõnumi töötlust[vastab tingimustele]

Süsteem saadab sõnumi käsitsi töötlusesse[ei vasta tingimustele]

Süsteem kontrol l ib sõnumivastavust automaattöötlusetingimustele

Olekute kirjeldused

Lisa X. Andmetabelite kirjeldused

Documents

Jan Matveus PROJEKTI „ÜHTSE EUROMAKSETE …enos.itcollege.ee/~lepikult/diplomitoo/naidistood/Matveus.pdf · REJ - Tagasilükatud SEPA kreeditkorraldus (O-le) - otseliikmele