Projekt ARGUS

V stari grški mitologiji je bil najvišji bog ZEUS. Ob vsej kreposti pa se je zaljubil v lepo svečenico IO. Ko je za to zvedela HERA, ljubosumna Zeusova žena, je naročila stookemu, vedno budnemu čuvaju z imenom ARGUS, paziti na Io, da se ne bi shajala z Zeusom.

Pravljica 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.


Zakonska ureditev SDK temelji na določbah zvezne in republiške ustave in drugih zakonov. Po teh določbah opravlja SDK evidenco in informacijsko analitične zadeve o razpolaganju s sredstvi imetnikov računov. SDK nadalje opravlja nadzorstvo nad zakonitostjo razpolaganja s sredstvi in nadzorstvo nad izpolnjevanjem obveznosti vseh pravnih oseb. SDK opravlja tudi enoten plačilni promet v državi.

Vsaka pravna oseba mora imeti pri SDK odprt žiro in morebitne druge račune. Do 18. 10. 1989 je SDK uporabljala obrazec RUDS (Register Uporabnikov Družbenih Sredstev), po navedenem datumu pa je v veljavi obrazec RIR (Register Imetnikov Računov, U.l. SFRJ 64/89). Vsebinsko sta oba obrazca skoraj identična. Ta obrazec je vhodni dokument za odpiranje vseh potrebnih zapisov v ustreznih podatkovnih zbirkah.

Poudariti velja, da je postopek za odpiranje računa predpisan, enoten in velja za celotno Jugoslavijo. Enotna in predpisana je tudi računalniška podpora, ki pa je v nekaterih delih že zastarela.

Pogoji za odprtje žiro računa pri SDK so med ostalim tudi: vpis v sodni register, kartoni z deponiranimi podpisi, pridobitev ustrezne matične številke na Zavodu za statistiko Republike Slovenije, akt o ustanovitvi, določitev oznake dejavnosti svojega poslovanja, pogodba s poslovno banko, vpis v register pravnih oseb pri podružnici SDK, kjer je sedež in naslov pravne osebe, vlogo za odprtje depozitnega računa itd.

SDK določi še naslednje podatke: številko žiro računa iz enotnega kontnega plana računov, številko partije, oznako poslovne enote SDK, preko katere bo potekalo poslovanje bodoče pravne osebe, dogovorijo se, kako bo potekalo obveščanje o spremembah stanja na žiro in drugih računih, določijo se še vsi ostali podatki (namen, značaj, pomen,  izločena sredstva, oznako poštne številke, oznako lastnine itd).

Vse te podatke delavci referata RIR ročno vpišejo na določena mesta obrazca RIR. Tako izpolnjen obrazec gre, poenostavljeno rečeno, v računalniško obdelavo in če je vse brez napak, je račun odprt, sicer pa sledi popravljanje in ponovna računalniška obdelava.

Sam APS, ki opravlja vse aktivnosti v zvezi z registrom imetnikov računov, je poznan pod imenom JUTRANJI PROGRAM (velja le za podružnice z IBM opremo). Naj nas ime (v ednini) ne zavede: to je več programov, ki imajo nalogo celovitega vzdrževanja vseh podatkov o imetnikih računov v SDK.

Podatki, ki jih JUTRANJI PROGRAM vzdržuje se nahajajo v naslednjih podatkovnih zbirkah - datotekah: REGISTER vsebuje vse podatke z obrazca RIR, MATIČNA vsebuje podatke o vseh finančnih spremembah za posameznega imetnika računa, PRORAČUN uporablja, vzdržuje in ažurira poseben APS, naloga JUTRANJEGA PROGRAMA je le, da odpira ali zapira določene proračunske račune in tako skrbi za enotnost podatkov, INVESTICIJE, ki jo podobno kakor PRORAČUN vzdržuje, uporablja in ažurira poseben APS, naloga JUTRANJEGA PROGRAMA je le v zagotavljanju konsistentnih podatkov do datoteke REGISTER in pomožne datoteke, ki se uporabljajo kot delovne (začasne) med samim izvajanjem JUTRANJEGA PROGRAMA in se takoj nato brišejo.

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

• čitanje podatkov z diskete
• sortiranje
• kontrola pravilnosti podatkov
• izpisovanje protokola o kontroli
• ažuriranje ustreznih podatkovnih zbirk
• izpis vseh podatkov iz ažuriranih datotek.

Celoten postopek brez ažuriranja se lahko izvrši večkrat dnevno, samo ažuriranje pa le po končani dnevni obdelavi plačilnega prometa, kar je običajno v poznih popoldanskih ali večernih urah.

Omenjen je bil "enoten plačilni promet v državi". Zelo na kratko in poenostavljeno lahko operativne naloge v pogojih računalniško podprtega plačilnega prometa opišemo z (1) opravili vzdrževanja osnovnih in drugih podatkov o imetnikih računov, (2) vnos in kontrola podatkov z inštrumentov plačilnega prometa in (3) obdelava in izdelovanje obvestil o spremembah na žiro računih pravnih oseb.

To razdelitev pa izvajalno (računalniško) pokrivajo naslednje APS: JUTRANJI PROGRAM, kontrolni program in dnevna 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 - VP 5,
• ponovno odpiranje imetnikov računov - VP 7 in
• pomožne naloge kot pomoč delavcem referata.

Podatkovna zbirka s podatki imetnikov računov se imenuje REGISTER. To je podatkovna zbirka VSAM (Virtual Storage Access Method), organizirana kot KSDS (Keyed Sequence Data Set). Do datoteke REGISTER se lahko pristopa  direktno -, po ključu ali  zaporedno (sekvencialno) s pričetkom od poljubnega ključa naprej.

Ključ datoteke REGISTER je dolg 13 znakov sestavljen iz osnovnega računa (3 cifre), namena ali občine (3 cifre) in individualne partije (7 cifer). S tako oznako se nedvoumno označi posameznega imetnika računa.

V SDK se uporablja različna strojna in ustrezna programska oprema. Ta zapis obsega le IBM opremo, ti. arhitekture /370, 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, tračne magnetne enote IBM 3420, model 7 in 8, tiskalniki IBM 4245 z hitrostjo pisanja do 2.000 lpm, komunikacijska kontrolna enota IBM 3705 za 16 linij, lokalna terminalska mreža s kontrolnimi enotami IBM 3272, 3274 in 3174. Skupaj je v uporabi približno 50 ekranskih terminalov.

Programska oprema pa je naslednja: celoten računalniški sistem kontrolira operacijsko programje VM/SP, ki omogoča delitev strojne opreme različnim uporabnikom kot zaključene celote, VSE/SP je osnovni operacijski sistem, ki omogoča odvijanje vseh APS za potrebe SDK, VTAM za kontrolo, podporo in nadzor celotne računalniške mreže, CICS za kontrolo in izvajanje vseh uporabniških on-line transakcij, VSAM kot način organizacije datotek in ustreznih pristopov do podatkov, SQL kot relacijska banka podatkov, PL/I kot programski jezik v katerem je napisanih večina programov, CSP kot jezik četrte generacije, ki pa ga kot orodje in pripomoček šele uvajamo v SDK in niz pomožnih (utility) programov za lažje delo, predvsem kot pomoč pri vzdrževanju operacijskega programja.

Vse APS, ki se uporabljajo v SDK so med IBM računalniškimi sistemi prenosljive. Delavci sektorja za računalniško obdelavo podatkov centrale v Ljubljani, kjer se izvajajo vse obdelave za podružnico Ljubljano, uporabljajo za programiranje in razvoj VM/SP, CMS in ustrezne prevajalnike.

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
• komunikacijska kartica, ki preko kontrolne enote 3274 omogoča povezavo z osrednjim računalniškim sistemom IBM 4341 na Cankarjevi 18
• operacijski sistem PC DOS 3.30
• emulacijski program IBM 3270 Entry Level 1, ki omogoča emulacijo ekranskega terminala IBM 3270.

Že na začetku je zapisano opozorilo, da ni nobene možnosti za spremembo osnov in principov obdelave registra imetnikov računov, lahko pa izboljšamo orodje in način dela ter tako posodobimo sedanje stanje.

Slabosti sedanjega stanja so predvsem:

