Delphi + EET

[Peťo]

Pro Delphi 2007/2006 jsem používal upravenou unit OPToSOAPDomConv.pas abych se vyvaroval náhodných chyb při sestavování/parsování soap xml. U nižších verzí nevím.

V čom približne spočívala tá úprava? Používam v Delphi 7 Soap s oveľa zložitejšími xml v desiatkach KB a nič také sa mi zatiaľ nestalo. Ale vždy to bolo bez podpisovania a certifikátov.

[Marek Weyda]

V čom približne spočívala tá úprava? Používam v Delphi 7 Soap s oveľa zložitejšími xml v desiatkach KB a nič také sa mi zatiaľ nestalo. Ale vždy to bolo bez podpisovania a certifikátov.

No, osobně si myslím a nejenom já - viz četné diskuze na síti sítí - že SOAP prostě v nižších verzích Delphi (minimálně Delphi 2007 a níže) není dobře implementované a bez úpravy příslušných SOAP unit to v dnešní moderní hektické době prostě nejde.

Nicméně stále se vracím k tomu, co tady již několikrát píši a jsem některými kamenován - podle mě ty chyby, co hlásíte, souvisí s tím řešením od uživatele Mirus. Nikdo jiný uvedené chyby nehlásil. Já mohu za sebe potvrdit, že naše vlastní řešení:

Upravené SOAP unity + Delphi 2007 + WinInet + další bezplatné knihovny zejména XML Security Library

běhá tak skvěle, až mě mrazí, protože v souvislosti se státní správou nikdy nic tak dobře nešlapalo, až teprve teď to EET. Mám rozsáhlé logy kvůli případným problémům s finančákem u zákazníků a jsou již tisíce odeslaných účtenek a za celou dobu jedna jediná chyba u jednoho dokladu a to ještě kvůli dočasně nedostupnému internetu u zákazníka, nicméně FIK nakonec samozřejmě přiděleno bylo, máme frontu na pozdější odeslání. V březnu možná bude problémů více, ale šlape to nyní, až mě to opravdu děsí, páč na toto skutečně zvyklý u naší postsocialistické země nejsem.

Nemyslím si, že naše řešení je nějak o hodně jiné než to Mirusovo - tady ani není moc co jiného vymýšlet, pokud nejdu cestou placených komponent třetích stran. Záleží ale na konkrétní implementaci a u Miruse asi nějaký problém je, takže se budete muset ponořit hlouběji do jeho zdrojového kódu. Určitě bych nepoužíval Indy a určitě bych nepoužíval původní SOAP unity u starších Delphi. To je moje doporučení, Mirus ale podle mě svoje řešení pro starší Delphi neoptimalizoval a ani se mu nedivím, já bych to také nedělal (zadarmo určitě ne !!!). Musel jsem to ale kvůli svému chlebodárci nakonec stejně ve starších Delphi 2007 implementovat, ale opravdu to jde a šlape to skvěle - ale až díky tomu přepsání SOAP unit a rozhodně bez Indy komponent !

Takže to se už opakuji, za což se omlouvám, ale v poslední době tady řešíme vlastně pořád to samé a i ty chyby, co hlásíte, už se tady řešily.

[Peťo]

Nicméně stále se vracím k tomu, co tady již několikrát píši a jsem některými kamenován - podle mě ty chyby, co hlásíte, souvisí s tím řešením od uživatele Mirus. Nikdo jiný uvedené chyby nehlásil. Já mohu za sebe potvrdit, že naše vlastní řešení:

Upravené SOAP unity + Delphi 2007 + WinInet + další bezplatné knihovny zejména XML Security Library

běhá tak skvěle, až mě mrazí, ...

To je pekné, že sa vieš pochváliť, ako ti všetko beží. Ale čím si vlastne v tejto diskusii prispel okrem všeobecných kecov a odsudzovania cudzích riešení? Netvrdím, že máš zverejniť kód ako mirus, ani nejaké veľké fragmenty, to by ti chlebodarca mohol vyčítať. Ale táto diskusia je na to, aby aj komerčný programátor mohol napísať, že napríklad v unite XYZ.pas je taká všeobecne známa (alebo dobre utajená) chyba, ktorú si všetci opravte, alebo pozor na komponent TAbcde, ktorý v EET robí takýto problém. Nemá každý za sebou celý tím analytikov, právnikov, daňovákov a pomocných kodérov, aby si vyvinul vlastné dokonalé riešenie. Možno to tu robíme tak trochu na kolene, ale tak to pri malých firmách a samostatných programátoroch býva.

