Vlákno názorů k článku Jak EET vidí ajťák aneb Draze zaplacená vražda uživatelské přívětivosti od Jarda Servisní technik výpočetní techniky, správce síťí a SW vývojář - Servisní technik výpočetní techniky, správce síťí a SW...

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

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

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.

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

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!

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