OLISS [1]

Republika Slovenija
Služba Družbenega Knjigovodstva
centrala v Ljubljani

Sektor za Računalniško Obdelavo Podatkov

61000 LJUBLJANA
Cankarjeva 18

O N
L I N E
I  N F O R M A C I J S K I
S E R V I S
S D K

Ljubljana, junij 1992

© SDK v Republiki Sloveniji

Zamisel za projekt [2]

Računalniškega izmenjevanja podatkov med SDK in pravno osebo

Interes SDK

Za računalniško izmenjevanje dokumentov je Služba družbenega knjigovodstva zainteresirana iz več razlogov, ki so deloma operativne narave, deloma pa se tičejo načina financiranja Službe. Kot operativne lahko opredelimo

- zmanjšanje števila plačilnih nalogov, ki jih je treba zajemati,

- povečanje produktivnosti dela v Službi in

- podaljšanje časa sprejemanja nalogov.

Razlog, ki izvira iz narave financiranja Službe, je ta, da se nadomestilo za delo Službe (tarifa Službe) obračunava od debetnega prometa na žiro računih, ki so jih uporabniki dolžni voditi pri Službi družbenega knjigovodstva. S sredstvi na teh računih Služba ne sme razpolagati, če se hitreje obračajo, pa to pomeni večji priliv iz naslova tarife.

Interes podjetja

Za vsako uvedbo računalniškega izmenjevanja podatkov obstaja interes tudi v gospodarstvu. Na kratko komentirajmo le nekaj potencialno zanimivih področij:

- povečanje produktivnosti dela Službe glede na to, da se Služba financira iz tarife, ki jo plačuje gospodarstvo, je to zainteresirano, da je Služba, ki jo financira, bolj produktivna,

- hitrejše obračanje sredstev,

- znižanje stroškov poslovanja,

- povečana konkurenčna sposobnost podjetja,

- možnost kontrole in usmerjanja finančnih tokov.

Organizacijsko tehnična rešitev mora pokrivati področje plačilnega prometa in statističnih obdelav SDK v povezavi z delovanjem pravnih oseb. Omogočati mora opravljanje računalniškega izmenjevanja podatkov brez bistvenih investicij v obstoječe resurse Službe, predvsem na področju komunikacij mora biti orientirana v smer uporabe javnih poštnih storitev.

Plačilni promet

Na področju plačilnega prometa (plačilni promet in on-line informacijski servis) mora prototip omogočati možnost prenosa podatkov s plačilnega naloga in vpogled v stanje sredstev računov v datotekah plačilnega prometa Službe, oboje z oddaljene lokacije. V posebnem mora obsegati

- zajem in kontrolo splošnega prenosnega naloga v podjetju,

- prenos naloga v X.400 poštni predal SDK,

- prevzem naloga iz poštnega predala in vključitev v obdelavo plačilnega prometa,

- obdelavo,

- pošiljanje obvestil o opravljeni transakciji v poštni predal podjetja in

- vpogled banke v stanje računov komitentov.

Posebej mora biti v okviru tega področja obdelana možnost varovanja integritete podatkov, zaščita dostopa do podatkov in avtorizacija pooblaščenih delavcev v podjetju, ki lahko take transakcije opravljajo.

Statistične obdelave

Na področju statističnih obdelav mora prototip omogočati vpogled v določene zbirke podatkov in sicer

- periodične obračune,

- zaključne račune,

- katalog podatkov,

- baze podatkov pod SQL/DS,

ki bo mogoč preko oddaljenega terminala, instaliranega pri uporabniku (pravni osebi), avtoriziran za vpogled v te zbirke podatkov.

Za obe kategoriji transakcij je treba proučiti in eventualno realizirati možnost uporabe standarda UN/EDIFACT.

Opis tehnične izboljšave [3]

Opis tehnične izboljšave

Prototipna rešitev on-line informacijskih servisov SDK obsega organizacijo in programski del. Pri končni izvedbi sta sodelovali podjetji Merkur iz Kranja in Kovinotehna iz Celja kot poskusni lokaciji zunaj SDK, vseskozi pa PTT podjetje Ljubljana in SDK Centrala v Ljubljani. Prototipna rešitev se je razvijala od leta 1989 in obsega

- zajem in kontrolo splošnega prenosnega naloga v podjetju,

- prenos naloga v X.400 poštni predal SDK,

- prevzem naloga iz poštnega predala in vključitev v obdelavo plačilnega prometa,

- obdelavo,

- pošiljanje obvestil o opravljeni transakciji v poštna predala podjetij,

- vpogled v stanje računa podjetij (za banko račun banke in računi njenih komitentov, če jo pooblastijo),

- vpogled v register imetnikov računov (RIR) in  - vpogled v zbirke podatkov pod SQL/DS.

Prototip je toliko izpopolnjen, da je primeren za poskusno uvedbo v poslovanje podjetij in SDK, ter da bi bil lahko naslednji korak v razvoju le še poskusno delo. Druge funkcije OLISS, ki so tudi že razvite in so bile javno prikazane, je mogoče v prototip vključiti brez bistvenih težav.

Bistvena prednost rešitve pred drugimi je v tem, da je sistem zaščite izpopolnjen in omogoča zaščito finančnih transakcij, ki so nečitljive za vse razen za udeleženca v finančni transakciji. Rešitev ni vezana na izmenjavanje podatkov med pravnimi osebami, temveč jo je mogoče uporabiti tudi za izmenjavanje podatkov znotraj SDK in sicer za vse funkcije, ki so sicer na voljo pravnim osebam.

Tehnična izboljšava OLISS [4]

OLISS (On-Line Informacijski Servisi SDK) je skrajšano ime za organizacijsko - tehnično izboljšavo delovanja SDK z razširitvijo uporabe podatkovnih baz SDK in njene računalniške mreže. Bistvene nove funkcije, ki jih OLISS omogoča, so izvajanje naslednjih transakcij z lokacije zunaj organizacijskih enot SDK:

- zajem podatkov splošnega prenosnega naloga na lokaciji zunaj SDK,

- prenos podatkov in vključitev v obdelavo podatkov plačilnega prometa,

- vpogled v stanje računa podjetja ali banke (za banko tudi v stanje računov njenih komitentov),

- vpogled v register imetnikov računov (RIR) in iskanje podatkov v njem,

- vpogled in iskanje podatkov v zbirkah podatkov, ki so vodene pod upravljavskim sistemom za baze podatkov SQL/DS,

Opis tehnične izboljšave

Prototipna rešitev on-line informacijskih servisov SDK obsega organizacijo in programski del. Pri končni izvedbi sta sodelovali podjetji Merkur iz Kranja in Kovinotehna iz Celja kot poskusni lokaciji zunaj SDK, vseskozi pa PTT podjetje Ljubljana in SDK Centrala v Ljubljani. Prototipna rešitev se je razvijala od leta 1989 in obsega

- zajem in kontrolo splošnega prenosnega naloga v podjetju,

- prenos naloga v X.400 poštni predal SDK,

- prevzem naloga iz poštnega predala in vključitev v obdelavo plačilnega prometa,

- obdelavo,

- pošiljanje obvestil o opravljeni transakciji v poštna predala podjetij,

- vpogled v stanje računa podjetij (za banko račun banke in računi njenih komitentov, če jo pooblastijo),

- vpogled v register imetnikov računov (RIR) in  - vpogled v zbirke podatkov pod SQL/DS.

Shema 1: Izvedba finančne transakcije

Prototip je toliko izpopolnjen, da je primeren za poskusno uvedbo v poslovanje podjetij in SDK ter da bi bil lahko naslednji korak v razvoju le še poskusno delo. Druge funkcije OLISS, ki so tudi že razvite in so bile javno prikazane, je mogoče v prototip vključiti brez bistvenih težav.

Shema 2: Okolje izvedbe prototipne rešitve

Bistvena prednost rešitve pred drugimi je v tem, da je sistem zaščite izpopolnjen in omogoča zaščito finančnih transakcij, ki so nečitljive za vse razen za udeleženca v finančni transakciji. Rešitev ni vezana na izmenjavanje podatkov med pravnimi osebami, temveč jo je mogoče uporabiti tudi za izmenjavanje podatkov znotraj SDK in sicer za vse funkcije, ki so sicer na voljo pravnim osebam.

Način uveljavitve predloga

Predlog je mogoče uveljaviti tako, da se ga kot ustrezen projekt vključi v delovne načrte SDK. Določiti je treba delovno skupino, ki bo že razvit in delujoč prototip dodelala v ponudbo nove storitve SDK. Ocena je, da je to mogoče realizirati v času treh mesecev. Implementacija rešitve kot ponudbe nove storitve SDK v okviru skupine, ki je OLISS razvijala, ni bila mogoča, ker presega možnosti in kompetence posameznih članov skupine.

Podatki o prihrankih

Dejanske prihranke lahko pričakujemo v SDK in pri pravnih osebah:

- v SDK manjši stroški zajemanja podatkov,

- pri uporabnikih hitrost poslovanja