• Izrazita zaporedna (batch) obdelava v vseh segmentih in vseh postopkih vzdrževanja in uporabe podatkov registra imetnikov računov.
• Najmanj enodnevna zakasnitev obdelave JUTRANJEGA PROGRAMA, ki se pokaže kot ovira pri vsebinski napaki ali pri vnosu podatkov na računalniškem sistemu IBM S/1.
• Praktično brez izdelanih sprotnih (on-line) transakcij. Priznati je treba, da vsako sprotno ažuriranje ni dovoljeno zaradi podatkov, ki so distribuirani na različnih računalniških sistemih.
• Izdelovanje in izpisovanje različnih vrst imenikov na papir že dan po obdelavi pridobijo "muzejsko" vrednost ob podatku, da je dnevno tudi po nekaj 100 različnih sprememb v datoteki REGISTER.

Iz vsega navedenega sledi, da  ne obstojajo omembe vredni programi in transakcije, ki bi jih lahko koristno uporabili pri iskanju rešitev in izboljšav na področju računalniško podprte obdelave registra imetnikov računov v SDK podružnicah z IBM opremo.

Podružnica Ljubljana, sektor za evidenco in plačilni promet je pisno zahteval, da se organizira in izdela ustrezne programske rešitve kot pomoč pri delu delavcem v referatu RIR. Na skupnem sestanku smo pregledali zahtevek in določili naslednje aktivnosti:

• Delavcem referata RIR omogočiti sprotni vpogled v podatke datoteke REGISTER - takoj po pridobitvi najete telefonske linije.
• Vse dosedanje ročno delo (zbiranje dokumentacije, kontrola pravilnosti podatkov itd.) ostane nespremenjeno.
• Poiskati in narediti takšno organizacijsko - programsko rešitev, ki bo omogočala:
• Namesto vpisovanja podatkov v obrazec RIR njihov vnos v osebni računalnik.
• Izdelati programske rešitve za vnos in kontrolo na osebnem računalniku ob stalni aktivnosti in pomoči transakcije na glavnem računalniškem sistemu.
• Kreirati datoteko vnesenih obrazcev RIR
• Izpis vnesenih podatkov na osebni računalnik v obliki obrazca RIR.
• Prenos vnesenih podatkov iz osebnega računalnika na glavni računalniški sistem v taki obliki, ki bo primerna za batch obdelavo s pomočjo obstoječega JUTRANJEGA PROGRAMA.
• Vse rezultate obdelave JUTRANJEGA PROGRAMA delavci referata RIR dobijo prikazane na ekranskem terminalu in z možnostjo izpisa na tiskalniku.
• Tiskanje odločb o odpiranju, zapiranju ali spremembah na računih pravnih oseb na tiskalniku ob PC v referatu RIR.

Kratkoročna rešitev 'Sprotni vpogled v podatke datoteke REGISTER' je že izdelana kot CICS transakcija RALL. Omogoča vpogled tj. listanje podatkov datoteke REGISTER na različne načine. Ti različni načini so pogoji  - kriteriji za iskanje podatkov. Osnovni kriterij je ključ datoteke (račun - namen - partija). Po želji pa je lahko kriterij tudi naziv, kraj, naslov, dejavnost ali matična številka pravne osebe.

Dolgoročna rešitev pa je ustrezna CICS transakcija, ki ob vzporednem delu APS na PC in na zahtevo PC programa izvrši določene funkcije na glavnem računalniškem sistemu, rezultat sprejme in prestreže PC program, ki ga tudi ustrezno obdela.

In sedaj smo pri mitološkem stookem, vedno budnim čuvajem. Tudi APS, ki je v izdelavi, ima nalogo čuvanja in kontroliranja vseh vhodnih podatkov za register imetnikov računov. Prav zato smo ga imenovali ARGUS.

S pomočjo ARGUS-a bo v končni fazi bistveno skrajšal celoten postopek pri odpiranju novega računa pravne osebe v registru imetnikov računov in poenostavljeno popravljanje vseh tistih podatkov, ki nimajo neposrednega vpliva na dnevno obdelavo v plačilnem prometu.

Povečala se bo zanesljivost celotnega vzdrževanja registra imetnikov računov, saj bo odpadla vrsta dosedanjih postopkov, ki so možni viri napak.

Delavci referata RIR bodo tudi neposredni udeleženci v nekem konkretnem postopku in dogajanju ne le pri svojem dosedanjem delu temveč tudi pri delu, ki ga za njih in po njihovih navodilih opravlja računalniški sistem.

Ocenjuje se, da bo dosežen tudi določen prihranek pri materialnih stroških, predvsem pri papirju in porabljenem računalniškem času za tiskanje. Rezultat svojega dela bodo delavci referata RIR videli in spremljali na ekranskem zaslonu svojega osebnega računalnika. Vsekakor se bo končni rezultat pokazal kot časovni in materialni prihranek in ne nazadnje kot preskok v višjo kvaliteto celotnega opravljenega dela.

Identifikacija pravne osebe

Leta 1988 je v bivši SDKJ delovala skupina s ciljem vsestranske proučitve zamenjave še danes veljavne oznake za žiro račun - identifikacije pravne osebe. Narejen je bil osnutek predloga, ki razen v SDK ni bil predstavljen širši javnosti. Tudi predlog za spremembo označevanja žiro in drugih računov novega plačilnega prometa (Ljubljana, 22. 01. 1993) ne rešuje kaj dosti, še več, vnaša dodatno zmedo v že tako nedorečeno identifikacijo pravne osebe. Osnutek iz leta 1988 je služil kot osnova za predlog nove identifikacije pravne osebe. Vsekakor je treba opozoriti na dejstvo, da sprememba identifikacije ni le stvar same SDK, temveč posega v vsako podjetje z bolj ali manj radikalno, vsekakor pa s spremembo, ki ima finančne posledice tj. stroške pri poslovanju. To pa je tisto področje, ki ga nikakor ne gre zanemariti, mora dobiti najširšo podporo, omogočiti vsaki pravni osebi, predvsem časovno, spremembe v vseh segmentih njenega poslovanja in prilagoditev novemu stanju. In prav zanemarjanje tega področja kaže na premajhen posluh, morda celo na podcenjevanje obsega, količine in zahtevnosti takega posega, kakor je sprememba identifikacije pravne osebe.

Na Službi je, da skupaj z ostalimi vladnimi organi in drugimi institucijami izpelje ustrezno šifriranje občin. Ne gre pozabiti na že pričete razprave in razmišljanja o novi upravi in določanju novih občin. Tudi mednarodne inštitucije so že naslovile na R Slovenijo, Urad za UN/EDIFACT zahtevek za nekatere šifrante (luke, letališča itd). Če ima SDK voljo in interes, potem je sedaj pravi trenutek za celovito, radikalno in dolgoročno spremembo identifikacijske oznake pravnih oseb.

Namen in cilj

Vsaka pravna oseba (tj. uporabnik) ima pri Službi družbenega knjigovodstva odprt žiro in morebitne druge račune. Sedanji način označevanja tj. številčenja ima pomanjkljivosti, ki jih predlog skuša odpraviti. Osnovan je na predpostavki, da ima vsaka upravna enota tj. občina svojo organizacijsko enoto SDK. Pri tem tudi upošteva, da identifikacijska oznaka pravne osebe ne vsebuje internih predpisov SDK. To pa pomeni večjo prožnost uporabe tako za uporabnike kakor tudi za SDK.

Sedanje stanje

Danes različne pravne osebe npr. Zavod Republike Slovenije za statistiko, Republiška carinska uprava, Banka Slovenije in ne nazadnje tudi SDK za različne namene in uporabnike zbirajo, obdelujejo in prikazujejo podatke.

Na kratko lahko vse te podatke imenujemo osnovne enote opazovanja. Da se lahko izvrši osnovno opazovanje vseh in vsakega posebej, mora vsaka pravna oseba imeti določeno oznako - identifikacijo. Te oznake SDK vodi v svojem Registru imetnikov računov - RIR. Nekaj podobnega vodi tudi Zavod RS za statistiko, Banka Slovenije, Republiška carinska uprava itd. Že bežen pogled npr. na register v SDK in Zavodu RS za statistiko pokaže njuno neenotnost in nepovezljivost. Ta nepovezljivost seveda ne pomeni, da SDK in Zavod RS za statistiko ne moreta primerjati želenih in določenih podatkov, pomeni pa, da taka primerjava ni enostavna. Če nič drugega, mora tako prva kot druga organizacija v svojih podatkovnih zbirkah imeti zapisana oba podatka - identifikaciji za vsako pravno osebo.

Povrh vsega pa obe organizaciji zbirata in obdelujeta podatke, ki se prepletajo in kar je še huje, so celo enaki.

