SDK SALDOTEL

Saldo na žiro računu po tonskem odzivniku

 

V svetu sodobnih komunikacij se potrebe po hitrih in pravilnih informacijah nenehno povečujejo. Vzporedno s potrebami po informacijah pa se povečujejo tudi različni in vsakdan bolj izpopolnjeni ter širšemu krogu ljudi dostopni načini posredovanja informacij.

 

V SDK Slovenije vseskozi spremljamo dogajanja na informacijskem področju in se trudimo, da bi našim komitentom ponudili najboljše možne rešitve in kvalitetnejše usluge na vseh področjih našega dela. Še posebej pa pri našem osnovnem in lahko rečemo najpomembnejšemu opravilu, to je posredovanju informacij o denarju.

 

V ljubljanski podružnici se vseskozi srečujemo s problemom pravočasnega posredovanja informacij o stanju in spremembah sredstev na računih imetnikov računov.

 

Sedaj posredujemo informacije o stanju in spremembah na žiro računih pri SDK na naslednje načine:

 

• prek delavcev interne kontrole, ki je zaenkrat najobsežnejše, vendar časovno omejen,
• prek dnevnih izpiskov imetnikov računov po pošti ali z osebnim dvigom naslednji dan,
• -prek sistema Paging zvečer in enkrat na dan v dopoldanskem času,
• prek računalniške povezave z imetnikom računa pri SDK (majhno število in testno),
• prek SALDOTELA, ki omogoča tekoče posredovanje informacije o stanju in spremembah širokemu krogu interesentov neprekinjeno 24 ur na dan, ob relativno nizkih stroških, kjerkoli imamo telefon in ob visoki stopnji varnosti.

 

V letu 1993 pa je bila v sodelovanju z delavci SROP Centrale Ljubljana, Podružnice SDK Ljubljana in podjetjem MAITIM d. o. o. Kamnik razvita in verificirana rešitev za govorno posredovanje informacij o tekočem stanju na žiro računu imetnika računa v SDK. V podružnici Ljubljana smo jo poimenovali SDK SALDOTEL.

 

SDK SALDOTEL - informacije o stanju na računu, posreduje govorno informacijo o stanju na žiro računu imetnika računa s pomočjo avtomatskega tonskega odzivnika.

 

Za posredovanje teh podatkov poskrbi elektronska naprava WECCUTALK (inteligentna mikroračunalniška naprava), povezana na eni strani z osebnim računalnikom, ki je naprej povezan z glavnim računalnikom IBM, na drugi strani pa je povezava oziroma povezljiva prek telefonskega omrežja z naročniki - imetniki računa, ki poizvedujejo po stanju na svojem žiro računu. Rešitev omogoča posredovanje informacij o stanju na računu 24 ur dnevno.

 

Zaradi narave podatka (stanje na računu pri SDK), ki je poslovna skrivnost, je potrebna visoka stopnja tajnosti, varnosti in zaščite teh podatkov. Varnost in tajnost sta zagotovljeni s pomočjo osem številčnega gesla. Geslo se avtomatsko določa s pomočjo generatorja slučajnih števil trimesečno, lahko tudi v manjših časovnih razdobjih ali na željo koristnika - imetnika računa, vključenega v SDK SALDOTEL. Geslo posredujemo kot poslovno skrivnost po pošti, na točno določeno osebo, ki jo imetnik računa določi ob sklenitvi pogodbe s SDK.

 

Za potrebe marketinga smo skrbno pripravili tudi komunikacijsko podporo pri uvajanju SDK SALDOTELA. Za te potrebe so bili pripravljeni oglasi v časopisih in revijah, plakati po ekspoziturah in naročilnice s kratkim opisom delovanja in prednosti novega načina posredovanja informacije o stanju na računu, ki smo jih priložili k dnevnim izpiskom za imetnike računov. Za čim boljše informiranje o novosti v SDK smo ustrezno informirali tudi delavcev interni kontroli, saj je neposreden stik še vedno prevladujoča oblika komuniciranja med delavci SDK in imetniki računov.

 

Tako dobro načrtovana in izpeljana akcija je takoj pokazala odlične rezultate, saj je bilo že v prvem mesecu, ko smo ponudili storitev, podpisanih nekaj manj kot petsto (500) pogodb za vključitev v SDK SALDOTEL in tudi plačana pristopnina v sistem.

 

Razloge za tako velik odziv lahko verjetno iščemo tudi v nizkih stroških za nakup opreme, saj naročnik potrebuje poleg telefona, vključenega v telefonsko omrežje, le še tonski posrednik (biper - generator tonskega signala, ki ga dobi v SDK), v kolikor nima telefonskega aparata, ki omogoča tonsko izbiranje (DTMF - Dual-tone multi-frequency signaling ali dvotonska večfrekvenčna signalizacija). Velika prednost pa je tudi v celodnevnem dostopu do informacije o stanju na računu in enostavni uporabi.

 

