Názory k článku Jak EET vidí ajťák aneb Draze zaplacená vražda uživatelské přívětivosti

Nečekejte moderní řešení tam, kde o něm rozhodují dinosauři

Proč nejdeme do ulic proti EET?

To uz je v CR takova tradice, kdyz po 40 letech komunismu to zase ridi stbak. V Brazilii zvysili ceny za MHD o 10% a byl z toho malem prevrat. Ale je to samozrejme asi jedine mozne (zakonne) reseni, podobne jako kdysi nedavno pripomenuta akce Internet proti monopolu.

Otazka je kdo pujde demonstrovat ? Znacna cast zdejsi populace se tesi, jak to "tem podnikatelum/ziv­nostnikum co se topi v penezich" konecne natrou. Ze budou mezi temi co diky tomu prijdou treba nakonec o praci, to jim dojde az pozdeji.

Dneska se demonstruje jen vykonavanim sql prikazu UPDATE FacebookPages SET Like = Like + 1 WHERE PageID = dalsi zbytecna stranka :-)

A Tonda Blaník musí přeci taky něco jíst, musí si nechat přelakovat jachtu a vůbec ....

Tenhle článek celou problematiku strašně zjednodušuje. Jde o to vystavět od základu robustní (a ne nutně funkční) systém. To nejde, aby do toho krafal někdo zvenčí. Pro jistotu to dáme prověřeným kádrům ...

To bude zase krabic s vínem .... :)

K tomu, že jsou potřeba JSON schémata, už se dospělo, následovat budou předpokládám jmenné prostory, pak JPath a transformace.

... az nakonec znovu vynaleznou XML a razem bude JSON "slozity" a nahrazen CSV/TXT soubory.

Nestava se to tu casto, ale tentokrat s Vasi odpovedi plne souhlasim :-)

... asi tak to vidí STBureš.

"Proč nejdeme do ulic proti EET?"
Protože Klausové, Zemanové apod. nás naučili, že demokracie je to, že jednou za 4 roky jsou volby a v mezidobí máš držet hubu a krok, maximálně se můžeme poklonit dočasným vládcům.

Ale tohle neni jednoduche pouziti. Za kazdou ztracenou transakci hrozi pokuta 500 000 Kc, takze radne zabezpeceni je na miste. Zde budou zajimave zaruky dodavatele na ten software, zvlaste na shitiodnich zarizenich typu Android, kde se nic zarucit neda.

Je to i dobry filtr kvality dodavatele, pokud nekdo nezvladne implementovat takto jasne popsany a leta pouzivany standard, mel by jit delat neco jineho.

Daleko horsi je ovsem v clanku zmineny zcela nedomysleny princip opakovani zasilani transakce pri vypadku, kde opet hrozi ona pokuta.

Cože, vy chcete dělat nějaký IT systém za nějaké plesnivé milionky?

To si děláte srandu, ne? IT systému musí stát miliardy!

A teď mě omluvte, jdu si za miliardu koupit Windows.

>Ze budou mezi temi co diky tomu prijdou treba nakonec o praci, to jim >dojde az pozdeji.

Nedojde jim to nikdy, nanejvys oznaci noveho vinika sveho nestesti.

Ano, CORBA, IDL, DCOM ... masakr.

Kazdy problem lze ale zjednodusovat jen do urcite urovne.

Treba zminene SOAP webove sluzby. Kompletni W3C specifikace je hruza a je v ni plno zbytecnosti jako RPC/Document model atd. Proto vznikl WS-I Basic Profile, ktery vybral podmnozinu rozumnych vlastnosti, na ktere se shodli vsichni. Takze podpora SOAP sluzeb casto neznamena celou specifikaci, ale prave tuto rozumnou podmnozinu, pritom je to stale v souladu s obecnou specifikaci.

Tohle je podle mne lepsi cesta, nez JSON ktery se hodi pro inetrni komunikaci ve webovych aplikacich, ale ne jako obecne API, ke kteremu se dnes zneuziva. Je prilis primitivni a nedospely, prave kvuli neexistenci metadat, ktera vede k jiz zminene implementaci stylem: tak dlouho matlame pokus/omyl, az to domatlame. Tolik zbytecne promarneneho casu ve srovnani s WSDL a jeste chaby vysledek.

Dnes je jediná rozumná technologie, kterou má smysl použít, a to je blockchain. Odpadly by všechny potíže s dočasnou nedostupností.
Ale samozřejmě mnohem rozumnější by bylo to vůbec nedělat. Proč nejdeme do ulic proti EET?

Běda, jak o technické, (a nejen technické), věci rozhoduje pologramotný politik, kterému radí jakákoli lobby! Jenže státní peníze přece nemůže dostat někdo, kdo není kámoš!

LPAIR :-D

Dál jsem nečetl

balkánský buzerační systém EET a STBureše i Sobotku, toho budu volit. A ne řešit pitomé šifrování naprosto zbytečného a nefunkčního systému.

A když už "narovnat" podnikatelské prostředí, pak zrušit dotace, daňové úlevy a prázdniny pro koncerny a firmy oligarchů. Živnostníci možná neodvedou řádově miliardy, oligarchové ale neodvedou řádově desítky až jednotky stovek miliard. A přesto jim MF ani policie za krk nedýchá…