Namen tega pisanja ni v poenotenju enega ali drugega registra z namenom lažjega in predvsem boljšega delovanja obeh organizacij in s tem tudi ostalih pravnih oseb, temveč v iskanju rešitev za identifikacijo uporabnika v registru SDK.

Sedanja konstrukcija žiro in drugih računov pravnih oseb, ki jih vodi SDK, ima lahko do 18 numeričnih znakov. Teh 18 cifer je razdeljeno v 4 skupine na naslednji način:



1. skupina:  Organizacijska enota SDK

2. skupina:  Osnovni račun

3. skupina:  Namen ali občina

4. skupina:  Individualna partija

Informacije, ki jih vsebuje takšen zapis so:

1. Lokacija pravne osebe glede na pripadnost določeni organizacijski enoti SDK.
2. Oznaka osnovnega računa iz kontnega plana računov SDK. Iz tega kontnega plana se opravi klasifikacija pravne osebe na določene skupine računov tj. na osnovni žiro račun in posamezne vrste računov izločenih sredstev.
3. Podrobna delitev po namenu in vrsti sredstev v povezavi z osnovnim računom, ki je osnova za izločene račune. Pri določenih vplačilnih - proračunskih računih, se te oznake uporabljajo za označevanje občin.
4. Identifikacijska številka lastnika računa s kontrolno številko.

Čeprav taka konstrukcija žiro računa lahko vsebuje do 18 znakov, se v praksi vsi zelo redko ali pa skoraj nikoli ne uporabljajo.

Verjetno je največja slabost sedanjega numeričnega označevanja računov v tem, da ni možna avtomatska kontrola usmerjenja sredstev. Računalniško podprta kontrola obsega le individualno partijo pravne osebe tj. 7 cifer, kjer je zadnja kontrolna, izračunana po nestandardnem modulu 11.

Izračun kontrolne številke je izveden na naslednji način:

0  1  4  2  7  9  0
-------------------
1  2  3  4  5  6  7

Številka na poziciji 1 se ne kontrolira.
Številke na pozicijah od 2 do 6 so pod kontrolo in njihova izračunana kontrolna številka je na poziciji 7. Algoritem izračuna kontrolne številke je naslednji:

Številko na 2 poziciji množimo z 1 =  1
Številko na 3 poziciji množimo z 2 =  8
Številko na 4 poziciji množimo s 3 =  6
Številko na 5 poziciji množimo s 4 = 28
Številko na 6 poziciji množimo s 5 = 45
===========================
            Skupaj = 88
    88 / 11 = 8, ostanek 0, tj. kontrolna številka !

Slabosti sedanjega stanja

Vidimo, da računalniška kontrola obsega le del individualne partije vsake pravne osebe, vsa ostala kontrola, predvsem točnost usmerjanja sredstev glede na sedež, osnovni račun, namen ali občino pa je odvisna od ročne tj. vizualne kontrole delavcev, ki sodelujejo v celotnem postopku obdelave plačilnega prometa. In teh ni malo: predhodna kontrola na šalterjih, kjer pravna oseba odda dokumente, delavci pri zajemanju in prenosu podatkov z dokumentov na računalniške medije, kontrolorji pravilnosti vnosa podatkov, delavci pri sortiranju in razvrščanju dokumentov itd. Vsi ti pa so le ljudje, kar seveda ni nobeno zagotovilo, da ne bo prišlo do napak.

Tudi pri samem dodeljevanju individualnih partij v okviru osnovnih računov sistemska (računalniška) kontrola ne omogoča točnosti pri identifikaciji pravne osebe. Enake individualne partije se v okviru ene organizacijske enote SDK pojavijo večkrat na različnih osnovnih računih.

Primer:
    RAČUN   PARTIJA
    601     16      = gospodarstvo
    603     16      = negospodarstvo
    620     16      = poslovne banke
    675     16      = hišni sveti

Dovolj je napaka ene številke (603 namesto 601) in že so sredstva napačno usmerjena!

V takih pogojih se lahko upravičeno trdi, da je točnost obdelave nalogov plačilnega prometa rezultat subjektivnega dela, kar v množični obdelavi nalogov plačilnega prometa ni moglo ostati brez posledic pri usmerjanju sredstev pravnim osebam.

Sedanji način označevanja pa ima med drugim še naslednje pomanjkljivosti:

1. Vsebuje podatke, ki so po svoji prirodi vhodni in izhodni. Sprememba izhodnih podatkov SDK neposredno vpliva na spremembe vhodnih podatkov pravne osebe. Kot primer naj služijo spremembe organizacijske enote SDK, sprememba oznake osnovnega računa v kontnem planu računov SDK itd.
2. Ne omogoča povezave vseh sredstev iste pravne osebe s pomočjo enotne in enosmiselne identifikacijske oznake.
3. Omejuje širšo uporabo telekomunikacijskega prenosa podatkov.
4. Preprečuje splošno možnost posodabljanja plačilnega prometa.

Računalniška podpora sedanjega modela identifikacijske oznake pravne osebe v SDK je maksimalna v danih pogojih in razmerah. Kontrolo lahko razdelimo v

• formalno in
• vsebinsko.

Formalna kontrola obsega

• kontrolo vhodnih podatkov na numeričnost
• pravilnost vnešenih podatkov za
• oznako SDK
• osnovni račun
• in odvisno od osnovnega računa še kontrolo
• namena ali občine
• izračun kontrolne številke.

Vse te kontrole se izvedejo s primerjavo ustreznih šifrantov.

Vsebinska kontrola se izvede le takrat, ko so vsi podatki formalne kontrole pravilni. Zgradi se ključ v obliki račun-namen/občina-partija za pristop do ustrezne podatkovne zbirke. Če takšen račun obstaja, potem je vsaj kar se tiče avtomatske kontrole vse v najlepšem redu. Jasno je, da noben računalniški program ne more odkriti napačno vpisanega osnovnega računa 603 namesto 601, če pa sta oba pravilna in še več, tudi enaki individualni partiji za oba različna osnovna računa sta v podatkovnih zbirkah!


Takšna napaka se lahko običajno odkrije le v časovno zelo neugodnem trenutku, ko je celotna računalniška obdelava plačilnega prometa praktično že zaključena. Delavci, ki sortirajo in kompletirajo dokumentacijo (dokumente plačilnega prometa) z računalniško izdelanimi seznami obdelanih dokumentov imajo možnost, da odkrijejo take napake. Takoj pa se postavi vprašanje, če je smotrno popraviti odkrite napake in ponoviti celotno računalniško obdelavo ter tako zamuditi časovne termine za oddajo dokumentacije na pošto. Običajno se napake evidentira in odpravi kot reklamacija s strani SDK pri obdelavi naslednji dan.


Predlog novega označevanja


Nov način numeričnega označevanja identifikacije pravne osebe v SDK bi obsegal največ 11 znakov naslednje oblike in vsebine:

1. skupina:  Oznaka občine

2. skupina:  Individualna partija

 

3. skupina:  Vrsta sredstev

Novo označevanje pravnih oseb pomeni naslednje:

1. Prva skupina označuje občino, zadnja pa je kontrolna številka izračunana po standardnem modulu 11. Definicija modula 11 je taka, da približno 10% kombinacij ne pride v poštev. To pa tudi pomeni nov šifrant občin, ki bo nujno različen od sedanjega. Nesmiselno je na sedaj veljavne oznake občin dodajati kontrolne številke, ker bodo nekatere odpadle in jih je treba v vsakem primeru zamenjati. Druga možnost pa je izračun kontrolne številke po standardnem modulu 10, ki pa ne izloči nobene kombinacije, ima pa slabšo zagotovilo za odkrivanje napak pri različnih kombinacijah napačno vpisanih cifer. Obseg 999 ali 900 oznak za občine je dovolj velik za sedanje in vse bodoče potrebe države Slovenije.

2. Druga skupina s 5 številkami predstavlja identifikacijsko oznako pravne osebe oz. njenega računa v okviru ene občine. Zadnja 5 cifra je kontrolna številka izračunana po nekem standardnem načinu. Ta se lahko izračuna le iz te skupine npr. po modulu 11. Tudi če jih 10% odpade, to ni problematično, ker niso vezane na noben obstoječ šifrant.

Če pa se kontrolna številka izračuna tako, da poleg druge skupine znakov zajema še vse znake prve skupine, potem pa lahko pri izračunu po modulu 11 pride do situacije, ko nekatere oznake ne pridejo v poštev. To pa pomeni, da določene kombinacije iz prve skupine odpadejo zaradi vpliva cifer druge skupine. V tem primeru je smiselno uporabiti izračun kontrolne številke po modulu 10.

