EKONOMIKA: Povinná četba pro Andreje Babiše

Proč online pokladny nebudou v 2016 ani omylem

Pojďme na to. V pátek se opět prohnala médii informace o povinném hlášení tržeb finančáku a s tím spojená sranda s názvem „účtenková loterie“. Nechám stranou hlášky o programové likvidaci živnostníků, odpustím si vtipy na ANOfert, prostě budu hodný, konstruktivně přispívající občan, ano? Jediné, o čem budu psát, je realizovatelnost návrhu zákona po technické stránce (ano, jsem „ajťák“, ale napíšu to srozumitelně). Pane ministře, prosím, dočtěte to, tuhle analýzu vám dám zdarma (pro notorické rýpaly, ano, tohle není skutečná analýza, ta by měla desítky stran a nepsal bych ji v pátek v noci…).

Long story short:
Proč je termín 2016-17 nereálný? Jednoduše proto, že se to nestihne. Tak komplexní systém (abstrahuji od nutnosti nákupu kompatibilních pokladen, to je problém živnostníků) není možné pro státní správu v šibeničním termínu 9-21 měsíců naprogramovat, natož otestovat a nasadit. Samotná myšlenka je možná (s důrazem na „možná“, osobně ji považuju za paskvil) zajímavá (pro velké společnosti), ale technická realizace je noční můra. Dle mého nejoptimističtějšího odhadu by se celá tahle legrace dala spustit v polovině roku 2018, a i to ještě v testovacím provozu. Takže jednoznačně – schválit ten zákon můžete, ale to je tak všechno.

Long story:
Nejprve stručné intro. Následující text nejsou „odhady a dohady někoho, kdo tomu absolutně nerozumí“ – za posledních pět let jsem pracoval na několika státních zakázkách „velkého rozsahu“ (na různých pozicích - technical writer, test a business analytik), spolupracoval jsem s vnitrem, ŘSD, poštou, skupinou ČEZ, takže si myslím, že mám určitý „vhled“ do fungování státních zakázek – od výběrového řízení až po implementaci (pokud k ní vůbec došlo…). Současně jsem ale podepsal ledacos (pšššt…), takže nemohu být konkrétnější, budete mi muset věřit, no…

Ale zpět k tématu. Aktuální návrh MinFin bych shrnul asi takto: každý z dotčených podnikatelů bude mít registrační pokladnu/terminál, která bude každou účtenku posílat na příslušný finanční úřad. Finančák si ji uloží, přidělí jí unikátní identifikační číslo a tohle číslo pošle zpět pokladně. Pokladna vytiskne účtenku s tímto unikátním ID a zákazník zaplatí. Při kontrole daňového přiznání se účtenky uložené na finančním úřadě sečtou a porovnají s daňovým přiznáním subjektu. Hotovo. (Zjednodušeno až na dřeň, ale pro tuhle „analýzu“ stačí – i tak to bude zajímavé.)

Píšu tady „účtenky“, to vypadá jednoduše – částka, provozovna, ID a hotovo, jenže… V prezentaci MinFin je uvedeno, co všechno ta „účtenka“ bude obsahovat – ID subjektu, datum a čas transakce, celková tržba, základy DPH a částky DPH dle sazeb, identifikace provozovny, identifikace podkladního místa. To by ještě šlo, v prezentaci jsou ale navíc i „další zvažované údaje“ – informace o zaměstnanci přijímajícím tržbu, stav pokladny (hotovost), informace o zboží podléhajícím spotřební dani a typ platby. To už je celkem velká „účtenka“. Zvlášť ta část o zboží se spotřební daní – nakoupíme cigarety, nějaký alkohol a máme několik záznamů tohoto typu na účtenku.

Co to znamená z hlediska informačního systému, který aktuálně neexistuje a bude muset být vytvořen? Tak nejprve legislativní záležitosti pro zadání veřejné zakázky velkého rozsahu (ne, tohle opravdu nebude malý rozsah, bavíme se o částce 500+ mlionů za celý systém). Podle legislativy tedy:

- Bude nutné vypsat tendr na tuto zakázku. Jen vytvoření zadávací dokumentace bude potřebovat minimálně tři měsíce (a to počítáme s tím, že bude plná chyb, odhadů a „bude upřesněno“). Ostatně na webu je zatím jen stručná prezentace s tím, že technický rámec ještě bude upřesněn (= mají zatím jen nápad).

- Firmy, které to risknou, mají minimálně měsíc, v tomto případě raději dva, na dodání Nabídky. Součástí Nabídky by měla být i Studie proveditelnosti a Rámcový rozpočet projektu (podle kterého se budou vybírat „nejlepší“ nabídky, to dá rozum).

- Po ukončení výběrového řízení máme měsíc (spíš dva) na vyhodnocení vítězné nabídky.

- Pokud by došlo k odstartování výběrového řízení v březnu, máme vítěze už v září, ale spíše v listopadu 2015…

- Pochopitelně počítáme s tím, že žádná z nevybraných firem nepodá proti výsledku VŘ protest. To by znamenalo další tři až pět měsíců odklad…

- OK, máme vybranou firmu, je říjen 2015 (zprůměroval jsem optimistickou a pesimistickou variantu).

A jedeme dále. Teď to začne být teprve zajímavé. Opět abstrahuji od všech možných chyb v zadání, v analýze, specifikacích atd., které by znamenaly „zpět na start“. Máme vybraného dodavatele, dodavatel zná všechny požadavky, rizika a dokonce je schopen i dodat hardware. (V reálu to tak nebude, na HW se bude vypisovat další výběrové řízení a kritériem bude opět cena. Takže pokud dodavatel software po celou dobu počítá s nasazením na servery HP ProLiant, tak klidně může měsíc - nebo spíš týden - před nasazením zjistit, že bude nasazovat na Hitachi CBlade, protože proto…)

S čím si bude tento, zatím hypotetický systém muset poradit? Tady to začne být trošku technické, ale pokusím se to napsat srozumitelně i pro „IT nepostižené“:-). Zatím se hovoří o jednom centrálním datovém centru (pár spolupracujících velkých počítačů), které bude zpracovávat účtenky z celé republiky. Ostatně – v Chorvatsku to tak funguje a odezva (vrácení kódu na účtenku) je kolem 0,4 s. Jenže ono to Chorvatsko má 4 miliony obyvatel, ČR jaksi 10 milionů. Počítám, že nakonec to dopadne tak, že se bude pracovat s variantou více serverů/DC, které si rozeberou zátěž z jednotlivých krajů. Ideální varianta pak bude – máme 14 krajů, v každém kraji je finanční úřad, který má server/DC (hlavní počítač/e), který bude vyřizovat všechny ty účtenky. Na jednu stranu to je fajn – zátěž z celé republiky se rozloží mezi 14 serverů, na druhou stranu budou muset být nějak propojené, aby nevydaly stejná „unikátní“ čísla na víc účtenek (ale to je snadno zvládnutelný detail). Pojďme si trošku započítat (do té techniky zabředneme až v dalším odstavci). Dle vize MinFin by to od 2016 mělo vypadat takto:

- Registrační pokladny se budou týkat cca 600 000 podnikatelů.

- To máme cca 42 800 podnikatelů na jeden kraj/server (opět zjednodušení, v Praze to bude více než v Olomouci, ale nechme to tak).

- Nejvíce účtenek generují restaurace a maloobchod (prodejny, markety), ostatní (služby, živnosti atd.) budou vykazovat řádově méně transakcí, tak je můžeme zanedbat. Dle údajů ČSÚ máme u nás:
⃰ 91 000 aktivních podnikatelů v maloobchodě (nás budou zajímat hlavně hypermarkety).
⃰ 63 000 aktivních podnikatelů v pohostinství (restaurací je u nás cca 26 000).
⃰ Takže zanedbáváme ten „zbytek“ – 446 tisíc podnikatelů.

- Zkusím odhadnout provoz v maloobchodě – řekněme prodej potravin a běžných potřeb pro domácnost. Bude to jen velice hrubý odhad, ale pro představu o části provozu by nám to mělo stačit.