Imetnik računa dobi govorno informacijo s pomočjo SDK SALDOTEL-a tako, da prek telefona poklice številko SALDOTEL-a, nakar mu telefonski odzivnik sporoči, da je poklical SDK SALDOTEL, in ga pozove, naj vnese geslo. Po uspešno vnesenem geslu imetnik računa dobi govorno informacijo o stanju na računu, v nasprotnem primeru pa ga pozove za ponovni vnos. Če tudi tokrat vneseno geslo ni pravilno, SDK SALDOTEL prekine zvezo. Geslo je treba posredovati kot tonski signal, za razliko od običajnega zastarelega pulznega načina izbiranja številk, ki se uporablja pri nas. Geslo vnesemo prek telefona (če ima tonski način izbire DTMF), če pa imamo navaden telefon, moramo geslo vnesti prek posebnega tonskega posrednika (biperja, ki ga naročnik dobi v SDK ob sklenitvi pogodbe). Biper prislonimo na mikrofon telefonske slušalke in vnesemo geslo. Obstajata dve vrsti tonskih posrednikov. Pri prvem, najosnovnejšem, moramo vsakič posebej odtipkati geslo, pri drugem, ki je hkrati tudi žepni kalkulator in mala beležnica, pa lahko shranimo do 10 gesel vnaprej in jih pokličemo iz spomina, ko jih potrebujemo. To naredimo s posebno tipko.

 

Če je geslo pravilno vneseno, dobimo po nekaj sekundah govorno informacijo o stanju na računu. Stanje, posredovano prek SDK SALDOTEL-a, je enako stanju računa na računalniku IBM, saj se vse spremembe stanja na glavnem računalniku tekoče prenašajo iz računalnika IBM na SDK SALDOTEL.

 

Sedaj posredujemo le informacijo o tekočem stanju na žiro računu. Zaradi boljše preglednosti in informiranosti naročnikov SDK SALDOTEL-a pa pripravljamo razširitev rešitve z dodatnimi informacijami, ki jih bo naročnik enostavno dobil z dodatno vneseno izbiro po informaciji o tekočem stanju na računu. Dodatno bomo namreč ponudili še informacijo o končnem saldu prejšnjega dne, o skupnem prometu v breme in skupnem prometu v dobro žiro računa tekočega dne. Na osnovi teh dodatnih informacij bodo naročniki lahko še bolje spremljali spremembe na svojem računu in na osnovi tega sprejemali poslovne odločitve. Predvidevamo, da bodo dopolnjene rešitve implementirane še v letu 1993. Sistem je popolnoma usklajen s katerimkoli računalniškim sistemom in kot tak tudi s predvidenimi novimi računalniki HP. To potrjuje tudi dejstvo, da je bila testna postavitev na računalniškem sistemu Unissys v novomeški podružnici uspešna.

 

Vsekakor pomeni uporaba SDK SALDOTEL-a sodobnejši način informiranja imetnikov računov o stanju sredstev na računu v SDK in tudi racionalnejšo oziroma bolj smotrno izrabo in porazdelitev obremenitve dela vseh udeležencev v plačilnem prometu. Hkrati pa rešitev ponuja največjo možno varnost in zaščito podatkov. Zaradi teh in tudi drugih omenjenih prednosti je vsekakor vredno premisleka, ali bomo v prihodnje posredovali informacije o stanju in spremembah na žiro računih imetnikov računov prek delavcev interne kontrole ali celo mogoče katere tretje osebe, pri tem pa popolnoma pozabili na varovanje podatkov in spregledali možne zlorabe teh podatkov ter si na poceni način zapravili zaupanje in ugled, ki ga še imamo.

 

Enotna matična številka

Novi predpisi določajo mnogo večje število davčnih zavezancev, kot jih je bilo dozdaj. Interes države bo kontrola vseh in seveda zajemanje davkov glede na položaj oziroma premoženje pravne oziroma fizične osebe. Najbolj redno so plačevali dajatve zaposleni delavci v družbenih firmah in pa družbene firme. To je omogočal žiro račun odprt pri SDK in seveda pooblastila SDK.

Zavezanci so različni, od družb z omejeno odgovornostjo, delniških družb, ki so lahko v družbeni lasti, z mešanim kapitalom ali privatnim kapitalom, do fizičnih oseb in civilnopravnih oseb. Skupno je le to, da so zavezanci za plačilo davka na dobiček in drugih obveznosti. Da bi ti davčni zavezanci dobili skupni imenovalec bi morali uvesti enotno matično številko davčnega zavezanca.

Na primer: 11 mestna številka »123456 12 123«  bi pomenila naslednje:

• Prvih 6 (123456) mest bi bilo rezerviranih za številko davčnega zavezanca od  000001 do 999999, kar bi bilo dovolj v kombinaciji z drugima dvema številkama.
• Drugi dve (12) mesti bi določali status davčnega zavezanca: 01-09 fizične osebe, upokojenci, prejemniki OD, podjetja, kjer je lastnik sam zaposlen, kmetje, študentje z lastnimi prihodki, družba z neomejeno solidarnostno odgovornostjo, civilno pravne osebe itd.

• 10 - razne kombinacije več osnov
• 11 - druge organiziranosti pravnih oseb - s kombinacijo teh dveh številk bi lahko določili še dodaten atribut velikost.

• Zadnja tri (123) mesta pa so rezervirana za številko občine.

