četrtek, 2. januar 2003

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.




četrtek, 10. oktober 2002

Polomija prvega dne



AROPS so izdelali projektanti in programerji na Glavni centrali v Beogradu. V živo še ni bil uporabljen nikjer. Predlagali smo, da naredimo prvo poskusno obdelavo na podatkih plačilnega prometa ekspoziture Kamnik. Pripravili smo dokumente, speljali predvideni postopek, do rezultatov pa sploh nismo prišli.

Ne vem, kako so uspeli pretentati direktorja, da rezultati poskusa niso pomembni in da s paketom ni nič narobe. Pa smo šli v živo s celo podružnico. No, izpiskov ni bilo. Pri nas se je zbrala čez noč vsa beograjska ekipa. Programirali so in popravljali. Čez nekaj dni je stvar stekla.

Cena je bila pošastna.

Osramotili smo se pred računalniško in poslovno javnostjo, v podružnici smo ostali vse dni do prvega izpiska, spali, kolikor smo sploh spali, smo v pisarnah po stolih, pozabili, kje smo prvega dne parkirali kolesa in avte, po prihodu domov so se pričele živčne in z njimi povezane prebavne težave. V grlu se nam je zataknil cmok razočaranja.

Takega začetka ne privoščim niti najhujšemu sovražniku.




Maj 1973

petek, 4. oktober 2002

Projekt POLIFEM


V stari grški mitologiji so bili Kiklopi (samo ime pomeni "okroglo oko") velikani z enim samim očesom v glavi. Pričevanja o njihovem življenju se precej razlikujejo:

  • Heziod govori o treh kiklopih - Arg, Bront in Sterop naj bi bili otroci Urana in Geje, pozneje Zevsovi predani služabniki; iz maščevanja jih je ubil Apolon
  • Homerjevi kiklopi naj bi živeli v pečinah otoka, ki so ga pozneje identificirali kot Sicilijo; med njimi je najbolj znan Polifem, ki je ujel Odisejevo posadko.

Pravljic se nadaljuje, zapleta, mi pa se vprašamo, kaj ima pri vsem SDK. Na prvi pogled nič, z malo domišljije in kančkom potrpljenja pa morda le nekaj. Poglejmo!

Že dolgo časa obupani delavci funkcij zunaj računalniške obdelave podatkov so prijetno presenečeni s spremembami v načinu obveščanja o novih APS-ih, ki so jih izdelali delavci SROP-a; poleg rednega obveščanja z dopisi smo priče obširnega oznanjevanja novih projektov tudi v »Obvestilih«.

Da bi spoznali za kakšno spremembo gre, vas bom na kratko seznanil s kronologijo dogodkov, ki so vezani s to temo in katere lahko dokumentiram. Na sestanku pomočnikov direktorjev in vodij ROP-a dne 17. 6. 1988 je bilo sklenjeno, med ostalim, da se izdela popis programov za osebne računalnike. To zaradi tega, ker vse podružnice niso bile seznanjena s tem, da so jim že na voljo določeni programi.

Dne 08. 09. 1988 so podružnice prejele pregled programov za osebne računalnike, s pripombo: »Uvajanje programov in usposabljanje delavcev bo zagotovila funkcija, za področje dela katere se programi uporabljajo, vzdrževanje programov pa mora v sodelovanju s funkcijo zagotoviti dobavitelj ali avtor programov. Pri instaliranju vseh programov in osebnih računalnikov bo po potrebi sodeloval sektor ROP
centrale.« Pripomba je lahko razumljiva, ker na seznamu programov ni bilo kompletnega programa, ki bi bil izdelan v SROP-u.

Na sestanku pomočnikov direktorjev in vodij ROP-a dne 16. 2. 1990 je bilo sklenjeno, med ostalim, da »Sektor za računalniško obdelavo podatkov bo tekoče obvešča] podružnice o projektih v razvoju.«

Dne 13. 03. 1990 so podružnice prejele katalog aplikacijskih programskih sistemov na osebnih računalnikih v SDK Slovenije in interno navodilo za arhiviranje le-teh. Katalog vsebuje APS-e, ki so izdelani v sektorju ROP centrale. V spremnem dopisu predlagajo, da vse podružnice formirajo podobne kataloge in sprejmejo tak način arhiviranja ter tekoče obveščajo SROP o morebitnih spremembah.

