Portál AbcLinuxu, 26. dubna 2024 00:26
26.7.2020 21:25
| Přečteno: 4972×
|
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.
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.
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:
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.
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ů:
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).
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.crtVidí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-26439395V 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-26439395Jak 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.pemDů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:30Vidí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: OKPojď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 successfulKdyž 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.xmlTakž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
17102653Jak 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ší.
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.
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?
Tiskni
Sdílej:
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...
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.
Financak se tim razitkem priznal ze dostal konkretni verziNikoli. 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 podpisPodpis 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.
31.7.2020 10:51
Josef Kufner | skóre: 70
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á.
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.
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ý:
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
(Postup píšu z paměti, protože webový server finančního úřadu momentálně nefunguje.)
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
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.
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.
30.7.2020 16:11
Josef Kufner | skóre: 70
Ž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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
28.7.2020 08:56
