Organizacija in naloge SDK

Kratka osvežitev, kako je bila Služba družbenega knjigovodstva organizirana in kaj je opravljala:

Podružnica je imela naslednje sektorje, oddelke, referate ali službe:

Kontrola

Interna kontrola je delovala na šalterjih v podružnicah, ekspoziturah in poslovalnicah ter sprejemala dokumente od uporabnikov družbenih sredstev. Najbolj znani in množično uporabljeni dokumenti v plačilnem prometu so bili

• virman,
• položnica,
• ček in še niz drugih.

Eksterna kontrola imenovana tudi inšpekcija, pa je kontrolira pravilnost in zakonitost poslovanja pri samih uporabnikih družbenih sredstev.

Statistika in analize 

 

Naloga oddelka za statistiko pa je bila kontrola vseh podatkov, ki so jih morali izdelati uporabniki družbenih sredstev (npr. letna poročila, bilance stanja, situacijski zapisniki investicij, …)

Naloga oddelka za analize je bilo analiziranje vseh podatkov, ki so bili izkazani kot številčne vrednosti, jih tolmačiti, opisovati in narediti ustrezne zaključke. Kot vhodne podatke so uporabljali vsa poročila izdelana iz podatkov plačilnega prometa kot agregat mesečnih, trimesečnih, polletnih, letnih ali občasnih poročil.

Oba oddelka sta sprejema tudi zahtevke posameznih delovnih organizacij, DPS (družbeno političnih skupnosti), občin, vlade, komitejev, ministrstev, … za izdelavo posebnih tabel, poročil in razlag raznih podatkov s katerimi je razpolagala in upravljala SDK. Tovrstne zahtevke so izvrševale posamezne podružnice za svoje področje, za republiški nivo je poskrbela centrala, za državni nivo pa SDKJ. Na njihove zahteve in specifikacije so delavci v računalniških centrih izdelali ustrezne programe in izpise.

Plačilni promet 

 

Najobsežnejše in tudi najpomembnejše je vsekakor bilo izvajanje enotnega plačilnega prometa na območju celotne Jugoslavije, ki so ga opravljale vse podružnice SDK vključno z ekspoziturami in poslovalnicami. Republiški in pokrajinski centrali ter glavna centrala SDKJ v Beogradu niso fizično opravljale plačilnega prometa.

Samo izvajanje plačilnega prometa je vsakodnevno obsegalo

• šaltersko poslovanje, to je sprejem dokumentov od uporabnikov družbenih sredstev,
• likvidaturo, blagajno, trezor,
• vnos podatkov v obliko primerno za računalniško obdelavo,
• računalniško kontrolo podatkov,
• popravljanje napačnih vnosov,
• izdelavo dnevne bilance stanja,
• obdelava podatkov z ustreznimi izpisi,
• kompletiranje dokumentov za posameznega uporabnika,
• pošiljanje rezultatov plačilnega prometa uporabnikom in drugim podružnicam,
• v samem računalniškem sistemu priprava vseh splošnih podatkov (odpiranje novih uporabnikov, popravljanje obstoječih itd.) za obdelavo naslednji dan,
• izdelavo izpisov, arhiva, poročil (razčlenjeni promet, ST-3 gotovinski tok, B-2 proračun, investicije),
• ažuriranje podatkov, ki so potrebni za uspešno delo v proračunu, analizah, statistiki in vseh zainteresiranih izven SDK.

V oddelku DR (Družbeno Računovodstvo) je bilo organizirano tudi »žarišče«, kjer so bili evidentirani vsi poslani in sprejeti dokumenti. To je omogočalo ugotavljanje in odpravo napako med vsemi SDK podružnicami.

Obdelavo in »pot« posameznega dokumenta v plačilnem prometu je prikazana na spodnji sliki in tudi rezultat njegove obdelave:

Šaltersko poslovanje

Komunikacija s strankami je obsegala

• sprejem dokumentov plačilnega prometa negotovinskega poslovanja (npr. virmanski nalog),
• vizualna kontrola vpisanih podatkov na dokumentih,
• likvidiranje dokumentov gotovinskega poslovanja (npr. ček, položnica),
• izplačila ali vplačila gotovine za pravne in fizične osebe.

V ozadju, skrito očem, je bilo še trezorsko poslovanje

• števnica papirnatega in kovanega denarja,
• priprava gotovine za dvig ob plačilnih dnevih – predvsem za velike komitente,
• priprava za razvoz gotovine (dotacije in viški blagajniških maksimumov) za potrebe ekspozitur in poslovalnic,
• sprejem gotovine od Narodne banke Slovenije,
• izločanje poškodovanih bankovcev.