Sistem bi veljal za vso republiko. Pogoj za registracijo bi bila določitev take številke. Za ostale davčne zavezance pa bi jo določila služba za nadzor ob prvi predložitvi davčne napovedi.

Ta enotna številka bi bila element na vsakem nalogu za prenos. Z dodatnimi elementi bi lahko skozi plačilni promet računalniško spremljali prilive, odlive, plačilo akontacij davčnih obveznosti, medsebojna plačevanja itd.

Ti podatki bi kot predhodne informacije bili temelj za naknadno kontrolo zavezancev.

Pogoj je, da se zakonsko določi uvedbo enotne matične številke zavezanca in da se ta kot element pojavi na vsaki izdani fakturi ter da se evidentira skozi plačilni promet na glede kje ima pravna ali fizična oseba žiro račun.

Organizacijsko bi se lahko ti podatki zbirali v organizacijskem delu družbenega (*) računovodstva kot delu službe za nadzor.

-----------------------

(*) Pod pojmom družbeno ne mislim obliko lastnine ampak premoženje fizičnih oseb, podjetij, javno premoženje itd., torej celotne družbe.


Januar 1991

Nekaj zgodovine tehnologije dela v SDK

Izvrševanje nalog v zvezi s plačilnim prometom, knjiženjem sprememb na žiro računih in evidenc plačilnega prometa je že vseh 25 let neločljivo povezano s tehniko. V tem obdobju je Služba uporabljala pri svojem delu vse od mehanskih knjižnih strojev do računalniških sistemov in razvijala tehnologijo dela, ki je vedno optimalno vključevala razpoložljivo tehniko.

Delavci, ki letos praznujejo četrt stoletnico dela v Službi, posebno tisti, ki so delali v plačilnem prometu (PP) ali družbenem računovodstvu (DR) se prav gotovo dobro spominjajo takratne tehnologije dela. V podružnicah je bilo delo s prejemom, sortiranjem in pripravo plačilnih dokumentov oddvojeno od strojnega knjiženja. Osnovo za knjiženje so tvorili dokumenti, ločeni na odobritve in obremenitve, sortirani po posameznih osnovnih računih DR in individualnih partijah. Plačilni promet je za tako pripravljene dokumente že izdelal konsignacijo, to je kontrolni seštevalni trak, ki je služil kot osnova za knjiženje v družbenem računovodstvu. Sistem kontrole sloni na dvojnem knjigovodstvu, zato se je moral promet v breme na vseh osnovnih računih ujemati s prometom v dobro. Vsak dan znova je ekipa v oddelku DR s strahom čakala na izid končnega seštevanja prometa po osnovnih računih. Najmanjša razlika v tem trenutku je pomenila utrudljivo iskanje napake v celotnem gradivu tistega dne.

Plačilni promet je svojo nalogo priprave dokumentov za knjiženje končal po navadi do 17. oziroma 20. ure. DR, ki je po tem času prevzel štafetno palico pa se je v odvisnosti od natančnosti dela plačilnega prometa kot tudi delavcev pri strojnem knjiženju v DR, ubadal s knjiženjem, ki se je končalo z vlaganjem izdelanih izpiskov v predalčke uporabnikov, tja do 20. ali pa do 6. ure zjutraj.

Knjiženje prometa na individualnih partijah uporabnikov družbenih sredstev je bilo popolnoma ločeno od knjiženja razčlenjenega prometa za potrebe družbene evidence.

Edini medij za knjiženje so bile knjigovodske kartice. V oddelkih družbenega računovodstva je bilo zato vedno na kupe kartic, zloženih v kovinske zaboje ali vozičke.

Pogled v strojnico bivšega DR je bil zaradi množice mehanskih šklepetajočih strojev skoraj impozantnejši od današnjih lekarniško čistih in urejenih elektronskih računskih centrov. Ob vsakem stroju je stal voziček s kovinsko škatlo, v kateri so bile kartice za knjiženje. Knjiženje prometa in izdelava izpiskov je tekla na velikih, samostojno stoječih knjiženih strojih, postavljenimi drug za drugim kot tiskarski stroji v tiskarni. Razčlenjeni promet smo knjižili na malih namiznih knjižnih strojih, pravih pritlikavcih v primerjavi s prvimi. Cel sistem priprave in knjiženja je zahteval disciplinirano in natančno delo. Skrita napaka, ki je nastala v plačilnem prometu že dopoldne ali zgodaj popoldne, je bila odkrita šele po izdelavi končne bilance, torej ob primerjavi celotnega prometa v breme in dobro. Zaradi tega je bil delovni čas v plačilnem prometu in družbenem računovodstvu pravzaprav variabilen. Nič kolikokrat so se dekleta in fantje vračali z dela, ki so ga začeli že zjutraj, šele v poznih večernih ali celo jutranjih urah. Možje in fantje, v SDK so delala večinoma dekleta, so večkrat zaman čakali pred vrati podružnice. To slabo lastnost tedanje tehnologije so seveda dobro poznali vsi delavci v teh dveh organizacijskih delih. Medsebojna odvisnost delavcev, ki jo je narekovala taka tehnologija je zahtevala kar najboljše sožitje, stkala nič koliko pristnih prijateljskih zvez in naredila delovno in močno solidarnostno vzdušje v teh kolektivih.

