|

ps2013-033-02-009-009.ana

Český parlamentní korpus, Poslanecká sněmovna, 2015-10-07 ps2013-033-02-009-009 [ParCzech.ana]

Agenda Item Title

9. Vládní návrh zákona o evidenci tržeb /sněmovní tisk 513/ - druhé čtení

Date2015-10-07
Meetingps2013/033
Agenda Itemps2013/033/009
Sourcehttps://www.psp.cz/eknih/2013ps/stenprot/033schuz/s033088.htm
Javascript seems to be turned off, or there was a communication error. Turn on Javascript for more display options.
index   18 < Page 19 > 20
Například znalost PIN k bankovní kartě ještě neznamená, že dotyčný si smí vybrat peníze, i když není vlastníkem této karty. Rovněž je otázkou, a ta tu padla, proč předkladatel nezařadil evidenci tržeb do systému eGovernmentu, kde se přímo nabízí jako identifikační údaj AIFO, který by zde byl doplněn o certifikát. Nevyjasněný je vůbec vztah k DIČ. Důvodová zpráva o tom zcela mlčí, v odůvodnění v § 10 jen opisuje normativní text bez pokusu jej opravdu odůvodnit. Ne zcela vyjasněný je vztah k bezpečnostnímu kódu poplatníka podle § 12, který je definován, že je jedinečným kódovacím algoritmem poplatníka vygenerované označení, které jako výstup konkrétních vstupů v podobě údajů o evidované tržbě a poplatníkovi, který ji uskutečnil, identifikuje poplatníka, který účtenku vydal, a uskutečněnou tržbu s vydanou účtenkou. Ani v důvodové zprávě ani v tezích prováděcích předpisů k tomu nejsou žádné další podrobnosti. A je přitom více než pochybné, že BKP je zveřejňován, a to na účtence, což říká § 13. Fiskální identifikační kód. Zatímco v § 13 č. 2 písm. c) je FIK vágně vymezen jako jednoznačný identifikátor vytvořený správcem daně potvrzující zaevidování tržby, teprve důvodová zpráva stanoví: "Správce daně provede na základě údajů povinně zaslaných poplatníkem okamžitou evidenci tržby, přidělí jí unikátní fiskální identifikační kód, pod kterým tržbu nadále eviduje. Přidělený fiskální identifikační kód zašle zpětně poplatníkovi, který jej vytiskne na účtenku, již je povinen vydat původci realizované tržby." Je pak nejasné, proč FIK je nazván tak vágně a ne třeba "evidenční číslo tržby". Je otázkou, zda to takto může fungovat, protože pokud dojde k výpadku internetu, je nutné náhradní řešení podle § 14, tam je to popsané dobře, ale osnova stanoví: "nejpozději však do 48 hodin od uskutečnění tržby", což však nebude možné. Navíc je sporné, zda je skutečně nezbytná komunikace přímo se správcem daně; zda nemůže poplatník tržbu identifikovat sám a proč je nezbytná dvojí identifikace: pomocí BKP a FIK. S přemírou identifikátorů souvisí údaj o pořadí účtenky, identifikace provozovny a pokladního místa. Proč to není součástí BKP? Důvodová zpráva zcela mlčí. Za osmé, a už se blížím k závěru: povinnost převzít účtenku a informační povinnost o tom. Lze mít za to, že toto břemeno je dalším výrazem paternalistického státu. Předkladatel by měl ve věcném záměru vyhodnotit alternativní řešení. Rovněž by měl vyhodnotit smysluplnost této povinnosti, když nebude nijak vymáhána. S tím souvisí i další zatěžující povinnost v § 20, že je podnikatel povinen informovat zákazníky o tom, že mají povinnost převzít účtenku. Podnikání neslouží k informování o oprávněních a povinnostech, které má každý ze zákona znát. Ověření účtenky. Tato právní norma je jen načrtnuta a právní úprava zde zcela postrádá podrobnosti, jak by měla být realizována. Důvodová zpráva k tomuto zákonu o tom zcela mlčí. Za desáté, zjednodušený režim. Osnova v § 22 nestanoví jiné kritérium pro povolení zjednodušeného režimu než že standardní režim "nelze spravedlivě požadovat". To je svévole a porušení právního státu. Kritéria se pokouší vymezit důvodová zpráva. Patří však do normativního textu, nikoli do jeho vysvětlení. A za jedenácté, účtenková loterie. Důvodová zpráva nijak neobjasňuje smysluplnost této právní normy. Na hru, které se lze zúčastnit pouze na základě zaslání účtenek a jejímž pořadatelem je Česká republika, se nepoužije zákon upravující hazardní hry? Jakou veřejnoprávní regulací se tedy účtenková loterie bude řídit? Děkuji za pozornost. Místopředseda PSP Petr GazdíkDěkuji panu poslanci Radimu Holečkovi za jeho příspěvek do obecné rozpravy. Dalším řádně přihlášeným je pan poslanec Vladimír Koníček. Prosím, pane poslanče, máte slovo. Poslanec Vladimír KoníčekVážený pane předsedající, vážené kolegyně, kolegové, Chtěl bych jenom na úvod opravit některé údaje, které zazněly tady v rozpravě. A to pan ministr říkal, že studie BDO stála nějaký 190 tisíc. Nám na kontrolní výbor zaslal přehled nebo seznam uskutečněných nákladů k 15. 9. 2015 a tam je u položky Konzulace BDO částka 241 879 korun. Placeno jednou fakturou. Co se týká... Bez DPH, pane ministře, kdyby to bylo, tak to by vyšlo 190 tis. na nějakých 229 tis., takže furt tam ještě něco falíruje. Pan Stanjura tady mluvil o nějakém píárku, tam jsme dostali informaci, že Marek Hlavica dostal vyplaceno 1 253 802 korun k tomu datu. A celkové náklady k datu 15. 9. na elektronické tržby jsou 4 718 036,66 koruny. A teď bych chtěl ještě něco dalšího. V prvním čtení zákona o elektronické evidenci tržeb nám pan ministr předvedl velké účtenky, na kterých ovšem chyběla spousta údajů. Před druhým čtením vydal vlastním nákladem brožurku, o které nás tady od tohoto pultíku ujišťoval, že tam už je to všechno správně. Bohužel není. Minule jsem tady vzpomněl, že v zasílaných údajích chybí například takový zásadní údaj, jako je základ daně, jak to vyžaduje § 19 odstavec 2 písmeno d). Také podpisový kód poplatníka byste mezi zasílanými údaji marně hledali. Tím myslím v té brožurce. Naopak je tam navíc fiskální identifikační kód. Ten ve skutečnosti opravdu není odesílán na finanční úřad, tento kód se dozví prodejce až od finančního úřadu jako potvrzení zaevidované platby. Bezpečnostní kód poplatníka uvedený v brožurce neodpovídá návrhu vyhlášky, která nám byla předložena spolu s návrhem zákona. Podle ní je bezpečnostní kód poplatníka tvořen transformací podpisového kódu poplatníka dle matematické funkce SHA1. Výsledkem této matematické funkce je řetězec 20 osmibitových znaků. Z nich jsou ale některé netisknutelné, a proto jste pro vytištění provedli asi převod do tisknutelné verze znaků Base64. Ta převádí tři osmibitové znaky na čtyři šestibitové. Vámi předložený bezpečnostní kód poplatníka má ale jen 27 znaků, jeden prostě chybí, protože výsledek převodu má mít n krát 4 znaky, tedy 28. A jenom pro fajnšmekry, kód, který je uvedený na účtence, není možno reálně vygenerovat, protože nemá-li zpráva, ta původní, 20 znaků, n-krát tři znaky, doplní se znakem =, pokud to uděláte, tak nikdy nemůžete dostat na 27. místě znak 5, protože ten má v kódování Base64 nejnižší bity 01, zatímco bity znaku =, které připadají na ten 27. znak, jsou 00. Tož tak, pane ministře. (Oživení v sále, potlesk zleva.)A ještě bych měl jednu otázku k technickému řešení. Ve studii BDO je v části Kvantitativní odhad objemu transakcí uvedeno: Propočtem na kapacitu zpracovaných transakcí systémem a s ohledem na špičky je určena cílová hodnota výkonnosti systému na 10 tisíc transakcí za sekundu. S touto hodnotou je potřebné v projektu pracovat a projektovat technické a jiné výkonnostní kapacity systémů. - To má pan Stajnura v té studii, kterou dneska obdržel. Protože nemáme na kontrolním výboru dosud smlouvu o zajištění provozu informačního systému elektronické evidence tržeb, byť jsme o ni opakovaně žádali, tak ocituji jenom z výzvy k zajištění provozu, to je taková zadávací dokumentace. A tam je uvedena špičková požadovaná propustnost přijímaných účtenek 4000 kusů za sekundu. Tedy méně než poloviční. I ostatní údaje jsou v obdobných relacích. Ptám se, pane ministře, proč jsou ty požadované parametry systému v zadávací dokumentaci tak podhodnoceny? Na mě to dělá dojem, že se požadované parametry podstřelí, aby v průběhu realizace byly proplaceny navýšené náklady, protože systém je přece potřeba posílit. Děkuji za odpověď. (Potlesk poslanců KSČM a ČSSD.)

Download XML • Download text • Dependencies • Wavesurfer • Named Entities