OLISS predstavlja v bistvu novo ponudbo SDK za storitve na področju plačilnega prometa in glede pristopa do podatkovnih zbirk SDK. Mogoče ga je razširiti tudi na bonitetno službo in morebitna druga za uporabnike storitev SDK zanimiva področja. Eksplicitni prihranek, ki ga SDK lahko pričakuje in tudi ovrednoti, je zmanjšanje zajema podatkov plačilnega prometa in drugih podatkov, ki jih SDK še zbira, bi se pa lahko posredovali preko OLISS-a. Ocena je, da se v razvitih državah okoli 70 % finančnih transakcij lahko posreduje preko take tehnike, kar pomeni v končni fazi zmanjšanje stroškov zajema podatkov in s tem povezanih investicij v opremo za približno enak odstotek.

Drugo pomembno dejstvo je, da se z OLISS-om odpre možnost, ki jo v finančnem smislu omogoči nova storitev. Poleg tega se lahko za pravne osebe, ki bi poslovale tako, podaljša čas dostave virmanskih nalogov.

Za pravne osebe pomeni ta servis učinkovitejše poslovanje in boljšo kontrolo finančnih tokov nižje stroške posredovanja podatkov SDK.

Stroški pri razvijanju tehnične izboljšave

OLISS se je pričel razvijat na pobudo Fakultete za organizacijske vede iz Kranja kot eden od možnih pristopov k računalniškemu izmenjavanju podatkov. Za razvoj te organizacijsko tehnične rešitve posebna sredstva ali investicije niso bile potrebne. Nekatere naprave in programske produkte, ki so bili potrebni za razvoj prototipne rešitve, so posodili dobavitelji in/ali proizvajalci te opreme. Poudariti je treba, da je bil OLISS razvit v celoti zunaj okvira rednih delovnih zadolžitev, kar dokazuje tudi dejstvo, da redno delo in projekti SDK zaradi razvijanja OLISS-a niso bili v zaostanku. Posebnih ali dodatnih stroškov pri razvijanju OLISS zato ni bilo.

Druge navedbe

OLISS je bil v različnih razvojnih fazah javno predstavljen v strokovnem krogu organizacij, ki so aktivno sodelovale v raziskovalni nalogi Fakultete za organizacijske vede. Končna rešitev je bila prezentirana junija 1992 in je bila ocenjena v strokovnih krogih kot pomemben pozitiven prispevek v načinu poslovanja.

OLISS je bil predstavljen tudi na 10. seji kolegija direktorjev SDK v R Sloveniji dne 27. septembra 1991. Mnenje kolegija je bilo, da je treba OLISS čimprej uvesti, in sprejet sklep, da se nabavi programski produkt, ki omogoča enostavnejše komuniciranje preko javnega poštnega servisa X.400.

Tehnične specifikacije [5]

Uvod

OLISS je APS (Aplikacijski Programski Sistem), ki omogoča izmenjevanje različnih podatkov s pomočjo elektronske pošte.

Sedanji način dela in izmenjavanja podatkov med SDK in pravnimi osebami poteka na vsakodnevnem izmenjavanju dokumentov - papirjev. To se lahko izvede večkrat dnevno, vedno pa takrat, ko pride do transakcije - plačila.

Cilj OLISS je, da se omogoči večkrat dnevno izmenjavanje podatkov brez fizične prisotnosti dokumentov - papirjev in z uporabo javne storitve pri PTT tj. elektronske pošte ali X.400 ali MHS (Message Hendling Service) in z uporabo SIPAK javnega omrežja za paketni prenos podatkov po standardu X.25.

Naloga OLISS je, da obdela različne zahtevke različnih pravnih oseb. OLISS sestavljajo različni APS pri pravnih osebah in pri SDK z namenom enotnega pristopa do podatkov, ki jih obdeluje in hrani SDK na svojih računalniških sistemih.

Na HW nivoju je OLISS računalniški sistem PC in host računalniškim sistemom serije IBM 4300. IBM 4381 model R14 računalniški sistem je v Ljubljani glavno vozlišče TP mreže SDK v R Sloveniji, ki povezuje 4 sisteme IBM 4300 in 10 sistemov UNISYS serije A.

IBM računalniški sistemi v SDK so med seboj povezani v CROSS DOMAIN s pomočjo NCP, VTAM, POWER in CICS. UNISYS računalniški sistemi so povezani z Ljubljano s pomočjo POWER RJE in emulacijo RJE 3770.

Osebni računalnik PC v funkciji FEP (Front End Procesor) predstavlja edina vhodna vrata zunanjih uporabnikov v SDK.

Komunikacija s PTT

Komunikacija s PTT se opravlja s pomočjo vmesnika (interface) med javnim omrežjem SIPAK - X.25, X.400 na eni strani in z uporabnikom SDK (client, proprietary sistem) na drugi strani.

Prenos sporočila od PTT na PC in obratno

Po uspešno vzpostavljeni zvezi med PC in PTT in če je treba prenesti sporočilo, se le-to prenese na PC računalnik SDK.

To so sporočila - rezultati obdelave na host računalniškem sistemu. Iz host računalniškega sistema se sporočila prenesejo na PC v različne datoteke z naključno izbranimi imeni v skupen poddirektorij.

Pripravljene so tudi datoteke, ki so rezultat lokalne obdelave tj. obdelave na samem osebnem računalniku PC - brez posredovanja host računalniškega sistema.

Varnost

Vsako sporočilo, ki pride iz PTT X.400 sistema na SDK računalniški sistem se na PC ustrezno pregleda in preveri.

Vzdrževanje tabel

Vse tabele, konstante in podatki so zapisani izven programske kode v eni ali več tekstualnih datotekah.

Vsaka sprememba v podatkih teh zunanjih tabel lahko takoj vpliva na delovanje programa ali programov sistema OLISS, vedno pa ob startu posameznega APS ali klicanju programa na izvajanje.

Povezovanje računalnika s PC

Za povezavo PC in računalniškega sistema skrbi poseben interface  PIPS. Na IBM računalniškemu sistemu se uporablja posebna CICS transakcija, na PC strani pa program, napisan v "C" ali v "CLIPPER" programskem jeziku in z dodatkom posebnih rutin (HLAPI) za povezavo in prenos datotek PC - host.

Statistika

Vsa sporočila v ali iz OLISS se beležijo v ustrezne podatkovne zbirke. Vsem sporočilom se vedno doda še tekoči datum in ura obdelave. Te podatkovne zbirke posebni programi v off-line obdelavi, ki pa so sestavni del OLISS, obdelajo po različnih kriterijih in izpišejo ustrezna statistična poročila.

Obdelovanje napak

V primeru napake na komunikacijah se to zabeleži v ustrezno datoteko. Istočasno se kreira posebno sporočilo o takšni napaki. Ob prvi naslednji uspešni vzpostavitvi zveze se pošlje tudi to sporočilo na ustrezen naslov (pravna oseba, OLISS, host, arhiv).

Lokalna obdelava podatkov

Aplikacijski programski sistem OLISS, ki se izvaja na računalniškem sistemu IBM PC, vsebuje tudi funkcijo za lokalno obdelavo. To so vsi tisti zahtevki - sporočila, ki zahtevajo podatke npr. iz Republiškega Registra Imetnikov Računov - RRIR.

Pošiljanje rezultatov do naslovnika je identično kot za sporočila prejeta iz host računalniškega sistema.

Komponente PC

IBM PC-DOS verzija 3.3 ali višja je izbrana kot osnovni operacijski sistem.

Za povezavo PC računalniškega sistema z IBM računalniškim sistemom se uporablja IBM Personal Communications/3270 (PC/3270) in programski vmesnik PIPS (Programski Interface PS), ki je bil izdelan za potreba SDK.

Programski jezik na PC računalniškem sistemu je "C" in "CLIPPER" za programe, ki obdelujejo statistične podatke.

Za potrebe OLISS je izbrana strojna oprema IBM PC - 386 ali večji oziroma ustrezna kompatibilna konfiguracija. Minimalna zahteva je vsaj 150 MB na trdem disku.

Povezava računalniškega sistema PC s PTT javnim paketnim omrežjem X.25 SIPAK bo narejena preko COMM izhoda na PC in s posredovanjem protokol konvertorja. Protokol konvertor sprejema podatke s PC in oddaja paketni protokol X.25 v SIPAK omrežje in obratno.

Programski vmesnik za OLISS komunikacijo z X.400 javnim PTT omrežjem bo izdelan po priporočilu X.400 Gateway Application Program Interface (API) Specification.

Uporabiti in izbrati je treba orodje, ki omogoča prenos privatnih uporabniških sporočil v/iz standardni X.400 elektronski poštni servis.

Računalniški sistem IBM

Računalniški sistem je IBM 4381 model R14. Vsebuje ustrezne periferne enote diske, trakove, printerje, komunikacijske kontrolerje itd.

Osnovni operacijski sistem je VSE/SP, ACF/VTAM, ACF/NCP, CICS/VS. Vse skupaj je lahko pod kontrolo VM/XA SP.

Za zvezo med host in PC računalniškim sistemom se uporablja CICS transakcija, ki skupaj s PC vmesnikom PIPS in ustreznim programom omogoča prenos podatkov - File Transfer.

Računalniški sistem UNISYS

V osnovi bo celotna SW in HW rešitev in oprema PC računalniškega sistema omogočala tudi ustrezno povezavo in komunikacijo z UNISYS računalniško opremo.

Primarna in osnovna je izdelava takšnega vmesnika OLISS, ki bo omogočal stik z IBM host računalniškim sistemom.

