Nejčastější dotazy vývojářů

Otázky a odpovědi k evidenci tržeb.

  • Finální technické řešení včetně datového rozhraní bylo zveřejněno na portále správce daně dne 11. května 2016, a to v sekci pro IT/Vývojáři formou technického manuálu. Dne 13. června 2016 bylo spuštěno testovací prostředí pro vývoj SW třetích stran.

    • Fiskální identifikační kód (FIK) je unikátní kód generovaný a zasílaný systémem Finanční správy, kterým potvrzuje přijetí datové zprávy o evidované tržbě.
    • Bezpečnostní kód poplatníka (BKP) je kód generovaný automaticky pokladním zařízením podnikatele, který prokazuje jednoznačnou vazbu mezi účtenkou a podnikatelem, který ji vydal.
    • Podpisový kód poplatníka (PKP) je pomocným ochranným prvkem, který umožňuje kontrolu integrity a prokazuje odpovědnost podnikatele za vystavení účtenky. Je generován automaticky pokladním zařízením podnikatele, na účtenku je však povinně uváděn pouze v případech, kdy na účtenku nelze uvést z objektivních důvodů FIK (např. při výpadku spojení nebo při evidenci tržeb ve zjednodušeném režimu).

    Způsob tvorby BKP a PKP stanovilo Ministerstvo financí vyhláškou č. 269/2016 Sb.

  • Certifikát slouží k jednoznačné identifikaci při zasílání údajů o evidované tržbě datovými zprávami. Správce daně umožní podnikateli získat prostřednictvím portálu jeden nebo více certifikátů k evidenci tržeb.

  • Volba počtu a způsobu využití certifikátů je ponechána zcela na uvážení podnikatele evidujícího tržby. Je možné využít jeden certifikát na zasílání údajů o evidovaných tržbách v rámci celé činnosti podnikatele, případně používat různé certifikáty dle jednotlivých provozoven nebo koncových zařízení.

  • Správce daně je povinen umožnit podnikateli získat certifikát prostřednictvím technického zařízení, kterým se rozumí portál správce daně. Přihlášený podnikatel si může přímo na portále správce daně vygenerovat certifikát pro evidenci tržeb. Postup instalace certifikátů se bude odvíjet od zvoleného typu využitého zařízení (pokladna, počítač, tablet, chytrý telefon…) a příslušného operačního systému.

  • Ne. Finanční správa ČR ani Ministerstvo financí ČR nebude certifikovat softwary, které zajistí zasílání dat z pokladen. Jednalo by se o zbytečnou byrokracii vůči uživatelům pokladních systémů. Je to podobné jako u účetních programů. Také nejsou certifikovány a výrobce ručí za jejich funkcionalitu, která musí být v souladu se zákony.

  • On-line evidence tržeb

    1. Podnikatel zašle datovou zprávu o transakci ve formátu XML do systému Finanční správy.
    2. Ze systému Finanční správy je zasláno potvrzení o přijetí s fiskálním identifikačním kódem.
    3. Podnikatel vystaví účtenku (včetně fiskálního identifikačního kódu), kterou předá zákazníkovi.
    4. Zákazník obdrží účtenku.
    5. Zákazník si může ověřit svoji účtenku na Daňovém portále, podnikatel si ověří tržby evidované pod jeho jménem ve webové aplikaci Elektronická evidence tržeb.

  • Údaji o evidované tržbě zasílaných datovou zprávou jsou vždy:

    • daňové identifikační číslo poplatníka (DIČ),
    • označení provozovny, ve které je tržba uskutečněna,
    • označení pokladního zařízení, na kterém je tržba evidována,
    • pořadové číslo účtenky,
    • datum a čas přijetí tržby nebo vystavení účtenky, pokud je vystavena dříve,
    • celková částka tržby,
    • bezpečnostní kód poplatníka (BKP),
    • podpisový kód poplatníka (PKP),
    • údaj, zda je tržba evidována v běžném nebo zjednodušeném režimu.

    Údaji o evidované tržbě zasílaných datovou zprávou jsou při naplnění konkrétních okolností také:

    • celková částka plateb určených k následnému čerpání,
    • celková částka plateb, které jsou následným čerpáním nebo zúčtováním platby,
    • daňové identifikační číslo poplatníka (DIČ), který pověřil evidováním této tržby poplatníka, který tržbu eviduje,
    • základ daně z přidané hodnoty a daň podle sazeb daně z přidané hodnoty,
    • celková částka v režimu daně z přidané hodnoty pro cestovní službu,
    • celková částka v režimu daně z přidané hodnoty pro prodej použitého zboží.

  • Podnikatel je na účtence povinen uvádět:

    • fiskální identifikační kód (FIK),
    • označení provozovny, ve které je tržba uskutečněna,
    • označení pokladního zařízení, na kterém je tržba evidována,
    • pořadové číslo účtenky,
    • datum a čas přijetí tržby nebo vystavení účtenky, pokud je vystavena dříve,
    • celkovou částku tržby,
    • bezpečnostní kód poplatníka (BKP),
    • údaj, zda je tržba evidována v běžném nebo zjednodušeném režimu.

    Nemá-li poplatník povinnost uvádět na účtence fiskální identifikační kód - FIK, je povinen na účtence uvádět svůj podpisový kód PKP. Jedná se zejména o případy výpadku spojení nebo evidence tržeb ve zjednodušeném režimu.

    V důsledku zrušení ustanovení § 20 odst. 1 písm. b) a odst. 2 ZoET nálezem Ústavního soudu ze dne 12. prosince 2017 sp. zn. Pl. ÚS 26/16 s účinností od 1. 3. 2018 není povinnou náležitostí účtenky daňové identifikační číslo (DIČ) poplatníka resp. DIČ poplatníka, který pověřil evidováním této tržby poplatníka, který tržbu eviduje. Povinnost zasílat údaj o DIČ poplatníka a DIČ pověřujícího poplatníka datovou zprávou dle § 19 odst. 1 písm. a) a odst. 2 písm. c) ZoET zůstává zachována. Dále upozorňujeme, že tímto rozhodnutím ÚS se nic nemění ve vztahu k DPH a uvádění DIČ (rodného čísla) na daňových dokladech (§ 29 ZDPH). Pokud má plátce DPH povinnost vystavit daňový doklad a vystavoval v těchto případech společný doklad pro EET a daňový doklad plátce DPH, bude muset nadále své DIČ na tomto dokladu uvádět, nebo bude muset doklady vystavit dva.

  • Doba odezvy je časový úsek mezi pokusem o odeslání údajů o evidované tržbě z pokladního zařízení podnikatele a přijetím potvrzovacího kódu (FIK) ze systému Finanční správy na pokladním zařízení podnikatele. Mezní dobu odezvy, po jejímž uplynutí lze zákazníkovi vystavit účtenku bez fiskálního identifikačního kódu (FIK), nastavuje sám podnikatel, a to s ohledem na kvalitu připojení internetu a druh vykonávané činnosti. Vždy však musí být delší než 2 sekundy. Pokud při evidování tržby dojde k překročení mezní doby odezvy, podnikatel zašle správci daně údaje o evidované tržbě datovou zprávou nejpozději do 48 hodin od uskutečnění evidované tržby.

  • Provádí-li se storno nebo oprava tržby, o níž byly údaje již zaslány do systému Finanční správy, postupuje podnikatel obdobně jako při evidenci tržby s tím rozdílem, že tuto tržbu zaeviduje jako zápornou (mínusovou položku). Postup se vztahuje na případy vrácení zboží bez uvedení důvodu, při vyřízení reklamace, u omylem zaevidované tržby nebo na případy, kdy byly údaje o evidované tržbě zaslány správci daně před přijetím tržby a zákazník nakonec zboží nezaplatil (nejčastěji půjde o zasílání zboží internetovými obchody na dobírku a následné nepřevzetí zboží). Provedené storno není z technického hlediska vázáno na původně zaslanou datovou zprávu (resp. vydanou účtenku).

  • Může se stát, že je třeba tržbu zaslat opakovaně (například proto, že jste neobdrželi FIK). Při opakovaném odeslání tržby je třeba v datové zprávě:

    • změnit v oblasti <Hlavicka>
      • UUID zprávy,
      • datum a čas odeslání zprávy a
      • příznak prvního zaslání a
    • opakovat přesně stejné údaje v oblasti <Data> a <KontrolniKody>.

    Vlivem odlišných údajů v oblasti <Hlavicka> je třeba celou zprávu znovu podepsat.

  • Pokud je přijata datová zpráva se stejnými hodnotami základních datových položek jako některá již dříve přijatá zpráva, bude nová zpráva považována za zaslání údajů o téže evidované tržbě. Taková tržba bude označena jako duplicitní a nebude zahrnuta do součtů tržeb na portálu. Základní datové položky jsou: DIČ poplatníka, Označení provozovny, Označení pokladního zařízení, Pořadové číslo účtenky, Datum a čas přijetí tržby a Celková částka tržby. Pokud je přijata datová zpráva, ve které se liší i jen jediná hodnota u základních datových položek vůči dříve přijatým zprávám, bude tato nová zpráva považována za zaslání údajů o další (tedy jiné) evidované tržbě.
  • V datové zprávě i na vydané účtence musí být uvedeno označení (číslo) provozovny. Toto číslo přidělí provozovně systém Finanční správy, když poplatník přihlášený do webové aplikace Elektronická evidence tržeb na Daňovém portálu zadává údaje o svých provozovnách. Poplatník si jej nemůže určit sám, ani využít existující identifikační číslo provozovny (IČP) přidělené Živnostenským úřadem.
    Provozovny jsou číslovány prostým pořadovým číslem (1, 2, 3…), ale za toto číslo se přidává ještě jedna technická číslice (obvykle se přidává jednička, ale může být i jiná). Čísla provozoven pak tvoří nesouvislou řadu (např. 11, 21, 31, 41, 52), ale jejich pořadí je zachováno podle toho, jak byly provozovny zadávány do systému.

  • Pokud nebude označení provozovny odpovídat formálním požadavkům (maximálně šestimístná číslice), bude zpráva odmítnuta a zaslána odpověď s kritickou chybou (3 - XML zprava nevyhovela kontrole XML schematu).

    Pokud bude přijata datová zpráva o tržbě s číslem provozovny, které je formálně správné, ale neodpovídá žádné provozovně uvedeného poplatníka:

    • systém zašle odpovědní (potvrzovací) zprávu s FIK,
    • údaje budou uloženy se zaslaným číslem provozovny, která bude mít název „Neexistující provozovna“,
    • údaje budou dostupné v detailních údajích o tržbách,
    • zpráva bude interně označena chybou „Neexistující provozovna“.

    Chybně uváděné číslo provozovny může iniciovat kontrolu plnění povinností zákona o evidenci tržeb.

  • 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.

  • Pokud kritická chyba nastane, je nutné zjistit příčinu a zajistit co nejrychleji její odstranění. Při výskytu kritické chyby je možné vystavovat zákazníkům po nezbytně nutnou dobu účtenky bez FIK, pouze s BKP a PKP. Bezodkladně po pominutí příčiny, způsobující výskyt kritické chyby, je třeba tržby dodatečně zaevidovat, a to každou přijatou tržbu zvlášť. Konkrétní postup záleží na typu chyby – viz dále.

  • Jedná se o stav, kdy z technických důvodů na straně systému EET dočasně není možné datovou zprávu zpracovat. V tomto případě má pokladní zařízení pokračovat v pokusech o opakované zaslání stejně, jako když nepřijde odpověď do nastavené mezní doby odezvy. Odesílání je třeba opakovat, až do přijetí odpovědi.

  • Jedná se o potvrzení o úspěšném zaslání datové zprávy v ověřovacím módu. Doručenou datovou zprávu v takovém případě systém EET neukládá. Pokud poplatník zaslal datovou zprávu záměrně v ověřovacím módu, je vše v pořádku. Pokud datovou zprávu nezaslal v ověřovacím módu záměrně, je vhodné zkontrolovat a případně opravit hodnotu zadanou do položky „overeni“ v datové zprávě a poté ji zaslat znovu.

    Pozn.: Když má položka „overeni“ hodnotu „true“ nebo „1“ znamená to ověřovací mód. Hodnoty „false“ nebo „0“ znamenají ostrý mód. Pokud položka „overeni“ ve zprávě není vůbec uvedena, považuje se datová zpráva za zaslanou v ostrém módu.

  • Kritická chyba s kódem 2 nastává, pokud datová zpráva XML nemá správnou strukturu a není možné ji správně načíst, např. není v kódování UTF-8. Pokud má datová zpráva nesprávnou strukturu, systém EET ji odmítne a odpoví chybovou zprávou s kódem chyby 2. Je třeba zajistit úpravu kódování nebo struktury datové zprávy a pak zprávu zaslat znovu.

  • Kritická chyba s kódem 3 nastává, pokud není dodrženo XML schéma podle dokumentu Formát a struktura údajů o evidované tržbě v kapitole Datová zpráva evidované tržby. V elementu <Trzba> musí být uvedeny všechny povinné položky a naplněné hodnotami, musí být dodrženy formáty hodnot ve všech uvedených položkách a dodržena předepsaná struktura datové zprávy. Pokud není dodrženo XML schéma, systém EET ji odmítne a odpoví chybovou zprávou s kódem chyby 3.

    Častou chybou je například hodnota DIČ uvedená bez písmen „CZ“ na počátku, nebo nedodržený přesný formát data a času. Je třeba zajistit úpravu datové zprávy a pak ji zaslat znovu.

  • Kritická chyba s kódem 4 nastává, pokud datová zpráva s údaji o evidované tržbě není korektně podepsána platným certifikátem, vydaným určeným vydavatelem (certifikační autoritou CA EET). Systém EET při příjmu zprávy provádí:

    • kontrolu vydavatele certifikátu,
    • kontrolu platnosti certifikátu včetně kontroly, zda certifikát nebyl revokován (nevyskytuje se v CRL certifikační autority, které jsou aktuálně technickému zařízení dostupné),
    • kontrolu správnosti podpisu.

    V případě, že podpis datové zprávy nesplní některé z kontrolních kritérií, systém EET ji odmítne a odpoví chybovou zprávou s kódem chyby 4. Je třeba zjistit příčinu (například exspirovaný certifikát, nebo je v produkčním prostředí použit certifikát vydaný pro Playground), odstranit ji a pak datovou zprávu zaslat znovu.

  • BKP je generován definovaným postupem z PKP na straně pokladního zařízení. Kritická chyba s kódem 5 nastává, pokud kontrola zjistí nesoulad mezi BKP a PKP. Pak systém EET datovou zprávu odmítne a odpoví chybovou zprávou s kódem chyby 5. Je třeba prověřit způsob generování BKP, upravit, a poté datovou zprávu zaslat znovu.
    Pozn.: Způsob generování a popis PKP i BKP je uveden v dokumentu Formát a struktura údajů o evidované tržbě v kapitole Kontrolní kódy PKP a BKP a dále ve vyhlášce č. 269/2016 Sb., o způsobu tvorby podpisového kódu poplatníka a bezpečnostního kódu poplatníka.

  • Pokud DIČ poplatníka nemá správnou strukturu, systém EET datovou zprávu odmítne a odpoví chybovou zprávou s kódem chyby 6. Je třeba překontrolovat zadané DIČ poplatníka, opravit a poté zaslat datovou zprávu znovu.

  • Maximální velikost datové zprávy (včetně SOAP obálky) je stanovena na 12 kB. Pokud datová zpráva přesáhne tuto velikost, systém EET ji odmítne a odpoví chybovou zprávou s kódem chyby 7. Datová zpráva přesahující stanovenou velikost však může být vyhodnocena i jako útok a v takovém případě nemusí být odeslána žádná odpověď. Je třeba překontrolovat velikost zasílané datové zprávy, upravit ji a poté zaslat znovu.

  • Kritická chyba s kódem 8 nastává, pokud se vyskytne jiná kritická chyba, která může být v datové zprávě nebo na straně systému EET. Datovou zprávu je vhodné zkusit zaslat opakovaně. Pokud nebude opakovaně přijata, je vhodné překontrolovat datovou zprávu a případně kontaktovat technickou podporu správce daně. Pokud se obrátíte na technickou podporu správce daně, využijte prosím kontaktní formulář na stránkách www.etrzby.cz, vyberte oblast „Technický dotaz“, připojte zaslanou datovou zprávu a odpověď s chybou 8 a vyčkejte na vyjádření.

  • Taková situace může nastat, ale kontroly na straně systému EET se ukončují již při nalezení první kritické chyby. Systém EET pak okamžitě odesílá odpověď s první nalezenou kritickou chybou. V jedné chybové zprávě (odpovědi) tedy nebude uvedeno více chyb, i kdyby je doručená datová zpráva o tržbě obsahovala.

  • Může se stát, že do uplynutí mezní doby odezvy nepřijde žádná odpověď, tj. ani chybová zpráva. Taková situace může nastat v případě, že datová zpráva nebyla doručena do systému EET, nebo nebyla doručena odpověď zpět pokladnímu zařízení. Také je možné, že datová zpráva byla vyhodnocena jako součást bezpečnostního útoku a v takovém případě systém EET odpověď nezasílá. Je třeba zkontrolovat datovou zprávu a její velikost. Pokud se datová zpráva jeví korektní, je vhodné ji zaslat znovu. Při opakovaném neúspěchu doporučujeme kontaktovat správce daně pomocí kontaktního formuláře na stránkách www.etrzby.cz, vybrat oblast „Technický dotaz“, popsat co nejpřesněji situaci, připojit datovou zprávu a vyčkat na vyjádření.

Nacházíte se zde:

  1. Úvodní stránka
  2. IT/Vývojář
  3. Nejčastější dotazy vývojářů