Blog | Jak jednoduše zrealizovat Centrální registr tržeb

Jak jednoduše zrealizovat Centrální registr tržeb

Setkal jsem se s tvrzením, že online registr tržeb nepůjde zrealizovat a když, tak za 3 roky odteď a za miliardu korun. Já si myslím, že je to hloupost a takový registr se dá udělat levně a rychle.

Zkusme si to spočítat. Zkusme zavést takový registr úplně pro všechny. To je cca milion subjektů. Počet faktur, tržeb, které denně udělají, se může výrazně lišit. Máte programátora, který pošle tak 1–2 faktury měsíčně, máte Tesco, kterým denně projde třeba 100 000 účtenek. Pak budete mít restaurace, ty dají tak 100 účtenek denně, obchody, ty jdou třeba do 2–3 stovek. Zkusme se dohodnout na čísle 150 a o víkendu tak 100. To je 50 000 tržeb na podnikatele a rok, samotné to číslo je obrovské a realita bude určitě nižší.

Vychází nám to na cca 50 miliard záznamů ročně.

Jeden záznam musí obsahovat:

  • IČ obchodníka (27 bitů, vejde se do 4 bajtů)
  • UUID – unikátní identifikátor transakce (36 bajtů, vlastně je to o trochu míň, ale případně nechávám prostor pro něco ještě silnějšího než UUID)
  • částka – desetinné číslo do 100 miliard s 2 místy za desetinnou čárkou (37 bitů, vejde se do 5 bajtů)
  • timestamp vzniku (4 bajty)

To máme na jeden záznam 49 bajtů, počítejme nějaký overhead, data budeme chtít ukládat na 2 disky naráz, budou indexována podle IČ, UUID, částky i timestampu, tak počítejme, že dat bude potřeba 20* tolik. To je 1 kilobajt na záznam.

Ročně nám systém vygeneruje cca 5 tera dat. To znamená, že roční náklady na uložení dat nás vyjdou do 10 tisíc. Záleží ještě na efektivitě ukládání v enginu.

Rozpočítejme si nyní datový tok, použil bych HTTPS requesty pomocí REST API.

Nechal bych na obchodnících, ať si vygenerují náhodné UUID sami (předpokládejme, že většina podnikatelů jsou poctiví lidé a pokus o zneužití by byl vždy vázaný na IČ, takže snadno by se dalo ukázat prstem na to procento podvodníků). Takže bych se zbavil na povinnosti být online, stačilo by jednou za čas poslat hromadně všechny tržby.

Předpokládejme overhead na 1 request asi 1 kilobajt. V requestu by šla data zmíněná výše + token, který by byl unikátní pro každého obchodníka a byl by tajný, ten dejme třeba 20 bajtů. To máme 1024+69 bajtů na 1 tržbu, nebo třeba pro průměrných 135 denních tržeb, pokud by stačilo nahrát data jednou denně 7123 bajtů (počítám, že IČ a token stačí poslat jen jednou v hromadné zprávě).

Pokud půjdou všechny tržby po jedné, bude denní tok dat 152 gigabajtů (A). Pokud by se posílala data pouze jednou denně, tok bude pouze něco přes 6 giga denně (B).

Pokud by třeba byla špička 8 hodin, v kterých se vydá 80 % požadavků, máme 8 hodin, během kterých musíme přijmout 121 giga (A), 5 giga (B), to vychází na 4.3 mega za vteřinu (A), popř. 182 kilobajtů za sekundu (B). Nic strašného. Myslím, že z 1 průměrného stroje ulož.to jde větší datový tok.

Podívejme se na počty requestů.

Při posílání tržeb po jedné máme v osmihodinové špičce 4166 requestů za vteřinu (A), při posílání tržeb po dni máme 27 requestů za vteřinu. Navíc ty requesty můžou jít asynchronně, nemusíme většinou moc čekat na odpověď. Šance, že se vygenerují dvě stejná náhodná UUID je tak malá, že do vás spíš narazí meteorit.

4166 requestů za vteřinu už je trochu oříšek, nebude nám stačit 1 stroj (když se použije rychlý programovací jazyk, tak i toto se dá zvládnout). Na 2 strojích ale už není toto nic nezvládnutelného. 27 requestů není nic, to utáhnete pomalu i na hostingu za dvě stovky měsíčně.