Program za zajem podatkov [6]

UVOD

APS IPON (Interaktivni Postopek Obdelave Nalogov) plačilnega prometa je namenjen interaktivnem zajemu nalogov plačilnega prometa na osebnih računalnikih in je v uporabi v organizacijskih enotah SDK, kjer se ta zajem izvaja.

Osnovna verzija programa je dopolnjena tako, da dovoljuje zajem podatkov ne le interaktivno v enotah SDK, po posameznih nalogih, ampak tako, da uporabnik dostavi podatke na disketi, ki se potem s programom IPON preverijo in se naprej vključijo v obdelavo na centralnem računalniku skupaj z nalogi, ki so interaktivno zajeti.

Za potrebe programskega sistema OLISS smo uporabili drugo možnost, ki jo dovoljuje IPON.

Da bi bolje razumeli sistem zajemanja nalogov plačilnega prometa bomo na kratko predstavili eden in drugi način zajemanja nalogov.

Interaktivni zajem

Nalogi plačilnega prometa se zajemajo in obdelujejo organizirani v največje  enote - trakove. Trakovi se označujejo s triciferno številko, ki je neponovljiva v enem dnevu. Sestavljeni so iz logičnih celot. Znotraj enega traku je poljubno število logičnih celot. V logični celoti sta dve vrsti zapisov: minusni in plusni. Minusni zapis je eden v logični celoti. Vsebuje žiro račun nalogodajalca, kontrolno vsoto ter še nekaj drugih podatkov potrebnih za obdelavo. Plusnih zapisov je več v eni logični celoti. Vsebuje individualne podatke iz virmana. Kontrole vnosa: en trak, kontrolne vsote, šifranti

Pri interaktivnem vnosu nalogov plačilnega prometa se sproti izvaja pravilnost ter usklajenost podatkov. Dovoljen je vnos enega traku le enkrat. Logične celote se kontrolirajo s kontrolnimi vsotami (vsota vseh zneskov v plusnih zapisih je enaka znesku v minusnem zapisu). Vsi SDK podatki (žiro računi, šifre DR, vezne oznake,...) se kontrolirajo v šifrantih.

Popravek nepravilnih podatkov

Neusklajenost med podatki se sproti kontrolira ter program zahteva takojšnje popravke. Kljub temu se lahko naknadno interaktivno izvršijo popravki na kateremkoli podatku. Zadnja kontrola pravilnosti podatkov programa IPON se izvaja pri pripravi datoteke, ki se po končanem zajemu prenese v centralni računalnik in se vključi v plačilni promet.

Priprava datoteke PPSLA.TXT

Po končanem vnosu nalogov se izvrši priprava podatkov za prenos na centralni računalnik za obdelavo. Rezultat priprave je ASCII datoteka z imenom PPSLA.TXT formata S1QUEUE (to je format, ki je rezultat zajema podatkov na računalnikih tipa SERIJE/1, s katerimi se potem v obdelavi združi).

Paketni zajem

Program IPON je dopolnjen tako, da namesto interaktivnega zajema nalogov plačilnega prometa omogoča zajem podatkov iz datoteke - paketno. Nalogi plačilnega prometa so v ASCII datoteki organizirani v formatu zbirnega naloga (SDK obrazec 47). Datoteka se mora nahajati na disketi ali na disku. Ime datoteke je oblike MNxxxxxx.SDK, pri čemer je xxxxxx šifra, ki jo dodeli SDK uporabniku. Nepomembno je, na katerem računalniku je narejena datoteka. Bistveno je le, da je ASCII ter ustreznega formata.

Pred zajemom podatkov iz datoteke program zahteva vnos podatkov, ki jih potem kontrolira v datoteki: šifra uporabnika, njegov žiro račun, datum podatkov. Določiti je potrebno še področje, kje se nahaja datoteka (disk ali  disketa). Po uspešnem preverjanju pravilnosti vnesenih podatkov se izvaja branje podatkov s sprotno vsebinsko kontrolo (zneski, žiro računi uporabnikov, šifre,...). Če podani in podatki v datoteki niso usklajeni, se izpiše vrsta napake in se branje podatkov prekine. V primeru, da ni napak med podatki, se po končanem branju izpiše opozorilo, da so podatki uspešno prebrani in prekontrolirani.

V primeru, ko podatki niso pravilni, se branje prekine in operater se odloči ali bo nadaljeval branje ali pa bo sproti odpravil napako. Če se odloči za naknadno popravljanje napak, se bo ob koncu branja datoteke izpisalo število napak. V nasprotnem primeru pa se program pozicionira ne nepravilen podatek.

Naknadno popravljanje podatkov se izvaja relativno enostavno. V meniju se izbere vrsta popravka ter podatek, ki se želi popraviti.

Potem, ko so prebrani podatki iz datoteke, se shranijo na diskih v bazah v enaki obliki, kot da so vneseni interaktivno. Shranjeni so pod številko paketa 0. To pomeni, da se vsi podatki, ki se preberejo iz datotek, shranijo pod skupno številko 0. Na ta način je omogočeno združevanje podatkov iz več datotek. Številka paketa 0 je le delovna številka. Pred pripravo datoteke PPSLA.TXT je potrebno podatkom iz traku številka 0 dodeliti eno triciferno številko, s katero bodo podatki obdelani v centralnem računalniku. Postopek dodeljevanja številke traku je enostaven in se izvaja prek menijev, kakor tudi večina operacij v programu.

Datoteka PPSLA.TXT se pripravi na enak način kakor za podatke, ki so bili interaktivno zajeti. V eni datoteki se lahko nahaja največ 5 trakov. Nekateri izmed teh so lahko zajeti interaktivno, drugi pa iz paketno.

Osnove delovanja programa OLISS

OLISS je program, ki je namenjen uporabnikom, ki so vključeni v izmenjavo podatkov preko poštnih predalov. Uporabniki so evidentirani pri SDK in se jim dovoli izmenjava podatkov po sistemu OLISS.

OLISS je program, ki je organiziran na principu večnivojskih menijev. Zelo enostaven je za uporabo, ker od uporabnika ne zahteva nobenega dodatnega znanja. Uporabnik v meniju s pritiskom na tipko <Enter> izbere vrsto zahtevka, ki ga bo poslal v SDK. Vsi zahtevki potekajo preko žiro računov pravnih oseb. Uporabnik lahko pripravlja le tiste zahtevke, ki so dovoljeni. Zahtevki se s pomočjo komunikacijskih orodij prenesejo v SDK, kjer se obdelajo ter se v obliki odgovorov po isti poti vrnejo nazaj uporabniku. Ta jih z OLISS-om pregleda. Zahtevki in odgovori se arhivirajo in se brišejo na zahtevo uporabnika. Poleg odgovorov na zahtevke uporabnik lahko dobi obvestila v zvezi z nalogi plačilnega prometa.

Za vse zahtevke ter odgovore se zapišeta datumi in ure, tako da je mogoč kronološki pregled izvajanja zahtevkov.

Predstavitev uporabnika

Po startu programa OLISS se zahteva vnos šifre uporabnika. To je ime, ki si ga uporabnik sam določi. S tem imenom mora obstajati poddirektorij v strukturi direktorijev OLISS. Na tem direktoriju se bodo shranjevali vsi podatki v zvezi s tem imenom (zahtevki in odgovori). Poleg tega mora s tem imenom in podaljškom TXT na istem direktoriju obstajati datoteka, v kateri je zapisan osnovni žiro račun uporabnika. Ta žiro račun se vedno ponudi kot osnovni račun, za katerega se pripravljajo zahtevki.

Po predstavitvi uporabnika se ponudijo meniji:

• priprava zahtevkov,
• pregled odgovorov,
• servis,
• konec.

Priprava zahtevkov

Vsak zahtevek vsebuje podatke o žiro račun uporabnika, za katerega se zahtevajo podatki, tip zahtevka, datum in ura zahtevka. Zahtevek se hrani v datoteki ZAHTEVEK.DBF vse dokler se ne dobi odgovor na zahtevek, ko se prenese v arhivsko datoteko zahtevkov ZAHTEVKI.DBF ali pa se briše.

OLISS ponuja možnost dajanja naslednjih vrst zahtevkov:

• Tip 1: matični podatki (saldo na računu in dnevni promet)
• Tip 2: podružnični register (osnovni podatki iz registra podružnice)
• Tip 3: republiški register (osnovni podatki iz republiškega registra)
• Tip 4: komitenti banke (obsvetilo za banko o prilivu in odlivu)
• Tip 5: promet (dnevni promet po nalogih)
• Tip 6: statistika (periodični obračun)

Zahtevki se lahko dajo le za podatke, ki so na razpolago. Matični podatki ter podatki iz podružničnega registra se lahko dobijo za račune iz domače podružnice.

Pregled odgovorov

Odgovori se dobijo v ASCII datoteki z imenom uporabnika ter podaljškom ODG. Pri startu programa se novi odgovori shranijo v datoteko ODGOVOR.DBF in se ob prvem pregledu le-teh prenesejo v arhivsko datoteko ODGOVORI.DBF. Vsi odgovori vsebujejo naslednje podatke: žiro račun uporabnika, tip podatkov (zahtevka), datum in ura priprave odgovora ne centralnem računalniku v SDK ter del, v katerem se nahajajo dejanski podatki za odgovor na zahtevek.