Obe skupini skupaj tvorita enoto in nedvoumno oznako za vsa sredstva iste pravne osebe.

Ker imajo določeni proračunski računi že sedaj predpisane enotne individualne partije v celi državi, lahko npr. v naprej rezerviramo številke do 9.999 za te namene. Vse kombinacije od 10.000 naprej pa so proste za uporabo v vsaki organizacijski enoti SDK.

3. Tretja skupina s 3 številkami, ki vključujejo tudi posebno kontrolno številko uporabljamo samo za vrsto sredstev ne pa za osnovni žiro račun. Pojem vrsta sredstev obsega dosedanji namen (skupna poraba, rezerva, sredstva za obračun itd). Če bi pravna oseba vsa svoja sredstva vodila le na osnovnem žiro računu (prva in druga skupina) potem tretje skupine sploh ne uporabljamo !

V Tabeli 1 je prikazana sedanja in predlagana oznaka za identifikacijo pravne osebe.

Neposredna zamenjava identifikacijske oznake pravne osebe vpliva na dve osnovni podatkovni zbirki SDK in sicer (1) register imetnikov računov in (2) matična datoteka. V prvi so zapisani vsi splošni podatki o vsaki pravni osebi, v drugi pa se evidentirajo in zbirajo vse finančne spremembe vsake pravne osebe. Iz teh dveh zbirk, ki sta vitalni za nemoteno opravljanje vseh nalog plačilnega prometa, pa se še dodatno izvedejo nekaj pomožnih podatkovnih zbirk. Nekatere se dnevno kreirajo za določeno vrsto obdelav, druge pa vsebujejo tedenske ali mesečne spremembe. Vse te izvedene zbirke niso problematične, so internega pomena in sprememba oznake za identifikacijo pravne osebe ne pomeni prevelikih težav pri novem oblikovanju njihove vsebine.

Cela stvar pa se zaplete pri registru in matični zbirki. Tukaj je treba poiskati in izpeljati tako reorganizacijo, da bodo vsi projekti in programi po možnosti delovali brez sprememb še naprej. Obdelave in programi so v SDK izdelani in se izdelujejo po načelu, da so vsi pristopi do podatkov neodvisni od aplikacijskih programov in programov za upravljanje z podatkovnimi zbirkami. Pristop do podatkov pomeni, da vsak programer uporabi standardno pristopno metodo in rutino, ki na dogovorjeni način opravi določeno nalogo: čitanje, pisanje, ažuriranje itd. zapisov v datoteki.

Torej je treba modificirati le standardne pristopne rutine in popraviti strukturo stavka, aplikacijske programe pa popraviti v tistih delih, kjer se formirajo ustrezni ključi kot vhodni podatek za pristopne rutine.

Verjetno so redke tiste pravne osebe, ki nimajo svoje poslovanje računalniško podprto. Nekatere aktivnosti pri pravnih osebah bodo verjetno naslednje:

1. Sprememba identifikacijske oznake v vseh evidencah, kjer se pojavlja.
2. Spremembe v računalniških programih.
3. Obvestiti vse poslovne partnerje o novi oznaki.
4. Tiskanje novih dokumentov (virmani, položnice, čeki, razni obrazci), če imajo predtiskane podatke.
5. Spremeniti vse pogodbe (npr. dolgoročno odplačevanje knjig), izpisati vse plačilne dokumente in jih poslati poslovnim partnerjem.

Prednosti novega označevanja


Opisani način označevanja pravnih oseb med drugim prinaša naslednje prednosti:

1. Daje informacijo o lokaciji lastnika žiro računa.
2. Omogoča enosmiselno in enotno identifikacijo vsake pravne osebe.
3. Omogoča sistemsko (računalniško) kontrolo vpisanih podatkov. To pa omogoča točno usmerjanje sredstev in pravilno knjiženje vsake spremembe.
4. Zmanjšuje obseg dela na ročni in vizualni kontroli vnešenih podatkov.
5. Ne vsebuje stalnih oznak, ki se nahajajo v ostalih evidencah, registrih ali šifrantih.
6. Omogoča racionalno obdelavo podatkov v plačilnem prometu ob možni spremembi vseh predpisov, ki formirajo npr. določeno skupino pravnih oseb.
7. Omogoča povezovanje vseh sredstev ene pravne osebe preko enotne identifikacije.
8. Zagotavlja vse pogoje za nemoteno opravljanje vseh nalog kontrole pravilnosti nalogov za plačevanje, njihovo evidenco in statistiko.
9. Ustvarja pogoje za avtomatsko spremljanje likvidnosti in pokritja računov pravne osebe.
10. Omogoča enotno računalniško kontrolo podatkov za identifikacijo pravne osebe, kar je pogoj za nemoten prenos podatkov s pomočjo telekomunikacijskih sredstev v vseh organizacijskih enotah SDK in kar je tudi osnovni pogoj za računalniško izmenjevanje podatkov in bodoči "elektronski denar". To pa pomeni tudi ukinitev ročnega sortiranja in kompletiranja dokumentacije za pravno osebo, saj bi vse podatke o spremembah na svojih računih dobil računalniško izpisane.
11. Omogoča, da vhodni podatki niso obremenjeni z internimi oznakami SDK.
12. Omogoča, da se kontni plan osnovnih računov zamenja brez sprememb pri identifikaciji pravne osebe.
13. Omogoča uvajanje novih vrst sredstev brez sprememb v trenutnem stanju.
14. Zmanjšuje količino znakov pri vnosu podatkov.

V Tabeli 2 je prikazan obseg poslov pri vnosu podatkov na računalniške medije.


Zaključek


Vse to in še marsikaj zahteva določen čas in ne nazadnje tudi sredstva. SDK mora vsak svoj predlog in spremembo pravočasno objaviti. Prav gotovo ni SDK sama sebi namenjena, zato morajo tudi pravne osebe videti svoje interese v opisani spremembi oznake za identifikacijo, ki so:

1. Manjši obseg dela pri pisanju identifikacijskih oznak na plačilnih dokumentih.
2. Možnost, da se identifikacija uporabi pri internem knjiženju za povezovanje poslovnih dogodkov.
3. Stabilnost oznake, ki bi se menjala le v spremembi občine.

Tabela 1: Primerjava stare in nove oznake

SSSSS - organizacijska enota SDK        
RRR - osnovni račun                    
NNN - namen ali občina                 
PPPPPPK - partija s kontrolno številko     
OOK - občina s kontrolno številko      
IIIIK - identifikacijska oznaka s kontrolno številko
VVK - vrsta sredstev s kontrolno številno                                           

Tabela 2: Število znakov na vnosu

Pri vnosu podatkov s plačilnega dokumenta je treba dodati še podatke o znesku, sklicevanju na številko itd.


Tabela 3: Število odpadlih računov po idejnem projektu

Vhodni podatki matične datoteke plačilnega prometa SDK podružnice Ljubljana z dne 5. aprila 1993. Oznaka sedeža 501 je bila zamenjana z 10 in dodana dosedanja oznaka za ekspozituro. Za prikaz računa 601 in njegovih izločenih sredstev je bil uporabljen standardni modul 11.


Opozoriti velja, da se število napak še poveča pri kombinacijah med posameznimi računi.

marec 1993

Brži rad s manje reklamacija

 

MOGUĆNOSTI ZA UNAPREĐENJE KLASIRANJA NALOGA PLATNOG PROMETA [1]

Koji su glavni nedostaci takozvanog AROPS načina klasiranja, a u čemu su prednosti sistema TEZAURUS

SDK je dužna da korisnike društvenih sredstava informiše o dnevnim promenama na njihovim računima i omogućava im uvid u stanje sredstava na ovim računima.

Danas SDK obavlja to informisanje na dva načina: o dnevnom stanju informiše korisnike izvodima, a o dnevnim promenama listom konsignacije i priloženim dokumentima.

Faza platnog prometa, koja u tom procesu iziskuje najviše vremena, je ručno klasiranje dokumenata jer današnji instrumenti plaćanja onemogućavaju mašinsko klasiranje dokumenata.

