Tajemství automatické likvidace - první část
Dovolte, abych se představil. Jmenuji se Petr Vocel a mohu říci, že jsem se celý život živil a točil okolo programování počítačů. Proto vím, že zdaleka nejde jenom o to jak "to" nakódovat, ale často neméně důležitou otázkou je výběr použitého postupu při řešení problematiky, která existuje venku a je potřeba ji "nacpat" do počítače. Dnes je trochu snaha fáze projektu rozdělit na analýzu a na kódování. Tohle řešení je vhodné pro projekty, které svými požadavky vlastně spadají do oblasti, dá se říci typových činností. Tam se dá vybrat vlastně již existující typové řešení a upravit jej podle, z hlediska typovosti drobných, požadavků zákazníka. Ale, jsou-li na funkčnost kladeny neběžné, dá se říci nestandardní požadavky, je potřeba do projektu zařadit fázi, ve které se ověří realizovatelnost "zatím" navrhnutého postupu při řešení funkčnosti. V této fázi je potřeba víc přemýšlet o těch číslech, která se mají zpracovat a co to s nimi opravdu děláme a míň kódovat. Každá rychle vybraná, ale ne dostatečně účinná cesta, stojí jak čas, tak energii a někde se ty zvýšené náklady promítnou.
Já vím, že vám tento článek nepřinese „tahák“ na to, jak vyřešit váš problém s kódováním, ale doufám, že by vás mohl poučit a inspirovat, jak se dá k problémům přistupovat a jak je lze řešit. Proto vzhůru do muzea programování.
Identifikace plateb
V polovině sedmdesátých let minulého století (to zní opravdu děsivě historicky) končila životnost počítače Státní banky Československé, která byla centrální bankou a kromě běžných funkcí centrální banky, které má dnes ČNB, plnila i funkci obchodní banky pro podnikovou sféru. Dá se říci, že v ní měly prakticky účty všechny "právnické" osoby. Občané měli účty v České spořitelně a ČSOB se specializovala hlavně na zahraniční operace. Tehdy začala centrální banka připravovat a řešit nový bankovní systém, který měl běžet na novém hardware a kromě jiného měl připravit i lepší prostředí pro další rozvoj automatizace platebního styku. Bylo zavedeno číslo dokladu - něco jako rodné číslo účetní položky, ze kterého se dalo poznat v které bance, kdy a kde byl podnět pořízen. Do položky byly přidány tři číselné, až 10 místné symboly, které sloužily a vlastně slouží dodnes k identifikaci platby pro její vyhodnocení a pro automatizaci dalšího zpracování. První symbol, takzvaný „variabilní“, se používá hlavně pro číslo faktury respektive jiné označení, ze kterého je plátce schopen identifikovat, za co zaplatil a příjemce za co dostal zaplaceno. Druhý symbol, takzvaný „konstantní“, charakterizoval ekonomickou podstatu platby. Z něj se dalo poznat, zda je to např. splátka úvěru, výplata mzdy, úroky, daně a podobně. Také se dalo poznat, zda platba byla placena v hotovosti. Dnes se sice stále používá, ale kromě plateb do státních institucí (např. Finanční úřady) se na něj neklade moc důraz. Poslední symbol, takzvaný „specifický“, se používal na to, aby měl plátce větší vodítko k identifikaci své vnitřní struktury. Například u plateb stavebních organizací se zde uvádělo číslo stavby a podobně. Jednalo se o velice progresivní způsob, který nám později řada zemí záviděla.
Jak systém funguje
Systém měl zkratku ABO (automatizované bankovní operace) a byl navržen koncepčně tak dobře, že s určitými technologickými inovacemi pracoval, respektive pracuje již skoro 40 let! Kromě dobré koncepce byla při jeho tvorbě i snaha o to, aby realizace projektu byla vedena, dá se říci až "vzorově". Základem byla důsledná dokumentace, kde každý modul měl popis funkčnosti, a samozřejmě jaké záznamy používá. Každý záznam měl svůj identifikátor (Znnn, kde nnn bylo jeho unikátní číslo) a popis z jakých údajů se skládá. Každý údaj měl své závazné jméno, zkratku, rozsah číselníku a význam jednotlivých hodnot a podobně. Mimo to měl dynamicky používané tabulky uživatelských parametrů, jako např. čísla a názvy poboček, kurzy měn, úrokové sazby pro jednotlivé případy a podobně. Tyto tabulky byly pomocí speciálního software udržovány uživatelem, který tímto způsobem řídil zpracování. Vlastně to byl předchůdce dnešní databáze, ve které si uživatel nastavuje hodnoty jednotlivých parametrů a řídí tím své zpracování.
Denně se sesbírala data, která byla pořizována na jednotlivých pobočkách pomocí terminálů dálnopisného typu. Terminály byly obsluhovány pomocí minipočítačů na úrovni krajů. Ty prováděly základní kontroly a zpětnou editaci pro uživatele. Takto sesbíraná data se potom po telefonních linkách posílala do centra, kde se na minipočítači sloučila do dávky pro centrální počítač a zapsala se na magnetickou pásku a předala dál. Data se dělila do dvou základních typů. Na účetní (platby) a neúčetní sloužící k udržování ostatních informací jako byly adresní údaje o klientovy, o účtech, trvalé příkazy, blokace a ostatní parametry jednotlivých klientů.
Po zpracování se na centrálním počítači vytvořil soubor s tiskovými sestavami, který se ve speciálním formátu (např. číselná pole ve čtyřbitových znacích, spec. znaky pro násobné mezery a podobně) se opět z minipočítače rozesílal do krajských středisek, kde se vytiskl, a výstupy se rozvezly v rámci kraje pobočkám. Takže byl dodržen denní cyklus. Druhý den byly v bance na všech pobočkách v celé republice k dispozici výpisy z účtů, které měly předchozí den pohyb.
Automatická likvidace
Třešničkou na dortu však byla automatická likvidace (i když z hlediska jazyka by se měla správně jmenovat „automatizovaná“ a ne automatická). Platby se neplatily automaticky, ale pouze se automatizovalo rozhodování, které budou při nedostatku prostředků prolaceny a které zatím ne. Problémem, který donutil ekonomy k požadování dané funkce, byla takzvaná "sekundární platební neschopnost", která vznikala tím, že vám vaši dlužnici zatím nezaplatili a vy jste tím pádem neměl na své platby. Byla snaha snížit tuto neschopnost alespoň tím, že peníze, které vám dojdou dnes na účet, budou automatizovaně ještě dnes použity na platby, které máte zaplatit vy. Tehdy byly totiž trochu jiné podmínky a firmy pokud nechtěly po právní stránce fakturu zpochybňovat, tak měly povinnost ji v den splatnosti dát do banky i když na fakturu v daný moment neměly. Tím pádem byla základna položek, na kterou bylo možno danou funkčnost aplikovat.
A automatická likvidace byl modul, který měl tuto funkčnost zajistit a rozhodnout, co se má ten den zaplatit tak, aby se co nejvíce využily i prostředky, které ten den došly, takzvaný naběhlý kredit. Samozřejmě bylo přitom nutno respektovat určitá pravidla hry, něco jako dopravní předpisy. Platby měly sestaven klíč pořadí, který byl vlastně věcné hledisko (co to bylo za platbu - např. vybranou hotovost je nutno zaplatit jako první), pak časové hledisko (splatnost) a další věcné pořadí v rámci stejné splatnosti. Při troše zamyšlení zjistíte, že vlastně není jasné, jak začít a hlavně i kdy už mohu skončit a také jak, aby se mi celý algoritmus, jak se říká, "nezacyklil". Aby člověk lépe pochopil, co bylo úkolem, tak si představte problém jako město, kde váš program má řídit semafory na křižovatkách tak, aby v dané situaci byla průjezdnost města co největší. Co je velice důležité, je samozřejmě četnost vyskytujících se prvků. Je potřeba si uvědomit, že počty účtů (řízených křižovatek) a počty položek (aut) se pohybovaly mezi statisíci až miliony. Byly na to i expertízy, že to nejde vyřešit. Je celkem jasné, že neexistuje jedno řešení, ale skupina dostatečně efektivních případů. Vzniká ale otázka, jak se do ní dostat.
Tak teď už víme, co se mělo řešit a příště můžeme přistoupit k tomu, jak to bylo uděláno.
