Delphi + EET

[Lukas]

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áš

[Ondřej Pokorný]

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

[KarelHorky]

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

[egroups]

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

[vandrovnik]

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.

[ShaneZB]

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.

[egroups]

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.

[vandrovnik]

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.

[egroups]

Ano,tyto údaje zůstanou stejné.

[egroups]

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

 

[Marek Weyda]

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é 

[egroups]

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.

[anec]

egroups: jak to dopadlo? jaks to vyřešil?

[egroups]

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

[RadimHoly]

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