Nejsem, dany problem jsem si samozrejme vyresil. Protoze je to jinak nejlepsi soucasna existujici platforma :-)

"Nobody ever got fired for buying IBM."

Souhlasim, JSON by byl navrat o 10 let zpet, protoze REST nema (zadny standardni) popis metadat kontraktu podobny WSDL. V kazdem rozumnem vyvojovem prostredi automaticky vygenerujete z WSDL typovy klientsky kod. Zadne zkouseni stringu pokus/omyl jako v REST/JSON, ktery je obliben hlavne u programatoru kteri maji problem pochopit i XML a jeho schema. Takze vyber WS-Security je prekvapive dobry.

Implementace muze byt komplikovana z jineho duvodu (viz dale), ktery ovsem autor clanku neobjevil :-) Vlastni WS-Security standard v .NETu i Jave by nemel byt problem, SHA-256 implementace je take v poradku (zatim jsem v .NET nemel problem, jde pripadne nahradit vlastnim).

Zrada bude jinde. WS-Security neresi jen zabezpeceni requestu, ale i response. A ta je podepsana jakym certifikatem ? Modri uz vedi :-)

Deti zlaty, co nechapete proc vubec eet...proc statni pokladna. Proc zakladni registry a utajeni RC. Proc open card atdatd. Aby bylo co delat preci, aby byl duvod proc mlatite do klavesnic a stahujete novou verzi elastic search. Zaroven nekomu pritece neci na konto.

1) To že to je tvz. 10 staré řešení není nijak na škodu - právě že to je výhoda
* má vychytané většinu problémů které mají vždy nové řešení
* SOAP má v sobě i Java ve formátu jax-ws jako leader korporátních systémů, a rozhodně neplánuje jej rušit - je to možná záruka dlouhodobé funkčnosti
2) že s tím některé jazyky budou mít problém se dalo čekat, otázkou právě bylo které.
3) A že se budou muset certifikáty po určité době obnovovat?

Faktem je že řešení které MF navrhlo umožnuje schopnému programátorovi si vyvinout naprosté své vlastní řešení a zadarmo. Ale chápu, že někteří kteří se těšily na zisky jsou nasraní.

Tak se to jeví jen v rámci tvojeho technologického světa. Napříč to nechodí, protože specifikace jako WS-* obsahují příliš stupňů volnosti - jsou nedokonalé. A ufoni u jiných světů to prostě pochopili jinak. Asn.1 trpí v reálu stejným problémem, jak soap i json, a to je význam aplikačních dat. Ale to by snad u přenosu jedné částky v korunách neměl být takový problém?! Pak určitě zvolit nejjednodušší protokol, třeba řádky oddělené crlf. A v ústavě přikázat, že ministerstvo musí k specifikaci přidat funkční oss klienty pro 90% zařízení na trhu, ono je to bájení o IBM přejde.

Opravdu Vám vrátil Babišov FIK na zprávu podepsanou pomocí SignSoapMessage ? Já stále dostávám jen odpověď 'Neplatny podpis SOAP zpravy'. Ale stejnou odpověď (Neplatny podpis SOAP zpravy) dostanu, když jim zašlu jejich ukázkouvou zprávu CZ00000019.va­lid.xml např. přes WebRequest.. Evidentně zprávu přečtou a zvalidují, protože nehlásí 'XML zprava nevyhovela kontrole XML schematu' . Ale proč se jim nelíbí podpis na jejich vlastní zprávě, kterou prezentují jako ukázkově validní ?..

,, jinak mám stejnou zkušenost se zasíláním dotazů ne jejich helpdesk. Jen arogance a odmítavá odpověď. Oni dobře vědí, proč na konci mejlu píší vždy : Generální finanční ředitelství nevyřizuje nestandardní podání např. obsahující vulgární výrazy... Člověk má sto chutí právě takový mejl jim napsat :).

Z dokumentace to neni zcela jasne, ale WS-Security umoznuje, ze response je podepsana jinym (serverovym) certifikatem nez request. Coz je scenar, ktery neni (napriklad v .NET) standardne podporovan.

Souhlas. Já bych například byl pro zavedení eskymáckého testu pro vstup do penze z jednoho starého vtipu. Pošleš aspiranta na penzi přeplavat Vltavu v Praze. Pokud jí přeplave, může ještě pracovat a pokud ne, tak je o penzistu míň.

Zverejneni ukazkovych implementaci pro vetsinu beznych vyvojovych nastroju, vcetne celeho procesu opakovani transakce pri chybe komunikace bych povazoval za povinnost. To je samozrejme.

Dalsi vec o ktere se nemluvi je archivace komunikace (na jake ovsem urovni ?) pro pripad sporu s uradem. Platce DPH lze kontrolovat az 10 let zpetne, takze to bude pekny balik dat.

Binární data jdou do XML vložit pomocí sekce CDATA.

Ano, už jsem videl hodně pomýlenců, co si toto mysleli, a pak koukali jak tele na nová vrata, že ono to ne a ne a nefunguje.

Pro začátek doporučuji XML Standard a v něm věnujte pozornost odstavci 2.2.

Proc se tocit v kruhu XML, JSON, kdyz tady mame radu let proverene ASN1?

V ASN1 je specifikovan/im­plementovan X509 (cerifikaty, klice), vlasni podpis zprav, cele SSL/TLS, proste vse ...