Poleg odgovorov na zahtevke (tip 1 do 6) se pojavljata še dva tipa odgovorov in sicer:

• Tip 7: obvestilo o odlivu sredstev zaradi vključitve nalogov, pripravljenih s programom IPON in _e obdelanih v SDK, ter
• Tip 8: obvestilo o prilivu sredstev (druga pravna oseba je s programom IPON pripravila naloge, ki so _e obdelani v SDK).

Pri vseh tipih podatkov se izvaja pregled odgovorov na ta način, da se znotraj vseh odgovorov, ki so izlistani na zaslonu, izberemo _želenega ter ga s pritiskom na tipko <Enter> pregledamo v formatirani obliki.

Izbira medija za odgovore

Medij izpisa odgovorov lahko poljubno izbiramo. Če ne določimo drugače, se podatki izpisujejo na zaslonu. Sicer pa lahko še izbiramo med tiskalnikom ter ASCII datoteko. Predvsem je zanimiva ta druga oblika, ker lahko podatke neposredno vključujemo v druge APS-je.

Vzdrževanje baze odgovorov

Podatki o zahtevkih in odgovorih so shranjeni na disku vse dokler se ne brišejo na zahtevo uporabnika. Podatki se brišejo za določeno obdobje. Pri izbiri te možnosti se ponudita datum in ura najstarejšega ter najmlajšega podatka. Lahko se brišejo vsi podatki s potrditvijo ponujenih podatkov, ali pa se znotraj tega časovnega obdobja določi nov, za katerega naj se brišejo podatki.

Za vse podatke, ki so na disku, je mogoč pregled kronologije zahtevkov in odgovorov s časi zahtevkov in priprav odgovorov na le-te.

Opis sistema zaščite transakcij [7]

OBLIKOVANJE ZAHTEV PO ZAŠČITI

Pri prenosu po različnih linijah je treba podatke zaščititi na primeren način. Osnovna zahteva je tajnost oziroma zasebnost podatkov, ki jo lahko zagotovimo s šifriranjem. Pretok "elektronskega" denarja pa zahteva še posebne postopke, imenujemo jih servise, za zagotovitev varne izmenjave sporočil.

Nek uporabnik, imenujmo ga pošiljatelj, želi drugemu uporabniku, ki ga imenujemo prejemnik, poslati neko sporočilo. Prizadevamo si uresničiti naslednje cilje:

1. Prejemnik mora imeti zagotovilo o pošiljateljevi identiteti (elektronski podpis).
2. Prejemnik mora imeti zagotovilo o originalnosti sporočila (elektronski pečat - sporočilo se med pošiljanjem ni spremenilo).
3. Pošiljatelj mora dobiti od prejemnika dokaz o prejemu sporočila (potrdilo o prejemu).
4. Pošiljatelj mora dobiti od  prejemnika dokaz o originalni vsebini sporočila.

Največkrat zahteva varna komunikacija le prva dva servisa: elektronski podpis in elektronski pečat. Če pa želimo opravljati finančne transakcije (npr. prenos in obdelava virmanskega naloga), se hitro pokažejo še dodatne zahteve. Če dodamo k prvima dvema (podpisan in zapečaten virman) še tretji servis, dobimo pošto s potrdilom (prejemnik potrdi prejem virmana). Nič pa ne vemo o integriteti vsebine sporočila (ali je znesek na virmanu pri prejemniku enak tistemu, ki ga je poslal pošiljatelj). To nam zagotavlja šele četrti servis - dokaz o originalni vsebini sporočila.

Opisane štiri servise lahko skupno imenujemo "servis, ki preprečuje zanikanje aktivnosti", ker nam zagotavlja:

1. Pošiljatelj ne more zanikati sporočila, niti njegove vsebine (podpisan in zapečaten virman).
2. Prejemnik ne more zanikati prejema sporočila, niti neavtorizirano spremeniti originalne vsebine (potrdilo o prejemu in originalni vsebini virmana).

Algoritmi

DES (Data Encryption Standard) je simetrični algoritem, ki je sestavljen iz substitucij in transpozicij. Simetrični pomeni, da uporablja en sam, tajni ključ za šifriranje in dešifriranje.

Pri večjem številu uporabnikov, ki med seboj komunicirajo, nastopi problem, znan pod imenom "Key Management", saj se morajo uporabniki vnaprej dogovoriti za ključ in za protokol menjave ključev (DES ključ je namreč priporočljivo spreminjati precej pogosto).

RSA (Rivest, Shamir, Adleman) je asimetrični algoritem, ki temelji na težavnosti faktoriziranja velikih števil. Za šifriranje uporablja javni ključ - to pomeni, da ga vsak uporabnik lahko javno objavi, medtem ko lahko s tajnim ključem, ki ga le sam pozna, dešifrira prejeta sporočila. Omejitev algoritma je njegova počasnost, zato ga za šifriranje daljših sporočil ne uporabljamo. V kombinaciji z nekaterimi drugimi algoritmi pa lahko z RSA realiziramo vrsto drugih servisov, kot so npr. distribucija tajnih ključev, elektronski pečat in podpis.

MAC (Message Authentication Code) je kontrolni niz, s katerim potrjujemo originalnost sporočila. Izračunamo ga z nekim algoritmom, ki nam mora zagotavljati zadostno odvisnost MAC od sporočila (če v sporočilu spremenimo le en znak, se mora spremeniti tudi MAC, izračunan iz spremenjenega sporočila).

Servisi

Od servisov, opisanih v točki 1., lahko najprej realiziramo (1) in (2) in sicer na način, ki nam bo dajal še neke dodatne garancije. Najenostavnejša je konkretna ponazoritev s primerom virmanskega naloga, ki ga pravna oseba pošlje v obdelavo Službi družbenega knjigovodstva:

1. Najprej pravna oseba generira DES ključ (slučajno izbran niz znakov).
2. DES ključ šifrira z javnim RSA ključem SDK.
3. Nalog šifrira z DES algoritmom.
4. Na osnovi naloga izračuna MAC.
5. MAC podpiše s svojim javnim RSA ključem (elektronski podpis).
6. Podpis šifrira z DES algoritmom (elektronski pečat).

S tem si pravna oseba zagotovi, da bo nalog lahko dešifrirala le SDK (tajnost vsebine naloga, avtentičnost SDK). SDK pa ima zagotovljeno identiteto pravne osebe (elektronski podpis) in originalnost vsebine naloga (elektronski pečat).

Naslednji korak je še realizacija servisov (3) in (4) iz točke 1. SDK mora pravni osebi potrditi prejem virmana. Na tem mestu uporabi svoj tajni RSA ključ in podpis zaščiti s tem, da ga šifrira z DES algoritmom. Dokaz o originalni vsebini sporočila pa se lahko sestavi s pomočjo virmana in MAC. Obdelan virman  označimo z nekim indikatorjem in ga pošljemo nazaj pravni osebi, skupaj z novim MAC. Pravna oseba bo imela tako tudi zagotovilo (potrdilo) o originalnosti dokumenta.

Uporaba

Opisani servisi so strukturirani tako, da se lahko uporabljajo za različne vrste povezav, tako "on-line", kot tudi preko poštnega predala. Edina omejitev je realizacija algoritmov na osebnem računalniku.

Opis pristopa do podatkovnih zbirk SDK [8]

NAMEN UPORABE

Računalniško zasnovana rešitev OLISS omogoča vzpostavitev računalniške komunikacije med pravno osebo in računalniškim centrom SDK v Republiki Sloveniji. Ta povezava omogoča uporabo podatkov, ki jih je  SDK po zakonu dolžna zbirati, uporabljajo pa se v različne namene. Pravne osebe, ki te podatke kreirajo, dobijo prve informacije iz agregiranih in obdelanih podatkov z večtedensko zamudo, ki jo povzroči priprava podatkov za publiciranje. Vrsta podatkov, ki jih SDK zbira za različne potrebe, je zanimiva tudi za pravne osebe, pri katerih  podatki nastajajo, pravo analitično moč pa ti podatki dobijo šele z medsebojno primerjavo med več pravnimi osebami ali s primerjavo individualnih podatkov s podatki, agregiranimi na različnih nivojih (občine, področja, panoge, skupine in podskupine dejavnosti). Izračun nekaterih kazalnikov omogoča uporabnikom, da primerjajo knjigovodska stanja lastne organizacije z organizacijami z enako dejavnostjo.

Potencialno največji uporabniki teh podatkov so organizacije in ustanove, ki te podatke nadalje obdelujejo ali uporabljajo v nadaljnjih analizah. Za pridobitev podatkov, njihovo ustrezno oblikovanje in analiziranje morajo danes čakati v vrsti, v kateri pa imajo prednost uporabniki, za katere je SDK dolžna pripravljati podatke po zakonu. Z direktno povezavo z republiškim računalniškim centrom v Ljubljani dobijo vsi uporabniki možnost direktnega dostopa do podatkov, ki so jim bili prej na voljo šele po posebnih zahtevah, odobrenih s strani funkcij SDK in to šele po realiziranju zahtev z aplikacijskimi programskimi sistemi.

