Před týdnem jsem dodělal ActiveX komponentu pro EET v Delphi 7, základem bylo použít (správně) Eldosácký secureblackbox.
Narazil jsem jen na problém, že rutina Trzba obsahuje dva parametry se stejným názvem (Hlavicka) - jeden jako In a druhý jako Out.
Když to nijak neošetříte, tak vám standardní Delphi deserializace SOAP odpovědi tu Out Hlavicku nevrátí. Kontroloval jsem SOAP kód XE5
knihovny a tam je problém stejný. Má někdo verzi Delphi která si s duplikovaným názvem parametru poradí bez přejmenovávání nodů v odpovědi?
Prozraďte ...
Takže - mám kód, který dostane zpátky fik, což je fajn, ale pár otázek - spíš metodického charakteru - stále zbývá:
1) V dokumentaci píšou, že datumočasy musí povinně obsahovat zónu +2:00 nebo +1:00 podle toho, jestli je příslušný datumočas
letní nebo zimní :-) Normálně XML standard, ale legrace je, že Delphi knihovny vymyslí zónu podle toho, kdy XML generujete, a ne
podle toho, jaký datumočas je v XML uveden. Samozřejmě že GFŘ do téhle léčky samo spadlo a jejich příklady validních XML obsahují datumočas 2016-09-19T19:06:37+01:00 . No nezasmějte se :-) Zajímavé je, že Chorvati si tohle asi uvědomili a na zóny si v jejich implementaci nehrajou. I když... napsat rutinu která do XML datumočasu zapíše zónu správně podle hodnoty údaje není zas tak těžké. Nesmí se ale měnit pravidla pro dny přechodu
mezi letním a zimním časem zapsaná v TimeZoneInformation.
2) Ve specifikaci je uvedeno, že certifikát použitý k výpočtu PKP a BKP a certifikát použitý k podpisu XML musí být ten samý, s vyjímkou případu, kdy
certifikátu kterým jste počítali BKP propadl čas platnosti. Pak můžete XML podepsat jiným - platným - certifikátem. Nevím jestli si někdo uvědomuje (GFŘ asi ne), že tenhle požadavek dost komplikuje správu certifikátů v celém EET procesu. Pokud se totiž nepodaří zprávu odeslat, nebo fungujete ve zjednodušeném režimu, tak spolu s BKP (který vytisknete na účtenku) musíte u tržby uložit i certifikát, který byl k výpočtu BKP použit. Těch certifikátů může mít podnikatel více. Když pak po 2-5ti dnech posíláte tržbu k zaevidování (kde je řečeno že to bude na stejném zařízení?), musíte se podívat na uložený certifikát, ověřit jestli náhodou ještě neplatí, a pokud ano, použít ho k podepsání XML. Teprve kdyby už neplatil, můžete použít nový. Oproti situaci, kdy prostě týden před koncem platnosti starého certifikátu nasadím nový, a jedu s ním jak generování nových, tak odesílání starých tržeb, je tahle podmínka dost velká komplikace. Co si o tom myslíte vy ostatní?
Tak tohle byly moje dva centy :-)