Navic ASN1 je prefixova notace - nemusim hledat 'parovy' koncovy element - hned na zacarku vim delku. Tudiz odpoda nutnost `escape` sekvenci ala & lt ; & gt ; & amp ; .... Vse je 1:1 :-)

Proc vymyslet neco nove s XML, JSON a pak specifikovat, co vsechno se vlastne podepisuje (hmm, mame string - binarni/UTF8-data, prevedeme to pro podpis do BASE64? nebo HEX? i s BOM? a Unicode ala Micro$oft v little-edianu)? A co `escape` sekvence ala `& amp ;` - ty podepiseme jako `&` nebo jako `& amp ;`?

Hmm, ale vydelek podpisu je binarni vec, kterou do XML nevlozime - take zase prevest na HEX nabo BASE64 .....

P.S. Otazka za 100 bodu - jak vlozit inteligentne do tohoto xml bazmeku & amp; a podobne?

Objemna binarni data lze v SOAP web service efektivne prenaset pomoci MTOM. Nicmene to asi neni zrovna v pripade EET ten aktualni problem.

Nesmí se taky zapomenout na vlastnost HTTPS "Přihlášení certifikátem". Pak bude jakékoliv podepisování XML zbytečné.

1) eet certifikaty budou trilete
2) u el. podepsanych dat lze vyuzit casovych razitek pro zachovani dlouhodobe prokazatelnosti platnosti v dobe vzniku/overovani podpisu

Jenze certifikat (alespon ve Windows) patri do uloziste, protoze tam je centralne bezpecne ulozen. A ne do nejakeho externiho souboru. Znalost prace s ulozistem je opet ten filtr zakladnich znalosti, nezlobte se.

Pak resite asi toto http://stackoverflow.com/a/21435041

GFŘ by si celý proces zjednodušilo, kdyby uveřejnilo příklady zdrojových kódů pro .NET, Javu a C, tedy dnes nejpoužívanější jazyky pro tvorbu pokladních systémů. :-)

To uz jsem tu psal, ze toto bych povazoval ne jen za samozrejmost, ale dokonce zakonnou povinnost. Kdyz si stat vynucuje pouziti podobnych technickych prostredku, musi rict i jak presne. Odkazy jen na strohe specifikace nejsou dostacujici.

Ostatne tohle by mela byt jedna z veci u EET, kterou by novinari meli peclive sledovat a kritizovat. Bohuzel malokdo tomu ve skutecnosti rozumi.

O offline rezim musite skemrat a muze byt uradem bezduvodne zamitnut. Opetovne muzete zadat az po 60 dnech od zamitnuti nebo tak nejak.

Ostatne satelitni propojeni je prece vsude, ze.

Myslím, ze se pletete. Jedná li se o chorvatský model, bude se hezky sčítat, kolik kdo utržil a následně porovnávat se zaplacenými daněmi a také s evidovanými fakturami. Různé disproporce ve srovnáních pak budou zdrojem dat pro revize. Relační uložení dat je celkem asi na místě. Je na čase začít vymýšlet alternativní měnu... A to zejména až pan ministr prosadí další díl skládačky matrixu a to centrální evidenci účtů a aktuálních zůstatků. Další krok už bude zrušení hotovosti...

a pak uz jen zvysovani dani az na 99,9%

Tak jsem profesně nucen se zabývat implementací EET, a asi si hodím mašli. Už jen první čtení: v příkladu SOAP zprávy mají finančáci XML datový údaj 2016-09-19T19:06:37+01:00 . Jestli umím počítat, 19.9.2016 je den kdy platí letní čas. V dokumentaci se však praví, že časová zóna u datového údaje musí být povinně uvedena a musí splňovat to, že datumy z letního času budou mít zónu +02:00 a datumy ze zimního času zónu +01:00. Tak teď fakt nevím ... Normálně knihovny vygenerujou zónu v textu podle data kdy text vytváříte, a ne podle hodnoty toho zapisovaného data. No a až vyřeším tohle, tak ještě budu bádat nad SHA256WithRSA :-)

..už mi to funguje.. Potvrzuji, že SignSoapMessage je skvělá implementace. Já jenom loadoval podepsanou message do WebRequestu přes XmlDocument místo abych ho natáhnul rovnou nativně přes FileStream..

Nemusí, zkuste třeba toto:

RSACryptoServi­ceProvider csp = null;
csp = (RSACryptoSer­viceProvider)cer­t.PrivateKey;

var cspEnh = new RSACryptoServi­ceProvider().CspKe­yContainerInfo;
var cspparams = new CspParameters(cspEn­h.ProviderType, cspEnh.Provider­Name, csp.CspKeyCon­tainerInfo.Ke­yContainerName);
csp = new RSACryptoServi­ceProvider(csppa­rams);

Ahoj,
rád bych s tebou probral další možnosti knihovny. Můžeš mě prosím kontaktovat na kahatek@seznam.cz?

Děkuji mockrát

Servisní technik výpočetní techniky, správce síťí a SW vývojář

