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ě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í.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.
Ano, certifilat na strane klienta.
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?
Pánové, kdyby někdo doufal v součinnost GFŘ, tak tady je jejich odpověď:
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.
Ř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
To by přece nemělo mít formátování XML vliv na podepisování. Jaký typ kanonizace jste nastavil?
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].
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á.
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]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ů.
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?
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.
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...
Ahojte nasel jsem konecne funkcni prikladysem objevil ameriku :) nevsiml jsem si, ze odkaz tu je. :-[
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 :)
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
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.
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 ...
předejít řitního použitím dostupných Opatření
OT: To je v akom jazyku? Ale toto ma pobaviloMe 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
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.
..................
Tak a teď jak do toho.
..................
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.
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
- XMLBlackBox VCL - podepisování a ověřování XMLZkouš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 ?
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.
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...
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?Resiva se to kontrolou hashu ev. serioveho cisla certifikatoru, ale nevim, jestli EET na strane serveru hash publikuje nebo jinak umoznuje zkontrolovat jeho pravost.
Ověření by mělo být v AfterExecute (pokud se používá RIO) asi nějak takto:Kód: Delphi [Vybrat]
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.
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.
Úř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...
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ě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í?
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.
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 EETAno.
a ještě odesílat po každé prodané licenci hlášení?Ano.
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).Podle seminářů, na kterých jsem byl, ovšem FÚ tu výjimku pro tyhle případy nedá.
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. :)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...
Zakoupím řešení pro Delphi XE. Požadavky:Případnou nabídku prosím na info@dsoft.cz
- 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
Reseni poptava, nenabizi. Ja bych tak prikry nebyl.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.
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.Reseni poptava, nenabizi. Ja bych tak prikry nebyl.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.
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.
S dovolením ale za shanění lidí si nějaký mrzký peníz (proti agenture) rád vezmu.
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?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).
Ahoj, mohl by jsi zverejnit spusteni COM object napsaný v C# bez Jcl ? docela by mne to zajimalo. dikS 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ě.
Díky za inspiraci. Mě se daří tak napůl: :DTak 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 ! :)
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 ! :)
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ší:
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)
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...
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.
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? :)
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.
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.
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.
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.
hlavne kombinácia ssleay32.dll+libeay32.dll, ktorá je v konflikte s týmito knižnicami, ktoré už používam kvôli Indy9
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:
@Peťo:Používam Indy9, pretože Indy10 v Delphi 7 neskompilujem. :(
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?
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]
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]
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"?
.........
Používam Indy9, pretože Indy10 v Delphi 7 neskompilujem. :(
..........
... 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:
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é:
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?
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]
No tohle právě v D7 nefunguje, protože, jak si všimnete, Bias je vždy Current.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.
A my potřebujeme Bias pro datum zadané ve Value argumentu funkce DateTimeToXMLTime :-)
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?
No tohle právě v D7 nefunguje, protože, jak si všimnete, Bias je vždy Current.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.
A my potřebujeme Bias pro datum zadané ve Value argumentu funkce DateTimeToXMLTime :-)
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 :-)
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í.
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>
...
<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.
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...............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 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
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...............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 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
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ď?
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....
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.
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
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
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
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
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)
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.
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.
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
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="".
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.
atribut="0" není prázdný atribut. Prázdný atribut je atribut="".
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ě)
[/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.
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.
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é.
jsem plátce dph, mám fakturu 100tisíc + 21000 dph celkem 121.000,-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Ř?
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?Ne. Pokud je příjemce peněz plátcem DPH, stávají se pro něj povinnými i rozpisy.
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.
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.
Takže pri pohľadávke 100 Kč + DPH 21 Kč = 121 Kč a jej čiastočnej úhrade v hotovosti 50 Kč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.
Správně. Mám to vyřešeno již dávno před EET, právě ve spolupráci s daňovým poradcem.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.
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
Takže pri pohľadávke 100 Kč + DPH 21 Kč = 121 Kč a jej čiastočnej úhrade v hotovosti 50 KčNevím. Nejsem si jistý, jestli tohle vůbec GFŘ řeší.
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 je otázka na FÚ.
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í.
ze by O2?Podle mě spíš IQ.
ze by O2?Podle mě spíš IQ.
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ť.
OT:CitaceAle ř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ť.
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.
Ešteže sme sa zbavili Babiša. A Fica nechcete? ;D ;D ;D
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.
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.
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.
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.
Marek mal na mysli hlavne tých, čo to zneužívajú. Takzvané vyžírky.
Mirusi, jen si dej dokupy info o licenci.Vyžírkovia sa na to vykašľu. A on sa nimi súdiť nebude :)
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ň".
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.
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:
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é.
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)
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ějNechapu, co je na tom u knihovny spatne?
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.
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á.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ějNechapu, 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.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.
Eventualne muzu udelat double licencing a prodavat i komercni licenci, pokud nejsem fanatickym stoupencem, ze veskery soft ma byt zadarmoTo 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í:
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.Mohlo, ale moje zkušenost je odlišná, i u dražších projektů.
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)...
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
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 :-(
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.
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!!
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".
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.
Mirusi, jen si dej dokupy info o licenci. Máš tam všehochuť souborů třetích stran ;)
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ů.CitaceAle 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.
Provoz EET zaplatí zase obyčejný lidi.
CitaceJistý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)Ne. To je šidítko pro neznalé, ne elektronický podpis (a už vůbec ne elektronický podpis uznávaný našimi zákony).
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.
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.
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.
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.
Kód: Delphi [Vybrat]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.
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 SendKód: Delphi [Vybrat]
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 :-)
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). ......
někdo tady dříve řešil jestli u plátců dph součet jednotlivých částekPodle vyjádření GFŘ nemusí. Jejich zdůvodnění jsem nepochopil, protože podle mě není k EET relevantní, ale říkají, že nemusí.
zakl_nepodl_dph + zakl_dan1 + dan1 .... se musí rovnat elementu celk_trzba
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.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.
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.
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 :-\
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;
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.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.
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.
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.Á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.
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ž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.
Já se snad ožeruJakmile to rozchodím pod D7 + WinInet, přidám se :)
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.
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.
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.
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.
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.
Nejspíš je takové DIČ neplatné - zkuste to s nějakým platným...
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.
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.
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í: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.
Upravené SOAP unity + Delphi 2007 + WinInet + další bezplatné knihovny zejména XML Security Library
běhá tak skvěle, až mě mrazí, ...
Zřejmě to má souvislost s tímto.to nevypadá, neboť o řádek výš jeKód: Delphi [Vybrat]
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.
Zřejmě to má souvislost s tímto.Kód: Delphi [Vybrat]
Zřejmě to má souvislost s tímto.Kód: Delphi [Vybrat]
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 PlaygroundKód: Delphi [Vybrat]
Bylo by vhodne ho zrusit z projektu, at to nemate lidi.
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í.
Na třetí stranu je to celkem zbytečné, protože za chvíli už to nebude aktuální.
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ů.
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 ?
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ě.
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í.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í:
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.
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ě.
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.
Hmm,tak asi ne:(
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.
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ů, ...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.
Používám D10.1 update 2
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ů, ...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.
Používám D10.1 update 2
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.
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...
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
Pokud se někdo pokoušíte v Delphi 10.3.3 rozchodit knihovnu DelphiEET od Mirus77 s knihovnami Indy, možná zjistíte, že nedokážete ověřit certifikáty. Problém je v systémové knihovně IdSSLOpenSSL, kde soudruzi z NDR opět udělali drobnou chybičku.
Oficiální patch je zde: https://cc.embarcadero.com/item/30906 (https://cc.embarcadero.com/item/30906)
Tak nic,prosím smazat předchozí příspěvek.Opět byl na vině Avast,grrr....