Je otázkou, jak to doopravdy bylo - s tím s Vámi souhlasím.
Ale pokud vědomě vytvářel fiktivní účtenky, tak to je skoro, jako kdyby fiktivně vytvářel falešné doklady (řidičáky, občanky), pak by měla být pokuta likvidační + ukončení podnikání + obvinění na § 209 tr. zákona, což je podvod.
Otazka jak to doopravdy bylo
Přesně tak. Ten kód je guid (UUID) což je pseudonáhodně jedinečný identifikátor vygenerovaný v daném čase. Celé EET je vymyšleno značně amatérsky, ten protokol totiž vůbec nebere v úvahu možnost chyby komunikace. Jejich řešení opakování zaslání transakce při chybě je z principu nefuknční a přiznali to až na nějakém videu z konference https://youtu.be/DgFH6tJhc6g?t=2530 v oficiální dokumentaci je stále ta nesmyslná varianta. Testovací a provozní rozhraní se navíc v této situaci chová zcela odlišně (nedetekuje duplicity zmíněné v tom videozáznamu), takže si to jako dodavatel software ani nemůžete odzkoušet. Je klidně možné, že ten systém byl jen velmi špatně napsaný a při první chybě neodesílal transakce opakovaně (o tom že jde o opakované přijetí se právě na straně klienta nedozvíte, EET server to pak ignoruje).
Pokud to ale udělali opravdu záměrně tak jsou dost naivní.
Tak EET funguje ( procesně ) , v podstatě od spuštění nebyl zaznamenám výrazný výpadek, pokud by skutečně šlo o chybu SW u EET poklady nebo k poruše na samotné EET pokladně, má možnost toto poplatník dokázat ve správním řízení ( mj. prokazatelná porucha EET pokladny či výpadek on line spojení je přímo v metodickém pokynu GFŘ označen za důvod liberační
http://www.etrzby.cz/assets/cs/prilohy/situace-pri-evidovani-trzeb.pdf
) případně škodu ( finanční postih od správce daně ) vymáhat po prodejci EET pokladny.
pokud vědomě kradl tak to asi není naivitou ale snahou daňově si nezákonně vydělat a tady není asi prostor pro nějaké diskuse. Něco jiného je pokud dají pokutu 30 tis. trafikantce v důchodu za 1 pochybení a to ještě ověřitelně ten den normálně a kontinuálně EET účtenky reportovala ( to je šikana a nesmyslná sankce ) a něco jiného je uvedený případ.
Předřečník píše o chybě komunikace, tedy ani EET systému, ani kasy. A k chybě komunikace stačí jen horší signál a hned se každá účtenka může přeposílat i několikrát, než se ji podaří zaregistrovat. A pokud protokoly ošetření chyb nejsou domyšlené nebo jsou nejednoznačně popsané, tak je klidně možné, že to, co kasa považovala za úspěšně zaregistrovanou účteniku, systém EET ve skutečnosti nezaregistroval.
Poplatník má ovšem právo ( a v případě selhání spojení či poruchy EET pokladny povinnost ) , si kdykoliv zkontrolovat či nechat poslat výpis z registrace EET od FÚ. Účtenka se může v případě výpadku signálu pokoušet o přeposlání i několikrát a pokud se jí to podaří obdrží FIK, pokud se nepodaří on-line spojení tz. je překročena mezní doba odezvy, pak se tiskne pouze PKP a BKP.
Dále platí že : Tržbu, ke které nebyla přijata potvrzovací zpráva s FIK, je třeba zaevidovat
bezodkladně po pominutí příčiny, nejpozději do 48 hodin od jejího uskutečnění. Každá taková tržba se
eviduje zvlášť. Odesílání dat může být zajištěno automaticky softwarem v pokladním zařízení. Odesílání se opakuje až do obdržení FIK.
V popisovaném případě, však podle Generálního finančního ředitelství dlouhodobě a ve velkém rozsahu porušoval zákon o evidenci tržeb. Během dvouměsíční kontrolní akce u něj kontroloři odhalili 4000 falešných účtenek.
4000 falešných účtenek !( pravděpodobně upravený SW EET pokladny tak, by tiskl falešné FIK kódy napodobující ověřovací kód z FÚ ) - co kromě krácení daně z příjmu v tom vidíte za konspirační teorie ?
Na jednom starším serveru byl problém s časy přijetí tržby. Na serveru se totiž čas rozchází za den i o půl minuty, což mohlo být starou baterií na desce. Protože jsem modul doprogramovávala, nikde v dokumentaci MFČR neuvádělo, že časy přijetí FIK musí být absolutně přesné, jinak sice tržbu odešlete, ale zákazníkovi dáte neplatný FIK, který do účtenkovky nikdy nezaregistruje. A víte co? V kontrolním seznamu po přihlášení si ověříte, že platby odešly, ale co s těmi neplatnými FIKy, když se systém rozejde až o minutu? A to ani nemusí být o minutu, protože zákazníkovi prodáte zboží v 9:40:45 a čas máte 9:41:00 a to už je jiný čas platný pro jiný FIK. Plus ani neberu v potaz nějakou nanic odezvu při slabé wifi někde v obchodním centru. Zjistili jsme to až po necelém roce, kdy si stěžovali zákazníci a helpdesk MFČR stál za velký kulový, nedokázali nám odpovědět na otázku, proč tam ty tržby mají, ale zákazníci nemohou FIKy zadat do účtenkovky...Nasadila jsem pak sice NTP, ale i tak to nemusí být úplně spolehlivé obzvláště vůči nárokům, které MFČR žádá po všech povinných subjektech.
Na výše uvedeném příkladu lze snadno dovodit, že neplatné FIKy mohou být jen za podmínek špatného času i více jak v 50%. Jenomže to nikdo nemá možnost finančáku nikdy prokázat, protože jsou šifrovací klíče pro generování FIKů neveřejné.
Že by někdo naprogramoval software, aby jednu polovinu odeslal OK a druhou polovinu byly FIKy chybné, to se mi ani věřit nechce.
To ale s loterií účtenkovka nemá nic společného, že se rozejde čas prodeje, s odezvou na FIK, není žádná anomálie, pokud není možná okamžitá odezva, odeslání se opakuje dokud nedojde potvrzovací FIK z FÚ a nebo se překročí mezní doba odezvy, pak účtenka vyjede bez FIK a musíte jí odeslat znovu do 48 hodin. Jestli to lze poté zadat do loterie nebo ne nevím (já to nehraju ) , ale rozhodně i později obdržený FIK z FÚ a to klidně za 20 hodin po opětovném reportu tržby, je FIK jedinečný a platný.
Navíc každá chyba reportu či selhání spojení je okamžitě detekováno, asi to nebudu vypisovat vše, základní princip detekce je : Každou přijatou datovou zprávu zkontroluje společné technické zařízení správce daně (dále systém EET) pomocí sady kritických kontrol. Pokud datová zpráva obsahuje kritické chyby, systém EET odpoví chybovou zprávou s kódem chyby a stručným popisem chyby, ale nezašle FIK. Zprávu s kritickou chybou systém EET neukládá, tržba tímto není zaevidována. Popis a výčet kritických chyb je uveden v dokumentu Formát a struktura údajů o evidované tržbě v kapitole Kritické kontroly (kritické chyby) a v kapitole Seznam chybových kódů a chybových zpráv. Kritická chyba v datové zprávě (s výjimkou chyb s kódem -1, 0 a potenciálně i 8) znamená, že pokladní zařízení nepracuje zcela korektně. Na otestovaném a správně nastaveném pokladním SW a HW by chyby s kódy 2 až 7 neměly nastat.
více zde ( psát to vše asi nemá smysl ) http://www.etrzby.cz/cs/nejcastejsi-dotazy-vyvojaru
Takže znovu, bavíme se zde o 2 možných scénářích, buď měl poplatník nevědomky chybně nastaven pokladní SW nebo poruchu samotné pokladny ( HW) , pak předpokládám že to lze dokázat ( asi tu pokladnu někde zakoupil a nechal si to nainstalovat a i kdyby to měl bez instalace, tak pokud dodržel postup instalace certifikátu a pokladna přesto nefunguje ) má možnost i toto prokázat a to nejlépe posudkem od výrobce nebo otestováním odeslání " testovacích tržeb generovaných v nějakém chybném módu - což lze opět otestovat IT vývojářem pokladny " v takovém případě, by ustál onu sankci ( jednak to je jasně uvedený liberační důvod z GFŘ ) a jednak i v případě soudního sporu - nevím čím by chtěla finanční správa argumentovat ? Že si poplatník - např. restauratér řádně zajistil certifikát, řádně zakoupil pokladnu, řádně si to nechal nainstalovat a protože se za rok ukázalo že mu SW či HW nefunguje a tiskne " něco jako FIK mimo evidenci FÚ a nebo tak, že k evidenci na straně FÚ nedochází ) tak za to bude postihován ? to asi u soudu nepůjde.
A nebo prostě krátil tržby, nemusí vůbec nic přeprogramovávat, ty podvody jsou celkem známé, prostě si např. ( technik je " hafo" ) pořídíte poklady 2, na jedné oficiálně sem tam vytisknete oficiální FIK z FÚ no a druhá je falzifikát - je to pouze hračka s tiskárnou co tiskne pořád dokola 3-4 přednastavené napodobeniny změti čísel a písmen aby to vypadalo jako FIK kód.
Já tady v žádném případě nehodnotím ani jednu možnost, ale fakta jsou zatím taková že bylo detekováno 4000 falešných účtenek, po kontrolách více než 2 měsíců, poplatník dostal sankci 270 tis. a ?? odvolal se ?, vysvětlil něco ? předložil nějaký posudek o poruše pokladny ? předložil nějaké testování o tom že mu generují chybové kódy k účtenkám ?
já nevím, ale žádná dostupná informace o tom není,