Připojuji zde malou část z komunikace s podporou MFCR, jedno je zapracovat EET do programu, ale problém je neexistence podpory pro SW vývojáře a jejich včasná informace o změnách, což by za provozu mohlo způsobit nefunkčnost jednotlivých systémů protože MFCR odpovídá, že nebude zasílat informace o změnách registrovaným SW vývojářům atd. Uvádím komunikaci bez jmen a důvod je jednoduchý, snažím se něco změnit a přispět k tomu a hlavně pomoct malým firmám, ale ať jsem napsal na různá místa nedaří se změnit přístup k EET ze strany MFCR. Není možné, aby SW vývojáři měli u zákazníků EET řešení, kde zároveň nebudou informováni včas od podpory MFCR, což může vyústit v kolabs klientských řešení, asi to možné je ...

Zde cituji z komunikace:

Dotaz SWvývojář:

Doopravdy mě již EET rozčiluje, člověk si musí cucat z prstu příkazy a knihovny, které chybí ve vývojových prostředích a operačním systému a když se už člověk někam dopracuje, náhodou zjistí, že už je nová verze EET na které nefunguje stará verze EET a vy neuděláte ani bůůů, to znamená nezašlete ani žádný informační e-mail, že byli v EET provedeny změny !!! Omlouvám se, ale už mě EET doopravdy dost rozčiluje.

Nesmyslná složitost, která vyhovuje pouze velkým dodavatelům HW, neopodstatněné náklady pro podnikatele např. v souvislosti ukončení podpory protokolů u Windows XP atd. což v konečném souhrnu podstatně zvyšuje náklady.

Prosím zamyslete se nad svým postupem a když už nechcete vyjít vstříct podnikatelům a upravit svůj systém, zasílejte aspoň informace o změnách v systému EET.

Odpověď podpora MFCR:

Vážený pane,

ke zveřejnění nové verze Playground došlo v tomto týdnu.
Informace o zveřejnění této verze byla k dispozici na stránkách Finanční správy a www.etrzby.cz od 1.8.2016.
Co se týče rozeslání informace vývojářům, není toto možné, z důvodu neexistence distribučního seznamu vývojářů pokladních zařízení. O zřízení takového distribučního kanálu v současné době Finanční správa neuvažuje. Pokud se vaše zmínka týká registrace do distribučního seznamu pro "odběr informačních zpráv", pak se však tato služba od jejího počátku týká výhradně "vývojářů SW určených pro odesílání elektronických daňových podání". S tímto se k této službě příslušní vývojáři registrují. Tato služba není určena pro zasílání informací o evidenci tržeb.

Rád bych také uvedl, že v současné době je možné používat Playground verze 2 a 3. Pro hladký přechod na novou verzi bude do 10.9.2016 podporován paralelní provoz předchozí verze rozhraní na původním URL.

Na straně 2 dokumentu "Formát a struktura údajů o evidované tržbě a popis datového rozhraní pro příjem datových zpráv evidovaných tržeb v3.0" jsou uvedeny změny vůči poslední publikované verzi (2.0).
Oproti předchozí verzi, obsahuje nová verze změny, např.:
- Zasílání informací o nalezených nekritických chybách v potvrzovací zprávě.
- Upřesňující a doplňující informace v jednotlivých bodech dokumentu "Formát a struktura údajů o evidované tržbě a popis datového rozhraní pro příjem datových zpráv evidovaných tržeb"

Odpověď SWvývojář:

Děkuji, ale přečetli jste si co jste napsali ? Píšete, že je neexistence distribučního seznamu vývojářů a vzápětí zase píšete o distribučním seznamu pro "odběr informačních zpráv", kde se však tato služba od jejího počátku týká výhradně "vývojářů SW určených pro odesílání elektronických daňových podání" a nemyslíte, že všichni tito vývojáři budou též muset řešit EET. Samozřejmě jsem tam mezi vývojáři registrován a má připomínka se samozřejmě týkala tohoto. Docela by mě zajímalo, který vývojář nebude muset řešit EET, takže Vás prosím uvažujte o zasílání informací vývojářům. Nebo MFCR jsou dvě nezávislé organizace, které naprosto nespolupracují to snad ne. Pro jednoduché vysvětlení např. uvádím (jen pro názornost a pochopení):

Kontrolní hlášení patří pod MFCR1 a EET patří pod MFCR2. Pak už mě napadá jediné dle odpovědí, tajný projekt, který je cílen pro dodavatele HW ?

Omlouvám se, ale i když jsem minulý týden zkoumal a testoval Váš web podrobně nenarazil jsem na informace o nové verzi, až včera, respektive dnes jsem náhodou, protože jsem potřeboval nějakou informaci narazil na novou verzi v3.

Prosím, prosím jestli má náš stát jedno MFCR posílejte nám registrovaným vývojářům aspoň informace o změnách. Děkujeme.

V to sice nedoufám, ale kdyby jste zaslali nějaké knihovny nebo návody pro různá vývojová prostředí, tedy Váš dodavatel systému, tak mnohým uděláte neuvěřitelnou radost a pomoc bude cennější než jakákoliv finanční dotace.

Odpověď podpora MFCR:

Dobrý den,

jak jsem již uvedl, "odběr informačních zpráv", se týká výhradně vývojářů SW určených pro odesílání elektronických daňových podání.
Takto je možnost odběru informačních zprávy prezentována. Zveřejněná informace o možnosti registrace nikde a nijak neuvádí, že se budou zprávy týkat informací o evidenci tržeb.
Skutečně si nemyslím, že většina ze stovek registrovaných vývojářů vytváří SW pro "tvorbu EPO podání" a zároveň bude programovat pokladní zařízení.