Periodične in zaključne račune je Služba obdelovala le na Centrali. Leta 1964 je bil instaliran v stolpnici na Kidričevi ulici prvi Univac, klasičen računalniški sistem. Vhodni podatki so se luknjali na kartice. V računalniško konfiguracijo je sodila še sortirka kartic, tabelirka in pa seveda sami luknjalniki kartic. Računalniški sistem je bilo mogoče programirati z ožičenjem programskih plošč. Ekipa delavcev iz AOP je uspešno delala na njem skoraj deset let.

Leta 1970 se je SDK odločila za modernizacijo tehnologije dela. Sklenjeno je bilo:

• da se prenesejo na računalniško obdelavo podatkov vsa najmasivnejša dela: plačilni promet, evidenca in statistična raziskovanja, pomembna za celo državo. Zagotoviti je bilo treba čim hitrejše kroženje denarnih sredstev in čim popolnejše informiranje združenega dela in družbenopolitičnih skupnosti.
• da se sistem obdelave podatkov zastavi decentralizirano, torej po podružnicah, ker so pač le-te pri vsakodnevnem opravljanju dela, neposredno povezane z organizacijami združenega dela in DPS. Obdelava plačilnega prometa, to pomeni prejem, priprava in knjiženje naj bo v podružnicah. Podatki Službe morajo predstavljati neposredno osnovo za informacijske sisteme družbenopolitičnih skupnosti in združenega dela.
• zagotovit je treba enotno tehnologijo dela pri obdelavi vseh podatkov, ki so pomembni za vso državo.
• zagotoviti je treba celovito tehnično-tehnološko kompatibilnost računalniških sistemov v organizacijskih enotah Službe.
• v drugi fazi avtomatizacije je treba zagotoviti povezavo elektronskih računalniških sistemov v podružnicah v enotno mrežo za TK prenos podatkov v Službi.

Leta 1972 so v Službo pričeli prihajati prvi računalniški sistemi. Ljubljana je dobila IBM 370/135. Spominjam se še predloga, naj bi bila kapaciteta internega pomnilnika 63 Kbytov, to je malenkost več, kolikor jo ima danes osnovna verzija hišnega računalnika Spectrum. Maribor, Celje in Kranj so dobili Singerjeve računalniške Sistem 10. Za zajemanje podatkov je bila izbrana Datica. To je luknjalnik papirnatega traku. Nova tehnika je nujno zahtevala tudi spremembo tehnologije.

Zaradi računalniške kontrole usmerjanja sredstev je Služba vsem uporabnikom menjala številko žiro in drugih računov. Neizkušenost in obremenjenost z ročno tehnologijo dela je povzročila nedoslednost pri določanju konstrukcije nove številke. Le-ta je sestavljena iz številke sedeža SDK, osnovnega računa in številke partije. Sistem kontrole zajemanja s kontrolno številko zajema le individualno partijo, izven take kontrole pa je ostala številka sedeža SDK in številka osnovnega računa po kontnem planu SDK.

Neizkušeni smo bili tudi pri določanju tehnologije kontrole pravilnosti zajemanja drugih podatkov. Kljub uvedenemu kontrolnemu seštevku, je bil ta seštevek, po zapisu podatka v prometno datoteko, zavestno izpuščen. Podatki so se sortirali kot prej dokumenti, v breme in dobro, narejena je bila končna bilanca in šele takrat je bilo znano, če je bilo zajemanje podatkov na Datikah v redu opravljeno.

Datičarka, kot smo imenovali operaterke na novih zajemalnih strojih, je lahko s pomočjo seštevka na začetku, kontrolirala pravilnost vpisanih zneskov. Ker pa je bil podatek luknjan na papirnati trak, napak ni mogla popraviti. Tudi napak pri prenosu številk partij ni bilo mogoče kontrolirati. Zato je v sistemu zajemanja in kontrole podatkov prišlo do faznega zamika, ki je razmaknil posamezne faze dela tudi za 8 ali več ur. Predpisana tehnologija je zahtevala previjanje papirnatih luknjanih trakov pred konvertiranjem na magnetni računalniški trak.

Opisane pomanjkljivosti so narekovale takojšnjo spremembo začrtane tehnologije in s tem tudi spremembo celotnega paketa programov za kontrolo in obdelavo podatkov plačilnega prometa. Matjaž Čadež iz Intertrada, s svojimi in našimi sodelavci, je realiziral nov programski paket, ki je slonel na precej spremenjenih osnovnih principih zajemanja in kontrole podatkov.

Nova računalniška tehnologija je zahtevala drugačno organizacijo dela. Vpeljane so bile naslednje faze dela:

• priprava dokumentov
• luknjanje podatkov
• sistemska kontrola
• elektronski računski center
• sortiranje dokumentov in prilaganje izpiskov.

Kljub precejšnjem izboljšanju začrtane tehnologije dela, nova tehnika ni prinesla pričakovanega učinka. Iskanje napake, končno bilanciranje, ki ga je opravljala sistemska kontrola, je bilo v veliki odvisnosti od števila in tipa napak. Namesto pričakovanega olajšanja, je tudi nova tehnologija zadržala variabilen delovni čas, ropot strojev, in še povečala odvisnost celega procesa obdelave od delovanja sedaj le enega stroja – računalnika. Prilaganje dokumentov izpiskom in konsignaciji, izdelani na računalniškem sistemu je predstavljalo in to še danes, zadnjo fazo kontrole pravilnosti zajemanja podatkov.