Ob tem, da so s ponujeno rešitvijo vsi razpoložljivi podatki dostopni takoj, lahko uporabniki s pomočjo sodobnega interaktivnega jezika podatke analizirajo za lastne potrebe. Za manj zahtevne uporabnike je predvidena uporaba predefiniranih ukazov, ki z minimalnim znanjem omogočajo dostop do podatkov in informacij velikih analitičnih vrednosti.

Strojno, programsko in podatkovno okolje

Za uporabo načrtovane računalniške rešitve je potrebna strojna in programska oprema, ki jo SDK že ima. To so računalnik IBM 4381 s komunikacijsko opremo, poštna komunikacijska infrastruktura in osebni računalnik s klicno telefonsko linijo ali SIPAK priključkom ter komunikacijsko opremo, ki je potrebna za uporabo drugih delov računalniške rešitve OLISS.

Sistem za upravljanje s podatkovnimi bazami v uporabi v računalniškem centru SDK je SQL/DS. To je eden prvih produktov, ki omogočajo upravljanje s podatkovnimi bazami relacijskega tipa. Sistem za upravljanje podatkovnih baz omogoča izgradnjo večstopenjskega sistema zaščite dostopa do podatkovnih virov, uporabo interaktivnega jezika SQL (ISQL), vsebuje pa tudi funkcije, ki jih sodoben sistem za upravljanje s podatkovnimi bazami mora vsebovati (referenčna integriteta, kontrola zaklepanja podatkov, arhiv, kontrola dvojnega ažuriranja, delovni žurnal in drugo). Jezika za definicijo podatkov (DDL - Data Definition Language) ter jezik za povpraševanje po podatkih (SQL - Structure Query Language) sta predstavljala temelj za izdelavo standardov za take jezike. Danes sta oba jezika standardizirana, zato jih vsebuje večina najboljših sistemov za upravljanje podatkovnih baz. Za uporabnika to pomeni, da ukaze, ki jih morebiti že uporablja v sestavi drugih orodij lahko identično uporabi v sistemu OLISS. Seveda pa tudi obratno. Z uporabo standardnega jezika SQL bo uporabnik pridobil znanje, ki ga bo lahko uporabil v večini drugih orodij za delo s podatki.

Podatkovne zbirke s katerimi upravlja SDK neprestano rastejo, že danes pa obsegajo nekaj sto relacij.

Za potrebe projekta OLISS so dane v uporabo evidence o investicijah SDK (INVAR), evidenca o plačilih za posamezne investicije (INVBR), register imetnikov računov (RIR, RUDOK) z zgodovino, bilance stanje (BSTA), bilance uspeha (BUSP), trimesečna poročila (TRIM), razporeditev  sredstev (RAZP), razni šifranti (dejavnosti, občin, podružnic, .....). Vsi periodični podatki se hranijo za obdobje enega leta, šifranti pa se vzdržujejo mesečno.

Z uporabo interaktivnega dostopa do podatkovnih zbirk SDK uporabniki pridobijo na času dostopa do podatkov, zagotovijo uporabo najbolj ažurnih podatkov in uporabo standardnega orodja močne analitične vrednosti.

Delavcem SDK se ob uporabi takega sistema zmanjša obseg dela s prepisovanjem podatkov na različne medije, omogoči uporaba varnostnih mehanizmov zaščite podatkov in s tem poveča čas za kreativnejše delo.

Skupna pridobitev SDK pa je neposreden stik z okoljem, vpliv na javno mnenje ter zmanjšanje stroškov dodatnih računalniških obdelav.

Uporaba interaktivnega dostopa do podatkovnih zbirk SQL ne pomeni nobenega dodatnega investiranja v opremo v SDK in tudi ne pri uporabnikih, saj je potrebna oprema nabavljena za potrebe, ki jih narekuje opravljanje plačilnega prometa.

Opis pristopa v računalniško mrežo SDK [9]

UVOD

Hrbtenica elektronske izmenjave podatkov v sistemu OLISS je javni sistem za elektronsko posredovanje sporočil. MHS (Massage Handling System), ki ustreza standardu X.400 je javna komunikacijska storitev slovenske PTT, z imenom SMail 400. Za MHS je značilno, da ni prisotne neposredne povezave med partnerji, ki komunicirajo, pač pa so med njimi poštni predali, kjer se sporočila vmesno shranjujejo. Uporabnik dobi sporočilo takrat, ko "pogleda" v svoj poštni predal in seveda, če mu je bila poslana pošta.

V primeru aplikacije OLISS pomeni to vsaj dve ugodnosti:

1. problem povezave različne računalniške opreme je rešen z standardom X.400
2. komunikacija ni dialog, ki bi zahteval istočasno "fizično" prisotnost partnerjev (računalnikov) in med drugim tudi njihovo združljivost, temveč je to sistem poštnih nabiralnikov, ki vmesno shranjujejo sporočila.

Zaradi tega je sprejemanje sporočil v SDK neproblematično tudi v primeru  večjega števila sporočil uporabnikov, ki bi hoteli istočasno oddati podatke. S tem je odpravljen problem števila vhodnih mest za komunikacije in njihova (ne)zasedenost. Tudi obratno je pošiljanje sporočil večjemu številu uporabnikov tehnično enostavno, skrb za zanesljivo dostavo (ali je naslovnik prisoten) in potrditev sprejema, pa je zagotovljena s sistemom SMail 400.

Način uporabe X.400

Konkretno smo predstavili po naši oceni najcenejši in najlažje dostopen način za uporabnike. Seveda pa je uporaba drugih (privatnih) MHS sistemov in način oddaje sporočila prepuščen izbiri uporabnika oziroma njihovemu stanju v računskem centru. Edina zahteva je, da je sporočilo posredovano v SMail 400 in da nosi X.400 naslov SDK Centrala Ljubljana. Predstavljen način zahteva naslednje komponente pri uporabniku:

• IBM kompatibilen PC,
• asinhroni modem (CCITT - V.22/V.22 bis, AT-Hayes kompatibilen),
• programski paket OLISS in paket za kriptografijo,
• programski paket na PC-ju (npr. Smarterm 320, Xtalk, in podobno) za emulacijo asinhronega terminala VT100, VT220 ali VT320 z možnostjo prenosa datotek po protokolu Kermit,
• komutiran vstop v SIPAK (dodeljeno geslo),
• zakupljen poštni predal v SMail.400 sitemu.

Izmenjave - prenos podatkov v sistemu OLLISS razdelimo na štiri dele in sicer:

1. Podjetje - MHS

2. MHS      - SDK

3. SDK      - MHS

4. MHS      - Podjetje

Uporabnik (podjetje) mora izvesti koraka 1 in 4. Naloga SDK je, da izvede korak 2 in 3. Celotna transakcija traja približno 5 do 10 minut, kar pomeni, da naj  bi uporabnik imel povratno informacijo najkasneje 10 minut po tem, ko je izvedel korak 1.

Prenos: podjetje ---> MHS

Tu gre za prenos kodiranih podatkov, to je binarne datoteke na PC-ju, ki je rezultat kreiranja zahtevka ali virmana v aplikaciji OLISS. To datoteko vključimo v elektronsko pošto, zahtevamo potrditev sprejema in jo pošljemo na X.400 naslov SDK. Sam postopek po korakih je naslednji:

• zagon zgoraj navedene emulacije asinhronega terminala na PC-ju,
• komutiran vstop v SIPAK (klic X.28 vrat z asinhronim modem-om),
• klic PTTLJ vozlišča (mikro VAX na PTT Ljubljana),
• logon na VAX PTTLJ in pristop do MHS (SMail 400),
• prenos binarne datoteke iz PC-ja na VAX PTTLJ po protokolu Kermit (100% error free) s predhodno nastavljenimi parametri binary in blok size,
• kreiranje sporočila za SDK, vključitev binarne datoteke in oddaja   sporočila z opcijo potrditve.

Postopek je potrebno zaradi odprave tipkarskih napak in hitrosti z pomočjo "skript file" v rednem obratovanju avtomatizirati.

Prenos: MHS ---> SDK

V SDK je postavljena PRMD (Private Administration Domain) oziroma je instalirana programska oprema MHS-a na PC-ju. Ta na vsaki dve minuti vzpostavi zvezo z MHS na PTTLJ ter sprejme in odda vsa sporočila. Postopek je sledeč:

• MHS v SDK-ju sprejme sporočila in jih porazdeli po mapah posameznih uporabnikov.
• SDK "prebere" sporočila in vključeno binarno datoteko zapiše v binarno datoteko na PC-ju,
• dešifriranje datoteke,
• obdelava podatkov na IBM host računalniku.

Prenos: SDK ---> MHS

Po obdelavi na host računalniku, se rezultat v obliki tekstovne datoteke prenese na PC. Sledi šifriranje datoteke in kreiranje sporočila z vključeno binarno datoteko. Postopek ima vgrajeno logiko, tako da iz rezultata obdelave spozna komu je potrebno poslati sporočilo:

• rezultat obdelave host-a se šifrira in pripravi za pošiljanje,
• SDK avtomatsko kreira sporočilo-odgovor za ustreznega uporabnika,  vključi binarno datoteko in zahteva potrditev,
• pri naslednji vzpostavljeni zvezi pošlje odgovor z vključeno binarno datoteko v SMail 400.

Prenos: MHS ---> podjetje