Nicméně děkujeme za zaslaný názor, kterým se budeme zabývat.

Odpověď SWvývojář:

Prosím, vy to ve své odpovědi nevidíte a stále v tomto duchu odpovídáte ?

Nemyslíte si, že většina ze stovek registrovaných vývojářů vytváří SW pro "tvorbu EPO podání" bude zároveň programovat pokladní zařízení ? V tom máte určitě pravdu, nebudeme programovat pokladní zařízení, jak si to přejete. EET a tato komunikace má snahu podnikatelům prodat mnoho HW zařízení, které v konečném řešení stejně vyhodí a to z důvodu, že mají software, který s těmito zařízeními nekomunikují a musí mít zapracované EET v programovém vybavení. Bohužel ta celá většina stovek registrovaných vývojářů má u zákazníků svůj software a dá se předpokládat, že každý kdo řeší např. kontrolní hlášení musí řešit i EET, aspoň já nevím o nějaké vyjímce pro podnikatele, kde by se mohli rozhodnout jestli chtějí či nechtějí EET. Nám vývojářům jsou vaše připravovaná a propagovaná zařízení nanic, omlouvám se za toto české vyjádření odpovědi. Musíte si uvědomit, že nejsme v době před mnoha lety, kdy se řešilo zavedení EET přes tiskárny s touto podporou. Dnes se vše většinou řeší přes software na což jste pozapomněli a přesto, že z neznámých důvodů (možná zjištných) je směrována podpora pro výrobce HW zařízení a ne pro vývojáře SW.

Vaše HW zařízení si zakoupí pouze, teď to přeženu, tak mě nechytejte za slova: p.Babiš, aby se ukázal v TV a dále pár menších ojedinělých trhovců atd. bez provázání na další software a skladové hospodářství a pak samozřejmě podnikatelé, kteří podlehnou Vaší reklamě a zakoupí HW zařízení, kam za nimi přijdeme mi vývojáři a řekneme, proč nevyužívají svou starou pokladní tiskárnu, když jejich programové vybavení vše zařídí, respektive z Vaší podporou možná všichni padnou a pro své programy EET nedořeší a pak budeme jako v kocourkově:

1. podnikatel si nacvaká ve svém systému SW paragon

2. po druhé ho nacvaká v HW zařízení, bez jakéhokoliv provázání atd.

Proč z Vaších odpovědí stále vyplívá něco jako zde uvádím ?

Prosím, prosím, prosím zaměřte veškerou podporu a pomoc pro nás vývojáře SW, HW firmy jsou většinou velké firmy, které neúspěch v prodejích finančně přežijí.

Ještě nevíte co udělat ? Pro začátek by stačilo, zasílat nám vývojářům informace přes již existující kanál podpory MFCR, který by měl být jednotný pro celé MFCR.

Dále by jste se z podpory a vývoje HW zařízení mohli postupně přeorientovat na podporu SW programového vybavení. Což znamená jednoduše řečeno a nechytat za slova kvůli bezpečnosti, neříkám jak řešit jen upozorňuji na problém, který se týká velkého množství i lidí a firem, kteří si pro zálibu dělají pro firmu vlastní SW.

Každý zvládne komunikaci ze službou, práci na obsahu XML, ale zničující je šifrování, proč ? např. základní API od operačního systému CAPICOM umí sice otevřít certifikát, ale postrádá vaše podmínky šifrování a zde začíná problém. Tuto část práce s certifikáty a šifrování by jste měli nahradit či změnit, jak nechávám na Vás, ale buď udělat variantu šifrování, která se zvládne přes základní API operačních systému Windows jako je API a to např. CAPICOM atd. nebo certifikáty se šifrováním nahradit jiným způsobem (možnou variantou) nebo aspoň se zaměřit na podporu knihoven a příkladů atd. Toto je pouze námět a každopádně nechci zasahovat do vašeho řešení, ale upozorňuji na Vážný stav nepřipravenosti plynoucí z Vámi zvoleného řešení. Dělám IT podporu a servis firmám a vídám to denně.

Nešlo by zdrojáky hodit na github a doplnit licencí? Už vzniklo několik projektů v různých jazycích, které EET ukázkově řeší. Pro příklad:

- https://github.com/ondrejnov/eet (PHP, MIT license)
- https://github.com/novakmi/eetlite (Groovy, MIT license)
- https://github.com/l-ra/openeet (Java, C#, UNIX shell, Apache 2.0 license)
- https://github.com/mirus77/DelphiEET (Delphi, MIT license)
- https://github.com/todvora/eet-client (Java, MIT license)

Díky!

Já jsem dokonce na podporu GFŘ poslal odkazy na ukázkového klienta s prosbou, ať to zveřejní. Níže je odpověď. To je prostě ostuda neuvěřitelná pro všechny, kdo tam pracují.

Vážený pane,

velice děkujeme za zaslaný podnět, nicméně zveřejnění uvedené informace na webu www.etrzby.cz není možné.

Finanční správa má zájem na vytvoření kvalitních klientských aplikací pro EET. Vámi odkazovaná informace může určité skupině vývojářů v jejich tvorbě pomoci. Finanční správa však nedokáže posoudit kvalitu dané informace, resp. vzorové implementace. Zveřejňování podobných informací nespadá do rámce poskytované podpory vývojářům „pokladních SW“.