- V ČR je 4 230 000 domácností (dle sčítání 2011), předpokládejme, že každá domácnost nakoupí dvakrát týdně potraviny (dle TNS AISA nakupuje domácnost - všechny nákupy - průměrně 10x za měsíc).

- Takže 4 230 000 * 2 (nákupy) / 7 (dní v týdnu) / 8 (hodin, provozní doba) / 60 (minut) = 2516 nákupů za minutu v celé ČR. Zdá se to hodně, ale ten odhad je velmi nízký – ostatně v ČR máme něco kolem 1600 velkých prodejen (z toho 300 hypermarketů) a celkem 15 800 prodejen potravin a smíšeného zboží.

- To znamená průměrně 42 nákupů za sekundu. Jenže to je průměr. Ve špičce to bude násobně více. Odhadem: 40 % všech prodejů se odehraje během jedné hodiny (špička), takže na jednu hodinu ve špičce připadá 241 536 prodejů/účtenek (134 za vteřinu).

- Kvalifikovaný odhad: nepůjde to moc jednoduše…

A teď ta nudná technická data. Těžko můžeme počítat s tím, že dodavatel vytvoří systém, který by byl kompatibilní s každou registrační pokladnou na trhu. Takže uděláme rozhraní (víte, vy vole, co je to API? :-)) pro nejrozšířenější systémy. Fajn, to není problém, prostě budou podporovány jen pokladny/terminály s nativní podporou standardu, odhaduju nějaký SOAP/XML. Což je na jednu stranu nejrozšířenější standard, na stranu druhou poněkud nenažraný co se datového toku týče. Nebudu zabíhat do podrobností (zájemcům klidně poskytnu vzorek dat), každopádně – zasílání dat na finančák a zpět bude realizováno formou XML datové věty (SOAP+data) s velikostí tak minimálně 5 kB (spíš víc) na každou účtenku. Výše jsme si vypočítali, že v zátěži dostaneme 134 účtenek/sekunda – 5,2 Mbps (megabitů za sekundu, v tom se udává rychlost sítě. Data jsou v megabajtech. Platí 1 bajt = 8 bitů, takže výpočet: 5 * 8 * 134 = 5360 kilobitů = 5,24 megabitů). A to jsou jen nákupy potravin. To bude, při rychlosti našich sítí, docela sranda. Pro teoretickou maximální zátěž se pak tyhle hodnoty ze špičky násobí obvykle 7,5x, takže musíme DC plánovat na nějakých 40 Mbps jen pro potraviny. Ale to už je jen takové teoretizování, oni si ti hospodští rádi počkají minutku na potvrzení účtenky, že ano…

To byla jen otázka rychlosti spojení, ale ono toho je mnohem, mnohem víc. Nebudu další rizika/problémy/nástrahy rozepisovat tak podrobně (ta čísla výše jsou hezká, ale obejdeme se bez nich), takže stručně (nástřel od boku, nezkoumal jsem to až tak podrobně a víc jak hodinu času tomuhle článku hlodat nehodlám věnovat):

- Konektivita – tedy připojení k internetu – pro nezanedbatelné množství obchodníků bude nutnost být stále online značnou překážkou. Pokrytí internetem (ať už kabel nebo mobilní data) je u nás poněkud nepředvídatelné – znám řadu míst, kde není ani EDGE (nejpomalejší mobilní data), ale hospoda ano. Lze řešit jako „částečně offline řešení“, ale úplně vidím tu radost hospodského, co musí každý večer vyšplhat na nejbližší kopec a odesílat účtenky… Nehledě na to, že jde o další investici (pro mnohé zbytečnou).

- Uživatelská přívětivost – systém bude muset být extrémně jednoduchý, aby jej byl schopen ovládat každý (nereálné). Vysokoškolsky vzdělaným doktorům trvalo jak dlouho, než pochopili elektronické recepty? Ano, může to být řešeno nějakou blbovzdornou pokladnou, ale to nebude fungovat např. u řemeslníků – znám řadu šikovných řemeslníků, machrů ve svém oboru, ale mnoho z nich nezvládne ani poslat SMS a na počítač se dívá s hrůzou srovnatelnou s utrpením pedofila v domově důchodců…