Vnos podatkov 

Dokumenti plačilnega prometa so po vizualni kontroli na šalterju imeli naslednje skupne in obvezne značilnosti:

• vsak posamezni dokument (samček) je imel pripeto konsignacijo,
• več dokumentov, ki jih je predložil isti uporabnik in so bili v breme istega žiro računa, v dobro pa različnim uporabnikom, so imeli tudi pripeto konsignacijo. Konsignacija je bila na navadnem seštevalnem stroju izdelan papirni trak s posameznimi zneski in na koncu njihova zbirna vsota.

Sam vnos podatkov na posebni napravi Datica  je bil različen glede na kontrolni program. Prvi kontrolni program AROPS, izdelan v SDKJ Beograd, je imel niz pomanjkljivosti, ki jih lahko opišemo kot

zamudno in nepotrebno rokovanje s papirnatimi trakovi, saj se je luknjani papirni trak navijal tako, da je bil začetek znotraj zvitka in seveda konec na zunanji strani,

• počasno izvajanje,
• označevanje vhodnih dokumentov le z zaporedno številko,
• končna dnevna izdelava in tiskanje seznama dokumentov za posameznega uporabnika v vrstnem redu, ki nikakor ni ustrezal vrstnemu redu ročno sortiranih dokumentov.

Vnos podatkov – verzija AROPS

Delavke na vnosu so dobile na delovni prostor kup dokumentov in podatke na njih so vpisale takole:

• v primeru »samčka« (en sam dokument) žiro račun v breme, znesek s konsignacije v breme, minus tipka, žiro račun v dobro, znesek z dokumenta v dobro, plus tipka in tipka zvezdica, da se je izpisal zbirni znesek. Če sta bila zneska pravilno vpisana, potem je bil zbirni znesek enak nič.
• vnos podatkov za več dokumentov združenih v konsignaciji, pa je potekal takole: s prvega dokumenta žiro račun v breme, skupni znesek vseh dokumentov s konsignacije v breme, minus tipka, žiro račun v dobro, znesek v dobro, plus tipka, z drugega dokumenta žiro račun v dobro, znesek, plus tipka, s tretjega in vseh naslednjih dokumentov do konca pa žiro račun v dobro, znesek, plus tipka in po zadnjem tipka zvezdica. Če je bilo vse v redu, potem je bil zbirni znesek enak ničli. 

Shematsko je imel luknjani papirni trak naslednjo podobo:

Pomen kratic je naslednji:

Kon1- so podatki s konsignacija 1 in minus tipka,
Dok1+ so podatki z dokumenta 1 in plus tipka,
ZBIR1* je seštevek predhodnih dokumentov dobljen s tipko zvezdica.

Ko je delavka vpisala okoli 500 dokumentov jih je skupaj s papirnim trakom oddala v računalniško obdelavo.

IBM Sistem /370 ni imel enote (hardware) za direktno čitanje papirnatih trakov, zato je bilo treba le-te predhodno prepisati (konvertirati) na magnetni trak. Za to prepisovanje se je uporabljal poseben čitalec papirnatega traku, ki je bil priključen na drugo enoto, ki je te podatke zapisovala na magnetni trak.

Velika ovira je bilo dejstvo, da je bilo treba predhodno papirni trak previti tako, da se je trak začel s prvim luknjanim dokumentom. Ustrezno so bili razvrščeni tudi zapisi na magnetnem traku, od prvega do zadnjega.

To pomanjkljivost je odpravil šele kontrolni program TEZAURUS, ki je obdelal magnetni trak in podatke od konca proti začetku, torej brez zamudnega, počasnega, nepotrebnega ročnega previjanja papirnatih trakov pred samim konvertiranjem.
Vnos podatkov – verzija TEZAURUS


5. februarja 1973 je SDK Ljubljana kot prva podružnica začela z računalniško podprtim izvajanjem plačilnega prometa. To so bili programi razviti in izdelani v SDKJ. Že proti koncu leta 1973 je SDK Ljubljana spoznala, da imajo beograjske rešitve in programi kup pomanjkljivosti. Intenzivno se je začelo novo organiziranje, programiranje, testiranje in po vsestranskem verificiranju novega kontrolnega programa TEZAURUS, so bile odpravljene vse napake starega programa AROPS. Še več, s svojo sodobno modularno zgradbo je TEZAURUS omogočal enostavno dodajanje novih funkcij, ki so bistveno izboljšale delo SDK in poenostavile delo uporabnikom družbenih sredstev. Programski paket TEZAURUS se je začel uporabljati v letu 1975 v vseh podružnicah SDK z IBM opremo po celi Jugoslaviji. Najvidnejši primer odlične organizacije in programiranja osnovne verzije TEZAURUS je klasiranja, to je ročno sortiranje izhodnih dokumentov v enakem vrstnem redu kot so bili narejeni računalniški izpisi.  Kontrolni program TEZAURUS je bil ustrezno dopolnjen v letu 1976 skupaj s celotno spremembo starega ročnega klasiranja.