Dne 23. 05. 1990 so podružnice prejele »informacijo o novih programih za osebne računalnike«, v kateri se omenjajo štirje novi programi, ki sicer niso končani ampak so že v razvoju ali v tesni fazi (izpisovanje virmanskih nalogov, evidenca sodnih sklepov, evidenca telefonskih nalogov, evidenca trakov). Dne 26. 09. 1990 so podružnice prejele opisni listič za APS ČEKI, ki je izdelan po zahtevku podružnice Ljubljana in v podružnici tudi verificiran. Na koncu, »last but not least«, APS ARGUS, ki dopolnjuje to vse bolj svetlo podobo in o katerem poroča gospod XY.

Eppur si muove !


Zelo mi je všeč, da so v Službi poleg pridnih delavcev tudi duhoviti delavci, ki so sposobni ljudem približati še tako tuje področje kot je računalništvo. Gospod XY gotovo sodi med njih. Ker nobena stvar ni tako dobra, da ne bi bila lahko boljša, si upam opozoriti na nekaj pomanjkljivosti v njegovem tekstu.

Osebno menim, da je namen teksta »Projekt ARGUS« predstavitev novega APS-a ARGUS. Avtor teksta, kljub svojim škotskim prednikom, ne varčuje (s prostorom in besedami):

Od tukaj naprej je zapisano tudi v originalu malce zmedeno, pa vseeno!

Podatki, ki jih JUTRANJI PROGRAM vzdržuje se nahajajo v naslednjih podatkovnih zbirkah - datotekah:

Na glavnem računalniku se starta JUTRANJI PROGRAM, sledi tipična zaporedna (batch) obdelava:

Vidimo da je osnovna naloga JUTRANJEGA PROGRAMA vzdrževanje vseh podatkov v ustreznih podatkovnih zbirkah. To vzdrževanje obsega:

  • odpiranje imetnikov računov - VP (vrsta posla) 9,
  • popravljanje podatkov imetnikov računov - VP 1,
  • zapiranje posameznih imetnikov računov - VP5

Konkretno pa se v SDK Ljubljana uporablja naslednja strojna oprema:
centralna procesna enota IBM 4341 z 8 MB glavnega spomina,
zunanji spomin na diskovnih enotah IBM 3375 in 3380 ter ustrezne kontrolne enote - skupaj 16,4 GB...

Programska oprema pa ja naslednja:
celoten računalniški sistem kontrolira operacijsko programje VM/SP, ki omogoča delitev strojne opreme različnim uporabnikom kot zaključne celote, VSE/SP je osnovni operacijski sistem, ki omogoča...

Do leta 1990 delavci referata RIR, ki je lociran v Ljubljani, Titova 66, računski center pa na Cankarjevi 18, niso imeli nobene računalniške opreme. Letos pa so dobili osebni računalnik IBM AT z opremo:

  • 1 MB spomina
  • 30 MB trdi disk
  • 1,2 MB disketna enota
  • tiskalnik

Konec  zmedenega besedila !

Šele na koncu nam pove kaj (bo) omogočal) novi APS. Tako smo veliko več zvedeli o delovanju jutranjega programa, hardware-ski konfiguraciji SROP-a, sistemskem in aplikativnem software-ju, ki ga uporabljajo delavci SROP-a, osebnem računalniku v oddelku RUDS (RIR) podružnice Ljubljana, kot o novem APS-u.

Spoštovani gospod XY, stari nemški pregovor pravi: »Preveč lepila slabo drži«.

Če pa je to vse, kaj se o APS-u ARGUS lahko pove v tem trenutku (in to ni nič posebnega, ker že dolgo obstajajo transakcije s podobnimi funkcijami), potem »Projekt ARGUS« dejansko lahko imenujemo »Projekt POLIFEM«.

Sedaj smo ponovno pri mitološkem enookem velikanu!


November 1990

sobota, 10. avgust 2002

Hitrejši prenos sredstev

S telekomunikacijskimi prenosi bi lahko pospešili hitrost kroženja denarja v obtoku, vendar si upamo o tem le na tiho razmišljati.