Po šestih letih delovanja navedenih tehničnih sredstev in tehnologije dela se je Služba odločila za precejšnjo spremembo. Zajemanje podatkov s kontrolo, ki je predstavljalo najzahtevnejšo in obenem najbolj občutljivo fazo v celotnem sistemu obdelave plačilnega prometa, naj bo interaktivno in dislocirano od glavnega računalniškega sistema v velikih podružnicah. Napako, storjeno ob zajemanju, je treba odkriti takoj in popravi naj jo tisti, ki jo je tudi napravil. Formalna, logična in računska kontrola je bila vgrajena v kontrolni program na mini računalniških sistemih IBM S/1 in Burroughs 1800 s priključenimi ekranskimi terminali.

Šele taka tehnologija dela je izpostavila veliko učinkovitost računalniške tehnike. Skoraj čez noč so bile ukinjene nočne izmene, v katerih so delale večinoma žene in mladina. Znatno se je izboljšala kvaliteta našega dela, saj je padlo število reklamacij na neznatni minimum. Tudi ažurnost in učinkovitost se je precej povečala. Kot primer navedimo le podatek, da smo prej obdelovali zaključne in periodične obračune do nivoja federacije 3-5 mesecev, danes pa potrebujemo za tako delo na navedenem nivoju le še 15 dni.

Služba družbenega knjigovodstva v SR Slovenji ima danes instalirano naslednjo računalniško opremo. V podružnicah Ljubljana, Maribor, Celje in Kranj računalniške sisteme IBM 370/ in 4331 ter za zajemanje podatkov IBM S/1 z ekranskimi terminali. V ostalih podružnicah so za zajemanje in obdelavo računalniški sistemi Burroughs, tudi z ekranskimi terminali.

Vzporedno z opremljanjem s tehničnimi sredstvi za AOP je Služba intenzivno pripravljala potrebne kadre, da bi vsa vlaganja v opremo dajala čim prej pričakovane rezultate.

Služba se je orientirala na strokovno usposabljanje delavcev iz obstoječega sestava. Na tak način smo v Sloveniji pridobili več kot 14 vodij računalniških centrov, 10 projektantov, čez 20 programerjev, okrog 50 operaterjev na sistemu, čez 300 operaterjev na zajemalnih strojih oziroma ekranskih terminalih, pa kontrolorjev in ostalih delavcev, ki sodelujejo v avtomatski obdelavi podatkov.

Naslednji važni element avtomatizacije je izdelava aplikativnega programja. Na tem področju je bila Služba, zaradi večjega števila enakih računalniških sistemov in enotne tehnologije dela, najbolj učinkovita. Za okrog 100 projektov na zveznem nivoju je bilo izdelanih preko 2.000 programov za zajemanje in obdelavo podatkov.

Sedanje stanje računalniške tehnologije obdelave podatkov in tehnike v Službi še ni zadovoljivo. V obdelavi podatkov je še vedno prisotno mnogo preveč ročnega dela. Identifikacija uporabnikov družbenih sredstev je prav tako še vedno neprimerna za popolno avtomatizacijo dela. Računalniški sistemi v SDK so nepovezani. Od uporabnikov družbenih sredstev še vedno prejemamo vhodne podatke le na papirnatih dokumentih. V nekaterih naših podružnicah so sicer že pričeli s poskusi pridobivanja podatkov na magnetnih medijih, vendar obstoječe organizacijsko tehnološke rešitve, ki izvirajo še iz obdobja ročnega dela, zavirajo razvoj v tej meri.

Za naslednje srednjeročno obdobje ima Služba v načrtu ponovno modernizacijo svojega dela, z naslednjimi glavnimi značilnostmi:

še večja distribuiranost obdelave v organizacijskih enotah SDK,
nova konstrukcija številke žiro in drugih računov, ki naj omogoča popolno kontrolo brez konzultacije baze podatkov. Tako bo mogoče zajemati podatke le enkrat in jih takoj vključiti v plačilni promet,
šifriranje namena nakazila bo omogočilo zaustaviti papirnate naloge na sedežu iniciative,
izdelati bazo podatkov za predhodno kontrolo in analize.

Pri tej modernizaciji naj bi sodelovala tudi domača industrija, ki naj bi v bodoče predstavljala čvrsto in zanesljivo oporo Službi pri opremljanju in nadaljnjem razvoju sistema avtomatske obdelave podatkov.

Maj 1980

Pripombe k modernizacije tehnologije dela v SDK

V gradivu osnovne koncepcije modernizacije tehnologije dela v SDK se omenja tudi informacija, da bo neposredno ugotavljanje vsebine informacijskega sistema Službe na bazi podatkov plačilnega prometa sledilo šele po sprejetju zakona o družbenem sistemu informiranja.