Postopek je podoben koraku št. 7.3. Prvi del, to je vzpostavitev zveze in vstop v Smail 400 je enak. Sledi branje sporočila - odgovora iz SDK-ja. Poštni predal podjetja je organiziran tako, da ima definirano posebno mapo, v katero prispejo vsa sporočila, ki jih pošlje SDK in imajo točno določen naslov.

Vsebina sporočila se prenese na PC v podjetju, dešifrira in obdela z aplikacijo OLISS:

• zagon zgoraj navedene emulacije asinhronega terminala na PC-ju,
• komutiran vstop v SIPAK (klic X.28 vrat z asinhronim modem-om),
• klic PTTLJ vozlišča (mikro VAX na PTT Ljubljana),
• logon na VAX PTTLJ in pristop do MHS (SMail 400),
• branje sporočila in  "print" vključene binarne datoteke na VAX disk,
• prenos binarne datoteke iz VAX PTTLJ na PC v podjetju po protokolu Kermit (100% error free) s predhodno nastavljenimi parametri binary in blok size,
• logout in prekinitev zveze,
• dešifriranje prenesene datoteke,
• pregled prispelih rezultatov v aplikaciji OLISS.

Celote postopek je potrebno zaradi odprave tipkarskih napak in hitrosti z pomočjo "skript file" v rednem obratovanju avtomatizirati.

Opis komunikacijskih transakcij [10]

UVOD

Za distribucijo nalogov plačilnega prometa sem uporabil sistem, ki je bil razvit leta 1985 in bazira na distribuciji on line aplikacij. Tem aplikacijam nudi sistemsko podporo produkt, ki je znan pod imenom CICS (Customer Information Control System). Tak način pošiljanja podatkov med  različnimi velikimi računalniki in osebnimi računalniki predstavlja v svetu strateško razvojno filozofijo na bazi CICS aplikacij.

Distribucija nalogov plačilnega prometa poteka v 3 fazah:

1. prenos podatkov z osebnega računalnika - PC na glavni računalnik,
2. distribucija in
3. povratna informacija.

Prenos s PC na glavni računalnik

Podatki so bili preneseni iz poštnih predalov na osebni računalnik. Z osebnega računalnika prenesemo podatke na glavni računalnik v Ljubljani s send ukazom v 3270 okolju, ki na strani glavnega računalnika starta CICS aplikacijo. Le-ta prenese vse podatke virmanskega naloga (pakete) v skupno zbirno datoteko, ki se prazni ob koncu obdelave za tekoči datum obdelave. Informacije o prenesenih podatkih se hkrati beležijo tudi v kontrolno datoteko, ki jo uporabljam za ponovitev (restart) distribucije nalogov plačilnega prometa, kadar je to potrebno zaradi tehničnih problemov (izpad povezave med računalniki).

Distribucija

Distribucija nalogov plačilnega prometa bazira na SNA LU6.2 konverzaciji med dvema ali več CICS sistemi na oddaljenih lokacijah (Celje in Kranj). Ko je prenos podatkov z osebnega računalnika končan, CICS zazna spremembo v zbirni datoteki in avtomatsko starta proces distribucije ne glede na število nalogov.

Proces distribucije je podprt s tremi CICS aplikacijami. Prva aplikacija zbere podatke po sedežih obremenitve npr. SDK Celje (minusni stavek) s pripadajočimi računi v dobro (plusni stavki) in formira novo logično celoto v obliki, ki se lahko vključi v obdelavo nalogov plačilnega prometa. Oddaljeni (remote) računalnik (sedež) jih vidi kot prispele avize v breme računa v minusnem stavku. V tej fazi aplikacija preda kontrolo naslednjemu programu in čaka na povratno informacijo (sporočilo) od tega programa. Ta program avtomatsko vzpostavi zvezo s CICS sistemom na oddaljeni lokaciji in prenese podatke, ki jih je pripravila prva aplikacija v datoteko na oddaljeni lokaciji. Po uspešnem prenosu (povezavo oziroma prenos aplikacija sama inicira vsakih 30 sekund, če s komunikacijami ni kaj v redu) ta program starta poseben program na oddaljeni lokaciji, ki sprejete podatke vključi (ažurira) v plačilni promet (prometna datoteka).