- Odezva – jak rychle to zvládne poslat zpět potvrzení. No, pokud bude systém skutečně robustní (čti: drahý, několikrát jištěný, odpovídající pomalu standardům NASA), pak by mohl zvládnout cokoliv, jenže známe to – někdo od stolu na ministerstvu začne myslet, napíše nereálné podmínky a dodavatel to „nějak očurá“, aby to splnilo požadavky úředníka, ale reálné požadavky necháme stranou (stejné to bylo u registru vozidel a dalších veselých zakázek).

- Práce s daty na minfin – nedokážu ani odhadnout, kolik dat se bude muset skladovat a analyzovat (s restauracemi bych to ještě odhadl, ale jak v tom budou i hypermarkety, tak se dostáváme za hranice reálných spekulací, prostě nevím). Ale bude to opravdu hodně dat…

- Ověřování – krása myšlenky prý spočívá v tom, že tržby budou pod kontrolou. No nevím, to by musel osobně a neočekávaně finančák kontrolovat zůstatek v kase, ne? Jinak jsme tam, kde teď: „Šéfiku, na fakturu nebo levnějš?“ Ono se ale vlastně počítá, že zákazníci budou hlásit, že nedostali účtenku (a nemůžou se tak zúčastnit slosování, že jo?). No, bonzáctví má u nás takovou pěknou tradici… (držím se, držím, nebudu odbíhat od technických záležitostí).

- Loterie – nehledě na to, že slosování došlých stvrzenek je další zátěž na už tak přebujelou a i tak nestíhající státní správu, tak úplně vidím „chytrého českého človíčka“, jak na pokladně rozděluje nákup po jednotlivých položkách, aby měl více účtenek (a vyšší šanci vyhrát)…

- Spolehlivost systému – státní zakázky většinou mají ve SLA (dohoda o úrovni služeb, neřešte) nastavenou garantovanou spolehlivost 99,99 % (jasně, na papíře, v reálu to známe), to znamená maximální výpadek na 52 minut za rok. Ze zkušenosti ale víme, že to nebude minuta pravidelně 1x týdně, ale spíš jednou 30 minut a podruhé 20 (a ještě nám zbylo!). Nebo i víc, známe to. Na tuto dobu se zastaví veškerý prodej v ČR (jasně, už přeháním, ale proč se nezasmát).

Mohl bych pokračovat dál, ale asi není potřeba (ostatně ani mi za to neplatí). Ať jsou záměry MinFin jakkoliv bohulibé (no, nejsou, ale slíbil jsem, že se budu držet jen technické stránky věci), není absolutně reálné spustit funkční systém do roku 2016. I do 2017 by to byl zázrak. Kombinace technických problémů, legislativních překážek a hlavně aktuálního stavu ICT státní správy prostě nedovoluje rozjet projekt takovéhoto rozsahu v termínu, který určuje projednávaný návrh zákona.

Jasně, stále tu je varianta, kdy „se to nějak připraví a nechá běžet“, ale v tom případě nás čekají i v restauracích „fronty jak na banány“, protože ten systém bude pravidelně kolabovat a jeho odezva (doručení unikátního identifikátoru na účtenku) se bude počítat v minutách, ne v milisekundách (jak by to bylo ideální).

Závěr – termín je absolutně nereálný. Funkčnost chorvatského modelu v ČR pochybná. Technologická realizace extrémně náročná. Nutnost přizpůsobit se bude pro hodně podnikatelů nepříjemná až likvidační. Těžko se vybere na daních tolik, kolik se investuje do tohoto systému. A příští vláda to stejně zruší…

Není to dobrý nápad.

Ano, ono to nakonec půjde zrealizovat. Trošku se zredukují vládní očekávání, naddimenzuje se to ve stylu Chorvatsko krát čtyři, pak se to začne zavádět, dají se odklady a po čase se to zruší…

Převzato z Jurica.info se souhlasem autora