A teď jak na to technicky.

Použil bych 2 stroje, na které bych dal Riak. Do Riaku bych ukládal data a udělal si sekundární indexy tak, jak jsem zmínil výše. Příjem dat by byl snadný, v podstatě by jen platforma zkontrolovala v Redisu, že odpovídající token se smí použít s daným IČ a zkontroloval by se formát requestů. Pak by se jen přeposlal dotaz do Riaku. Pokud by dokument v Riaku už existoval, vygeneroval by se jiný UUID, pod ním by se transakce uložila a taky by se UUID vrátil zpět obchodníkovi. To pro případ, že by tento zákon přežil několik stovek let, kdy dojde k první kolizi.

Ukládání dat by bylo bratru tak na 200 řádek kódu, s testy na 400.

Zbytek už jsou jen výstupy pro Ministerstvo financí, kterému by se vystavila různá API. Protože bych měl v Riaku indexy, běžné dotazy (co vydal tento podnikatel mezi těmito daty, jaké měl tržby mezi těmito daty, byla tato účtenka vydána v tuto dobu apod.) by netrvaly téměř nic.

Pak už je to o tom udělat jednoduchou stránku, kde si občan může zkontrolovat, že UUID bylo do systému posláno. Další tři, čtyři stovky řádek kódu.

Z technického pohledu, není důvod, proč by Online registr tržeb nemohl za měsíc ode dneška běžet.


Tento článek je pouze k technické realizaci online registru tržeb, kde ukazuju, jak by se to dalo udělat a něstálo by to miliardu a na provozu další stovky milionů, ale spíš tak 1 %. Pokud se taková věc vyvine s parametry běžnými v soukromé sféře.

Z politického pohledu je ale online registr tržeb extrémně špatný nápad. Jedná se o velkého bratra, který stojí už jen krůček od Online registru poloh obsahující, kde a kdy každý podnikatel a jeho zaměstnanec byl, kterým stát: „Zatočí se zneužíváním služebních cest, který tento stát stojí miliardy.“ A Online registru komunikace, aby stát předešel: „Organizovanému zločinu, který tento stát stojí miliardy.“

Za druhé je to další naprosto zbytečná bariéra. Pokud má stát jít směrem k podnikání, naopak, by měl být živnostníkem ze zákona každý. Nebyly by žádné minimální daně, každý by mohl poslat fakturu komukoliv za cokoliv. Měly by být zrušeny takové věci, jako zákoník práce, hygienické normy a mnoho dalších věcí (to neznamená, že budou číšníci plivat do polévky a majitelé sdírat zaměstnance, jen bude vše víc na osobní dohodě a na kontrole privátních kontrolorů hygieny). Samosprávu by si měly zajišťovat komory. Pokud si dnes už podnikatelé stěžují na příliš mnoho regulací a že nemůžou konkurovat státům s nižší regulací (a naopak se smějí státům jako Itálie, Španělsko, Řecko, kde by podnikal jen blázen), těžko problém vyřeší ještě více regulací.

Navíc se tím stát dostává k další podstatné informaci. K informaci, která je zajímavá pro průmyslovou špionáž, pro různé firmy napojené na stát (přímo přes vlastnictví, nepřímo tak, že nejmenovaný politik v pozici, ve které k datům rozhodně bude mít přístup, je zároveň podnikatel). Zavést takový registr a mít ho ve státě, instituci, která je hned po armádě asi nejvíc zkorumpovanou institucí v ČR (pravda, zdravotnictví je těžká konkurence), to je jak střílet do vlastních.


Takže: z pohledu státu zavést online registr je to minimální problém. Z pohledu podnikatelů, jde o to vyzvednout si token a poslat programátorovi přidání do aplikace. Poslat POST požadavek, to ať mi nikdo neříká, že to není na softwarové úrovni práce na víc než jedno odpoledne.

Přesto si myslím, že se jedná o špatný nápad. Nerad bych se dočkal doby, kdy si budou nejbohatší lidé pořizovat místa ve vládě, média, budou monitorovat tržby vlastní konkurence… nebo, že by se ta doba už blížila?

Předejte zkušenosti i dalším a sdílejte tento článek!

Předchozí článek
Následující článek


Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích