Technická poznámka: on ten pdf není žádný zázrak. To vůbec není záruka toho, že se na každém počítači zobrazí kompletně, správně, či dokonce i graficky stejně.
Sice když to program vyplivne jako PDF/A, tak tam je šance výrazně větší, ale žádný naprosto spolehlivý zázrak to také není.
Obávám se, že tímto soud (asi nechtěně) otevřel bránu k budoucím sporům.
PS: podle zdůvodnění rozsudku soud zřejmě nepochopil, že tady nejde o lpění na formalismu, přehnané byrokracii atp., ale o technickou záležitost. Takto by (asi) šlo rozsudek zdůvodnit například v případě, kdyby poslali DP v nějaké jednoznačně prohlíčem interpetovatelném formátu. Například jpeg, bmp, raw. Tam není v prohlížeči co zkazit, formát umožňuje jediný správný způsob zobrazení. Což není případ pdf.
Nu, když si dá někdo práci a vychytá to, takhle se s tímto rozsudkem dají dělat podvody za miliardy. Udělat pdf, co se bude správně zobrazovat jen na nějaké konfiguraci, a na většině jinak. Dá to trochu práce, ale on už někdo něco vymyslí.
Soud rozhodl, jak jedině rozhodnout mohl. Pdf v datové schránce je dle zákona ekvivalentní listinné podobě. Jestliže FÚ přijímá dokument "na papíře", pak jej musí přijmout v podobě elektronické. Nakonec přesně z tohoto důvodu byly datové schránky zavedeny.
Ne nikdo takovou konfiguraci "nevychytá" :-)
Jenze prave ze U firem uz FU papirovy dokument neprijima a maji povinnost davat dannove priznani pouze elektronicky. K teto zmene doslo za jedinym ucelem: umoznit pocitacove zpracovani a analyzu priznani.
Hezkym zpusobem jak tomu zabranit je pozadovany formular ulozit jako obrazek soucasti PDF, pak neni mozne dokument strojove zpracovavat. Pokud stat nechce byt za "***" tak upravi legislativu tak aby plnila svuj ucel.
Tak hlavně jde o to, že pokud si vyloženě vynucují nějaký specifický formát, tak by k jeho vygenerování také měli dodat patřičné nástroje, a to pro všechny operační systémy. Oni si ti úředníci totiž často velmi naivně myslí že všichni používají (nebo že dokonce všichni MUSÍ používat) ten jediný správný operační systém, jediný správný účetní program atd atd. Takhle by to opravdu nešlo, takže rozhodnutí soudu je nejen správné, ale jediné možné - jinak by se taky mohlo státu začít stávat, že se např. i menší daňoví poplatníci začnou registrovat k platbě daně v jiném státu (nebo nějaké jiné jevy, někde by se to časem určitě odrazilo).
A dokonce se použitím webových formulářů stáváte účastníkem licenční smlouvy, ve které se protistrana v maximální možné míře zříká zodpovědnosti - byli jste o tomto informování přímo na stránce s formuářem před jeho vyplněním?
https://adisepo.mfcr.cz/adistc/adis/idpr_pub/dpr_info/licence.faces
Jj, jasně, a kolik z těch lidí co podává daňová přiznání tohle dokáže?
Je potřeba, pokud po lidech chtějí přiznání ve specifickém formátu, dodat už hotový nástroj, který bude fungovat všude, to zaprvé. Zadruhé - zříci zodpovědnosti se samozřejmě mohou, ale před každým vyplňováním každého webového formuláře by vás měli v záhlaví stránky upozornit na to, že se stáváte účastníky licenční smlouvy a platí tam takovéto podmínky, ne provádět to stylem "vyvěšen na nástěnce ve sklepě jednoho nejmenovaného stavebního úřadu na Alfa Centauri".
Muj komentar smeroval spis k obsahu clanku, kdy obchodni spolecnost(ne fycizka osoba/obcan) podava danove priznani v PDF. U obchodnich spolecnosti tak nejak predpokladam ze maji ucetnictvi, SW, a i lidi kteri to udelaji. Cely muj komentar smeroval k tomu ze pokud chceme potirat karuselove uniky na DPH tak pozadavek na elektronicky format (XML) ktery se da automaticky zpracovavat mi neprijde neprimereny a prijdemi jednoduchy k integraci do existujicich ucetnictvi.
Fyzicke osoby nemaji povinnost podavat priznani elektronicky a dokonce pokud ano (jeden cas to byl dusledek vlastnicti datovky) tak tam nebyl pozadavek na XML.
To zreknuti se odpovednosti beru jako ochranu, stim ze pokud napriklad v EPO formulari nefunguje doplnovani Danovych sprav, PSZ atd, tak jim to je jedno a neberou to jako prekazku k podani danoveho priznani jinak. Taky bych byl radsi kdyby poskytovali klavlinejsi SW.
že jsem tak smělý, jak se dá něco, co je standardizováno jako ISO standard (ISO 32000) naiplementovat správně tak, že to na jiném počítači nepůjde přečíst?
Ano, nebude-li na cílovém počítači font, použije se jiné dostupné písmo, což nemůže být důvod pro nepoužitelnost daňového přiznání, navíc lze skutečně soubor uložit jako PDF/A, kde jsou fonty obsaženy.
Asi se budu muset ptát pořád dokola. Nějaký příklad, kde stejný SQL dotaz vrací různé výsledky? Rád se nechám poučit.
Dovedu si představit, že všechny typ proprietární nástavby a procedurální rozšíření (typu PL/SQL), který si každý výrobce matlá sám, mohou vracet různé výsledky, protože používají jiné jinak definované funkce. Ale standardní SELECT?
Prostý Select * from xxx samozřejmě funguje vždy, to je OK.
Ale jakmile začnete dávat složitější podmínky, tak jsou nesrovnalosti možné, třeba se mezi systémy liší identifikace prázdných polí. Dále často dělá zmatky ORDER (což je zásadní pro SELECT TOP nn).
A to jsou jen dva první příklady, které mne napadly a sám jsem se s tím potkal, je toho ale více (a pokud se potká víc problémových bodů v složitější složenině, tak se to přímo násobí) .
Samozřejmě, že leccos jde ošetřit, ale nelze popřít, že nesoulady u SQL dotazů tu opravdu jsou.
A nejsou ty identifikace prázdných polí náhodou v rozporu s SQL standardem? (což je to na co jsem narážel)
Jestliže si např. Oracle definuje NULL jako '' zatím co podle SQL-92 jsou všechny prázdné řetězce (0 až x mezerníků) ekvivalentní, pak to celé nějak nesedí. Což ovšem znamená, že není chyba SQL standardu, ale jeho konkrétní implementaci.