Forum Delphi.cz

Delphi => Obecné => Téma založeno: perverez 03-06-2016, 16:52:48

Název: Delphi + EET
Přispěvatel: perverez 03-06-2016, 16:52:48
Ahoj, v souvislosti s nadcházející nutností odesílání tržeb do EET se chci zeptat, jaké máte zkušenosti s podepisováním řezězců, SOAP, případně XML souborů. Podle dokumentace dostupné na http://www.etrzby.cz/assets/cs/prilohy/EET_popis_rozhrani_v1.0.pdf bude nutné v každé SOAP zprávě vytvářet PPK (podpisový kód poplatníka) a každou zprávu bude nutné podepisovat certifikátem. A teď to hlavní: hledal jsem na internetu, jaké komponenty v Delphi (RAD2007) použít, a dopátral jsem se pouze k SecureBlackBox jako jediné variantě, která splňuje definovaná pravidla podle kapitoly 6.2. Poradí mi někdo nějakou jinou (a hlavně levnější) variantu pro podepisování? Děkuji.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 04-06-2016, 01:04:44
Kdyby doslo na lamani chleba, myslim ze jsem slysel, ze bude nejaka referencni implementace v C#, kdyz tak si muzes udelat malou assembly, ktera ti to podopise a vrati - z Delphi jsem volani .NET assembly popisoval na delphi.cz
Název: Re:Delphi + EET
Přispěvatel: oxo 04-06-2016, 09:45:04
Sorry za OT:

Nějak nechápu MFČR a jeho posedlost certifikáty a podepisováním. V Rakousku veškerá komunikace s úřady funguje přes HTTPS portál a normální autentizaci přes jméno/heslo. Jednoduchý jak facka.

Fakt nevidím výhody certifikátu oproti HTTPS/jméno/heslo. Když se mi někdo nabourá do počítače, tak se k certifikátu dostane stejně jako k uloženému heslu.
Název: Re:Delphi + EET
Přispěvatel: pf1957 04-06-2016, 12:16:41
Nějak nechápu MFČR a jeho posedlost certifikáty a podepisováním. V Rakousku veškerá komunikace s úřady funguje přes HTTPS portál a normální autentizaci přes jméno/heslo. Jednoduchý jak facka.
Podepisovani je jedna vec, ale ses si jistej, ze to spojeni pres HTTPS nema zadny certifikat? Protoze co jsem videl v enterprise svete a nejen v cesku, ale treba v oblasti ASEAN, tak standard byl bud IPsec nebo HTTPS s certifikatem. Ten certifikat se pouziva proti MITM utokum a stejne tak ho pouziva ten IPsec tunel.

Název: Re:Delphi + EET
Přispěvatel: vandrovnik 04-06-2016, 12:25:56
EET mne také nemine programovat, už teď se na certifikáty a vše kolem netěším. Každá dobrá duše, která o tom už něco ví a informaci zde utrousí, bude mít mé vřelé díky :-)
Název: Re:Delphi + EET
Přispěvatel: oxo 04-06-2016, 14:27:27
Nějak nechápu MFČR a jeho posedlost certifikáty a podepisováním. V Rakousku veškerá komunikace s úřady funguje přes HTTPS portál a normální autentizaci přes jméno/heslo. Jednoduchý jak facka.
Podepisovani je jedna vec, ale ses si jistej, ze to spojeni pres HTTPS nema zadny certifikat? Protoze co jsem videl v enterprise svete a nejen v cesku, ale treba v oblasti ASEAN, tak standard byl bud IPsec nebo HTTPS s certifikatem. Ten certifikat se pouziva proti MITM utokum a stejne tak ho pouziva ten IPsec tunel.

Přes HTTPS to myslíš certifikát na straně klienta? Zatím jsem ještě neprogramoval žádnou automatiku pro spojení s rakouskými úřady. Posílání všech hlášení (DPH, příjmy, MOSS, ...) jsem dělal vždycky ručně přes jejich portál https://finanzonline.bmf.gv.at/fon/ (https://finanzonline.bmf.gv.at/fon/). Zadáš ID/PIN a jedeš. Nic víc tam nemají.
Název: Re:Delphi + EET
Přispěvatel: pf1957 04-06-2016, 16:23:04
Přes HTTPS to myslíš certifikát na straně klienta? Zatím jsem ještě neprogramoval žádnou automatiku pro spojení s rakouskými úřady. Posílání všech hlášení (DPH, příjmy, MOSS, ...) jsem dělal vždycky ručně přes jejich portál https://finanzonline.bmf.gv.at/fon/ (https://finanzonline.bmf.gv.at/fon/). Zadáš ID/PIN a jedeš. Nic víc tam nemají.
Ano, certifilat na strane klienta. Ale je pravda, ze ja jsem prisel do styku se systemy, kde byl s danou komunikaci potencialne nejaky presun penez a kdyz tak o tom premitam, tak jsem ani s zadnym "beznym" systemem neprisel do styku.

A jak maji v Rakousku udelany enrolment tj. jak poznaji ze jsi to ty? To ses sel nejak zaregistrovat na urad nebo ti poslali login do vlastich rukou nebo jak?
Název: Re:Delphi + EET
Přispěvatel: zj 04-06-2016, 18:06:56
Na https://sourceforge.net/projects/libxml2-pas/?source=navbar (https://sourceforge.net/projects/libxml2-pas/?source=navbar) je wrapper pro libxml2 a související projekty - zajímavý je libxmlsec https://www.aleksey.com/xmlsec/api/xmlsec-notes-sign-encrypt.html (https://www.aleksey.com/xmlsec/api/xmlsec-notes-sign-encrypt.html). To bude cesta kterou chci zkusit.

zj
Název: Re:Delphi + EET
Přispěvatel: oxo 04-06-2016, 19:20:42
Ano, certifilat na strane klienta.

Certifikát na straně klienta není.

A jak maji v Rakousku udelany enrolment tj. jak poznaji ze jsi to ty? To ses sel nejak zaregistrovat na urad nebo ti poslali login do vlastich rukou nebo jak?

Na živnostenský úřad jsem samozřejmě musel osobně se zaregistrovat, login pak poslali v normálním psaní, moc se s tím neštvou ;)
Název: Re:Delphi + EET
Přispěvatel: Petr P. 04-06-2016, 20:25:53
Možná by to mohl umět TurboPower LockBox.
https://sourceforge.net/projects/tplockbox/
Název: Re:Delphi + EET
Přispěvatel: < z > 05-06-2016, 09:18:11
s LockBox (3) bych byl opatrný, protože jejich implementace neni kompatibilni s OpenSSL
Název: Re:Delphi + EET
Přispěvatel: pepak 05-06-2016, 17:31:48
Až to bude akutní, zkusím to s libxmlsec. Zatím mi pro komunikaci se státní správou funguje, takže by se teoreticky mohlo stát, že si z toho MF vezme příklad.
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 07-06-2016, 08:32:14
To jsem docela rád, že s tím EET nejsem sám, koho to čeká a moc se mu do toho nechce :-) Až to bude aktuální, tak doufám, že se na toto téma tady na diskuzi podpoříme. Jinak se s ohledem na zkušenosti z předchozích implementací různých legislativních hovadin obávám, že to nebude procházka růžovým sadem.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 23-06-2016, 10:47:23
Mám Delphi XE6. Použil jsem WSDL importer pro vytvoření wrapperu pro vytváření XML souboru. Výsledná unita ale neobsahuje pořádnou definici pro několik typů, konkrétně:
Kód: Delphi [Vybrat]
  1.   OdpovedChybaType = TXMLData;      { "http://fs.mfcr.cz/eet/schema/v2"[GblCplxMxd] }
  2.   BkpElementType  = TXMLData;       { "http://fs.mfcr.cz/eet/schema/v2"[GblCplxMxd] }
  3.   PkpElementType  = TXMLData;       { "http://fs.mfcr.cz/eet/schema/v2"[GblCplxMxd] }
Mám někde něco špatně nastaveno nebo musím unitu ručně upravit?
Nebo je na to potřeba jít z úplně jiné strany?
Díky za vaše názory a zkušenosti, myslím, že toto téma se dotýká hodně programátorů.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 26-06-2016, 21:34:33
Pánové, kdyby někdo doufal v součinnost GFŘ, tak tady je jejich odpověď:

Předmět:    RE: Dotaz z kontaktního formuláře
Datum:    Sun, 26 Jun 2016 17:51:30 +0200
Od:    ePodpora (GFŘ) <epodpora@fs.mfcr.cz>
Komu:    Král Karel


Dobrý den,
 o zveřejnění vámi požadovaných „příkladů/šablon zpracování EET v různých vývojových jazycích“ v současné době Finanční správa neuvažuje.

 
S pozdravem

 
Radek Korčák
Generální finanční ředitelství
Technická podpora aplikací
Daňového portálu www.daneelektronicky.cz
E-mail: epodpora@fs.mfcr.cz

Od:
Odesláno: 25. června 2016 21:49
Komu: ePodpora (GFŘ)
Předmět: Dotaz z kontaktního formuláře

 Údaje odeslané z kontaktního formuláře:
Checkboxy: Technický dotaz
Jméno: Karel
Příjmení: Král

E-mail:

Dotaz: Dobrý den, nebylo by možné z vaší strany připravit nějaké šablony pro komunikaci s EET systémem v nejběžnějších programovacích nástrojích? Stačí jednoduché příklady, ušetřilo by to tisíce hodin práce. Vámi zvolené řešení nepoužívá zrovna jednoduché postupy co se týká podpisování zpráv. Doporučil bych příklady pro C# Microsoft .NET a Java.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 26-06-2016, 23:03:03
Bohužel málokterého úředníka vybičuje k činnosti fakt, že by svojí prací někomu jinému práci ušetřil...
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 27-06-2016, 10:16:01
Pánové, kdyby někdo doufal v součinnost GFŘ, tak tady je jejich odpověď:

Tak to jsem přesně čekal a vůbec mě to nepřekvapuje. Nemáš ani představu, co ze svých tvrdě vydělaných peněz platíme v daních za neschopný lidi prolezlý do státní správy. Pro mě osobně platí rovnítko IT (nejenom) zaměstnanec ve státní správě = dosaď si sám. Prostě nepochopili, že jsou živí z NAŠICH peněz. MY jsme jejich zákazníci a ONI nám jsou povinni sloužit. Bohužel je to přesně naopak. MY dřeme, MY chodíme do práce každý den, MY upíráme svým rodinám a svým dětem, aby ONI mohli žít nad poměry, stavět si luxusní sídla a pokud nedej bože něco od nich chceš - okamžitě Tě posílají někam a když se bráníš, tak na Tebe posílají různé kontroly a znepříjemňují Ti život. Bohužel bude to čím dál horší.

Takže pevně věřím, že se my programátoři tady semkneme a co nejvíce si s tím EET pomůžeme.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 27-06-2016, 10:31:53
Já doufám, že to dopadne jak na Slovensku, kde mají krabičky za pár tisíc, které dělají tu špinavou práci, a jí jim jen řeknu, že chci zaúčtovat to a to v takové sazbě DPH a nebudu si muset špinit ruce a nasazovat krk.
Název: Re:Delphi + EET
Přispěvatel: zdenek 27-06-2016, 11:50:30
Přispěju svou troškou do mlýna.

Tak klientské certifikáty pro připojení přes HTTPS nejsou požadovány (bod 6.1 dokumentace). Pro správné vytvoření zprávy stačí podepsat přesně daný řetězec přiděleným certifikátem (vytvořit PKP, BKP) a následně SOAP zprávu podepsat standardem XML (část zprávy). Ideální je třeba SecureBlackBox (pro podepsání XML i pro podepsání čehokoliv). Jinak cryptoapi na win umí první bod samozřejmě taky, druhý bod vyžaduje canonizaci.

 Hlavní věc je, kde mít ten certifikát. Na windows je to jednodušší, máme systémový store. Na androidu se ale k certifikátu v OS nedostaneme a uložení si certifikátu včetně priváního klíče někde do souboru mi přijde pekelně nebezpečné.
Název: Re:Delphi + EET
Přispěvatel: Karel 29-06-2016, 09:38:01
Nedělej si iluze, pro slovenský fiskál jsem programoval napojení a je to ještě mnohme složitější než EET.

Já doufám, že to dopadne jak na Slovensku, kde mají krabičky za pár tisíc, které dělají tu špinavou práci, a jí jim jen řeknu, že chci zaúčtovat to a to v takové sazbě DPH a nebudu si muset špinit ruce a nasazovat krk.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 29-06-2016, 16:15:20
Zdravím všechny postižené EET!
Postupně jsem se dopracoval až k podpisu SOAP zprávy. Podle mě je to správně, ale PlayGround mi to odmítá s kódem 4 - Neplatný podpis SOAP zprávy. Podepsáno to mám certifikátem "01000003.p12", který je k dispozici pro testování. Použil jsem SecureBlackBox v testovací verzi, tedy nevidím do zdrojů. Mohl by někdo, kdo použil také SecureBlackBox a PlayGround jeho SOAP zprávy akceptuje, sem také vložit nějakou svoji SOAP zprávu? To by všem, kdo to mají na triku, hodně pomohlo, předem díky za ochotu.

Kód: XML [Vybrat]
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOAP-ENV:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" SOAP-ENV:mustUnderstand="1"><wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" wsu:Id="id-1435331660" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIID6zCCAtOgAwIBAgIEAQAAAzANBgkqhkiG9w0BAQsFADBYMQswCQYDVQQGEwJDWjEaMBgGA1UEAwwRR0ZSIEVFVCB0ZXN0IENBIDExLTArBgNVBAoMJEdlbmVyw6FsbsOtIGZpbmFuxI1uw60gxZllZGl0ZWxzdHbDrTAeFw0xNjA1MTkxMjQ1MDJaFw0xODA1MTkxMjQ1MDJaMFMxCzAJBgNVBAYTAkNaMRUwEwYDVQQDDAxDWjEyMTIxMjEyMTgxFzAVBgNVBAoMDk9zb2JhIEZ5emlja8OhMRQwEgYDVQQFEwtUMDAwMDAwMDAwMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMt0eW9n+RB0PSawKSJbtAg3j7e1I5p7P9OvEj0n9raEMI496Zuw7s4VaE8JEX4iowjWhlPIOPljDiAXX6HgZzH4PDps0rFm388KZxj7Ek/ZLyyh5jRovc0Yccfgm3i2huBepk7ZtifZXOZzDEDT0CZsxRpypZJp9PK6SOdj2zPIc11F+prwsGQCDAZsRtama5/W5qn2YUWjjk+4c5Zu3TcknC7bcp1dg7RJ9yMtNiYPY7LNV3uWQhAXZVFpmOpbfYwT1F8H3/UrWDSJ5zrHshICPreMyZ0skU9SUANQ8QQKE6lSlgSs59YaeEmCyGtpttVjN+iR/L9M9FRtq3ZhZz0CAwEAAaOBwTCBvjAeBgNVHREEFzAVgRNlcG9kcG9yYUBmcy5tZmNyLmN6MB8GA1UdIwQYMBaAFHpa/A3L7DamDdppGWaMm++Cw6k0MB0GA1UdDgQWBBQbyTbuGBZdorOZZm7usMraGAJ2STBMBgNVHSAERTBDMEEGCmCGSAFlAwIBMAIwMzAxBggrBgEFBQcCAjAlGiNUZW50byBjZXJ0aWZpa2F0IEpFIFBPVVpFIFRFU1RPVkFDSTAOBgNVHQ8BAf8EBAMCBsAwDQYJKoZIhvcNAQELBQADggEBAC3L8Bm7ZlWui9xWrjM00SlvCokpc2ldGCxNvj4hANaISoLRdPVZAPeLd1X4KsRyxOIazR5oq3EKVZV1ZP3sCF4QFL+SqurkPiBbIrrbABDLyDpf/8DIfyA1x/+zNpN9ul9j9Ca1739P4L1x3wpQcYhEuvSrTiLztndlJb69LXgYZOFfqcBSRedRuMwRdtux9OWkkZjrd9wNHTCDOIfOPaPRRoq5IPHP32shsXaTLvhsT7ktvR5Fr/SQ8CkWq3U6tdcOQRN35ZWyYSyOd5/vkJqK773R/gAeBUE80gpLMdqgVj8HaD7RlHrYyYJEVUI9gbctTfUIJW/9LZ3K78JLXXg=</wsse:BinarySecurityToken><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><ds:Reference URI="#id-1510723327"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>MOkXQ2OCobT0WVJYKvoPwTp39Cn1InVJynRu1qqfXYo=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>N2hiJO5Pa8bXKzA5dd3G37htYo344hSjx3s6anJe3XFRQXYp05yq0hmUbdHuhyOUp4YI3jZuyVBvE+p2NLj4ztgx7oH2kLwGC7Z7z6m/rW4grpZX9HkzMh9y+/ih/bL01PRQvo8J6vvZUUgPcn0zuI2It2dHpLFUW4iIEbbpyoBIATvAUJDeUNtC1eHRwTTZrwHt3wcZIEADoaaHTa3t4No1xUV3tye3MlohbtVdovnIhubAoUph6YNXtU2eL8MBp9wKxSG1N0LJUkLeuEdl0869BzQJnK6412d5KNItjMySVeSGgXl6+yzFfPCV6r6L7mdN/h3GkMujkSIyjiNKBg==</ds:SignatureValue><ds:KeyInfo><wsse:SecurityTokenReference><wsse:Reference URI="#id-1435331660" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></SOAP-ENV:Header><SOAP-ENV:Body wsu:Id="id-1510723327" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><Trzba xmlns="http://fs.mfcr.cz/eet/schema/v2"><Hlavicka uuid_zpravy="d89c3911-98cd-4b1c-b129-1f67d4b605be" dat_odesl="2016-06-29T15:40:53+02:00" prvni_zaslani="true" overeni="true"/><Data dic_popl="CZ1212121218" id_provoz="273" id_pokl="/5546/RO24" porad_cis="0/6460/ZQ42" dat_trzby="2016-06-29T15:40:53+02:00" celk_trzba="121.00" zakl_dan1="100.00" dan1="21.00" rezim="0"/>
  3.                         <KontrolniKody>
  4.                                 <pkp cipher="RSA2048" digest="SHA256" encoding="base64">HKSUD8qfqXcJ9UwU5pBZgCp/Y5Gn05orpwKIyGvcpiocIRftFZq/XPU6s4QQMccPn+LklpgvHBxn
  5. Jb82bdTQpRYyFqB1EhQ4XugCEyGvjuQSP3N14ys+j0kLKbKIlDXRCC13+DmuSVtdujttsphNRyUw
  6. g6TXOo8QLtBjkuvMibAwS+8fWJXK1jItSfR62QRadQHhJ6xyL0+2C+oQB0yliAj/N8sXkGihAqqy
  7. 20ICruxovym6guJhtO769NpbrMfmo4pqsaaigMYsO6nUpuh8Wm8DVPooesWo7NyV6UtrehDkyfdM
  8. vLGSvG3Rp3in3EtnkSWQWBdOI9ytAlcziTrf4g==</pkp>
  9.                                 <bkp digest="SHA1" encoding="base16">78949ED8-91865FFF-607B2FF2-009D6820-7F6309CB</bkp>
  10.                         </KontrolniKody>
  11.                 </Trzba></SOAP-ENV:Body></SOAP-ENV:Envelope>
  12.  
  13.  

Moc hezky to nevypadá, tak to přiložím jako obrázek, xml není povoleno.
Mimochodem napojení na slovenský fiskál jsem úspěšně udělal, takže můžu porovnat. EET mi přijde mnohem složitější.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 29-06-2016, 16:29:41
Řešil jsem to tady, zatím jenom odesílám jejich testovací zprávu ale problémy jsem měl podobné. S podepisováním zatím zkušenosti nemám.
https://groups.google.com/d/msg/foxpro/dm0FRwXk2vc/zIRxiE3wCAAJ
Název: Re:Delphi + EET
Přispěvatel: roman@irl.cz 29-06-2016, 22:50:10
Mrkněte na toto http://www.arrowsys.cz/produkty/43-univerzalni-eet-modul.aspx má s tím někdo nějaké zkušenosti?
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 30-06-2016, 09:22:25
Díky za odkaz, je vidět, že se s tím bojuje na všech stranách. Prostudování diskuze mě přivedlo na pár nápadů, jak dál postupovat ve vlastním vývoji, tj. odstranit veškeré formátování, ověření SOAP komunikace odesláním validního xml, atd...
Řešil jsem to tady, zatím jenom odesílám jejich testovací zprávu ale problémy jsem měl podobné. S podepisováním zatím zkušenosti nemám.
https://groups.google.com/d/msg/foxpro/dm0FRwXk2vc/zIRxiE3wCAAJ
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 30-06-2016, 09:55:57
Tak opravdu pozor na formátování !!! Stačilo jej odstranit a už je zpráva validní !

fik: c42c1d5f-1cb0-4500-80ff-803834116cab-ff

Pro úpravu XML jsem použil XMLDoku: IXMLDocument, kde jsem měl
Kód: Delphi [Vybrat]
  1. XMLDoku.Options  := XMLDoku.Options + [doNodeAutoIndent];

Stačilo změnit na
Kód: Delphi [Vybrat]
  1. XMLDoku.Options  := [];
A už to podepisuje a odesílá a hlavně přijímá FIK. Wau!
Použil jsem standardní komponenty v Delphi XE6 a zkušební verzi SecureBlackBox, dá se to zvládnout s informacemi na webu Eldosu a nějakým tím googlením.
Název: Re:Delphi + EET
Přispěvatel: anec 30-06-2016, 13:48:32
zdravím, jednoduchý dotaz k EET:
máme skladový software, prodejce vystavuje mimojiné faktury za hotové, zjednodušené daňové doklady, normální daňové doklady. Je možné, že si zákazník koupí nějakou registrační pokladnu, která umí komunikovat s EET a postup by byl: v našem SW vystaví daňový doklad, do pokladny nacvaká částku celkem za doklad, odešle to na EET, po návratu FIKu se vytiskne na té pokladně nějaká stvrzenka, která se sešívačkou přicvaknce na náš daňový doklad?
díky
Název: Re:Delphi + EET
Přispěvatel: mjseven 30-06-2016, 16:05:22
Povinnost plynoucí z EET by tímto modelem mělo jít také splnit.
Z pohledu zákazníka, používajícího váš software, to myslím není ale úplně dobré řešení.


Název: Re:Delphi + EET
Přispěvatel: zdenek 30-06-2016, 18:00:28
To by přece nemělo mít formátování XML vliv na podepisování. Jaký typ kanonizace jste nastavil?

Edit:
Podle dokumentace k eet se používá exclusive kanonizace tedy by to mělo fungovat s:

Kód: Delphi [Vybrat]
  1. TElXMLSigner.CanonicalizationMethod:=xcmExclCanon;
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 01-07-2016, 09:06:14
To formátování vyplynulo z toho, jak jsem měl napsanou testovací aplikaci. Chtěl jsem vidět, co přesně posílám. Protože je to jeden dlooouhý řádek, tak jsem si do XML doplnil zalamování uzlů. V ostré verzi formátování mít nebudu.
Pro EET je předepsaná Exclusive Canonization, tu tam mám, bez ní to nejede.
To by přece nemělo mít formátování XML vliv na podepisování. Jaký typ kanonizace jste nastavil?
Název: Re:Delphi + EET
Přispěvatel: karel.kral 01-07-2016, 10:42:32
Pánové, tady jeden šikovný člověk vytvořil implementaci pro Php a Javu, může to sloužit minimálně jako inspirace. Díky!

https://github.com/l-ra/openeet.git
Název: Re:Delphi + EET
Přispěvatel: karel.kral 02-07-2016, 17:40:18
Pánové, kdo trochu rozumíte C#, ze je hotove reseni na podepisovani podle WS-Security (ktere vyzaduje GFR). Funguje, odzkouseno. Staci si zformatovat telo pro odeslani (element Trzba), samozrejme vcetne vypoctu Pkp a Bkp. O zbytek se postara tato knihovna, podepise presne tak jak Eet pozaduje.

https://github.com/zinkpad/SignSoapMessage
Název: Re:Delphi + EET
Přispěvatel: karel.kral 07-07-2016, 13:18:20
Už jste někdo řešili tento zjevný nesmysl? Zde se uvádí, že se na offline účtence má tisknout celý PKP, nikoliv jeho Hash BKP. Tudíž musíte vytisknout celých 344 znaků. Ptal jsem se na podpoře ale zatím bez odpovědi.

http://www.etrzby.cz/cs/zpusoby-evidence-a-uctenka
Pokud se pokladnímu zařízení, v důsledku technické závady, dočasného výpadku nebo prostého zhoršení úrovně přenosu, nepodaří navázat spojení v nastavené mezní době odezvy (ze zákona nejméně na 2 sekundy), nemusí pokladní zařízení už dál čekat na odezvu ze systému Finanční správy a podnikatel vystaví účtenku, která nebude obsahovat fiskální identifikační kód (FIK), ale musí obsahovat podpisový kód poplatníka (PKP).
Název: Re:Delphi + EET
Přispěvatel: Lukas 14-07-2016, 15:04:09
Dobrý den všem,
   už se někomu podařilo rozchodit EET v prostředí DELPHI ? Pokud ano, jaké komponenty jste použili a popř. nebylo by možné zaslat krátký příklad?

Děkuji moc
Lukáš
Název: Re:Delphi + EET
Přispěvatel: mirus 14-07-2016, 21:13:27
Zdravím,

povedlo se mi zrovna včera dokončit funkční komponentu pro odeslání tržby do playground.

1. WDSLImport dle specifikace.
2. Drobná úprava položek s TXMLData a doplnění vygenerováné unity.
3. Inspirace delphi kódem, který využívá libxml, libxmlsec knihovnu pro vytvoření vlastní komponenty pro EET.
4. Přidání upravené unity SOAP.Soapenv.pas do projektu (změna namespace pro vytváření namespace prefixu pro obálku a tělo SOAP zprávy)

Chybí mi ještě uchodit ověření el. podpisu u odpovědi.

OpenSSL knihovna viz. libxmlsec funguje i s INDY10 SSL pokud se zkompiluje s direktivou USE_INDY a přidáním zdrojů $(BDS)\source\soap do projektu.

Delphi 10 Seatle.

zdroje:
 wraper pro libxml a libmlsec :  https://sourceforge.net/projects/libxml2-pas/ nutno upravit pro unicode PChar -> PAnsiChar a další
 inspirace delphi kód :  https://sourceforge.net/p/f4d/wiki/Home/
 libxml2 a libxmlsec :ftp://ftp.zlatkovic.com/libxml/64bit/ (je tam i 32bit verze ke stažení - testováno pouze v 32 bit verzi)
 StrToHex a SHA1 : synacode.pas ze synapse
 encodebase16 : SZCodeBaseX.pas viz http://cc.embarcadero.com/Item/21951
Název: Re:Delphi + EET
Přispěvatel: mirus 18-07-2016, 00:46:04
Tak ukázka delphi + libxmlsec1 implementace zde. https://github.com/mirus77/DelphiEET
Ověření XML odpovědi dovede ověřit správnost el. podpisu zprávy. Ověřit platný certifikát odpovědi se mi nedařilo. Nevím jak je to potřeba hodně řešit, když to jede po HTTPS?

Testováno s playground EET.
Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 19-07-2016, 09:26:22
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 :-)
Název: Re:Delphi + EET
Přispěvatel: karel.kral 24-07-2016, 13:54:13
Ano, na přesně stejné problémy jako vy jsem narazil taky. Rozhodl jsem se problém s letním časem ignorovat :-)

A ten probléms  certifikáty - eviduji seznam certifikátů v úložišti, ke každému si pamatuji klíč a podpisování se děje vždy tím správným certifikátem. Není mi  ale jasné co ale chtějí ministři dělat se zprávou, která přijde po době platnosti certifikátu, kterým bylo vygenerováno BKP. Podepsaná sice bude novým certifikátem, ale jak si sakra ověří, že BKP je správně? Vždyť ve zprávě mají přiložen pouze nový platný certifikát a kde vezmou ten certifikát, kterým bylo vytvořeno BKP?
Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 25-07-2016, 10:33:45
Fakt je, že problém s XML datumočasem už v nových Delphi není (alespoň XE5 a dále, možná i dřív, nevím, v Delphi 7 problém ještě je).
Někdo asi opravil knihovny aby zóna odpovídala :-)
Pokud jde o ty certifikáty, tam je problém v tom, že si certifikát  použitý pro BKP musíte zapsat u každé tržby,
která nebyla zaevidovaná ihned po vygenerování BKP. Protože až ji budete evidovat později, musíte BKP nechat (zákazník
už ho má na účtence), ale podepsat ji musíte platným certifikátem - ten použitý pro BKP už může být v době evidování neplatný.
Takže nestačí si hlídat certifikáty, ale musíte mít i vazbu [zatím neevidovaná tržba -> BKP certfikát].
Název: Re:Delphi + EET
Přispěvatel: Sender 26-07-2016, 20:29:11
Roman Krejčí > V čem je problém v D7 ?
Název: Re:Delphi + EET
Přispěvatel: zdenek 27-07-2016, 09:48:34
Fakt je, že problém s XML datumočasem už v nových Delphi není (alespoň XE5 a dále, možná i dřív, nevím, v Delphi 7 problém ještě je).
Někdo asi opravil knihovny aby zóna odpovídala :-)
Pokud jde o ty certifikáty, tam je problém v tom, že si certifikát  použitý pro BKP musíte zapsat u každé tržby,
která nebyla zaevidovaná ihned po vygenerování BKP. Protože až ji budete evidovat později, musíte BKP nechat (zákazník
už ho má na účtence), ale podepsat ji musíte platným certifikátem - ten použitý pro BKP už může být v době evidování neplatný.
Takže nestačí si hlídat certifikáty, ale musíte mít i vazbu [zatím neevidovaná tržba -> BKP certfikát].


A nestačilo by dát na účtenku pouze UUID. A BKP, PKP vygenerovat až při vlastním odeslání?
Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 27-07-2016, 10:27:28
To Sender -  v Delphi 7 je problém s generováním XML datumočasu ve funkci DateTimeToXMLTime, která
  jako hodnotu offsetu do stringu přidá právě platný offset (+02:00 nebo +01:00), a nikoli offset platný
  v datu/času který na XML string převádíte. To se pak dále manifestuje jako vadná XML reprezentace
  datumočasu při použití třídy TXSDateTime z unity XSBuiltIns. V XE5 už se v té funkci zjišťuje offset
  platný v čase který na XML převádíte.

To zdenek -  To by asi nestačilo :-) BKP je hash údajů na účtence, takže potom, co BKP dáte z ruky,
 už nemůžete údaje na účtence měnit. uuid tuhle vlastnost nemá. 
Název: Re:Delphi + EET
Přispěvatel: zdenek 27-07-2016, 10:59:43
Nojo, ale jak poznají kterým certifikátem jsem to podepsal. Musím si projí dokumentaci znovu, ale matně si pamatuju, že tam bylo, že BKP, PKP musí být podpsaná stejným certifikátem jako SOAP zpráva. nebo jsem to blbě četl?
Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 27-07-2016, 11:54:35
K DIČ by měly být u GFŘ zaegistrované certifikáty, takže asi vyzkoušejí
jeden po druhém , a když žádný nepasuje, tak je někde chyba.
Název: Re:Delphi + EET
Přispěvatel: zdenek 27-07-2016, 17:51:54
  To by asi nestačilo :-) BKP je hash údajů na účtence, takže potom, co BKP dáte z ruky,
 už nemůžete údaje na účtence měnit. uuid tuhle vlastnost nemá. 

Takže na mobilním zařízení budu muset mít ten certifikát stejně uložený, kvůli tisku účtenky a BKP i když nebudu online odesílat :-(
Název: Re:Delphi + EET
Přispěvatel: chorec 02-08-2016, 11:16:37
Jsem zaseklý na stejném místě. Mám Delphi 7. V novějších Delphi je TXMLData definován v XSBuiltins.pas. Stejně se mi ale ani s přístupem ke zdrojovým kódům novějších verzí Delphi nedaří tohle vyřešit. Už jste přišel na to, co s tím?

Mám Delphi XE6. Použil jsem WSDL importer pro vytvoření wrapperu pro vytváření XML souboru. Výsledná unita ale neobsahuje pořádnou definici pro několik typů, konkrétně:
Kód: Delphi [Vybrat]
  1.   OdpovedChybaType = TXMLData;      { "http://fs.mfcr.cz/eet/schema/v2"[GblCplxMxd] }
  2.   BkpElementType  = TXMLData;       { "http://fs.mfcr.cz/eet/schema/v2"[GblCplxMxd] }
  3.   PkpElementType  = TXMLData;       { "http://fs.mfcr.cz/eet/schema/v2"[GblCplxMxd] }
Mám někde něco špatně nastaveno nebo musím unitu ručně upravit?
Nebo je na to potřeba jít z úplně jiné strany?
Díky za vaše názory a zkušenosti, myslím, že toto téma se dotýká hodně programátorů.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 02-08-2016, 11:49:44
V BeforeExecute objektu HTTPRIO si upravuji SOAPRequest. Potřebné uzly tam doplňuji ručně. Stejně tak si v AfterExecute načtu SOAPResponse a parsuju si potřebné hodnoty. Není to hezké, ale funguje to.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 02-08-2016, 13:01:04
Já bych zase potřeboval poradit s ověřením podpisu potvrzovací datové zprávy. Používám knihovnu SecureBlackBox, tam je třída TElXMLVerifier, ale nějak mi to zatím vždy řeklo, že zpráva není validní. V instalaci je spousta demo projektů, ale ani dema mi nikdy zprávu neověřily. Zajímalo by mě, jakým certifikátem je vlastně odpověď podepsaná, podle dokumentace to není jednoznačné. V EET_pristupove_porovozni_informace_playground_1.0.pdf v kapitole 3.3 mluví o certifikátu vydaném I.CA, stejný má být použitý i v produkčním prostředí. V EET_popis_rozhrani_v2.0.pdf v tabulce 1 na straně 8 píšou u potvrzovací datové zprávě o produkčním i testovacím certifikátu. Produkční certifikát ale podle mně ještě není dostupný, rozhodně ne na webu www.etrzby.cz.

Máte to někdo vyřešené a v čem je případně zakopaný pes?
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 03-08-2016, 22:59:22
Koukenete na chorvatsky system, ktery je podobny ceskemu. Pripravuji velmi podobnou verzi od 1.9.2016 spousti testovaci verzi s tim rozdilem, ze delaji 20.8. seminar pro programatory. Cílem semináře bylo seznámit IT společností ve zprávách systému fiscalization a pomoc při úpravě softwarová řešení.  tedy hodne podobne jako v CR  ;D
maji tam i navody v C#  http://www.porezna-uprava.hr/HR_Fiskalizacija/Documents/Tehnicka%20specifikacija%20za%20korisnike%201.4.pdf (http://www.porezna-uprava.hr/HR_Fiskalizacija/Documents/Tehnicka%20specifikacija%20za%20korisnike%201.4.pdf)


velmi podobny pristup na reseni dotazu v CR zde:
Dobrý den,
omlouváme se, ale váš dotaz nemůžeme zodpovědět, jelikož přesahuje rozsah poskytované podpory ze strany Finanční správy. Finanční správa neposkytuje analýzu fungování SW třetích stran a jejich výstupů, ani podrobnosti k použití obecně platných standardů.
Zároveň Vás chceme ujistit, že systém příjmu datových zpráv evidence tržeb je vytvořen podle uznávaných standardů a je v prostředí Playground funkční. Testovací transakce už úspěšně odeslaly desítky vývojářů SW pokladních zařízení. Volba vývojových nástrojů a podpůrných knihoven je zcela na dodavateli SW pro pokladní zařízení a měla by vyhovovat zveřejněným standardům systému pro příjem datových zpráv.
Zkuste si prosím ověřit správnost zprávy v některém z XML validátorů, dostupných na Internetu.
S pozdravem

Generální finanční ředitelství
Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 05-08-2016, 15:25:58
Nemám to experimentálně ověřené, ale tipnul bych si, že certifikát, kterým teď PlayGround podepisuje
odpovědi, se nevaliduje proto, že je vydán nějakou jejich proprietární certfikační autoritou. A tu
váš systém nezná. Sám narážím na obdobný problém, když si udělám vlastní kořenový certifikát pro různé
testovací účely.
Ono vůbec spousta věcí je na PlayGroundu úplně jinak, než to bude naostro. Playground vpodstatě jenom
prověří XML schéma, a prověří, jestli je BKP vytvořeno přiloženým certifikátem. Vůbec se neobtěžuje s identifikací
(takže DIČ můžete zadat jaékoli, pro tvorbu BKP můžete použít neregistrovaný certifikát, apod.) a vrátí FIK
i tehdy, když by ho ostrý systém vůbec nevrátil.

Já bych zase potřeboval poradit s ověřením podpisu potvrzovací datové zprávy. Používám knihovnu SecureBlackBox, tam je třída TElXMLVerifier, ale nějak mi to zatím vždy řeklo, že zpráva není validní. V instalaci je spousta demo projektů, ale ani dema mi nikdy zprávu neověřily. Zajímalo by mě, jakým certifikátem je vlastně odpověď podepsaná, podle dokumentace to není jednoznačné. V EET_pristupove_porovozni_informace_playground_1.0.pdf v kapitole 3.3 mluví o certifikátu vydaném I.CA, stejný má být použitý i v produkčním prostředí. V EET_popis_rozhrani_v2.0.pdf v tabulce 1 na straně 8 píšou u potvrzovací datové zprávě o produkčním i testovacím certifikátu. Produkční certifikát ale podle mně ještě není dostupný, rozhodně ne na webu www.etrzby.cz.

Máte to někdo vyřešené a v čem je případně zakopaný pes?

Název: Re:Delphi + EET
Přispěvatel: ShaneZB 10-08-2016, 15:49:15
Citace
Se spuštěním infolinky se Babiš v úterý pochlubil na Twitteru. „EET jde podle plánu, infolinka 225 092 392 spuštěna, kdyby nestačila ani ta, osobně vás obsloužím na ministr@mfcr.cz,“ napsal na sociální síti.

Co se Babiše zeptat některé nejasnosti?  :)
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 15-08-2016, 10:16:43
Poslal jsem email tak pak zverejnim co prijde. :) :) :)
Název: Re:Delphi + EET
Přispěvatel: zdenek 16-08-2016, 13:33:17
Pro zájemce Remotable pro PKP, BKP:

Kód: Delphi [Vybrat]
  1. unit EET_BKPPKP;
  2.  
  3. interface
  4.  
  5. uses
  6.  Soap.InvokeRegistry,xmlintf;
  7.  
  8. const
  9.   IS_OPTN = $0001;
  10.   IS_ATTR = $0010;
  11.  
  12. type
  13.  PkpElementType=class(TRemotable)
  14.  private
  15.     Fcipher: string;
  16.     Fpkphash: string;
  17.     Fencoding: string;
  18.     Fdigest: string;
  19.  public
  20.   function   ObjectToSOAP(RootNode, ParentNode: IXMLNode;
  21.                           const ObjConverter: IObjConverter;
  22.                           const NodeName, NodeNamespace, ChildNamespace: InvString; ObjConvOpts: TObjectConvertOptions;
  23.                           out RefID: InvString): IXMLNode; override;
  24.   procedure  SOAPToObject(const RootNode, Node: IXMLNode; const ObjConverter: IObjConverter); override;
  25.   //
  26.   property pkphash:string read Fpkphash write Fpkphash;
  27.  published
  28.   property digest:         string     Index (IS_ATTR) read Fdigest write Fdigest;
  29.   property cipher:         string     Index (IS_ATTR) read Fcipher write Fcipher;
  30.   property encoding:       string     Index (IS_ATTR) read Fencoding write Fencoding;
  31.  end;
  32.  BkpElementType=class(TRemotable)
  33.  private
  34.     Fbkphash: string;
  35.     Fencoding: string;
  36.     Fdigest: string;
  37.  public
  38.   function   ObjectToSOAP(RootNode, ParentNode: IXMLNode;
  39.                           const ObjConverter: IObjConverter;
  40.                           const NodeName, NodeNamespace, ChildNamespace: InvString; ObjConvOpts: TObjectConvertOptions;
  41.                           out RefID: InvString): IXMLNode; override;
  42.   procedure  SOAPToObject(const RootNode, Node: IXMLNode; const ObjConverter: IObjConverter); override;
  43.   //
  44.   property bkphash:string read Fbkphash write Fbkphash;
  45.  published
  46.   property digest:         string     Index (IS_ATTR) read Fdigest write Fdigest;
  47.   property encoding:       string     Index (IS_ATTR) read Fencoding write Fencoding;
  48.  end;
  49.  
  50. implementation
  51.  
  52. function PkpElementType.ObjectToSOAP(RootNode, ParentNode: IXMLNode; const ObjConverter: IObjConverter; const NodeName, NodeNamespace,
  53.   ChildNamespace: InvString; ObjConvOpts: TObjectConvertOptions; out RefID: InvString): IXMLNode;
  54. begin
  55.   Result := inherited ObjectToSOAP(RootNode, ParentNode, ObjConverter, NodeName, NodeNamespace, ChildNamespace,
  56.                                    ObjConvOpts, RefId);
  57.   if (Result <> nil) then
  58.   begin
  59.    result.NodeValue:=pkphash;
  60.   end;
  61.  end;
  62.  
  63. procedure PkpElementType.SOAPToObject(const RootNode, Node: IXMLNode; const ObjConverter: IObjConverter);
  64. begin
  65.   inherited;
  66.   pkphash:=Node.Text;
  67. end;
  68.  
  69. { BkpElementType }
  70.  
  71. function BkpElementType.ObjectToSOAP(RootNode, ParentNode: IXMLNode; const ObjConverter: IObjConverter; const NodeName, NodeNamespace,
  72.   ChildNamespace: InvString; ObjConvOpts: TObjectConvertOptions; out RefID: InvString): IXMLNode;
  73. begin
  74.   Result := inherited ObjectToSOAP(RootNode, ParentNode, ObjConverter, NodeName, NodeNamespace, ChildNamespace,
  75.                                    ObjConvOpts, RefId);
  76.   if (Result <> nil) then
  77.   begin
  78.    result.NodeValue:=bkphash;
  79.   end;
  80. end;
  81.  
  82. procedure BkpElementType.SOAPToObject(const RootNode, Node: IXMLNode; const ObjConverter: IObjConverter);
  83. begin
  84.   inherited;
  85.   bkphash:=Node.Text;
  86. end;
  87.  
  88. initialization
  89.  
  90. RemClassRegistry.RegisterXSClass(PkpElementType, 'http://fs.mfcr.cz/eet/schema/v2', 'PkpElementType');
  91. RemClassRegistry.RegisterXSClass(BkpElementType, 'http://fs.mfcr.cz/eet/schema/v2', 'BkpElementType');
  92.  
  93. end.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 18-08-2016, 09:44:29
Kdybyste si někdo myslel, že už u zákazníka nasadíte novou verzi programu, tak to asi nedělejte :-) Dle hochů z podpory programujte až do 30.10 a nasazujte až potom...

Dobrý den,

možnost evidovat tržby bude spuštěna od 1.11.2016.

V současné době nelze budoucí změnu XML struktury datové zprávy vyloučit.

Od: .........
Odesláno: 17. srpna 2016 16:05
Komu: ePodpora (GFŘ)
Předmět: Dotaz z kontaktního formuláře

 
Dotaz: Dobrý den, včera byla vydána nová verze datového rozhraní. Můžete mi říci, zda jde o poslední změnu nebo zda ještě budou následovat další změny datového rozhraní? Vzhledem k velkému počtu instalací bychom už potřebovali u zákazníků instalovat nové verze programů připravené na EET a pokud budete znovu měnit verze datového rozhraní, něco takového postrádá smysl.
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 19-08-2016, 08:06:55
Kdybyste si někdo myslel, že už u zákazníka nasadíte novou verzi programu, tak to asi nedělejte :-) Dle hochů z podpory programujte až do 30.10 a nasazujte až potom...

Tak to po zkušenostech z minulosti se státní správou rozhodně neudělám. Onehdá jsme nasazovali normalizované výkazy pro příspěvkové organizace. Udělali jsme export do XML na jejich portál. Od té doby pravidelně snad každý rok nejméně dvakrát mění naprosto podle mě nesmyslně strukturu toho XML. Přitom je to tak jednoduché. Kdyby na začátku někdo u nich to dobře zanalyzoval, tak mohl být pokoj. Na tom je přesně vidět, že tam ty státní zaměstnanci nemají do čeho píchnout, tak alespoň neustále mění zbytečně strukturu XML, aby vykázali nějakou činnost. Osobně čekám další změny. Když vidím to XML, co vymysleli, tak fakt z toho nemůžu. Takže podle mě EET bude naprosto to samé. Připravme se na to, že to budou neustále měnit, údajně "zlepšovat", pak jim to nakonec Ústavní soud zruší a veškeré programování půjde do háje. Ale hlavní je, že peníze z našich daní mají jisté. To se to žije z cizího...
Název: Re:Delphi + EET
Přispěvatel: oxo 19-08-2016, 22:08:54
A ještě si při tom vytunelujou evropské dotace a všichni možní darmožroujti pak můžou argumentovat, jak na té EU vyděláváme, kolik jsme z ní vyždímali peněz  :-X
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 23-08-2016, 19:42:47
Ahojte nasel jsem konecne funkcni priklady
Java 7
Java 8
.NET
Android Application

Je to OPENEET
https://github.com/l-ra/openeet (https://github.com/l-ra/openeet)

da se to prevest i do SharpDevelop C#
Neni to delphi, ale je to cisty kod.
Mam DLL upravene i pro verzi API EET 3.
Bohuzel se mi nedari udelat dll ktere nacte Delphi.
Zkuste to nekdo  :)
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 23-08-2016, 21:27:56
Ahojte nasel jsem konecne funkcni priklady
Java 7
Java 8
.NET
Android Application

Je to OPENEET
https://github.com/l-ra/openeet (https://github.com/l-ra/openeet)

da se to prevest i do SharpDevelop C#
Neni to delphi, ale je to cisty kod.
Mam DLL upravene i pro verzi API EET 3.
Bohuzel se mi nedari udelat dll ktere nacte Delphi.
Zkuste to nekdo  :)
sem objevil ameriku  :) nevsiml jsem si, ze odkaz tu je.  :-[
ale i tak nevite nekdo jak z toho udelat DLL pro delphi ?
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 23-08-2016, 22:07:25
Pokud to máš jako .NET assembly, tak ji z Delphi nactes a provedeš http://delphi.cz/post/Spoluprace-Delphi-a-NET-via-JCL.aspx (http://delphi.cz/post/Spoluprace-Delphi-a-NET-via-JCL.aspx)
Název: Re:Delphi + EET
Přispěvatel: pavel 24-08-2016, 09:14:08
Ahoj,
zacinam programovat EET a zatim bojuji s PKP a BPK.
Muj dotaz je ale na neco jineho, Jak odeslat data na playground. Manualu z etrzby.cz nerozumim.
Ani netusim, co jsou certifikaty a jak je pouzit a implementovat do delphi.
Poradi nekdo
Pavel
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 25-08-2016, 23:55:55
Ahoj,
zacinam programovat EET a zatim bojuji s PKP a BPK.
Muj dotaz je ale na neco jineho, Jak odeslat data na playground. Manualu z etrzby.cz nerozumim.
Ani netusim, co jsou certifikaty a jak je pouzit a implementovat do delphi.
Poradi nekdo
Pavel

nainstaluj si Jcl viz odpoved od Radka Cervinky a pripoj se na openeet a tu je volani dll

procedure TSDIAppForm.Button1Click(Sender: TObject);
var
  Host: TJclClrHost;
  Obj: OleVariant;
   UTF8Str: UTF8String;
   date:tdatetime;
begin
try
    Host := TJclClrHost.Create('v4.0.30319');
    Host.Start();

    Obj := Host.DefaultAppDomain
        .CreateInstancefrom('openeet-lite.dll',
        'openeet_lite.Builder')
        .UnWrap();
           
           obj.dat_trzby(now);
           obj.dic_popl('CZ1212121218');
           obj.id_provoz('1');
             obj.id_pokl('POKLADNA01');
             obj.porad_cis('1');
             
             obj.celk_trzba(100.0);
             obj.rezim(0);
           obj.pkcs12('01000003.p12');
             obj.pkcs12password('eet');
             obj.build;

   

    Host.Stop();
    Host.Free;
  Except
     on E : Exception do
     begin
       ShowMessage('Exception class name = '+E.ClassName + ' ' + 'Exception message = '+E.Message);
     end;
  end;
end;
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 28-08-2016, 10:59:13
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 :-)

Nejak se v tom ztracim,
kdyz podepisu XML  a to pak posilam, tak kdy vznikne situace, ze podepsane XML nemohu poslat v jiny den, kdyz se ho nepodarilo poslat v den trzby?.
Dva dny stare podepsane XML mi jde poslat i z jineho pc kde certifikaty nejsou.


Název: Re:Delphi + EET
Přispěvatel: vlatik.c 30-08-2016, 15:40:52
abychom se nenudili
Součástí připravované metodiky je však i možnost zaslat v určitých situacích požadované údaje o tržbách přijatých v době poruchy jednou sumární částkou. Jedná se právě o situace, kdy je během poruchy přijato velké množství tržeb a požadavek k jejich jednotlivému zaslání by byl pro podnikatele nereálný nebo nadměrně zatěžující. (GFŘ).
Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 31-08-2016, 11:55:16
Nejak se v tom ztracim,
kdyz podepisu XML  a to pak posilam, tak kdy vznikne situace, ze podepsane XML nemohu poslat v jiny den, kdyz se ho nepodarilo poslat v den trzby?.
Dva dny stare podepsane XML mi jde poslat i z jineho pc kde certifikaty nejsou.

Teď se zase ztrácím já - datová zpráva obsahuje datum a čas odeslání. To zprávu odesíláte se starým datem odeslání?

Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 31-08-2016, 11:58:29
Kdybyste si někdo myslel, že už u zákazníka nasadíte novou verzi programu, tak to asi nedělejte :-) Dle hochů z podpory programujte až do 30.10 a nasazujte až potom...

A to se vsadím že se Babiš zase bude někde v televizi prsit že o EET všichni všechno věděli rok dopředu a že měli dost času se připravit :-) Jako s kontrolním hlášením DPH ...
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 31-08-2016, 22:13:27
A to se vsadím že se Babiš zase bude někde v televizi prsit že o EET všichni všechno věděli rok dopředu a že měli dost času se připravit :-) Jako s kontrolním hlášením DPH ...

Přesně, lépe bych to neřekl. V našem ERP jsme měli za úkol implementovat Kontrolní hlášení DPH já a moje nadřízená analytička. Ta objížděla všechna možná školení a četla ty nesmyslné zákony a vyhlášky. Větší bordel jsem neviděl. Bylo mi z toho na blití, ale naprogramovat jsem to musel, naši zákazníci to potřebovali. A když pak vidíš, jak si Babiš pochvaluje, jak to bylo všechno v pohodě ... prostě totalita je tady zpět se vším všudy. A EET bude to samé. Když vidím svoji dceru, do jaké totality to zase roste, tak začínám přemýšlet o tom, že moji známý programátoři udělali možná dobře, že kdysi odjeli do zahraničí. A nejhorší je, že to lidé volí a volit budou. On si zase vymyslí pohádky alá Čapí hnízdo. Jsem teď na dovolené, po jejím návratu se budu muset vrhnout na EET. Kdyžtak pak se zapojím do této diskuze o pokusím se také pomoci. Bohužel s tím nic neuděláme, to prostě naprogramovat budeme muset. Ještě kdyby to zrušil Ústavní soud, ale ten v podstatě je už podle mě prolezlý také jejich příznivci a obávám se, že s tím nikdo nic neudělá. Už máme pár zákazníků, kteří s podnikáním prostě skončili. Turecko hadr oproti tomuhle ...
Název: Re:Delphi + EET
Přispěvatel: Stanislav Hruška 01-09-2016, 09:21:18
OT:
Už som si myslel, že takéto "vymoženosti" máme výhrade len na Slovensku. U nás sa medzi podnikateľmi hovorí, že podnikanie je trestný čin.
Len poznámočka: na daniach sa vybrala rekordná suma a dane sa idú zvyšovať. To nie je irónia.
Název: Re:Delphi + EET
Přispěvatel: vlada 01-09-2016, 14:19:40
Předem chci poděkovat autoru Mirkovi https://github.com/mirus77/DelphiEET

Podařilo se někomu rozpohybovat na Delphi XE? Mám problém s metodou xmlSecDSigCtxSign z unity libxmlsec, která vrací -1, tedy nedaří se podepsat XML dokument.

Nainstaloval jsem demo Delphi Berlin a tam to běží bez problému.
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 12-09-2016, 18:55:08
Ahojte zde mate reseni v Turbo Delphi s jednim DLL vcetne zdroje v c#

https://github.com/vlastikcocek/openeet/tree/master/dotnet (https://github.com/vlastikcocek/openeet/tree/master/dotnet)
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 13-09-2016, 12:01:27
Metodický dotaz

Dotaz: dobry den, mate vypracovanou metodiku pro možnost zaslat v určitých situacích požadované údaje o tržbách přijatých v době poruchy jednou sumární částkou. Jedná se právě o situace, kdy je během poruchy přijato velké množství tržeb a požadavek k jejich jednotlivému zaslání by byl pro podnikatele nereálný nebo nadměrně zatěžující ?

# Odpoved Z GFR:

Dobrý den,
 
podle § 30 odst. 1 ZoET správní delikt podle tohoto zákona projednává finanční úřad nebo celní úřad. Podle § 30 odst. 2 ZoET pak správní delikt projednává ten orgán, který provádí nebo provedl prověřování plnění povinností podle tohoto zákona. Tato ustanovení vymezují věcnou a místní příslušnost a pravomoc vybraných orgánů veřejné moci k projednání správních deliktů podle zákona o evidenci tržeb. Věcně příslušnými jsou dle uvedeného finanční úřady ve smyslu ustanovení § 8 odst. 1 zákona č. 456/2011 Sb., o Finanční správě České republiky, ve znění pozdějších předpisů a celní úřady ve smyslu § 6 odst. 1 zákona č. 17/2012 Sb., o Celní správě České republiky, ve znění pozdějších předpisů. Místně příslušným pak bude kterýkoliv z věcně příslušných orgánů, který zjistí porušení povinnosti.
 
Podle § 30 odst. 3 ZoET právnická osoba a podnikající fyzická osoba za správní delikt neodpovídá, prokáže-li, že vynaložila veškeré úsilí, které bylo možno požadovat, aby porušení právní povinnosti zabránila. Uvedené lze mimo jiné aplikovat na „poruchy“ pokladního zařízení.
 
V případě poruchy pokladního zařízení může poplatník ve své činnosti pokračovat. Z povahy věci je však zřejmé, že nebude v daném okamžiku moci zaslat správci daně datovou zprávou údaje o evidované tržbě a vystavit zákazníkovi účtenku, která by obsahovala všechny údaje uvedené v § 20 ZoET, neboť bezpečnostní kód poplatníka (BKP), fiskální identifikační kód (FIK) nebo podpisový kód poplatníka (PKP) mohou být získány pouze z funkčního pokladního zařízení.
 
Liberační důvod je naplněn v případě neodvratitelné události přicházející zásahem zvenčí (např. porucha zařízení v důsledku přepětí elektrické energie, přerušení elektrické energie v důsledku překopání kabelů, zkrat v elektroinstalaci způsobivší výpadek elektrické energie i po zapnutí jističe apod., nebo náhlá porucha pokladního zařízení), který při běžném provozu pokladního zařízení vyvolá škodlivý účinek, jemuž nemohl poplatník nikterak zabránit, a nebylo možné škodlivému účinku předejít ani použitím dostupných opatření. Zároveň se může jednat o situace vedoucí k porušení povinnosti, při níž nelze objektivně nikdy na straně poplatníka vyšší úsilí vyžadovat, tj. jedná se o náhlé, nepředvídatelné a nevyhnutelné okolnosti, které poplatníkovi zabránily splnit uloženou povinnost. Prokázáním uvedených skutečností pak může být např. potvrzení dodavatele elektrické energie o výpadku; doklad, po jakou dobu bylo pokladní zařízení v servisu, potvrzení od elektrikáře o době opravy apod.
 
Údaje o přijatých platbách po dobu nefunkčního pokladního zařízení je však poplatník povinen správci daně zaslat elektronickou cestou z funkčního pokladního zařízení dodatečně po odstranění příčin. Zákon o evidenci tržeb upravuje pouze zasílání údajů o jednotlivých tržbách a zánik této povinnosti v případě poruch z něho nijak nevyplývá. V určitých situacích, kdy je během poruchy přijato velké množství tržeb a požadavek k jejich jednotlivému zaslání by byl pro poplatníka nereálný nebo nadměrně zatěžující, lze liberaci uvedenou v § 30 odst. 3 ZoET vztáhnout i na zasílání údajů dle jednotlivých tržeb a umožnit poplatníkům, aby údaje o tržbách přijatých v době poruchy zaslali správci daně jednou sumární částkou.
 
Každý případ je však vždy nutné posuzovat individuálně s ohledem na konkrétní okolnosti daného případu. Pokud by například došlo pouze k přerušení internetového připojení, ale pokladní zařízení by zůstalo funkční, může být liberace vztažena pouze na nezaslání údajů správci daně včas. Na nevydání účtenky, příp. na možnost zaslat údaje jednou sumární částkou, by se za této situace liberace nevztahovala.
 
Při posouzení Vámi předloženého emailového dotazu vycházelo Generální finanční ředitelství výhradně z údajů uvedených ve Vašem dotazu, a to bez dalších konkrétních informací a souvislostí, které se k předmětné situaci vztahují. Upozorňujeme, že Generální finanční ředitelství neposkytuje závazný výklad a aplikaci právních předpisů. K tomuto je v individuálních případech oprávněný místně a věcně příslušný soud. Poskytnuté informace nenahrazují závazný právní výklad, závazné posouzení o určení evidované tržby či rozhodnutí v soudním řízení.
 
S pozdravem
 
Ing. Kristýna Misiarzová
Generální finanční ředitelství
Metodická podpora evidence tržeb
E-mail: eet@fs.mfcr.cz
Web: www.e-trzby.cz
Název: Re:Delphi + EET
Přispěvatel: Stanislav Hruška 13-09-2016, 12:11:44
OT: To je v akom jazyku? Ale toto ma pobavilo
Citace
předejít řitního použitím dostupných Opatření
Název: Re:Delphi + EET
Přispěvatel: pf1957 13-09-2016, 12:32:46
OT: To je v akom jazyku? Ale toto ma pobavilo
Me to prijde, ze Babiška vyloudil na Chorvatech popis k jejich systému a těď to někde nějaká teta na podpoře překládá Googlem  ;D
Název: Re:Delphi + EET
Přispěvatel: raul 13-09-2016, 15:40:18
Upozorňujeme, že Generální finanční ředitelství neposkytuje závazný výklad a aplikaci právních předpisů. K tomuto je v individuálních případech oprávněný místně a věcně příslušný soud.

Me pobavilo tohle, takze jako vzdy, zadnej ourada (na kteryho si ani nesmite otevrit hubu), za vubec nic nezodpovida - a to nejen jako fyzicka osoba, ale ani jako osoba zastupujici pravnickou osobu (ci stat). Tak k cemu tam vlastne je ? Tuhle odpoved si totiz muzete akorat tak strcit nekam, nebot to znamena, ze se pani dneska vyspala a napsala toto. Zejtra klido napise neco jineho a vy s tim nic neudelate.
Název: Re:Delphi + EET
Přispěvatel: Jan Šebelík 16-09-2016, 09:20:39
Ahoj.

Od počátku jsem věděl, že mě EET nemine. Sleduju to zpovzdálí několik měsíců, od záři jsem začal naostro. Jenže ...!!! Čím víc jsem se do toho ponořoval, tím víc mi bylo jasné, že to sám nezvládnu.

Windows XP, Delphi 7, Visual Studio 2008, .NET 3.5. Nový počítač s Win7 jsem už objednal. To ale samo o sobě stačit nebude. Do Delphi XE se mi nechce. RAD Studio XE Professional jsem v roce 2011 koupil, vyzkoušel a smazal. S .NET pracuju jenom výjimečně, kupovat nejnovější verze je nonsens.

Studuju dokumentaci: ale je napsána pro mě neznámým jazykem.
http://www.etrzby.cz/assets/cs/prilohy/EET_popis_rozhrani_v3.0.pdf
http://www.etrzby.cz/assets/cs/prilohy/Popis_polozek_datove_zpravy_v3.0.pdf
Jenom třeba kapitola 6 popisu rozhraní. Absolutně nemám ponětí, o čem to je.

Zde zrekapituluju, co jsem kde k tématu nalezl. Může to být pro vás užitečné. Případně doplňte.

https://github.com/l-ra/openeet/ (android, dotnet, java, stunnel-eet)
https://github.com/vlastikcocek/openeet (android, dotnet, java, stunnel-eet, delphi-test)
https://github.com/mirus77/DelphiEET
http://forum.delphi.cz/index.php/topic,15267.45.html (PKP+BKP, volání openeet-lite přes Jcl)
https://sourceforge.net/p/f4d/wiki/Home/ (Chorvatsko - F4D-0.3.3.8 )
https://groups.google.com/d/msg/foxpro/dm0FRwXk2vc/zIRxiE3wCAAJ (FoxPro, MSXML2.XMLHTTP.3.0)
https://groups.google.com/forum/#!topic/foxpro/dm0FRwXk2vc%5B1-25%5D
https://groups.google.com/forum/#!topic/foxpro/dm0FRwXk2vc%5B51-75%5D (prodej knihovny - JADU)
https://groups.google.com/forum/#!topic/foxpro/dm0FRwXk2vc%5B76-100%5D (Karel Král - řešení, Radim Kolek - XP funguje)
https://groups.google.com/forum/#!topic/foxpro/dm0FRwXk2vc%5B101-125%5D (podepisování, LR - dotnet řešení, JADU - distribuce)
https://github.com/isdoc/dsig-demo (podepisování certifikátů)
https://github.com/zinkpad/SignSoapMessage (podepisování SOAP zprávy)
http://www.jadu.cz/data/EET/EETsetup.zip (JADU - distribuce)

Tak a teď jak do toho. Výše zmíněné projekty svými nástroji nejenže nepřeložím, ale ani neotevřu. Hledám cestu, kudy se vydat.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 16-09-2016, 09:42:13
Co nepřeložíš např. na openeet-lite přes Jcl? Nedávno jsem rozchodil pro jednoho člověka volání .NET assembly v D4 právě via JCL, i když JCL je od D6. A ty máš D7.
Název: Re:Delphi + EET
Přispěvatel: Roman Krejčí 16-09-2016, 11:38:34
..................
Tak a teď jak do toho.
..................

Evidence tržby není nic jiného než zavolání nějaké Webové služby na serveru GFŘ.
Především je tedy třeba podívat se na o, jak se v Delphi pracuje s webovými službami. D7 to celkem zvládá,
i když wsdl import jsem si musel trochu upravit.
Druhá věc je podívat se jak v Delphi pomocí certifikátu vyrobit podpisy a) nějakého obsahu paměti b) XML paketu dle příslušných XML norem.
Já to řešil knihovnama ELDOS (jo, je to drahý, ale ušetří mi to čas se zporovozňováním zadara řešení).
Na verzi Delphi vlastně ani moc nezáleží (teda pokud mluvíme o D7 a víše :-) Funkční  D7 projekt jsem bez větší námahy přenesl pod XE5.
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 16-09-2016, 21:31:32
Byl jsem dnes na seminari EET v Brne, byl tam aji Babis a rikal, ze  si vyzkousite v praxi, ze EET funguje a prodejci obcerstveni vam vydaji doklad s testovacim EET (FIK a BKP).
Celkem me pobavilo co mi dali za doklad po zakoupeni dvou rizku. :) :) :) :)
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 16-09-2016, 21:48:29
Že by předzvěst toho, jak bude vše "pěkně" fungovat po ostrém zahájení provozu? :-)
Název: Re:Delphi + EET
Přispěvatel: vladac 19-09-2016, 08:15:47
Pochopil jsem správně, že Windows XP a Vista nemají protokol TLS 1.2 a tudíž jediná cesta pro tyto operační systémy je nativní TLS? Nativní TLS nabízí pro Delphi snad jen Eldos. Ceníku nerozumím. Eldos jak jsem pochopil mají vlastní komponenty pro volání vzdálených funkcí XML SOAP.

Na ty z vás, kterým se již komunikace pomocí Eldos zdařila, bych měl ještě dotaz. Kolik komponenty stojí a o kolik MB jim narostla aplikace (demo balíček má velikost 120 MB). No a kdyby snad byl i příklad, to by bylo báječné.
Název: Re:Delphi + EET
Přispěvatel: < z > 19-09-2016, 09:18:03
Na to tu jsou pro komunikaci Indy komponenty s OpenSSL ...
Název: Re:Delphi + EET
Přispěvatel: Jan Šebelík 19-09-2016, 14:49:11
Co nepřeložíš např. na openeet-lite přes Jcl? Nedávno jsem rozchodil pro jednoho člověka volání .NET assembly v D4 právě via JCL, i když JCL je od D6. A ty máš D7.
Díky za odpověď, ale nevím, zda si rozumíme.

Jediné řešení EET obsahující Jcl jsem našel tady: https://github.com/vlastikcocek/openeet/tree/master/dotnet/delphi_test (https://github.com/vlastikcocek/openeet/tree/master/dotnet/delphi_test)
Vlastimil Čoček ale používá JclDotNet. Tak nevím ...

Přes Jcl nechci nic spouštět. COM object napsaný v C# umím spustit i bez Jcl. Buďto najdu řešení čistě v Delphi 7, nebo jsem nakloněn napsat/převzít nějakou C# assembly spustitelnou jako COM objekt
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 19-09-2016, 23:48:51
Co nepřeložíš např. na openeet-lite přes Jcl? Nedávno jsem rozchodil pro jednoho člověka volání .NET assembly v D4 právě via JCL, i když JCL je od D6. A ty máš D7.
Díky za odpověď, ale nevím, zda si rozumíme.

Jediné řešení EET obsahující Jcl jsem našel tady: https://github.com/vlastikcocek/openeet/tree/master/dotnet/delphi_test (https://github.com/vlastikcocek/openeet/tree/master/dotnet/delphi_test)
Vlastimil Čoček ale používá JclDotNet. Tak nevím ...

Přes Jcl nechci nic spouštět. COM object napsaný v C# umím spustit i bez Jcl. Buďto najdu řešení čistě v Delphi 7, nebo jsem nakloněn napsat/převzít nějakou C# assembly spustitelnou jako COM objekt

Ahoj, mohl by jsi zverejnit spusteni COM object napsaný v C#  bez Jcl ?  docela by mne to zajimalo. dik
Název: Re:Delphi + EET
Přispěvatel: zdenek 20-09-2016, 16:09:26
Co se týká ElDOS, tak jsou potřeba následující balíčky:

- XMLBlackBox VCL - podepisování a ověřování XML
- XMLBlackBox NG - to samé ale pro mobilní vývoj
- HTTPBlackBox - pro komunikaci přes SOAP + ověření validity certifikátu

Pokud použijete SOAP z Delphi (RIO) (win nebo indy verzi), neotřebujete HTTPBlackBox na SOAP. Ale pozor, pokud chcete ověřovat podepsanou odpověď včetně CRL, tak ho potřebujete nebo si musíte podle certifikátu stáhnout CRL seznam pomocí vlastního http get a ten pak předhodit validátoru certifikátu.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 21-09-2016, 09:45:31
- XMLBlackBox VCL - podepisování a ověřování XML
Zkoušel jsem ověřit vrácenou XML zprávu pomocí třídy TElXMLVerifier (ELDOS, XML BlackBox). U té třídy se toho nedá moc nastavit, přesto mi verifikace nikdy neprošla. Můžeš naznačit, jak ověřuješ vrácenou XML zprávu ?

Jinak pro informaci, jak se kdosi ptal, po zkompilování XML BlackBoxu se výsledný exáč zvětšil asi o 6-7 MB.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 21-09-2016, 10:41:39
Není mi úplně jasné kam v procesu komunikace zařadit krok "ověřování podpisu vrácené odpovědi" :-) Podle mne je to ta nejzbytečnější část, protože důvěryhodnost komunikace je zajištěna https protokolem, takže jediný problém vznikne když někdo hakne nebo zneužije server GFŘ, a promiňte mi, to už není můj problém :-)
Název: Re:Delphi + EET
Přispěvatel: pepak 21-09-2016, 10:45:06
Není mi úplně jasné kam v procesu komunikace zařadit krok "ověřování podpisu vrácené odpovědi" :-) Podle mne je to ta nejzbytečnější část, protože důvěryhodnost komunikace je zajištěna https protokolem, takže jediný problém vznikne když někdo hakne nebo zneužije server GFŘ, a promiňte mi, to už není můj problém :-)
Nebo třeba když přesměruje spojení na falešný server ověřený něčím jako WoSign nebo Comodo.
Název: Re:Delphi + EET
Přispěvatel: pf1957 21-09-2016, 11:06:51
Podle mne je to ta nejzbytečnější část, protože důvěryhodnost komunikace je zajištěna https protokolem, takže jediný problém vznikne když někdo hakne nebo zneužije server GFŘ, a promiňte mi, to už není můj problém :-)
Jen takova poznamka: kdyz implementujete EET klienty: co auditni log? Vytvarite si? Idealne asi v oblacich? Abyste mohli dolozit co, kdy a kam jste poslali a jak to dopadlo, az se vas treba nekdo bude snazit hnat k zodpovednosti a nejake penalizaci za dysfunkce EET ;-) Prece jenom jde o penize...
Název: Re:Delphi + EET
Přispěvatel: zdenek 21-09-2016, 11:37:28
Není mi úplně jasné kam v procesu komunikace zařadit krok "ověřování podpisu vrácené odpovědi" :-) Podle mne je to ta nejzbytečnější část, protože důvěryhodnost komunikace je zajištěna https protokolem, takže jediný problém vznikne když někdo hakne nebo zneužije server GFŘ, a promiňte mi, to už není můj problém :-)

A co útok MiM?
Název: Re:Delphi + EET
Přispěvatel: zdenek 21-09-2016, 11:43:23
Ověření by mělo být v AfterExecute (pokud se používá RIO) asi nějak takto:

Kód: Delphi [Vybrat]
  1. procedure THSFTFunkceEET.DoAfterExecute(const MethodName: string;  SOAPResponse: TStream);
  2. var EXML:TElXMLDOMDocument;
  3.     EMSG:TElXMLSOAPMessage;
  4.     Handler: TElXMLSOAPCustomSignatureHandler;
  5.     Status : TSBXMLSOAPSignatureValidationStatus;
  6. begin
  7.   SOAPResponse.Position:=0;
  8.   EXML:=TElXMLDOMDocument.Create;
  9.   EXML.LoadFromStream(SOAPResponse, '', true);
  10.  
  11.   EMSG:=TElXMLSOAPMessage.Create(nil);
  12.   EMSG.LoadFromXML(EXML);
  13.  
  14.   if EMSG.SignatureHandlerCount > 0 then
  15.     Handler := TElXMLSOAPCustomSignatureHandler(EMSG.SignatureHandlers[0])
  16.   else
  17.   begin
  18.     ErrorMessage('Odpověď EET není podepsána.', '', '', 0);
  19.     exit;
  20.   end;
  21.  
  22.   Status := TElXMLSOAPBaseSignatureHandler(Handler).Validate;
  23.  
  24.   if (Status <> ssvsValid) and (Status <> ssvsInvalidReferenceDigest ) then
  25.   begin
  26.     ErrorMessage('Neplatný podpis odpovědi EET.', '', '', 0);
  27.   end;
  28.  
  29.   -- sem přijde validace certifikátu
  30.  
  31.   Handler.Free;
  32.   SOAPResponse.Position:=0;
  33. end;
Název: Re:Delphi + EET
Přispěvatel: pf1957 21-09-2016, 12:09:26
A co útok MiM?
Resiva se to kontrolou hashu ev. serioveho cisla certifikatoru, ale nevim, jestli EET na strane serveru hash publikuje nebo jinak umoznuje zkontrolovat jeho pravost.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 21-09-2016, 12:42:52
Ověření by mělo být v AfterExecute (pokud se používá RIO) asi nějak takto:

Kód: Delphi [Vybrat]
  1. procedure THSFTFunkceEET.DoAfterExecute(const MethodName: string;  SOAPResponse: TStream);
  2. var EXML:TElXMLDOMDocument;
  3.     EMSG:TElXMLSOAPMessage;
  4.     Handler: TElXMLSOAPCustomSignatureHandler;
  5.     Status : TSBXMLSOAPSignatureValidationStatus;
  6. begin
  7.   SOAPResponse.Position:=0;
  8.   EXML:=TElXMLDOMDocument.Create;
  9.   EXML.LoadFromStream(SOAPResponse, '', true);
  10.  
  11.   EMSG:=TElXMLSOAPMessage.Create(nil);
  12.   EMSG.LoadFromXML(EXML);
  13.  
  14.   if EMSG.SignatureHandlerCount > 0 then
  15.     Handler := TElXMLSOAPCustomSignatureHandler(EMSG.SignatureHandlers[0])
  16.   else
  17.   begin
  18.     ErrorMessage('Odpověď EET není podepsána.', '', '', 0);
  19.     exit;
  20.   end;
  21.  
  22.   Status := TElXMLSOAPBaseSignatureHandler(Handler).Validate;
  23.  
  24.   if (Status <> ssvsValid) and (Status <> ssvsInvalidReferenceDigest ) then
  25.   begin
  26.     ErrorMessage('Neplatný podpis odpovědi EET.', '', '', 0);
  27.   end;
  28.  
  29.   -- sem přijde validace certifikátu
  30.  
  31.   Handler.Free;
  32.   SOAPResponse.Position:=0;
  33. end;

Na Playgroundu mi to vraci status ssvsNoKey, takže validace se nedaří...
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 21-09-2016, 14:14:26
Díky za inspiraci. Mě se daří tak napůl:  :D

1. mám uložený soubor odpovědi z Playgroundu v2, tento jsem prohnal validací s výsledkem ssvsValid.
Vypsal jsem si certifikát:
Subject CommonName "Elektronická evidence tržeb - Playground"
Subject Organization "Česká republika - Generální finanční ředitelství"
Issuer CommonName "I.CA - Qualified Certification Authority, 09/2009"
Issuer Organization "První certifikační autorita, a.s."
Výborně, všechno OK.

2. mám uložený soubor odpovědi z Playgroundu v3, tento jsem prohnal úplně stejnou validací s výsledkem ssvsInvalidSignature.
Soubor samozřejmě obsahuje FIK, takže by měl být validní.
Tož tak...
Název: Re:Delphi + EET
Přispěvatel: pepak 21-09-2016, 17:08:54
Jen takova poznamka: kdyz implementujete EET klienty: co auditni log? Vytvarite si? Idealne asi v oblacich? Abyste mohli dolozit co, kdy a kam jste poslali a jak to dopadlo, az se vas treba nekdo bude snazit hnat k zodpovednosti a nejake penalizaci za dysfunkce EET ;-) Prece jenom jde o penize...
U jiné podobné služby loguju svoje requesty a případnou odpověď a plánuju v tom pokračovat i v EET.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 21-09-2016, 21:54:11
Citace
Jen takova poznamka: kdyz implementujete EET klienty: co auditni log? Vytvarite si? Idealne asi v oblacich? Abyste mohli dolozit co, kdy a kam jste poslali a jak to dopadlo, az se vas treba nekdo bude snazit hnat k zodpovednosti a nejake penalizaci za dysfunkce EET ;-) Prece jenom jde o penize...

Loguji každý odeslaný request a response + http hlavičky. Úspěšnou komunikaci po měsíci mažu, neúspěšnou uschovávám 2 roky. Ať se úřady nažerou, když budou potřebovat.
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 22-09-2016, 07:50:36
Loguji každý odeslaný request a response + http hlavičky. Úspěšnou komunikaci po měsíci mažu, neúspěšnou uschovávám 2 roky. Ať se úřady nažerou, když budou potřebovat.

Úřady se nenažerou nikdy :-) Na školách v různých přihlouplých oborech živíme ze svých daní tisíce a tisíce nových naprosto nepotřebných a nezaměstnatelných jedinců, pro které vytvářejí nová a nová místa na úřadech. Vzhledem k tomu, kolik jich je a kolik se jim neustále přidává peněz, tak to už není obezita, to je rakovina. A bude hůř.
Název: Re: Delphi + EET
Přispěvatel: pf1957 22-09-2016, 08:07:29
Úřady se nenažerou nikdy :-)
Nejsem danar, takze o problematice ucetnictvi ani EET nic nevim, ale mam dojem, ze u obecne danove kontroly se FU muze chtit nazrat az 10 let zpetne...
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 22-09-2016, 09:11:27
Nejsem danar, takze o problematice ucetnictvi ani EET nic nevim, ale mam dojem, ze u obecne danove kontroly se FU muze chtit nazrat az 10 let zpetne...

To si myslím, že je přesné. Moje nadřízená analytička a účetní zároveň měla kdysi ve starých prostorech firmy hned vedle svého kanclu další, který byl narvaný bednami s fakturami a dalšími doklady až ke stropu. Když jsem onehdy zjišťoval, proč to tam má, tak mi právě říkala o těch 10ti letech. Ale dnes snad už to požadují nejenom v papírové formě. I když ... jsou to úřady a ouřada nerad něco mění :-)
Název: Re:Delphi + EET
Přispěvatel: JaroB 22-09-2016, 13:40:19
Dost dlouho mi trvalo, než jsem pochopil, co je to "danar" - a není to http://www.kralovstvidanar.com/cs/ (http://www.kralovstvidanar.com/cs/)

:)
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 26-09-2016, 12:46:06
To se nám to komplikuje https://www.souki.cz/eet-pro-eshopy-je-postavene-na-hlavu (https://www.souki.cz/eet-pro-eshopy-je-postavene-na-hlavu), hlavně ohledně platebních karet. Je mi z toho blbě.
Název: Re:Delphi + EET
Přispěvatel: oxo 26-09-2016, 13:00:22
No ty bláho, doteď jsem byl vysmátej a myslel jsem si, že se mě EET netýká. A teď zjistím, že se musí evidovat i online tržby přes PayPal ???

Takže nejenom, že se seru se SH a MOSS, ale teď ještě i s EET... No myslím, že si seženu nějakou zprostředkovatelskou službu v zahraničí. Snad nějaká bude z Evropy...
Název: Re:Delphi + EET
Přispěvatel: < z > 26-09-2016, 13:39:41
Nějak jsem tomu nevěnoval pozornost, tak jen otázka, jestli to chápu dobře.

Když podnikající programátor prodá licenci na program a zákazník zaplatí online kartou a podobně, tak to jako kvůli takové kravině budu muset si projet kolečko s EET a ještě odesílat po každé prodané licenci hlášení? A pak se to stejně objeví na účtu? ... fakt chudáci ti lidi, co budou muset mít EET kvůli "10" platbám.
Název: Re:Delphi + EET
Přispěvatel: Lukas 26-09-2016, 13:48:01
kvůli pár platbám není potřeba podání elektronicky, stačí požádat FÚ o vyjímku na zjednodušený režim (vystavení je pak na účtenky obdržené od FU).
stejně jako ten, kdo fakturuje s 99% převodním příkazem, tak udělá to samé.
navíc se to týká IT až od 3/2018 a kdo ví, co se za tu dobu stane. :)
Název: Re:Delphi + EET
Přispěvatel: oxo 26-09-2016, 13:52:07
Nějak jsem tomu nevěnoval pozornost, tak jen otázka, jestli to chápu dobře.

Když podnikající programátor prodá licenci na program a zákazník zaplatí online kartou a podobně, tak to jako kvůli takové kravině budu muset si projet kolečko s EET a ještě odesílat po každé prodané licenci hlášení?

Tak jsem to pochopil taky. A to EET kolečko musí být automatizované, t.j. zákazník musí dostat účet včetně EET balastu okamžitě.
Název: Re:Delphi + EET
Přispěvatel: < z > 26-09-2016, 14:11:56
Do 2018 se může stát cokoliv, ale už je to práce navíc sledovat, co s tím zas vymyslí.
S automatikou taky můžou být problémy, jak by to napojení mělo fungovat - to mě spíš napadá potom pořídit nějakou zdarma dostupnou pokladnu a jak platba dojde, tak to tam naťukat a odeslat. Ale jestli to zůstane, tak to bude dobrej opruz.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 26-09-2016, 14:35:27
Do 2018 se může stát cokoliv, ale už je to práce navíc sledovat, co s tím zas vymyslí.
S automatikou taky můžou být problémy, jak by to napojení mělo fungovat - to mě spíš napadá potom pořídit nějakou zdarma dostupnou pokladnu a jak platba dojde, tak to tam naťukat a odeslat. Ale jestli to zůstane, tak to bude dobrej opruz.

Jak provedeš natukaní v okamžiku platby online kartou? Já to chápu tak, že v okamžiku online platby kartou musí mít nakupující možnost ověřit účtenku - tj. musíš to udělat obratem. Ach jo.

Název: Re:Delphi + EET
Přispěvatel: pepak 26-09-2016, 15:25:45
Když podnikající programátor prodá licenci na program a zákazník zaplatí online kartou a podobně, tak to jako kvůli takové kravině budu muset si projet kolečko s EET
Ano.
Citace
a ještě odesílat po každé prodané licenci hlášení?
Ano.
Citace
A pak se to stejně objeví na účtu?
Ano.

kvůli pár platbám není potřeba podání elektronicky, stačí požádat FÚ o vyjímku na zjednodušený režim (vystavení je pak na účtenky obdržené od FU).
stejně jako ten, kdo fakturuje s 99% převodním příkazem, tak udělá to samé.
Podle seminářů, na kterých jsem byl, ovšem FÚ tu výjimku pro tyhle případy nedá.
Citace
navíc se to týká IT až od 3/2018 a kdo ví, co se za tu dobu stane. :)
Optimista řekne, že se to třeba zruší. Já se obávám, že se to posune k dřívějšímu datumu.

A to EET kolečko musí být automatizované, t.j. zákazník musí dostat účet včetně EET balastu okamžitě.
Zákazník musí dostat účet okamžitě, ale není nutné, aby to EET kolečko bylo automatizované. Bylo nám opakovaně vysvětlováno, že je možné si účtenku připravit předem.

Jak provedeš natukaní v okamžiku platby online kartou? Já to chápu tak, že v okamžiku online platby kartou musí mít nakupující možnost ověřit účtenku - tj. musíš to udělat obratem. Ach jo.
Uděláš si účtenku s EET, potom necháš zákazníka zaplatit, a když to z nějakého důvodu neprojde, tak zase účtenku s EET stornuješ. Je to trochu na hlavu, ale tak co chceš, když se má řídit stát jako firma...
Název: Re:Delphi + EET
Přispěvatel: pepak 26-09-2016, 17:44:04
Jinak kdyby to někoho zajímalo, tak důvod, proč platby kartou spadají do EET, je podle lidí z ministerstva ten, že jinak by srovnatelné provozovny, lišící se tím, jestli berou karty, vykazovaly dramaticky odlišné částky, což by FÚ ztěžovalo analýzu, ke komu naběhnout na kontrolu. Úvahami o tom, jestli třeba náhodou EET nad kartami není problém pro podnikatele, se FÚ nezatěžoval, zjevně vychází z názoru, že podnikatelé jsou tu pro FÚ, nikoliv naopak.
Název: Re:Delphi + EET
Přispěvatel: tanton 27-09-2016, 18:21:25
Zkouším toto řešení https://github.com/vlastikcocek/openeet a funguje. Zdrovy kód pro assembly "openeet-lite.dll" není ten s úpravami pro volání z Delphi. Je neveřejný nebo jenom blbě hledám? V C# se nějak moc neorientuji. díky
Název: Re:Delphi + EET
Přispěvatel: cadsky 27-09-2016, 23:07:22
Zakoupím řešení pro Delphi XE. Požadavky:
Případnou nabídku prosím na info@dsoft.cz
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 29-09-2016, 08:10:31
Zakoupím řešení pro Delphi XE. Požadavky:
  • Musí fungovat pod Win XP. (asi obejít THTTPRIO a pro https komunikaci využít např. ararat synapse)
  • Včetně zdrojového kódu
  • Pokud možno bez externí DLL
Případnou nabídku prosím na info@dsoft.cz

Aha, takže takhle se dnes tvoří kvalitní software, nestačím se divit, zvláště pokud se podívám na webové stránky firmy. Podle mě tento příspěvek tady nemá co dělat, tohle je komerce jak blázen. Toto vlákno si myslím, že je pro nás programátory, aby jsme sdíleli své zkušenosti s EET a ne pro komerční nabídky nebo poptávky.
Název: Re:Delphi + EET
Přispěvatel: pf1957 29-09-2016, 08:20:58
Zakoupím řešení pro Delphi XE. Požadavky:
Podle mě tento příspěvek tady nemá co dělat, tohle je komerce jak blázen.
Reseni poptava, nenabizi. Ja bych tak prikry nebyl.

Jestli si to pamatuju, tak se v tuzemske Delphi komunite vzdycky zprostredkovavaly programatorske joby i reseni, krome nabidek/podpory prodeje komercnich produktu.

Treba si tak nekdo rad privydela.
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 29-09-2016, 08:44:37
Reseni poptava, nenabizi. Ja bych tak prikry nebyl.

To pf1957:

No nevím, když to vezmu selským rozumem: sice je to poptávka, ale podívej se na stránky té firmy D-Soft nebo jak se to jmenuje. Prezentují se jako největší profesionálové a přijde Ti profesionální vytvářet software tak, že někam na fórum napíšu inzerát, že koupím hotové řešení, aniž bych dopředu znal kvalitu výstupu ? Podle těch stránek mají údajně kvalitní tým profesionálů. Sorry, ale tohle mi profesionální nepřijde. EET je navíc docela důležitá věc a plácat software tímto způsobem - nevím, asi jsem už z nějaké staré školy. Tohle bych já svěřil opravdu někomu z našeho prověřeného týmu programátorů a ne inzerovat někde na fórech.

Navíc - komerce to je. Tady inzeruje, hledá samozřejmě co nejlevněji, prodá co nejdráž. Podle mě by měl autoru tohoto webu - Radku Červinkovi - za toto zaplatit. Jak říkám, tohle prostě není profesionální a podle mě ani etické.

Toť můj názor. Ale jak říkám, jsem už opravdu asi ze staré školy. Já když dneska vidím, jak se vytváří software, jsem z toho čím dál tím více smutnější. Doby kvalitních interních týmů programátorů ve firmách jsou tytam, dneska se nakupuje od kdekoho kdeco co nejlevněji a prodává se to za přemrštěné ceny a prezentuje se to jako kvalitní softwarehouse. Naštěstí v oblasti ERP systémů stále ještě mám pocit, že obor má úroveň. Nedovedu si představit, že by toto udělaly firmy jako Abra, Assceco a další.

Ale jak říkám, je to můj názor a můj pocit. Jak říká moje o 13 let mladší manželka - už jsem senior :-)
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 29-09-2016, 08:52:43
Treba si tak nekdo rad privydela.

A ještě malá poznámka: v podstatě je to také zároveň komerční inzerát typu poptávka po programátorovi. Normálně si firma musí takovou inzerci zaplatit - a to je v pořádku. Ať už je to na různých pracovních portálech nebo tady na delphi.cz, takže to podle mě obchází a prostě ten příspěvek je inzerát zdarma, který měl být ale uveřejněn jako komerční za peníze. Takže to je prostě můj názor a už to nechám, je pravda, že teď už i já jsem mimo téma EET. Jdu teď právě programovat EET, takže určitě se pak podělím také o své zkušenosti s vývojem EET v Delphi, slibuji a to už bude určitě k tématu :-)
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 29-09-2016, 09:12:09
Zakoupím řešení pro Delphi XE. Požadavky:
Podle mě tento příspěvek tady nemá co dělat, tohle je komerce jak blázen.
Reseni poptava, nenabizi. Ja bych tak prikry nebyl.

Jestli si to pamatuju, tak se v tuzemske Delphi komunite vzdycky zprostredkovavaly programatorske joby i reseni, krome nabidek/podpory prodeje komercnich produktu.

Treba si tak nekdo rad privydela.
Když nějaká firma hledá programátora je něco jiného když někdo chce komponentu nebo naprogramovat kus kodu. Nedávno tady byla řeč o tom, jak jsou všichni spokojeni s TMS komponentami a že rádi si zaplatí. To je přece to samé. S dovolením ale za shanění lidí si nějaký mrzký peníz (proti agenture) rád vezmu.

Cílem delphi.cz a přidruženého fora je a bylo podporovat Delphi a Delphi programátory. A tohle je podle mne ten případ - někdo šikovný pomůže někomu kdo třeba na to nemá čas aby znovu vyvinul kolo, v tomto případě spíše perpetum mobile. Upřímně pokud má někdo řešení v podstatě splňující požadavky, klidně tady uveřejněte nabídku nejlélpe s orientační cenou. Tazatel nebude sám, kdo by měl určitě zájem.

Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 29-09-2016, 09:25:40
S dovolením ale za shanění lidí si nějaký mrzký peníz (proti agenture) rád vezmu.

To je právě v pořádku a naprosto si ty peníze zasloužíš. Protože pokud díky tomu inzerátu firma najde kvalitního programátora nebo kvalitní řešení, tak na tom bohatě vydělá a těch pár korun, co za inzerát dá Tobě, jsou prostě minimum - a víme všichni dobře, kolik si berou třeba personální agentury. Proto právě mi ten inzerát nepřišel korektní - prostě mi to Radku přišlo selským rozumem tak, že Tě okrádá. Ale samozřejmě je to jenom můj názor, je jen na Tobě, jak to vyhodnotíš Ty. Já to myslel tak - jak by řekl někdo od nás z obchodního - utíkají nám tady peníze :-) Ale už dost o tom, nechci tady dále kazit zatím dost kvalitní diskuzi o EET. Teď je tady u nás obrovská porada o tom, celá firma tím žije, tak pak opravdu zkusím něco sepsat, co by mohlo být pro ostatní přínosem. Jenom ten čas kdyby ho bylo o dost více. Tak zatím hezký den všem.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 29-09-2016, 10:35:42
A to EET kolečko musí být automatizované, t.j. zákazník musí dostat účet včetně EET balastu okamžitě.
Zákazník musí dostat účet okamžitě, ale není nutné, aby to EET kolečko bylo automatizované. Bylo nám opakovaně vysvětlováno, že je možné si účtenku připravit předem.
.................

Mám dnes asi útlum - jak připravit účtenku předem, když BKP je otiskem data tržby a předem datum tržby neznám?
Název: Re:Delphi + EET
Přispěvatel: pepak 29-09-2016, 15:25:41
Mám dnes asi útlum - jak připravit účtenku předem, když BKP je otiskem data tržby a předem datum tržby neznám?
Pokud například prodávám službu "přijedu k vám nainstalovat Windows" a někdo si mě objedná, tak vím, kdy k němu pojedu. Nebo to vím aspoň přibližně. Takže si podle lidí z FÚ připravím účtenku na předpokládanou částku třeba ten den ráno (nebo den předem), proženu ji EET, dostanu FIK, ten si vytisknu na účtenku a k zákazníkovi pojedu s hotovou účtenkou. Až se ukáže, že jsem tam jel zbytečně, protože vůbec nemá počítač, nebo se tam zaseknu na dvojnásobnou dobu a částka bude úplně jinde, tak večer starou účtenku zruším nebo doplním nebo tak něco (ale co dělat, když ji chci doplnit a zákazník chce hned na místě i tenhle FIK, to nevím).

Každopádně dotazy spíš na kontaktní formulář http://www.etrzby.cz (http://www.etrzby.cz), já jen předávám, jak jsem řečené pochopil já a nedělám si žádný nárok na to, že jsem to pochopil dobře.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 03-10-2016, 14:16:16
To Whom It May Concern

Dotaz: Dobrý den, mám dotaz k metodice používání certifikátů, kterými bude vygenerována XML signature SOAP požadavku evidence tržeb. V části portálu určeném pro podnikatele uvádíte, že podnikatel si bude moci vygenerovat jeden nebo více certifikátů pro účely EET. Zároveň v technické specifikaci uvádíte, že certifikát použitý k vygenerování BKP a certifikát použitý pro generování XML signature MUSÍ BÝT STEJNÝ - S JEDINOU VYJÍMKOU, a to když certifikát použitý pro vygenerování BKP již není v okamžiku odeslání zprávy platný. Ovšem to, že podnikatel bude moci používat současně více certifikátů, které mohou mít různá data expirace, a výše uvedená podmínka, že BKP-certifikát a XMLsig-certifikát musejí být stejné až na uvedenou vyjímku, vnáší do celého procesu závažnou komplikaci. Bude totiž nutné, aby se s každou tržbou, která se nezaevidovala bezprostředně po vytvoření BKP (zjednodušený režim, chyba přenosu při běžném režimu), uchovával i certifikát použitý k vytvoření tohoto BKP. Mám proto dotaz, jestli se náhodou neuvažuje o opuštění výše uvedené podmínky shodnosti BKP a XMLsig certifikátů, protože by evidentně mělo stačit, aby certifikát byl evidovaný na podnikatele a platný v okamžiku přijetí tžby (BKP certifikát), resp. odeslání zprávy (XMLsig certifikát). Děkuji a jsem s pozdravem....


Odpověď: Dobrý den,
 
potvrzujeme tyto skutečnosti uvedené ve vašem dotazu:
1.       poplatník si může vyžádat více certifikátů a používat je paralelně
2.       v jedné datové zprávě musí být privátní klíč (tedy i certifikát) použitý k vygenerování BKP a privátní klíč použitý pro generování XML signature totožný
3.       bod 2 může být porušen pouze z důvodu přesně uvedené výjimky.
 
Uvažovali jsme i o dalších možnostech kombinace dvou certifikátů v rámci jedné zprávy, ale rozhodnutí je platné tak, jak jste vyčetl z technické dokumentace (bod 2 a 3). Důvodem je minimalizace případů, kdy se bude certifikát odlišovat. Umožňuje to jednodušší a rychlejší kontrolní postupy na obou stranách, menší objem zasílaných zpráv a vyšší jistotu, že „cestou“ nedošlo k žádné manipulaci s daty. Na vaší straně to znamená, že musíte uchovávat informaci, kterým certifikátem byl vytvořen PKP pro konkrétní tržbu, zejména, pokud nebyla úspěšně zaevidována okamžitě. Vzhledem k tomu, že máte například možnost používat jeden certifikát pro danou provozovnu/pokladnu, dokonce jen jeden pro poplatníka, záleží na rozhodnutí poplatníka, jaký způsob bude provozně, bezpečnostně  i technicky vyhovující.

Při posouzení Vámi předloženého emailového dotazu vycházelo Generální finanční ředitelství výhradně z údajů uvedených ve Vašem dotazu, a to bez dalších konkrétních informací a souvislostí, které se k předmětné situaci vztahují. Upozorňujeme, že Generální finanční ředitelství neposkytuje závazný výklad a aplikaci právních předpisů. K tomuto je v individuálních případech oprávněný místně a věcně příslušný soud. Poskytnuté informace nenahrazují závazný právní výklad, závazné posouzení o určení evidované tržby či rozhodnutí v soudním řízení.

S pozdravem

Ing. Kristýna Misiarzová
Generální finanční ředitelství
Metodická podpora evidence tržeb
E-mail: eet@fs.mfcr.cz
Web: www.etrzby.cz
Název: Re:Delphi + EET
Přispěvatel: Roman K. 03-10-2016, 16:13:21
čili ještě k předchozímu: tady je vidět, co za truhlíky to EET vyvíjí. Oni si myslí, že ten požadavek na shodnost certifikátů jim ušetří provoz (jenže vůbec neušetří, stejně budou muset kontrolovat oba "podpisy" zvlášť, jenže to jim dojde asi tak měsíc po zahájení ostrého provozu), a na to konto na uživatele klidně navalej řešení persistence certifikátu použitého pro tvorbu BKP. To by se člověk po...  :-(
Název: Re:Delphi + EET
Přispěvatel: Jan Šebelík 06-10-2016, 09:20:35
Ahoj, mohl by jsi zverejnit spusteni COM object napsaný v C#  bez Jcl ?  docela by mne to zajimalo. dik
S EET jsem pokročil do stavu, kdy do C# prostě naimportuju WCF Service s jasnou typovou kontrolou, bez žádného dalšího balastu, bez dalších úprav. Zadám položky, vytvořím BKP/PKP (ještě neotestováno). Odešlu. Request korektně projde. Kód chyby 4: Neplatný podpis SOAP zprávy. Jasně.

Dnes se chci soustředit na to, abych zkontroloval správnost BKP/PKP. Taky už bych to chtěl malinko učesat, protože se mi to rozlejzá jenom v Program.cs (všechno static). Vyrobit z toho třídu, která se jednou incializuje (DIC, číslo prodejny/provozovny, certifikát, heslo) a pak opakovaně odesílá tržby. A aby to byl COM.

Nepamatuju si to teď z hlavy, jak se to dělá, ale určitě to bude snadné. Snad jenom

using System.Runtime.InteropServices;
a pak
   [ComVisible(true)]
   public interface IEETClient...
a
   [ComVisible(true)]
   [ClassInterface(ClassInterfaceType.AutoDual)]
   public class EETClient : IEETClient
Třída EETClient, která implementuje (dll) interface IEETClient by měla jít naimportovat do Delphi jako type library.

Název: Re:Delphi + EET
Přispěvatel: KarelHorky 06-10-2016, 09:47:57
Díky za inspiraci. Mě se daří tak napůl:  :D
2. mám uložený soubor odpovědi z Playgroundu v3, tento jsem prohnal úplně stejnou validací s výsledkem ssvsInvalidSignature.
Tak jsem se na ten podpis znovu podíval a udělal to pořádně v HTTPRIOAfterExecute. A ověření podpisu začalo fungovat. Můžu potvrdit, že uvedený kód je funkční a ověřuje podpis Playground V3. Takže teď se mi daří už naplno !  :)
Název: Re:Delphi + EET
Přispěvatel: Roman K. 06-10-2016, 14:07:00
Tak jsem se na ten podpis znovu podíval a udělal to pořádně v HTTPRIOAfterExecute. A ověření podpisu začalo fungovat. Můžu potvrdit, že uvedený kód je funkční a ověřuje podpis Playground V3. Takže teď se mi daří už naplno !  :)

Tak to blahopřeji. Mně ten kód (provedený v RIO AfterExecute, playground v3) stále vrací  Status rovný ssvsNoKey.
Pokud tedy oba mluvíme o kódu ze stránky 6...
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 06-10-2016, 16:10:47
Ano, kód od Zdenka, trochu jsem to upravil podle sebe:
Kód: Delphi [Vybrat]
  1. procedure DatEET2.HTTPRIOAfterExecute(const MethodName: string; SOAPResponse: TStream);
  2. var
  3.   EMSG: TElXMLSOAPMessage;
  4.   Handler: TElXMLSOAPCustomSignatureHandler;
  5.   Status : TSBXMLSOAPSignatureValidationStatus;
  6.   FXmlDocument: TElXMLDOMDocument;
  7. begin
  8.   SOAPResponse.Position := 0;
  9.   FXmlDocument := TElXMLDOMDocument.Create;
  10.   EMSG:=TElXMLSOAPMessage.Create(nil);
  11.   try
  12.     FXmlDocument.LoadFromStream(SOAPResponse, '', true);
  13.     EMSG.LoadFromXML(FXmlDocument);
  14.  
  15.     if EMSG.SignatureHandlerCount > 0 then
  16.     begin
  17.       Handler := TElXMLSOAPCustomSignatureHandler(EMSG.SignatureHandlers[0]);
  18.       Status := TElXMLSOAPBaseSignatureHandler(Handler).Validate;
  19.       if (Status <> ssvsValid) and (Status <> ssvsInvalidReferenceDigest ) then
  20.       begin
  21.         fStavPodpisuOdpovedi := spsPodpisNeoveren;
  22.         Log.Add('Neplatný podpis odpovědi EET.');
  23.       end
  24.       else
  25.       begin
  26.         fStavPodpisuOdpovedi := spsPodpisOveren;
  27.         fOdpovPodpisVydal := TElXMLSOAPBaseSignatureHandler(Handler).SignerCertificate.IssuerName;
  28.         fOdpovPodpisOsoba := TElXMLSOAPBaseSignatureHandler(Handler).SignerCertificate.SubjectName;
  29.         Log.Add(Format('Subject Organization "%s"',[fOdpovPodpisOsoba.Organization]));
  30.         Log.Add(Format('Issuer  Organization "%s"',[fOdpovPodpisVydal.Organization]));
  31.         Log.Add('PLATNY podpis odpovědi EET.');
  32.       end;
  33.     end
  34.     else
  35.     begin
  36.       fStavPodpisuOdpovedi := spsPodpisNeni;
  37.       Log.Add('Odpověď EET není podepsána.');
  38.     end;
  39.  
  40.   finally
  41.     FreeAndNil(EMSG);
  42.     FreeAndNil(FXMLDocument);
  43.   //  Handler.Free;               { neuvolnovat, uvolni se samo ! }
  44.   end;
  45.  

Tento kód mi funguje v XE6.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 07-10-2016, 13:01:27
Ano, mám ten samý kód a status je ssvsNoKey. Evidentně mi někde vkódu chybí nastavení
certifikátu pro ověření (ten certifikát jde vyzobnout z uzlu BinarySecurityToken, ale asi
to Eldos komponenty neudělají automaticky). Možná že mám starou verzi ELDOS komponent
(prosinec 2015)? Budu bádat dál.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 07-10-2016, 15:00:31
Evidentně mi někde vkódu chybí nastavení certifikátu pro ověření (ten certifikát jde vyzobnout z uzlu BinarySecurityToken, ale asi to Eldos komponenty neudělají automaticky). Možná že mám starou verzi ELDOS komponent (prosinec 2015)?
Já mám teda verzi novější:
SecureBlackbox - version 14.0.292 - Released May 1, 2016
A bude to asi něco takového, protože když to krokuju dovnitř SBB komponent, tak certifikát již mají načtený, aniž bych ho já nějak explicitně vyvolal. Ale asi víc neporadím.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 07-10-2016, 15:43:56
Tak bohužel verzí ELDOSu to nebude. Downloadnul jsem SecureBlackBox vytvořený 29.7.2016 a furt to samé.
Píšete, že certifikát je ve vašm kódu už nějak nastaven - docela by bodlo vědět kdy se nastavuje :-) jestli
se nepřehlédl nějaký podstatný krok. Ale uznávám, že to by dalo trochu víc práce zjistit.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 07-10-2016, 15:52:17
Ještě mne napadlo jestli teda ověřujeme to samé ... přikládám SOAP odpověď EET Playgroundu kterou se snažím ověřit já.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 10-10-2016, 08:50:20
Ověřit odpověď uloženou do souboru se mi nepodařilo, nicméně pro podívání přikládám moji odpověď, kterou ověřuji jako první krok v HTTPRIOAfterExecute. Podle mně jde o xml se stejnou strukturou, jako jsi přiložil ty.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 10-10-2016, 13:26:22
Ano, struktura těch XML je ta samá. Takže zbývá jen zjistit, kde bere validator z kódu na straně 6 informaci o použitém certifikátu :-)
V tom kódu je validátor dynamicky vytvořený a pokud si automaticky nevyřeší řeferenci SecurityTokenReference a nevyzobne veřejnou
část certifikátu z paketu sám - což se u mne neděje - tak certifikát nemůže nijak zjistit. Ledaže by se někde nastavovaly nějaké properties
o kterých v kódu není řeč.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 10-10-2016, 16:41:48
Trochu jsem prohlédl zdrojáky SBB a mám tam toto:
Kód: Delphi [Vybrat]
  1. procedure TElXMLSOAPMessage.LoadFromXML(Element: TElXMLDOMElement);
  2. var
  3.   Ver : TSBXMLSOAPVersion;
  4. begin
  5.  
  6.   ... něco jsem odmazal ...
  7.  
  8.   FEnvelope := TElXMLSOAPEnvelope.Create(Ver, Element.NamespaceURI);
  9.   FEnvelope.LoadFromXML(Element);
  10.   ExtractSecurityHeaders;
  11.   ExtractSignatures;
  12. end;
  13.  
Ty to tam nemáš? Když jsem to krokoval v debugeru, rozhodně se tam načítaly hlavičky i podpisy.
Ještě doplním, že žádné další properties ani nic jiného jsem nikde nenastavil, všechno je v default nastavení od SBB.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 10-10-2016, 16:58:40
Díky za info. Není někde JINDE v kódu volání helper funkcí, kde se nastavují globální
proměnné v SBXMLWSSCore? Např SBXMLSOAPCore.SOAPSecSetElementId(...,
nastavení Namespace apod?
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 11-10-2016, 11:36:29
Během vytvoření, odeslání, příjmu a zpracování zprávy to nešlo v unitě SBXMLSOAPCore ani do jedné:
Kód: Delphi [Vybrat]
  1. function GetSOAPNamespaceURI(Version: TSBXMLSOAPVersion): XMLString;
  2. function SOAPSecGetElementId(Element : TElXMLDOMElement) : XMLString;
  3. procedure SOAPSecSetElementId(Element : TElXMLDOMElement; const Value : XMLString);
  4.  
Jak jsem psal, všechno mám v default nastavení SBB.
Název: Re:Delphi + EET
Přispěvatel: Benjamin Makovský 12-10-2016, 13:19:51
Ahojte zde mate reseni v Turbo Delphi s jednim DLL vcetne zdroje v c#

https://github.com/vlastikcocek/openeet/tree/master/dotnet (https://github.com/vlastikcocek/openeet/tree/master/dotnet)

Moc děkuji za ukázku  řešení  v Turbo Delphi, potřebuji  implementaci  v Delphi 7. Snažím se rozjet, překlad O.K. v běhu  chyba "Sada klíčů  není definována". Potřebuji poradit, kde a jaké klíče mají být umístěny.
Děkuji...
Název: Re:Delphi + EET
Přispěvatel: Roman K. 12-10-2016, 13:22:53
Já  mám jen licenci bez zdrojáků, takže krokování je poněkud ztížené :-). Navíc moje licence neobsahuje
BBox pro secure HTTP, takže je možné, že některé části kódu jsou díky absenci licence automaticky
přeskakovány. Žádné jiné vysvětlení mne nenapadá. Nicméně vyřešil jsem celou věc jinak -
normálně "ručně" pracuju s TElXMLVerifier, a všechno běhá. Díky za spolupráci.
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 12-10-2016, 23:01:37
Ahojte zde mate reseni v Turbo Delphi s jednim DLL vcetne zdroje v c#

https://github.com/vlastikcocek/openeet/tree/master/dotnet (https://github.com/vlastikcocek/openeet/tree/master/dotnet)

Moc děkuji za ukázku  řešení  v Turbo Delphi, potřebuji  implementaci  v Delphi 7. Snažím se rozjet, překlad O.K. v běhu  chyba "Sada klíčů  není definována". Potřebuji poradit, kde a jaké klíče mají být umístěny.
Děkuji...

je to chyba winXP tam neni sada klicu v registru.. nema to kodovani 256bit ale jen 128bit.
Priklad jede na win7 a vyse.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 13-10-2016, 14:30:22
Pokud to někomu uniklo, jako např. mně, tak na www.etrzby.cz (http://www.etrzby.cz) je zveřejněna nová verze EET rozhraní 3.1. Mělo by být kompatibilní s verzí 3.0, aspoň to píšou. Dejte sem vědět, pokud narazíte na nějaké novinky nebo zádrhele.
Název: Re:Delphi + EET
Přispěvatel: astaldo 13-10-2016, 16:35:46
Zdravim vespolek,
 pracuji sice v Jave, ale mam obecny dotaz ohledne pouziti certifikatu.
 Dnes jsem dostal ostre certifikaty od Financni spravy a pri pouziti na PLAYGROUNDu mi to vraci "Neplatny podpis SOAP zpravy"
Ten samy kod s testovacimi certifikaty funguje a dostavam fiktivni FIK. Predpokladam ze nelze pouzivat produkcni certifikaty v testovacim prostredi playground? Je to tak, nebo mam jeste nekde chybu? :)
Název: Re:Delphi + EET
Přispěvatel: ShaneZB 14-10-2016, 09:09:18
Zdravím všechny,
přemýšlím o tom, jak budu testovat funkčnost, až v listopadu zapnou ostré-testovací EET. Bude možné použít testovací privátní certifikát nebo bude třeba se zaregistrovat a získat vlastní? Když zcela ostrý provoz bude až v prosinci: bude možné v listopadu posílat i jiné zprávy než ověřovací?
Zjišťoval to někdo? Nebo je to někde napsané a já jsem slepý? Je někde zveřejněna cesta na ostré SOAP? Nepodařilo se mi to najít.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 14-10-2016, 11:05:23
Pokud to někomu uniklo, jako např. mně, tak na www.etrzby.cz (http://www.etrzby.cz) je zveřejněna nová verze EET rozhraní 3.1. Mělo by být kompatibilní s verzí 3.0, aspoň to píšou. Dejte sem vědět, pokud narazíte na nějaké novinky nebo zádrhele.

Koukal jsem na to a žádná moc změna až na to, že idpokladny je max 20 znaků
a číslo účtenky je teď max 25 znaků. Jinak vše při starém, namespace se nemění.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 14-10-2016, 11:09:52
Zdravim vespolek,
 pracuji sice v Jave, ale mam obecny dotaz ohledne pouziti certifikatu.
 Dnes jsem dostal ostre certifikaty od Financni spravy a pri pouziti na PLAYGROUNDu mi to vraci "Neplatny podpis SOAP zpravy"
Ten samy kod s testovacimi certifikaty funguje a dostavam fiktivni FIK. Predpokladam ze nelze pouzivat produkcni certifikaty v testovacim prostredi playground? Je to tak, nebo mam jeste nekde chybu? :)

To bude tím že "ostré" certifikáty nejde na PG (3) použít - tohle je jedna ze změn za poslední dobu (na PG 2 kdysi šel
použít jakýkoli platný certifikát, ale nevím jak je to teď)
Název: Re:Delphi + EET
Přispěvatel: ShaneZB 14-10-2016, 12:38:22
přemýšlím o tom, jak budu testovat funkčnost, až v listopadu zapnou ostré-testovací EET. Bude možné použít testovací privátní certifikát nebo bude třeba se zaregistrovat a získat vlastní? Když zcela ostrý provoz bude až v prosinci: bude možné v listopadu posílat i jiné zprávy než ověřovací?
Zjišťoval to někdo? Nebo je to někde napsané a já jsem slepý? Je někde zveřejněna cesta na ostré SOAP? Nepodařilo se mi to najít.

Tak jsem se zeptal a toto jsem se dozvěděl:
od 1.11.2016 je spuštěno produkční prostředí, které do 1.12.2016 poběží v pilotním provozu. Toto prostředí bude mít všechny funkcionality pro prostředí evidence tržeb. V produkčním prostředí bude možné použít pouze ostré certifikáty produkčních zařízení.

Funkčnost EET systému v produkčním prostředí bude možné ověřit tak, že zašlete ověřovací zprávu.
Obecně lze říci, že každý poplatník může produkční prostředí využít/používat jako zkušební a to až do data, od kterého je povinen dle zákona o EET evidovat tržby. Pokud tedy nemám povinnost evidovat tržby a přesto do systému odešlu datové zprávy s evidovanou tržbou, nemůžu být sankcionován za to, že dojde k např. chybné evidenci, nebudou evidovány veškeré tržby, apod.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 15-10-2016, 18:24:56
Tak jsem se zeptal a toto jsem se dozvěděl:
od 1.11.2016 je spuštěno produkční prostředí, které do 1.12.2016 poběží v pilotním provozu. Toto prostředí bude mít všechny funkcionality pro prostředí evidence tržeb. V produkčním prostředí bude možné použít pouze ostré certifikáty produkčních zařízení.

Funkčnost EET systému v produkčním prostředí bude možné ověřit tak, že zašlete ověřovací zprávu.
Obecně lze říci, že každý poplatník může produkční prostředí využít/používat jako zkušební a to až do data, od kterého je povinen dle zákona o EET evidovat tržby. Pokud tedy nemám povinnost evidovat tržby a přesto do systému odešlu datové zprávy s evidovanou tržbou, nemůžu být sankcionován za to, že dojde k např. chybné evidenci, nebudou evidovány veškeré tržby, apod.

tak to je docela drsné :-) ... tedy myslím pro GFŘ. Jestli tomu dobře rozumím, když nejsem podle OKEC zatím do určitého data povinen tržby evidovat, nic mi stejně nebrání nafasovat ostrý certifikát, a pak do systému evidovat fiktivní tržby bez příznaku "overeni" a GFŘ si to samo musí odfiltrovat.. Je to skutečně tak ?
Název: Re: Delphi + EET, funkční řešení
Přispěvatel: Marek Weyda 18-10-2016, 15:38:46
Uff ... tak se hlásím k těm, co úspěšně dostali FIK z PlayGroundu. Takže potvrzuji, že v Delphi 2007 je možné udělat funkční řešení EET, veškeré knihovny použité jsou volné pro komerční účely. Nemuseli jsme nic dokupovat. Jediné, s čím jsem se hodně potýkal, že bohužel toto jsem zatím nemohl naprogramovat ve vyšší verzi Delphi, musel jsem pro naši firmu použít Delphi 2007, takže práce se SOAP je tam dost problematická, což je ve vyšších verzích už o něčem jiném a navíc používat TimeZone prostě nejde, protože je v unitě DateUtils prostě nemáte :-)  Ale jde to, musí se hodně improvizovat a hodně věcí si doprogramovat sám. Nyní zkusím sepsat článek a pošlu to Radkovi, pokud uzná za vhodné, může to zveřejnit. Bude mi to ale chvíli trvat, protože hned po EET se na mě tady chrlí další úkoly. Takže pevně věřím, že nám před spuštěním ostré verze totálně zase nepředělají komunikaci, že třeba nevymyslí verzi 4, která nebude kompatibilní se současnou 3.1 :-) Snad má Babiš rozum.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 18-10-2016, 20:26:59
Na článek se těším! :-)
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 18-10-2016, 20:54:17
Marku, tak to napiš aspoň stručně, jak tě znám tak by ses krásně rozepsal, ale to zabere čas.

Rád to samozřejmě uveřejním, nepochybuji že to někomu pomůže, resp. třeba někdo poskytne zpětnou vazbu.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 21-10-2016, 16:29:31
Pánové, už se někomu podařilo zjistit adresu ostrého serveru? Za 10 dní má být spuštěný testovací provoz, my máme stovky instalací a adresa stále nikde.
Název: Re:Delphi + EET
Přispěvatel: ShaneZB 21-10-2016, 16:43:29
Pánové, už se někomu podařilo zjistit adresu ostrého serveru? Za 10 dní má být spuštěný testovací provoz, my máme stovky instalací a adresa stále nikde.
Optimisto, možná jsem špatně četl, ale nikde není napsáno, že to rozjedou přesně 1.11. - jen, že zhruba měsíc předem ... takže, nechme se překvapit. Předpokládám, že to zveřejněj okamžikem startu ostré služby - ne dříve.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 21-10-2016, 22:57:27
Našel jsem! Je to dost nepochopitelně uvedené v Informacích o Playground!
http://www.etrzby.cz/cs/oznameni-k-testovacimu-prostredi-playground
Název: Re:Delphi + EET
Přispěvatel: agentKobliha 22-10-2016, 11:04:20
Nechal jsem se inspirovat Vašim řešením, zacož skládám velký dík, vše fungovalo, ovšem na MF vydali nové vzorové certifikáty poplatníků pro Playground
http://www.etrzby.cz/assets/cs/prilohy/EET_CA1_Playground_v1.zip
s kterými to hlásí chybu "Chyba 4 - neplatny podpis SOAP zpravy".
Nevíte jak s novými certifikáty naložit?


Tak ukázka delphi + libxmlsec1 implementace zde. https://github.com/mirus77/DelphiEET
Ověření XML odpovědi dovede ověřit správnost el. podpisu zprávy. Ověřit platný certifikát odpovědi se mi nedařilo. Nevím jak je to potřeba hodně řešit, když to jede po HTTPS?

Testováno s playground EET.
Název: Re:Delphi + EET
Přispěvatel: mirus 22-10-2016, 22:54:41
DelphiEET opraveno pro použití s novými certifikáty "EET_CA1_Playground".
Netušil jsem, že soubor .p12 může obsahovat více certifikátů. Konkrétně i certifikát vydavatele certifikátu pro tento certifikát.
Už si to hlídám dle subjektu CN privátní klíč a certifikát co se vkládá do <wsse:BinarySecurityToken> node v hlavičce soap zprávy.

V demu stačí upravit akorát řádek :
Kód: Delphi [Vybrat]
  1.    EET.PFXStream.LoadFromFile(ExpandFileName('..\cert\EET_CA1_Playground-CZ00000019.p12'));
a DIČ pro odesílanou tržbu dle předmětu v certifikátu.
Název: EET v Delphi 7
Přispěvatel: Peťo 25-10-2016, 14:57:22
Zdravím,
Problematika EET ma prinútila sa registrovať, pretože vidím, že to nebude jednorazová záležitosť, aby sa to naprogramovalo a naveky fungovalo.  :)
Používam Delphi 7 a pôvodne som začal importami z WSDL, ich ručnými modifikáciami, aby zodpovedali skutočnosti, až po HTTPRIO, ktoré som sa snažil podpísať certifikátmi načítanými zo systémového úložiska cez CAPICOM a InternetSetOption. Tam som nakoniec zastal s Chybou 4 - chyba podpisu SOAP a zistil som, že tadiaľ cesta asi nevedie. Ak sa to takto niekomu podarilo, tak napíšte.

Výborné riešenie od mirusa github.com/mirus77/DelphiEET (http://github.com/mirus77/DelphiEET) nešlo na prvýkrát skompilovať v Delphi 7, ale po značných úpravách áno a je plne funkčné. Nevysporiadal som sa zatiaľ s TimeZone, ktoré D7 neobsahuje, ale to by bola maličkosť. Problém mi robí veľké množstvo DLL, od ktorých je riešenie závislé, hlavne kombinácia ssleay32.dll+libeay32.dll, ktorá je v konflikte s týmito knižnicami, ktoré už používam kvôli Indy9. Vzájomne sú nekompatibilné a nepoznám riešenie, ako ich oddeliť do osobitných adresárov pre jeden exe program.

Má niekto nápad, ako to vyriešiť, prípadne načrtnúť spôsob, ako objekt TEETTrzba oddeliť do samostatnej dll, túto umiestniť do osobitného adresára aj s príslušnými knižnicami a tak ju zavolať z hlavného programu?
Prípadne nejaké iné riešenie pre Delphi 7?
Název: Re:EET v Delphi 7
Přispěvatel: Marek Weyda 25-10-2016, 15:07:48
Výborné riešenie od mirusa github.com/mirus77/DelphiEET (http://github.com/mirus77/DelphiEET) nešlo na prvýkrát skompilovať v Delphi 7, ale po značných úpravách áno a je plne funkčné. Nevysporiadal som sa zatiaľ s TimeZone, ktoré D7 neobsahuje, ale to by bola maličkosť. Problém mi robí veľké množstvo DLL, od ktorých je riešenie závislé, hlavne kombinácia ssleay32.dll+libeay32.dll, ktorá je v konflikte s týmito knižnicami, ktoré už používam kvôli Indy9. Vzájomne sú nekompatibilné a nepoznám riešenie, ako ich oddeliť do osobitných adresárov pre jeden exe program.

Tak pokud nechceš zbytečně platit, tak se podle mě DLL knihovnám nevyhneš. Já v tom problém nevidím. XML Security Library je prostě super, holt ale DLL potřebuješ. Stejně tak TimeZone, osobně jsem to vyřešil tak, že mám na to vlastní DLL, vytvořenou ve verzi Delphi, která už s tím umí pracovat. Řešení od mirus77 je super, obdobně jsem to řešil i já. Akorát jsem se musel potýkat s tím, že jsem musel použít Delphi 2007, kde práce se SOAP není úplně dobře vyřešená, třeba použití InvString místo TStream (který je běžný ve vyšších verzích Delphi) u SOAP requestu mě fakt namíchla, ale nakonec jsem to také vyřešil, že jsem si předělal SOAP unity. Teď mě tady ve firmě tlačí, abych ideálně všechno naprogramoval hned zítra, tak stále nemám čas, ale slíbil jsem Radkovi, že napíšu alespoň krátký článek na téma implementace EET v Delphi 2007. Tam bych se rozepsal více. Ale jde to a je to funkční a podle mě velice dobré řešení. Takže v Delphi 7 to určitě také rozchodíš, tím jsem si jistý. Samozřejmě je ale daleko lepší mít už vyšší verzi Delphi - já ale prostě tu Delphi 2007 zatím použít musel, měl jsem nůž na krku :-)
Název: Re:EET v Delphi 7
Přispěvatel: Marek Weyda 25-10-2016, 15:14:55
hlavne kombinácia ssleay32.dll+libeay32.dll, ktorá je v konflikte s týmito knižnicami, ktoré už používam kvôli Indy9

Jo a pozor - Indy komponentám jsem se v tomto případě úplně vyhnul, jde to. Používám pouze WinINet. Takže kdo má Windows XP, má smůlu. Ale to mi stejně už nepodporujeme. A navíc přímo na stránkách EET je napsáno toto:

Systém EET vyžaduje pro komunikaci z bezpečnostních důvodů alespoň TLS 1.1, který není v operačním systému Windows Vista a starších operačních systémech přímo podporován.

Takže na XP ty Indy jsou nutnost, ale není to už podporovaný operační systém, takže já to naštěstí řešit nemusel. Náš ERP vyžaduje Windows 7 a výše. Tak kdyby jsi musel řešit XP, tak to opravdu budeš muset ty Indy použít asi.
Název: Re:Delphi + EET
Přispěvatel: < z > 25-10-2016, 15:28:25
@Peťo:

Jaký důvod máš, abys používal Indy 9? Ty jsou dost hodně starý, zabugovaný a přechod na Indy 10 není zas tak složitý. Podporují vůbec TLS 1.1 a ne jen 1.0?
Pokud bys ale potřeboval, je možné použít 2 různé OpenSSL knihovny. Asi v těch starších to neni přímo implementované, ale Indy 10 mají GIdOpenSSLPath / IdOpenSSLSetLibPath,
kde můžeš nastavit cestu ke knihovnám, tak to případně můžeš okopířovat a dodělat ;)
Název: Re:Delphi + EET
Přispěvatel: Peťo 25-10-2016, 16:18:30
Akorát jsem se musel potýkat s tím, že jsem musel použít Delphi 2007, kde práce se SOAP není úplně dobře vyřešená, třeba použití InvString místo TStream (který je běžný ve vyšších verzích Delphi) u SOAP requestu mě fakt namíchla, ale nakonec jsem to také vyřešil, že jsem si předělal SOAP unity.
SOAP unity som neprerábal, ten SOAPRequest v stringu a jeho podpísanie som riešil vytvorením dočasného MemStreamu. Ak to niekomu pomôže, pre Delphi 7 takto:
Kód: Delphi [Vybrat]
  1. procedure TEETRIO.HTTPRIO_BeforeExecute(const MethodName: string; var SOAPRequest: WideString);
  2. var
  3.   MemStream: TMemoryStream;
  4.   S: string;
  5. begin
  6.   if Assigned(FEET) then
  7.   begin
  8.     MemStream := TMemoryStream.Create;
  9.     try
  10.       S := SOAPRequest;
  11.       MemStream.Write(S[1], Length(S));
  12.       MemStream.Position := 0;
  13.       FEET.SignMessage(MemStream);
  14.       MemStream.Position := 0;
  15.       SetLength(S, MemStream.Size);
  16.       MemStream.Read(S[1], MemStream.Size);
  17.       SOAPRequest := S;
  18.       if Assigned(FEET.OnBeforeSendRequest) then FEET.OnBeforeSendRequest(MethodName, SOAPRequest);
  19.     finally
  20.       MemStream.Free;
  21.     end;
  22.   end;
  23. end;
Název: Re:Delphi + EET
Přispěvatel: Peťo 25-10-2016, 16:31:56
@Peťo:
Jaký důvod máš, abys používal Indy 9? Ty jsou dost hodně starý, zabugovaný a přechod na Indy 10 není zas tak složitý. Podporují vůbec TLS 1.1 a ne jen 1.0?
Používam Indy9, pretože Indy10 v Delphi 7 neskompilujem.  :(
Používam to len na úplne jednoduchý účel prístupu na HTTPS k českém obchodnímu rejstříku. A nechce sa mi prerábať overené funkčné veci, ale možno sa tomu nevyhnem. Systém WinXP nemusím nutne podporovať v EET, ale nebolo by to zlé. Tunel vo WinXP cez tstunnel.exe+eet.conf, ako tu bolo skôr napísané, v kombinácii s DelphiEET nefunguje - zamrzne to.
Název: Re:Delphi + EET
Přispěvatel: zdenek 25-10-2016, 18:57:47
Ohledně TLS a wininet doporučuji toto:

https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/ (https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/)

Máme hodně velkých firem na w2003 a citrixu. na w2008 apod.

Já to řešil předěláním THTTPRIO na EldoS HTTP BlackBox a bylo. Indy to taky zvládnou přes OpenSSL, ale to není u velkých firem úplně v oblibě.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 26-10-2016, 08:25:34
SOAP unity som neprerábal, ten SOAPRequest v stringu a jeho podpísanie som riešil vytvorením dočasného MemStreamu. Ak to niekomu pomôže, pre Delphi 7 takto:
Kód: Delphi [Vybrat]
  1. procedure TEETRIO.HTTPRIO_BeforeExecute(const MethodName: string; var SOAPRequest: WideString);
  2. var
  3.   MemStream: TMemoryStream;
  4.   S: string;
  5. begin
  6.   if Assigned(FEET) then
  7.   begin
  8.     MemStream := TMemoryStream.Create;
  9.     try
  10.       S := SOAPRequest;
  11.  

Nic proti, ale podle mě to není dobré řešení. Proměnná S je typu string, proměnná SOAPRequest typu InvString (což je typ WideString, v Delphi 7 je to asi přímo WideString, já to mám v Delphi 2007 jako InvString). Provedeš přiřazení S := SOAPRequest, takže do proměnné typu string (což je v Delphi 7 AnsiString) dáváš takto přímo proměnnou SOAPRequest typu WideString. Dle mého názoru dojde ke ztrátě informace. Podle mě Tvůj XML request nebude správně kódovaný v UTF-8. Když to takto zkouším, jak jsi to udělal, tak to sice opravdu projde na PlayGround EET, ale XML request není správně kódovaný v UTF-8. Což může být docela problém. Proto jsem to právě takto nepoužil.

K přímému přiřazení WideString do AnsiString se píše doslova toto:

When assigning to a 'narrow' string, such as an AnsiString, the double to single byte conversion can have unpredictable results. Use with care.

A já právě nemám rád řešení, co sice nějak fungují, ale nejsou prostě košer. Ten XML request opravdu na PlayGround EET projde, ale prostě není to správně kódované UTF-8. Takže proto jsem hrábnul do SOAP unit v Delphi 2007, které se mi vůbec nelíbily a předělal jsem to tak, jak je to ve vyšších verzích Delphi, kde se pracuje už přímo s TStream.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 26-10-2016, 08:35:33
Krásně je to vidět, když mám jeden XML (SOAP request na EET), který byl vytvořen pomocí TStream a druhý XML, který byl vytvořen přiřazením InvString(WideString) do string (AnsiString). Sice na EET PlayGround projdou oba SOAP requesty a opravdu EET vrátí platnou SOAP response, ale když si otevřeš ty XML requesty, tak vidíš, že jeden je opravdu správně kódovaný v UTF-8, ale ten druhý není. Takže to klidně v budoucnu může přestat fungovat nebo to funguje jenom teď v PlayGroundu, ale na ostré verzi už to fungovat nemusí. Opravdu doporučuji toto řešení nepoužít, je snadné si SOAP unity upravit.
Název: Re:Delphi + EET
Přispěvatel: Peťo 26-10-2016, 10:08:19
Nic proti, ale podle mě to není dobré řešení. Proměnná S je typu string, proměnná SOAPRequest typu InvString (což je typ WideString, v Delphi 7 je to asi přímo WideString, já to mám v Delphi 2007 jako InvString). Provedeš přiřazení S := SOAPRequest, takže do proměnné typu string (což je v Delphi 7 AnsiString) dáváš takto přímo proměnnou SOAPRequest typu WideString. Dle mého názoru dojde ke ztrátě informace. Podle mě Tvůj XML request nebude správně kódovaný v UTF-8.
Chápem, že tými priradeniami do obyčajného stringu sa môže stratiť informácia. Ale EET má v dokumentácii napísané, že žiadnu diakritiku nepoužíva, ani v requeste, ani v response, aj chybové hlášky sú bez nej. Ako môže byť nesprávne kódované UTF8 xml, a aká informácia sa môže stratiť, keď tam nie je žiadny znak väčší ako #$7F?

Samozrejme by som bol rád, keby ten kód konvertoval WideString do MemStreamu nejako elegantnejšie. Doplnil som teda encode a decode, v prípade EET to ale nijak nemení výsledok:
Kód: Delphi [Vybrat]
  1.       ...
  2.       S := UTF8Encode(SOAPRequest);
  3.       ...
  4.       SOAPRequest := UTF8Decode(S);
  5.       ...
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 26-10-2016, 11:12:21
Samozrejme by som bol rád, keby ten kód konvertoval WideString do MemStreamu nejako elegantnejšie. Doplnil som teda encode a decode, v prípade EET to ale nijak nemení výsledok:
Kód: Delphi [Vybrat]
  1.       ...
  2.       S := UTF8Encode(SOAPRequest);
  3.       ...
  4.       SOAPRequest := UTF8Decode(S);
  5.       ...

Ale to je přeci správně, že Ti to výsledek nezmění. Vždyť se podívej, co se děje v té unitě RIO, kterou využíváš. Konkrétně v proceduře TRIO.DoBeforeExecute. Ten SOAPRequest, co máš potom v té Tvojí proceduře HTTPRIO_BeforeExecute, totiž vznikne takto:

ReqWideStr := UTF8Decode(StrStrm.DataString);

StrStrm je TStringStream, DataString je obyčejný string (AnsiString). Toto je ještě v pořádku, protože ReqWideStr je WideString a přiřazení do něj je v pořádku, AnsiString do WideString přiřadit můžeš beze ztráty informace, obráceně to neplatí. Jenže potom, co si to zpracuješ v té Tvojí proceduře HTTPRIO_BeforeExecute, tak se s tím upraveným ReqWideStr (což je Tvůj SOAPRequest v proceduře HTTPRIO_BeforeExecute) stane toto:

StrStrm := TStringStream.Create(string(ReqWideStr));

Ono to totiž vytvoří nový stream, do kterého to prostě hodí ten ReqWideStr, ale předtím ho přetypovává na string (AnsiString). A to je podle mě ten kámen úrazu, protože opět se WideString přiřazuje do string (AnsiString) a může dojít ke ztrátě informace ! To je přeci šílenost !!! Proto určitě v nových verzích to RIO upravili, v proceduře TRIO.DoBeforeExecute se děje pouze toto:

Kód: Delphi [Vybrat]
  1. if Assigned(FOnBeforeExecute) then
  2. begin
  3.   FOnBeforeExecute(MethodName, Request);
  4.   Request.Position := 0;
  5. end;
  6.  

A Request je TStream, takže už nemusíš řešit nějaké šílené konverze AnsiStringu na WideString a obráceně, pracuješ jenom s TStreamem a k žádné ztrátě informací nedojde ! Prostuduj tu unitu RIO a uvidíš, co se tam děje, je to dobře čitelné a hned to pochopíš.

A znovu trvám na tom, že ty XML requesty nejsou správně kódovány, i když tam nemáš diakritiku. Jak už jsem psal, mám dva XML requesty - odchycené před odesláním. Jeden vytvořený pomocí TStream je normálně kódován UTF-8, když si ho kdekoliv otevřeš, druhý nemá kódování. Klidně si to vyzkoušej, není to nic časově náročného.

Opravdu doporučuji toto raději nyní dobře vyřešit. S tím kódováním jsou pak děsný problémy.
Název: Re:Delphi + EET
Přispěvatel: pf1957 26-10-2016, 11:40:22
A znovu trvám na tom, že ty XML requesty nejsou správně kódovány, i když tam nemáš diakritiku. Jak už jsem psal, mám dva XML requesty - odchycené před odesláním. Jeden vytvořený pomocí TStream je normálně kódován UTF-8, když si ho kdekoliv otevřeš, druhý nemá kódování.
Ne ze by se mi libilo cpani tlusteho do tenkeho, ale co znamena: "nema kodovani"?

1. XML ma ze standardu (https://www.w3.org/TR/REC-xml/#charencoding (https://www.w3.org/TR/REC-xml/#charencoding)) kodovani UTF-8 i kdyz neni explicitne uvedeno: "... use an encoding other than UTF-8. Note that since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly need an encoding declaration."
2. Pokud neposle do XML znak s kodem vetsim nez 0x7F tj. ASCII-7, tak UTF-8 == ASCII7

Nebo ty mas vecne odlisny obsah souboru, kdyz ty dva soubory porovnas?
Název: Re:Delphi + EET
Přispěvatel: Roman K. 26-10-2016, 11:46:54
.........
Používam Indy9, pretože Indy10 v Delphi 7 neskompilujem.  :(
..........

Indy 10 v D7 používám a zkompilovat to určitě jde :-)
Je tam jedna nebo dvě drobnosti které se musejí upravit ve starých
kódech šitých na Indy9, ale to je všechno.
Název: TimeZone v EET pre Delphi 7
Přispěvatel: Peťo 26-10-2016, 11:49:32
... Stejně tak TimeZone, osobně jsem to vyřešil tak, že mám na to vlastní DLL, vytvořenou ve verzi Delphi, která už s tím umí pracovat.
Doriešil som TimeZone v Delphi 7, stačí použiť systémové volanie, ktoré je ešte jednoduchšie ako použitie TTimeZone, pretože vracia priamo potrebnú hodnotu Bias. V mirusovom zdrojáku DelphiEET je malá chyba, nesmie tam byť test na Bias <> 0, pretože vo formáte XML dátumu EET vždy očakáva bias, aj keby mal byť nulový. Takže kód vnútri TEETTrzba.SignTrzba:
Kód: Delphi [Vybrat]
  1.   function GetCurrentTimeZoneBias: Integer;
  2.   var
  3.     TZInfo: TTimeZoneInformation;
  4.   begin
  5.     case GetTimeZoneInformation(TZInfo) of
  6.       TIME_ZONE_ID_STANDARD: Result := TZInfo.Bias + TZInfo.StandardBias;
  7.       TIME_ZONE_ID_DAYLIGHT: Result := TZInfo.Bias + TZInfo.DaylightBias;
  8.       TIME_ZONE_ID_UNKNOWN: Result := TZInfo.Bias;
  9.     else
  10.       Result := 0;  // TIME_ZONE_ID_INVALID
  11.     end;
  12.   end;
  13.  
  14.   function DateTimeToXMLTime(Value: TDateTime): string;
  15.   const
  16.     Neg: array[Boolean] of string=  ('+', '-');
  17.   var
  18.     Bias: Integer;
  19.   begin
  20.     Result := FormatDateTime('yyyy''-''mm''-''dd''T''hh'':''nn'':''ss''', Value); { Do not localize }
  21.     Bias := GetCurrentTimeZoneBias;
  22. //    if (Bias <> 0) then   // Bias musí by pre EET vždy uvedený
  23.     begin
  24.       Result := Format('%s%s%.2d:%.2d', [Result, Neg[Bias > 0],            { Do not localize }
  25.                                          Abs(Bias) div MinsPerHour,
  26.                                          Abs(Bias) mod MinsPerHour]);
  27.     end
  28.   end;
  29.  
Název: Re:Delphi + EET
Přispěvatel: Peťo 26-10-2016, 12:05:23
StrStrm := TStringStream.Create(string(ReqWideStr));
Tento kód, ktorý som pred chvíľou tiež našiel v zdrojáku ma tiež rozčúlil. Kód pochádza už z opravy od Borlandu a v tej oprave už použili UTF8Decode, ale na opačný proces s UTF8Encode zabudli. Myslím, že keď to bude nutné, tak to opravím a takto by to mohlo byť dokonalé:
Kód: Delphi [Vybrat]
  1. StrStrm := TStringStream.Create(UTF8Encode(ReqWideStr));

A znovu trvám na tom, že ty XML requesty nejsou správně kódovány, i když tam nemáš diakritiku. Jak už jsem psal, mám dva XML requesty - odchycené před odesláním. Jeden vytvořený pomocí TStream je normálně kódován UTF-8, když si ho kdekoliv otevřeš, druhý nemá kódování. Klidně si to vyzkoušej, není to nic časově náročného.
Stále nechápem, aký môže byť rozdiel medzi tvojimi dvoma rozdielnymi XML súbormi, keď obidva sú v čistej znakovej sade ASCII-7. Čím sa odlišujú? Iba uvedením encoding v prvom riadku?
Název: Re:TimeZone v EET pre Delphi 7
Přispěvatel: Roman K. 26-10-2016, 12:20:08
Doriešil som TimeZone v Delphi 7, stačí použiť systémové volanie, ktoré je ešte jednoduchšie ako použitie TTimeZone, pretože vracia priamo potrebnú hodnotu Bias. V mirusovom zdrojáku DelphiEET je malá chyba, nesmie tam byť test na Bias <> 0, pretože vo formáte XML dátumu EET vždy očakáva bias, aj keby mal byť nulový. Takže kód vnútri TEETTrzba.SignTrzba:
Kód: Delphi [Vybrat]
  1.   function GetCurrentTimeZoneBias: Integer;
  2.   var
  3.     TZInfo: TTimeZoneInformation;
  4.   begin
  5.     case GetTimeZoneInformation(TZInfo) of
  6.       TIME_ZONE_ID_STANDARD: Result := TZInfo.Bias + TZInfo.StandardBias;
  7.       TIME_ZONE_ID_DAYLIGHT: Result := TZInfo.Bias + TZInfo.DaylightBias;
  8.       TIME_ZONE_ID_UNKNOWN: Result := TZInfo.Bias;
  9.     else
  10.       Result := 0;  // TIME_ZONE_ID_INVALID
  11.     end;
  12.   end;
  13.  
  14.   function DateTimeToXMLTime(Value: TDateTime): string;
  15.   const
  16.     Neg: array[Boolean] of string=  ('+', '-');
  17.   var
  18.     Bias: Integer;
  19.   begin
  20.     Result := FormatDateTime('yyyy''-''mm''-''dd''T''hh'':''nn'':''ss''', Value); { Do not localize }
  21.     Bias := GetCurrentTimeZoneBias;
  22. //    if (Bias <> 0) then   // Bias musí by pre EET vždy uvedený
  23.     begin
  24.       Result := Format('%s%s%.2d:%.2d', [Result, Neg[Bias > 0],            { Do not localize }
  25.                                          Abs(Bias) div MinsPerHour,
  26.                                          Abs(Bias) mod MinsPerHour]);
  27.     end
  28.   end;
  29.  

No tohle právě v D7 nefunguje, protože, jak si všimnete, Bias je vždy Current.
A my potřebujeme Bias pro datum zadané ve Value argumentu  funkce
DateTimeToXMLTime :-)
Název: Re:TimeZone v EET pre Delphi 7
Přispěvatel: Peťo 26-10-2016, 12:36:41
No tohle právě v D7 nefunguje, protože, jak si všimnete, Bias je vždy Current.
A my potřebujeme Bias pro datum zadané ve Value argumentu  funkce DateTimeToXMLTime :-)
To je pravda, ale účtenky sa vystavujú vždy k aktuálnemu dátumu aj času, takže current bias nespôsobí chybu. Pri offline režime EET sa XML pripraví tiež k aktuálnemu dátumu, podpíše a uloží a pri dodatočnom odoslaní bude v XML správny bias. Na to, že bias môže mať normálne len dve hodnoty +02 a +01 by bolo komplikovanejšie riešenie len mrhaním času.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 26-10-2016, 12:39:45
Ne ze by se mi libilo cpani tlusteho do tenkeho, ale co znamena: "nema kodovani"?

1. XML ma ze standardu (https://www.w3.org/TR/REC-xml/#charencoding (https://www.w3.org/TR/REC-xml/#charencoding)) kodovani UTF-8 i kdyz neni explicitne uvedeno: "... use an encoding other than UTF-8. Note that since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly need an encoding declaration."
2. Pokud neposle do XML znak s kodem vetsim nez 0x7F tj. ASCII-7, tak UTF-8 == ASCII7

Nebo ty mas vecne odlisny obsah souboru, kdyz ty dva soubory porovnas?

To pf1957 a Peťo:

Promiň, blbě jsem se vyjádřil. Samozřejmě že platí to, co píše pf1957. Já jsem napsal "nemá kódování", ale to samozřejmě vždy nějaké má - třeba jenom ANSI. Jenže právě tady u těch XML to bylo tak, že když jsem si je otevřel v mém programátorském editoru a zkoumal byte po byte, tak to obsahově bylo stejné. Ale u jednoho mi ten můj editor hlásil, že je v kódování UTF-8 bez BOM, což je dobře, u druhého mi ale nehlásil žádné kódování, ani ANSI, ani UTF-8, ani cokoliv jiného. Takže nějak to načíst uměl (asi jako to umí ten EET PlayGround), ale něco tam být špatně muselo, když u jednoho správně rozeznal kódování UTF-8 bez BOM (to byl ten vytvořený pomocí TStream) a u druhého nehlásil kódování žádné (to byl ten vytvořený pomocí staré procedury z Delphi 2007, kde se v mezikroku používá InvString, což je typ WideString a pak se to zpětně přetypovává na AnsiString). A samozřejmě že oba XML mají v záhlaví encoding="UTF-8", prostě v tom editoru se to byte po byte jeví stejné včetně řídících znaků. Surově binární data těch XML jsem nezkoumal, neměl jsem čas, raději jsem ho věnoval tomu, že jsem si SOAP unity přizpůsobil na správnou práci přímo se streamy. Prostě ten editor mi u jednoho kódování hlásil, u druhého ne. S tím už jsem se v minulosti setkal a vždy to bylo díky podobným čachrům jako to přetypování string(WideString) a podobně.

Bohužel teď jsem se díval a ten starý XML jsem už smazal a neobnovím. Takže to již dále nemůžu zkoumat, ale stejně na to teď není čas. Prostě doporučuji pracovat opravdu se streamy, tohle je zhovadilost, co bylo v těch Delphi 2007 a nižších v tom RIO.

Zatím !
Název: Re:Delphi + EET
Přispěvatel: zdenek 26-10-2016, 14:29:38
No tohle právě v D7 nefunguje, protože, jak si všimnete, Bias je vždy Current.
A my potřebujeme Bias pro datum zadané ve Value argumentu  funkce DateTimeToXMLTime :-)
To je pravda, ale účtenky sa vystavujú vždy k aktuálnemu dátumu aj času, takže current bias nespôsobí chybu. Pri offline režime EET sa XML pripraví tiež k aktuálnemu dátumu, podpíše a uloží a pri dodatočnom odoslaní bude v XML správny bias. Na to, že bias môže mať normálne len dve hodnoty +02 a +01 by bolo komplikovanejšie riešenie len mrhaním času.

Nevím jestli mi něco neuteklo, ale XML je součást soap komunikace a to nikde nemusí ukládat. Vždy se vytvoří a podepíše a odešle nové. Jen údaje o tržbě zůstanou podle účtenky včetně PKP.
Název: TimeZone v EET pre Delphi 7 podruhé
Přispěvatel: Peťo 26-10-2016, 15:59:24
No tohle právě v D7 nefunguje, protože, jak si všimnete, Bias je vždy Current.
A my potřebujeme Bias pro datum zadané ve Value argumentu funkce DateTimeToXMLTime :-)

Tak na to treba radšej zapojiť googla a hneď našiel riešenie na funkciu

  function GetTimeZoneBias(const Date: TDateTime): Integer;

ktoré tu ani nemusím dávať, stačí skopírovať odtiaľ: http://qc.embarcadero.com/wc/qcmain.aspx?d=43488 (http://qc.embarcadero.com/wc/qcmain.aspx?d=43488)
Název: Re:Delphi + EET
Přispěvatel: Roman K. 01-11-2016, 10:05:27
Když jsem to ještě bastlil v D7, můj kód pro XML datumočas byl tento (vyžaduje unitu JcldateTime)

Kód: Delphi [Vybrat]
  1. function eet_DateTime(Value: tDateTime): AnsiString;
  2. const
  3.   cBiasSigns: array [false..true] of Char = ('-','+');
  4. var
  5.   Info: TTimeZoneInformation;
  6.   yy,dd,mm,hh,nn,ss,mss: Word;
  7.   DSTTime,
  8.   STDTime: tDateTime;
  9.   ValueBias: Integer; // in minutes (Value)UTC = Value + ValueBias
  10. begin
  11.   DecodeDate(Value, yy, mm, dd);
  12.   DecodeTime(Frac(Value), hh, nn, ss, mss);
  13.  
  14.   if GetTimeZoneInformation(Info) =  TIME_ZONE_ID_INVALID then
  15.     raise Exception.Create('Cannot get time zone info');
  16.  
  17.   { Zjistíme, jaký 'Bias' - letní nebo zimní - přísluší zadanému datu a času }
  18.  
  19.   { optimalizace: v lednu, únoru a prosinci NENÍ letni cas }
  20.   if (mm <= 2) or (mm >= 12) then
  21.  
  22.     ValueBias := Info.Bias + Info.StandardBias
  23.  
  24.   { optimalizace: v květnu až září JE letni cas }
  25.   else if (mm >= 5) and (mm <= 9) then
  26.  
  27.     ValueBias := Info.Bias + Info.DaylightBias
  28.  
  29.   else begin
  30.  
  31.     { Zjistíme, v jakých datech-časech se mění zimní čas na letní a naopak }
  32.  
  33.     // Info.(Daylight/Standard)Date.wDay určuje, kolikátý wDayOfWeek v měsíci wMonth se čas mění, 4 znamená POSLEDNÍ
  34.  
  35.     if Info.DaylightDate.wDay > 4 then // čas se na letní mění poslední wDayOfWeek v měsíci wMonth
  36.  
  37.       DSTTime := EncodeDate(yy, Info.DaylightDate.wMonth, LastDayOfWeek(yy, Info.DaylightDate.wMonth, Info.DaylightDate.wDayOfWeek)) +
  38.  
  39.                     EncodeTime(Info.DaylightDate.wHour, 0, 0, 0)
  40.  
  41.     else  // čas se na letní mění wDay - tý wDayOfWeek v měsíci wMonth
  42.  
  43.       DSTTime := EncodeDate(yy, Info.DaylightDate.wMonth, IndexedDayOfWeek(yy, Info.DaylightDate.wMonth, Info.DaylightDate.wDayOfWeek, Info.DaylightDate.wDay)) +
  44.  
  45.                     EncodeTime(Info.DaylightDate.wHour, 0, 0, 0);
  46.  
  47.     if Info.StandardDate.wDay > 4 then
  48.  
  49.       STDTime := EncodeDate(yy, Info.StandardDate.wMonth, LastDayOfWeek(yy, Info.StandardDate.wMonth, Info.StandardDate.wDayOfWeek)) +
  50.  
  51.                     EncodeTime(Info.StandardDate.wHour, 0, 0, 0)
  52.     else
  53.  
  54.       STDTime := EncodeDate(yy, Info.StandardDate.wMonth, IndexedDayOfWeek(yy, Info.StandardDate.wMonth, Info.StandardDate.wDayOfWeek, Info.StandardDate.wDay)) +
  55.  
  56.                     EncodeTime(Info.StandardDate.wHour, 0, 0, 0);
  57.  
  58.     if (Value > DSTTime) and  (Value <= STDTime) then // pokud toto vse splneno, Value je cas z letniho casu
  59.  
  60.       ValueBias := Info.Bias + Info.DaylightBias
  61.  
  62.     else // a pokud ne, tak Value je cas z letniho casu
  63.  
  64.       ValueBias := Info.Bias + Info.StandardBias;
  65.  
  66.  
  67.   end;
  68.  
  69.   Result := Format('%.2d-%.2d-%.2dT%.2d:%.2d:%.2d%s%.2d:%.2d',
  70.                    [yy,mm,dd,hh,nn,ss, cBiasSigns[ValueBias < 0], Abs(ValueBias) div 60, Abs(ValueBias) mod 60]);
  71.  
  72. end;
  73.  
Název: Re:Delphi + EET
Přispěvatel: Hop 01-11-2016, 11:27:24
Dobrý den,
jede Vám implementace proti https://prod.eet.cz:443/eet/services/EETServiceSOAP/v3  ?
Když pošlu request na playground https://pg.eet.cz:443/eet/services/EETServiceSOAP/v3 tak se mi vrátí response s FIKem, nicméně pokud ten samý request pošlu na
https://prod.eet.cz:443/eet/services/EETServiceSOAP/v3 tak se mi vrátí:

<?xml version="1.0"?>
<soapenv:Envelope xmlns:eet="http://fs.mfcr.cz/eet/schema/v3" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <eet:Odpoved>
         <eet:Hlavicka uuid_zpravy="ab1bc7a0-5ab0-4d61-a170-2982f2d83784" dat_odmit="2016-11-01T11:23:10+01:00"/>
         <eet:Chyba kod="4">Neplatny podpis SOAP zpravy</eet:Chyba>
      </eet:Odpoved>
   </soapenv:Body>
</soapenv:Envelope>


Tak nějak jsem asi hloupě předpokládal, že když to jede na playground tak to pojede i na ostrém...
Název: Re:Delphi + EET
Přispěvatel: Hop 01-11-2016, 11:59:42
Tak jsem teď ještě zkusil ten jejich "validní" http://www.etrzby.cz/assets/cs/prilohy/CZ00000019.valid.v3.1.xml request a chová se to naprosto stejně...
pro  https://pg.eet.cz:443/eet/services/EETServiceSOAP/v3 se mi vrátí response s FIKem, nicméně pokud ten samý request pošlu na
https://prod.eet.cz:443/eet/services/EETServiceSOAP/v3 se mi vrátí:
 
<eet:Chyba kod="4">Neplatny podpis SOAP zpravy</eet:Chyba>
Název: Re:Delphi + EET
Přispěvatel: ShaneZB 01-11-2016, 12:08:49
jestli to nebude kvůli tomuto:
Citace
od 1.11.2016 je spuštěno produkční prostředí, které do 1.12.2016 poběží v pilotním provozu. Toto prostředí bude mít všechny funkcionality pro prostředí evidence tržeb. V produkčním prostředí bude možné použít pouze ostré certifikáty produkčních zařízení.

Máš ostrý certifikát privátního klíče?
Název: Re:Delphi + EET
Přispěvatel: Hop 01-11-2016, 12:24:18
Nějaký budu mít odpoledne, tak sem pak napíšu jestli to s ním jede.
Nicméně bych čekal trochu jinou chybu, než že to mám špatně podepsané.
I když pravda ten výčet chyb není zrovna největší...  :-\
Název: Re:Delphi + EET
Přispěvatel: ShaneZB 01-11-2016, 12:41:32
No mě to zase řve "Neplatný podpis odpovědi" (používám https://github.com/mirus77/DelphiEET) - PG to bylo OK ... který certifikát je ten správný?
Název: Re:Delphi + EET
Přispěvatel: Hop 01-11-2016, 14:50:15
tipuji že jde o to samé a "Neplatný podpis odpovědi" bude interpretací chyby:
<eet:Chyba kod="4">Neplatny podpis SOAP zpravy</eet:Chyba>
Název: Re:Delphi + EET
Přispěvatel: ShaneZB 01-11-2016, 15:08:54
Nee - odpověď dorazila. FIK obsahuje. Ale funkce pro ověření podpisu má problém ...
Název: Re:Delphi + EET
Přispěvatel: Hop 02-11-2016, 09:40:33
Aha,
no já se na ověření podpisu u odpovědi vy..... Nepřijde mi to tak úplně podstatné. Běží to na TLS 1.2 což je dle mého názoru dostatečné a nepředpokládám, že by někdo mohl mít užitek z podvrhování response zpráv z EET. Nehledě na to, že jsem si do simulátoru generování podpisů ani nedal, takže by mi to vůči simulátoru nechodilo :)
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 02-11-2016, 16:17:03
Tak jsem teď ještě zkusil ten jejich "validní" http://www.etrzby.cz/assets/cs/prilohy/CZ00000019.valid.v3.1.xml request a chová se to naprosto stejně...
pro  https://pg.eet.cz:443/eet/services/EETServiceSOAP/v3 se mi vrátí response s FIKem, nicméně pokud ten samý request pošlu na
https://prod.eet.cz:443/eet/services/EETServiceSOAP/v3 se mi vrátí:
 
<eet:Chyba kod="4">Neplatny podpis SOAP zpravy</eet:Chyba>

pokud se posila zprava  na https://prod.eet.cz:443/eet/services/EETServiceSOAP/v3 musi to byt podepsane produkcnim certifikatem, nemuze to byt podepsane certifikatem z PG jinak to vrati chybu Neplatny podpis SOAP zpravy
Název: Re:Delphi + EET
Přispěvatel: Peťo 03-11-2016, 09:21:12
... 
<eet:Chyba kod="4">Neplatny podpis SOAP zpravy</eet:Chyba>

pokud se posila zprava  na https://prod.eet.cz:443/eet/services/EETServiceSOAP/v3 musi to byt podepsane produkcnim certifikatem, nemuze to byt podepsane certifikatem z PG jinak to vrati chybu Neplatny podpis SOAP zpravy

Myslím si, že nebudem jediný, kto by privítal, keby chybu 4 rozdelili na varianty:
a) Podpis úplne absentuje alebo je chybný
b) Podpis je neplatný pre konkrétne prostredie (pg v produkčnom)
c) Podpis je pred/po dátume platnosti
d) Podpis je neplatný - zrušený napr. po krádeži certifikátu

Uľahčilo by to ladenie a neskôr aj komunikáciu s hotline.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 03-11-2016, 10:59:46
..............
Myslím si, že nebudem jediný, kto by privítal, keby chybu 4 rozdelili na varianty:
a) Podpis úplne absentuje alebo je chybný
b) Podpis je neplatný pre konkrétne prostredie (pg v produkčnom)
c) Podpis je pred/po dátume platnosti
d) Podpis je neplatný - zrušený napr. po krádeži certifikátu

Uľahčilo by to ladenie a neskôr aj komunikáciu s hotline.

Ovšem fakt je, že až na "podpis je chybný", což může být způsobeno drobnou
chybou v kódu, všechno ostatní můžete snadno na straně klienta ošetřit vy :-)
Třeba nepodepisovat ostrá podání certifikátem pro PG je úplně triviální - stačí
porovnat DIČ z certifikátu s DIČ ve zprávě.
Název: Re:Delphi + EET
Přispěvatel: Peťo 03-11-2016, 14:52:24
..............
Myslím si, že nebudem jediný, kto by privítal, keby chybu 4 rozdelili na varianty:
a) Podpis úplne absentuje alebo je chybný
b) Podpis je neplatný pre konkrétne prostredie (pg v produkčnom)
c) Podpis je pred/po dátume platnosti
d) Podpis je neplatný - zrušený napr. po krádeži certifikátu
Ovšem fakt je, že až na "podpis je chybný", což může být způsobeno drobnou chybou v kódu, všechno ostatní můžete snadno na straně klienta ošetřit vy :-) Třeba nepodepisovat ostrá podání certifikátem pro PG je úplně triviální - stačí porovnat DIČ z certifikátu s DIČ ve zprávě.
Myslím, že prípad d) ukradnutý a zneplatnený certifikát ošetriť na strane klienta nie je možné. Všetci sme začínali s chybu a), teraz podľa tejto diskusie sú bežné chyby b) a c+d nás ešte len čaká. Bolo by plusom dostať jasnejšiu chybu, a nie ako teraz jedinú chybu 4 na všetko.

Vyriešil už niekto v DelphiEET overenie podpisu prijatej správy v produkčnom prostredí? Priznám sa, že v certifikátoch nie som doma. Odkiaľ pochádza súbor trusted_CA.der? Pretože na webe etrzby.cz nie je. Ako získať ekvivalentný súbor pre produkčné prostredie, ktorým bude podpísaná odpoveď?
Název: Re:Delphi + EET
Přispěvatel: mirus 03-11-2016, 15:06:09
Zdravím,
soubor trusted_CA.der je http://www.ica.cz/CA-pro-kvalifikovane-sluzby konkrétně http://www.ica.cz/userfiles/files/certifikaty/SHA2/qica_root_key_20090901.der
Je to vydavatel certfikátu odpovědi na playgroud.
Pro produkční certifikát odpovědi je vydavatel https://www.ica.cz/HCA-kvalifikovany "CN = I.CA Qualified 2 CA/RSA 02/2016", ten je jako subvydavatel. Hlavní CA je "CN = I.CA Root CA/RSA" zde https://www.ica.cz/HCA-root

Ještě nemám k ruce certifikát pro produkční prostředí, tak nemohu zatím otestovat. Už brzy.

DelphiEET již upraveno, aby šlo přidávat více trusted certifikátů, protože zatím nevím jak se to bude chovat pokud nebude znám i "CN = I.CA Root CA/RSA".
Nyní lze třeba přidat jak ověřovací certifikát pro playground, tak i pro produkční najednou současně.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 04-11-2016, 09:30:27
..............
Myslím si, že nebudem jediný, kto by privítal, keby chybu 4 rozdelili na varianty:
a) Podpis úplne absentuje alebo je chybný
b) Podpis je neplatný pre konkrétne prostredie (pg v produkčnom)
c) Podpis je pred/po dátume platnosti
d) Podpis je neplatný - zrušený napr. po krádeži certifikátu
Ovšem fakt je, že až na "podpis je chybný", což může být způsobeno drobnou chybou v kódu, všechno ostatní můžete snadno na straně klienta ošetřit vy :-) Třeba nepodepisovat ostrá podání certifikátem pro PG je úplně triviální - stačí porovnat DIČ z certifikátu s DIČ ve zprávě.
Myslím, že prípad d) ukradnutý a zneplatnený certifikát ošetriť na strane klienta nie je možné. Všetci sme začínali s chybu a), teraz podľa tejto diskusie sú bežné chyby b) a c+d nás ešte len čaká. Bolo by plusom dostať jasnejšiu chybu, a nie ako teraz jedinú chybu 4 na všetko.

Vyriešil už niekto v DelphiEET overenie podpisu prijatej správy v produkčnom prostredí? Priznám sa, že v certifikátoch nie som doma. Odkiaľ pochádza súbor trusted_CA.der? Pretože na webe etrzby.cz nie je. Ako získať ekvivalentný súbor pre produkčné prostredie, ktorým bude podpísaná odpoveď?

Vyřešit případ d) je problém hlavně pro přijímací stranu :-) Pokud jde o podepisující
stranu, tak když už nějakým certifikátem podepisuju, tak mám asi nejvíc informací o tom,
jestli jsem ho zneplatňoval nebo ne. Každopádně ověřit jestli certifikát byl revokován
je elementární úloha, a můžete ji provést jak na klientovi před použitím certifikátu,
tak na straně příjemce který podpisový certifikát ověřuje.
Název: Re:Delphi + EET
Přispěvatel: peta.dol 04-11-2016, 10:23:44
Ted se mi vratila z produkcniho prostredi chyba:

<eet:Chyba kod="8">Datova zprava nebyla zpracovana kvuli technicke chybe nebo chybe dat</eet:Chyba>
Zkontroloval jsem odesilany request a je v poradku...

a jak tak znova premyslim o tom vyctu chyb:

-1 Docasna technicka chyba zpracovani – odeslete prosim datovou zpravu pozdeji
0  Datovou zpravu evidovane trzby v overovacim modu se podarilo zpracovat
1  **
2  Kodovani XML neni platne )***
3  XML zprava nevyhovela kontrole XML schematu
4  Neplatny podpis SOAP zpravy
5  Neplatny kontrolni bezpecnostni kod poplatnika (BKP)
6  DIC poplatnika ma chybnou strukturu
7  Datova zprava je prilis velka
8  Datova zprava nebyla zpracovana kvuli technicke chybe nebo chybe dat


Tak pro 2,3,4,5,6,7 je jasne ze se nemusim pokouset o odeslani teto zpravy znovu - je s ni neco v neporadku (spatne setavena) a server ji tak jak je stejne nikdy neprijeme...
Ale pro -1 a 8 to neni uplne tak jasne.
U -1 je vyslovene napsano ze se mam pokusit o odeslani pozdeji - OK pokusim se.
Co ale v pripade chyby 8? Mam ji prohlasit taky za neopravitelnou nebo se mam pokouset o jeji doodeslani pozdeji? Nikde jsem toto rozebrane nenasel, tak me zajima Vas nazor, jak se k chybe 8 stavite vy....
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 04-11-2016, 10:54:26
Co ale v pripade chyby 8? Mam ji prohlasit taky za neopravitelnou nebo se mam pokouset o jeji doodeslani pozdeji? Nikde jsem toto rozebrane nenasel, tak me zajima Vas nazor, jak se k chybe 8 stavite vy....

No, já myslím, že v tom zákoně je to jasně naspané. První odeslání - má příznak první odeslání. Chyba číslo 8 je také chyba, takže první pokus selhal. Zařadit do fronty pro následné odeslání a již příznak první odeslání nenastavovat. Já to tedy mám takto v EET udělané a dle zákona je to tak asi správně.

Mně zase fascinuje "XML zprava nevyhovela kontrole XML schématu". S tím jsem se natrápil nejvíc, dokud jsem nezjistil, že neumožňují prázdné atributy, což potom do toho jejich dokumentu dopsali, ale předtím to tam nebylo.

Celkově s vámi všemi souhlasím, že by možná mohli ty chyby více konkretizovat.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 04-11-2016, 10:56:32
Jo, ještě jsem zapomněl napsat, že ta chyba 8 je podle mě na jejich straně, takže jednoznačně odeslat znovu. Ty ostatní samozřejmě zkoumat u sebe.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 04-11-2016, 11:00:39
A ještě k té chybě 8, u nich v dokumentaci na EET píší doslova toto:

Může se jednat o chybu ve vámi zaslané datové zprávě nebo o chybu v aplikaci Playground. Připojte prosím zaslanou datovou zprávu a odpověď s chybou 8 ke kontaktnímu formuláři na stránkách www.etrzby.cz a vyčkejte na vyjádření.

Ale to je pro PlayGround, v produkčním prostředí nevím. Já to mám prostě udělané tak, že tato chyba se vyhodnotí jako zařazení do fronty pro nové odeslání s příznakem První odeslání na False. Ale možná to tedy budu muset ještě přehodnotit, když tam píší, že se může jednat i o chybu v mojí datové zprávě. Co si pod tím ale představit ? Ach jo.
Název: Re:Delphi + EET
Přispěvatel: peta.dol 04-11-2016, 11:08:43
A ještě k té chybě 8, u nich v dokumentaci na EET píší doslova toto:

Může se jednat o chybu ve vámi zaslané datové zprávě nebo o chybu v aplikaci Playground. Připojte prosím zaslanou datovou zprávu a odpověď s chybou 8 ke kontaktnímu formuláři na stránkách www.etrzby.cz a vyčkejte na vyjádření.

Ale to je pro PlayGround, v produkčním prostředí nevím. Já to mám prostě udělané tak, že tato chyba se vyhodnotí jako zařazení do fronty pro nové odeslání s příznakem První odeslání na False. Ale možná to tedy budu muset ještě přehodnotit, když tam píší, že se může jednat i o chybu v mojí datové zprávě. Co si pod tím ale představit ? Ach jo.

Já mám aktuálně nastaveno automatické doodesílání pouze pro chybu "-1" a právě si nejsem jistý jestli chybu "8" tam také nezařadit. Ale vzhledem k tomu, že ve výsledku všechny zprávy musejí být stejně nakonec poslány. Asi nezkazím nic tím, že i chybu "8" budu klasifikovat jako chybu na jejich serveru a budu se jí pokoušet automaticky odeslat znovu z fronty...
Následně pokud to byla nějaký chyba na serveru - příště ji server přijme. Pokud na mojí straně (chybně sestavená) tak mi jí vrátí opět s chybou 8 nebo s chybou jinou a mě zůstane ve frontě...
Název: Re:Delphi + EET
Přispěvatel: anec 04-11-2016, 14:57:09
ahoj,
nemohl by prosím někdo ověřit, že pokud odesílám do ostrého eet a do údaje provozovna zadám provozovnu, která není registrována,
že to projde bez chyby
díky
Název: Re:Delphi + EET
Přispěvatel: agentKobliha 04-11-2016, 17:55:15
Tak FIK mi to vrátí a objekt třídy TEETTrzba.HasVarovani vrátí False, pak v přehledu na webové aplikaci EET se mi to zobrazí v sekci jako "neregistrovaná provozovna".

ahoj,
nemohl by prosím někdo ověřit, že pokud odesílám do ostrého eet a do údaje provozovna zadám provozovnu, která není registrována,
že to projde bez chyby
díky
Název: Re:Delphi + EET
Přispěvatel: anec 04-11-2016, 19:15:59
ok, děkuji
Název: Re:Delphi + EET
Přispěvatel: zdenek 07-11-2016, 17:43:25
Pro ty, co řeší prodej i na mobilních zařízeních, tak minimiálně v Delphi Berlin 10.1 je chyba v CreateGUID a generuje to špatná UUID. Jsou přeházené bajty. Tak, abyste na tím nestrávili pátek jako já :-)

Z
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 08-11-2016, 08:05:23
Pro ty, co řeší prodej i na mobilních zařízeních, tak minimiálně v Delphi Berlin 10.1 je chyba v CreateGUID a generuje to špatná UUID. Jsou přeházené bajty. Tak, abyste na tím nestrávili pátek jako já :-)

Z

Aha, tak to je zajímavé, na to jsem nepřišel. Jak přesně to GUID generuješ ? Pokud vím, tak v tom opravdu problém byl - když se používalo CoCreateGuid, tak předtím muselo být voláno CoInitialize. Není to Tvůj případ ? Jinak by to byla dost blbá chyba, pokud by to opravdu generovalo špatné GUID. Já s tím ale problém nemám a ani jsem o tom nikde neslyšel ani nic nevygooglil, že by RAD Studio mělo tuto chybu.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 08-11-2016, 08:09:57
Pro ty, co řeší prodej i na mobilních zařízeních, tak minimiálně v Delphi Berlin 10.1 je chyba v CreateGUID a generuje to špatná UUID. Jsou přeházené bajty. Tak, abyste na tím nestrávili pátek jako já :-)

Z

Jo, teď jsem si ještě uvědomil, že píšeš o mobilních zařízeních. Tak to možná bude něco jiného.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 08-11-2016, 08:27:10
Pro ty, co řeší prodej i na mobilních zařízeních, tak minimiálně v Delphi Berlin 10.1 je chyba v CreateGUID a generuje to špatná UUID. Jsou přeházené bajty. Tak, abyste na tím nestrávili pátek jako já :-)

Z


Cau Zdenku,

mohu poprosit o bug report, nebo test case? Moc ten popis nechapu. Nikdy jsem se o to nezajimal, ale myslel jsem ze GUID nema presne dane poradi co ktery byte znamena. Resp. ze to je dle platformy. Nebo se pletu?

R.

Název: Re:Delphi + EET
Přispěvatel: pf1957 08-11-2016, 08:42:51
ale myslel jsem ze GUID nema presne dane poradi co ktery byte znamena. Resp. ze to je dle platformy. Nebo se pletu?
https://tools.ietf.org/html/rfc4122 (https://tools.ietf.org/html/rfc4122)
Název: Re:Delphi + EET
Přispěvatel: pepak 08-11-2016, 12:07:01
myslel jsem ze GUID nema presne dane poradi co ktery byte znamena. Resp. ze to je dle platformy. Nebo se pletu?
Hlavně to je podle varianty GUID. EET má speciální požadavek na některé jeho části, za účelem snížení náhodnosti vygenerovaného ID a zvýšení rizika kolize. To může být v konfliktu s tím, jak funguje CreateGUID.
Název: Re:Delphi + EET
Přispěvatel: oxo 08-11-2016, 12:13:36
EET má speciální požadavek na některé jeho části, za účelem snížení náhodnosti vygenerovaného ID a zvýšení rizika kolize.

 ;D  ;D  ;D  ;D
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 08-11-2016, 15:06:51
Pro ty, co řeší prodej i na mobilních zařízeních, tak minimiálně v Delphi Berlin 10.1 je chyba v CreateGUID a generuje to špatná UUID. Jsou přeházené bajty. Tak, abyste na tím nestrávili pátek jako já :-)

Z

Hele, tak já jsem se ještě jednou v tom prohrabal, podíval jsem se do logu svého k EET, kde už mám desítky úspěšně zaslaných tržeb a vygenerované UUID je správně dle RFC 4122 u všech, což píší v dokumentaci k EET, že to má být podle RFC 4122. Odkaz na to RFC tu zveřejnil pf1957 a Delphi mi to určitě generují správně pomocí CoInitialize + CoCreateGUID.

Chápu to tedy dobře, že s tím máš problém jenom u mobilních zařízení ? Tam to tedy negeneruje ta funkce CreateGUID podle RFC 4122 ? Můžeš zaslat nějaký příklad GUID, co Ti to vygeneruje ?
Název: Re:Delphi + EET
Přispěvatel: oxo 08-11-2016, 19:20:33
CoCreateGuid je z ole32, t.j. Win-only. Mobilní zařízení ji z logických důvodů používat nemohou. Viz CreateGUID z System.SysUtils.pas - nových verzí Delphi.
Název: Re:Delphi + EET
Přispěvatel: zdenek 08-11-2016, 22:43:58
Delphi na Androidu používá pro GUID funkce java/utils/UUID konkrétně randomUUID. Výslednou hodnotu pak čte pomocí getLeastSignificantBits a getMostSignificantBits. Ty nakonec poskládá do TGUID pomocí následujícího nesmyslu:

Kód: Delphi [Vybrat]
  1.   LSB: Int64;
  2.   MSB: Int64;
  3.   Temp: PInt64;
  4.  
  5.   Temp := @Guid;
  6.   Temp^ := MSB;
  7.   Inc(Temp);
  8.   Temp^ := LSB;
  9.  

Výsledek má přeházené všechny bajty. Já to nahradil tímto:
Kód: Delphi [Vybrat]
  1.  RV=packed record
  2.      A:Int16;
  3.      B:Int16;
  4.      C:Int32;
  5.     end;
  6.  RX=packed record
  7.      D,E,F,G,H,I,J,K:Byte;
  8.     end;
  9.  
  10.   Guid:=TGuid.Create(RV(MSB).C,RV(MSB).B,RV(MSB).A,
  11.                      RX(LSB).K,RX(LSB).J,RX(LSB).I,RX(LSB).H,RX(LSB).G,RX(LSB).F,RX(LSB).E,RX(LSB).D);

A výsledek je správný jak má být. Radku, podívej se do SysUtils do GetAndroidGUID.
Název: Re:Delphi + EET
Přispěvatel: pepak 09-11-2016, 06:02:32
Osobně jsem i na Win raději vynutil správný obsah GUID:

Kód: Delphi [Vybrat]
  1.   Result := GenerateUuid;
  2.   if Result <> '' then
  3.     if Result[1] = '{' then
  4.       Delete(Result, 1, 1);
  5.   if Result <> '' then
  6.     if Result[Length(Result)] = '}' then
  7.       SetLength(Result, Length(Result)-1);
  8.   Result := LowerCase(Result);
  9.   if Length(Result) >= 36 then begin
  10.     Result[15] := '4';
  11.     case Result[20] of
  12.       '0': Result[20] := '8';
  13.       '1': Result[20] := '9';
  14.       '2': Result[20] := 'a';
  15.       '3': Result[20] := 'b';
  16.       '4': Result[20] := '8';
  17.       '5': Result[20] := '9';
  18.       '6': Result[20] := 'a';
  19.       '7': Result[20] := 'b';
  20.       'c': Result[20] := '8';
  21.       'd': Result[20] := '9';
  22.       'e': Result[20] := 'a';
  23.       'f': Result[20] := 'b';
  24.     end;
  25.   end;
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 09-11-2016, 10:57:54
Super, tak už je mi to jasné s tím GUID, díky za info pepakovi i zdenkovi.

Ještě mám jeden dotaz na vás všechny, co řešíte EET. Jak se stavíte k částkám tržby. Uvedu příklad: mojí pokladnu bude používat člověk, který není plátcem DPH, takže má povinnost zaslat pouze celkovou tržbu. Zatím to mám dělané tak, že v tomto případě se v XML jako celková tržba vloží skutečná částka tržby a další částky - jednotlivé základy, DPH, částky pro použité zboží, cestovní služby a podobně jsou nulové, ale posílají se. EET to zpracuje jako správný XML request. Jenže v dokumentaci píší, že nejsou povoleny prázdné atributy. Takže třeba pokud nemáte DIČ pověřující osoby, tak prázdný atribut hlásí chybu, musí se ten atribut úplně odstranit. U těch částek je to ale sporné. Já tam prostě posílám například: cerp_zuct="0". Jenže teď nevím, zda je to dobře. EET to vezme, ale ... Jak toto řešíte ? Když klient například nemusí vykazovat položku "cerp_zuct", posíláte v elementu <eet:Data> tento atribut jako cerp_zuct="0" nebo tam tento atribut vůbec neuvádíte ? V dokumentaci na jednom místě totiž píší, že chybějící atribut s částkou a atribut částky s nulovou hodnotou nejsou to samé. Nicméně EET to vezme bez varování jako správné. Jak toto řešíte ?
Název: Re:Delphi + EET
Přispěvatel: pepak 09-11-2016, 11:04:34
jsou nulové, ale posílají se. [...] Jenže v dokumentaci píší, že nejsou povoleny prázdné atributy.
atribut="0" není prázdný atribut. Prázdný atribut je atribut="".

Citace
Když klient například nemusí vykazovat položku "cerp_zuct", posíláte v elementu <eet:Data> tento atribut jako cerp_zuct="0" nebo tam tento atribut vůbec neuvádíte ?
Vůbec neuvádím. Ale podle všech školení je OK, když se uvede s hodnotou nula.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 09-11-2016, 13:12:06
atribut="0" není prázdný atribut. Prázdný atribut je atribut="".

Což to je jasný, to je opravdu tak, jak píšeš, v tom jsem netápal.

Mně zajímalo z jejich pohledu, když pošlu atribut="0", což není prázdný atribut a systém jim to vezme, protože ten nebere jenom prázdné atributy, tak jak to budou posuzovat, když se ta položka vykazovat nemusí. Asi nejlepší by bylo jí neposílat. Ale jestli podle školení je to jedno, že se pošle nula, jak píšeš, tak to asi nemá smysl řešit. Mně jenom zajímalo, co si o tom myslíte. Je to sice kravina, ale nerad bych, abych pak zjistil, že tam celou dobu posílám nesprávně vykázanou tržbu. Takže díky za odpovědi.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 09-11-2016, 13:21:27
Hele a teď jsem si všimnul, že ve verzi dokumentace 3.1.1 vypadla ta poznámka ohledně nulových částek a prázdných atributů. Alespoň to tam už nemůžu najít. Takže to bude určitě tak, jak psal pepak, že uvedení nulových hodnot u atributů částek je úplně jedno v případě, že se nemusí vykazovat.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 09-11-2016, 13:40:12
Cituji z dokumentace (Popis_polozek_datove_zpravy_v3.1.pdf), ta se s verzí 3.1.1 neměnila:
Společné informace ke všem položkám datové zprávy 
  Datová zpráva musí vždy obsahovat všechny povinné položky. 
  Položky označené jako nepovinné musí být vyplněny, pokud jsou k evidované tržbě
relevantní (např. plátci DPH musí mít vyplněny položky o DPH, které jsou relevantní
k tržbě). 
  Položky, které nejsou k dané tržbě relevantní, se do datové zprávy vůbec neuvádí,
a to ani s nulovou, ani s prázdnou hodnotou (např. Celkový základ daně s první
sníženou sazbou, u tržby, která má DPH pouze v základní sazbě)

Takže u Neplátce DPH neuvádím žádný atribut základů a daní, u Plátce DPH uvádím jen ten základ a daň, který se na účtu skutečně vyskytuje, byť by měl nulovou hodnotu. Atribut cerp_zuct uvádím jen při platbě zákaznickou kartou, atribut urceno_cerp_zuct jen u dobíjení zůstatku zákaznické karty.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 09-11-2016, 13:55:44
Položky, které nejsou k dané tržbě relevantní, se do datové zprávy vůbec neuvádí,
a to ani s nulovou, ani s prázdnou hodnotou (např. Celkový základ daně s první
sníženou sazbou, u tržby, která má DPH pouze v základní sazbě)

Jo, já to znovu hledal v tom dokumentu EET_popis_rozhrani_v3.1.1.pdf a ono to je v dokumentu Popis_polozek_datove_zpravy_v3.1. Takže díky za info, tím to je jasné, ještě to předělám raději podle toho jejich dokumentu. Sice to přes to jejich rozhraní projde, ale chci se vyvarovat problémům v budoucnu. Řečeno je to tam jasně, takže co ouřada chce, to mu dám :-)

Jinak to urceno_cerp_zuct používám u zálohových listů a to cerp_zuct u dokladů, které jsou vyúčtováním zálohového listu.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 09-11-2016, 14:22:12
Ty zálohy se týkají samozřejmě elektronických peněženek a podobně, není to samozřejmě pro všechny zálohy a doklady, které je vyúčtovávají. Musím říci, že z toho EET jsem už dost zmagořený, minulý rok Kontrolní hlášení DPH, letos EET, co vymyslí příští rok ? Raději nechci domyslet.
Název: Re:Delphi + EET
Přispěvatel: anec 09-11-2016, 14:39:47
asi blbě hledám, ale nemůžu najít návod k:
jsem plátce dph, mám fakturu 100tisíc + 21000 dph celkem 121.000,-
a zákazník mi zaplatí 50.000,-
pošlu tedy do EET 50.000,- ale jak se rozepisují ty základy daně a dph?
Název: Re:Delphi + EET
Přispěvatel: karel.kral 09-11-2016, 15:36:04
Zajímalo by mě, jak se stavíte k cerp_zuct a tím, uvádět pro toto základy daní a hodnoty daně? A co zapisujete do celk_trzba? Poslal jsem na GFŘ podporu následující dotaz a odpověď po 5 týdnech je dost zmatená: Podle nich by se do celk_trzba měl uvádět vklad na účet. Ale u něho není známa sazba daně. Z čeho chtějí tedy počítat daň a základ daně?

Dobrý den,
za předpokladu, že zákazník nabil kredit v hotovosti, platební kartou nebo obdobnými prostředky a současně v rámci jedné transakce zakoupil u poplatníka zboží, které je zaplaceno formou čerpání nabitého kreditu:
·         nabití kreditu 100 Kč – není znám předmět plnění
·         nákup zboží v hodnotě 50 Kč

Datová zpráva bude následující:
    celk_trzba = 100 Kč
    urceno_cerp_zuct = 100 Kč
    cerp_zuct = 50 Kč
    základ daně v příslušné výši
    daň v příslušné výši

Dotaz: Dobrý den, potřebuji vědět, jakým způsobem se má chovat pole 11 (Celková částka tržby) ve vztahu k polím 23 (CELKOVÁ ČÁSTKA PLATEB URČENÁ K NÁSLEDNÉMU ČERPÁNÍ NEBO ZÚČTOVÁNÍ) a 24 (CELKOVÁ ČÁSTKA PLATEB, KTERÉ JSOU NÁSLEDNÝM ČERPÁNÍM NEBO ZÚČTOVÁNÍM PLATBY). Jedná se o prodej registrovaným klientům, kteří si mohou vkládat částky na svůj zákaznický účet a pak zase z tohoto účtu provádět úhradu zboží. To se může stát i na jedné účtence. Uvedu příklad: Klient vloží 100 Kč na svůj účet - dobije si stav účtu vkladem. Na stejném paragonu odebere zboží za 50 Kč Do pole 23 Finanční položky tržby zadám tedy 100 Kč (vklad) Do pole 24 Finanční položky tržby zadám 50 Kč (za odebrané zboží) Má otázka: Jaká má být v tomto případě hodnota v poli 11 Celková částka tržby? Má se toto pole vůbec vyplňovat?

[/i]
Takže u Neplátce DPH neuvádím žádný atribut základů a daní, u Plátce DPH uvádím jen ten základ a daň, který se na účtu skutečně vyskytuje, byť by měl nulovou hodnotu. Atribut cerp_zuct uvádím jen při platbě zákaznickou kartou, atribut urceno_cerp_zuct jen u dobíjení zůstatku zákaznické karty.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 09-11-2016, 15:44:09
Nemáte prosím někdo zkušenosti z tím, co všechno je na firewallu potřeba mít otevřené pro komunikaci s produkčním serverem? Stačí mít jenom povolený odchozí port 443 pro prod.eet.cz? Někteří správci sítí jsou psi a mají takové podmínky. Někteří tvrdí, že museli otevřít i port 80, aby nám to jelo, ale to se mi nezdá.

Máte někdo ponětí o tom, jakým způsobem se v případě, že je povolena pouze jedna odchozí adresa, komunikuje ohledně certifikátů atd? Předpokládám, že je to v režii WebRequestu, ale jak to přesně funguje nevím.
Název: Re:Delphi + EET
Přispěvatel: zdenek 09-11-2016, 16:07:25
Nemáte prosím někdo zkušenosti z tím, co všechno je na firewallu potřeba mít otevřené pro komunikaci s produkčním serverem? Stačí mít jenom povolený odchozí port 443 pro prod.eet.cz? Někteří správci sítí jsou psi a mají takové podmínky. Někteří tvrdí, že museli otevřít i port 80, aby nám to jelo, ale to se mi nezdá.

Máte někdo ponětí o tom, jakým způsobem se v případě, že je povolena pouze jedna odchozí adresa, komunikuje ohledně certifikátů atd? Předpokládám, že je to v režii WebRequestu, ale jak to přesně funguje nevím.

Jestli ověřujete podpisy tak i přístup na CRL certifikátů. Jinak nic. Odesílání je ve výsledku klasický HTTPS.Post.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 09-11-2016, 16:36:35
Citace
Zajímalo by mě, jak se stavíte k cerp_zuct a tím, uvádět pro toto základy daní a hodnoty daně? A co zapisujete do celk_trzba? Poslal jsem na GFŘ podporu následující dotaz a odpověď po 5 týdnech je dost zmatená: Podle nich by se do celk_trzba měl uvádět vklad na účet. Ale u něho není známa sazba daně. Z čeho chtějí tedy počítat daň a základ daně?
To je především otázka na daňového poradce. Aby to nebylo tak jednoduché, je ještě nutné rozlišovat, zda je zůstatek na zákaznické kartě plusový a pak jde o čerpání zálohy, nebo je zůstatek nulový, placením jdete do mínusu, pak na kartu vlastně půjčujete a jedná se o půjčku. Každý případ je v jiné sazbě. No a ještě do toho vstupují placené položky, i když u nich je DPH jasné.
Více se do toho nechci nořit, daňový poradce nejsem.
Název: Re:Delphi + EET
Přispěvatel: Peťo 10-11-2016, 08:55:34
jsem plátce dph, mám fakturu 100tisíc + 21000 dph celkem 121.000,-
a zákazník mi zaplatí 50.000,-
pošlu tedy do EET 50.000,- ale jak se rozepisují ty základy daně a dph?
Toto by veľmi zaujímalo aj mňa. Stačí pri úhrade pohľadávky u platcu DPH uviesť iba jednu sumu celk_trzba bez rozpisu na DPH? Keďže DPH už bola odvedená z faktúry a hrozili by problémy s párovaním a dvojnásobné odvedenie DPH. Nemá niekto vyjadrenie z FŘ?
Název: Re:Delphi + EET
Přispěvatel: pepak 10-11-2016, 20:34:04
Toto by veľmi zaujímalo aj mňa. Stačí pri úhrade pohľadávky u platcu DPH uviesť iba jednu sumu celk_trzba bez rozpisu na DPH?
Ne. Pokud je příjemce peněz plátcem DPH, stávají se pro něj povinnými i rozpisy.

Citace
Keďže DPH už bola odvedená z faktúry a hrozili by problémy s párovaním a dvojnásobné odvedenie DPH. Nemá niekto vyjadrenie z FŘ?
EET účtenka není sama o sobě daňovým dokladem, přestože obsahuje některé z náležitostí daňového dokladu.
Název: Re:Delphi + EET
Přispěvatel: pepak 10-11-2016, 20:35:01
To je především otázka na daňového poradce. Aby to nebylo tak jednoduché, je ještě nutné rozlišovat, zda je zůstatek na zákaznické kartě plusový a pak jde o čerpání zálohy, nebo je zůstatek nulový, placením jdete do mínusu, pak na kartu vlastně půjčujete a jedná se o půjčku. Každý případ je v jiné sazbě.
Nicméně to jsi musel řešit i před EET. EET na to nemá žádný vliv.
Název: Re:Delphi + EET
Přispěvatel: Peťo 11-11-2016, 08:13:35
Stačí pri úhrade pohľadávky u platcu DPH uviesť iba jednu sumu celk_trzba bez rozpisu na DPH?
Ne. Pokud je příjemce peněz plátcem DPH, stávají se pro něj povinnými i rozpisy.
Takže pri pohľadávke 100 Kč + DPH 21 Kč = 121 Kč a jej čiastočnej úhrade v hotovosti 50 Kč
sa bude do EET posielať klasicky najskôr úhrada dane a potom základu:
         celk_trzba=50  zakl_dan1=29  dan1=21
a pri úhrade zvyšku pohľadávky:
         celk_trzba=71  zakl_dan1=71  dan1=0
Nebudú takéto tržby pre FÚ podozrivé, keď tam nebude sedieť výpočet DPH?
To naozaj nie sú nijako rozlíšené úhrady pohľadávky od bežného predaja?
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 11-11-2016, 11:01:04
To je především otázka na daňového poradce. Aby to nebylo tak jednoduché, je ještě nutné rozlišovat, zda je zůstatek na zákaznické kartě plusový a pak jde o čerpání zálohy, nebo je zůstatek nulový, placením jdete do mínusu, pak na kartu vlastně půjčujete a jedná se o půjčku. Každý případ je v jiné sazbě.
Nicméně to jsi musel řešit i před EET. EET na to nemá žádný vliv.
Správně. Mám to vyřešeno již dávno před EET, právě ve spolupráci s daňovým poradcem.
Název: Re:Delphi + EET
Přispěvatel: bohdan 11-11-2016, 11:44:15
jsem plátce dph, mám fakturu 100tisíc + 21000 dph celkem 121.000,-
a zákazník mi zaplatí 50.000,-
pošlu tedy do EET 50.000,- ale jak se rozepisují ty základy daně a dph?


Zde je odpověď od GFŘ

Dobrý den,
vystavuje-li podnikatel fakturu, není pro účely evidence tržeb rozhodné, jaká forma platby je na ní uvedena, ale jakým způsobem je částka uvedená na faktuře fakticky uhrazena. Zaplatí- li zákazník příslušnou částku v hotovosti, platební kartou nebo jiným obdobným způsobem, musí podnikatel platbu zaevidovat, a to i tehdy, je-li jako způsob úhrady uvedeno bezhotovostně.
 
Obecně platí, že v případě plátce DPH jsou v datové zprávě zasílané správci daně uváděny i údaje o DPH, které se k evidované tržbě vztahují (viz ust. § 19 zákona č. 112/2016 Sb., o evidenci tržeb, dále jen „ZoET“). Způsob uvedení těchto částek v případě částečné úhrady faktury s více sazbami ZoET neupravuje. Částky týkající se DPH, které se vztahují k částečné částce uhrazené v hotovosti, mohou tedy být s ohledem na více použitých sazeb na vydané faktuře zohledněny poměrem nebo si poplatník sám stanoví, která sazba se uhrazené částky týká. Pro účely daně z přidané hodnoty (uvedené v daňovém přiznání k DPH a kontrolním hlášení) je rozhodující celá částka zdanitelného plnění, tedy 1000 Kč, která je uvedena na vystaveném daňovém dokladu (faktuře) ve smyslu ustanovení § 26 a následující zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů.
 
Při doplatku faktury v hotovosti ve výši 99 Kč bude datová zpráva obsahovat příslušné základy daně a odpovídající částky DPH. Pokud by bylo uhrazeno v hotovosti více faktur jednou částkou, bude evidovanou tržbou celková přijatá částka a v datové zprávě budou souhrnně uvedeny i příslušné částky DPH. Propojení na původní daňový doklad zákon poplatníkům neukládá. Podnikatel však musí nastavit procesy uvnitř firmy tak, aby byl schopen výše uvedenou povinnost danou ZoET splnit.
 
Při posouzení Vámi předloženého emailového dotazu vycházelo Generální finanční ředitelství výhradně z údajů uvedených ve Vašem dotazu, a to bez dalších konkrétních informací a souvislostí, které se k předmětné situaci vztahují. Upozorňujeme, že Generální finanční ředitelství neposkytuje závazný výklad a aplikaci právních předpisů. K tomuto je v individuálních případech oprávněný místně a věcně příslušný soud. Poskytnuté informace nenahrazují závazný právní výklad, závazné posouzení o určení evidované tržby či rozhodnutí v soudním řízení.
 
S pozdravem,
 
Alena Marešová
Generální finanční ředitelství
Metodická podpora evidence tržeb


Název: Re:Delphi + EET
Přispěvatel: pepak 11-11-2016, 12:59:35
Takže pri pohľadávke 100 Kč + DPH 21 Kč = 121 Kč a jej čiastočnej úhrade v hotovosti 50 Kč
sa bude do EET posielať klasicky najskôr úhrada dane a potom základu:
         celk_trzba=50  zakl_dan1=29  dan1=21
a pri úhrade zvyšku pohľadávky:
         celk_trzba=71  zakl_dan1=71  dan1=0
Nevím. Nejsem si jistý, jestli tohle vůbec GFŘ řeší.

Citace
Nebudú takéto tržby pre FÚ podozrivé, keď tam nebude sedieť výpočet DPH?
To je otázka na FÚ.

Citace
To naozaj nie sú nijako rozlíšené úhrady pohľadávky od bežného predaja?
Ne. EET je zavedená na evidenci hotovostních*) plateb. Jaký byl účel platby není relevantní.

*) Kde hotovostí je skoro všechno kromě převodu přes banku.
Název: Re:Delphi + EET
Přispěvatel: dynamo37 12-11-2016, 16:03:52
Ahoj, používáte někdo knihovnu nabízenou na jadu.cz/eet.html? Pokud ano jaké s ní máte zkušenosti?
Název: Re:Delphi + EET
Přispěvatel: Jirka 13-11-2016, 12:54:04
Třeba to někomu pomůže .. 
Aplikace pro testovaní odeslání tržby pomocí certifikátu bud v souboru nebo v úložišti    , nastavení produkčního nebo testovacího serveru
offline režim atd.

http://www.agrowin.cz/data/EET-TEST.ZIP

Další info na dotaz ..

P.S. Vyžaduje Dotnet 4,5
Název: Re:Delphi + EET
Přispěvatel: vlatik.c 13-11-2016, 17:19:27
Ahojte, musim se smat..
http://ekonomika.idnes.cz/poridili-si-eet-pokladnu-a-slapli-vedle-dys-/ekonomika.aspx?c=A161112_192100_ekonomika_jvl (http://ekonomika.idnes.cz/poridili-si-eet-pokladnu-a-slapli-vedle-dys-/ekonomika.aspx?c=A161112_192100_ekonomika_jvl)
ze by O2?
Název: Re:Delphi + EET
Přispěvatel: pepak 13-11-2016, 19:16:37
ze by O2?
Podle mě spíš IQ.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 14-11-2016, 08:57:25
ze by O2?
Podle mě spíš IQ.

Souhlas. Je to o IQ. U nás se teď dveře předávají z jedné ruky do druhé - lidi, které vůbec neznáme, se chodí ptát na EET. Jsou to vesměs drobní podnikatelé. Řeší to až teď, nemají naprosto přehled o tom, o co jde. Naše firma je naštěstí slušná, ale je mi jasné, co jim všude možně nakukají a nabídnou jim předražené řešení, které ani nepotřebují. To je ale tohle hlavně chyba těch, kterých se EET týká. Nesnáším socialisty, jsem pro tvrdý kapitalismus, ale je pravda, že o EET se mluví už měsíce. Takže ty, kterých se to týká, si o tom mohli zjistit nějaké informace už dávno. Ale řeší to až teď, za pět minut dvanáct a je jasné, že se na tom teď přiživí spousta firem, který něco splácají a nabízí jim to za předražené peníze. Je mi těch podnikatelů na jednu stranu líto, ale na druhou - čas na to zjistit si informace a být připravený, ten čas byl a dost dlouhý. Konkurence je obrovská, snadno si najdou levné a dobré řešení.

Mě zase fascinuje jiná věc. U nás se na to udělala pořádná analýza, jezdilo se na školení, naprogramovalo se to, pořádně otestovalo a stále ladí, aby to pak s ostrým provozem bylo už na 100 procent. Přesto jsem dostal pár e-mailů, zda bych narychlo nenaprogramoval někomu EET ... Tak takhle se dělá software ? Narychlo obešlu pár lidí, zda mi to rychle za pět minut dvanáct splácají ? U nás se to analyzuje, programuje, testuje, věnuje so tomu maximální péče a pak někdo si představuje, že mu to někdo splácá za pár minut. Ale o tom jsem už psal mnohokrát a nebudu to už komentovat, je mi z toho smutno. Z tvorby software se stává něco, co mě děsí.

Jinak děkuji za podnětnou diskuzi o těch částkách. Ještě jsem to doladil, aby to bylo ouředně na 100 procent. Hezký den !
Název: Re:Delphi + EET
Přispěvatel: anec 14-11-2016, 10:32:22
2mweyda: aby to bylo ouředně na 100%, znamená to tedy, že při částečné úhradě první umořuješ dph a nebo to bereš jako podíl zálohy na celkové částce a podle toho vypočítáš podíl všech základů a daní?
Název: Re:Delphi + EET
Přispěvatel: Stanislav Hruška 14-11-2016, 11:42:23
OT:
Citace
Ale řeší to až teď, za pět minut dvanáct
Čo sa čuduješ :)  U nás nosia daňové priznanie na DÚ zásadne 31.03. ;D  Alebo si dajú žiadosť o odklad. A sú experti, ktorí v ten deň sú schopní účtovníkovi doniesť účtovné doklady. A tak je to vo všetkom. Aj keď nejaký ten malý pokrok sem tam vidieť.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 14-11-2016, 13:25:56
Ono pro některé vývojáře není za pět minut dvanáct, protože jejich zákazních budou mít třeba EET povinně až od března 2017 nebo i později...
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 15-11-2016, 09:30:31
OT:
Citace
Ale řeší to až teď, za pět minut dvanáct
Čo sa čuduješ :)  U nás nosia daňové priznanie na DÚ zásadne 31.03. ;D  Alebo si dajú žiadosť o odklad. A sú experti, ktorí v ten deň sú schopní účtovníkovi doniesť účtovné doklady. A tak je to vo všetkom. Aj keď nejaký ten malý pokrok sem tam vidieť.

No, Stano, prostě mě to rozčílilo :-) Ale je fakt, že někdy je o i obráceně. Že ouřadové vymyslí něco na poslední chvíli a zákazník to pak samozřejmě musí mít hned druhý den :-) Ale to na Slovensku je určitě podobně nebo ne ?
Název: Re:Delphi + EET
Přispěvatel: Stanislav Hruška 15-11-2016, 11:47:14
Citace
Ale to na Slovensku je určitě podobně nebo ne ?
Mám pocit, že ešte horšie. Bežne sa niečo direktívne prikáže od 1.1 a ajhľa. Ono to na strane štátnej správy nefunguje.
Najväčší gól v rámci IT je "elektronizácia", či ako sa to volá. Minuli sme 802 mil €. Ešte je v rezerve 200 mil € a v podstate to nefunguje. Litva to celé spravila za 200 mil €. Akurát, že jej to funguje :o
Taký malý súčasný príklad. Vydávajú sa elektronické OP. S možnosťou elektronické podpisu. Polícia túto možnosť žiadateľom neoznamuje. Dôvod: je to v podstate nefunkčné + ďalšie výdavky (čítačka).
Ešteže sme sa zbavili Babiša. A Fica nechcete? ;D ;D ;D
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 15-11-2016, 11:57:48
Ešteže sme sa zbavili Babiša. A Fica nechcete? ;D ;D ;D

Stano, díky za nabídku, ale Fica vám rádi přenecháme  :) Jinak to, co píšeš, jak to u vás na Slovensku chodí, tak se mi zdá, že Češi a Slováci jsou si opravdu naprosto rovný  :) Bordel ve státní správě je koukám u vás i u nás úplně stejný. Nedáme to zase dohromady, Česko-Slovensko ?  :)
Název: Re:Delphi + EET
Přispěvatel: Stanislav Hruška 15-11-2016, 12:01:21
Citace
Bordel ve státní správě je koukám u vás i u nás úplně stejný.
Nebudeš veriť, ale u Vás to je o niečo lepšie. Hlavne prístup k ľuďom. To tvrdia ľudia, čo podnikajú v ČR.
Název: Re:Delphi + EET
Přispěvatel: Daniel_Andrascik 15-11-2016, 20:44:01
Ešteže sme sa zbavili Babiša. A Fica nechcete? ;D ;D ;D

Stano, díky za nabídku, ale Fica vám rádi přenecháme  :) Jinak to, co píšeš, jak to u vás na Slovensku chodí, tak se mi zdá, že Češi a Slováci jsou si opravdu naprosto rovný  :) Bordel ve státní správě je koukám u vás i u nás úplně stejný. Nedáme to zase dohromady, Česko-Slovensko ?  :)

Marku no nie som si isty ci nas dokazete dohnat. Zaznamenali ste ten pruser ktory sa u nas stal pred 4 rokmi? Pani na slovensku na dva mesiace zlyhal danovi system. Prosim pekne slovensko zaplatilo tusim 10 milionov eur (250 000 000Kc) za vyvoj noveho komplexneho danoveho softveru, pretoze ten stary bol z dob DOSu. A nie len tak hoci komu, ale prosim pekne firme IBM.

S velkou slavou prislo na preprnutie zo stareho na novy system pre istou vo februari (unor) pred marcovimi danovimi priznaniami. No a prepnutie skoncilo takym fiaskom ze danovy uradnici sa vratili k ceruzkam, papierom a kalkulackam prosim. Po dvoch mesiacoch politickych otrasoch kedy si hadzali vinu jedni na druhych a vyvodzovali politicku zodpovednost sa naspat aktivoval stary informacny system. Tisicom podnikatelom chybali vratky DPH co pre niektorych mohlo byt na pokraji prezitia a dalsi sa zase s vysmechom tesili a dane ani neplatili.

Pruser cislo dva je eHealt. Cize elektronizacia zdravotnictva. Do neho sa prosim nasypali uz desiatky ak nie stovky milionov euro. Neviem presne ale malo byt dokoncene uz asi pred dvomi vladami a kazda vlada to len zo tri krat odsunie a potom pridu volby. Pred xyz rokmi sa uz pre eHealt vybudovala velka a velmi draha serverovna strazena viac ako pentagon (pretoze sa tam vraj nachadzaju osobne udaje, uhm zatial tam len horko tazko nahravaju nejake testovacie fiktivne data, ale nevadi). Spustene eHealtu je stale v podstate v nedohladne. A pokym dojde k spusteniu budu moct polovicku hardveru a softveru v tej serverovni vymenit pretoze to bude vsetko moralne zastarale.

No vivat slovakia...

Ja vazne neviem ale za tolke peniaze keby sme sa tu dali dokopi, prizvali si este zopar znamych serioznych programatorov, plus najali tym danovych analytikov a poradcov plus nejaky ten zakladny management tak za tych 10 milionov euro by sme to za dva roky spravili kazdy s nadhernym ziskom, nehovoriac o tom ze by sme mali krasny biznis po uplinuti paru rokov nejakej tej zmluvnej udrzby by sa zacali vsetky upravy a modifikacie systemu seriozne fakturovat. Biznis na dalsie desatrocia. Jediny problem je ze zo statom a tymi prasiatkami pri korytach nechcem mat nic spolocne.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 15-11-2016, 21:25:15

Marku no nie som si isty ci nas dokazete dohnat. Zaznamenali ste ten pruser ktory sa u nas stal pred 4 rokmi? Pani na slovensku na dva mesiace zlyhal danovi system. Prosim pekne slovensko zaplatilo tusim 10 milionov eur (250 000 000Kc) za vyvoj noveho komplexneho danoveho softveru, pretoze ten stary bol z dob DOSu. A nie len tak hoci komu, ale prosim pekne firme IBM.

S velkou slavou prislo na preprnutie zo stareho na novy system pre istou vo februari (unor) pred marcovimi danovimi priznaniami. No a prepnutie skoncilo takym fiaskom ze danovy uradnici sa vratili k ceruzkam, papierom a kalkulackam prosim. Po dvoch mesiacoch politickych otrasoch kedy si hadzali vinu jedni na druhych a vyvodzovali politicku zodpovednost sa naspat aktivoval stary informacny system. Tisicom podnikatelom chybali vratky DPH co pre niektorych mohlo byt na pokraji prezitia a dalsi sa zase s vysmechom tesili a dane ani neplatili.

Uprimne receno nas danovy SW (myslim CR) bezi na IBM mainframu nebo tak. A EET je k nemu jen dolepeno. To prvni mi nevadi - protoze to je stejne jako s tim, ze jaderny arzenal USA je ovladan pocitaci z 70 let https://www.muckrock.com/news/archives/2016/sep/23/governments-oldest-computer-isnt-technically-compu/ (https://www.muckrock.com/news/archives/2016/sep/23/governments-oldest-computer-isnt-technically-compu/) - ted se mimochodem chysta upgrade - vymena floppy mechaniky za neco co ji bude emulovat. Ale vse je deterministicke a popsane chovani (jen skoda ze heslo k odpaleni raket bylo x let 4xnula).
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 16-11-2016, 08:29:59
No vivat slovakia...

Ja vazne neviem ale za tolke peniaze keby sme sa tu dali dokopi, prizvali si este zopar znamych serioznych programatorov, plus najali tym danovych analytikov a poradcov plus nejaky ten zakladny management tak za tych 10 milionov euro by sme to za dva roky spravili kazdy s nadhernym ziskom, nehovoriac o tom ze by sme mali krasny biznis po uplinuti paru rokov nejakej tej zmluvnej udrzby by sa zacali vsetky upravy a modifikacie systemu seriozne fakturovat. Biznis na dalsie desatrocia. Jediny problem je ze zo statom a tymi prasiatkami pri korytach nechcem mat nic spolocne.

Danieli, díky moc za krásné shrnutí toho, jak to vypadá na Slovensku a připomíná mi to aféry posledních let u nás v České republice, které jsi asi také zaznamenal - nový informační systém pro naší sociálku a podobně. Také tam se vše hroutilo, přepínalo se ze starého systému na nový a zase zpět a pak ještě zase zpět a tak dále a tak dále, velké firmy si namastily kapsu a s nimi si kapsu namastili různí politici a informatici ze státní správy (většinou vedoucí IT odborů, kteří ovlivnili výběrové řízení). Je ale pravda, že nyní probíhají soudní řízení a tuším, že už byl i někdo za to pravomocně odsouzen. Takže alespoň něco. To jsou miliónové škody, které státu a nám daňovým poplatníkům vznikly a za to prostě jsou léta vězení, to je v pořádku. Tuším, že ten jeden vedoucí IT odboru v nějakém státním úřadě dostal asi 6 let nebo tak nějak.

A souhlasím s Tebou, že nechci mít nic společného s prasátky u koryt. Věřím tomu, že kdyby se sešlo pár Delphi programátorů se znalostí databází a dobrých analytiků, tak jim za zlomek ceny ty informační systémy naprogramujeme. Ale já s těmi zloději u koryt nechci mít nic společného. Jsem rád, že programuji ERP systém převážně pro soukromé firmy, které si své peníze musí tvrdě vydělat. Máme i zákazníky ze státní správy, ale ty jsou naštěstí dobrý, je s nimi dobrá spolupráce, ale občas se stane, že řeknou - bohužel, byli jsme nucený pořídit si předražený a daleko horší informační systém, protože někdo nahoře to tak chtěl, dostal do kapsy všimné a tak dále. Je to hnus. Nic si z toho nedělej Danieli, v České republice je to úplně stejné jako na Slovensku. A jiné to nebude. Vždy tam nahoře bude ten největší póvl, slušný člověk by tam nešel.

Takže vlastně se zase dostáváme k tomu, že v Čechách je to stejné jako na Slovensku, takže to klidně můžeme spojit  :)
Název: Re:Delphi + EET
Přispěvatel: Daniel_Andrascik 16-11-2016, 09:22:05
 ;D tak jo, ale prezidenta radsej zvolime slovaka  :-X  :o  ;D  :P

BTW: Myslim ze akurat minuly mesiac bol sud s niekym na koho tu zodpovednost za kolaps zhodili. Respektive ani nie, za to nesudia nikoho. Ak si to dobre pamatam tak ho sudili len za to ze podpisal take dodatky k zmluve s IBM ze to v podstate IBM kludne mohla takto sprasit a nedokoncit a napriek tomu mohla spokojne fakturovat. A mam taky pocit ze ho nakoniec aj tak zbavili obvinenia. Ale to uz len lovim z utrzkov mojej pamate...
Název: Re:Delphi + EET
Přispěvatel: mirus 20-11-2016, 16:55:50
Aktualizoval jsem DelphiEET viz. https://github.com/mirus77/DelphiEET
Nyní je možno propojit s projektem libeet https://github.com/mirus77/libeet
  -  (staticky zkompilovaná nadstavba nad xmlsec,libxml2,openssl do jedné dll knihovny se závislostí na MS Visual C++ 2013 Runtime soubor MSVCR120.DLL)
V komponentě EETSigner přibyly dvě funkce MakeBKP a MakePKP (přemístěno generování těchto hodnot přímo do EETSigneru).
Přidán ErrorHandler pro odchytávání chyb v libeet, xmlsec, libxml2, openssl apod.

V DelphiEET jsem upravil komponentu EETSigner. Lze ji kompilovat s původním použitím libxml2,xmlsec,openssl atd. anebo s použitím knihovny libeetsigner.dll, jejích zdroje jsou v druhém jmenovaném projektu.
Zkompilované libeetsigner.dll pro 32 bit i pro 64 bit je ve složkách bin a bin64 u projektu Delphi EET. Wrapper u_libeet.pas také.

Knihovna libeetsigner.dll při podepisování znovu generuje Soap:Envelope, Soap:Header, Soap:Body (původní odmaže). Lze poslat pro podesání třeba jen xml s slementem Trzba. Soap obálka se vytvoří a xml element Trzba se vloží do těla SOAP:Body a request se podepíše. V response je kompletní Soap odpověď.
libeetsigner.dll používá buď jednoho defaultního manažéra klíčů (není třeba vytvářet instanci manažéra klíčů) pro uchovávání klíčů nebo je možné mu podsunout svoji vlastní vytvořenou instanci manažéra klíčů.

libeet je programováno v Céčku. Nejsem kovaný céčkař (programoval jsem v céčku zase po 20 letech), tak kdybych nedodržoval nějaké zásadní zvyklosti v Céčku , tak mne prosím nekamenujte. Pečlivě jsem to ladil, tak snad to bude k užitku. Osobně tuto knihovnu budu v ostrém provozu používat.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 21-11-2016, 08:12:47
libeet je programováno v Céčku. Nejsem kovaný céčkař (programoval jsem v céčku zase po 20 letech), tak kdybych nedodržoval nějaké zásadní zvyklosti v Céčku , tak mne prosím nekamenujte. Pečlivě jsem to ladil, tak snad to bude k užitku. Osobně tuto knihovnu budu v ostrém provozu používat.

No, já osobně si myslím, že Tě nikdo kamenovat nemá právo. Osobně jsem se na Tvůj projekt díval a podle mě zbytečně dáváš svojí práci druhým zadarmo. Prohlédl jsem si Tvůj projekt a v podstatě jsi postupoval dost podobně jako jsme implementovali projekt EET u nás ve firmě, kde jsme to vlastními silami zanalyzovali a naprogramovali a stálo nás to dost peněz ať už analytické nebo programátorské práce. Takže podle mě jsi fakt dobrý programátor, akorát jednu věc bych Ti poradil - nedávej svojí práci zadarmo. Takhle to neschopní programátoři od Tebe okopírují, Tvojí práci budou vydávat za svojí a ještě na tom vydělají peníze a Tobě nedají ani korunu. To je můj názor. Oceňuji Tvojí práci, oceňuji to, že to dáváš zadarmo, ale nechápu to a radím Ti - nedělej to, nech si za to zaplatit.

Svého času jsem také poskytnul projekt zadarmo. Okopírovalo to desítky lidí a stále mi psali kvůli banalitám, přenášeli na mě svojí zodpovědnost, ať tam ladím chyby, nebyli schopný si poradit s maličkostmi, které by si mohli doprogramovat sami. Prostě a sprostě to okopírovali, zadarmo a ještě si mysleli, že jim budu nadále dělat technickou podporu a řešit jejich chyby. Pak jsem zjistil, že ještě někteří mojí práci druhým prodávali, mně samozřejmě nedali ani korunu a ještě po mně chtěli, abych ladil dále chyby a doprogramovával tam jejich požadavky.

Od té doby jsem už nikdy nic zadarmo nenaprogramoval a je mi daleko lépe.

Takže podle mého názoru Ty jsi odvedl skvělou práci, naprogramoval jsi kompletně napojení na EET a poskytnul jsi to zbytečně zadarmo. Radím Ti - za takovou dobrou práci si určitě nech příště zaplatit a neposkytuj druhým nic zbytečně zadarmo, aby se na Tvé práci někdo přiživil.

Jinak u nás ve firmě byla situace ještě složitější, protože naši zákazníci pokrývají celou tu škálu vykazování tržeb - takže tam byli i ty, co vykazují použité zboží, následné čerpání a další tyhle výmysly. Takže u nás byla jedna věc to naprogramovat, ale předtím se udělala dost složitá analýza a na to by samozřejmě programátor nestačil, to musel udělat analytik se znalostí daní, legislativy a ten to bude i nadále sledovat, protože podle mě časem to zase celé překopají, jak jsme zvyklý. Teď jsem se dozvěděl, že zase překopali normalizované výkazy, takže podle mě takhle budou ladit EET - během roku to několikrát změní, legislativu a podle mě i strukturu XML a další.

V každém případě Tě chválím, projekt jsem viděl a odvedl jsi skvělou práci ! Jenom Ti ještě jednou radím - nedělej to zadarmo  :)
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 21-11-2016, 09:49:21
Já s tebou Marku tak úplně nesouhlasím. Podle mne je skvělé, že někdo uvolnit svůj kód jako opensource, protože hodně lidí s malým SW prostě nemá na to (kapacity, sílu) to věc implementovat od začátku a tak by jejich systém umřel.

Pro autora to může naopak znamenat nějaké zakázky, protože tak to prostě chodí. Člověk ukáže, že něčemu rozumí a tak se na něj lidi obratí v budoucnu nebo přímo s implementací EET. Osobně používám pár open source knihoven (ale i komerčních) a na oplátku v nich sem opravím nějaký problém nebo uvolním sám něco (případně napíši nějaký článek).

Moc díky.
Název: Re:Delphi + EET
Přispěvatel: Stanislav Hruška 21-11-2016, 11:36:46
Marek mal na mysli hlavne tých, čo to zneužívajú. Takzvané vyžírky.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 21-11-2016, 12:47:00
Marek mal na mysli hlavne tých, čo to zneužívajú. Takzvané vyžírky.

Je to tak, jak píše Stano.

Radkův názor respektuji a proti open source až na pár věcí nic nemám.

Na věci kolem EET jsem ale docela pes. Mluvím ze zkušenosti událostí posledních měsíců, kdy u nás ve firmě víme, jak pracovala ohledně EET konkurence, jak často doslova ukradla cizí kód, případně děsivým způsobem splácala, draze prodává a zneužívá těch podnikatelů, kteří nevědí, která ohledně EET bije. Prostě levně udělali, draze prodali.

Také vím, jak se u nás ve firmě tomu opravdu věnoval velký prostor, od analýzy, naprogramování, školení a následně bude i podpora v ostrém provozu samozřejmě. Prostě jsem asi z jiné planety, ale já si pořád programování představuji jako poctivou práci, která je sice náročná, ale zase dobře placená a pro toho, koho to baví, je to podle mě skvělá práce. A prostě se mi nelíbí, k čemu to dnes spěje, jak se dnes programuje. V tom je oproti minulosti opravdu rozdíl. A velký.

Kéž by to řešení od uživatele mirus (které je určitě opravdu skvělé), posloužilo těm, jak píše Radek - malým - bohužel si ale nejsem tím docela jistý.

Berte to jenom jako můj názor. Já samozřejmě svoje řešení EET uvolnit nemohu (a ani nechci), jsem komerční programátor, živí mě to a navíc EET je majetkem firmy, pro kterou jsem to programoval. Jsem ve fázi, že zkouším pro Radka napsat článek o EET, ale přijde mi ta problematika tak děsně široká, že se mi to zatím nedaří dopsat. Rád v jednotlivých částech poradím tady na diskuzi.

Prostě mi přijde divné, že někdo skvělé řešení zveřejní jen tak. Ale to je prostě a jenom věc autora - tedy uživatele mirus, jak se svým dílem naloží. Já mu jenom radil, aby si za svojí práci nechal zaplatit. Když vidím, co si za EET nechají zaplatit firmy kolem mě, které to jednoznačně využili a zneužili ke svému obohacení. Naše firma to primárně implementuje pro své již četné zákazníky v rámci legislativní podpory a jenom pár nových nalákali naši obchoďáci a ceny jsou proti některé konkurenci opravdu směšné.

Takže to je moje troška do mlýna.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 21-11-2016, 13:07:28
Na ten článek se pořád těším ;-)
Název: Re:Delphi + EET
Přispěvatel: oxo 21-11-2016, 13:27:45
Mirusi, jen si dej dokupy info o licenci. Máš tam všehochuť souborů třetích stran ;)
Název: Re:Delphi + EET
Přispěvatel: Stanislav Hruška 21-11-2016, 14:42:35
Citace
Mirusi, jen si dej dokupy info o licenci.
Vyžírkovia sa na to vykašľu. A on sa nimi súdiť nebude :)
Název: Re:Delphi + EET
Přispěvatel: mirus 21-11-2016, 21:06:48
To: Radek Červenka - tak nějak to bylo také myšleno. I něco jako reference.
To: Marek Wejda - Díky za hodnocení. Také souhlasím s tím zneužitím vyžírků hlavně na téma EET atd. Pro mne to konkurence není, nemám s kým bojovat. Možná jsem vás znevýhodnil. Sorry.
To: Oxo - licenci jsem poladil. Snad už to bude srozumitelné. Je pravda, že jsem to sfouknul horkou jehlou na rychlo ty licence.

Na jednu stranu jsem se chtěl trošku předvést. Na druhou stranu chápu Marka. Jistým způsobem to byl i protest na cenu ElDos komponent (i když jsou to určitě dobré komponenty a nemám je) a že to jde i bez ElDosu. Ještě se naučit podepsat a ověřit PDF bez .NETu a Javy a budou úplně mimo můj zájem.
Druhý projekt "libeet" vznikl na zeštíhlení počtů knihoven u aplikace pro EET, také raději používám nativní delphi komponenty.
Název: Re:Delphi + EET
Přispěvatel: pepak 22-11-2016, 07:30:43
No, já osobně si myslím, že Tě nikdo kamenovat nemá právo. [...] V každém případě Tě chválím, projekt jsem viděl a odvedl jsi skvělou práci !
Naprosto souhlasím.

Prohlédl jsem si Tvůj projekt a v podstatě jsi postupoval dost podobně jako jsme implementovali projekt EET u nás ve firmě, kde jsme to vlastními silami zanalyzovali a naprogramovali a stálo nás to dost peněz ať už analytické nebo programátorské práce. Takže podle mě jsi fakt dobrý programátor, akorát jednu věc bych Ti poradil - nedávej svojí práci zadarmo. Takhle to neschopní programátoři od Tebe okopírují, Tvojí práci budou vydávat za svojí a ještě na tom vydělají peníze a Tobě nedají ani korunu. To je můj názor. Oceňuji Tvojí práci, oceňuji to, že to dáváš zadarmo, ale nechápu to a radím Ti - nedělej to, nech si za to zaplatit. [...] poskytnul jsi to zbytečně zadarmo. Radím Ti - za takovou dobrou práci si určitě nech příště zaplatit a neposkytuj druhým nic zbytečně zadarmo, aby se na Tvé práci někdo přiživil.
Tohle mi vysloveně připadá jako "Ano, udělal jsi to hezky, ale kazíš nám tím byznys, tak s tím prosím přestaň".
Název: Re:Delphi + EET
Přispěvatel: pepak 22-11-2016, 07:31:41
Marek mal na mysli hlavne tých, čo to zneužívajú. Takzvané vyžírky.
Bohužel, těm nedokážeš zabránit. Jakmile zabráníš vyžírkům, postihneš současně i legitimní uživatele.
Název: Re:Delphi + EET
Přispěvatel: pepak 22-11-2016, 07:40:33
To: Oxo - licenci jsem poladil. Snad už to bude srozumitelné. Je pravda, že jsem to sfouknul horkou jehlou na rychlo ty licence.
Pokud jde o licence, vidím tam dva problémy:

1) Primárně nejde ani tak o to, pod jakou licencí ten kód poskytuješ ty, ale o to, abys kód jiných autorů využíval v souladu s jejich licencí. LibXml používá MIT, totéž LibXslt, LibXmlSec. Synapse používá vlastní licenci velmi blízkou MIT. OpenSSL je vlastní licence blízká Apache. SZUtils používá MPL.

2) Nicméně když už řešíš i licenci DelphiEET, tak IMHO, tím že jsi z toho udělal LGPL, tak jsi to celé dost zazdil. LGPL dovoluje rozumné použití pouze ve variantě, že vezmu tvoje DLL a napojím se na něj, ale nedá se rozumně používat tak, že vezmu tvůj zdroják (protože typicky nemohu celou svoji aplikaci uvolnit jako GPL, i kdybych stokrát chtěl, protože mi to nedovolí používané third-party komponenty). Pokud chceš ochránit svoje zájmy a současně umožnit používání, tak je IMHO mnohem vhodnější třeba ta MPL. Ještě lepší by bylo nechat to na původní MIT, ale OK, třeba ti neposkytuje potřebnou ochranu. LGPL je ale pro komponentu zcela nevhodná.

Citace
Jistým způsobem to byl i protest na cenu ElDos komponent (i když jsou to určitě dobré komponenty a nemám je) a že to jde i bez ElDosu. Ještě se naučit podepsat a ověřit PDF bez .NETu a Javy a budou úplně mimo můj zájem.
Jsem zvědav, kam se dostaneš. Mě se podařilo udělat podpis, ale používám na to Gnostice, což není výrazné cenové zlepšení proti ElDosu, a navíc jim nefunguje současně podpis a přílohy, takže je to nepoužitelné.
Název: Re:Delphi + EET
Přispěvatel: pf1957 22-11-2016, 08:18:46
Tohle mi vysloveně připadá jako "Ano, udělal jsi to hezky, ale kazíš nám tím byznys, tak s tím prosím přestaň".
8)
Název: Re:Delphi + EET
Přispěvatel: pf1957 22-11-2016, 08:26:39
2) ... LGPL, tak jsi to celé dost zazdil. LGPL dovoluje rozumné použití pouze ve variantě, že vezmu tvoje DLL a napojím se na něj
Nechapu, co je na tom u knihovny spatne?

Potrebuju EET, najdu DLL, zjistim jak se vola a pouzivam. Kdyz mi nevyhovuje a je to OSS, tak se muzu stat contributorem a vlastnosti rozsirovat, chyby opravovat etc..., zase k uzitku vsech.

A vsichni to pouzivaji pod LGPL a nemohou legalne vzit cizi zdrojovky, neco k nim pripsat a strcit to do svych proprietarnich SW a parazitovat tak na praci druhych, jak zminoval Marek.

A pokud nejake firme zalezi na reputaci, kterou budovala treba desitky let a chce delat business v oborech, kde se na to da, tak si nikdy nic takoveho nedovoli, takze to zbyde na nejake obskurni firmicky...

Eventualne muzu udelat double licencing a prodavat i komercni licenci, pokud nejsem fanatickym stoupencem, ze veskery soft ma byt zadarmo
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 22-11-2016, 08:48:42
Jistým způsobem to byl i protest na cenu ElDos komponent (i když jsou to určitě dobré komponenty a nemám je) a že to jde i bez ElDosu.

Tady nemám dalšího komentáře, Tvoje řešení obdivuji právě proto, že mi to připomíná to naše. Oprostím se teď od toho, že nesouhlasím s tím, že svoje řešení dáváš zadarmo - to je prostě Tvoje věc, takže dále to už komentovat nebudu, jen jsem se snažil poradit a nebyl to konkurenční boj, jak si někteří tady myslí, ale nedivím se tomu, svádí to opravdu k tomu, že jsem to tak myslel. Je pravda, že na poli ERP systémů v České republice je ostrý konkurenční boj (a nejenom v ČR), ale naše firma rozhodně nemá o zákazníky nouzi a EET nám rozhodně příliš peněz nevydělalo, naopak jsme se nemohli věnovat teď lukrativnějším věcem (například půjčovny, napojení dalších e-shopů a další), ale své zákazníky si hýčkáme, takže legislativní změny mají zdarma v rámci podpory. Takže většina našich zákazníků za EET vlastně nezaplatila ani korunu, tak je to ale v pořádku, změny v legislativě jdou na naše bedra. Takže to opravdu nebylo o konkurenci, alespoň ne v případě EET. Navíc jsem programátor a konkurenční boj mezi ERP systémy mě vlastně nemusí zajímat. Celá pravda je taková, že prostě nechápu, proč to dáváš zadarmo a já bych to neudělal - je to ale jen můj pohled a názor.

Vrátím se ale k Tvému řešení - je super a na tom trvám. Byl jsem tady před časem kamenován, když jsem prozradil ideu našeho vývoje - být maximálně samostatný. Proto prostě u nás se v minulosti věnoval opravdu velký čas tomu naprogramovat maximum vlastních komponent, nebýt závislý na třetích stranách. V tom jsou Delphi úžasné, že když opravdu chceš, v podstatě naprogramuješ v nich úplně všechno - chce to jenom mít čas a schopné lidi.

Takže když milý uživateli mirus vidím Tvoje řešení EET, srdce zajásá :-) Jdeš dobrou cestou. Když jsem před časem dostal za úkol samotné programování EET, tak jsem nejprve zjišťoval alternativy. Napojení máme už na všechno možné, ale díky EET jsem se alespoň naučil spoustu nových věcí, protože tohle napojení bylo trochu jiné než komunikace s dalšími oblastmi státní správy. A bylo super, že jsme našli opravdu dobré řešení s pomocí kvalitních knihoven, které zároveň neporušilo naší ideu být co nejnezávislejší. Já prostě nerad platím za něco, co je zbytečné. Delphi je velice kvalitní vývojový nástroj a rád za něj tvrdě zaplatím. Pak už to je ale o mých schopnostech. To vývojové prostředí mi dává svobodu v něm v podstatě vytvořit úplně všechno a nechce se mi tím pádem brát třetího do party, když to řeknu natvrdo. Ale beru i druhý názor - ne každý má čas a schopné lidi, ale má peníze - tak si samozřejmě raději koupí řešení třetí strany.

Takže naposledy a znovu - řešení od uživatele mirus je skvělé, chválím ho, neznám uživatele mirus osobně, nikdy jsem s ním nespolupracoval, ale když se podívám do jeho kódu, jsem si jistý, že je to schopný programátor. Na druhou stranu ale znovu opakuji - nechápu uživatele mirus, že své řešení dal zadarmo. Ale opět to berte jenom jako můj názor a nechci tím vyvolat nějakou ostrou diskuzi. Každý si přeci se svým dílem může naložit tak, jak chce. Ono i ten vysmívaný Microsoft - charitu nedělá ani on. Pokud něco poskytne zadarmo, má to dost dobře promyšlené, proč to tak dělá. Stejně tak Embarcadero a další. To je podle mě normální. Takže to ukončím - v každém případě uživateli mirus náleží pochvala za tvrdou práci na jeho řešní EET bez ohledu na to další, na co můžeme mít jiný názor.

Jenom to trochu odlehčím - teď tady se s vámi všemi sázím o to, že celý koncept EET v následujících letech tuto diskuze nabobtná tak asi 100 krát. Jak pány ze státní správy znám, tak se dočkáme změny úplně všeho. Takže si hlavně jednotlivé části vašeho řešení EET dobře zakomentujte, budete to v budoucnu potřebovat :-) Kéž bych se mýlil, ale obávám se, že ne.
Název: Re:Delphi + EET
Přispěvatel: pepak 22-11-2016, 09:48:25
2) ... LGPL, tak jsi to celé dost zazdil. LGPL dovoluje rozumné použití pouze ve variantě, že vezmu tvoje DLL a napojím se na něj
Nechapu, co je na tom u knihovny spatne?
Pokud by DelphiEET bylo bráno jako knihovna, tak nic. Já jsem ho chápal, a licence to pochopení podporovala, jako komponentu. A ta je pod LGPL nepoužitelná.

Citace
Potrebuju EET, najdu DLL, zjistim jak se vola a pouzivam. Kdyz mi nevyhovuje a je to OSS, tak se muzu stat contributorem a vlastnosti rozsirovat, chyby opravovat etc..., zase k uzitku vsech.
K užitku všech kromě sebe, protože bez ohledu na to, zda jsem nebo nejsem contributor, LGPL zdroják do ne-GPL aplikace zařadit nejde. Jediná cesta je uvolnit celou aplikaci jako GPL, což ti ale typicky nedovolí komponenty třetích stran.

Citace
Eventualne muzu udelat double licencing a prodavat i komercni licenci, pokud nejsem fanatickym stoupencem, ze veskery soft ma byt zadarmo
To by zrovna u DelphiEET byla cesta, ale tato možnost tu není. V současné době si mohu vybrat z následujících legálních možností:
a) Smířit se s LGPL. IMHO v řadě případů nemožné.
b) Používat starší verzi pod MIT.
c) Inspirovat se v DelphiEET, ale napsat si totéž vlastním kódem.
Za sebe volím b+c.
Název: Re:Delphi + EET
Přispěvatel: pepak 22-11-2016, 09:50:52
BTW., zpátky k EET jako takovému:

1) Oceňuju, že to relativně funguje. Když si to srovnám s dřívějšími IT projekty, se kterými jsem musel spolupracovat, tak je to paráda.

2) Děsí mě, že týden před ostrým startem stále ještě nemám odpověď na otázku, jestli je nebo není požadováno, aby mezi hlášenými částkami byl nějaký vztah (třeba že Celkem = Základ0 + Daň0 + Základ1 + Daň1 + ...). Stále to čeká na odpověď oddělení pro metodiku. Chudáci ti, kdo spadají do první fáze.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 22-11-2016, 10:29:40
BTW., zpátky k EET jako takovému:

1) Oceňuju, že to relativně funguje. Když si to srovnám s dřívějšími IT projekty, se kterými jsem musel spolupracovat, tak je to paráda.

No kdyz to stalo zatim 388M Kč (a další roky roční provoz 180M) https://twitter.com/hlidacsmluv/status/800344614024675328 (https://twitter.com/hlidacsmluv/status/800344614024675328) tak by to mohlo snad trochu fungovat. Ale nazývat to paráda je trochu chucpe. a https://pbs.twimg.com/media/CxuDbxNWIAEgrqs.jpg:large (https://pbs.twimg.com/media/CxuDbxNWIAEgrqs.jpg:large)
Název: Re:Delphi + EET
Přispěvatel: pepak 22-11-2016, 10:39:23
No kdyz to stalo zatim 388M Kč (a další roky roční provoz 180M)[https://twitter.com/hlidacsmluv/status/800344614024675328 (https://twitter.com/hlidacsmluv/status/800344614024675328) tak by to mohlo snad trochu fungovat.
Mohlo, ale moje zkušenost je odlišná, i u dražších projektů.

Citace
Ale nazývat to paráda je trochu chucpe.
Proč? Systém běží, testovací prostředí funguje, dokumentace existuje a je i víceméně v souladu s realitou, dokonce to všechno bylo připravené celé měsíce před spuštěním (zvyklý jsem spíš na dny)...

Jiná věc je, že je celé EET z principu blbost a že to samozřejmě stojí víc, než bylo deklarováno, ale čistě z technického pohledu to ještě dopadlo dobře.
Název: Re:Delphi + EET
Přispěvatel: mirus 22-11-2016, 11:05:14
Mým účelem není nějaká blokace použití toho co jsem napsal. Je mi jasné,že samotná GPL nebude ta správná, pak jsem myslel, že LGPL je pro knihovnu použitelnější.
Původně jsem to chtěl pod MIT licencí (myslel jsem, že se to musí ještě užití nějak dospecifikovat a anglicky to nezvládnu). Nejsem moc zdatný angličtinář, tak se v tom plácám.
Teď pročítám i tu OpenSSL licenci. Tam bych musel zřejme při binární distribuci zmínit tu jejich zmíňku o autorovi OpenSSL. Ve zdrojácích knihovny je pouze použití OpenSSL bez modifikace.
Přinejhorším se to dá i zkompilovat s použitím DLL openssl knihoven místo přímo staticky, ale to už by to nemělo to kouzlo.

Oxo mě komentářem trošku vyvedl z míry, tak jsem to hodil pod licenci knihoven, která by měl umožnit použití kódu v komerčních projektech.

Pokud se v DelphiEET použije s knihovnou libEET, tak synapse a SZUtils nejsou potřeba. Potřebné věci se řeší v Céčku SHA1(OpenSSL) a Base16Encode (časem jsem zjistil, že se jední o jednoduchý StrToHex m.j.)

Nemám problém to uvolnit k plnému užití. Poraďte prosím jakou licenci tam dát? Původně jsem myslel, že by MIT licence plně vyhovovala.
Název: Re:Delphi + EET
Přispěvatel: pf1957 22-11-2016, 11:35:57
K užitku všech kromě sebe, protože bez ohledu na to, zda jsem nebo nejsem contributor, LGPL zdroják do ne-GPL aplikace zařadit nejde.
Proc krome me? Ja to prece budu pouzivat taky jako vsichni jen jako knihovnu - mj. proto, abych overil, ze to bez zdrojaku pouzivat lze a pokud to pouzivat lze, tak prece nemam duvod to pouzivat jinak  :o
Název: Re:Delphi + EET
Přispěvatel: pepak 22-11-2016, 11:47:25
Mým účelem není nějaká blokace použití toho co jsem napsal. Je mi jasné,že samotná GPL nebude ta správná, pak jsem myslel, že LGPL je pro knihovnu použitelnější.
LGPL je použitelná pro knihovnu, která bude distribuována a používána pouze jako DLL. Jinak je to stejný paskvil jako GPL :-(

Citace
Původně jsem to chtěl pod MIT licencí (myslel jsem, že se to musí ještě užití nějak dospecifikovat a anglicky to nezvládnu). Nejsem moc zdatný angličtinář, tak se v tom plácám.
IMHO by MIT úplně stačilo.

Citace
Teď pročítám i tu OpenSSL licenci. Tam bych musel zřejme při binární distribuci zmínit tu jejich zmíňku o autorovi OpenSSL.
Což ji činí nekompatibilní s GPL i LGPL!!

Citace
Nemám problém to uvolnit k plnému užití. Poraďte prosím jakou licenci tam dát? Původně jsem myslel, že by MIT licence plně vyhovovala.
Já pro své projekty používám BSD, která je téměř identická s MIT. Jak a proč jsem se tak rozhodl jsem popsal v článcích https://www.pepak.net/programovani/free-licenci-ale-kterou/ (https://www.pepak.net/programovani/free-licenci-ale-kterou/) a https://www.pepak.net/programovani/free-licenci-ale-kterou-cast-2/ (https://www.pepak.net/programovani/free-licenci-ale-kterou-cast-2/). Ve stručnosti - právě proto, že chci, aby programátoři moji tvorbu mohli použít a nebyli svazování nesmyslnými omezeními v duchu filozofie "však já ti tu svobodu vnutím, i kdyby tě to mělo zabít".
Název: Re:Delphi + EET
Přispěvatel: oxo 22-11-2016, 16:24:40
Oxo mě komentářem trošku vyvedl z míry, tak jsem to hodil pod licenci knihoven, která by měl umožnit použití kódu v komerčních projektech.

To se omlouvám - neměl jsem to v plánu. Licenci jsi měl OK, ale info o ní ne:

Mirusi, jen si dej dokupy info o licenci. Máš tam všehochuť souborů třetích stran ;)

Stačilo by k původnímu textu licence připsat: "Knihovna používá tyto a tyto kódy, které jsou pod těmito a těmito licencemi a týká se to těchto a těchto souborů. Ostatní soubory jsou mým výtvorem a platí na ně výše uvedená licence."

Na licenci jako takové nic špatného není a nebylo, jen to chtělo přidat trochu transparentnosti o kódu třetích stran.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 22-11-2016, 22:07:04
Pro zajímavost, třeba to někomu pomůže - http://hlidaceet.cz/ (http://hlidaceet.cz/) , měří dostupnost API pro EET. Jsem zvědav za jak dlouho dostane BAN od MFCR.
Název: Re:Delphi + EET
Přispěvatel: Vasek 23-11-2016, 13:52:38
Dobrý den, o něco dříve se tu řešil certifikát potvrzovací datové zprávy ze serveru EET. Mohl bych poprosit někoho, kdo má údaje pro přístup do produkčního prostředí, aby tento certifikát z odpovědi vyseparoval, popř. stačí vložit XML potvrzovací datové zprávy. Zajímalo by mě jakým certifikátem jsou ty odpovědi podepsané. Nemám certifikát s přístupem do prod. prostředí a proto nedokáži toto vyseparovat z odpovědi. Děkuji
Název: Re:Delphi + EET
Přispěvatel: mirus 23-11-2016, 13:59:44
https://github.com/mirus77/DelphiEET/raw/master/cert/trusted_CA_prod.der - CN = I.CA Qualified 2 CA/RSA 02/2016
https://github.com/mirus77/DelphiEET/raw/master/cert/trusted_CA_prod_ROOT.der -  I.CA Root CA/RSA - Vydavatel přechozího
Vše z www.ica.cz.

Název: Re:Delphi + EET
Přispěvatel: Vasek 23-11-2016, 14:27:36
Dobrý den, to jsou kořenové certifikáty ne? Mě jde o konkrétní certifikát, kterým je ta zpráva podepsána.  Něco jako http://q.ica.cz/cgi-bin/crt_qpub.cgi?page=Cert&reqId=&fromSn=&toSn=&fromNotBefore=8.6.2016&toNotBefore=8.6.2016&fromNotAfter=&toNotAfter=&cn=&email=epodpora@fs.mfcr.cz&organization=&organizationUnit=&location=&stateOrProvince=&action=search (http://q.ica.cz/cgi-bin/crt_qpub.cgi?page=Cert&reqId=&fromSn=&toSn=&fromNotBefore=8.6.2016&toNotBefore=8.6.2016&fromNotAfter=&toNotAfter=&cn=&email=epodpora@fs.mfcr.cz&organization=&organizationUnit=&location=&stateOrProvince=&action=search) certifikát, kterým jsou podepsány zprávy z playgroundu.

Z produkčního prostředí by měli být potvrzovací datové zprávy pravděpodobně podepsány jedním z http://q.ica.cz/cgi-bin/crt_qpub.cgi?page=Cert&action=search&fromSn=&fromNotBefore=25.10.2016&fromNotAfter=&cn=&email=epodpora%40fs.mfcr.cz&organization=&search=Hledat (http://q.ica.cz/cgi-bin/crt_qpub.cgi?page=Cert&action=search&fromSn=&fromNotBefore=25.10.2016&fromNotAfter=&cn=&email=epodpora%40fs.mfcr.cz&organization=&search=Hledat) těchto certifikátů. Podle cesty certifikátů by to sedělo. Ale potřeboval bych prověřit, který z těchto certifikátů to je, popř. jestli oba.

Děkuji
Název: Re:Delphi + EET
Přispěvatel: mirus 23-11-2016, 14:38:34
http://q.ica.cz/cgi-bin/crt_qpub.cgi?page=Cert&action=search&fromSn=0x00aa83c2&fromNotBefore=&fromNotAfter=&cn=&email=epodpora%40fs.mfcr.cz&organization=&search=Hledat
Název: Re:Delphi + EET
Přispěvatel: karel.kral 24-11-2016, 12:35:59
Já si taky myslím, že na rozdíl od jiných státních projektů je tento docela dobře připravený. Vše jede, jediné výhrady mám vůči podpoře, která je opravdu otřesná. Ale technicky je vše ok.

No kdyz to stalo zatim 388M Kč (a další roky roční provoz 180M)[https://twitter.com/hlidacsmluv/status/800344614024675328 (https://twitter.com/hlidacsmluv/status/800344614024675328) tak by to mohlo snad trochu fungovat.
Mohlo, ale moje zkušenost je odlišná, i u dražších projektů.

Citace
Ale nazývat to paráda je trochu chucpe.
Proč? Systém běží, testovací prostředí funguje, dokumentace existuje a je i víceméně v souladu s realitou, dokonce to všechno bylo připravené celé měsíce před spuštěním (zvyklý jsem spíš na dny)...

Jiná věc je, že je celé EET z principu blbost a že to samozřejmě stojí víc, než bylo deklarováno, ale čistě z technického pohledu to ještě dopadlo dobře.
Název: Re:Delphi + EET
Přispěvatel: Sender 24-11-2016, 16:01:58
Provoz EET zaplatí zase obyčejný lidi.
Název: Re:Delphi + EET
Přispěvatel: oxo 24-11-2016, 18:34:55
Provoz EET zaplatí zase obyčejný lidi.

AFAIK ti platí všechno.

I když znám osobně jednoho člověka absolutně nezávislého na systému. Když zrovna chce, tak pracuje (na černo), neplatí sociální, nemá žádný majetek, nikdo si na něm nic nevezme, ani úředník... Ale vypadá šťastně a spokojeně :) Prostě nějak vyskočil z matrixu :)
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 24-11-2016, 21:13:41
Citace
Jistým způsobem to byl i protest na cenu ElDos komponent (i když jsou to určitě dobré komponenty a nemám je) a že to jde i bez ElDosu. Ještě se naučit podepsat a ověřit PDF bez .NETu a Javy a budou úplně mimo můj zájem.
Jsem zvědav, kam se dostaneš. Mě se podařilo udělat podpis, ale používám na to Gnostice, což není výrazné cenové zlepšení proti ElDosu, a navíc jim nefunguje současně podpis a přílohy, takže je to nepoužitelné.

Moc tomu neholduji - ale tohle asi není ono že? http://blog.synopse.info/post/2013/06/19/SynPDF-now-implements-40-bit-and-128-bit-security (http://blog.synopse.info/post/2013/06/19/SynPDF-now-implements-40-bit-and-128-bit-security)

Název: Re:Delphi + EET
Přispěvatel: pepak 25-11-2016, 20:29:37
Moc tomu neholduji - ale tohle asi není ono že? http://blog.synopse.info/post/2013/06/19/SynPDF-now-implements-40-bit-and-128-bit-security (http://blog.synopse.info/post/2013/06/19/SynPDF-now-implements-40-bit-and-128-bit-security)
Ne. To je šidítko pro neznalé, ne elektronický podpis (a už vůbec ne elektronický podpis uznávaný našimi zákony).
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 28-11-2016, 09:56:47
Napojení na EET přes proxy, jak postupovat.
Vytvořil jsem napojení na EET pomocí SOAP a Indy, aby jsme podporovali TLS 1.2 také na Windows XP SP3. Všechno funguje bez problémů, pokud je PC přímo připojeno k internetu. Ale máme pár zákazníků, kteří mají připojení na web přes proxy a tady moje napojení nefunguje. Síťové komunikace jdou celkem mimo mně, ale nemám se čeho chytnout, jak to udělat, na firmě proxy nemáme. Můžete mi poradit, jak postupovat při připojení na servery EET přes proxy?
Vygooglil jsem, že HTTPRIO.HTTPWebNode má  property Proxy, Username, Password. Stačí to vyplnit správnou adresou proxy? Máte to někdo ověřeno?
Díky za info.
Název: Re:Delphi + EET
Přispěvatel: pepak 28-11-2016, 10:33:45
Napojení na EET přes proxy, jak postupovat. [...] Vygooglil jsem, že HTTPRIO.HTTPWebNode má  property Proxy, Username, Password. Stačí to vyplnit správnou adresou proxy? Máte to někdo ověřeno?
Při použití WinInet to tak funguje, samozřejmě za předpokladu, že to podporuje i ta proxy. Jak přes Indy, to nevím.
Název: Re:Delphi + EET
Přispěvatel: < z > 28-11-2016, 19:53:14
Napojení na EET přes proxy, jak postupovat.
Vytvořil jsem napojení na EET pomocí SOAP a Indy, aby jsme podporovali TLS 1.2 také na Windows XP SP3. Všechno funguje bez problémů, pokud je PC přímo připojeno k internetu. Ale máme pár zákazníků, kteří mají připojení na web přes proxy a tady moje napojení nefunguje. Síťové komunikace jdou celkem mimo mně, ale nemám se čeho chytnout, jak to udělat, na firmě proxy nemáme. Můžete mi poradit, jak postupovat při připojení na servery EET přes proxy?
Vygooglil jsem, že HTTPRIO.HTTPWebNode má  property Proxy, Username, Password. Stačí to vyplnit správnou adresou proxy? Máte to někdo ověřeno?
Díky za info.

Vážně by mne zajímalo, kolik lidí nezná stránku google.com
http://delphi.cz/post/Komunikace-delphi-HTTP-Indy.aspx (http://delphi.cz/post/Komunikace-delphi-HTTP-Indy.aspx)
resp. dodej, co z toho nefunguje
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 28-11-2016, 20:07:27
Tak on se především ptal, jestli to má někdo ověřeno v praxi...
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 29-11-2016, 08:13:14
Díky za reakce. Jak jsem psal, síťové komunikace jdou nějak mimo mně. Kdo v tom žije, tak je to pro něho stará vesta. Já se chtěl nechat poučit. Jak to vidím, asi by mělo stačit nastavit uvedené property a mělo by to fungovat.
Až to otestuju, dám vědět.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 29-11-2016, 08:37:31
Díky za reakce. Jak jsem psal, síťové komunikace jdou nějak mimo mně. Kdo v tom žije, tak je to pro něho stará vesta. Já se chtěl nechat poučit. Jak to vidím, asi by mělo stačit nastavit uvedené property a mělo by to fungovat.
Až to otestuju, dám vědět.

Jenom prosím ještě o informaci. Z příspěvku od vás mám pocit, že Indy řešení jste zvolil kvůli lidem, co ještě používají Windows XP. Jinak já osobně bych neviděl důvod použít Indy oproti WinInet, ale samozřejmě kvůli XP asi není jiná cesta. Jenom by mě zajímalo, kolik vašich zákazníků ještě používá Windows XP ? Ani v oficiálních materiálech EET není podpora XP zmiňována, rovnou to odbyli tím, že XP nepodporuje, nemá TLS 1.1 nebo vyšší. Zajímalo by mě, jak je XP ještě v praxi rozšířený.
Název: Re:Delphi + EET
Přispěvatel: JaroB 29-11-2016, 09:01:50
Mám něco přes 5000 evidovaných uživatelů jednoho mého programu a XP používá necelých 600 lidí resp. hlásí se tak tolik strojů (s klesající tendencí) a dva mají dokonce Windows 2000.
Situace je jiná u čistě soukromých osob (mají vlastní počítač), tam jsou to maximálně jednotky procent a jiné u drobných podnikatelů se zaměstnanci, tam zhusta XP ještě jsou (prý z důvodu nákladů prozatím zůstávají) - v drtivé většině jsou XP na stolních PC. Tolik moje výzkumy.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 29-11-2016, 09:03:44
Indy (když už je máme v Delphi) jsme zvolili právě kvůli interní podpoře protokolu TLS, aby šly naše programy používat pro EET i na Windows XP. Kolik přesně našich zákazníků má XP nevím, ale odhadnu to na 10-15%. Samozřejmě to ubývá, ale nechtěli jsme nikoho odstřihnout jen kvůli starému PC, zvlášť když to v Delphi+Indy tak pěkně funguje.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 29-11-2016, 09:47:54
To JaroB a KarelHorky:

Díky moc za zajímavé info. U nás je to totiž 0 procent (alespoň tedy u těch, kteří mají aktuálně zaplacenou podporu, u uživatelů starších verzí našeho ERP možná nějací budou, ale ty neaktualizují a nevíme o nich a je pravda, že někdy nás překvapí, jak staré verze někdy používají, když se ozvou po novější verzi a stačí jim to dosud - ale proč ne, když vysloveně nepotřebují některé legislativní změny), tak mě zajímalo, jak to třeba je jinde. Je pravda, že od svého švagra vím o celkem velké firmě, kde správce IT odmítl upgrade z Windows XP. Takže tam prostě mají XP možná na desítkách počítačů. Jak řeší zabezpečení a další - opravdu nevím. Ale snad ví, co dělá. Hezký den.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 29-11-2016, 12:35:26
Taky máme u zákazníka ve firmě dost počítačů s Windows XP, zbytek má Windows 10. On v podstatě pro přechod na Windows 10 není žádný zásadní důvod, takže se obměňují, až když umřou (ty počítače, ne uživatelé...).
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 30-11-2016, 08:35:16
S úspěchem otestováno a nasazeno u zákazníka. Třeba to někomu pomůže, aby věděl, jak se dá naplnit SOAP objekt v Indy, aby použil proxy při napojení na web službu:
Kód: Delphi [Vybrat]
  1. var
  2.   xRIO: TSSLHandlerRIO;
  3.   MujEET: EET;
  4. begin
  5.   Result := False;
  6.   Log.Clear;
  7.   Log.Add('----- Začátek tvorby zprávy -----');
  8.   if not PripravaZpravy then
  9.     Exit;
  10.   xRIO := TSSLHandlerRIO.Create(nil);
  11.   xRIO.OnAfterExecute  := HTTPRIOAfterExecute;
  12.   xRIO.OnBeforeExecute := HTTPRIOBeforeExecute;
  13.   xRIO.HTTPWebNode.ConnectTimeout := fConnectTimeout;
  14.   xRIO.HTTPWebNode.SendTimeout    := fSendTimeout;
  15.   xRIO.HTTPWebNode.ReceiveTimeout := fReceiveTimeout;
  16.  
  17.   if (FProxyAdresa <> '') and FProxyPouzit then
  18.   begin
  19.     Log.Add('Zapnuto použití Proxy serveru');
  20.     Log.Add('Nastavení proxy:');
  21.     Log.Add('  adresa: '+iif(FProxyAdresa <> '',FProxyAdresa, _('není nastaveno')));
  22.     Log.Add('  port: '+iif(FProxyPort > 0,IntToStr(FProxyPort), _('není nastaveno')));
  23.     Log.Add('  uživatel: '+iif(FProxyUzivatel <> '',FProxyUzivatel, _('není nastaveno')));
  24.     Log.Add('  heslo: '+iif((FProxyHeslo <> ''),_('nastaveno podle konfigurace'),_('není nastaveno')));
  25.     if FProxyPort > 0 then
  26.       xRIO.HTTPWebNode.Proxy := Format('%s:%d',[FProxyAdresa, FProxyPort]) // 'server_ip:port'
  27.     else
  28.       xRIO.HTTPWebNode.Proxy := FProxyAdresa;
  29.     xRIO.HTTPWebNode.Username := FProxyUzivatel;
  30.     xRIO.HTTPWebNode.Password := Zakoduj(FProxyHeslo);
  31.   end;
  32.   xRIO.HTTPWebNode.OnBeforePost   := HTTPWebNodeBeforePost;
  33.  
  34.   try
  35.     try
  36.       MujEET := GetEET(False, FAdresaProstredi, xRIO);  
  37.       if Assigned(MujEET) then
  38.       begin
  39. ( atd, atd, další kód není pro proxy podstatný)
Tak jak jsou Indy napsané, tak UserName a Password se v tomto případě použijí pro autentifikaci v proxy serveru, ne pro autentifikaci ve webové službě. Ale u EET to právě vyhovuje, webová služba nevyžaduje autentifikaci.
K.
Název: dotaz na první den EET
Přispěvatel: Marek Weyda 01-12-2016, 13:02:36
Takže máme první den ostrého provozu EET. Proto se zeptám, jaký máte ohlas od svých zákazníků ? Nám najelo první den jenom minimum z nich, ale kupodivu bezproblémově, prověřoval jsem u nich logy a vše funguje, jak má, již desítky odeslaných účtenek a všechny s FIK bez problémů. Zdá se mi to až divné. Takže se zeptám, jak to probíhá u vás ? Máte nějaké problémy ?
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 01-12-2016, 13:14:10
Ne, desitky pokladen, a nikdo po mne nerve. Tak asi ok. Jinak http://hlidaceet.cz/ (http://hlidaceet.cz/) taky rika, ze je to stabilni.
Název: Re:Delphi + EET
Přispěvatel: anec 01-12-2016, 13:31:04
dnes jsem byl v jedné celostátní síti tabákových prodejen a vyjela mi účtenku bez EET.
naproti vitnamské bistro EET i s fíkem :)
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 01-12-2016, 13:33:52
dnes jsem byl v jedné celostátní síti tabákových prodejen a vyjela mi účtenku bez EET.
naproti vitnamské bistro EET i s fíkem :)

tabák není v první vlně. Jen hotely a restaurace.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 01-12-2016, 13:39:59
tabák není v první vlně. Jen hotely a restaurace.

Přesně tak, jak píše Radek. Prodejna tabáku zatím nemusí vydávat účtenky s FIK, vietnamské bistro ale ano - spadá do první vlny a ta je ode dneška. Většina našich zákazníků právě začne až příští rok v té druhé vlně. Nicméně i u těch pár, co máme v první vlně, je to fakt bez problémů, takže zatím valím oči.

Přidám také story z dneška - tady v Budějovicích jsou 2 restaurace, které má stejný majitel, stejná firma s.r.o. Do jedné jsem šel dnes já s manželkou a dcerou, do druhé kolega. Porovnali jsme účtenky a kolega měl správnou s FIK a já starou bez FIK.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 01-12-2016, 13:57:18
Právě končí doba obědů a markování meníček a nikdo nevolá, tak je to asi OK. Co volali, tak kvůli změně sazby DPH, někteří ani nevěděli, že dnes nějaká změna sazby je a divili se, na co se ten program ptá !  :)
Pak ještě dotazy k certifikátům, jestli opravdu mají být na PC nainstalovány a proč je to nechce pustit do placení, když je tam nemají ...
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 02-12-2016, 13:46:19
Kód: Delphi [Vybrat]
  1.   xRIO.HTTPWebNode.ConnectTimeout := fConnectTimeout;
  2.   xRIO.HTTPWebNode.SendTimeout    := fSendTimeout;
  3.   xRIO.HTTPWebNode.ReceiveTimeout := fReceiveTimeout;
  4.  
Jak jsem uvedl v příkladu už předtím, kromě jiného nastavuji také timeout, shodně na 2 sek do všech uvedených property. Ale při výpadku připojení na web to vyhučí na timeout mnohem později, řádově tak do 30 sek. A pokud je připojení přes proxy, tak to trvá ještě mnohem déle, až několik minut. Co se ještě musí nastavit, aby se timeout objevil po únosné době (do 10 sek)?
Nebo jde spojení zrušit nějak zvenku, třeba v obsluze timeru?
Díky za odpověď, K.
Název: Re:Delphi + EET
Přispěvatel: pepak 02-12-2016, 14:07:52
Btw., když už tu vidím ten timeout - 2 sekundy nejsou doporučená hodnota, i když se to tak často uvádí. Jsou to minimální hodnota, cokoliv menšího bude FÚ považovat za porušení povinností. V závislosti na typu provozu ale může jako nedostatečné posoudit i vyšší hodnoty!!!
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 02-12-2016, 14:53:52
Potíž je v tom, že můžu do timeoutu nastavit libovolnou hodnotu, třeba i tu minimální 2 sek, přesto se timeout dostaví po mnohem delší době, řádově 30 sek. U proxy ještě později. Vám se timeout řídí nastavenou hodnotou?
Problém je, když číšník a host čeká u kasy na účtenku, pak je každá sekunda jako týden  :)
Název: Re:Delphi + EET
Přispěvatel: rames.iii 02-12-2016, 17:13:29
Kód: Delphi [Vybrat]
  1.   xRIO.HTTPWebNode.ConnectTimeout := fConnectTimeout;
  2.   xRIO.HTTPWebNode.SendTimeout    := fSendTimeout;
  3.   xRIO.HTTPWebNode.ReceiveTimeout := fReceiveTimeout;
  4.  
Jak jsem uvedl v příkladu už předtím, kromě jiného nastavuji také timeout, shodně na 2 sek do všech uvedených property. Ale při výpadku připojení na web to vyhučí na timeout mnohem později, řádově tak do 30 sek. A pokud je připojení přes proxy, tak to trvá ještě mnohem déle, až několik minut. Co se ještě musí nastavit, aby se timeout objevil po únosné době (do 10 sek)?
Nebo jde spojení zrušit nějak zvenku, třeba v obsluze timeru?
Díky za odpověď, K.

Pokud vím, je to nějaká chyba, kterou lze obejít takto (2s jsem nezkoušel, potřeboval jsem naopak řádově minuty):
Kód: Delphi [Vybrat]
  1.   HTTPRIO1.HTTPWebNode.OnBeforePost:=configureHttpRequest;
  2.   //následující řádky už nemusí fungovat, ale hodnoty použiji v configureHttpRequest
  3.   HTTPRIO1.HTTPWebNode.ConnectTimeout:=60*1000;
  4.   HTTPRIO1.HTTPWebNode.ReceiveTimeout:=60*1000;
  5.   HTTPRIO1.HTTPWebNode.SendTimeout:=60*1000;
  6.  
kde configureHttpRequest je:
Kód: Delphi [Vybrat]
  1. procedure TForm1.configureHttpRequest(const HTTPReqResp: THTTPReqResp;
  2.   Data: Pointer);
  3. begin
  4.   //obejití chyby WinInet s timeouty
  5.   InternetSetOption(Data, INTERNET_OPTION_CONNECT_TIMEOUT,
  6.     Pointer(@HTTPReqResp.connectTimeout), SizeOf(HTTPReqResp.connectTimeout));
  7.   InternetSetOption(Data, INTERNET_OPTION_SEND_TIMEOUT,
  8.     Pointer(@HTTPReqResp.sendTimeout), SizeOf(HTTPReqResp.sendTimeout));
  9.   InternetSetOption(Data, INTERNET_OPTION_RECEIVE_TIMEOUT,
  10.     Pointer(@HTTPReqResp.receiveTimeout), SizeOf(HTTPReqResp.receiveTimeout));
  11. end;
  12.  
Název: Re:Delphi + EET
Přispěvatel: pf1957 02-12-2016, 18:30:15
Kód: Delphi [Vybrat]
  1.   xRIO.HTTPWebNode.ConnectTimeout := fConnectTimeout;
  2.   xRIO.HTTPWebNode.SendTimeout    := fSendTimeout;
  3.   xRIO.HTTPWebNode.ReceiveTimeout := fReceiveTimeout;
  4.  
Ber to s rezervou: V Delphi jsem primo s WinInet nikdy nic nedelal, vzdycky jen se Synapsi, ale s ohledem na to, jak THTTPReqResp nastavuje ty timouty tj. v metode Send
Kód: Delphi [Vybrat]
  1.     Request := HttpOpenRequest(FInetConnect, 'POST', PChar(FURLSite), nil,
  2.                                nil, nil, Flags, 0{Integer(Self)});
  3.     Check(not Assigned(Request));
  4.  
  5.     { Timeouts }
  6.     if FConnectTimeout > 0 then
  7.       Check(not InternetSetOption(Request, INTERNET_OPTION_CONNECT_TIMEOUT, Pointer(@FConnectTimeout), SizeOf(FConnectTimeout)));
  8.     if FSendTimeout > 0 then
  9.       Check(not InternetSetOption(Request, INTERNET_OPTION_SEND_TIMEOUT, Pointer(@FSendTimeout), SizeOf(FSendTimeout)));
  10.     if FReceiveTimeout > 0 then
  11.       Check(not InternetSetOption(Request, INTERNET_OPTION_RECEIVE_TIMEOUT, Pointer(@FReceiveTimeout), SizeOf(FReceiveTimeout)));
  12.  
tak je treba zjistit, ktery timeout ti vyfuci. Protoze jestli je to INTERNET_OPTION_CONNECT_TIMEOUT, tak tam ho IMHO nastavuji s krizkem po funuse tj. v dobe, kdy uz mas navazane spojeni... A INTERNET_OPTION_RECEIVE_TIMEOUT ze neni presny a bude delsi o 6 sekund viz odkaz do MSDN nize

IMHO by to InternetSetOption INTERNET_OPTION_CONNECT_TIMEOUT melo byt volano na handle FInetRoot pred volanim FInetConnect := InternetConnect viz https://msdn.microsoft.com/en-us/library/windows/desktop/aa385328(v=vs.85).aspx (https://msdn.microsoft.com/en-us/library/windows/desktop/aa385328(v=vs.85).aspx)

Zrovna tak si myslim, ze rada presunout nastavovani timeoutu do OnBeforePost nicemu nepomuze, protoze ve fragmentu vyse je ukazano, ze se stejnym zpusobem nastavuji jeste pred vyvolanim udalosti OnBeforePost a jedine, co se mezitim nastavenim TO a udalosti dela, je sestavovani hlavicek pro HTTP request...

Název: Re:Delphi + EET
Přispěvatel: Sender 02-12-2016, 21:35:27
>..... Problém je, když číšník a host čeká u kasy na účtenku, .....<
Host nečeká.Na účtenku kašle a bere kramle. :)
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 05-12-2016, 09:07:05
Díky za reakce. Asi to nechám, jak to je. OnBeforePost se v mých Delphi XE6 ve funkci THTTPReqResp.Send opravdu volá až po tom, co se timeouty již nastaví pomocí InternetSetOption, v podstatě bych znovu nastavil to samé podruhé. Navíc se dlouhé timeouty projeví jen u jednoho zákazníka, pokud má výpadek napojení na internet, ještě používá proxy, u sebe to nemůžu nasimulovat nebo nějak ladit.
V běžném provozu to jede, jako když bičem mrská ...
Název: Re:Delphi + EET
Přispěvatel: Roman K. 05-12-2016, 09:48:55
S tím "InternetSetOption" jste spadli do pastě :-) Přes tohle se timeout reálně nastavit nedá, byl jsem docela zvědav jestli se to tu objeví. Jediný možný přístup je rozběhnout odeslání tržby ve vedlejším vlákně a to po požadované době utnout (použít waitforsingleobject).
Název: Re:Delphi + EET
Přispěvatel: Roman K. 05-12-2016, 09:55:33
Mám dotaz na ověřování účtenek - na stránkách pro online ověření účtenky se vyžaduje zadání "Datum a čas přijetí tržby". Vpadá to však že ve skutečnosti je potřeba zadat datum a čas přijetí tržby serverem finanční správy, kterýžto údaj se na účtence neuvádí. Navíc zákon praví, že na účtence se uvádí "datum a čas přijetí tržby nebo vystavení účtenky, pokud je vystavena dříve", takže ani ten datumočas přijetí tržby na účtence nemusí být (pokud je účtenka vystavena dříve). Řešíte to nějak?
Název: Re:Delphi + EET
Přispěvatel: rames.iii 05-12-2016, 10:16:18
Podle mě je to DatumČas přijetí tržby, tedy to, co se posílá a kóduje do PKP, BKP. Tedy co jsem zkoušel ověřovat, tak takto funguje (a to čas tržby a čas přijetí se kvůli špatně nastaveným lokálním hodinám liší i o minuty). Čas tržby pak na účtenku tisku. Čas je nutné zadat aktuálně platný, tedy SEČ, v létě SEČL.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 05-12-2016, 10:28:34
Podle mě je to DatumČas přijetí tržby, tedy to, co se posílá a kóduje do PKP, BKP. Tedy co jsem zkoušel ověřovat, tak takto funguje (a to čas tržby a čas přijetí se kvůli špatně nastaveným lokálním hodinám liší i o minuty). Čas tržby pak na účtenku tisku. Čas je nutné zadat aktuálně platný, tedy SEČ, v létě SEČL.
Díky za info. Poslal jsem pro jistotu dotaz na mfcr přes kontaktní formulář. Hlavně mně vadí, že ten čas přijetí tržby vůbec podle zákona nemusí být (v  některých případech) uveden a na té ověřovací stránce je to povinný údaj. Pokud u GFŘ někdo dělal analýzu procesu tak bych mu odebral prémie :-)
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 05-12-2016, 10:29:57
Tisknu oba časy, s přesností na sekundy, někdy jsou shodné, někdy ne. Lokální čas na PC se může lišit od času v systému EET, s tím se nedá nic dělat. Na změnu času na PC jsou potřeba práva Administrátora... Ověření účtenky je složité jako heslo do Pentagonu, myslel jsem, že zadám FIK a je to hotovo. No nic, třeba v další verzi to bude lepší  ;)
Název: Re:Delphi + EET
Přispěvatel: Roman K. 05-12-2016, 13:39:49
tak jak jsem zjistil, možná jsem pořádně nepřečetl a nepochopil
http://www.etrzby.cz/assets/cs/prilohy/Popis_polozek_datove_zpravy_v3.1.pdf

kde se píše cituji:

Citace
10. DATUM A ČAS PŘIJETÍ TRŽBY
Jedná se o datum a čas přijetí tržby nebo vystavení účtenky, pokud je vystavena dříve (viz §19 odst. 1 písm. e) ZoET). ......

kde se vyskytuje zajímavá definice polokruhem... :-)
Název: Re:Delphi + EET
Přispěvatel: anec 06-12-2016, 17:11:03
někdo tady dříve řešil jestli u plátců dph součet jednotlivých částek
zakl_nepodl_dph +  zakl_dan1 + dan1 .... se musí rovnat elementu  celk_trzba

mám zaklad daně 101,-
daň 21,21
zaokrouhlední -0,21
celkem tržba 122,-

do celk_trzba jde logickz 122,- 
do zakl_dan1 dám 101
do dan1 dám 21.21
ale dávat někam to zaokrouhlení? nikde v popisech EET jsem nic nenašel,
řešíte to nějak?
díky
Název: Re:Delphi + EET
Přispěvatel: rames.iii 06-12-2016, 19:31:15
Ono to podle mnohých vyplývá ze zákona o DPH. Zaokrouhlení je předmětem DPH, tudíž tento problém není. Ale co jsem viděl všemožné účtenky, tak jen málo SW to do DPH dává, převažuje účtování jako finanční rozdíl. Jeden auditovaný zákazník přesně na tohle také narazil a rád by měl zaokrouhlení v DPH. Ale upřímně to asi dělat nebudeme, moc práce;)
Název: Re:Delphi + EET
Přispěvatel: pepak 06-12-2016, 21:45:57
někdo tady dříve řešil jestli u plátců dph součet jednotlivých částek
zakl_nepodl_dph +  zakl_dan1 + dan1 .... se musí rovnat elementu  celk_trzba
Podle vyjádření GFŘ nemusí. Jejich zdůvodnění jsem nepochopil, protože podle mě není k EET relevantní, ale říkají, že nemusí.
Název: Re:Delphi + EET
Přispěvatel: karel.kral 07-12-2016, 20:46:18
Díky za reakce. Asi to nechám, jak to je. OnBeforePost se v mých Delphi XE6 ve funkci THTTPReqResp.Send opravdu volá až po tom, co se timeouty již nastaví pomocí InternetSetOption, v podstatě bych znovu nastavil to samé podruhé. Navíc se dlouhé timeouty projeví jen u jednoho zákazníka, pokud má výpadek napojení na internet, ještě používá proxy, u sebe to nemůžu nasimulovat nebo nějak ladit.
V běžném provozu to jede, jako když bičem mrská ...
Mám podobné zkušenosti v .NET. Timeout 2 sec, platí, když jede internet. Když ale např. vypadne modem a nejede ani DNS, dotazy trvají i přesto třeba 15 sec. Hledal jsem a prý je to normální. Řešením je spustit request asynchronně a po 2 sec ho utnout. Zatím jsem nezkoušel.
Název: Re:Delphi + EET
Přispěvatel: Jirka 12-12-2016, 20:28:13
Mám podobné zkušenosti v .NET. Timeout 2 sec, platí, když jede internet. Když ale např. vypadne modem a nejede ani DNS, dotazy trvají i přesto třeba 15 sec. Hledal jsem a prý je to normální. Řešením je spustit request asynchronně a po 2 sec ho utnout. Zatím jsem nezkoušel.

Z těchto důvodů (trvalejší závady na trase) mám v profilu EET k dispozici "OffLine" režim  který mi ihned automaticky vrátí PKP +BKP  bez volání služby  .
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 13-12-2016, 09:09:12
Teď jde právě o tu detekci, jestli jsem/nejsem připojen přes internet až na servery EET. A když nejsem, potřebuji se to dozvědět v nějaké rozumné době (jednotky sekund). Timeouty nastavené pomocí HTTPWebNode moc nepomáhají, možná pomůžou čas prodloužit (do řádu minut), ale zkrátit timeout na určitou zaručenou dobu (třeba 10 sekund) s nimi nejde.
Nebo to máš nějak nastaveno?
Název: Re:Delphi + EET
Přispěvatel: Roman K. 13-12-2016, 12:42:25
Už jsem to tady zmiňoval - nastavování timoutů u Wininetu nemá smysl - nefunguje to.
Já používám přístup, kdy nastartuju vlákno které v Execute prování volání webové služby.
Níže uvedená funkce končí nejpozději po zadaném počtu milisekund (pseudokód) :

Kód: Delphi [Vybrat]
  1. function  TrzbaWithTimeout (.....; aTimeout: Integer; ....): HResult;
  2. var
  3.   ....
  4.   ttt: teet_TrzbaThread; // tThread descendant který v Execute volá webovou službu
  5.   h: tHandle;
  6.   WaitResult: DWORD;
  7. begin
  8.   ......
  9.   if aTimeout <> 0 then begin
  10.     ......
  11.     { Spustíme thread, ten zavolá webovou službu}
  12.     ttt := teet_TrzbaThread.Create(true);
  13.  
  14.      // nastavit parametry ttt ...
  15.      ...
  16.      ...
  17.      ...
  18.  
  19.     h := ttt.Handle;
  20.     ttt.Start;
  21.     if aTimeOut < 0 then
  22.       WaitResult := WaitForSingleObject(h, Windows.INFINITE)
  23.     else
  24.       WaitResult := WaitForSingleObject(h, aTimeOut);
  25.     case WaitResult of
  26.     WAIT_OBJECT_0: begin
  27.            // Thread doběhl včas, výsledky jsou validní, zpracovat je
  28.            .....  
  29.           end;
  30.     else begin
  31.            // Thread ještě nedoběhl
  32.             if GetHandleInformation(h, Tmp) then
  33.               ttt.Terminate; // signalizujeme, že s ním končíme, ale je ttt stale validni?
  34.             if WaitResult = WAIT_TIMEOUT then
  35.               Result := E_ABORT
  36.             else begin
  37.               // volání ve vlákně selhalo, ošetřit..
  38.               ....
  39.               ....  
  40.             end;
  41.          end;
  42.      end; // Case
  43.   end else // aTimeout  = 0
  44.     Result := E_ABORT; // automaticky ihned jakoby vysumi na timeout bez toho abych thread vubec startoval
  45. end;
  46.  
  47.  
Název: Re:Delphi + EET
Přispěvatel: peta.dol 02-01-2017, 14:26:48
Ahoj,
používáte někdo XmlSec? Mám s ním problém v případě diakritiky v heslu k certifikátu. Konkrétně volaná funkce:
xmlSecCryptoAppKeyLoad       
https://www.aleksey.com/xmlsec/api/xmlsec-app.html#XMLSECCRYPTOAPPKEYLOAD
vrací nil v případě, že je v heslu diakritika :-\
Název: Re: Delphi + EET
Přispěvatel: Marek Weyda 02-01-2017, 14:39:23
Ahoj,
používáte někdo XmlSec? Mám s ním problém v případě diakritiky v heslu k certifikátu. Konkrétně volaná funkce:
xmlSecCryptoAppKeyLoad       
https://www.aleksey.com/xmlsec/api/xmlsec-app.html#XMLSECCRYPTOAPPKEYLOAD
vrací nil v případě, že je v heslu diakritika :-\

Používám a o problému nevím. Heslo je parametr typu PChar, jakým způsobem ho do funkce předáváš ? Není problém při přetypování, jak jsme tady už řešili ? Jakou verzi těch knihoven XmlSec používáš ?
Název: Re:Delphi + EET
Přispěvatel: peta.dol 02-01-2017, 15:25:38
volám to takto:
dsigCtx.signKey := xmlSecCryptoAppKeyLoad(PChar(AnsiString(FParams.CertificateFile)),
          xmlSecKeyDataFormatPkcs12,  PChar(AnsiString(FParams.CertificatePass)), nil, nil);

definice:
 TxmlSecCryptoAppKeyLoad = function(const filename: PChar; format: xmlSecKeyDataFormat; const pwd: PChar;
        pwdCallback: Pointer; pwdCallbackCtx: Pointer): xmlSecKeyPtr; cdecl;

FParams.CertificatePass : string;

Co se týká verze nejsem schopný to nikde vyčíst (knihovny již používáme i v jiných projektech a jsou historické), žádné resource s informacemi v libxmlsec nejsou, jediné co jsem vyčetl je šas kompilace 19.6.2011 20:14:36
V commentu libsec.pas mám:
{This file generated (mostly) automatically from libxmlsec-api.xml}
{For libxmlsec version: 1.2.10}



Název: Re:Delphi + EET - problém přetypování
Přispěvatel: Marek Weyda 02-01-2017, 16:15:37
volám to takto:
dsigCtx.signKey := xmlSecCryptoAppKeyLoad(PChar(AnsiString(FParams.CertificateFile)),
          xmlSecKeyDataFormatPkcs12,  PChar(AnsiString(FParams.CertificatePass)), nil, nil);

definice:
 TxmlSecCryptoAppKeyLoad = function(const filename: PChar; format: xmlSecKeyDataFormat; const pwd: PChar;
        pwdCallback: Pointer; pwdCallbackCtx: Pointer): xmlSecKeyPtr; cdecl;

FParams.CertificatePass : string;

Tak to je podle mě ono. To je právě to, co jsme řešili. Psal jsem o tom dost obsáhle - o problémech s přetypováním. Zkus si najít to příslušné diskuzní vlákno, případně Daniel Andrascik má odkazy na všechno ve své obsáhlé databázi a pošle Ti odkaz, viď Danieli ?  ;)

Pokud používáš Delphi XE3, jak uvádíš v profilu, tak string není AnsiString jako dříve, proto to zřejmě přetypováváš při volání té funkce - AnsiString(FParams.CertificatePass) a pak ještě na PChar - ale problém je u toho přetypování na AnsiString. POZOR totiž ! Pokud používáš diakritiku, může dojít ke ztrátě informace a to je podle mě Tvůj příklad.

Takže to vymysli jinak. Nemám teď čas to znovu vysvětlovat, ale zkus googlit nebo najít tu diskuzi. Podle mého názoru je zakopaný pes právě u toho přetypování na AnsiString.

XmlSec jsou jinak super knihovny.
Název: Re:Delphi + EET
Přispěvatel: Daniel_Andrascik 02-01-2017, 18:27:34
 :P
Název: Re:Delphi + EET
Přispěvatel: peta.dol 02-01-2017, 22:45:33
udělal jsem si tedy
s: array of char;
 a do něj nasypal jednotlive znaky a predal jako pchar(s).
Kdyz se podivam do pameti pres CRTL+ALT+C vidim tam:
56 00 79 00 61 01 32 00 00 00 (heslo Vyš2)
ale takto mi to neprojde
kdyz  mam
s: array of ansichar;
tak v pameti mam:
56 79 9A 32 00 (Vyš2)

Opravdu nevím jak jinak to posílat, vámi uváděný thread o přetypování jsem hledal fakt dlouho, ale dost blbě se to hledá, když vlastně nevím co v něm pořádně je...
zdá se, že mám tyto knihovny:ftp://ftp.zlatkovic.com/libxml/libxmlsec-1.2.18.win32.zip
Název: Re:Delphi + EET
Přispěvatel: pepak 03-01-2017, 07:31:21
Nechci na to teď přísahat, ale co si pamatuju, tak některé deklarace Delphovské konverze libxml2 a spol. jsou špatně a uvádějí typ PChar tam, kde knihovna ve skutečnosti očekává UTF8 (takže spíš PAnsiChar). Takže Delphi přesně podle instrukcí provedou konverzi a výsledek nefunguje, protože konverze není ve správném kódování...

Rychlý regexp nad zdrojáky mi vrací, že jediné místo, kde v libxml unitách používám PChar, je v libxmlsec_openssl.InitXMLSecOpenSSL, kde to má svou logiku. Všude jinde jedu přes PAnsiChar.
Název: Re:Delphi + EET
Přispěvatel: peta.dol 03-01-2017, 10:29:51
upravil jsem tedy:
    TxmlSecCryptoAppKeyLoad = function(const filename: PAnsiChar; format: xmlSecKeyDataFormat; const pwd: PAnsiChar;
        pwdCallback: Pointer; pwdCallbackCtx: Pointer): xmlSecKeyPtr; cdecl;

nefunguje:     
dsigCtx.signKey := xmlSecCryptoAppKeyLoad(PAnsiChar('cert_diak.pfx'), xmlSecKeyDataFormatPkcs12,
            PAnsiChar('Vyš2'), nil, nil);

bez diakritiky je to ok:     
dsigCtx.signKey := xmlSecCryptoAppKeyLoad(PAnsiChar('cert_nodiak.pfx'), xmlSecKeyDataFormatPkcs12,
            PAnsiChar('Vys2'), nil, nil);

zkoušel jsem to i jako:
s: array of byte;
56 79 9A 32 00 (Vyš2)
ale taky nic...

Můžete mi někdo potvrdit, že Vám to s diakritikou funguje? Případně poslat knihovny se kterými vám to jede a způsob jak to voláte? Díky..

Název: Re:Delphi + EET
Přispěvatel: pepak 03-01-2017, 10:59:20
PAnsiChar('Vyš2') ti neudělá kódování UTF8...
Název: Re:Delphi + EET
Přispěvatel: peta.dol 03-01-2017, 12:32:50
zkusil jsem i UTF8:
s: RawByteString;

s := AnsiToUtf8('Vyš2');
dsigCtx.signKey := xmlSecCryptoAppKeyLoad(PAnsiChar('cert_diak.pfx'), xmlSecKeyDataFormatPkcs12,PAnsiChar(s), nil, nil);
v paměti je:
56 79 C5 A1 32 00

ale opět nefunguje...
Název: Re:Delphi + EET
Přispěvatel: Roman Č. 12-01-2017, 10:38:21
Kolegové profíci, se SOAP mám minimální zkušenosti, HTTPS, SSL a certifkáty obecně jsou moje noční můra. Nicméně stát si to žádá, tak není úniku. Zkouším zkompilovat projekt od Miruse (za zdroje velice a upřímně děkuji) v Delphi XE2 (USE_INDY) a potřebuji odeslat zprávu na EET přes SOAP. Mám jen Indy 10.5.8.0, kde je TIdSSLVersion = (sslvSSLv2, sslvSSLv23, sslvSSLv3, sslvTLSv1); - tedy bez sslvTLSv1_1 a sslvTLSv1_2. Nastavil jsem tedy v constructor TEETRIO.Create(AOwner: TComponent);   SSLOptions.Method := sslvTLSv1; a SSLOptions.SSLVersions := [sslvTLSv1];
Projekt se mi podaří zkompilovat a spustit, ale při pokusu o odeslání dostávám
Error connecting with SSL.
error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
Asi to od Vás profíků schytám, ale přesto to zkusím: můžete mi někdo poradit, jak toto vyřešit, co je špatně?
Díky...
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 12-01-2017, 11:02:49
Asi to od Vás profíků schytám, ale přesto to zkusím: můžete mi někdo poradit, jak toto vyřešit, co je špatně?
Díky...

No, když uvedené chybové hlášení zadám do Googlu, tak mi to najde celkem docela dost diskuzí o této chybě, tak bych to asi zkusil jako první tam.

Jinak ale osobně doporučuji, pokud netrváte na Windows XP, nepoužívat Indy, ale WinInet. EET nám jede už u několika klientů a naprosto bez problémů. Od Indy postupně upouštíme, štve mě tak hodně věcí, ale o tom by bylo další diskuzní vlákno.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 12-01-2017, 13:07:51
Špatně je to, že se pokoušíš navázat spojení se serverem pomocí TLS v. 1.0, ale server podporuje 1.1 nebo vyšší. Viz dokumentace:
"Podporované verze TLS jsou TLS 1.1 a vyšší, doporučená verze TLS je 1.2."

Pokud trváš na Indy, můžeš jedině přeinstalovat Indy na verzi s TLS 1.1 nebo 1.2. Nebo použít WinInet, jak ti radil Marek Weyda. Pomocí Indy dosáhneš jedině toho, že budeš mít podporu TLS 1.1 nebo 1.2 i na Win XP, které už dnes nepodporuje opravdu nikdo.
K.
Název: Re:Delphi + EET
Přispěvatel: Roman Č. 12-01-2017, 14:45:33
Pánové díky za tipy.
Citace
No, když uvedené chybové hlášení zadám do Googlu, tak mi to najde celkem docela dost diskuzí o této chybě, tak bych to asi zkusil jako první tam.
Věřte mi, několik dlouhých hodin jsem nedělal nic jiného. Většinou jsem narazil na pro mne složité odpovědi, ze kterých jsem pouze vydedukoval, že možná upgrade Indy by mohl pomoci, jak píše KarelHorky. Nedošlo mi ale, že sslvTLSv1 je vlastně verze TLS v. 1.0, nikoliv TLS v. 1.1. Pak je to asi zřejmé, co se děje.
Takže jsem se dostal k další poznámce:
Citace
Pokud trváš na Indy, můžeš jedině přeinstalovat Indy na verzi s TLS 1.1 nebo 1.2.
Ano, našel jsem, že je možné použít nové Indy, ale zase jsem obratem také našel, že pokud se ho pokusím přeinstalit v mých Delphi XE2, přestane mi fungovat spousta dalších věcí - jednoduše to prý není možné. Takže jsem se neodvážil toto podstoupit.
Jelikož ale opravdu Win XP nepotřebuji, zkusil jsem tu druhou cestu USE_LIBEET - tedy přes WinInet - a POZOR - po drobných úpravách kódu pro XE2 se kompilace i přenos se podařil!!!

Takže díky díky !!!

Bohužel mám ale další starost. Jeden projekt mám v Delphi 7. Je bohužel docela rozsáhlý, jeho přepis do XE2 je časově neřešitelný. Naneštěstí řešení Miruse přes WinInet (o Indy ani nemluvím) nejde vůbec zkompilovat pod D7, prostě z důvodu mnoha nekompatibilit.

Takže se ptám: rozchodil někdo EET pod Delphi 7? Především tedy myslím samotný přenos zprávy přes TLS 1.1. Opět dopředu moc děkuji za Váš čas.
Název: Re:Delphi + EET
Přispěvatel: Peťo 12-01-2017, 15:04:00
Bohužel mám ale další starost. Jeden projekt mám v Delphi 7. Je bohužel docela rozsáhlý, jeho přepis do XE2 je časově neřešitelný. Naneštěstí řešení Miruse přes WinInet (o Indy ani nemluvím) nejde vůbec zkompilovat pod D7, prostě z důvodu mnoha nekompatibilit.

Takže se ptám: rozchodil někdo EET pod Delphi 7? Především tedy myslím samotný přenos zprávy přes TLS 1.1. Opět dopředu moc děkuji za Váš čas.
Áno, dá sa to. Mirusove riešenie DelphiEET sa mi podarilo upraviť, aby pod Delphi 7 išlo skompilovať a fungovalo cez WinInet (Indy som neskúšal). Bolo nutné zmeniť viaceré deklarácie a vygoogliť nejaké v D7 neexistujúce funkcie. Mám takto upravenú iba staršiu verziu DelphiEET, na budúci týždeň sa chystám upraviť aktuálnu vylepšenú verziu a konečne to dopracovať do aplikácie, lebo kritický mesiac 03/2017 sa blíži.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 12-01-2017, 15:32:22
Takže se ptám: rozchodil někdo EET pod Delphi 7? Především tedy myslím samotný přenos zprávy přes TLS 1.1. Opět dopředu moc děkuji za Váš čas.

Tak u nás se EET zanalyzovalo a naprogramovalo vlastními silami, ostatní projekty (i od zmíněného Mirus, což je určitě dost dobrý projekt, jak jsem koukal a už jsem ho tady kdysi chválil) jsem prolétl jenom letem světem, jak to kdo řešil pouze pro zajímavost a potvrzuji, že lze udělat naprosto funkční řešení (potvrzeno tisíci logy u našich zákazníků) pod Delphi 2007 s tím, že SOAP komunikace se musí ale opravdu upravit, toto pod Delphi 2007 ještě nebylo dobře vyřešené. Takže jsem si brutálně upravil SOAP unity alá moderní Delphi. Bohužel jsem nemohl programovat ve verzi 10.1 Berlin, což bych nejraději, musel jsem prostě se ohlížet na možnosti toho, kým jsem placen, který zatím projekt nemá migrovaný z Delphi 2007 do nejnovějších Delphi, byť se na tom intenzivně dělá.

Takže pokud je funkční řešení Delphi 2007 + WinInet, musí být funkční i Delphi 7 + WinInet si myslím. Já ale za sebe 100 procentně potvrzuji opravdu funkční řešení Delphi 2007 + WinInet.

Osobně jsem daleko více času než SOAP, SSL, certifikáty a další lahůdky, tak daleko více času mi zabral složitý systém logování EET, aby to bylo legislativně opravdu na 100 procent a případná kontrola finančáku nestála naše klienty zbytečné peníze na pokutách. Takže jsem si vyhrál spíše než se samotnou komunikací tak s tím, jak ošetřit všechny možné chybové stavy, nová zaslání a další. Naší analytičku zase potrápilo to, že naši klienti jsou ze všech oborů, takže museli jsme do EET zapracovat všechny ty vymoženosti, jak už jsme o tom tady diskutovali. Takže na březen 2017 si myslím, že jsme už připravený, jediné, čeho se v březnu obávám, že tam najednou začne chodit daleko více (podle mě o opravdu hodně) dokladů, takže jsem na Ministerstvo financí zvědavý, jak to ustojí. Teď nemám v logu jediný záznam, že by byla chyba na straně Ministerstva financí a mám pouze u jednoho klienta jeden jediný záznam, že se stejný doklad třikrát neodeslal z důvodu, že zrovna ten klient měl nefunkční internet. Na počtvrté už se to odeslalo s příznakem první zaslání na False, jak vyžaduje zákon. Což mi přijde neskutečně ideální a nechce se mi tomu věřit. Takže v březnu přeci jenom čekám, že už budou servery MF ČR padat. Údajně už problémy měly, ale já jsem je prostě v logách zatím nezaznamenal a všechno mělo FIK tak, jak má být. Takže se to asi neodesílalo v ten čas, kdy měl být na serveru MF ČR problém. Fakt se mi tomu nechce věřit, že by tentokrát státní správa opravdu realizovala téměř dokonalý systém ? Já se snad ožeru  :)
Název: Re:Delphi + EET
Přispěvatel: Roman Č. 12-01-2017, 16:24:33
To Marek Weyda:
Citace
Já se snad ožeru
Jakmile to rozchodím pod D7 + WinInet, přidám se :)

To Peťo:
Citace
Bolo nutné zmeniť viaceré deklarácie a vygoogliť nejaké v D7 neexistujúce funkcie.
No tady jsem právě skončil, konkrétně na neexistenci HTTPWebNode.GetHTTPReqResp.OnWinInetError (tedy neexistenci FOnWinInetError: TWinInetErrorEvent ve třídě THTTPReqResp) a hned na to na staré nekompatibilní definici TBeforeExecuteEvent = procedure(const MethodName: string; var SOAPRequest: InvString) of object v RIO.pas. To už bylo nad mé síly.
Pokud někdo máte upravené řešení, případně víte, jak dostat do D7 nové definice těchto objektů, budu velmi vděčný za jakoukoliv radu či ukázku kódu.
Název: Re:Delphi + EET
Přispěvatel: Sender 12-01-2017, 17:00:16
Nejednodušším řešením asi je udělat z projektu na githubu dll knihovnu.V projektu D7 používat dll a posílat do ní data.
Název: Re:Delphi + EET
Přispěvatel: Peťo 12-01-2017, 20:17:46
Nejednodušším řešením asi je udělat z projektu na githubu dll knihovnu.V projektu D7 používat dll a posílat do ní data.
To som aj urobil, akurát som to robil v Delphi 7, takže som všetky problémy starej verzie musel vyriešiť. Dôvodom bolo to, že projekt DelphiEET vyžaduje enormné množstvo DLL knižníc, čo je neprehľadné a naviac boli dve z nich v konflikte s ich inou verziou, ktorú už používam. V Dll som použil InterfacedObject, aby som vyexportoval celú triedu, a neviem, či by to fungovalo medzi rôznymi verziami Delphi.

V najnovšej verzii som videl, že Mirus tiež vytvoril v projekte dll knižnicu. Idem si zajtra ešte preštudovať, ako to urobil sám majster.
Název: Re:Delphi + EET
Přispěvatel: mirus 13-01-2017, 09:58:23
Aktualizoval jsem nyní Delphi EET přidal jsem funkci TEETTrzba.OdeslaniTrzbyDirectIndy. Mělo by to být použitelné i pro Delphi Starter Edition. Není potřeba rekompilovat SOAP s podporou INDY t.j. není potřeba definovat USE_INDY. To sloužilo pouze pro rekompilaci SOAP delphi jednotek.
V této funkci je celý proces generování, odeslání a zpracování odpovědi pohromadě. Lze si libovolně nahrazením řádku FIdHttpClient.Post vložit svůj alternativní způsob odeslání (např. synapse, libcurl atd.).
Ostatní funkcionalita zachována.
Název: Re:Delphi + EET
Přispěvatel: Peťo 13-01-2017, 11:32:11
Aktualizoval jsem nyní Delphi EET přidal jsem funkci TEETTrzba.OdeslaniTrzbyDirectIndy. Mělo by to být použitelné i pro Delphi Starter Edition. Není potřeba rekompilovat SOAP s podporou INDY t.j. není potřeba definovat USE_INDY. To sloužilo pouze pro rekompilaci SOAP delphi jednotek.
...
Ostatní funkcionalita zachována.

Obávam sa, že táto zmena znemožní kompiláciu pre tých, čo majú staršiu verziu Indy, kde nie je definované napr. sslvTLSv1_2, atď.

Bolo by možné funkciu OdeslaniTrzbyDirectIndy a všetko s tým súvisiace (uses Id...) dať tiež pod nejaký $define, napríklad USE_DIRECTINDY?

Vďaka.
Název: Re:Delphi + EET
Přispěvatel: Roman Č. 13-01-2017, 14:21:14
A přátelé pozor!! Povedlo se mi upravit kód od Miruse pro Delphi 7 a libeet, před chvílí jsem odeslal první účtenku! Tímto bych chtěl opět vyseknout poklonu Mirusovi, ale samozřejmě i všem dalším, kteří přispěli do tohoto fóra svými cennými podněty. Všem Vám patří veliký dík! A máme tady páťulínek, tak to asi oslavíme, co říkáte??!!

Ale abych také přispěl svou troškou: jak jsem psal tady dříve, zasekl jsem se především na staré verzi Rio.pas. Úprava nakonec nebyla až tak složitá, jen jsem dle naťuknutí od ostatních zkopíroval část kódu z posledních Soap.Rio zdrojů pro vyšší delphi.
Konkrétně jsem upravil deklaraci TBeforeExecuteEvent:
Kód: Delphi [Vybrat]
  1. TBeforeExecuteEvent = procedure(const MethodName: string; SOAPRequest: TStream) of object;
a původní strašný kód procedury TRIO.DoBeforeExecute jsem nahradil jen krátkým:
Kód: Delphi [Vybrat]
  1. TRIO.DoBeforeExecute(const MethodName: string; Request: TStream);
  2. begin
  3.   if Assigned(FOnBeforeExecute) then
  4.   begin
  5.     FOnBeforeExecute(MethodName, Request);
  6.     Request.Position := 0;
  7.   end;
  8. end;
  9.  

A jelikož opravdu netuším, kde všude se mohou změnit projevit, radši jsem Rio.pas nahradil jen ve svém projektu, do instalovaných knihoven  D7 jsem se rozhodl nezasahovat vůbec. V případě dalších dotazů rád pomohu, pokud budu vědět, všem tady to dlužím.
Název: Re:Delphi + EET
Přispěvatel: mirus 13-01-2017, 14:36:28
DelphiEET má direktivu USE_DIRECTINDY, aby šlo jejím nedefinování vypnout potřebu indy komponent při kompilaci v DelphiEET pro použití s WinInet.
Snad to bude takto stačit.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 13-01-2017, 14:50:42
A jelikož opravdu netuším, kde všude se mohou změnit projevit, radši jsem Rio.pas nahradil jen ve svém projektu, do instalovaných knihoven  D7 jsem se rozhodl nezasahovat vůbec. V případě dalších dotazů rád pomohu, pokud budu vědět, všem tady to dlužím.

Tak to, co píšeš, se poměrně obsáhle řeší na stránce 11 a dříve této diskuze, kde právě rozebíráme staré a nové verze RIO unity a kde píši o problému s přetypováním řetězců právě v té staré verzi RIO a lepším řešením pomocí streamů v té nové, ale to předpokládám, že jsi četl a podle toho to upravil, jak píšeš.

Osobně bych nechtěl být závislý na řešení někoho jiného, byť je to určitě od Miruse profesionálně udělané, jsem ale komerční programátor, tak toto bych si ani dovolit nemohl. Jak jsem psal, na EET je podle mě nejsložitější ten legislativní proces, aby to bylo opravdu na 100 procent, protože tam už půjde o hodně - kontrolu z finančáku a chybu v řešení EET by nám zákazníci omlátili o hlavu.

Jsem zvědavý, co tady v diskuzi budeme řešit v tom březnu, až na to přejde další vlna klientů. Nechci strašit, ale osobně už nepředpokládám takový hladký průběh ze strany Ministerstva financí. Ale třeba se mýlím, uvidíme.
Název: Re:Delphi + EET
Přispěvatel: Sender 13-01-2017, 15:46:15
S USE_DIRECTINDY se mi to nepodařilo v D Starter rozchodit.Chybějící property,nekompatibilita verze Indy.Nedopátral jsem se na jakou verzi Indy je ten projekt psán.
Název: Re:Delphi + EET
Přispěvatel: Peťo 13-01-2017, 16:15:35
S USE_DIRECTINDY se mi to nepodařilo v D Starter rozchodit.Chybějící property,nekompatibilita verze Indy.Nedopátral jsem se na jakou verzi Indy je ten projekt psán.

V Delphi 7 je veľmi stará verzia Indy, preto som aj ja potreboval tieto nové veci dať do podmieneného prekladu. Nepodporuje TLS 1.2 a použitie takto starého Indy nie je v EET možné. Jednoznačne treba stiahnuť najnovšiu verziu Indy, čo som ja nechcel robiť, stačí mi cez WinInet podpora Windows 7 a novších.

Vďaka Mirus za doplnenie ifdefov, je lepšie, keď to je v originále, ako keď to mám dopĺňať pri každej aktualizácii ručne vždy znovu a znovu. Už teraz mám pre Delphi 7 dosť práce pri aktualizácii s tými streamami, dopĺňaním timezone, atď.
Název: Re:Delphi + EET
Přispěvatel: Jirka 18-01-2017, 15:20:24
Na playgroundu posílám požadavek s DIČ: CZ1212121218
Vše projde ok

pokud ale změním poslední číslo na 6,  nahlásí mi to:
6 - DIC poplatnika ma chybnou strukturu%*%

Přitom podle specifikace by to mělo být v pořádku . Můžete to někdo vyzkoušet . Děkuji 
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 18-01-2017, 15:21:43
Nejspíš je takové DIČ neplatné - zkuste to s nějakým platným...
Název: Re:Delphi + EET
Přispěvatel: Jirka 18-01-2017, 15:32:08
Nejspíš je takové DIČ neplatné - zkuste to s nějakým platným...

Neplatné bude s velkou pravděpodobností  ale já se odkazuji na specifikaci která mi říká že  DIC má mít na začátku
CZ+ 8-10 cifer. O žádné jiné validaci nic nepíší . .   
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 18-01-2017, 15:35:52
Píšou:

Kritické kontroly jsou následující:
...
5. kontrola integrity DIČ poplatníka
Název: Re:Delphi + EET
Přispěvatel: JaroB 18-01-2017, 15:45:15
DIČ má extra validaci - CZ + rodné číslo nebo CZ + IČ a každé má svojí validaci.
Název: Re:Delphi + EET
Přispěvatel: Jirka 18-01-2017, 15:59:42
díky už jsem to objevil ...  :)
Název: Re:Delphi + EET
Přispěvatel: erB 19-01-2017, 15:02:15
Ahoj,

jaké máte zkušenosti s úpravami programů v Turbo Delphi 2006 pro EET ?

Díky
Název: Re:Delphi + EET
Přispěvatel: rimba 01-02-2017, 09:36:22
Ahojda,
už jste někdo obdržel hlášku "error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure". (Testováno na Mirusově demo-app-ce. Napadá vás něco?
Název: Re:Delphi + EET
Přispěvatel: mirus 01-02-2017, 10:00:28
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.  
Název: Re:Delphi + EET
Přispěvatel: Peťo 01-02-2017, 10:44:32
Ja sa momentálne v DelphiEET borím s chybou

Chyba : -1 - Access violation at address 453D4E53. Read of address 453D4E43.

Objavuje sa úplne náhodne, napríklad tri pokusy sú v poriadku, potom dvakrát táto chyba, päť pokusov v poriadku, atď. Adresa je vždy iná. Nedá sa to odladiť, chyba vzniká pri volaní OdeslaniTrzby niekedy počas tvorby xml alebo podpisovaní. Čo s tým?
Název: Re:Delphi + EET
Přispěvatel: JaroB 01-02-2017, 11:11:47
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.
Název: Re:Delphi + EET
Přispěvatel: Peťo 01-02-2017, 11:38:21
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.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 01-02-2017, 13:03:04
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.
Název: Re:Delphi + EET
Přispěvatel: Peťo 01-02-2017, 15:19:18
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.
Název: Re:Delphi + EET
Přispěvatel: rimba 02-02-2017, 17:49:48
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.
Název: Re:Delphi + EET
Přispěvatel: Lukas 03-02-2017, 09:00:09
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áš
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 03-02-2017, 10:30:05
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.
Název: Re:Delphi + EET
Přispěvatel: rimba 03-02-2017, 13:33:11
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.

Název: Re:Delphi + EET
Přispěvatel: mirus 04-02-2017, 00:10:51
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"
Citace
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.
Název: Re:Delphi + EET
Přispěvatel: oxo 04-02-2017, 17:51:35
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ě  :D
Název: Re:Delphi + EET
Přispěvatel: pepak 05-02-2017, 16:38:05
Na třetí stranu je to celkem zbytečné, protože za chvíli už to nebude aktuální.
Název: Re:Delphi + EET
Přispěvatel: oxo 06-02-2017, 08:54:48
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ší?
Název: Re:Delphi + EET
Přispěvatel: RadimHoly 10-02-2017, 18:43:45
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.
Název: Re:Delphi + EET
Přispěvatel: rames.iii 10-02-2017, 20:46:19
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.
Název: Re:Delphi + EET
Přispěvatel: RadimHoly 12-02-2017, 21:03:04
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ě.
Název: Re:Delphi + EET
Přispěvatel: Roman K. 13-02-2017, 12:34:38
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ů.
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 13-02-2017, 14:05:34
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ů.

Tak to je samozřejmé, já jsem určitě řešení bez Indy - použít WinInet - propagoval, ale vždy jsem psal, že to není pro ty, co musí podporovat XP - a upřímně řečeno tyto lituji. XP je mrtvé a budou s tím jenom problémy.

Jinak k tomu, co tady zaznělo - aby se tato diskuze nějak rozložila, jsem pro. Já osobně bych byl pro jedno vlákno pro uživatele řešení od Mirus, kteří tady řeší problémy s tím jeho projektem a pak ty obecně se týkající EET nejenom jednoho řešení.

Ale pravdu má také pepak, že EET už nebude aktuální. Předpokládám, že všichni už mají svůj soft odladěný, kyž druhá vlna je na spadnutí.

Osobně jsem rád, že teď ve firmě už EET neřeším, ale zažívají si lidi v přímém kontaktu se zákazníky, i když jsme na to měli extra školení. Řeší se fakt téměř na 100 procent kraviny, které se týkají toho, že nepochopili certifikáty, mají špatná hesla, špatně nastavené parametry a podobně. Předpokládám, že jste na tom ostatní podobně.
Název: Re:Delphi + EET
Přispěvatel: zdenek 14-02-2017, 13:53:36
Kdyby XP, ale hodně mají 2003 servery což je totéž a ještě proxy s NTLM. Jinak nemusím nic víc psát, Marek Weyda to napsal přesně.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 20-02-2017, 13:09:34
Evidentně už máte všichni podporu EET vyšperkovanou, tak mi třeba někdo poradí s urceno_cerp_zuct (Celková částka plateb určená k následnému čerpání nebo zúčtování) a cerp_zuct (Celková částka plateb, které jsou následným čerpáním nebo zúčtováním platby) protože zákazník si to žádá doplnit i když jsem s tím původně nepočítal.

Četl jsem specifikaci a nejsem si 100% jist vykladem hlavně v případě b)

a) nakupuji zboží za 200 s DPH 21% a kupuji voucher za 100.

tj. na EET půjde celková částka (celk_trzba) = 200 + 21% DPH + 100 (bez DPH, tj. zakl_nepodl_dph) = 342, a do urceno_cerp_zuct se dá 100.

b) nakupuji zboží za 200 s DPH 21% a PLATIM předchozím voucherem za 100

tj. na EET půjde celková tržba (celk_trzba)  200 + 21% DPH - 100 = 142, přičemž
bude uvedeno v zakl_nepodl_dph = - 100  (tj. minus 100) a v cerp_zuct = 100 ?

nebo

na EET půjde celková tržba (celk_trzba)  200 + 21% DPH = 242 a v cerp_zuct = 100 ?

díky Radek

Název: Re:Delphi + EET
Přispěvatel: rames.iii 20-02-2017, 13:38:33
Já to mám takto:
Při prodeji je celk_trzba úhrada, tedy včetně voucher (342), tam je to asi jasné.
Pokud voucher čerpám (a nepodléhá DPH), celk_trzba je včetně voucheru (242 - tolik je platba), zakl_nepodl_dph=0 (voucher je platební metoda, pokud nepodléhá DPH) a cerp_zust=100.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 20-02-2017, 15:01:50
b) nakupuji zboží za 200 s DPH 21% a PLATIM předchozím voucherem za 100

tj. na EET půjde celková tržba (celk_trzba)  200 + 21% DPH - 100 = 142, přičemž
bude uvedeno v zakl_nepodl_dph = - 100  (tj. minus 100) a v cerp_zuct = 100 ?

Toto je správně, pokud přijmeme, že voucher je osvobozen od DPH. Ale podle mně je voucher v základní sazbě DPH, pokud se s ním dá "platit" zboží v základní sazbě.
Název: Re:Delphi + EET
Přispěvatel: Radek Červinka 20-02-2017, 15:15:56
b) nakupuji zboží za 200 s DPH 21% a PLATIM předchozím voucherem za 100

tj. na EET půjde celková tržba (celk_trzba)  200 + 21% DPH - 100 = 142, přičemž
bude uvedeno v zakl_nepodl_dph = - 100  (tj. minus 100) a v cerp_zuct = 100 ?

Toto je správně, pokud přijmeme, že voucher je osvobozen od DPH. Ale podle mně je voucher v základní sazbě DPH, pokud se s ním dá "platit" zboží v základní sazbě.

Díval jsem se do manuálu pro účetnictví Pohoda a tam je uvedeno, že pro EET se vouchery musí nastavit 0% DPH - http://delphi.cz/temp/pohoda.jpg (http://delphi.cz/temp/pohoda.jpg).

Bavil jsem se o tom s účetní, a ta to připustila, že pro EET je to možné.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 20-02-2017, 15:17:15
Asi podobně jako dárkové poukázky - poukázka stojí 500 Kč, ale předem se neví, v jaké sazbě bude zboží, které si pak zákazník vybere.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 20-02-2017, 15:42:58
Je prostě nutné vědět, o jaký voucher se jedná a co se za něj bude "nakupovat". Nejlíp se poradit s daňovým poradcem. My používáme zákaznické karty, kde si zákazník může zůstatek předplatit a pak s ním platí útratu v restauraci, zde je dobíjení a čerpání zůstatku v základní sazbě. Pak je druhý případ, kdy zákazník nejdřív platí zákaznickou kartou (v podstatě mu půjčuji) a následně mi to zákazník vrátí. Pak je to osvobozeno.
Název: Re:Delphi + EET
Přispěvatel: rames.iii 20-02-2017, 17:09:00
Jestli voucher podléhá DPH, nebo ne, to je opravdu složitější (různí daňový poradci různých zákazníků mají různý názor;) ).
Z různých názorů a svých znalostí jsem pro sebe vyvodil, že pokud je voucher na peníze s možností čerpat cokoliv, nepodléhá DPH (něco jako stravenky), pokud naopak zní na konkrétní produkt (zboží, služba, ...), případně skupinu produktů, tak podléhá DPH. Oboje umíme a evidujeme do EET.
Název: Re:Delphi + EET
Přispěvatel: rames.iii 20-02-2017, 17:19:51
b) nakupuji zboží za 200 s DPH 21% a PLATIM předchozím voucherem za 100

tj. na EET půjde celková tržba (celk_trzba)  200 + 21% DPH - 100 = 142, přičemž
bude uvedeno v zakl_nepodl_dph = - 100  (tj. minus 100) a v cerp_zuct = 100 ?

Toto je správně, pokud přijmeme, že voucher je osvobozen od DPH. Ale podle mně je voucher v základní sazbě DPH, pokud se s ním dá "platit" zboží v základní sazbě.

Rozlišoval bych "osvobození od DPH" (zjednodušeně podléhá DPH, ale s nulovou sazbou) a "není předmětem DPH". Voucher podle mě osvobozen být nemůže. Buď je předmětem DPH, nebo není (ale už je to opravdu dlouho, co jsem dělal zkoušku z daní). Pak platí:
"Do celkové částky tržby se uvádějí všechny částky, které je poplatník povinen evidovat. To znamená i částky, které jsou určené k následnému čerpání nebo zúčtování; i částky, které jsou následným čerpáním nebo zúčtováním; zahrnuje se i DPH." zdroj http://www.etrzby.cz/assets/cs/prilohy/Popis_polozek_datove_zpravy_v3.1.pdf
Název: Re:Delphi + EET
Přispěvatel: Peťo 21-02-2017, 00:23:31
Rozlišoval bych "osvobození od DPH" (zjednodušeně podléhá DPH, ale s nulovou sazbou) a "není předmětem DPH". Voucher podle mě osvobozen být nemůže. Buď je předmětem DPH, nebo není.
Na položku EET zakl_nepodl_dph som takto narazil aj ja. Dal by som si na ňu veľký pozor, lebo máločo do nej bude podľa mňa spadať. Určite nie zakúpenie a čerpanie poukážok alebo záloh, a rovnako nie napríklad zaokrúhlenie faktúr, ak sa eviduje bez DPH (čo som tam plánoval zahrnúť). Podľa pokynov Popis_polozek_datove_zpravy_v3.1.pdf do zakl_nepodl_dph patrí:
Jedná se o všechna plnění osvobozená od daně s nárokem na odpočet, ostatní plnění vstupující do údaje na ř. 20, 21, 22, 23, 24, 25, 26 (kromě zvláštních režimů podle § 89 a § 90 zákona o DPH) přiznání k DPH a plnění osvobozená od daně bez nároku na odpočet daně vstupující do údaje na ř. 50 přiznání k DPH.
Z toho mi vychádza, že tam bude napríklad predaj tovaru do zahraničia a špeciálne služby typu poisťovacie, zdravotnícke, poštové listové zásielky a ešte pár činností (http://www.finance.cz/dane-a-mzda/dph-a-spotrebni-dane/dph/osvobozeni-od-dane/), s ktorými sa v EET stretneme málokedy. Čerpanie voucheru by sa tam malo ocitnúť len vtedy, ak pôjde o nejakú z tých služieb alebo predaj do zahraničia.
Název: Re:Delphi + EET
Přispěvatel: anec 22-02-2017, 12:49:04
2Peťo: no a kam tedy dáváš to zaorkrouhelní, nebo neuvádíš vůbec?
Název: Re:Delphi + EET
Přispěvatel: Peťo 22-02-2017, 15:20:13
2Peťo: no a kam tedy dáváš to zaorkrouhelní, nebo neuvádíš vůbec?
Nedávam ho nikam a celk_trzba je zaokrúhlená suma na celé Kč. Ako sa tu už spomínalo (http://forum.delphi.cz/index.php/topic,15267.msg94895.html#msg94895), aj podľa vyjadrenia GFŘ, súčet položiek nemusí byť rovný celk_trzba.

Podobne nebude súčet rovný aj v prípade, že je v doklade odpočítaná záloha, ktorá bola prevzatá už skôr a bez zaúčtovania DPH.
Název: Re:Delphi + EET
Přispěvatel: Jirka 22-02-2017, 19:20:08
Nevím jestli jsem něco někde nepřehlédl  ale na testovacím serveru se  mi response vrací v <soapenv:Envelope></soapenv:Envelope>
a z ostrého <soap:Envelope></soap:Envelope>
Může mi to někdo prosím objasnit   
Děkuji
Název: Re:Delphi + EET
Přispěvatel: anec 23-02-2017, 17:33:04
kdyby někoho zajímalo:

Byl zveřejněn dokument s příklady, jak u různých typů tržeb správně naplnit položky datové zprávy. Obsahuje 22 různých situací a jim odpovídající vzory.

http://www.etrzby.cz/cs/novinky_Priklady-naplneni-polozek-datove-zpravy
Název: Re:Delphi + EET
Přispěvatel: Lukas 28-02-2017, 10:39:34
Zbývá už jen pár hodin do spuštění 2.etapy, ale přeci jenom jsou ještě další :-)

Řešil někdo EET pro Delphi FMX (Android) ?

Naťukněte mi postup, díky
Lukáš

Název: Re:Delphi + EET
Přispěvatel: oxo 28-02-2017, 11:11:53
Já bych si udělal server, který by to řešil mimo android. T.j. android odešle dotaz na tvůj server a ten to vyřídí.
Název: Re:Delphi + EET
Přispěvatel: KarelHorky 01-03-2017, 12:35:34
Na www.etrzby.cz zveřejnili takový stručný dokument s nejčastějšími prohřešky:

http://www.etrzby.cz/assets/cs/prilohy/Informace_pro_vyvojare_201702.pdf
Název: Re:Delphi + EET
Přispěvatel: egroups 03-03-2017, 13:10:49
Právě jsem s hrůzou zjistil,že nějakým nedopatřením jsem sypal DPH do základů a odesíllal vesele na EET:(
Existuje nějaký způsob,jak doklady již zaevidované na portále lze opravit?
Jedná se Prodejky a Faktury hotově.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 03-03-2017, 13:18:03
Právě jsem s hrůzou zjistil,že nějakým nedopatřením jsem sypal DPH do základů a odesíllal vesele na EET:(
Existuje nějaký způsob,jak doklady již zaevidované na portále lze opravit?
Jedná se Prodejky a Faktury hotově.

Z hlediska částek by mělo stačit, když se tam "totéž", ale s opačnými znaménky, pošle znovu - tím se původní záznamy v součtech vynulují. Pak poslat všechny doklady znovu už správně. Nicméně problém nejspíš bude s datem a časem vystavení dokladu versus datem a časem jeho odeslání do EET.
Název: Re:Delphi + EET
Přispěvatel: ShaneZB 03-03-2017, 13:20:24
Možná je to rouhání, ale pokud je celková částka správná, tak bych to raději nechal, aby ta "oprava" nepřitáhla nechtěnou pozornost.
Název: Re:Delphi + EET
Přispěvatel: egroups 03-03-2017, 13:41:57
Celková částka je v pořádku,ale nesedí samozřejmě součty základů a DPH s celkovou částkou.Je zajímavé,že to portál zbaštil:(
Doklady mám v databázi.Nevím,jestli jde prostě jen poslat ty data jakoby znovu,aniž by mi to přidělilo FIK,jen to prostě přepsalo ty DPH u daného dokladu,protože index dokladu je furt stejný.Nemá s tím někdo zkušenost.
Je to samozřejmě moje velká chyba,že při testech jsem se nějak přepsal,nicméně to budu muset nějak opravit.
Nové doklady už budou samozřejmě v pořádku.
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 03-03-2017, 13:50:12
Celková částka je v pořádku,ale nesedí samozřejmě součty základů a DPH s celkovou částkou.Je zajímavé,že to portál zbaštil:(
Doklady mám v databázi.Nevím,jestli jde prostě jen poslat ty data jakoby znovu,aniž by mi to přidělilo FIK,jen to prostě přepsalo ty DPH u daného dokladu,protože index dokladu je furt stejný.Nemá s tím někdo zkušenost.
Je to samozřejmě moje velká chyba,že při testech jsem se nějak přepsal,nicméně to budu muset nějak opravit.
Nové doklady už budou samozřejmě v pořádku.

Nové odeslání = nový FIK.

Nicméně pokud by při novém odeslání byly klíčové údaje stejné, mělo by u nich dojít k nahrazení předchozích údajů. Půjde to dohledat v dokumentaci, mám dojem, že stejné musí být DIČ, provozovna, pokladna, číslo účtenky, datum a čas přijetí tržby a celková částka tržby.
Název: Re:Delphi + EET
Přispěvatel: egroups 03-03-2017, 14:05:27
Ano,tyto údaje zůstanou stejné.
Název: Re:Delphi + EET
Přispěvatel: egroups 03-03-2017, 14:13:23
Hmm,tak asi ne:(
Odpověď z GFŘ:

Dobrý den,

s daty, která byla odeslána do systému evidence tržeb, již není možné jakkoliv manipulovat. Nelze tedy data dodatečně upravovat, odstraňovat, apod. V případě, že došlo k odeslání datové zprávy s evidovanou tržbou (i v případě "chybné" tržby) a tato tržba byla přijata do systému, nelze ji následně odstranit či změnit. Záznam o tržbě již bude v systému uložen.

Provést storno určitých tržeb je ale samozřejmě možné. V systému evidence tržeb pak bude uvedena "chybně evidovaná tržba" a také provedené storno.

Vrací-li se evidovaná tržba nebo provádí-li se opravy tržby, která již byla odeslána do systému správce daně, postupuje se obdobně jako v případě evidování tržby s tím rozdílem, že tato zadaná částka bude záporná (mínusová položka). Postup se vztahuje na případy vrácení zboží bez uvedení důvodu, při vyřízení reklamace, u omylem zaevidované tržby nebo na případy, kdy byly údaje o evidované tržbě zaslány správci daně před přijetím tržby a zákazník nakonec zboží nezaplatil (nejčastěji půjde o zasílání zboží webovými obchody na dobírku a následné nepřevzetí zboží). Provedené storno není z technického hlediska vázáno na původně zaslanou datovou zprávu (resp. vydanou účtenku).

 
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 03-03-2017, 15:12:11
Hmm,tak asi ne:(

No, to Ti opravdu nezávidím, to je pech. Co pošleš, to se prostě eviduje a moc nedoporučuji dráždit hada bosou nohou, protože podle mě oni půjdou právě po těch, co budou doklady (byť chybně odeslané) se snažit různě stornovat a opravovat a jedině tak na sebe upozorní, protože podle mě v tom jejich systému budou právě mít nějaké kontroly na ty různé několikrát zaslané doklady - stejné a s různými údaji. To si tedy myslím, z praxe zatím nemám vyzkoušené, běží to poměrně krátce, ale s Kontrolním hlášením DPH už máme zkušeností po více než roce dost a tam opravdu jdou po těch, co nějak "divně vyčnívají".

U nás ve firmě jsme se právě těchto nesrovnalostí dost báli, takže EET se fakt testovalo a testovalo a testovalo a stejně jsme tam nějaké chyby ladili, nejsme stroje, takže vše se v testovacím prostředí nedomyslelo, praxe pak ukázala více. Ale nic zásadního tam naštěstí nebylo a ty částky to byl základ, to se tady analyzovalo desetkrát, jestli to opravdu vše rozhodí, jak má.

Už mi to EET leze krkem, myslel jsem, že už bude klid, ale stejně teď to stále řeším, ale jak jsem psal - víceméně je to už na straně našich zákazníků, některým opravdu dělají problém i základy, ale nedivím se - leckdo vidí počítač díky EET poprvé  :)
Název: Re:Delphi + EET
Přispěvatel: egroups 06-03-2017, 09:48:08
O lezení krkem mi ani nemluv.Tolik prášků na spaní jsem už dlouho nebaštil.
Nicméně z GFŘ mi pak ještě odepsali,že můj dotaz je specifický a odkázali mne na jiný formulář pro metodiku.
Teď čekám,až mi zákazník přepošle seznam dokladů,ještě to zkontroluju a pak zkusím napsat na tu metodiku.
Doufám,že to dopadne tak,že prostě sepíšu omluvný dopis z vysvětlením a seznamem dokladů,kterých se to týká.Přesně tak,nejsme stroje a chyby se můžou stát.Stejně z účetnictví odevzdají vše v pořádku,včetně DPH.
Název: Re:Delphi + EET
Přispěvatel: anec 10-03-2017, 12:27:05
egroups: jak to dopadlo? jaks to vyřešil?
Název: Re:Delphi + EET
Přispěvatel: egroups 10-03-2017, 13:20:09
Z finančáku už se ani neobtěžovali mi odepsat,tak jsem to nechal plavat.Těch pár dokladů snad přežijou.Myslím,že mají spoustu jiných starostí.
Název: Re:Delphi + EET
Přispěvatel: RadimHoly 03-04-2017, 15:51:56
Nemáte někdo zkušenost s tím, že na terminálových serverech 2008 R2 při prvním spojení někdy zamrzne program. Většinou po restartu programu a novém spuštění již komunikace většinou běží bez problémů. Tedy nejčastěji problém prvního dokladu daného dne určité stanice. Dělají to ale jen některé připojení, ostatní běží normálně. V některém dni to proběhne bez problémů, ale často z 20 terminálových spojení nefunguje první spojení na cca 2. V dalším dni to často jsou jiné pobočky, ale nejčastěji stále stejné (možná ty co nejdříve provedou první doklad EET). Je divné, že některé připojení toto chybu nezaznamenaly nikdy.
Zjistil jsem, že ve většině případů to zamrzne v proceduře TEETTrzba.OdeslaniTrzby v místě:
          finally
            TT.Free;
          end;
Ve většině případů dojde do místa finally, ale neprovede TT.Free v případě, že thread neproběhl v zadaném čase. Při dalších pokusech v tom dni většinou i při nestihnutí limitu program běží dál a není s tím problém, tedy Free pak projde bez problémů.
Používám D10.1 update 2
Název: Re:Delphi + EET
Přispěvatel: Marek Weyda 03-04-2017, 16:07:35
Nemáte někdo zkušenost s tím, že na terminálových serverech 2008 R2 při prvním spojení někdy zamrzne program.

S 2008 R2 mám problém v jednom případě a tam to neustále padalo při vzdáleném spuštění OdeslaniTrzby a jakože to fakt řachlo Windowsovskou hláškou na nějaké DLL knihovně jádra Windows. Na jiných 2008 R2 to nedělalo a to jich z minulosti máme.

Veškeré aktualizace a další věci ničemu nepomohly, normálně jsme si na tom vylámali zuby, příčinu jsme neodhalili. Takže nyní tam už nemají 2008 R2, ale tuším, že 2016  ;)

Jinak na dalších 2008 R2 to běhá naprosto bez problémů.

Ale to asi byl jiný problém než ten Váš, protože tady na tom jednom terminálu to neodeslalo nikdy. Kdežto Vy píšete, že někdy jo.
Název: Re:Delphi + EET
Přispěvatel: Peťo 04-04-2017, 08:48:06
Nemáte někdo zkušenost s tím, že na terminálových serverech 2008 R2 při prvním spojení někdy zamrzne program. Většinou po restartu programu a novém spuštění již komunikace většinou běží bez problémů. Tedy nejčastěji problém prvního dokladu daného dne určité stanice. Dělají to ale jen některé připojení, ostatní běží normálně. V některém dni to proběhne bez problémů, ...
Používám D10.1 update 2
Stretávam sa presne s týmto malým problémom u niektorých zákazníkov. Prvý doklad v dni a program spadne, potom už bez problémov. Robí to len niektorým a nie vždy, všetci majú Windows 10. Keď som chcel chybu vyvolať u seba, tak sa mi to žiadnym spôsobom nepodarilo, ani na Windows 10, ani na Windows 7. Používam Mirusove DelphiEET a Delphi 7, mal som podozrenie na starú verziu Delphi, ale vidím, že to nie je chyba v Delphi.

Vidím to na chybu niekde v komunikácii Delphi SOAP - WinINet, alebo ešte ak sa do toho zapojí niekto tretí. Nemám istotu, ale zdá sa mi, že všetci, čo majú problém, majú aj Avast, a ten vie celkom nečakane zablokovať spustenie exe alebo dll. Najskôr ho spustí nejako do sandboxu, a až o 15 sekúnd normálne. Keď sa takto správa aj k dll, tak by som sa nečudoval ničomu.
Název: Re:Delphi + EET
Přispěvatel: doonio 09-05-2017, 09:35:32
Ahoj vespolek všem, dostal jsem za úkol naprogramovat u nás ve firmě EET, sice až teď ale ještě se nás netýká zatím povinná evidence. Nějak se mi pořadilo vygenerovat podepsané XML, vypočte se mi otisk  <ds:DigestValue> i samotný podpis <ds:SignatureValue>, ale všechny tagy, kde má být nějaké ID jsou prázdné <ds:Signature Id= ""> nebo <ds:KeyInfo Id="">, atd. K podpisu používám knihovnu xmlsec (https://www.aleksey.com/xmlsec/ (https://www.aleksey.com/xmlsec/)). A můj dotaz zní, jestli ty jednotlivý identifikátory si volím libovolně já, nebo by to měla generovat ta podpisová knihovna (např. v oficiálním příkladu od E-tržeb je zase uvedeno <ds:Signature Id="SIG-AB79979F3364F5119A14761286404065">). Tak jsem z toho mírně v nesnázích, protože když já vygeneruji podpisové XML, tak tag Signature Id je prázdny. Díky za tip
Název: Re:Delphi + EET
Přispěvatel: RadimHoly 09-05-2017, 12:54:03
Nemáte někdo zkušenost s tím, že na terminálových serverech 2008 R2 při prvním spojení někdy zamrzne program. Většinou po restartu programu a novém spuštění již komunikace většinou běží bez problémů. Tedy nejčastěji problém prvního dokladu daného dne určité stanice. Dělají to ale jen některé připojení, ostatní běží normálně. V některém dni to proběhne bez problémů, ...
Používám D10.1 update 2
Stretávam sa presne s týmto malým problémom u niektorých zákazníkov. Prvý doklad v dni a program spadne, potom už bez problémov. Robí to len niektorým a nie vždy, všetci majú Windows 10. Keď som chcel chybu vyvolať u seba, tak sa mi to žiadnym spôsobom nepodarilo, ani na Windows 10, ani na Windows 7. Používam Mirusove DelphiEET a Delphi 7, mal som podozrenie na starú verziu Delphi, ale vidím, že to nie je chyba v Delphi.

Vidím to na chybu niekde v komunikácii Delphi SOAP - WinINet, alebo ešte ak sa do toho zapojí niekto tretí. Nemám istotu, ale zdá sa mi, že všetci, čo majú problém, majú aj Avast, a ten vie celkom nečakane zablokovať spustenie exe alebo dll. Najskôr ho spustí nejako do sandboxu, a až o 15 sekúnd normálne. Keď sa takto správa aj k dll, tak by som sa nečudoval ničomu.

Několikerým nastavováním jednotlivých možností komunikace se zdá, že jsem tento problém vyřešil. Použil jsem nakonec direktivu USE_DIRECTINDY a volám tedy komunikaci pomocí OdeslaniTrzbyDirectIndy. U firem, kde to dosud padalo jsem zatím nezaznamenal žádný problém.
Název: Re:Delphi + EET
Přispěvatel: thcom 16-06-2017, 19:50:35
ahoj, kdo tady pouziva JADU EET
stahnul jsem posledni verzi a nejak nedokazu vycist jak se ted jmenuje trida, predtim to bylo teet ale ted jsem to nejak nepojal

omlouvam se za stupidni dotaz, ale zamrzl jsem v programatorskem umu v dobach borlandpascalu :)

diky moc TH
Název: Re:Delphi + EET
Přispěvatel: Daniel_Andrascik 17-06-2017, 11:49:05
Pre "zamzrnuteho" programatora je celkom odvaha pustat sa rovno do EET. Neviem neviem, nechcem cokolvek namietat proti tvojim schopnostiam, ale ja by som to v takomto pripade radsej nechal na niekoho ostrielaneho. S certy nejsou zerty a financna sprava je cele klbko certov...
Název: Re:Delphi + EET
Přispěvatel: oxo 17-06-2017, 14:41:08
Pre "zamzrnuteho" programatora je celkom odvaha pustat sa rovno do EET. Neviem neviem, nechcem cokolvek namietat proti tvojim schopnostiam, ale ja by som to v takomto pripade radsej nechal na niekoho ostrielaneho. S certy nejsou zerty a financna sprava je cele klbko certov...

On EET nedělá, jen chce použít externí DLL knihovnu.
Název: Re:Delphi + EET
Přispěvatel: Tomáš Holý 03-07-2017, 18:34:30
ahoj, muzete me prosim nakopnout, kdyz se trba neodesle, dojde k timeoutu, jak se to presne posila znova, neni nekde nejaky pokec v pdf, nejak to nemuzu najit, uz tu dnes asi sedim moc dlouho :(
jde mi o to zda mam udelt nove uuud nebo stejne, diky TH
Název: Re:Delphi + EET
Přispěvatel: vandrovnik 03-07-2017, 19:09:34
ahoj, muzete me prosim nakopnout, kdyz se trba neodesle, dojde k timeoutu, jak se to presne posila znova, neni nekde nejaky pokec v pdf, nejak to nemuzu najit, uz tu dnes asi sedim moc dlouho :(
jde mi o to zda mam udelt nove uuud nebo stejne, diky TH

Nové, je to v tom EET_popis_rozhrani_v3.1.1.pdf na etrzby.cz:
Jde o univerzální jedinečný identifikátor v hlavičce datové zprávy evidované tržby, který je generován pokladním zařízením poplatníka. Jednoznačně identifikuje datovou zprávu (nikoli e-tržbu). I při opakovaném zaslání datové zprávy má být vytvořeno nové UUID zprávy.