U razvoju računarske obrade platnog prometa, u periodu od poslednje tri godine, veliki broj ručnih obrada prenet je na računare, i time unapređena i obezbeđena tačnija obrada nekih delova platnog prometa. Međutim, ručno klasiranje dokumenata se zbog funkcija Službe i zbog raznovrsnosti dokumenata (kako po obliku tako i po načinu upisanih stavki) nije moglo izbeći. U vreme razvoja automatizacije bilo je više idejnih pokušaja da se ručno klasiranje ukine jer nema izgleda za automatizaciju ove funkcije u datom trenutku. Posle više analiza utvrđeno je da je za sada ručno klasiranje za večinu dokumenata neophodno, a na drugoj strani postoje mogućnosti i određena rešenja da se deo obrade klasiranja preda računaru.

Pristup problemu klasiranja zahtevao je promenu u organizaciji klasiranja u sledećim pravcima: u kvalitetu, brzini i standardizaciji. Analizom stanja utvrđeno je da se zbog spore obrade u klasiranju produžava prema obrtu sredstava, da se zbog lošeg kvaliteta izlaznog materiala povećava broj radnika na reklamacijama i da zbog netačno definisanog posla u Službi postoji toliko načina klasiranja koliko ima filijala. Cilj traženja novih načina klasiranja je u tome da se ova funkcija u SDK učini jednostavnijom i jedinstvenom ali sa mogućnošću više varijanti (centralizovano, decentralizovano itd.), tako da je rešenje prihvatljivo kako za najveće tako i za najmanje filijale.

Drugo čega se treba pridržavati je da se računar uključi u klasiranje i kontrolu, tako da klasiranje diktira način obrade računara, a ne obrnuto kao do sada. Rezultat klasiranja treba da se podudara sa rezultatom računske obrade (redosled sortiranih dokumenata isti je redosledu štampanja konsignacija).

Klasiranje mora da bude fleksibilno i što više nezavisno od računara i drugih službi. Time se omogućava veća propusna moć obrade klasiranja, dakle, veća brzina.

Potrebno je uvođenje individualne odgovornosti i mogućnosti ispravljanja grešaka koje se javljaju pri klasiranju i pri unošenju podataka u sistem (bušenje). Dakle, potrebno je da se uvede unakrsna kontrola dokumenata i da se eliminiše većina potencijalnih reklamacija.

KRITIČKI OSVRT NA AROPS NAČIN KLASIRANJA

Princip starog načina klasiranja bazira na hijerarhiji razvrstanja dokumenata (razgranata struktura). Kod ovakvog metoda (slika 1) svi dokumenti dolaze do ulazne tačke u proces klasiranja i razvrstavaju se grubo na oko 10 mesta (po klasama osnovnih računa, po sedištima, po poslovnicama). Svaka od ovih grana se dalje razvrstava opet grubo na oko 10 raznih grana. Postupak se nastavlja do konačnog razvrstavanja dokumenata u pregratke određenih korisnika. Postoji i razvrstan broj nivoa ovako razgranate strukture, što zavisi od konačnog broja mesta na koje treba razvrstati dokumente.

Broj nivoa za određenu vrstu korisnika jednak je broju premeštanja svakog dokumenta iz date vrste korisnika, koja su potrebna da dokumenat dođe do konačnog razvrstavanja. Na kraju su dokumenti sortirani u silaznom, odnosno uzlaznom redosledu s obzirom na ulazno razvrstavanje dokumenata i s obzirom na paran, odnosno neparan broj nivoa (premeštanja) potrebnih do konačnog razvrstavanja.

Za konačni redosled dokumenata koji mora da se poklapa sa redosledom odštampanih konsignacija, potrebno je da su dokumenti pre početka klasiranja pripremljeni u istom redosledu kao što je to određeno u računaru. U AROPS verziji moguća su dva načina sorta: (i) dokumenti su u okviru korisnikovog računa sortirani po rednom broju vrećice (papirne trake), (ii) po rednom broju određene vrećice koja je bez greške, (iii) za određene klase dokumenata za koje je potreban neparan broj premeštaja (nivoa u razgranatoj strukturi) potrebno je još jedno dodatno premeštanje, da se iz silaznog redosleda dobije ulazni redosled. Ovako sortirani material sada se može kontrolisati izlaznom listom konsignacija koje se štampanju na kraju obrade platnog prometa na računaru.

Za veću propusnu moć procesa klasiranja mogu da se uspostave dve ili više hijerarhija sortiranja (više razgranatih struktura). Međutim, u tom slučaju nastaje problem pri spajanju sortiranih dokumenata svih hijerarhija zbog konačnog redosleda dokumenata.

Problemi koji nastaju prilikom hijerarhijskog načina klasiranja izražavaju se u sledećim oblicima:

1. Prostorija

Za razvrstavanje dokumenata potrebna je srazmerno velika i jedinstvena prostorija, pošto se samo u ovakvoj prostoriji mogu nesmetano odvijati više ili manje sve operacije. Na sredini prostorije potreban je veliki sto gde se grubo razvrstavaju dokumenti. Uz zidove se nalaze pregradci u koje se ulažu konačno klasirani dokumenti. Za nesmetano kretanje radnika potreban je dovoljan prostor između stola i pregradaka.

2. Greške

U svim fazama klasičnog načina klasiranja nalozi se više puta pokreću u klasiranju, pa je moguć izvor nepreglednog broja grešaka. Pošto stalna kontrola nije moguća, gube sa pogrešno klasirani nalozi. Potreba za ovako izgubljenim nalozima pokazaju se prilikom konačnog usklađivanja sortiranih dokumenata sa odštampanim konsignacijama.

3. Ispravljanje nađenih grešaka

Pored toga što izvor za pogrešno usmeravanje (sravnjivanje) naloga ima veliki broj (svaki nivo u hijerarhijskoj strukturi je potencijalni izvor grešaka), u ovom načinu klasiranja mnogo je otežano ispravljanje pronađenih grešaka. Od trenutka kada se dokument uputi u pogrešan pravac (pogrešna grana hijerarhijske strukture) pa do trenutka kada ovaj dokument treba pronaći (vreme kontrole dokumenata konsignacijama) protekne obično mnogo vremena, pa je zato teže razmišljati o tome gde je dokument zalutao. Dokument tako treba tražiti u celokupnoj masi naloga dnevnog platnog prometa filijale, a što je kod večih filijala praktično nemoguće. Ukoliko se redosled štampanih konsignacija ne poklapa sa redosledom klasiranih naloga, više se ne može govoriti o traženju i spravljanju grešaka klasiranih naloga.

4. Grupna odgovornost za rezultate rada

U hijerarhijskom načinu klasiranja svaki nalog proputuje više nivoa sortiranja (od najgrubljeg sorta u klase računa do poslednjeg, finog sorta u pregratke korisnika). Jasno je da čitav put klasiranja određenog dokumenta ne može da prati jedan radnik, zato i svaki nalog putuje kroz mnogo ruku. U vreme procesa klasiranja naloga, položaj naloga je nedefinisan. Tačno su određene samo tačka ulaza naloga u proces klasiranja i tačka izlaza naloga u odgovarajući pregradak (ako je ovaj pravilan). U ovakvom procesu niko lično ne može biti odgovoran za rezultat određene grupe klasiranja dokumenata, pošto nije njegova krivica što određeni nalog uopšte nije dospeo do njegovog nivoa, jer je greškom već zalutao na pogrešan put.

5. Brzina klasiranja malo zavisi od broja ljudi

Brojem klasera ne može se istovremeno povećati brzina klasiranja pošto je u hijerarhijskoj strukturi usko grlo ulazna tačka dokumenata u proces klasiranja. Kroz ovu tačku moraju da pođu sva dokumenta. Na ovom mestu može da radi samo jedan radnik, jer bi se uporednim radom na tom radnom mestu poremetila sortna struktura ulaznih, a tako i izlaznih naloga.

Mogućno je uporedo uspostaviti čitavu hijerarhiju klasiranja što, međutim, izaziva zahteve za novim, još jedanput večim prostorom, što jako otežava usklađivanje rezultata obe hijerarhije klasiranja.

6. Neravnomerno opterećenje

U sistemu hijerarhijskog dokumenata obično je jedan radnik odgovoran u procesu za klasiranje unapred određenih klasa naloga. Od broja naloga u određenoj klasi zavisi koliko tačaka klasiranja dokumenata obrađuje jedan radnik. Međutim, nalozi pritiču više ili manje ravnomerno samo do ulazne tačke klasiranja, odnosno u sledećem nivou do onih grana koje imaju procentualno najviše naloga. Što je niži nivo klasiranja (finije sortiranje), u toliko se više vremenski menja priliv naloga. Adekvatno ovome, radnici u različitim vremenskim periodima različito su zaposleni. Vreme, koje je obavezna posledica neravnomernog priliva materiala, ne može se nadoknaditi preteranim opterećenjem radnika u vreme velikog priliva materijala.

