Tajomstvo automatické likvidácia - prvá časť
Dovoľte, aby som sa predstavil. Volám sa Peter Vocel a môžem povedať, že som sa celý život živil a točil okolo programovanie počítačov. Preto viem, že zďaleka nejde len o to ako "to" nakódovať, ale často nemenej dôležitou otázkou je výber použitého postupu pri riešení problematiky, ktorá existuje vonku a je potrebné ju "napchať" do počítača. Dnes je trochu snaha fáza projektu rozdeliť na analýzu a na kódovanie. Toto riešenie je vhodné pre projekty, ktoré svojimi požiadavkami vlastne patria do oblasti, dá sa povedať typových činností. Tam sa dá vybrať vlastne už existujúce typové riešenia a upraviť ho podľa, z hľadiska typovosti drobných, požiadaviek zákazníka. Ale, ak sú na funkčnosť kladené nebežný, dá sa povedať neštandardné požiadavky, je potrebné do projektu zaradiť fáze, v ktorej sa overí realizovateľnosť "zatiaľ" navrhnutého postupu pri riešení funkčnosti. V tejto fáze je potreba viac premýšľať o tých číslach, ktoré sa majú spracovať a čo to s nimi naozaj robíme a menej kódovať. Každá rýchlo vybraná, ale nie dostatočne účinná cesta, stojí ako čas, tak energiu a niekde sa tie zvýšené náklady premietnu.
Ja viem, že vám tento článok neprinesie "ťahák" na to, ako vyriešiť váš problém s kódovaním, ale dúfam, že by vás mohol poučiť a inšpirovať, ako sa dá k problémom pristupovať a ako ich možno riešiť. Preto hor sa do múzea programovania.
Identifikácia platieb
V polovici sedemdesiatych rokov minulého storočia (to znie naozaj desivo historicky) končila životnosť počítača Štátnej banky Československej, ktorá bola centrálnou bankou a okrem bežných funkcií centrálnej banky, ktoré má dnes ČNB, plnila aj funkciu obchodné banky pre podnikovú sféru. Dá sa povedať, že v nej mali prakticky účty všetky "právnickej" osoby. Občania mali účty v Českej sporiteľni a ČSOB sa špecializovala hlavne na zahraničné operácie. Vtedy začala centrálna banka pripravovať a riešiť nový bankový systém, ktorý mal bežať na novom hardware a okrem iného mal pripraviť aj lepšie prostredie pre ďalší rozvoj automatizácie platobného styku. Zaviedlo číslo dokladu - niečo ako rodné číslo účtovné položky, z ktorého sa dalo spoznať v ktorej banke, kedy a kde bol podnet zhotovený. Do položky boli pridané tri číselné, až 10 miestne symboly, ktoré slúžili a vlastne slúži dodnes na identifikáciu platby pre jej vyhodnotenie a pre automatizáciu ďalšieho spracovania. Prvý symbol, takzvaný "variabilné", sa používa hlavne pre číslo faktúry respektíve iné označenie, z ktorého je platiteľ schopný identifikovať, za čo zaplatil a príjemcu za čo dostal zaplatené. Druhý symbol, takzvaný "konštantný", charakterizoval ekonomickú podstatu platby. Z neho sa dalo poznať, či je to napr. Splátka úveru, výplata mzdy, úroky, dane a podobne. Tiež sa dalo poznať, či platba bola platená v hotovosti. Dnes sa síce stále používa, ale okrem platieb do štátnych inštitúcií (napr. Finančné úrady) sa na neho nekladie moc dôraz. Posledný symbol, takzvaný "špecifický", sa používal na to, aby mal platiteľ väčšiu vodítko k identifikácii svojej vnútornej štruktúry. Napríklad u platieb stavebných organizácií sa tu uvádzalo číslo stavby a podobne. Jednalo sa o veľmi progresívny spôsob, ktorý nám neskôr mnohé krajiny závidela.
Ako systém funguje
Systém mal skratku ABO (automatizované bankové operácie) a bol navrhnutý koncepčne tak dobre, že s určitými technologickými inováciami pracoval, respektíve pracuje už skoro 40 rokov! Okrem dobrej koncepcia bola pri jeho tvorbe aj snaha o to, aby realizácia projektu bola vedená, dá sa povedať až "vzorovo". Základom bola dôsledná dokumentácie, kde každý modul mal opis funkčnosti, a samozrejme aké záznamy používa. Každý záznam mal svoj identifikátor (Znnn, kde nnn bolo jeho unikátne číslo) a opis z akých údajov sa skladá. Každý údaj mal svoje záväzné meno, skratku, rozsah číselníku a význam jednotlivých hodnôt a podobne. Mimo to mal dynamicky používané tabuľky užívateľských parametrov, ako napr. Čísla a názvy pobočiek, kurzy mien, úrokové sadzby pre jednotlivé prípady a podobne. Tieto tabuľky boli pomocou špeciálneho softvéru udržiavané užívateľom, ktorý týmto spôsobom riadil spracovania. Vlastne to bol predchodca dnešnej databázy, v ktorej si užívateľ nastavuje hodnoty jednotlivých parametrov a riadi tým svoje spracovanie.
Denne sa zozbierala dáta, ktoré boli nadobudnuté na jednotlivých pobočkách pomocou terminálov ďalekopisného typu. Terminály boli obsluhované pomocou minipočítačov na úrovni krajov. Tie vykonávali základné kontroly a spätnú editáciu pre užívateľov. Takto zozbierané dáta sa potom po telefónnych linkách posielala do centra, kde sa na minipočítač zlúčila do dávky pre centrálny počítač a zapísala sa na magnetickú pásku a odovzdala ďalej. Dáta sa delila do dvoch základných typov. Na účtovník (platby) a nefinančných slúžiace na udržiavanie ostatných informácií ako boli adresné údaje o klientove, o účtoch, trvalé príkazy, blokácia a ostatné parametre jednotlivých klientov.
Po spracovaní sa na centrálnom počítači vytvoril súbor s tlačovými zostavami, ktorý sa v špeciálnom formáte (napr. Numerické polia vo čtyřbitových znakoch, špec. Znaky pre násobné medzery a podobne) sa opäť z minipočítačov rozosielal do krajských stredísk, kde sa vytlačil, a výstupy sa rozviezli v rámci kraja pobočkám. Takže bol dodržaný denný cyklus. Druhý deň boli v banke na všetkých pobočkách v celej republike k dispozícii výpisy z účtov, ktoré mali predchádzajúci deň pohyb.
Automatická likvidácia
Čerešničkou na torte však bola automatická likvidácia (aj keď z hľadiska jazyka by sa mala správne volať "automatizovaná" a nie automatická). Platby sa neplatili automaticky, ale iba sa automatizoval rozhodovaní, ktoré budú pri nedostatku prostriedkov prolaceny a ktoré zatiaľ nie. Problémom, ktorý donútil ekonómov k požadovaní danej funkcie, bola takzvaná "sekundárne platobná neschopnosť", ktorá vznikala tým, že vám vašu dlžníka domáhali zatiaľ nezaplatili a vy ste tým pádom nemal na svojej platby. Bola snaha znížiť túto neschopnosť aspoň tým, že peniaze, ktoré vám dôjdu dnes na účet, budú automatizovane ešte dnes použité na platby, ktoré máte zaplatiť vy. Vtedy boli totiž trochu iné podmienky a firmy ak nechceli po právnej stránke faktúru spochybňovať, tak boli povinné ju v deň splatnosti dať do banky aj keď na faktúru v daný moment nemali. Tým pádom bola základňa položiek, na ktorú bolo možné danú funkčnosť aplikovať.
A automatická likvidácia bol modul, ktorý mal túto funkčnosť zabezpečiť a rozhodnúť, čo sa má v ten deň zaplatiť tak, aby sa čo najviac využili aj prostriedky, ktoré v ten deň došli, takzvaný naakumulovaný kredit. Samozrejme bolo pritom nutné rešpektovať určité pravidlá hry, niečo ako dopravné predpisy. Platby mali zostavený kľúč poradí, ktorý bol vlastne vecné hľadisko (čo to bolo za platbu - napr. Vybranú hotovosť je nutné zaplatiť ako prvý), potom časové hľadisko (splatnosť) a ďalšie vecné poradie v rámci rovnakej splatnosti. Pri troche zamyslenie zistíte, že vlastne nie je jasné, ako začať a hlavne aj keď už môžem skončiť a tiež ako, aby sa mi celý algoritmus, ako sa hovorí, "nezacyklil". Aby človek lepšie pochopil, čo bolo úlohou, tak si predstavte problém ako mesto, kde váš program má riadiť semafory na križovatkách tak, aby v danej situácii bola prejazdnosť mesta čo najväčší. Čo je veľmi dôležité, je samozrejme frekvencia vyskytujúcich sa prvkov. Je potrebné si uvedomiť, že počty účtov (riadených križovatiek) a počty položiek (áut) sa pohybovali medzi státisícmi až milióny. Boli na to aj expertízy, že to nejde vyriešiť. Je celkom jasné, že neexistuje jedno riešenie, ale skupina dostatočne efektívnych prípadov. Vzniká ale otázka, ako sa do nej dostať.
Tak teraz už vieme, čo sa malo riešiť a nabudúce môžeme pristúpiť k tomu, ako to bolo urobené.