Zveřejněním odkazu na oficiálních stránkách www.etrzby.cz by však Finanční správa za kvalitu produktu fakticky převzala odpovědnost a to jak v daný okamžik, tak i v budoucnu, přičemž na vývoj daného produktu nemá žádný vliv.

S pozdravem

Radek Korčák

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

zažádejte si o šablonuu podle zákona 106 o informacích pokud ho už mají tak ho musí zveřejnit

doporučuji vyzkoušet www.eetgo.cz - internetovou aplikaci ZDARMA pro všechny, kterých se nově týká EET a nechtějí utrácet za komerční řešení. Pokud nepotřebujete pokladnu, či drahá řešení, stačí využít aplikaci EET GO, která je zdarma. Zaevidujete platbu a fakturu vytisknete.

našel jsem parádní stránku kde srovnávají více řešení pro PHP EET … koukněte zde http://www.eet-php-reseni.cz/eet-php-knihovna-_modul_—srovnani

Žumpa žumpou zůstane ®

No to moc vtipné není, on by ji každý přeplaval :-)))

Coz u podepsanoho XML nejpozdeji za rok plati take.

No nevim, ty argumenty jsou dost na vode. Spis mi to prijde jako psani ve stylu byt dulezity za kazdou cenu. Nevim, kolik modernich architektur autor videl a kolik opravdu velkych aplikaci navrhoval. Implementace podepisovani a overovsni podpisu je bez spravneho navodu jak a s kterou knihovnou opravdu trochu onanie (jak v .netu tak v jave), ale pochybuju, ze k tomu navod pro vyrobce aplikaci nedaji. To by si fakt dost nasrali do vlastniho hnizda. Autor naznacuje automatizaci obnoveni certifikatu a odkazuje se na ssl anywhere. vzhledem k tomu, ze sluzba je zatim spis v plenkacha nikde neni napsano, ze bude fungovat i za 5 let a zaroven neni v tuto chvili jeste dostatecne duveryhodna, povazuju to za spravne rozhodnuti. A automatizace vydavani a nastaveni certifikatu - no proc ne, ale nejsem si jist, kolik ca neco podobneho umoznuji. autorovi spis uniklo, jestli budou vedeny nejake seznamy trusted ca. Zaverem vyjmenuje naklady na hw a z placu vysype par cloudovych technologii bez naznaku smysluplnosti jejich vyuziti. Pouziti microservices? podle ceho soudi, ze tam aplikacni architektura neni microservices orientovana, pokud ma jasnou indicii, sem s ni. Cassandra znamena multinode databazi pro lepsi skalovatelnost a distribuovatelnost formou kvora. Vzhledem k uvazovane geolokacne centralizovane architekture (rozumej v jednom dc, a tedy jeden s nejvetsi pravdep. v 1 node)v tom absolutne neni problem a vzhledem k predpokladatelnemu mnozstvi dat je i zbytecne uvazovat jinak. Dse? stejne jako cassandra (nehlede na to, ze datastax a jejich stack je defakto cassandra a par dalsich produktu, pospojovanych do stacku, ale prijde mi, ze to autorovi unika). Elatic to same. Elastic je dokumentova db, jejiz hlavni vyhoda, ktera se pouziva prevazne rychle vyhledavani v nerelacnich datech. Jinymi slovy - strkam tomu nejak strukturovany dokument, elastic to indexuje a je schopen v tom uzasene rychle vyhledavat, ale relace z toho uplne poskladat neumi, coz bych rekl, ze je hlavni podstatou eet (davat dohromady ma dati a dal). Kafka? to same. Kde a proc message bus? Jak muze vedet, ze vnitrni architektura neco takoveho neobsahuje (i kdyz osobne si uplne nedovedu predstavit, proc by vzhledem k velikosti mela, pokud opravdu nejedou na microservicach). Pokud by tim chtel resit multinode architekturu, samotna kafka bez neceho jako zookeeper nesmysl. Spis mi prijde, ze autor chtel napsat sokantni clanek.
autoruv navrh na automaticke vyzadani certifikatu je imho potencialne celkem nebezpecna vec. Spis me napada daleko dulezitejsi vec: jak bude probihat autentizace? Jestli pouze pomoci certifikatu, neni to malo? Jak se bude system branit proti pripadnym zcizenim privatnich klicu? Pokud budou vyzadovany njake dalsi udaje, bude se drzet sessiona nebo bude probihat autentizace per request? Pokud per request, prijde mi to jako performance killer. Pokud bude drzena sessiona, bude nejaky session management?
Jinak ten clanek imho neni odborny, jen ma pusobit odborne na laickou verejnost, coz se podle nekritickeho primuti ocividne povedlo

Dobrý den,
trochu nám uniká motivace k zavedení propustných kontrol č.1 a 3 v rozhraní v3. Znáte ji? Nejde v důsledku o hrubou bezpečnostní díru (kontrola č.1), resp. popření smyslu PKP (kontrola č.3)? Předem díky za názory.

Problém není EET, problém je, že stát disponuje příliš mnoha penězi, a pomocí nich vytváří širokou parazitní vrstvu. Většina lidí si nedovede svůj život bez paternalistického státu vůbec představit. A znamenalo by to třeba vzdát se penzí.

tak ono cele IBM je zamrzle v dobe pred 10lety, tady se moc neni cemu divit