7. Loše definisan rad

Radnik nema celoviti pregled nad procesom rada, već uvek učestvuju samo u malom deliću celokupnog procesa, što se može skoro poistovetiti sa ubitačnom tekućom trakom u industriji. Pored toga što rad u toj strukturi nije tako dobro definisan kao što je, na primer, na tekućoj traci, radnik takođe ne vidi rezultate svog rada, pa zato lično nije zainteresovan za postizanje što boljeg rezultata svog rada.

8. Naporan i jednoličan posao

U hijerarhijskom sortiranju naloga postoji više nivoa razvrstavanja, što obavezno ima za posledicu prenošenje naloga. U konačnom, finom razvrstavanju svakog naloga posebno po pregradcima korisnika, ovo ulaganje naloga je i fizički naporno, jer treba izdržati vreme celokupne radne smene. Ako je pri tome posao stalno isti, jasno je da klaser radi u teškim uslovima rada.

9. Zavisnost klasiranja od računara

Redosled konačnih konsignacija, koje sa dokumentima idu korisnicima, utvrđen je u AROPS aplikaciji sortnim pojmom u programu koji štampa konsignacije. U AROPS verziji postoje dve mogućnosti: soritiranje naloga jednog korisnika po broju ulazne papirne trake (vrećice) ili, pak, po rednom broju čistoti papirne trake (papirna traka – vrećica – koju sistemska kontrola unapred očisti, dobije redni broj 1, a druga očišćena vrećica redni broj 2 itd.).

Pre početka sortiranja u obe verzije treba pripremiti redosled vrećica po kojem se štampaju konačne konsignacije. Tako celokupni sistem klasiranja zavisi od toka obrade na sistemu umesto da proces klasiranja utiče na rezultat računarski ispisanih konsignacija.

10. Faza kontrole klasiranih naloga na kraju procesa

Do trenutka štampanja konsignacija nema mogućnosti za kontrolu pravilnosti klasiranja naloga po pregradcima. To je prilično kasno što ima za posledicu nesavesnu kontrolu ili, pak, osetno produžavanje kraja obrade platnog prometa. U fazi kontrole obično se nađe i priličan broj grešaka koje nisu posledice pogrešno klasiranih dokumenata, već su posledica loše sistemske kontrole ili pogrešnog bušenja (pogrešno usmeravanje istih partija sa različitih računa 701-602-620 itd.). Greške ove vrste više se ne mogu ispraviti pošto je u vreme kontrole sortiranih dokumenata računarska obrada platnog prometa već završena (obrađeni izvodi, ažurirane datoteke o finansijskom stanju korisnika itd.).

11. Poslata zbirna aviza

S obzirom na štampane konsignacije kod lošeg klasiranja materijala organizaciono je izuzetno teško izvršiti razbijanje naloga na pakete koji idu u druga obračunska sedišta na manje paketa (do 500 naloga na jedan zbirni avizo).

Posledice problema nabrojanih od 1 do 11 su sledeće:

• priličan broj procesa loše dokumentovanih naloga na privremenom računu;
• veliki broj reklamacija koje su posledica pogrešno uloženih, usmerenih i izgubljenih naloga (pošto nema unakrsne kontrole dobiju se pogrešna usmeravanja istih partija na raznim računima 701-603-620 itd.), kao i neknjiženih naloga;
• obrtanje sredstava je dugotrajno pošto se klasiranje razvuče na više od dve smene; zbirna aviza se kod većih filijala ne mohu dostaviti istog dana;
• deo materijala ostaje neobrađen za naredni dan kada klaseri još nemaju tekući priliv dokumenata do prvih čistih traka;
• obično loše uređen materijal, s obzirom na konsignacije, predstavlja posebno osetljiv problem kod korisnika sa velikim brojem naloga dnevno (banke itd.).

PREIMUĆSTVA TEZAURUS NAČINA KLASIRANJA

Godine 1975. počeli smo u SDK Filijala Ljubljana intenzivnije da rešavamo probleme klasiranja naloga, pošto se sa hijerarhijskim načinom klasiranja kod filijala sa velikim brojem dokumenata zbog navedenih nadostataka pokazalo da porastom broja naloga automatizacija platnog prometa vodi slabijem umesto boljim rezultatima. Problemi su se gomilali, a osnovni nedostaci se nisu mogli otkloniti manjim ispravkama starog načina klasiranja. Rešenje za klasiranje traženo je u boljem kvalitetu i povećanoj propusnoj moći grupe za klasiranje.

Osnovna ideja novog pristupa bila je, da sortiranjem manjeg broja dokumenata, dobijemo manje problema, pošto za vreme sortiranja raste mogućnost nastajanja grešaka srazmerno sa kvadratom broja dokumenata i kvadratom broja konačnih tačaka klasiranja (broj korisnika). Prema tome, ako se sortiranje čitave mase dokumenata razbije na sortiranje više pojedinačnih delova, mogućnost nastajanja grešaka se odgovarajuće smanjuje. Tako je sortirano više delova ukupnog prometa sa mogućnošću nastajanja grešaka koje je toliko puta manja koliko ima delova sortiranog materijala u celini.

Kod faze mešanja (spajanja) svih sortiranih delova u konačno sortiranu masu svih dokumenata (merge faza) nalazi se značajna karakteristika platnog prometa u SDK koja olakšava konačno mešanje dokumenata; ovo je činjenica da je u SDK broj korisnika, koji nose najveći deo dokumenata dnevnog platnog prometa, prilično mali.

Prema tome, u fazi mešanja (merge faza) ne prenosi se individualno svaki dokumenat posebno, već manji broj paketa (za jednog korisnika), što može ovu fazu bitno da pojednostavi.

Prema tome, prvi zaključak je razbijanje sorta celokupne mase dokumenata na sortiranje dokumenata po delovima i mešanje (merge) delova u konačno sortirani materijal.

Prednost ovakvog rešenja je u smanjenju potencijalnih grešaka na jednoj strani i istovremeno zapošljavanje više radnika na drugoj strani (jedan deo – jedan radnik); dakle, povećanje propusne moći grupe za klasiranje.

Rešenje smo tražili i u kvalitetu izlaznog materijala, dakle, u kontroli rada. Ova kontrola treba da bude tekuća i vremenski ne sme biti pomerena na kraj procesa rada. Unakrsnom kontrolom (unakrsna s obzirom na sistemsku kontrolu) omogućili bi vršenje ispravki u sistemu pogrešno knjižnog dokumenta (pogrešno usmeravanje sa računa 601 na 603, iz sedišta 1 na sedište 2 itd.). S obzirom da smo sortiranje razbili na više delova, mogućnost da se nađe pogrešno klasirani dokument kod uzastopne kontrole je mnogo veća, čak i zagarantovana. Međutim, za ovu fazu rada treba da razpolažemo sa programskima rešenjama koji imajo mogućnost pristupa do podataka u takvom obliku kao što to traži radnik na klasiranju.

Tako je problem sortiranja idejno rešen. Sortiraju se mali delovi i uz put se kontroliše rezultat rada. Time se olakšava traženje pogrešno klasiranih naloga i omogućava vršenje ispravki pogrešno upisanih dokumenata u sistemu pre završetka obrade.

Međutim, ostaje problem mešanja svih sortiranih delova u konačno sortirani promet (merge faza). Za ovu fazu treba uzeti u obzir okolnost koja olakšava vršenje sortiranja u SDK, i to da samo 3-5 % korisnika ima 70 % svih naloga dnevnog platnog prometa. Prema tome, pre faze mešanja treba pripremiti dokumente, koje se odnose na jednog korisnika, u vidu paketa (koverta, paketa i sl.). Ovakvim načinom, u fazi mešanja, učestvuje bitno manji broj jedinica od ukupnog broja svih dokumenata. Pošto su dokumenti u ovim jedinicama već prekontrolisani (i ispravljeni ako je to bilo potrebno), posle izvršene faze mešanja preostaje još samo kontrola postojanja svih jedinica (paketa) ili tzv. faza kontrole - rekapitulacija.

Mešanje rezultata delimičnih sortova je na taj način pojednostavljeno pripremom paketa dokumenata koji pripadaju jednom korisniku već u fazi delimičnog sorta. Kontrola mešanja omogučena je rekapitulacijama paketa koje ispisuje računar. Posao u konačnoj fazi mešanja na taj način je lakši zato što su svi paketi istog oblika, a oznake korisnika jasno ispisane na vidljivom mestu pomoću računara.

