Podáváme daňové přiznání přes web finanční správy

26.7.2020 21:25 | Přečteno: 5310× |

Letos jsem tak jako každý rok podával daňové přiznání na poslední chvíli, tedy s tím rozdílem, že vzhledem k epidemii tato chvíle vycházela místo konce března na konec června. Pak se ale termín opět posunul, a mě se tak výjimečně podařilo podat přiznání více než měsíc před termínem. Popis jak tohle funguje přes internet bez kvalifikovaného certifikátu nebo datové schránky by tak teď v červenci mohl být pořád možná někomu i užitečný, ale na druhou stranu stávající webová aplikace finanční správy je v provozu již více než 10 let, a moje hlavní motivace k sepsání tohoto zápisku je tak spíše poznamenat si jak to přesně funguje (což se může příští rok navzdory připravovaným novinkám stále hodit) a zároveň sondovat jaké zkušenosti s tím máte vy.

Malé upozornění na úvod. Toto není návod jak řešit daně. Nedovíte se tu kdy a proč musíte daňové přiznání řešit, co do které položky uvést ani jaké přílohy dodat.

Možnosti podání daňového přiznání

Pokud máte nějaký důvod podat daňové přiznání z příjmů fyzických osob sami místo toho, aby to za vás udělal váš zaměstnavatel nebo daňový poradce, máte hned několik oficiálních možností.

• Dojít si pro formulář na úřad, ručně to vypsat a fyzicky na úřadě odevzdat. Tohle asi dělat nebudete, ale zmiňuji to tady proto, že historicky je to primární use case a spousta věcí z něj vychází.

• Stáhnout si z webu finanční správy tzv. klasický tiskopis v pdf, vytisknout a pak pokračovat stejně jako v předchozím případě.

• Stáhnout si ze webu tzv. interaktivní tiskopis, nainstalovat Adobe Acrobat Reader (ve verzi alespoň 9.1) a tiskopis v Acrobatu vyplnit s tím, že položky co lze odvodit z jiných umí tento interaktivní pdf formulář sám dopočítat. Takto vyplněné je to pak nutné vytisknout a fyzicky donést na úřad. Když opomenu fakt, že poslední Acrobat Reader pro Linux byla verze 9.5.5 z roku 2013 a dnes se již blbě shání, proprietární binární datový formát je v tomto případě dostatečný důvod proč se této možnosti vyhnout. Jednotlivé formuláře nemůžete rozumně porovnat nebo zpracovat skriptem, a bez Acrobatu se ke svým datům nedostanete, žádný free software pdf prohlížeč neumí takto vyplněná data ani omezeně zobrazit (takže je dobrý nápad to aspoň na virtuální tiskárně vytisknout do pdf souboru). Vy přitom ale chcete mít možnost jednoduše formulář přečíst a opravit pro případ, že by se vám kvůli nějaké nesrovnalosti ozval finančák (a to až 3 roky zpětně). A drobnost, že vyplňujete data na počítači abyste je vytiskly na papír a pak na úřadě někdo jiný opět přepsal do počítače, tu dál rozebírat raději ani nebudu (-:

• Podat přiznání elektronicky pomocí daňového portálu, což je imho nejrozumnější možnost a věnuji se jí ve zbytku tohoto zápisku.

Mimo to existují neoficiální tabulky pro excel/libreoffice calc, do kterých můžete naládovat data, některé položky se dopočítají a po vytisknutí vypadá podobně jako oficiální tištěný formulář, který pak donesete fyzicky na úřad. Je to tak podobné jako v případě oficiálního interaktivního pdf s tím rozdílem, že data jsou uložená v o něco čitelnějším formátu, ale na druhou stranu to není zas o tolik lepší a navíc nemáte jistotu, že ten formulář je správně.

Když jsem tohle řešil před pár lety poprvé, zvolil jsem interaktivní pdf tiskopis pro Acrobat Reader, a pak jsem toho později několikrát těžce litoval. Možnost elektronického podání jsem ke své škodě tenkrát ignoroval, protože jsem se mylně domníval, že k tomu je třeba mít datovou schránku.

Přiznání přes daňový portál

Podat některé daňové přiznání přes internet jde minimálně od roku 2003. Pro daň z příjmů fyzických osob pak tato možnost existuje minimálně od roku 2009 (viz také heslo EPO na wikiverzitě). Současná podoba webového rozhraní je pak zdá se min. z roku 2015. Rozhodně tu tedy neřeším nějakou novinku.

Webovou aplikaci Elektronická podání pro finanční správu (EPO), která podání přes internet umožňuje, najdeme na daňovém portálu na url:

https://adisepo.mfcr.cz/adistc/adis/idpr_epo/epo2/uvod/vstup.faces

Jelikož ale takové url není dost cool, na EPO se lze dostat i z separátního rozcestníku na adrese:

https://www.daneelektronicky.cz/

Začneme tím, že v seznamu formulářů vybereme ten správný. Takový seznam se dá najít na dvou místech jako:

• Databáze daňových tiskopisů na webu finanční správy (poslední sloupec v tabulce tiskopisů s názvem EPO obsahuje odkaz, který otevře daný formulář ve webové aplikaci)
• Elektronické formuláře na webu Elektronických podání (EPO)

Na první pohled je seznam na webu EPO mnohem kratší a srozumitelnější. Pokud ale nevíte, že pro daň z příjmů fyzických osob od roku 2016 existuje navíc zjednodušená dvoustránková verze formuláře, nebude vám hned jasné, proč ten seznam z webu EPO obsahuje formuláře dva a který z nich máte použít. Navíc s velkou pravděpodobností stejně nakonec zvolíte původní plnou verzi, protože pokud už toto řešíte sami, šance že můžete zkrácený formulář použít je malá. Pokud byste ale např. zpracovávali větší množství daňových přiznání na papírových formulářích, mohl by vám ten zkrácený formulář teoreticky ušetřit určité množství papíru (-:

Tento přístup má imho dva drobné problémy. Bez ohledu na to že existuje několik různě obsáhlých papírových verzí formuláře bych čekal, že elektronický formulář bude z pohledu uživatele existovat pouze jeden. Hádám že finanční správa asi nechce kvůli tomu EPO nijak upravovat (třeba přidat funkcionalitu, která by výběr toho formuláře nějak inteligentně řešila), bylo by ale dobré aspoň v seznamu na webu EPO zalinkovat to oznámení o zkráceném formuláři, aby bylo hned jasnější o co se jedná.

Otevřeme tedy aplikaci EPO s plným formulářem, tj. daň z příjmů fyzických osob - od roku 2013 včetně.

Vpravo nahoře vidíme, že nejsme přihlášení. Hned o kus dál je pak odkaz na login přes NIA. Pokud tedy např. máte aktivovanou novou občanku s čipem (další možnosti přibyly teprve nedávno), můžete se přes ni přihlásit. Více se tomu věnuje server lupa.cz v článku Přes Portál občana se můžete přihlásit i k Daňovému portálu. Sám jsem možnosti přihlášení nevyužil (občanku s čipem nemám a další metody autentizace jsem zatím nestudoval) a dál se jí věnovat nebudu. Pointa tohoto zápisku je totiž i v tom, že pro to, abyste mohli aplikaci EPO použít k podání daňového přiznání, se přihlašovat nemusíte.

Vyplňujeme a podáváme formulář

Teď můžeme buď využít průvodce, který se nás nejprve zeptá na typ příjmů a podle toho omezí políčka formuláře, které po nás bude chtít vyplnit, nebo přes odkaz “Další stránka” přejít na vyplňování první části, která více méně odpovídá začátku papírového formuláře. Ve výsledku se ale oba přístupy zas tolik neliší. Postupně vyplníme všechny položky, které bychom museli vyplnit na papírovém formuláři, ale EPO alespoň umí některé položky dopočítat (ty jsou podbarvené žlutě) a upozorní nás na konflikty nebo na chybějící přílohy. Stránku formuláře nebo celý formulář je možné také nechat zkontrolovat.

Během vyplňování je třeba dávat pozor na to, že server data drží jen asi půl hodinu od poslední změny ve formuláři. Pokud tedy na hodinu odejdeme od rozpracovaného formuláře, o vyplněná data můžeme přijít. Na druhou stranu nám ale aplikace umožňuje všechna data, co jsme dosud vyplnili, stáhnout ve formě XML souboru (po kliknutí na odkaz Uložení prac. souboru), který můžeme později načíst a pokračovat v zadávání dat. Schéma XML opět přesně odpovídá papírovému formuláři, a tak obsahuje jak hodnoty, co jsme ručně zadali, tak ty dopočítané (jako např. základ daně). Případné binární přílohy jsou v XML souboru uložené jako base64 kódovaný CDATA text.

Možnost stáhnout data je imho velká výhoda. Porovnáním průběžně uložených XML dat lze zjistit jaký vliv má vyplnění konkrétní přílohy nebo položky. Případně pokud máme XML export z předchozího roku, lze se také přímo podívat, v čem je letošní přiznání jiné, resp. zda se liší ve věcech co bychom čekali. Takové porovnání lze v případě potřeby automatizovat a podobně funkce importu XML dat otevírá možnost, že data pro formulář vygenerujeme, třeba jen částečně, nějakým skriptem.

Pro demonstrační účely v rámci tohoto zápisku jsem formulář částečně vyplnil, a abych si nemusel vymýšlet úplné blbosti, použil jsem veřejně dostupné osobní údaje paní Specimen ze vzoru občanského průkazu z roku 2012 (-:

Pracovní export XML dat z formuláře, kde byl vyplněn pouze 1. oddíl Údaje o poplatníkovi, vypadá následovně:

<?xml version="1.0" encoding="UTF-8"?>
<Pisemnost nazevSW="EPO MF ČR" verzeSW="41.10.5">
<DPFDP5 verzePis="06.02">
<VetaD rok="2019" pln_moc="N" dokument="DP5" audit="N" c_ufo_cil="456" k_uladis="DPF" zdobd_od="01.01.2019" prop_zahr="N" zdobd_do="31.12.2019" dap_typ="B" />
<VetaP ulice="Pražská" psc="40001" email="specimen.vzor@post.cz" k_stat="CZ" rod_c="8160080610" titul="Mgr." c_pop="257" c_obce="567892" c_orient="43" c_pracufo="2501" prijmeni="Specimen" stat="ČESKÁ REPUBLIKA" st_prislus="ČR" naz_obce="ÚSTÍ NAD LABEM-MĚSTO" jmeno="Vzor" />
<VetaB priloh_celk="0" />
</DPFDP5>
</Pisemnost>

Co který atribut znamená lze dohledat v dokumentaci tiskopisu DPFDP5 (že jde právě o tento lze poznat mimo jiné z prefixu XML souboru), kde se dá také stáhnout jeho XML schéma.

Zatím mi ale vždy stačilo XML soubor skriptem přeformátovat tak, abych mohl použít běžné textové nástroje pro zobrazení rozdílů (např. vimdiff nebo meld):

$ xml-pretty-data DPFDP5-8160080610-20200717-001524-pracovni.xml
<?xml version="1.0" encoding="UTF-8"?>
<Pisemnost
  nazevSW="EPO MF ČR"
  verzeSW="41.10.5"
  >
  <DPFDP5
    verzePis="06.02"
    >
    <VetaD
      audit="N"
      c_ufo_cil="456"
      dap_typ="B"
      dokument="DP5"
      k_uladis="DPF"
      pln_moc="N"
      prop_zahr="N"
      rok="2019"
      zdobd_do="31.12.2019"
      zdobd_od="01.01.2019"
      >
    </VetaD>
    <VetaP
      c_obce="567892"
      c_orient="43"
      c_pop="257"
      c_pracufo="2501"
      email="specimen.vzor@post.cz"
      jmeno="Vzor"
      k_stat="CZ"
      naz_obce="ÚSTÍ NAD LABEM-MĚSTO"
      prijmeni="Specimen"
      psc="40001"
      rod_c="8160080610"
      st_prislus="ČR"
      stat="ČESKÁ REPUBLIKA"
      titul="Mgr."
      ulice="Pražská"
      >
    </VetaP>
    <VetaB
      priloh_celk="0"
      >
    </VetaB>
  </DPFDP5>
</Pisemnost>

Když jsme s vyplňováním formuláře hotovi, můžeme přiznání v aplikaci EPO podat jedním z těchto 3 způsobů:

• přes datovou schránku
• s použitím kvalifikovaného certifikátu
• bez elektronického podpisu

Tady ještě doplním, že aplikace EPO umožňuje stáhnout pdf verzi vyplněného formuláře i před samotným podáním. Můžeme tedy místo výše popsaných možností podání formulář prostě vytisknout a donést na úřad. V takovém případě bychom vlastně použili EPO pouze jako nástroj k vyplnění a základní kontrole formuláře.

Jelikož datovou schránku ani kvalifikovaný certifikát nemám, zbývá mi jen poslední možnost. Ta spočívá v tom, že vyplněná data se odešlou na server, který je podepíše, uloží a vygeneruje mi o tom potvrzení.

Pak je třeba do 5 dnů vytisknout, podepsat a na úřad osobně doručit jednostránkové potvrzení o podaní (na screenshotu výše jde o e-tiskopis podání). Fyzické ověření totožnosti tu tak úřadu nahrazuje elektronický podpis. Teprve od okamžiku přijetí tohoto potvrzení úřadem je přiznání oficiálně podáno. Pokud bychom to do těch 5 dnů nestihli, je to jako bychom přiznání vůbec nepodali.

E-tiskopis kvůli identifikaci podávajícího obsahuje naše rodné číslo, jméno a adresu, dále pak 3 hodnoty ze samotného přiznání (daňový bonus, daň a ztráta) a identifikaci elektronického podání (název souboru s podáním, číslo podání a tzv. kontrolní číslo). Není mi sice jasné jak a z čeho přesně se to kontrolní číslo spočítá, ale je možné ho nalézt i ve finálním XML exportu dat formuláře.

Pokud vám aplikace spočítá nedoplatek, tak jistě oceníte, že vám vygeneruje i kompletní platební informace: částku k platbě, číslo účtu a variabilní symbol A to včetně QR kódu pro platbu přes mobilní aplikace. Bez této funkce by bylo dohledávání platebních informací vyloženě za trest: každý kraj má totiž vlastní sadu několika různých účtů, každý pro jiný typ daně. Naopak v případě přeplatku se žádné překvapení nekoná, během vyplňování formuláře by bylo třeba vyplnit číslo účtu kam vám mají peníze vrátit v oddílu “Vrácení přeplatku”.

Mimo pdf s e-tiskopisem je dobré stáhnout a uschovat minimálně potvrzení v souboru s příponou .p7s. Ten obsahuje jak metadata o podání (včetně čísla podání a přístupového hesla) a kompletní XML data vyplněná do formuláře, tak podpis všech těchto dat s certifikátem. Na tento soubor je proto vhodné dávat dobrý pozor.

Dále je ještě možné stáhnout XML data nebo pdf verzi formuláře, ale pokud máte ten .p7s soubor, vše ostatní lze s jeho pomocí později získat.

Při zadání čísla a hesla podání na stránce Stav zpracování elektronických podání vám aplikace EPO zobrazí jeho strohý stav zpracování (buď “Podání bylo přijato cílovým úřadem” nebo “Podání bylo přijato na společném technickém zařízení správců daně.”), zatímco pokud necháme načíst celý .p7s soubor, dostaneme se znovu ke všem informacím o podání, včetně možnosti zaslat úpravy (to jsem ale nezkoušel).

Pitváme (a ověřujeme) potvrzení podání

Jelikož potvrzení podání v .p7s souboru se důrazně doporučuje stáhnout a uschovat, podíváme se na něj podrobněji. Jde o PKCS #7 signedData zprávu kódovanou v binárním DER formátu. Tento soubor tedy obsahuje jak samotná data o podání v XML formátu (včetně vloženého XML našeho vyplněného DPFDP5 formuláře) tak podpis těchto dat s X.509 certifikátem.

Nejprve se zaměříme na samotný certifikát. Pro demonstrační účely si jej vyexportujeme do souboru potvrzeni.crt v textového PEM formátu:

$ openssl pkcs7 -inform DER -in DPFDP5-8160080610-20200719-133006-17102653-potvrzeni.p7s -print_certs -outform PEM -out potvrzeni.crt

Vidíme že certifikát vydala I. CA:

$ openssl x509 -in potvrzeni.crt -issuer -noout
issuer=C = CZ, CN = I.CA Qualified 2 CA/RSA 02/2016, O = "Prvn\C3\AD certifika\C4\8Dn\C3\AD autorita, a.s.", serialNumber = NTRCZ-26439395

V seznamu kvalifikovaných certifikátů I. CA tedy najdeme příslušný záznam “I.CA Qualified 2 CA/RSA 02/2016” a stáhneme jej v PEM formátu:

$ wget https://www.ica.cz/userfiles/files/certifikaty/HCA_kvalifikovany/2qca16_rsa.pem
$ openssl x509 -in 2qca16_rsa.pem -noout -subject
subject=C = CZ, CN = I.CA Qualified 2 CA/RSA 02/2016, O = "Prvn\C3\AD certifika\C4\8Dn\C3\AD autorita, a.s.", serialNumber = NTRCZ-26439395

Jak ale vidíme, pro ověření potřebujeme ještě minimálně příslušný kořenový certifikát I. CA:

$ openssl x509 -in 2qca16_rsa.pem -noout -issuer
issuer=C = CZ, O = "Prvn\C3\AD certifika\C4\8Dn\C3\AD autorita, a.s.", CN = I.CA Root CA/RSA, serialNumber = NTRCZ-26439395
$ wget https://www.ica.cz/userfiles/files/certifikaty/HCA_root/rca15_rsa.pem

Důkladnější ověření pravosti kořenového certifikátu (včetně zohlednění revocation seznamů) už ale nechám na vás (-:

$ openssl x509 -in rca15_rsa.pem -noout -fingerprint -sha256
SHA256 Fingerprint=D3:D6:07:A9:FF:24:A1:95:23:B6:DA:9D:2C:64:94:46:F8:78:8C:B9:6D:9F:D1:30:97:2E:12:0C:13:67:77:30

Vidíme, že řetězec certifikátů podle očekávání sedí k sobě, tj. že kořenový rca15_rsa.pem opravdu podepsal mezilehlý 2qca16_rsa.pem a ten pak certifikát potvrzeni.crt z podání:

$ openssl verify -CAfile rca15_rsa.pem -untrusted 2qca16_rsa.pem potvrzeni.crt
potvrzeni.crt: OK

Pojďme ale udělat něco užitečnějšího: data z PKCS#7 zprávy vytáhneme a zvalidujeme. Oba kořenové certifikáty ale kvůli tomu nejprve uložíme do jednoho PEM souboru:

$ cat rca15_rsa.pem 2qca16_rsa.pem > certchain.pem
$ openssl cms -verify -inform DER -in DPFDP5-8160080610-20200719-133006-17102653-potvrzeni.p7s -CAfile certchain.pem -out potvrzeni.pkcs7-data.xml
Verification successful

Když se teď podíváme na data z potvrzení, co jsme takto dostali, vidíme, že formulář samotný není v potvrzení vložený přímo:

$ xml-pretty-data potvrzeni.pkcs7-data.xml
<?xml version="1.0" encoding="UTF-8"?>
<Pisemnost>
  <Data>
  </Data>
  <Kontrola>
    <Soubor
      Delka="783"
      KC="8e3ddda5a61e40aac7f268973aa5d9ac"
      Nazev="DPFDP5-8160080610-20200719-133006"
      c_ufo="456"
      >
    </Soubor>
  </Kontrola>
  <Podani
    Cislo="17102653"
    Datum="2020-07-19T13:33:54"
    Email="specimen.vzor@post.cz"
    Heslo="XXXXXXXX"
    KC="a52e16cc1e2648d2c393e2722e71c2d3"
    ZAREP="false"
    >
  </Podani>
</Pisemnost>

Resp. nevidíme, protože můj skript xml-pretty-data nevypisuje textový obsah XML elementů. Pro účely porovnávání XML dokumentů lezoucích z EPO je to ale výhoda, protože taková data obsahují pouze jiné velké vložené soubory a přímo by ani porovnat nešla. Na XML našeho DPFDP5 formuláře v hexadecimálním formátu v elementu Data by stejně nebyl pěkný pohled.

$ xmlstarlet sel -t -v "/Pisemnost/Data" potvrzeni.pkcs7-data.xml > potvrzeni.pkcs7-data.DPFDP5.hex
$ xxd -r -p potvrzeni.pkcs7-data.DPFDP5.hex > potvrzeni.pkcs7-data.DPFDP5.xml

Takže pokud přemýšlíte proč je ten soubor tak velký, tohle by mohl být ten důvod.

Když pak porovnáme XML soubor, co jsme právě vytáhly z potvrzení, s tím, co jsme si stáhli při samotném podání, obsah souborů by se neměl nijak lišit. Porovnání s pracovní verzí formulářových dat uloženou těsně před podáním ale ukáže, že po podání se v datech objeví element Kontrola, všechna ostatní data by ale měla zůstat stejná.

$ diff potvrzeni.pkcs7-data.DPFDP5.xml DPFDP5-8160080610-20200719-133006.xml
$ diff potvrzeni.pkcs7-data.DPFDP5.xml DPFDP5-8160080610-20200717-001524-pracovni.xml
8c8
< <Kontrola><Uzivatel jmeno="null" prijmeni="null" /><Soubor Delka="503" KC="8e3ddda5a61e40aac7f268973aa5d9ac" Nazev="DPFDP5-8160080610-20200719-133006" c_ufo="456" /></Kontrola></Pisemnost>
---
> </Pisemnost>

Tímto si tedy můžeme být jisti, že nám daňový portál opravdu podepsal data, které jsme zadali do formuláře.

Jak si ale můžeme mít jistotu, že na papírovém potvrzení (e-tiskopisu) podepisujeme stejnou informaci? Když se podrobně na e-tiskopis znovu podíváme, vidíme následující údaje, které podání identifikují:

Jak jsem poznamenal už výše, nejsem si jistý z čeho a jak se kontrolní číslo počítá, takže žádnou z těchto hodnot nelze brát jako checksum všech formulářových dat. Ale na druhou stranu máme tyto údaje spolu se všemi ostatními daty, co jsme vyplnily do formuláře, podepsané v PKCS#7 souboru od finanční správy. Můžeme se tak podívat, že tyto údaje z papírového potvrzení sedí k těm podepsaným:

$ xmlstarlet sel -t -v "/Pisemnost/Kontrola/Soubor/@Nazev" potvrzeni.pkcs7-data.xml; echo
DPFDP5-8160080610-20200719-133006
$ xmlstarlet sel -t -v "/Pisemnost/Kontrola/Soubor/@KC" potvrzeni.pkcs7-data.xml; echo
8e3ddda5a61e40aac7f268973aa5d9ac
$ xmlstarlet sel -t -v "/Pisemnost/Podani/@Cislo" potvrzeni.pkcs7-data.xml; echo
17102653

Jak daňová správa tak my tedy můžeme zpětně dokázat, co bylo přesně ve formuláři podáno.

A nakonec pro jistotu dodám, že o něco uživatelsky přívětivější je pro validaci podpisu v PKCS#7 potvrzení použít GUI nástroje typu Kleopatra, kde po naimportování a ověření kořenových certifikátů I. CA, lze popis potvrzení pohodlně zvalidovat.

Validaci samotného podepsaného obsahu to ale samo o sobě pochopitelně neřeší.

Moje dojmy

Samotná aplikace bohužel otrocky vychází z papírových formulářů, což je hádám problém i současných zákonů a předpisů, takže musíte např. vypisovat k jakému finančnímu úřadu patříte, i když později vyplňujete adresu trvalého pobytu, ze které by tento detail šel odvodit. Jak píše lupa.cz ve výše odkazovaném článku, při přihlášení přes portál občana sice je možné některé osobní údaje nechat předvyplnit, ale ideálně bych si představoval, že pokud už se přihlásím přes občanku s čipem, žádné údaje které již stát o mě má nebudu vůbec muset znovu zadávat.

Naopak dobrá ukázka využitého potenciálu strojového zpracování při podání je vygenerování platebních pokynů včetně bankovního QR kódu. Další pozitivní aspekt systému EPO je možnost z aplikace stáhnout veškerá data nebo naopak data do aplikace nahrát. A to ve strukturovaném zdokumentovaném formátu, který používá otevřené standardy. Otvírá to možnosti počítačového zpracování dat, včetně tvorby pomocných aplikací (skutečně rozumně navržené aplikace na ulehčení vyplňování daňového přiznání generují XML data, která si pak můžete sami přes EPO podat).

Použití XML jako datového formátu tu imho dává smysl. I když bohužel se autorům aplikace nepodařilo na řadě míst vyvarovat podivným hackům, jako např. při vkládání XML do XML. Ale to by bylo na další XML flamewar …

Škoda jen, že alespoň některé části aplikace EPO nejsou státem zveřejněny jako open source knihovny, když už si to platíme z daní. Ještě více je ale škoda, že příslušné zdrojáky nevlastní ani samotný stát. Informační systém ADIS, kde data vyplněná přes EPO nakonec skončí, totiž zaujímá přední postavení v zástupu vendor lock-in systémů používané v naší státní správě.

Dále je těžké pochopit, proč stát lidi k používání el. podání nijak pozitivně nemotivuje. Už jen to, že na úřadě nikdo nemusí formuláře ručně přepisovat do počítače musí finančáku ušetřit spoustu času. Stát ale “motivuje” jen ve speciálních případech, a pouze sankcemi. Pokud např. máte datovou schránku a podáte přiznání jiným způsobem, automaticky vám vzniká neprominutelná pokuta ve výši 2000 Kč. Když ale povinnost používat datovou schránku nedodrží stát, nezbývá vám než se v případě problémů bránit zpětně u soudu. Problém tohoto typu už stihl řešit i Nejvyšší správní soud, takže by dnes snad mělo být jasné, že úřad použít datovou schránku prostě musí, a že tu nelze použít tzv. fikci doručení a považovat nepřevzatý dopis za doručený. Na druhou stranu pokud ale dopis, co měl být poslán datovou schránkou, skutečně převezmete, legitimizujete tím chybný úřední postup a zaniká vám možnost si na něj dál stěžovat. Ve výsledku tak takové prostředí spíše od zřízení datové schránky odrazuje aniž by to propagaci el. podání nějak pomohlo.

Budoucnost

Zhruba před rokem se finanční správa pochlubila plánem, jak získat autorská práva k systému ADIS, vyřešit problém s vendor lockinem a umožnit jeho modernizaci. Drobný zádrhel ovšem je, že na implementaci nového systému má ministerstvo financí omezený čas, a tak teď těžko říct, jestli se to opravdu podaří vyřešit.

Kromě toho se už nějaký čas připravuje novela daňového řádu, která by mohla některé problémy zmiňované výše řešit. Automatická pokuta za nepodání daňového přiznání pro držitele datových schránek by měla být omezena a naopak při elektronickém podání by se měla lhůta pro podání prodloužit o měsíc.

Novela také zahrnuje vznik tzv. “online finančního úřadu” MOJE daně, který vznikne rozšířením a modernizací současného systému daňových informačních schránek, o kterém jsem se tu zatím vůbec nezmiňoval. Pokud chápu stručný popis nového portálu dobře, půjde o další možnost jak daně podat, která by měla umožnit nejen předvyplnit data co finanční správa už ví, ale i dostat se ke stavu a údajům z předchozích podání a plateb. Mělo být také možné se do systému přihlásit i bez datové schránky, kvalifikovaného certifikátu nebo e-občanky. Jak to má ale přesně fungovat jsem nedohledal.

Já teď zvažuji možnosti, jak bych příště podal přiznání zcela elektronicky. Nová občanka s čipem vypadá na první pohled zajímavě, ale když jsem si začal dohledávat detaily, byl jsem z toho poněkud rozpačitý. Možná nakonec skončím u datové schránky. A co vy? Máte kvalifikovaný podpisový certifikát, datovou schránku nebo novou občanku s čipem?

       

Anketa

Anketa

Komentáře

[Luk]

Vyplním v EPO a podám přes EPO s ověřením totožnosti přes datovou schránku.

[vlk]

+1

[Bubak]

Vygeneruji v PROFITu (lpsoft.cz) a nejak dodam - letos postou (podaval jsem ho v normalnim terminu, nebot tem kriplum, co tu vladnou, a rikaji co pet minut neco jineho, jsem neveril, ze pak nebudou prudit, proc jsem nepodal, kdyz jsem mohl apod.). Puvodne jsem si nechal vyrobit eidentitu, protoze to vypadalo, ze tak pujde podat priznani bez dalsich saskaren, ale hovno hovno, zlata rybko. A jelikoz me nasrali a na postu se mi nechtelo, poslal jsem to (vytistene, podepsane a naskenovane) pres postaonline.cz. Zatim je z financaku ticho po pesine, CSSZ a VZP jsou s tim v pohode, zda se.

[marbu]

Jo, to s tím pruzením chápu. Možnost podání přes Dopis Online mě vůbec nenapadla, protože imho podpis na naskenovaném papíru neplňuje definici elektronického podpisu, co zle úředně uznat. Ale ty zákony jsem k tomu nějak podrobně nestudoval, tak snad to i vzhledem k pandemii bude v pohodě. Kdyby s tím měli na finančáku nějaký problém, docela by mě zajímalo jaký.

[Bubak]

Nevim, taky jsem to nestudoval, uvidime, kdy a s cim na me prijdou Ale kdyz poslu priznani vytisknute primo a podepsane, je to temer to same, protoze stejne nevedi, jestli jsem to podepsal ja, nebo nekdo za me, nebo jsem podepsal cisty papir, na ktery nekdo neco dotisknul (no dobre, to by slo asi casto odhalit, kdyby nekdo chtel). Ve smyslu zakona, ktery to zrovna moc neresi, je to ostatni elektronicky podpis, ktery je (pravdepodobne) uznatelny v soukromopravnim jednani.

Ale vzhledem k tomu, ze za normalnich okolnosti postou vytistene priznani posilam sice vlastnorucne podepsane a podpis neni overeny, prijde mi to prast jako uhod...

[Michal Kubeček]

Ode mne už si několikrát úředníci FÚ takhle "podepsané" dokumenty sami vyžádali, takže je poměrně velká šance, že to projde. Navíc je to při EPO podání běžné u některých příloh - např. čestné prohlášení druhého z manželů, že neuplatňuje slevu na stejné dítě (což je samo o sobě jedna z velkých absurdit praxe naší daňové správy).

[Filip Jirsák]

Naskenovaný podpis vytištěný na papíře není elektronický podpis, natož uznávaný elektronický podpis. Ale vzhledem k tomu, že to Česká pošta s největší pravděpodobností tiskne barevným inkoustem (předpokládám, že to nakonec stejně skončí na lince PostServisu), úředník to nejspíš na první pohled nerozezná od vlastnoručního podpisu – pokud je ten podpis trochu rozumně naskenovaný. Já už léta na všechny dokumenty, které vytvářím já, svůj podpis rovnou tisknu (když je nemůžu rovnou elektronicky podepsat), a nikdo si toho nikdy nevšiml.

[Bubak]

Jasne, ten "ostatni" elektronicky podpis jsem myslel na naskenovany vlastnorucne podepsany dokument.

Jinak jo, tisknou to barevne.

[Filip Jirsák]

Naskenovaný vlastnoruční podpis vytištěný na papíře není „elektronický podpis“, je to prostý „podpis“.

[osel jara]

Pak je třeba do 5 dnů vytisknout, podepsat a na úřad osobně doručit jednostránkové potvrzení o podaní

Zatím jsem vždy potvrzení posílal (doporučeně) poštou.

A ještě drobnost, je možné uložit předvyplněnou šablonu. Při novém podání stačí do aplikace nahrát šablonu a doplnit změny (rok, částky).

[marbu]

Díky za doplnění. Poslat to doporučeně je taky možnost. I když bych se trochu bál, zda to doručí včas (přece jenom, je tam ten termín 5 dnů). Pokud si ale můžu vybrat, např. protože ve městě je jak pošta tak finančák, finančák je jasná volba ...

To s tím předvyplněním je dobrá poznámka. Zkoušel jsem takto řešit jen osobní údaje, protože jinak jsem měl strach, že bych pak musel zkontrolovat zda ten formulář nějak neupravili.

[Vantomas]

Při komunikaci se státní správou je rozhodující datum na razítku/podacím lístku. Dnes už to není tak běžné, ale ještě před lety v Praze na hlavní poště bývaly velké fronty před půlnocí posledního dne termínu daní.

[Vantomas]

Datovkou posílám XML z účetnictví nebo vyexportovaný formulář v XML z EPO. Datovka je snad prakticky jediná rozumná vstupní brána do egovermentu. I ta eidentita.cz se dá pohodlně pořídit hnedka s Datovkou...

[plostenka]

PDF z EPO formulare tisknu dvakrat a pak odevzdam osobne na FU - jeden stejnopis si nechaji, druhy orazitkovany si odnasim. Financak se tim razitkem priznal ze dostal konkretni verzi - nemuze si ex-post vymyslet ze nedostal nic nebo jen prazdny papir, nevyprsi digitalni podpis...

[j]

Presne, navic naklady na archivaci = jedno suple ve skrini = 0. Nemusis resit, kdy ti chcipne disk nebo neco dalsiho.

Nemluve o takovych krasnych vecech, ze jako az se (mozna) jednou dozijes duchodu, a stat ti bude tvrdit, ze na zadnej nemas narok, protoze si nikdy nepracoval, tak chci videt, jak budou dokladovat ti, kteri budou mit hromady necitelnych jednicek a nul, protoze formaty ve kterych to maji uz davno nebude nikdo znat.

BTW: Ono uz v tom kilometrovym blogu je krasne videt, oc jednodussi je vzit papir, a cestou se stavit na podatelne a nechat si orazitkovat kopii.

---

Dete s tim guuglem dopice!

[marbu]

Pravda.To s dlohodobou archivací je dost dobrá poznámka. Navíc i vzhledem k tomu, že oni k tomu systému ani nemají zdroják. Na druhou stranu, aspoň jde o datový formát používající otevřené standardy, takže by to nemusel být úplně neřešitelný problém.

[luky]

PDF z EPO formulare tisknu dvakrat a pak odevzdam osobne na FU - jeden stejnopis si nechaji, druhy orazitkovany si odnasim. Financak se tim razitkem priznal ze dostal konkretni verzi - nemuze si ex-post vymyslet ze nedostal nic nebo jen prazdny papir, nevyprsi digitalni podpis...

Kdyz to podate pres datovku, tak zpatky dostanete podepsany hash zpravy, takze dukaz o podani take mate.

[Filip Jirsák]

Financak se tim razitkem priznal ze dostal konkretni verzi

Nikoli. Přiznává se tím k tomu, že dostal něco, co alespoň vzdáleně připomínalo daňové přiznání. Kdyby měl potvrzovat, že dostal konkrétní verzi, musel by vaši verzi podrobně údaj po údaji porovnat s tím, co si nechává. Tak se ale ověřená kopie samozřejmě nedělá – ověřená kopie se dělá tak, že ten, kdo to ověřuje, si sám udělá kopii a tu pak potvrdí.

nevyprsi digitalni podpis

Podpis je považován za pravý, dokud se neprokáže opak. Elektronický podpis i po vypršení platnosti certifikátu bude dost věrohodně potvrzovat, kterou přesně verzi daňového přiznání jste podal. Razítko na vašem originálu to opravdu nepotvrzuje. A mimochodem, elektronické potvrzení o přijetí musí úřad povinně opatřit nejen elektronickou značkou, ale také časovým razítkem.

[Josef Kufner]

Ale vůbec ne. Tím, že ti to potvrdí, tak potvrdí, že to je stejné jako to, co přijali. Proto to ta paní na přepážce kontroluje (nebo by alespoň měla).

Pokud by se na nějakou neshodu přišlo, tak se může řešit, zda tu či onu verzi někdo nějak neupravil. Pokud to ztratí úplně, tak je to jednoduché a tvoje potvrzená kopie je dostačující.

[Michal Kubeček]

Co můžu říct ze zkušenosti, tak na podatelně kontrolují nanejvýš tak základní údaje na začátku první strany a pak ještě mrknou na poslední stranu, jestli je formulář podepsaný. Ale jak píšete, to je jejich problém, ne váš nebo můj. Argument, že je přeci jasné, že to nemohli zkontrolovat pořádně, je asi tak na stejné úrovni jako tvrzení, že je přeci jasné, že jsem tu smlouvu nepřečetl celou.

V případě sporu to asi bude tak, že budou-li k dispozici obě verze, pak je a priori platná ta, kterou má FÚ, a budete-li ji chtít nějak zpochybnit, musel byste nějak prokázat, že váš podpis na ní je falešný (hodně štěstí). Pokud se jejich ztratí a zůstane jen vaše, bude situace opačná.

[Filip Jirsák]

Ne, shodu těch dvou originálů na přepážce nikdo nekontroluje. Jak jsem psal, kdyby to měla být kopie, nedělá se to složitě kontrolou (při které je snadné něco přehlédnout), ale tu kopii by vám fyzicky vytvořili. Ověřenou kopii na poště nebo u notáře také dělají tak, že předlohu sami okopírují.

Mimochodem, kdyby na přepážce skutečně kontrolovali shodu, budete tam s jedním přiznáním čtvrt hodiny. A teprve teď by na vás přišla řada s daňovým přiznáním za rok 2018. V podatelně kontrolují, jestli jsou tam vyplněné základní údaje – aby vám to případně vrátili rovnou a ne až běžnou úřední cestou.

Pokud by se na nějakou neshodu přišlo, nic by se neřešilo – vy jste podal to, co má úřad. Nějaká vaše soukromá kopie nikoho nezajímá – bez ohledu na to, že je na ní podací razítko FÚ. Jediné, k čemu je ta kopie dobrá, je důkaz, že jste vůbec nějaké daňové přiznání podal.

[Ovoce]

Taky posílám přes EPO a nosím potvrzení na úřad.

Je ovšem dobré říct, že pro jistotu si to potvrzení vytiskněte dvakrát a nechte si ho orazítkovat - ta druhá kopie je pro vás - kdyby zrovna úřad tu noc vyhořel, tak máte doklad, že jste to opravdu podali.

[Michal Kubeček]

On nemusí úřad ani vyhořet, někdy stačí, že člověk drze využije svého práva a místo na místně příslušném úřadě, kam spadá, podá to potvrzení na jiném FÚ, který má pár set metrů od práce. Teprve když jsem jim poslal nascanované potvrzení s razítkem, tak se najednou ten neexistující papír zázračně objevil…

[marbu]

Souhlas, mít jednu kopii pro úřád a druhou pro sebe je základ, ale zapomněl jsem se o tom přímo v blogu zmínit.

[ZAH]

Bohužel, pod linuxem , nefunguje jednoduše ověření pomocí elektronického podpisu. Přikládám odpověď z MfCR.

Dobrý den,
 
jak uvádíte, pro použití kvalifikovaného certifikátu v souboru *.PFX, resp. *.P12 je v aplikacích na Daňovém portále nutné využívat prohlížeč, ve kterém je nainstalovaný applet JAVA. V současné době neznáme pro daný operační systém internetový prohlížeč, resp. jeho aktuální verzi, který applet JAVA podporuje. Využít kvalifikovaný certifikát pro uznávaný elektronický podpis v daném operačním systému tedy nelze. Využít kvalifikovaný certifikát je v současné době možné pouze v systému Windows. V současné době není ze strany technické podpory GFŘ možné určit zda a pokud ano kdy, bude možné opět kvalifikovaný certifikát využít v ostatních operačních systémech.  
 
Možnosti podepsání/odeslání podání v aplikaci „EPO“ jsou v příslušném operačním systému v současné době následující:
 
·         pomocí Ověřené identity podatele způsobem, kterým se hlásí do datové schránky. Návod naleznete zde: http://epodpora.mfcr.cz/cs/seznam-okruhu/elektronicka-podani-epo/jak-podepsat-podani-overenou-identitou-p-4391
 
·         pomocí volby Nepodepisovat podání (neopatřené uznávaným elektronickým podpisem). Daňová podání v aplikaci (EPO) lze odeslat také bez digitálního podpisu. Aby se však jednalo o plnohodnotné podání, je nutné následně vytisknout, podepsat a doručit na místně příslušný FÚ, do 5 dnů od odeslání podání, potvrzení o odeslaném podání tzv. E-tiskopis podání. Ten lze uložit ze stránky zobrazené bezprostředně po odeslání podání. Více informací o tom, kde nalézt tzv. E-tiskopis naleznete zde: http://epodpora.mfcr.cz/cs/seznam-okruhu/navody-pro-praci-v-aplikaci-epo/kde-najdu-e-tiskopis-elektronickeho-poda-4487. V případě kontrolního hlášení však upozorňujeme, že tzv. E-tiskopis podání musí být doručen nejpozději 25. den po skončení příslušného období.
 
Další možností je podepsání podání pomocí uznávaného elektronického podpisu na PC, mimo aplikaci „EPO“ a takto, elektronicky podepsané podání nahrát a následně odeslat již prostřednictvím aplikace „EPO“, tzv. Zrychlené odeslání podání. Podrobné informace najdete zde: http://epodpora.mfcr.cz/cs/seznam-okruhu/elektronicka-podani-epo/zrychlene-odeslani-pisemnosti-nacteni-po-4552.
 
S pozdravem
 
Petr Čejka
Generální finanční ředitelství
Technická podpora:
- aplikací Daňového portálu www.daneelektronicky.cz
- elektronické evidence tržeb www.etrzby.cz
E-mail: epodpora@fs.mfcr.cz
-----------------------------------------------------------------------
Databáze častých dotazů z oblasti aplikací Daňového portálu: http://epodpora.mfcr.cz
Databáze častých dotazů z oblasti elektronické evidence tržeb: http://www.etrzby.cz
 
PŘI ODPOVÍDÁNÍ NA TENTO E-MAIL PONECHTE VE ZPRÁVĚ PŮVODNÍ KOMUNIKACI
Generální finanční ředitelství nevyřizuje anonymní podání, opakovaná podání a jinak nestandardní podání např.
nesrozumitelného anebo zmatečného obsahu, obsahující vulgární výrazy nebo zaslaná pouze na vědomí.
 
From: zahour
Sent: Thursday, April 25, 2019 7:00 PM
To: ePodpora (GFŘ) 
Subject: Dotaz z kontaktního formuláře ePodpora
 
Údaje odeslané z kontaktního formuláře

Jméno a příjmení: Ladislav Žahour
Email: zahour@zah.cz
Prohlížeč tazatele: Firefox 65.0
Operační systém: UNIX (32bit)
Okruh: Elektronická podání (EPO)
Článek: Jaké požadavky musí splňovat uznávaný elektronický podpis použitelný v aplikacích Daňového portálu?

Dotaz:
Počítá se v dohledné době s autorizací podání EPO2 pomocí kvalifikováného certifikátu. Aktuálně je to , na drtivé většině systémů vyloučeno, vzhledem k technologii java appletu. Aktuální verze Javy applet označují minimálně za deprecated. Prakticky všechny prohlížeče ho neumožňují spustit.

[petr_p]

V kterém aktuálním prohlížeči fungují javové applety? Mám pocit, že už jen v Internet Exploreru, který Microsoft dříve či později zařízne, protože má vlastní přebarvené Chromium.

Ale jinak podat s digitálním podpisem lze i v Linuxu. Letos jsem tak učinil také. Finta je v tom, podávací HTML formulář pro nahrání vyplněného formuláře přijímá nejen XML, ale i XML s podpisem zabalené v CMS. Webová stránka, když zjistí, že podpis sedí (a je kvalifikovaný a v certifikátu je bezvýznamový identifikátor), tak nabídne podání s již existujícím podpisem. Na webu je to někde (jinde, než by se hodilo) zdokumentované. Čili postup je následovný:

1. Z webu stáhnout vyplněné XML.

2. XML soubor digitálně podepsat. CMS s podpisem musí být ve formát DER, musí obsahovat podepsaný dokument a certifikát podepisujícího a musí mít příponu p7s. Příklad:

   $ openssl cms -outform der -sign -binary -nodetach -signer cerifikate.pem -inkey private.key -in DPFDP5_form.xml -out signed.p7s

3. Otevřít webovou stránku pro podání, vybrat z možností nahrání vyplněného formuláře a nahrát podepsaný dokument (signed.p7s z příkladu výše).
4. Odpověď webového serveru bude oznámení, že formulář byl digitálně podepsán (včetně údajů o certifikátu) a že může být podán.
5. Když zvolíte podat, dostanete standardní stránku jako po dokončení podání: digitálně podepsané potvrzení úřadu o přijetí, heslo pro sledování stavu podání, opis formuláře a platební údaje.

(Postup píšu z paměti, protože webový server finančního úřadu momentálně nefunguje.)

[Michal Kubeček]

Jestli dobře vidím, tak to je v podstatě to, co v té odpovědi zmiňují:

Další možností je podepsání podání pomocí uznávaného elektronického podpisu na PC, mimo aplikaci „EPO“ a takto, elektronicky podepsané podání nahrát a následně odeslat již prostřednictvím aplikace „EPO“, tzv. Zrychlené odeslání podání. Podrobné informace najdete zde: http://epodpora.mfcr.cz/cs/seznam-okruhu/elektronicka-podani-epo/zrychlene-odeslani-pisemnosti-nacteni-po-4552

[petr_p]

Máte pravdu. V těch nekonečných řádcích jsem to přehlédl.

[marbu]

Každopádně díky, takto jsem si toho všiml taky :)

[Filip Jirsák]

V kterém aktuálním prohlížeči fungují javové applety? Mám pocit, že už jen v Internet Exploreru, který Microsoft dříve či později zařízne, protože má vlastní přebarvené Chromium.

Java byla jediný reálný způsob, jak v prohlížeči něco elektronicky podepsat (když může být privátní klíč na čipové kartě nebo USB tokenu). Jenže pak se Oracle nedohodl s výrobci prohlížečů, ti postupně přešli na nový (bezpečnější) model pluginů a Oracle Java plugin nezaktualizoval. Tím pádem podepisování v Javě přestalo být použitelné, protože nefunguje v aktuálních prohlížečích. Takže jsme se vrátili o 15 let zpět, kdy jedinou možností bylo psát binární pluginy pro každý OS zvlášť.

Chápu, že uživatele to nezajímá, ale provozovatelé webů jsou v téhle situaci také obětí. Hlavní vina je na tvůrcích prohlížečů, kteří efektivně zabili elektronické podepisování v prohlížeči, protože zařízli jedinou reálnou možnost, aniž by nabídli alternativu. Že bude možné podepisovat přímo v prohlížeči se řeší už spoustu let, ale nic reálného se pro to neudělalo. A máslo na hlavě má i Oracle, který na tenhle problém zvysoka kašlal. Ani nebylo nutné zachovávat applety, stačil by Java WebStart.

Takže na jednu stranu chceme všechno elektronizovat, a na druhou stranu jsme se v oblasti podepisování v prohlížečích vrátili o 15 let zpět.

[marbu]

Je tu snaha standardizovat podepisování v prohlížečích přes WebCryptoAPI. Ale nevím v jakém stavu je to prakticky. Druhá věc je, že ten standard zdá se nezahrnuje práci s čipovými kartami (mohl jsem se ale přehlídnout).

[marbu]

ten standard zdá se nezahrnuje práci s čipovými kartami (mohl jsem se ale přehlídnout)

Ah, tak oni tam přímo píšou:

4.3. Out of scope

This API, while allowing applications to generate, retrieve, and manipulate keying material, does not specifically address the provisioning of keys in particular types of key storage, such as secure elements or smart cards. This is due to such provisioning operations often being burdened with vendor-specific details that make defining a vendor-agnostic interface an unsuitably unbounded task.

[Josef Kufner]

Ono to je dobře, že to neřeší. To webové API by mělo mít (a doufám, že má) jen něco jako "podepiš tohle" a prohlížeč už se postará o klíč, certifikát, kartu, token, cokoliv. Je tam příliš mnoho platformě závislých věcí a většinou stačí jen kontaktovat službu, kterou už máš v systému (scdaemon).

[Filip Jirsák]

Že bude možné podepisovat přímo v prohlížeči se řeší už spoustu let, ale nic reálného se pro to neudělalo.

Tím „řeší, ale nic reálného“ jsem právě myslel nehotový standard, který je jen na papíře.

[Mrkva.]

DPH/KH poedituju pldle sablony ve vimu a poslu pres datovku. Zalezitost na 15min :)

[marbu]

Ehm. Ten portál “online finančního úřadu” www.mojedane.cz se od léta neaktualizoval, a ministerstvo z nějakého důvodu novinky prezentuje na nové doméně www.mojedane21.cz. Stručný seznam toho, co by ten systém měl dělat, vypadá zajímavě, ale systém zatím neběží a težko říct, zda se to podaří letos spustit. Ale možná stejně jako minulý rok dojde kvůli epidemii k posunutí termínů ...

[magic2021]

Podívejte se na odkaz https://adisepo.mfcr.cz/adistc/adis/idpr_epo/epo2/uvod/nacteni_souboru.faces

Kdo mi to může říct rozdíl mezi Načíst XML soubor s podáním aplikace EPO2 a Načíst podepsaný P7S soubor s podáním aplikace EPO2?

Děkuji

[marbu]

Jak píšu v blogu, data vyplňená do formuláře lze kdykoli uložit do XML souboru, který lze později do té webové aplikace opět načíst. Použiješ to v případě, když si uložíš rozpracovaný formulář a chceš se k němu vrátit, nebo pokud si předgeneruješ data nějak jinak (např. vlastním skriptem nebo nějakým jiným nástrojem). Po načtení XML souboru pak můžeš formulář editovat a oficiálně podat.

Naproti tomu ten p7s soubor získáš až v momentě, kdy formulář prohlásíš za vyplněný a pošleš ho na finančák. A jak píšu v blogu, ten p7s souboru obsahuje jak xml soubor tak další metadata o podání. Když ho znovu načteš do aplikace EPO, uvidíš informace o stavu podání (např. podací číslo nebo timestamp podání) a opět se můžeš dostat do formuláře a podívat se, co jsi tam vlastně vyplnil. Editovat to ale přímo nelze, protože formulář už byl podán. Pokud potřebuješ udělat v podání změny, musíš podat "dodatečné opravné podání" (nebo jak se to jmenuje).