no a co proč jsi připodělaný z NET? Však to na MS platformě nemusí být vůbec závislé.

3 roky neprezije pouzity algoritmus ...

Mně se ty navrhované technologie také úplně nezdají. Podle mne je ale podstatné:

Jak to, že tato veřejná diskuse probíhá až po zadání výběrového řízení? Pár měsíců před dodávkou řešení? Pak je celkem logické, že zadání je špatné a nahrávající jednomu dodavateli.

A konkrétně mě napadají tyto problémy:

Bude moct živnostník prodávat i při výpadku internetu? Někde jsem slyšel že ne, jestli to je pravda, tak to fakt zrušte!

Obsahuje systém řešení pro případ, že data v nějakém období jsou chybná? (Například kvůli úniku a zneužití přihlašovacích údajů). Je možnost odeslat z pokladen opravné podání?

Ja nehodnotim EET, ale obsah toho clanku, ktery se snazi kritizovat technicky obsah, pricemz vypichuje naproste marginalie, podstatne veci miji a legitimitu se snazi dodat vyjmenovanim technologii, kde autor krom nazvu a faktu, ze v cloudu ted frci, nevi vubec nic. Jako maly hint taky staci, mrknout se na linkedin - autorova zkusenost s velkymi systemy je spis nulova.

Duvod, ze jsou narozdil od JSON a temer nepouzivaneho WADL pouzitelne ? Nevim co s tim ma spolecneho OSS, tam snad neumi implementovat obecne a zcela otevrene standardy jako WS-Security ?

Spis mam pocit, ze se zde narazi na limity znalosti a schopnosti. Ono treba parsovat XML regexem v PHP jako text po radcich ma jiste limity :-)

Neni spis problem jinde ? Pouzitim normalniho vyvojoveho nastroje prece nemusim tohle vubec resit (coz neznamena, ze nemam o te technologii neco vedet). Zkratka naimportuji WSDL, ziskam typove bezpecny klientsky kod (interface, metody, typy), nastavim certifikat a mohu volat sluzbu. O vlastni format a zabezpeceni XML zprav se uz nemusim starat a uz vubec nemusim neco zkouset stylem pokus/omyl.

Prave to je prinos vyspelych a standardnich (a otevrenych) technologii.

Receno s klasikem: Kdo se zeni s duchem doby, byva brzy vdovcem....

co nejlepe, nejefektivněji!

Nebudme naivní. Na nebohé ajťáky přece nebude brát ohled

Jen přidám drobnost z vlastní zkušenosti:
Při generování testovacího certifikátu pro právnické osoby (jde o certifikát s platností od 19.5.2016) byl jako základní použit modul Microsoft Enhanced Cryptographic Provider v1.0 (tedy ProviderType 1), který ovšem nepodporuje podepisování s využitím hash algoritmů rodiny SHA-2 (tedy ani požadovaný SHA256withRSA). Sice by bylo vhodnější již při generování použít Microsoft Enhanced RSA and AES Cryptographic Provider (tj. ProviderType24), nicméně GFŘ na to neslyší (odpověď podobného charakteru jako výše, jen trochu zmatenější). Problém lze samozřejmě vyřešit změnou certifikátu před samotným podpisem, ale je to zase pár řádků kódu navíc.

Slušné by bylo s každou novou verzí zveřejnit referenční klientská řešení pro obvyklé platformy, které tak jako tak GFŘ musí mít (tedy aspoň doufám). Nebo aspoň zajistit solidní technickou podporu (mě odpověděli za 33 dnů). No nic, další stížnosti až u volební urny...

Vám palec nahoru, pane Hájku! Stejně jako většina dalších vývojářů jsme nemohli čekat na to, až někdo zveřejní vlastní řešení, srovnání je pro nás ale poučné.

Vaše řešení považuji za dobré, jen bych si dovolil poznamenat, že při validaci odpovědi (verze knihovny 1.5.0.0) nestačí ověřit důvěryhodnost podpisového certifikátu serveru a platnost samotného podpisu (předchozí ukázkové řešení na GitHubu neřešilo ani tohle), klient by měl ještě ověřit, zda jde opravdu o certifikát GFŘ. Vzhledem k HTTPS jde jen o další úroveň ochrany, specifikace Playgroundu to ale předpokládá.

Také mě překvapilo mě, že ačkoli volíte více low-level řešení než my (WCF, mírně znásilněné), máme za shodných podmínek v průměru 2x kratší odezvy (včetně všech kontrol a podrobného logování).

Každopádně díky, pěkný den a hodně zdaru s/navzdory EET.

Jen pro pobavení, psal jsem jednoduchý dotaz na eet helpdesk. Po třítýdenním urgování mi odpověděli toto:

Dobrý den,

níže předáváme vyjádření odborného pracoviště:

Omlouváme se, ale Finanční správa neodpovídá na dotazy tohoto typu. Finanční správa opodvídá na dotazy metodického a technického charakteru, které se přímo vztahují ke zveřejněným specifikacím a funkcionalitě Playgroundu, resp. systému elektronické evidence tržeb. Součástí podpory není poradenství k software pokladních systémů, podpůrným knihovnám a vývojovým nástrojům, ani výklad nebo postup při aplikaci obecně platných technických standardů.

S pozdravem

Irena Vaňková
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