Morda se lahko najprej vprašamo o namenu tega zakona. Če izhajamo iz predpostavke, da je finančna nedisciplina med ostalimi vzroki tudi eden od razlogov za naraščajočo nelikvidnost, potem bi omenjeni zakon vsaj za toliko izboljšal likvidnost, kolikor se bo zaradi njega izboljšala finančna nedisciplina. Zakon o zavarovanju plačil med uporabniki družbenih sredstev že od samega začetka podrobno določa kazenske sankcije za kršilce finančne nediscipline. Očitno pa ta instrumentarij v pogojih našega gospodarjenja ni bil dovolj močan, da bi zavrl te pojave. Posledica tega je, da smo si izmislili 7.a člen v zakonu o zavarovanju plačil, ki je teoretično odigral vlogo prototipa letošnjega intervencijskega zakona. S tem smo določili še eno sankcije več, oziroma razširili krog odgovornosti na tiste, ki s to zadevo nimajo nič skupnega. Z malo nagajivosti bi lahko rekel, da lahko že sedaj razmišljamo, katero dodatno kazen bomo v letu 1985 uporabili, če bomo ugotovili, da učinki tega predpisa ne bodo zadovoljivi. Menim, da imamo kazenskih določb v zakonu o zavarovanju plačil čisto dovolj in vsakemu po meri. Zdi se, da bo večja sankcija za tistega, ki ne bo sposoben v redu poravnati svojih obveznosti, pravzaprav izguba bonitete pri bankah in poslovnih partnerjih, seveda pa se tega še naprej ne bodo zavedali tisti sistemi, ki imajo na trgu zaradi takšnih ali drugačnih razlogov monopolni položaj.

No, pa bodi dovolj filozofiranja. Kako smo se mi pripravili na navedeni zakon? Naj še enkrat spomnim, da smo že lansko leto lahko prebrali 7.a člen z grožnjo, da bo ta veljal od 1. januarja naprej. V interni kontroli smo novembra lani anketirali uporabnike družbenih sredstev, primerjali njihove izjave s prijavami na OBZ obrazcih. Mislim, da je bila plod tega dela tudi informacija o pripravljenosti uporabnikov na določilo 7.a člena. No, ZIS je konec leta odložil uporabo tega člena za eno leto. Ker pomenijo določila letošnjega intervencijskega zakona pravzaprav razširitev 7.a člena in ker se o tem piše in govori že eno leto, tudi v sredstvih javnega obveščanja, menim, da ne bi smelo biti razloga za nepripravljenost ali neinformiranost. V juniju je bila na to temo izvedena še ena anketa. V interni kontroli v podružnici Kranj smo na začetek uporabe zakona in na potrebno dokumentacijo opozorili uporabnike družbenih sredstev v dveh okrožnicah. O tem se je govorilo na področnih seminarjih društva računovodskih in finančnih delavcev. Na Jesenicah smo na ta zakon pa tudi na druge ukrepe, opozarjali na delovnih posvetili z gospodarstveniki. Na te posvete je bila vabljena služba, organiziral pa jih je občinski izvršni svet. Morda je sedaj, pred začetkom izvajanja, še nekoliko nejasnosti in več vprašanj uporabnikov v zvezi s samo tehniko in razumevanjem zapadlih neporavnanih obveznosti po zakonu. Za samo pripravo je bilo na razpolago več časa kot sicer.

Sprašujete nas, kako lahko prispevamo, da bo teh organizacij čim manj. Prav gotovo bo treba biti v kontaktu s tistimi uporabniki, ki bodo v naših enotah že imeli prijavljene zapadle obveznosti na OBZ obrazcih. To delo za interne kontrolorje ne bo prav nič prijetno in bo zahtevalo od njih, pa tudi od drugih oddelkov več poglobljenega dela pri razreševanja posameznih primerov. Gotovo bodo interni kontrolorji »veseli« novih obrazcev ODN ali ODI, kot da bi bilo teh in podobnih evidenc do sedaj premalo. Verjetno je, da se bodo še v večji meri koristili dnevni prilivi, ki jih kontrolorji lahko zvedo v oddelkih AOP in prištejejo k izpiskom stanj žiro računov. Menimo, da se bo zlasti v izplačilnih dnevih osebnih dohodkov povečal telefonski prenos sredstev. Naj omenim, da so ta sredstva, vsaj za ekspoziture, ki oddajajo dokumente v obdelavo v podružnico že ob 11.15 uri, uporabna pretežno le do tega trenutka in da so zlasti v kritičnih dnevih telefonski nalogi za občane pravi balast. Posebno jezo pa povzročajo tisti s simboličnimi zneski in bil bi že skrajni čas, da se dogovorimo in določimo spodnjo mejo zneska, ki bi bil lahko sporočen po telefonu. S hitrejšim prenosom sredstev torej lahko tudi nekaj pripomoremo. Poznana nam je ideja o telekomunikacijskih prenosih, katere realizacija bi na tem področju pomenila verjetno premik za en kvalitetni razred navzgor in s tem pospešila hitrost kroženja denarja v obtoku. Čeprav za te zadeve nismo poklicani, si upamo o tem le na tihem razmišljati.