Delavci v pripravi dokumentov za vnos so dokumente vlagali v plastično vrečko z vidno označeno trimestno številko, ki je pomenila »trak« (TR). Vsaka vrečka je vsebovala okoli 500 dokumentov.

Delavke na vnosu so dobile na delovni prostor posamezno plastično vrečko z dokumenti in podatke na njih so vpisale takole:

• vnos številke plastične vrečke oziroma TR in tipka #. Ta podatek o TR je predstavljal bistveno izboljšavo in koncept kontrolnega programa TEZAURUS, na samo hitrost vnosa podatkov pa praktični ni imel nobenega vpliva.
• v primeru »samčka« (en sam dokument) žiro račun v breme, znesek s konsignacije v breme, minus tipka, žiro račun v dobro, znesek z dokumenta v dobro, plus tipka in tipka zvezdica, ki je izpisala oziroma luknjala zbirni znesek. Če sta bila zneska pravilno vpisana, potem je bil zbirni znesek enak nič.
• vnos podatkov za več dokumentov združenih v konsignaciji, pa je potekal takole: s prvega dokumenta žiro račun v breme, skupni znesek vseh dokumentov s konsignacije v breme, minus tipka, žiro račun v dobro, znesek v dobro, plus tipka, z drugega dokumenta žiro račun v dobro, znesek, plus tipka, s tretjega in vseh naslednjih dokumentov do konca pa žiro račun v dobro, znesek, plus tipka in po zadnjem tipka zvezdica. Če je bilo vse v redu, potem je bil zbirni znesek enak ničli.
• vsak posamezni dokument (samček) ali pa več skupaj zajetih dokumentov v konsignaciji (spisku ali seznamu), je predstavljalo »logično celoto« (LC), ki ji je v obdelavi kontrolni program TEZAURUS dodelil zaporedno številko,
• več LC skupaj je bilo združeno v TR, ki je fizično predstavljal plastično ovojnico z vidno označeno številko TR. Številke TR so bile vnaprej določene in se niso ponovile v enem dnevu obdelave.

Shematsko je imel luknjani papirni trak naslednjo podobo:

Pomen kratic je naslednji:

TR# je podatek »trak« ali številka plastične vrečke,
LC1- so podatki s konsignacija 1 in minus tipka (ti podatki so enaki kot pri AROPS vnosu KON1-),
Dok1+ so podatki z dokumenta 1 in plus tipka,
ZBIR1* je seštevek predhodnih dokumentov dobljen s plus tipko zvezdica.

Le za primerjavo oba papirnata trakova skupaj:

Kontrola podatkov


Kontrolni program je obdelal podatke z magnetnega traku, kontroliral njihovo pravilnost in izpisal »kontrolne liste«. Kontrolne liste so vsebovale naslednje:

• številka sloga (zapisa), ki je bila programsko dodeljena vsakemu posameznemu dokumentu,
• številka traku ali TR – velja za kontrolni program TEZAURUS,
• številka logične celote ali LC – velja za kontrolni program TEZAURUS,
• pri samčkih v breme računa, v dobro računa, znesek,
• pri paketu dokumentov v breme računa, skupni znesek s konsignacije, sledili so vsi računi v dobro z zneski s posameznih dokumentov,
• pri vsakem dokumentov še oznaka morebitne napake.

Plastične vrečke z dokumenti je skupaj s kontrolnimi listami dobila skupina delavce, ki je pregledala vse napake in jih kot popravke s pravilnimi podatki vnesla v ustrezne obrazce. Ti obrazci s popravki so imeli enak postopek kot prvotni dokumenti:

• luknjanje,
• konvertiranje,
• računalniška kontrola,
• izpis kontrolne liste s popravljenimi podatki skupaj z morebitno oznako za napako.

Klasiranje dokumentov – TEZAURUS način

Opomba: Klasiranje na prvotni, AROPS način, je razdelilo dokumente za ustrezne prejemnike, toda vrstni red je bil popolnoma poljuben in se v nobenem primeru ni ujemal z vrstnim redom dokumentov, ki je bil narejen v procesu dnevne obdelave. Vse napisano se nanaša izključno na način klasiranja, ki je opisan tukaj.

Ko je kontrola podatkov razglasila »bilanca je v redu«, so plastične vrečke z vsemi dokumenti prišle do skupine za klasiranje.