Zatem se formira sporočilo (back-end) sedežu iniciative (Ljubljana). To sporočilo se na sedežu iniciative zabeleži v datoteko sporočil, ki je last tega programa (message.log.file). Program preda kontrolo prvi aplikaciji na sedežu iniciative, ki je čakala na sporočilo z oddaljenega računalnika. Prva aplikacija sedaj formira minusni stavek s sedežem odobritve (npr. SDK Kranj) in pripadajočimi računi v dobro (plusni stavek) in zopet formira logično celoto, ki se lahko vključi na oddaljeni lokaciji v plačilni promet in jih le-ta vidi kot prispele avize v dobro računa v minusnem stavku. Iz številke sedeža v žiro računu minusnega stavka program zazna, na katero oddaljeno lokacijo (sedež SDK) mora poslati novo formirano logično celoto (lahko pa tudi pošlje domačemu sedežu na katerem teče aplikacija. V tej fazi se zopet starta program, ki avtomatsko vzpostavi zvezo s CICS sistemom oddaljenega računalnika in prenese pripravljene podatke na oddaljeni računalnik v datoteko VSAM organizacije.

Ko je prenesen zadnji stavek (kar je pomembno), program zopet starta na oddaljenem računalniku poseben program, ki vključi sprejete podatke v plačilni promet. Potem formira sporočilo, da so bili nalogi obdelani npr. v Kranju v dobro računa iz minusnega stavka, kot povratno informacijo "back-end transaction" za sedež iniciative (Ljubljana), ki zabeleži v kontrolno datoteko, da so bili nalogi obdelani v celoti (v breme in v dobro na pripadajočih sedežih) ter jih označi kot obdelane. Naslednji iniciran prenos podatkov z osebnega računalnika piše podatke v zbirno datoteko od tu dalje, od koder starta tudi naslednja distribucija. Podatki na sedežu iniciative se ne brišejo tekom delovnega dne in se na koncu delovnega dne prepišejo na magnetni trak za vsak dan v tednu, od koder se lahko restavrirajo za morebitno reševanje reklamacij oziroma nejasnosti.

Povratna informacija

Na podlagi sporočil v datotekah na sedežu iniciative se formira sporočilo, ki se prenese na osebni računalnik za uporabnika, ko se starta na osebnem računalniku ukaz receive v okolju 3270. To sporočilo se potem prenese v uporabnikov (pravna oseba) poštni predal.

OLISS je treba še dogradi za primer, ko ne bo mogoča povezava z določenim sedežem SDK. V ta namen bi pripravljene podatke pisali v "VSAM queue file", kjer bi bili na listi čakanja  in bi se vključili (obdelali) na isti način takoj, ko bi bila povezava z računalniki mogoča in obdelava nalogov plačilnega prometa v prvi fazi (vnos in kontrola). Kadar pa to ne bi bilo mogoče, bi se ob koncu delovnega dne prepisali na prenosljiv magnetni medij (trak ali disketa) in poslali po pošti.

Za take primere ima operater na sistemu možnost nasilne prekinitve sicer avtomatske vzpostavitve komunikacije "CICS to CICS". To bi bilo v primeru, da sedež iniciative samodejno začne pošiljati podatke v večernih urah, ker je bil prej računalnik v okvari, na sedežu kamor so podatki namenjeni pa je obdelava že v zaključni fazi (konec vnosa in kontrole nalogov plačilnega prometa).

Prav tako bi morali še dograditi ponovno pošiljanje že poslanega materiala v primeru, da določen sedež SDK začne tekom dneva z včitavanjem materiala od začetka, oziroma vrne določeno stanje prometa (TD), kjer še ni zajet poslani material zaradi tehničnih problemov. Aplikacije so že sedaj tako projektirane, da se iste logične celote ne morejo obdelati dvakrat za isti datum obdelave in so s tega vidika varne (ne pride do dvojnih ažuriranj).

Gornje aplikacije lahko tudi prilagodimo za pošiljanje materiala podružnicam SDK, ki so opremljene z UNISYS računalniki in to bi pošiljali po ustaljeni poti preko "punch queue-a" ali pa bi morali na strani Unisysa instalirati produkt, ki simulira CICS sistem. Takšna povezava bi delovala kot "CICS-TO-IMS/VS ISC" aplikacija (Information Management System/Virtual Storage Inter System Communication).

Za izvedbo zgoraj navedenega projekta je potrebno detajlno znanje CICS-a in VTAM-a, saj je projekt vezan na veliko sistemsko podporo, torej je potrebno poleg aplikativnega dela tudi precej sistemskega programiranja. Na podružnicah (Ljubljana, Celje, Maribor, Kranj) poteka projekt na obstoječi IBM računalniški opremi, že vzpostavljenem sistemskem programju in komunikacijah tako, da s tega vidika ni potrebnih nobenih dodatnih stroškov pri zgoraj opisanem poteku dela na centralnih računalnikih.

Moj denar - OLISS

RAČUNALNIŠKO IZMENJAVANJE PODATKOV MED SDK IN PODJETJEM  [*]

Mnogi direktorji (še posebej finančni) sanjajo o tem, da bi v vsakem trenutku vedeli, koliko denarja imajo na žiro računu podjetja, katera plačila so prispela in katera še ne, kaj lahko poravnajo …. Vse bolj razvite računalniške mreže načeloma omogočajo uresničitev teh sanj. Tudi v Sloveniji.

Pričujoči prispevek obravnava problematiko in rešitev računalniškega izmenjavanja podatkov v plačilnem prometu med podjetji preko SDK in javne PTT-storitve elektronska pošta. Opisani so vsi bistveni elementi, ki omogočajo, da se ta način dela lahko poskusno vpelje v poslovanje podjetij.


Sedanji način dela in izmenjavanja podatkov med SDK in pravnimi osebami poteka na vsako-dnevnem izmenjavanju dokumentov – papirjev. To se lahko izvede večkrat dnevno, vedno pa takrat, ko pride do transakcije – plačila in o čemer so udeleženci obveščeni naslednji dan z izpisom o spremembah in stanju na žiro računu.

Cilj OLISS je, da se omogoči večkrat dnevno izmenjavanje podatkov brez fizične prisotnosti dokumentov – papirjev in z možnostjo obdelave različnih zahtevkov pravnih oseb. OLISS sestavljajo različni aplikacijski programski sistemi pri pravnih osebah in pri SDK z namenom enotnega pristopa do podatkov, ki jih obdeluje in hrani SDK na svojih računalniških sistemih. To pa tudi pomeni, da so udeleženci o vsaki transakciji obveščeni skoraj v »realnem času«.

Nova storitev SDK

OLISS (On Line Informacijski Servisi SDK) je skrajšano ime za organizacijsko-tehnično izboljšavo delovanja SDK z razširitvijo uporabe  podatkovnih baz SDK in njegove računalniške mreže. Bistvene nove funkcije, ki jih OLISS omogoča, so izvajanje naslednjih transakcij z lokacije zunaj organizacijskih enot SDK:

• zajem podatkov splošnega prenosnega naloga (virmana) na lokaciji zunaj SDK,
• prenos podatkov in vključitev v obdelavo podatkov plačilnega prometa,
• vpogled v stanje računa podjetja,
• vpogled v stanje računa banke in njenih komitentov,
• vpogled v register imetnikov računov (RIR) in iskanje podatkov v njem,
• vpogled in iskanje podatkov v zbirkah podatkov, ki so vodene pod upravljavskim sistemom za baze podatkov SQL/DS.

V tej obliki in fazi izdelave pomeni OLISS novo storitev, ki jo v plačilnem prometu lahko ponudi SDK. OLISS ni v nobenem pogledu zamenjava obstoječega plačilnega prometa, saj na način dela in obdelave podatkov plačilnega prometa v SDK nima vpliva v smislu, da bi bile zato potrebne spremembe tehnologije ali organizacije dela. Pomeni le pospešitev dobivanja podatkov in informacij, zmanjšanje količine zajema podatkov v SDK ter – glede na sedanje stanje – prednosti, ki jih za poslovanje prinaša možnost sprotnega vpogleda v stanje računa podjetja. OLISS je poleg tega seveda na razpolago tudi kot interni servis SDK.

Na področju statističnih obdelav OLISS omogoča vpogled v določene zbirke podatkov in sicer:

• periodične obračune,
• zaključne račune,
• katalog podatkov,
• baze podatkov pod SQL/DS,

kar je mogoče preko oddaljene računalniške opreme ali terminala, instaliranega pri uporabniku (pravni osebi).

Interes podjetja

Za podjetje pomeni OLISS novo kvaliteto v poslovanju predvsem z vidika bistveno povečane možnosti vpliva na finančne tokove zaradi sprotnega izvajanja finančnih transakcij. Poleg tega je v okviru tega servisa mogoče ponuditi nove storitve, ki jih sedaj še ni, se pa OLISS z njimi lahko dopolni. Razloge in interese za uvajanje računalniškega izmenjavanja podatkov lahko gospodarstvo potencialno vidi v

• znižanju stroškov poslovanja,
• povečani konkurenčni sposobnosti podjetja,
• možnosti kontrole in usmerjanja finančnih tokov,
• povečanju produktivnosti dela SDK.

Organizacijsko-tehnična rešitev pokriva področje plačilnega prometa in statističnih obdelav SDK v povezavi z delovanjem pravnih oseb. Predvsem pa omogoča opravljanje računalniškega izmenjavanja podatkov brez bistvenih investicij v obstoječe resurse SDK in pravih oseb. Ocenjujemo, da je mogoče ta servis začeti uporabljati na večini obstoječih računalniških naprav, ki so v podjetjih že instalirane, z morebitnimi dopolnitvami naprav in programov za komunikacijo ter seveda z dopolnitvijo aplikacijskih programov za zajem in/ali prenos podatkov med obstoječo aplikacijo v podjetju. Programe za kontrolo plačilnega prometa in za zaščito oskrbi ponudnik storitev, torej SDK, in sicer v obliki, ki bo uporabniku onemogočala posege v programe.

Ob ponudbi nove storitve se seveda postavi vprašanje, katerim podjetjem je pravzaprav namenjena. V končni fazi je odgovor na to vprašanje odvisen le od tega, ali podjetje želi modernizirati in pospešiti določen segment svojega poslovanja. Če je odgovor na to vprašanje pozitiven, je nepomembna velikost podjetja, dejavnost in drugi dejavniki poslovanja.

Interes SDK

Za računalniško izmenjavanje dokumentov je Služba družbenega knjigovodstva zainteresirana iz več razlogov, ki so operativne narave in jih lahko opredelimo kot

• zmanjšanje števila plačilnih nalogov, ki jih je treba zajemati,
• povečanje produktivnosti dela v Službi družbenega knjigovodstva in
• podaljšanje časa sprejemanja nalogov.

Nobenega razloga ni, da SDK ne bi svoje različne izdelke in rezultate mnogih obdelav posredovala zainteresiranim pravnim osebam namesto »na papirju« preko računalniškega izmenjavanja podatkov.

Tako pri uporabniku kot pri ponudniku storitve je treba ustanoviti ekipo za uvajanje OLISS. Pri uporabniku je to enkratni projekt, za SDK pa pomeni trajno delovno obremenitev. Ekipa v SDK bi imela nalogo, da

• uvaja storitev pri uporabnikih in
• dopolnjuje servis z novimi funkcijami.

Pravna vprašanja

V ozadju računalniškega izmenjavanja podatkov obstaja obsežen kompleks problematike pomanjkljive pravne regulative, kolikor o njej lahko sploh govorimo. Že v deželah, kjer je ta tehnika uveljavljena, ugotavljajo potrebo po zakonodaji, ki bi to področje urejala. Pri nas se bo to pokazalo takoj, ko bodo tehnični problemi rešeni in se bo računalniško izmenjavanje začelo. Za začetek je sicer dovolj, da se poslovna partnerja sporazumeta o takem načinu izmenjavanja sporočil. Ker pa se to ne da opravljati brez posrednikov, je nujno izdelati pravila, ki so neizogibna nevtralna referenca, ko pride do nesporazumov. Dobra volja je potrebna za začetek, ni pa dovolj za srečen konec.

Ob tem je nujno opozoriti, da se tovrstna zakonodaja v svetu že pripravlja in da bo obstoj take zakonodaje pri nas zelo verjetno pogoj, da bodo razviti z našimi podjetji na tak način sploh hoteli poslovati. Po drugi strani pa je računalniško izmenjavanje podatkov že mogoče oceniti kot enega od pogojev za poslovanje z razvitim svetom. Sklep, da je s pravno regulativo nedopustno čakati, se torej kar vsiljuje. Le upamo lahko, da še nismo izgubili preveč časa – nekaj smo ga namreč že – in da bodo zgledi od drugje za nas sprejemljivi brez večjih dopolnitev ali sprememb.

Zgornje ugotovitve ne smejo zavesti v smislu, da je zaradi omejitev v predpisih nadaljnja uporaba OLISS, pa čeprav poskusna, nemogoča. Nasprotno, prav bi bil tak korak napraviti takoj, obstoječi predpisi tega pravzaprav izrecno ne prepovedujejo. Dovolj bi bilo, če bi se na primer nalogi – virmani, ki jih podjetje realizira na tak način, vidno označili z napisom »NI ZA ZAJEM«. Obstajajo pa gotovo tudi še druge sprejemljive možnosti.

Tehnična vprašanja

Pri uvajanju OLISS morajo biti usklajeni trije segmenti:

• ponudnik storitve OLISS (SDK),
• ponudnik storitev X.25/X.400 (PTT) ter
• uporabnik.

V tem kontekstu je zanimivo vprašanje zmogljivosti sistema za prenos sporočil. Uporaba X.25 (SIPAK – slovensko javno omrežje za paketni prenos podatkov), X.400 (mednarodni standard ISO za elektronsko pošto – Messages Handling System) je bila vključena v rešitev prav iz razloga, da se premostijo omejitve komunikacijskega podsistema SDK, ki je dimenzioniran za potrebe SDK, vprašanje pa je, ali ima PTT dovolj zmogljiv sistem. Malo namreč vredno uvajanje hitrega plačevanja, če se tehnika degradira zaradi premalo zmogljivih komunikacij. Po standardih naj bi bila nujna sporočila v sistemu za prenos sporočil X.400 posredovana v 45 minutah. V praksi je to realizirano bistveno hitreje, to je v nekaj minutah. Vseeno ocenjujemo, da se bo morala zmogljivost X.400 v Sloveniji opazno povečati, da ne bi prišlo do diskriminacije prijav uporabnikov za OLISS.

Drugo vprašanje je imenik naročnikov OLISS. Ta problem bi lahko rešili s pomočjo standarda X.500 (elektronski imenik v povezavi z X.400). Ker ta servis v Republiki Sloveniji še ni operativen in splošno uporaben, to praktično pomeni, da bo morala odgovornost in delo za vzdrževanje ažurnega imenika naročnikov storitev prevzeti SDK, ki bo morala tudi dodeljevati ključe za zaščito in določati, kdaj in kako se lahko vključujejo novi uporabniki.

Zaščita transakcij

Prenos podatkov zahteva ustrezno zaščito, ker še posebej velja za »elektronski« denar. Upoštevati in zagotoviti je treba naslednje štiri servise:

1. Prejemnik mora imeti zagotovilo o pošiljateljevi identiteti (elektronski podpis),
2. Prejemnik mora imeti zagotovilo o originalnosti sporočila (elektronski pečat),
3. Pošiljatelj mora dobiti od prejemnika dokaz o prejemu sporočila (potrdilo o prejemu),
4. Pošiljatelj mora biti od prejemnika dokaz o originalnosti vsebine sporočila.

Največkrat zahteva varna komunikacija le elektronski podpis in elektronski pečat. Pri opravljanju finančnih transakcij pa moramo dodati še tretji servis in dobimo pošto s potrdilom. Integriteto vsebine sporočila pa nam zagotavlja šele četrti servis – dokaz o originalnosti vsebine sporočila.

Vsi štirje servisi skupaj pa zagotavljajo, da

1. pošiljatelj ne more zanikati sporočila niti njegove vsebine in
2. prejemnik ne more zanikati prejema sporočila niti spremeniti originalne vsebine.

Za opisano zaščito so bile uporabljene standardne metode in algoritmi ter bi njihovo navajanje presegalo osnovni namen tega prispevka.

Prihranki

OLISS je zamišljen kot nova ponudba SDK za storitve na področju plačilnega prometa, statistike in pristopa do podatkovnih zbirk SDK. Mogoče ga je razširiti tudi na bonitetno službo in morebitna druga za uporabnike storitev SDK-ja zanimiva področja. Eksplicitni prihranek, ki ga SDK lahko pričakuje in tudi ovrednoti, je zmanjšanje zajema podatkov plačilnega prometa in drugih podatkov, ki jih SDK še zbira, bi se pa lahko posredovali preko OLISS. Ocena je, da se v razvitih državah okoli 70 % finančnih transakcij lahko posreduje preko take ali podobne tehnike, kar pomeni v končni fazi zmanjšanje stroškov zajema podatkov in s tem povezanih investicij v opremo za približno enak odstotek.

Drugo pomembno dejstvo je, da se z OLISS odpre možnost, ki jo v finančnem smislu, tj. v hitrosti obračanja denarja omogoči nova storitev. Poleg tega se prav lahko za pravne osebe, ki bi poslovale tako, podaljša čas dostave virmanskih nalogov.

Za pravne osebe pomeni ta servis učinkovitejše poslovanje in boljšo kontrolo finančnih tokov ter nižje stroške posredovanja podatkov SDK.

Kako naprej

OLISS obsega organizacijo in programski del. Začeli smo ga razvijati na pobudo Fakultete za organizacijske vede iz Kranja kot enega od možnih pristopov k računalniškemu izmenjavanju podatkov. Pri končni izvedbi sta sodelovali podjetji Merkur iz Kranja in Kovinotehna iz Celja kot poskusni lokaciji zunaj SDK, PTT podjetje Ljubljana in SDK Centrala v Ljubljani, Sektor za računalniško obdelavo podatkov kot nosilec posla. Prototipna rešitev se je razvijala od 1989 in je bila v različnih razvojnih fazah javno predstavljena v strokovnem krogu organizacij, ki so aktivno sodelovale v raziskovalni nalogi. Končna rešitev je bila predstavljena junija 1992 in je bila ocenjena kot pomemben pozitiven prispevek v načinu poslovanja.

Posebnost javne izvedbe je bila, da so informatiki in računalničarji iz SDK in obeh podjetij pojasnili le okolje izvedbe in tehnični del, prenos sredstev pa sta prikazala »končna uporabnika«, torej delavca v finančni službi podjetja Merkur in Kovinotehna, ki tovrstna dela opravljata tudi sicer. Na ta način je bila sprejemljivost in enostavnost uporabe OLISS resnično izkazana. Podobno pozitivno stališče je zavzel tudi kolegij direktorjev SDK v Republiki Sloveniji.

Projekt OLISS je tako izpopolnjen, da je primeren za poskusno uvedbo v poslovanje podjetij in SDK ter da bi bil lahko naslednji korak v razvoju le še poskusno delo. Izvedbeno je OLISS izdelan do take faze, da so vsa opravila v SDK povsem avtomatizirana in rutinska. Dodati velja, da smo pri izdelavi aplikacijskega programskega sistema OLISS »preskočili« sedanjo vlogo in pomen predhodne, tj. šalterske kontrole v SDK.

Razvijalci OLISS smo mnenja, da je prikazani model že uporaben. Rešeni so bistveni tehnični problemi, ki so v prejšnjih fazah razvoja omejevali uporabnost. To so problemi zaščite podatkov, problemi enostavnosti dela ali, bolje rečeno, transparentnost tehničnega ozadja ter, kar je navzven skoraj nezaznavno, treba je bilo rešiti probleme obdelave in prenosov podatkov znotraj računalniške mreže SDK. Poudariti je treba dejstvo, da je ves OLISS naslonjen na obstoječe tehnične in organizacijske rešitve, ki se tudi sicer uporabljajo v SDK.

V teku priprav na preizkus je nastopilo tudi vprašanje, kaj se zgodi, če je en uporabnik vključen v OLISS, drugi pa ne. V resnici to ni resen zadržek za uporabo servisa, saj bo transakcija realizirana v vsakem primeru na isti način, le informacija o njej in zajem ter prenos podatkov bosta opravljena drugače, pač odvisno od tega, kateri od uporabnikov, plačnik ali prejemnik, uporablja OLISS.

Finančna transakcija se izvede v realnem času z omejitvami, ki jih postavlja X.400. To pomeni, da se zajem, prenos in obdelava podatkov opravijo takoj, ko so zahtevani, čakanje je vezano le na delo X.400.

Poseben komentar zahteva dejstvo, da podatki iz splošnega prenosnega naloga niso konvertirani v standardno obliko, kakor jo določa ustrezni UN/EDIFACT standard (United Nation/Electronic Data Interchange For Administration, Commerce and Trade). Poizkus konverzije je bil že opravljen in je tudi opisan, rezultat pa ni navdušujoč, in sicer zato, ker je bil konvertiran en sam tip virmanskega naloga, pa še ta s težavami, ker se vsebina podatkov, ki jo predpostavlja standard, od vsebine podatkov na virmanskem nalogu tako razlikuje, da je bila večina podatkov z naloga prenesena v polje za komentarje. Po drugi strani lahko pričakujemo, da bo moral biti splošni prenosni nalog kmalu usklajen z evropskimi standardi.

Tedaj bo konverzija v standardni format enostavna in naravna, vendar s pogojem, da bo ob kreiranju novega dokumenta upoštevano dejstvo, da tak standard sploh obstaja. Sicer je to vprašanje del širše problematike koncipiranja novega plačilnega prometa države Slovenije.

Sklepi

Na podlagi izvedbe in ocene On Line Informacijskih Servisov SDK je mogoče skleniti naslednje:

• Že v obstoječi obliki predstavlja uporaba OLISS rešitev, ki bistveno pospeši izvajanje plačilnega prometa ob nespremenjenih vseh ostalih parametrih poslovanja in dela v SDK in pri uporabnikih.
• Predstavljena rešitev je komplementarna glede na način, na katerega se plačilni promet izvaja sedaj. Prav zato ni bojazni, da bi z uvedbo novega servisa SDK konkuriral samemu sebi. Za gospodarstvo pomeni možnost za pospešitev poslovanja in bolj ažurno spremljanje denarnih tokov ter vplivanje nanje.
• OLISS je mogoče uporabiti poleg plačilnega prometa tudi za odpiranje drugih splošno zanimivih zbirk podatkov in informacij SDK (register imetnikov računov, bonitete, kazalci poslovanja).
• Priporočljivo bi bilo, da se storitev čim prej vpelje v poslovanje dveh podjetij in se tako pridobi nujno potrebne informacije za izboljšave. Uvedbo OLISS naj zahteva tisti, ki ima za tak način poslovanja največji interes. Predpostavljamo, da je to gospodarstvo. SDK mora za ta namen najti dovolj razumevanja za delo v okviru obstoječih predpisov.
• Novi servis mora biti v SDK ustrezno tehnično, organizacijsko in kadrovsko podprt. Prikazana rešitev predstavlja po oceni realizatorjev skrajno mejo, do katere je še mogoče tako rekoč od zunaj razvijati novo storitev na »amaterski« osnovi in s pomočjo raziskovalne naloge.

----------------------------
[*]  Objavljeno: Revija Denar, 1993.