Mislim, da je treba delo pri razvoju nove tehnologije nadaljevati v smeri celovitega in računalniško podprtega plačilnega prometa. Nova tehnologija mora predvsem zagotavljati popolno in točno informacijo o tem kdo plačuje, komu, koliko in zakaj. Pri tem »zakaj« mislim predvsem prvobitno osnovo plačila, torej, račune, poravnave dolga ali podobno.

V zvezi z nadaljnjim evidentiranjem namena plačevanja je treba dejansko počakati nov zakon o DSI. Če bo treba omenjene evidence voditi še vnaprej, ali jih celo razširjati, mora nova tehnologija prvič to upoštevati, drugič pa mora prav tako zagotoviti popolnost in točnost te informacije. Kontrola zapisa in zajemanja te informacije mora biti programirana že na vhodu in ne šele po končani dnevni obdelavi ali celo pri mesečnem tabeliranju teh podatkov.

Načelo nove tehnologije naj bi bilo, da je vsaka informacija, ki jo Služba pridobiva na osnovi plačilnega prometa popolnoma zanesljiva. Pri določanju povezav med šiframi namena nakazila in identifikacijo številke UDS oziroma vrste in namena sredstev v oznaki žiro računa je treba vgraditi algoritem, ki bo zagotavljal pravilnost in kontrolo teh podatkov.

Nova tehnologija plačilnega prometa mora prav tako upoštevati storno prometa in zagotoviti pravilnost zajemanja in obdelave glede na značaj plačila (v breme, v dobro), kar je ena od večjih pomanjkljivosti sedanje tehnologije dela računalniško podprtega plačilnega prometa.

Glede izvajanja nove tehnologije v prehodnem obdobju sem mnenja, da je treba »zaustaviti papirje« povsod naenkrat. Podružnice, ki še nimajo tehničnih možnosti za telekomunikacijski prenos podatkov naj pošiljajo zbirno avizo s sekundarno generiranimi nalogi na računalniških tiskalnikih. Ekspoziture, ki so direktno vključene v plačilni promet bi bile edine izjeme, vendar je treba tudi pri teh čimprej izvesti centralizirano obdelavo na podružnici. Ta organizacijski korak bi v prvi vrsti kroženje denarnih sredstev na področju take podružnice, zato tudi ti ukrepi sodijo k pripravam na modernizirano tehnologijo v SDK.

V zvezi z numeričnimi oznakami za namen nakazila lahko na osnovi individualnih razgovorov z uporabniki družbenih sredstev posredujem njihovo mnenje, da naj se za vsako plačilno obveznost izpolni po en nalog plačilnega prometa. Če pride do plačevanja več obveznosti z enakim namenom plačila (plačilo računa) in le z različnim sklicevanjem na številko, naj bi se uvedel zbirni nalog s specifikacijo.

Načrt osnovne koncepcije modernizacije tehnologije dela v SDK je zelo dobro sestavljen, opaža pa se, da nekatere aktivnosti že zaostajajo za načrtovano dinamiko razvoja. Čimprej bo treba določiti odgovorne nosilce za vsako planirano dejavnost in pripraviti vse uskladitve v zvezi z nalogami in odgovornostmi, kot tudi finančnimi obveznostmi med posameznimi centralami in podružnicami, ki so potrebne za realizacijo celega projekta.


junij 1982

Aktivnost SDK Ljubljana pri uveljavljanju TK prenosa

Junij 1991

V začetku leta 1991 so bile vse podružnice SDK v R Sloveniji med seboj povezane v republiško TK mrežo z računalniki Unisys in IBM. S tem je bil izpolnjen prvi pogoj za uvedbo popolnega TK prenosa podatkov z nalogov plačilnega prometa v SDK.

Ker pa za uspešno delovanje tako kompleksnega in pomembnega sistema, kot je TK prenos podatkov, niso dovolj le lepe želje, temveč je potrebno še kaj več, sem mnenja, da je Služba v letih, odkar je začela uvajanje TK prenosa podatkov (od leta 1984 dalje), bila premalo aktivna tako na področju razvoja in nadgradnje obstoječih tehnoloških rešitev v Službi in sodelovanju z zunanjimi institucijami, kot tudi pri izobraževanju in sodelovanju z uporabniki naših storitev - podjetji in iskanju novih rešitev za odpravo napak in težav, ki se pojavljajo pri delu v funkciji.

Z razvojem in nadgradnjo TK prenosa podatkov smo bili preveč pod vplivom in odvisnostjo SDKJ (kar je zaradi enotnosti PP lahko zagovarjati), včasih pa je taka odvisnost in povezanost lahko služila tudi za izgovore.

Če bi hoteli doseči maksimalne učinke in prednosti TK prenosa podatkov, pa menim, da bi morala biti formirana mešana delovna skupina, sestavljena iz strokovnjakov službe s področja funkcije plačilnega prometa in AOP-ja ter zunanjih institucij (ki se ukvarjajo z informacijskimi sistemi) in uporabnikov storitev. Skupina bi morala dajati pobude za nove rešitve in nadgradnjo obstoječega koncepta TK in usklajevanja interesov, zahtev in možnosti uporabnikov in izvajalcev storitev.