Momentálny problém Access violation sa tu ešte neriešil a nie je to problém nižších verzií Delphi, mám mail, že to robí aj v Delphi 10 Berlin.

[rimba]

Zřejmě to má souvislost s tímto.

Kód: Delphi [Vybrat]

1.     EET.OnVerifyPeer := VerifyPeer;
2.     EET.RootCertFile := ExpandFileName('..\cert\Geotrust_PCA_G3_Root.pem');
3.  

to nevypadá, neboť o řádek výš je

Kód: Delphi [Vybrat]

1. {$IFDEF USE_INDY OR USE_DIRECTINDY}

a to já ne (DX10). Také jsem pátral zda mám aktuální certifikáty a na nic špatného jsem nepřišel. Signed.xml mi (s použitím jiného SW) přijímá a vytavuje fik (..-ff). Tak furt nevím. A před 14 dny to ještě fungovalo.

[Lukas]

Setkal se někdo s tím, že při použití projektu od Miruse (https://github.com/mirus77/DelphiEET) to na Windows 7 hlásí následující chybu -3 (při odeslání tržby). Při použití třetího parametru 0 při volání procedury OdeslaniTrzby to přidá k dané chybě text, že systém nemůže nalézt uvedený soubor.

Při použití tohoto samého exe souboru ale na Win 10 funguje v pořádku.
Chyba je pravděpodobně způsobená handleWinInetError. Při zakomentování chyby Fik dorazí OK.

Na Win 7 CZ je to testováno jak na samotných tak i s sp1. Vždy to skončí se  stejnou chybou.

Díky za reakci
Lukáš

[Marek Weyda]

To je pekné, že sa vieš pochváliť, ako ti všetko beží. Ale čím si vlastne v tejto diskusii prispel okrem všeobecných kecov a odsudzovania cudzích riešení? Netvrdím, že máš zverejniť kód ako mirus, ani nejaké veľké fragmenty, to by ti chlebodarca mohol vyčítať. Ale táto diskusia je na to, aby aj komerčný programátor mohol napísať, že napríklad v unite XYZ.pas je taká všeobecne známa (alebo dobre utajená) chyba, ktorú si všetci opravte, alebo pozor na komponent TAbcde, ktorý v EET robí takýto problém. Nemá každý za sebou celý tím analytikov, právnikov, daňovákov a pomocných kodérov, aby si vyvinul vlastné dokonalé riešenie. Možno to tu robíme tak trochu na kolene, ale tak to pri malých firmách a samostatných programátoroch býva.

Momentálny problém Access violation sa tu ešte neriešil a nie je to problém nižších verzií Delphi, mám mail, že to robí aj v Delphi 10 Berlin.

No comment, protože mám teď šíleně málo času, jinak bych k tomu napsal více, protože je to zcela mimo.

Jenom ale jedna poznámka: pokud máte zákazníky, kteří od vás jak sám píšeš tyto "robíme tak trochu na kolene" řešení kupují, tak je zcela upřímně lituji. Já osobně bych své tvrdě vydělané peníze za software "robíme tak trochu na kolene" nedal.

A také jsi zcela mimo, když píšeš, že do této diskuze jsem přispěl pouze obecnými kecy. Tak to ani náhodou. Přečti si moje příspěvky. Psal jsem konkrétně o problémech s přetypováním v RIO komponentách, o výhodě využívání WinInet oproti Indy a podobně. Takže jsi zcela mimo.

Pouze a jenom mám velmi málo času, proto na vše nejsem schopen odpovědět.

[rimba]

Zřejmě to má souvislost s tímto.

Kód: Delphi [Vybrat]

1.     EET.OnVerifyPeer := VerifyPeer;
2.     EET.RootCertFile := ExpandFileName('..\cert\Geotrust_PCA_G3_Root.pem');
3.  

Geotrust_PCA_G3_Root.pem je stary certifikat:
C=US, O=GeoTrust Inc., OU=(c) 2008 GeoTrust Inc. - For authorized use only, CN=GeoTrust Primary Certification Authority - G3

Vystavitel ma byt :
DC=CZ, O=Česká Republika – Generální finanční ředitelství, CN=EET CA 1 Playground

Kód: Delphi [Vybrat]

1. openssl x509 -inform DER -in EET_CA1_Playground-ca.crt -out EET_CA1_Playground-ca.pem -text

Bylo by vhodne ho zrusit z projektu, at to nemate lidi.

[mirus]

Zřejmě to má souvislost s tímto.

Kód: Delphi [Vybrat]

1.     EET.OnVerifyPeer := VerifyPeer;
2.     EET.RootCertFile := ExpandFileName('..\cert\Geotrust_PCA_G3_Root.pem');
3.  

Geotrust_PCA_G3_Root.pem je stary certifikat:
C=US, O=GeoTrust Inc., OU=(c) 2008 GeoTrust Inc. - For authorized use only, CN=GeoTrust Primary Certification Authority - G3

Vystavitel ma byt :
DC=CZ, O=Česká Republika – Generální finanční ředitelství, CN=EET CA 1 Playground

Kód: Delphi [Vybrat]

1. openssl x509 -inform DER -in EET_CA1_Playground-ca.crt -out EET_CA1_Playground-ca.pem -text

Bylo by vhodne ho zrusit z projektu, at to nemate lidi.

Certifikát Geotrust_PCA_G3_Root.pem slouží pro ověření HTTPS komunikace to je autorita HTTPS certifikátu. To není zavádějící. V DelphiEET se používá pouze s INDY komponentou.
WinInet si ho bere ze systémového uložistě certifikátů automaticky.
Toto ověření je požadováno viz bod.
6.1 ŠIFROVÁNÍ KOMUNIKACE PROTOKOLEM HTTPS ve specifikaci "EET_popis_rozhraní.pdf"

Společné technické zařízení správce daně bude vybaveno SSL certifikátem serveru. Pokladní zařízení musí v rámci navázání spojení SSL spojení (SSL handshake) se společným technickým zařízením povinně kontrolovat platnost SSL certifikátu serveru, zda byl vystaven důvěryhodnou autoritou a zda se shoduje jméno, na které byl vydán, s adresou společného technického zařízení.

Ověření jména na kterého byl vydán je možné nastavit hodnotou EET.HttpsTrustName := 'www.eet.cz';  // for HTTPS validation default : 'www.eet.cz'

To je ROOT vydavatel HTTPS certifikátu obou prostředí. (Playground, Production).

EET_CA1_Playground-ca.crt je pouze vydavatel certifikátů pro klíče k použití pro podepisování eTržeb a SOAP zpráv.

[Ondřej Pokorný]

Problém tématu EET+Delphi je, že máme jedno sběrné vlákno, ve kterém se nedá nic dohledat Asi by bylo bývalo lepší udělat kategorii Delphi/EET a každý nový dotaz směřovat do nového vlákna.

Ale to je takový výkřik "po bitvě každý generálem"... Na druhou stranu nikdy není pozdě 

[pepak]

Na třetí stranu je to celkem zbytečné, protože za chvíli už to nebude aktuální.

[Ondřej Pokorný]

Na třetí stranu je to celkem zbytečné, protože za chvíli už to nebude aktuální.

Myslíš, že po nových parlamentních volbách EET zruší?

[RadimHoly]

Můžu se zeptat jestli někdo tuto komunikaci rozjel i na serverech Windows 2012 a 2012 R2? Na ostatních windows tento super projekt bez problémů funguje, ale na tomto systému ne. Žádnou chybu komunikace nenahlásí, ale vrátí prázdnou odpověď, tedy spíše nevrátí. Díky za nějakou odpověď, která by mi pomohla to zprovoznit.

[rames.iii]

Teď jsem to zkusil z Win2012 R2 na playground a FIK mám

EDIT: V Možnostech internetu se dá povolit/zakázat protokol TLS, tak zkuste zkontrolovat to.

[RadimHoly]

Díky za nakopnutí, pro Windows 2012 a 2012 R2 jsem musel doinstalovat MicrosoftEasyFix51044.msi, která povolí TLS 1.1 a 1.2 a poté již komunikace funguje správně.

[Roman K.]

Jen takové drobné 2 centy k výše proběhlým diskusím o tom které řešení je to nejlepší: doporučení nepoužívat INDY bohužel užijí jen ti, kteří nemusí podporovat EET  z XP mašin :-) Pokud XP podporujete, nic jiného než Indy nezbývá. Jinak mně všechno běží OK, mám vlastní řešení typu Indy + původní SOAP VCL z XE5 s direktivou  použít Indy + OpenSSL kvůli TLS pro Indy +  EldoS Secure BlackBox pro XML security. Šlape to bez problémů.