Vydělávej až 160.000 Kč měsíčně! Akreditované rekvalifikační kurzy s garancí práce od 0 Kč. Více informací.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Vzájemný zápočet

Program vzájemného zápočtu měl vyhodnotit, co vše lze z balíku nerealizovaných položek zaplatit bez vložení finančních prostředků - takzvanou vzájemnou kompenzací pohledávek. Úkol zdánlivě jednoduchý, ale při bližším pohledu na věc zjistíte, že se jedná o velice složitý problém. Když se jedná o vzájemné dluhy mezi dvěma dlužníky, tak to umí vyřešit malé dítě v základní škole. Jak ale přibývají účastníci, tak geometrickou řadou rostou vazby mezi nimi a vynořuje se otázka, které cesty by se měly použít, aby se dosáhlo co největšího efektu.

Ukázalo se, že klasické „vědecko-matematické“ postupy, které se tehdy snažili řešitelé použít, zdaleka nedosahují očekávaných výsledků. Úkol tehdy řešila skupina „ekonomů“ okolo p. Václava Klause a p. Rudlovčáka, kteří v té době pracovali ve Státní bance. Já jsem v té době také pracoval v dané instituci, ale na rozdíl od nich jsem se nezabýval ekonomickými odhady, nýbrž jsem zodpovídal za to, aby denní zpracování proběhlo v pořádku a ráno byly v celé republice k dispozici korektní výpisy z účtů. Musím se přiznat, že dokud mne neupozornili, abych se o tuto problematiku nezajímal, tak jsem ji skutečně nevěnoval pozornost. Pak mi to ale nedalo a začal jsem o ní přemýšlet. Nelíbily se mi zmiňované vědecké metody a pořád jsem cítil, že tomu něco chybí, zkrátka že to není ono.

A jednoho dne mne napadlo, že by se to dalo řešit zcela jinak. Nedalo mi to a zkusil jsem si to napsat. Když se mi to podařilo konečně odladit, šel jsem se zeptat, zda neposunovali čas v počítači, protože výpočet byl velice rychlý. Člověk si musí ale uvědomit, že v životě při realizaci nestojíte pouze před technickými problémy, ale i před problémy z oblasti společnosti. Proti mně stála skupina, která svým dalším společenským vývojem jasně prokázala, že o své cíle hraje tvrdě. Dát to jen tak na stůl, prostě nešlo a proto jsem své řešení podal jako zlepšovací návrh, proti v té době již jejich hotovému řešení. Tím jsem získal zákonné právo, že museli porovnat svoje již hotové řešení s mým. Porovnání bylo jednoduché. Jejich řešení počítalo 8 hodin a uvolnilo z daného balíku cca 1 miliardu. Moje řešení pracovalo 30 s a uvolnilo ze stejného balíku cca 2 miliardy.

Realizace

Na tomto příkladu je vidět, že „programovací technika“ může ledacos, ale nejdůležitější je pochopit co a proč počítat. A teď, když už víme zhruba o co se vlastně jednalo, tak se podíváme na to, jak to bylo provedeno. Řešení vycházelo z toho, že místo aby se počítalo, co lze zaplatit, tak se počítalo, co se nemá, respektive je nevhodné zaplatit. Když se pokoušíte vypočítat, co máte zaplatit, tak vlastně nevíte, kde začít a kam pokračovat. Při hledání toho co se nemá realizovat, můžete inicializací převést problém do stavu, kdy je toto jasné. Proto první byl inicializační krok pro nastavení situace. Ten krok spočíval v tom, že napřed se vše zaúčtovalo. Tím se ale některé účty dostaly do debetu a jiné do kreditu. Představíme li si situaci, že po tomto kroku by všechny účty až na dva byly na nule, potom musí existovat jedna platba mezi těmito dvěma účty, která způsobí to, že daný účet bude v debetu a ten druhý v kreditu. Takže stačí ji odstranit a máme nejefektivnější řešení a dá se říci, že skoro bez počítání.

Problém je to, že platba nemusí být pouze přímo mezi těmito účty, ale může přecházet přes několik dalších jako transakce in/out. Problém se vyřeší rekurzivní funkcí, která odstraňuje platby mezi kreditními a debetními účty. Jako parametr má počet meziúčtů, přes které může daný vztah procházet. V prvním kole se nastavil počet meziúčtů na nulu, a odstranily se všechny položky mezi účty, kde jeden byl v debetu a druhý v kreditu a mezi nimi nebyl žádný další. Pokud se tím všechny účty nedostaly na nulu, zvednul se počet meziúčtů o jeden a podprogram zavolal rekurzivně sám sebe. Tak se postupovalo, dokud nebyly všechny účty na nule, nebo se nevyčerpal maximální počet vnoření. To bylo nastaveno na 10, ale k vyčerpání nikdy nedošlo.

Toto řešení kromě velice rychlého a efektivního výpočtu, provedlo rovněž analýzu, kolik by šlo uvolnit při úvěrech na správné místo. Každá dávka vyřazená při odpovídajícím vnoření, svým objemem a vyřazenou částkou naznačovala, kolik by se uvolnilo, kdyby se poskytl úvěr v této výši konkrétním dlužníkům. Čím větší vnoření, tím byla větší efektivita snížení objemu dluhů. Tyto informace však nebyly nikdy využity a k úvěrování se nepřistoupilo.

Výsledek

Pro představu o rozsazích problematiky a dopadů vzájemného zápočtu, mohu uvést, že poslední zpracování dat bylo ještě po rozdělení Československa na Českou a Slovenskou republiku. Výsledky zpracování tehdy hlásili v rozhlase, a byly následující: Představíme-li si problém jako mapu, dlužníky jako města a sečtené dluhy jako cestu mezi nimi, tak se jednalo o 5000 měst, mezi nimi 170 000 sečtených dluhů jako cest. Zpracování trvalo 5 minut a uvolnění mělo hodnotu přes 8 miliard.

Ještě bych rád řekl, že kromě vhodného algoritmu výpočtu, je potřeba vytvořit také technické podmínky pro realizaci. První bylo to, že bylo potřeba provést dostatečnou integraci dat, aby počet vazeb odpovídal skutečně nutnému minimu. Proto byly jednotlivé položky se shodnými účty (debet+kredit) sečteny do jedné. Z výše uvedených výsledků je zřejmé, že i po sečtení všech dílčích položek mezi dvěma partnery do jediné, jich bylo pořád ještě 170 000. Druhé co bylo nutné vyřešit, byla struktura uložení dat v paměti a management výměny dat mezi pamětí počítače a diskovým nosičem tak, aby se toto nestalo úzkým profilem při zpracování. A protože na konci bylo nutno výsledky zpětně vyjádřit v detailních položkách, tak bylo nutno vnutit deagregační podmínky uživateli. To znamená, že podle vypočtené částky mezi dvěma účty se postupně ze závazného pořadí plateb, které byly agregovány do jedné, uvolňovaly jednotlivé platby s tím, že u poslední možné platby byla provedena pouze částečná úhrada ve výši, která byla ještě k dispozici. Jinak by se celý výsledek rozbil a přestal by být účetně správný. To ale nebyl problém, protože částečné úhrady již byly v té době podporované a dá se říci i běžné.


 

Všechny články v sekci
Články nejen o programování
Článek pro vás napsal Petr Vocel
Avatar
Uživatelské hodnocení:
7 hlasů
Autor se méně soustředí na nástroje a pozornost věnuje více tomu jak dostat funkčnost reaálného světa do počítače.
Aktivity