V sedanji organiziranosti Službe je bil povezovalni člen med uporabniki in plačilnim prometom oddelek preventivne kontrole, vendar zaradi preobremenjenosti s kontrolno funkcijo in medorganizacijsko (funkcijsko) ločenostjo ta komunikacija ni funkcionirala optimalno. Dobro bi bilo, ali bi ta problem funkcijske povezanosti s prihodnjo organiziranostjo Službe rešili.

Že od uvedbe TK načina prenosa podatkov naprej se srečujemo s podobnimi težavami in problemi, tehnološke rešitve samega zajema in prenosa podatkov pa se do danes bistveno niso spremenile. Če bi hoteli obdelati vse naloge plačilnega prometa prejete od imetnikov računov v podružnici Ljubljana po TK načinu (teh pa je bilo v letu 1990 45.890.772, kar je približno 40 % vseh obdelanih nalogov v SDK R Sloveniji, približno enak odstotek obsega dela pa odpade tudi na ostala opravila v plačilnem prometu), bi bila nujna posodobitev obstoječe tehnologije dela in opreme, saj trenutno zajemamo na tri različne načine (preko PC, S1 in S1 z EDX operacijskim sistemom). Vsekakor je to primer, kako se množična obdelava NE sme delati. Če k temu dodamo še dva različna kontrolna programa (TK in TEZAURUS), obilo različnih plačilnih instrumentov in načinov izvršitve, potem lahko v bližnji prihodnosti pričakujemo zrušitev sistema, če ne bomo v doglednem času nekaj ukrenili.

Kot prvo je treba takoj začeti aktivnosti, da prenehamo pošiljati naloge po TK-4 načinu, saj je bil ta način izvršitve ob uvajanju TK prenosa sprejet kot začasna rešitev. Tovrstni način dela nam povzroča največ problemov in težav pri TK obdelavi. V letu 1990 je podružnica Ljubljana obdelala 4.410.467 nalogov po TK, od tega jih je bilo 2.488.525 po TK-4 načinu ali 56 %. Namesto da bi se odstotek TK-4 nalogov manjšal in povečevalo število TK-1 nalogov, smo v Službi ustvarjali trend ravno v obratni smeri. Enako stanje je tudi v letu 1991, čeprav za to ni nobenih razumnih vzrokov, temveč so bile razvite nove rešitve, ki omogočajo hitrejši zajem podatkov po TK-1. Tudi če pregledamo prejete originalne naloge po TK-4, lahko kaj hitro ugotovimo, da ima velik del teh nalogov vse pogoje, da bi bili izvedeni po TK-1 načinu, vendar to iz takšnih ali drugačnih vzrokov ni tako.

Kot drugo pa bi morali intenzivneje pristopiti k informiranju podjetij ter nazornemu prikazu prednosti in koristi, ki jih prinaša tak način prenosa podatkov, ter pravočasno opozoriti uporabnike na pomembnost posameznih podatkov v desnem delu virmanskega naloga (predvsem vezna oznaka in sklicevanje na številko). Za uspešno delo pa bi morali akcijo izvajati koordinirano na celem območju R Slovenije.

Kot tretje pa bi morali delavci interne kontrole posvetiti več pozornosti na pravilno izpolnjevanje podatkov, ki so pomembni za TK prenos. To so predvsem podatki »sklicevanje na številko« in vezna oznaka, ter na vse napačno izpolnjene podatke opozoriti predlagatelje virmanskih nalogov in zahtevati, da so naslednjič ti podatki pravilno formirani in vsebinsko ustrezni.

Če bomo od julija 1991 dalje prenašali naloge (tiste, ki izpolnjujejo te kriterije) le po TK-1 načinu, si vsekakor ne bi smeli dovoliti pošiljanja nalogov po TK-4 načinu, če obstajajo na takem nalogu podatki, ki omogočajo TK-1 prenos. Če bi obdelali vse naloge po TK-1 načinu, to ne bi smel biti vzrok za dodatno - tretjo izmeno, ker bi bilo treba okrepiti popoldansko izmeno, ki bi pretežno skrbela za kontrolo vnesenih podatkov, s tem pa bi lahko zmanjšali tudi odstotek napak in reklamacij, hkrati pa bi odpadlo klasiranje nalogov za pošiljanje po pošti za kompletiranje TK-4.

Vzroki, ki nam ovirajo pravočasno končanje obdelave in s tem nakazujejo potrebo po tretji izmeni, so predvsem pozen sprejem zadnjega preseka prejetih TK nalogov od SDKJ iz Beograda in dodatne zadolžitve Službe v večernih urah (reševanje likvidnosti bank) ter občasno tudi okvare računalniške opreme.

Če pa bi se pokazalo, da celotnega dela ne moremo opraviti v predvidenem času, pa ne bi smelo biti problematično dodatno zaposlovanje delavcev na področju plačilnega prometa, saj vsi vemo, da je to ena od vitalnih funkcij Službe in je bila vedno argument, s katerim smo lahko zagovarjali obstoj Službe družbenega knjigovodstva in opravljanje plačilnega prometa v neodvisni instituciji.