Julij 1984

Mednarodni obrtni sejem v Celju (MOS 96)

Na letošnjem Mednarodnem obrtnem sejmu v Celju (MOS 96) smo predstavili novost na področju opravljanja domačega plačilnega prometa, to je ELEKTRONSKO POSLOVANJE med Agencijo in pravnimi osebami. Osnova za uvajanje tega načina poslovanja je standard vhodnih in izhodníh dokumentov (Ur.l. RS, št. 9/ 95). ki je že oblikovan pri predlaganju nalogov na magnetnem mediju. Obenem je ta standard tudi temelj za pripravo sporočil po EDIFACT standardu, ki se bo predvidoma uporabljal pri računalniški izmenjavi podatkov.

Do sedaj so pravne osebe pošiljate podatke v plačilni promet večinoma na papirju in na magnetnih medijih, kot sta magnetni trak in disketa. Na podoben način so sprejemale tudi informacije o spremembah na žiro računu (magnetni medij) ali z neposredno računalniško povezavo. V zadnjem času pa se je hitro povečalo tudi poizvedovanje o stanju in prometu na računu s pomočjo zvočne pošte, to je SALDOTEL-a.

Zanimivo je, da pravne osebe vidijo največji pomen pri uvajanju elektronskega poslovanja prav na področju plačilnega prometa. To je pošiljanje nalogov, sprejemanje sporočil oziroma podatkov o opravljenih plačilnih transakcijah in sprejemanje drugih informacij (spremembe na žiro računu) prek elektronskega načina poslovanja.

Veliko zanimanje za tak način pošiljanja nalogov v Agencijo so pokazali predstavni pravnih oseb z velikim obsegom poslovanja, ki tudi večkrat dnevno pošiljajo naloge v Agencijo. Prav tako pa se zanj zanimajo predstavniki pravnih oseb z manjšim obsegom poslovanja, ki podatke z nalogov pošiljajo iz krajev, bolj oddaljenih od Agencije in jim to veliko pomeni zaradi prihranka časa.

Glede na to, da skoraj vsaka pravna oseba že ima potrebno opremo (osebni računalnik, razpoložljiva klicna linija in modem), je ta aplikacija še bolj zanimiva.

Pravne osebe namreč lahko pri elektronskem poslovanju uporabljajo več komunikacijskih protokolov (X.400 - elektronski poštni predal, elektronska pošta, klicna linija in Internet). V zadnjem času je izredno zanimanje za povezavo v Internet omrežje, zato je veliko obiskovalcev vprašalo, kakšen je postopek pri pošiljanju nalogov prek Internet omrežja v Agencijo.

Osnova za prehod na elektronsko poslovanje z Agencijo je, da pravna oseba najprej pripravi podatke v takem formatu, kot je predpisano pri pošiljanju nalogov na magnetnem mediju.

Pri tem pa imajo pravne osebe pomisleke, ker so še premalo seznanjene s prednostmi in drugimi ugodnostmi, ki jih imajo pri plačilu stroškov za opravljeni plačilni promet.

Zaradi tega so tovrstne predstavitve na sejmih izredno učinkovite in verjetno bo treba tudi v prihodnje temu področju posvetiti veliko publicitete.

V Podružnici Celje ugotavljamo, da se je po končanem Mednarodnem sejmu v Celju oglasilo že veliko strank v organizacijskem delu računalniške obdelave podatkov.

Povprašujejo za program NALOGI in za druge informacije v zvezi s sodobnejšimi načini opravljanja plačilnega prometa.

V naši podružnici pravne osebe uporabljajo naslednje načine računalniškega povezovanja: INFORMACIJSKI SERVIS SDK, INFORMACIJSKI SISTEM ZA BANKE IN ZA DRUGE PRAVNE OSEBE, PAGING SISTEM in SALDOTEL.

Pri uvajanju ELEKTRONSKEGA POSLOVANJA smo na začetku, čeprav je veliko povpraševanja, zato bomo morali še veliko postoriti.

Na koncu je treba izročiti posebno zahvalo in pohvalo vsem avtorjem aplikacije, ki so omogočili pripravo zelo uspešne in odmevne predstavitve. Prav tako je treba pohvaliti vse delavce SRISa in SROPa, ki so pripravili računalniško opremo za nemoteno delovanje ali sodelovali pri predstavitvah. Isto velja tudi za delavce iz Podružnice Celje, ki so bili prisotni na vseh področjih.

Oktober 1996