Tipičen dokument plačilnega prometa je imel štiri enake izvode, ki jih je uporabnik – nalogodajalec prinesel na šalter SDK. Delavci so razdvojili vse dokumente

• original – za arhiv SDK pri kateri je izdajatelj imel odprt žiro račun,
• 1 kopija – dobil ga je izdajatelj, to je uporabnik v breme,
• 2 kopija – dobil ga je prejemnik v dobro,
• 3 kopija - za arhiv SDK pri kateri je prejemnik imel odprt žiro račun.

V primeru, da je imel prejemnik odprt žiro račun pri drugi organizacijski enoti SDK kot izdajatelj, sta bili obe kopiji 2 in 3 s pošto poslani v kraj prejemnikovega sedeža SDK, kjer so 2. kopijo poslali prejemniku, 3. kopija pa je ostala v arhivu prejemnikove SDK.

V primeru, da je imel prejemnik odprt žiro račun v isti organizacijski enoti SDK kot izdajatelj, sta bili obe kopiji 2 in 3 poslani prejemniku, saj je SDK že imel original za arhiv.

Razdvojene dokumente pri posameznih delavcih so na predpisan način zložili skupaj v posebej pripravljene »škatle«, vodja pa je na poseben obrazec zapisal vrstni red TR, to je številke plastične vrečke v teh škatlah. Izpolnjen obrazec je šel na vnos in podatke je obdelal kontrolni program TEZAURUS. Podatki so se pozneje uporabili pri izpisu – tiskanju seznamov vseh dokumentov za posameznega uporabnika.

Dosledno upoštevanje pravil pri ročnem sortiranju dokumentov, vnos podatkov o vrstnem redu klasiranja plastičnih vrečk v škatle in uporaba teh podatkov za računalniško sortiranje izpisov, je pomenilo kvaliteto, saj je bilo ročno in računalniško sortiranje identično.

Zaključek delovnega dneva je bilo le še vlaganje (dokumenti, izpiski itd.) v ustrezne predalčke, kjer so kurirji od uporabnikov družbenih sredstev prevzeli rezultate obdelave plačilnega prometa, ali pa odprema na pošto za nekatere uporabnike na področju lastne podružnice SDK oziroma za druge podružnice SDK po celi Jugoslaviji.

Računalniška obdelava

Oddelek za računalniško obdelavo podatkov je bil po podružnicah organiziran različno. V SDK podružnici Ljubljana je imel naziv »elektronski računski center« ali ERC. Organiziran je bil takole:

Centrala SDK v Ljubljani ni imela svojega ERC. Imeli so le nekaj zaposlenih, ki so pripravili ustrezne zahtevke, v glavnem za statistične obdelave na nivoju republike. Organizacijska in programerska opravila so izvedli zaposleni v ERC SDK podružnice Ljubljana.

Podobno je bilo tudi v ostalih, manjših podružnicah SDK: imeli so računalniški center z operaterji. Lahko so predlagali ali zahtevali nove programe, toda vse tovrstne zadeve so organizacijsko in programersko naredili v centrali ali celo v SDKJ, ko jo šlo za vsedržavno upravičenost in korist.

Leta 1978 sta SDK Centrala Slovenija in podružnica Ljubljana skupaj ustanovili samostojno delovno enoto, nekakšna mini izvedba TOZD, »Skupni Elektronski Računski Center«, SERC, ki je opravljal vse posle za oba ustanovitelja. Računalniško podprto izvajanje plačilnega prometa je imelo absolutno prednost pred vsemi drugimi obdelavami.

Podobno kot SERC v Ljubljani so tudi v Zagrebu ustanovili »Center za Avtomatsko Obdelavo Podataka«, CAOP. Oba centra sta novembra 1979 podpisala skupen dogovor o »trajnem prijateljstvu in sodelovanju, da bi skupno razvijali bratstvo in enotnost in samoupravne odnose v službi družbenega knjigovodstva, omogočili izmenjavo izkušenj s področja strokovnega dela, izobrazbe, kulture, športa in družbenopolitičnega dela in delovanja ter ostalih področij družbenega življenja delavcev«. Tukaj. 

Splošni posli

Sem lahko uvrstimo

• vodstvo,
• računovodstvo,
• kadrovske,
• pravne in
• splošne zadeve.

Najbolj razvejani je bil oddelek za splošne zadeve, saj je obsegal

• šoferji za prevoz dokumentov in denarje,
• mehanikov za vzdrževanje računskih, pisalnih in drugih strojev,
• vratarjev,
• električarjev,
• mizarske delavnice,
• kuhinja.