Glede na to, da živimo v dobi informacijske tehnologije, kjer so pravočasne in točne informacije najbolj iskano in pomembno blago, kar pa vsekakor so informacije o prilivu oziroma odlivu denarja na žiro računu, se bomo morali počasi zavedati dejstva, da nam ni dano za vedno in samo nam opravljanje plačilnega prometa. Verjetno se bo tudi na tem področju čez čas pojavila konkurenca, ali pa si bodo uporabniki naših storitev poiskali alternativne rešitve (tako kot RTV Slovenija) in z nekom drugim sklenila posel, ki ga je do nedavna opravljala Služba, pa se zaradi svoje togosti ni mogla prilagoditi zahtevam in potrebam uporabnikov. V podružnici Ljubljana se je že več podjetij oglasilo z željo, da bi jim Služba zajemala podatke (sklicevanje na številko odobritve) ter posredovala tako zajete podatke na magnetnih medijih za njihovo nadaljnjo uporabo. Vendar ker nam obstoječe tehnološke rešitve ne omogočajo takega načina dela (lokalni TK za določenega uporabnika), smo jim ponudili le obstoječe rešitve, ki pa vsekakor niso zadovoljile pričakovanj. Zaradi svojega obstoja in preživetja pa so na ta način prisiljeni iskati druge rešitve zunaj SDK, kar pa vsekakor ni v korist Službi.

Kako so »orali ledino«

Ljubljanski Dnevnik je v letu 1995 objavljen članek "Vse, kar imamo, ni tako slabo". Govori o posodobitev plačilnega prometa, ki ga v imenu in na račun Agencije RS za plačilni promet, nadziranje in informiranje (APPNI) izvaja podjetje Hermes SoftLab. Namen tega pojasnila ni polemizirati, kako "je bilo jeseni 1992 to podjetje izbrano za glavnega zunanjega izvajalca" ali o "vsebinski in tehnološki posodobitvi plačilnega prometa". Zadnji del članka govori, kako so »v Agenciji skupaj z Hermes SoftLabom na področju razvoja plačilnega prometa orali ledino, saj je Slovenija po osamosvojitvi ostala tako rekoč brez tovrstnega tehnološkega znanja, ki je doslej prihajalo iz Beograda«.

To »oranje ledine« je treba pojasniti.

V bivši Jugoslaviji je takratna SDK opravljala plačilni promet po enotni tehnologiji, ki je še danes velja v Sloveniji in jo tudi posodobitev plačilnega prometa še kako upošteva in uporablja. Tehnologija izvajanja plačilnega prometa je bila izvedena z aplikativnimi programskimi sistemi (APS) in strojno opremo za tri različne računalniške sisteme in sicer IBM, Borroughs-UNISYS in NCR. Grobo lahko razdelimo APS za plačilni promet v tri sklope:

(1) vzdrževanje podatkov,
(2) vnos in obdelava dokumentov plačilnega prometa in
(3) izdelava vseh potrebnih izpisov, poročil, pregledov.

Prvi prehod na avtomatizacijo in računalniško podprto obdelavo plačilnega prometa je bil narejen februarja 1973 v Ljubljani s projektom AROPS, izdelanim v Beogradu. In v daljnem letu 1973 smo delavci SDK res orali ledino. Pokazalo se je, da le preslikava takratne "ročne" obdelava plačilnega prometa v računalniško okolje ne zadostuje. Tako smo jeseni 1973 v Ljubljani pričeli razmišljati in tudi izdelali jedro računalniške programske opreme za IBM računalnike. Narejen je bil projekt, imenovan TEZAURUS, ki je vseboval tehnološke specifikacije, zahtevke in določitve za izdelavo posameznih programskih rešitev ter ustrezne spremembe pri ročni obdelavi (sortiranje dokumentacije in kompletiranje z računalniškimi izdelki). Še več, v Ljubljani smo izdelali vse programe za prva dva sklopa (vzdrževanja podatkov ter vnos in obdelavo dokumentov plačilnega prometa) ter sodelovali pri izdelavi programov za tretji sklop (izdelava vseh potrebnih izpisov, poročil itd). Poznejši telekomunikacijski prenos podatkov, ki omogoča večkrat dnevno izmenjavo dokumentov plačilnega prometa, tudi ni šel mimo Slovenije.

Skoraj 22 (dvaindvajset) let star projekt, ki pa še danes odlično služi svojemu namenu, bo tako zamenjan. Ni odveč tudi podatek, da se v Sloveniji na IBM strojni opremi (Ljubljana, Celje, Kranj in Maribor) in s programsko opremo, ki smo jo razvili in izdelali v SDK Ljubljana s sodelovanjem strokovnjakov IBM z Dunaja in Intertrade iz Ljubljane, dnevno obdela približno 70% vsega plačilnega prometa republike Slovenije. Tudi večje SDK podružnice v drugih republikah z IBM računalniškimi sistemi uporabljajo APS TEZAURUS. Groba ocena je, da se v plačilnem prometu po celi Jugoslavi ob uporabi programske opreme TAZAURUS obdela okoli 70% vseh dokumentov (virmani, čeki, položnice itd.).

Ni mi poznano koliko in kako so do jeseni 1992 v Hermes SoftLabu imeli opravka s plačilnim prometom. Če je to bilo le vsakomesečno plačevanje položnic za elektriko, telefon in morda še kakšno knjigo, potem so res orali ledino.

Delavcem APPNI oziroma prejšnje SDK tega zagotovo ni bilo treba.