Ovako modulirani pristup omogućava centralizovanu i decentralizovanu organizaciju klasiranja. Odgovornost za pravilno sortiran materijal ostaje na mestu delimičnog sorta. Samo poslednja faza mešanja nalazi se u odgovornosti centralnog ulaganja. Brojem radnika srazmerno se povećava propusna moć (brzina klasiranja). Prema tome, filijala sa velikim brojem naloga i, takođe, sa velikim problemima, idejno se razbije na veći broj manjih jedinica koje snose celokupnu odgovornost za svoj rad. Glavna kontrola uključuje se u fazu klasiranja i time se ravnomerno raspoređuje u vremenu do kraja obrade na sistemu, čime se najosetljiviji deo klasiranja pomera u povoljnije vreme dnevne obrade.

Osnovni element platnog prometa je nalog. U automatskoj obradi nalozi se grupišu u vrećice. Svaka vrećica dobija svoj broj kojim je označena u sistemu (broj vrećice je jednak broju papirne trake). Novim načinom klasiranja dobija se još jedan nov pojam koji se odnosi na deo naloga, a koji se posebno sortiraju.

Ova nova jedinica naziva se kutija. Sve kutije (delimični sortovi) mešaju se u tzv. velike kutije.

Prema tome, celokupan dnevni promet filijale sastavljen je od kutija. Svaka kutija sadrži više vrećica (traka) u kojima su grupisane logičke celine, koje se sastoje od osnovnih elemenata platnog prometa – naloga.

Istu sliku platnog prometa treba da imamo u računaru. Radi toga je potrebno da imamo bazu podataka koja se može na isti način logično adresirati. Uz ovako modulirano strukturiranu bazu podataka bilo kojoj grupi radnika u dnevnom platnom prometu mogu se predavati podaci u formi koja grupi najviše odgovara.

Nalozi dolaze u odeljenje za klasiranje u vrećicama označenim brojevima (br. papirne trake). Ovi nalozi mogu da dolaze od sistemske kontrole (prema tome već očišćene trake), ili pak od grupe za pripremu logičkih celina i vrečica koja je određenu klasu naloga (npr. virmani) već razdvojila na odobrenja i zaduženja. Vrećica sa nalozima za odobrenje ide u grupu za klasiranje, a vrećica sa nalozima za zaduženja u grupu za unošenje podataka u sistem (bušenje) i grupu za sistemsku kontrolu. Kod ovih naloga značajno je da su obe vrećice označene istim brojem, kao i da su nalozi u obe vrećice sortirani po istom redosledu.

Radnik u grupi za klasiranje uzima dokumenta iz vrećice i izvršava konačno sortiranje; izvršava klasiranje svih dokumenta po oznaci korisnika i to za naloge koji idu u strana sedišta, a za domaće naloge po osnovnom računu, u okviru računa po opštinama ili nameni, u okviru toga po partiji. U vrećicama se nalazi oko 300 do 500 dokumenata obično za oko 100 do 150 različitih korisnika. Radnik izvrši konačno klasiranje više vrećica i kao rezultat svoga rada dobije na stolu dokumenta koji su u okviru jedne vrećice presortirana po sedištima (za dokumenta stranih sedišta) i po računu, nameni ili opštini i partiji (za dokumenta domaćih korisnika).

Šef grupa za klasiranje zahteva od računara ili sistemske kontrole u određenim vremenskim intervalima spisak vrećica (traka) koje je sistemska kontrola već očistila (O=KL funkcija kontrolnog programa ili lista očišćenih traka na kraju izvršenih ispravki). Na drugoj strani šef grupe za klasiranje upisuje u svoj dnevnik brojeve svih vrećica (traka) čiju su dokumenta radnici već sortirali. Na osnovu ove dve informacije: broja čistih traka i broja klasiranih traka, šef grupe određuje klaserane koje klasiranje vrećice treba da sačinjavaju jednu kutiju. Kombinacija vrećica koje pripadaju jednoj kutiji upisuje se u takozvani dnevnik klasiranja. Dnevnik klasiranja predstavlja štampani formular, a potreban je da se iz njega vade podaci o redosledu vrećica u određenoj kutiji koje se unose u sistem. Kada su podaci iz dnevnka klasiranja upisani u sistem, radnik u grupi za klasiranje može da zahteva izvod kontrolnih konsignacija za određenu kutiju (broj dnevnika). Kontrolne konsignacije (ili delimične konsignacije) namenjene su kontroli sortiranih dokumenta. Istovremeno služe i kao saopštenje korisniku društvenih sredstava o izvršenim transakcijama, dakle, one zamenjuje stare konačne konsignacije u AROPS načinu klasiranja.

Kontrola konsignacija sadrži podatke korisnika kome je namenjena (oznaka računa), podatke o broju kutija za koju je pisana i o rednom broju strane u okviru kutije. Ovi podaci kasnije služe za kontrolu faze mešanja pomoću rekapitulacije. U svakom detaljnom redu kontrolne konsignacije nalaze se podaci o protivstavci naloga za račun korisnika, kao i podaci koji su važni prilikom reševanja reklamacija (arhiva): redni broj naloga u prometnoj datoteci, broj logičke celine i broj vrećice u kojoj je bio dokumenat.

Ovakvim načinom sastavljanja kutija iz već očiišćenih traka izbegnu se problemi koji nastupe ako se već unapred kreira dnevnik klasiranja kutija. Često puta se događa da su skoro sve vrećice u okviru jedne kutije čiste, a kontrola ovakve kutije se odugovlači samo zbog jedne nečiste vrećice dokumenata.

Kontrolne konsignacije u Ljubljani se štampaju na koverte. Na jednoj koverti ispisano je do 18 stavki, dakle, ovakav koverat može da sadrži do 18 naloga. Pošto su stavke na kontrolnim konsignacijama pisane u istom redosledu po kojem su nalozi sortirani u okviru vrećica, kontrola dokumenata je jednostavna. Istovremeno sa kontrolom odvija se i ulaganje naloga u kovertu kontrolne konsignacije. Klaser ima pred sobom na stolu više vrećica sortiranih dokumenata, a informacija o broju traka, koja je ispisana na kontrolnoj konsignaciji, predstavlja za klasere podatak na kojoj gomili se nalazi odgovarajući nalog. Svim ovim podacima radnik na klasiranju jednostavno kontroliše pravilnost sortiranja naloga na jednoj strani, a na drugoj strani pravilnost upisa naloga u sistemu. Prema tome, omogućena je unakrsna kontrola naloga i time bitno smanjena mogućnost za pogrešno usmeravanje naloga. Dokumentaciju za bilo koji nalog, za koji je bilo utvrđeno pogrešno mesto u sortnom redosledu, ili, pak, pogrešan upis u sistem, klaser nalazi u okviru svog materijala. Zato je on potpuno odgovoran za ispravku greške. Kod pogrešnog upisa u sistem radnik uočava grešku sistema, a kod pogrešno uloženog naloga ispravi sortni redosled.

Posle završene kontrole dokumenata (time i posle završenog ulaganja dokumenata u koverte) jedne kutije potrebno je ulaganje u velike kutije. U velike kutije se ulažu kontrolne konsignacije sa dokumentima po istom redosledu kao i u male kutije. U okviru jednog korisnika ulažu se kontrolne konsignacije po rednom broju kutije, čime se olakšava kasnije kontrola pomoću rekapitulacija. Na kraju radnog dana dobije se celokupna dokumentacija platnog prometa sortirana po oznakama korisnika u velikim kutijama.

Postupak mešanja kontrolnih konsignacija iz kutija u velike kutije jednostavniji je i brži od prvobitnog sortiranja dokumenata. Mešanje u velike kutije ide po istom uzlaznom redosledu po kome su dokumenti već složeni u kutiju. Material za mešanje nije više dokumenat sa svim mogućim oblicima i rukopisima (što otežava klasiranje), već koverat koji ima na prikladnom mestu računski ispisanu oznaku korisnika (sortni pojam). Ova se operacija obično vrši u kutijama koje imaju oblik prilagođen veličini koverta. Na kraju ulaganja svih kutija (ili posle preseka obrade) u velikim kutijama računar odštampa rekapitulcije i zbirna aviza. Rekapitulacije predstavljaju izvod svih kontrolnih konsignacija i uz njihovu pomoč može da se prekontroliše kompletnost materiala u velikim kutijama. Podaci u rekapitulacijama sadrže, pored oznaka računa korisnika, i sve brojeve kutija u kojima je nastupio dokument za korisnika, kao i ukupne iznose svih dokumenata koji se nalaze u kutijama. Ukupan iznos svih kutija predstavlja dnevni kumulativni promet korisnika. Na nalozima koji idu u strano sedište, pored rekapitualacije ispisuje se i zbirni avizo koji predstavlja samo dokument o zajedničkom iznosu upućenom na određeno obračunsko sedište. Ovim podacima dokumenti su već pripremljeni za ekspediciju u strano sedište. Kod naloga za domaće korisnike treba dodati još samo izvode koji kod naloga za strana sedišta zamenjuju već ispisane zbirne avize.