chtělo by to svrhnout vládu...

Ano, je to jen o tom, zda to vedet chteji.

Embedded aplikace, tam nemam vubec predstavu, moznosti tech dnesnich hw pro IoT me prijdou pro to dostatecne. Nakonec i ta XML zprava je jen shluk bytu, ktery podepisete. Idealni by asi bylo poskytnout EET rozhrani v obou technologiich, ale to by stalo dalsi stamiliony :-)

Na neco takoveho kde jde nakonec o penize bych se to Android neodvazil pouzit. Tam mi neni jasne, jak chce dodavatel poskytovat nejakou zaruku funkce, zvlaste opakovani odeslani zpravy pri vypadku (Android se mezitim 20x zadre a bude treba restart, zprava se neulozi). To je proste technologicky odpad s nulovou spolehlivosti a bezpecnosti, vyrazne horsi moznost nez ty jednoucelove embedded aplikace.

Pan v jende casti zminuje M$ windows, tedy hracku s totalni hrackou zvanou .NET ... a na konci uvede, ze se na to koupi IPM Power arch, tedy CPU, na kterem bezi jen AIX a Linux, ale nikdy ne windows.

Ano IBM Power je draha arch a jedina jeji vyhoda je LPAIR a s nekterymi poli moznost omezovat/garantovat prostredky az na urovni dokovych IO operaci, coz jine virtualizace neumi.

A ano IBM Power arch je velmi draha a v mnoha pripadech postrada vyznam, vyznam mela v dobe, kdyz mel intel velmi pomale sbernice, nemel switchovane sbernice na CPU (tedy ji ciste rozdelil na pocet CPU bez ohledu, zda tam neco bezelo) a hlavne intel nemel garanci provedenych instrukci, tedy jste meli sice minimalni, ale zato sanci, ze se nejaka instrukce neprovede, ac si myslite, ze se provedla.

Jenze dneska ma intel i AMD ty same vlastnosti jako RISC vcetne garance provedene instrukce a switchovane arch. vcetne slusnych sbernic jak na CPU, tak RAM i karty.

Ano IBM power masiny maji moznost vymeny CPU za behu atd. ale od toho je dnes cluster, krom toho, ze HP to ma i na x86, ale pri cene PC serveru si jich koupite klidne 10, nebo 4 extremne naslapanych.

Dalsi vyhoda IBM power arch. je ta, ze tam date vice CPU a tedy mate extremne vykonnou masinu, ale v dobe zvladnutych clusteru to uz resi malokdo.

Ano, coz je presne WS-Security. Proc zase vymyslet znova neco co uz je davno vymyslene, standardni, overene, a hlavne v praxi pouzivane.

Takovou cestou slo jedno ministerstvo, to vyzaduje take podani nejakych hlaseni (zemedelstvi) elektronicky a vytvorilo za tim ucelem jakysi proprietalni paskvil, ktery vzdalene pripominal WS-Security.

Jelikož jsem se také musel zaobírat EET, tak jsem vytvořil ukázkovou aplikaci v .NET VisualStudiu.
Obsahuje .NET knihovnu (požadavek verze >=4.5) a ukázkového jednoduchého (neučesaného) desktopového klienta.
Jsou k tomu samozřejmě i zdrojáky.

Je to komplet zdarma, nic za to nechci, můžete si s tím dělat co libo.

Odkaz:
EET google složka -> https://drive.google.com/drive/folders/0B2B4_OfsI25paTB2R0NNM1hqMzg
Aktulně je tam: EET_1.2_1.4.zip a nějakých pár screenshotů.

Technické detaily a poznámky:
1) Je to napsané v C#, ale obecně tu .NET knihovnu mužete konzumovat z čeho libo např. z Visual Basic či Foxky

2) Ověřil jsem, že to jde natahnout a rebuildovat do VisualStudia 2013 Express i 2015 Community

3) Je to nejvíc .NET, jak jen to jde. Pokud se něco ve schématu XML zpráv změní (a je to celkem pravděpodobné),
stačí jen updatovat webovou referenci o vše se postará Visual Studio.
T.j. tu objektovou proxy generuje VS ! A to je velká výhoda, odpadá jakési ruční vytváření obalových tříd.
Pokud přidají nějaký element či atribut uzlu, stačí to vyřešit jen jedním update tlačítkem a nic se přepisovat nemusí.
Přístup k objektům je tedy silně typový. Trik je v tom, že je to implementováno na bázi serializace a deserializace objektů.

4) Podepisování SOAP body (teď nemluvím o nějakém PKP/BKP, znalci vědí) je v podsatě standartní a kód se tedy může použít i pro podepisování něčeho jiného než jsou EET zprávy.
(pouziva se vyse zminene SignSoapMessage jen mirne upravene)

Daniel Hajek

Ja tem security vecem moc nerozumim, ani technologickym, ale co vim urcite je to ze EET zadne ma dati dal/relace delat nemusi. To si asi pletete s kontrolnim hlasenim.

To jsou vsechno validni otazky, ale nevidim duvod, proc by verejnost mela diskutovat technicke parametry. Ty businessove pozadavky jsou samozrejme neco jineho a neverim, ze by to byl takovy paskvil, ze by system neresil vypadky podobneho typu.

https://www.youtube.com/watch?v=2gNXfrMR_Lw&nohtml5=False