Treba spomenuti i mogućnost razbijanja prevelikih zbirnih aviza na oko 500 naloga. Program koji štampa rekapitulacije i zbirni avizo, automatski izradi rekapitulaciju i zbirni avizo tako što objedini toliko kontrolnih konsignacija da je broj njihovih dokumenata približno jednak 500. Preostale kontrolne konsignacije objedinjuje u narednom zbirnom avizu.

Tako je faza klasiranja završena. Ukoliko dolazi do prekomernog broja naloga u toku dana, TEZAURUS programski paket ima još mogućnost prekida obrade pred kraj čišćenja materijala sa ciljem da i u slučaju ovakvog dana filijala uputi veći deo naloga za strana sedišta još istog dana.

Rezultati novog rešenja klasiranja naloga platnog prometa u SDK Ljubljana bili su očigledni. Svi glavni nedostaci AROPS hijerarhijskog načina klasiranja su otklonjeni.

1. Prostorije

U TEZAURUS načinu klasiranja ne postoji više potreba za velikom centralnom prostorijom, pošto je hijerarhijska funkcija sorta sada sužena na broj dokumenata jedne vrećice, između 300 i 500 naloga, što prostorno iziskuje samo jedan sto. Radnici deluju nezavisno jedan od drugog i tako mogu biti raspoređeni u više manjih prostorija. Zato je moguća i decentralizacija procesa klasiranja po poslovnicama i ekspoziturama, što je još od posebnog značaja kod filijjale sa velikim brojem naloga.

2. Greške

Mogućnost za pogrešno klasiranje naloga još uvek postoji, ali je ova mogućnost smanjena, jer je kod manjeg broja naloga potreba za prevrtanjem dokumenata manja. Bitna prednost sistema je u tome da je moguća stalna usputna kontrola obrađenog materijala već na manjim količinama dokumenata pomoću kontrolnih konsignacija. Kontrolu nad celokupnim delimičnim svrstavanjem (sortiranjem) imamo na jednom stolu, a nalaženje pogrešno unetih naloga je kod ovako male grupe izrazito pojednostavljeno i sigurno jer se svi nalozi nalaze na istom mestu.

3. Ispravljanje nađenih grešaka

Ispravljanje grešaka sada se može obavljati direktno u računar pošto radnici izvrše kontrolu sortiranih dokumenata pred kraj čišćenja prometne datoteke. Time se izbegavaju brojne, inače, obavezne reklamacije.

4. Odgovornost za rezultat rada

Prema TEZAURUS načinu klasiranja ODGOVORNOST JE TAČNO ODREĐENA. Za delimične sorte u kutijama odgovorni su pojedini radnici - klaseri koji mogu da potvrde svoj posao (kontrolne konsignacije) potpisom ili žigom. Konačno ulaganje dokumenata zajedno sa kontrolnim konsignacijama u velike kutije preuzimaju odgovornost radnici koji kontrolišu kompletnost materijala u velikim kutijama. I ovi radnici svoj posao mogu da potvrde potpisom ili žigom. Pored toga, može da se vodi tačna evidenca koja dokumenta (vrećice) je određeni radnik klasirao i povratnom petljom, preko reklamacija, uspešnost rada radnika može da se traži u klasiranju. I zainteresovanost za rad sa povećava, jer radnik prati čitav proces rada od početka do kraja. Greške, otklonjene u prethodnoj fazi, radnika ne sputavaju u narednoj fazi kontrole. Pošto svi radnici deluju nezavisno, u rasporedu svog radnog vremena su slobodniji.

5. Ravnomernije opterećenje radnika

Ovakvo opterećenje je uslovljeno nezavisnošću rada. Svaki radnik ima, u vreme svoje izmene, više faza rada koje može sam da raspoređuje (klasiranje, kontrolisanje, ulaganje). Jedini uslov za ravnomerno raspoređivanje posla između radnika je ravnomerno priticanje materijala do grupe za klasiranje, a što zavisi od organizacije rada u fazama rada predklasiranja.

6. Brzina

Klasiranja čitavog materijala je srazmerna broju radnika koji su uključeni u proces. Svaki radnik obavi konačno klasiranje dokumenata u jednoj vrećici. Nezavisno deluje od ostalih radnika i zaposlen je sve dok ima vrećica u redu čekanja. Kad završi fazu klasiranja, nastavlja sa kontrolom i ulaganjem dokumenata. I ove operacije takođe obavlja nezavisno.

7. Faze rada

Faze rada pojedinog radnika tačno su utvrđene. Pošto odgovara za tačnost svoga rada, što potvrđuje žigom ili potpisom, lično je zainteresovan za tačnost izvršenja svake faze rada. Učinjenom greškom u bilo kojoj fazi rada radniku se pojavljuje problem u narednoj fazi (povratna petlja). Radnik vidi i može da popravlja uspešnost svog rada ako on obavlja obradu čitavog procesa klasiranja svih dokumenata za svoju kutiju.

8. Rad klasera u TEZAURUS

Ovaj rad u TEZAURUS načinu klasiranje obrade dokumenata u odnosu na hijerarhijski način lakši je i raznolikiji. Sve faze rada klaser može da izvrši sedeći za stolom. Prenos dokumenata sveden je na prenošenje konačno sortiranih kutija do mesta ulaganja u velike kutije. U toku svog radnog vremena obavi više raznih faza rada koje posao klasera, bar u odnosu na stari način, čine interesantnijim.

9. Zavisnost računar – klaser

TEZAURUS načinom klasiranja ova zavisnost je obrnutog pravca. Po novom načinu računar zavisi od toga kako se obrađuju dokumenti u grupi za klasiranje, a ne obrnuto. S obzirom na podatke koje dobije od klasera (dnevnik klasiranja) računar štampa konsignacije rekapitulacije i zbirna aviza po odgovarajućem redosledu. Time je grupa za klasiranje dobila mogućnost paralelnog rada sa sistemskom kontrolom i odeljenjem za upisivanje naloga u sistem (bušenje). Ovo omogućava brže kompletiranje materiala, što postaje od posebnog značaja u kritičnom periodu obrade u popodnevnim časovima.

10. Kontrolna faza klasiranih naloga

Ova faza obavlja se još u vreme rada (aktivnog) kontrolnog programa. Time je data mogućnost da se greške, koje su posledica pogrešno usmerenog dokumenta prilikom upisivanje naloga u sistem (pogrešno bušenje, prenos 701-603 – itd.), istovremeno isprave preko normalnih ispravki sistemske kontrole. S obzirom da se kontroliše relativno mala količina naloga, pronalaženje pogrešno klasiranih naloga je mnogo jednostavnije. Raspoređivanje faze kontrole u toku celog dana ima prednost i u bržem kompletiranju materijala i u sigurnijoj konačnoj obradi.

11. Dostavljanje zbirnih aviza

Dostavljanje se može razbiti na grupe dokumenata sa oko 500 naloga, što pojednostavljuje upisivanje i kontrolu podataka filijali koja ove naloge pirma. Razvijanje u ovakve grupe je organizaciono sada jednostavno pošto u određenom zbirnom avizu učestvuju dokumenti kutija koje zajedno sadrže oko 500 naloga. Kutije, koje učestvuju u jednom zbirnom avizu, ispisane su na listi rekapitulacija za dato sedište.

Rezultati poboljšanja rada iskazuju se u:

• smanjenju broja reklamacija kako zbog pogrešno klasiranih naloga, tako i zbog pogrešno usmerenih naloga;
• ubrzanju obrta sredstava; zbirna aviza se mogu dostavljati isti dan i u vreme velikih opterećenja platnog prometa;
• konsignacije, koje prate naloge, štampane su po istom redosledu po kojem su nalozi uloženi;
• ukidanju treće (noće) smene i kod filijala sa največim brojem naloga.

---

[1]  Brošura – publikacija, SDK Jugoslavije u Beogradu, 1976.