Hlavní kategorie

Aktuálně ke stažení

Zoner INSHOP4 Manager verze 4.7
(velikost 24 MB)

 

Zoner INSHOP4 Manager verze 4.5
(velikost 24,3 MB)

 

Update verze 4
(velikost 21,8 MB)

 

Manuál pro Zoner INSHOP4 Manager
(velikost 2,5 MB)

 

Elektronická evidence tržeb (4.7.6)

Od 1.3.2017 vstoupí v platnost povinnost elektronického hlášení tržeb i pro eshopy, využívají-li platby v hotovosti, kartou nebo obdobné platby.
V Zoner inShopu bude modul EET implementován od verze 4.7.6. Zda budete tržby evidovat v systému EET a pro které platby lze nastavit.


10.2. Doplněno stanovisko k nové metodice Generálního finančního ředitelství pro online platby ze dne 3.2.2017


Hlášení o tržbách

  • Při každém potvrzení objednávky, na kterou se EET vztahuje, se v databázi vytvoří záznam o tržbě.
  • Ještě před přesměrováním zákazníka na platební bránu se na základě záznamu o tržbě vytvoří hlášení a odesílá se na server systému EET.
  • Není-li hlášení úspěšné kvůli nedostupnosti serveru EET nebo dochází k timeoutu, zůstává záznam o tržbě evidován jako neodeslaný. Při dalším pokusu o vyřízení fronty bude znovu odesílán.
  • Není-li hlášení úspěšné kvůli chybnému nastavení nebo systémovému selhání, je zákazníkovi zabráněno v pokračování na online platební bránu.
  • Je-li objednávka v jiné měně než CZK, do záznamu o tržbě se přepočítá do CZK podle aktuálního kurzu ČNB.
  • Do potvrzujícího emailu s objednávkou je vkládána účtenka EET. Nevyžaduje zásah do upravené šablony.
  • Je-li hlášení úspěšné ihned při potrvzování objednávky, do emailu s potvrzením objednávky zákazníkovi se zapisuje BKP a FIK.
  • V opačném případě se do potvrzení objednávky zapisuje PKP a FIK.
  • Každou hodinu se automaticky fronta neodeslaných hlášení vyřizuje.
  • Hlášení jsou odesílána vždy v běžném režimu.

Storno objednávky

Při stornu objednávky podléhající EET se rozlišují následující případy:
  1. hlášení ještě nebylo odesláno – neodesílá se storno hlášení, jen se stornuje záznam o tržbě
  2. hlášení již bylo odesláno, platba ještě nebyla přijata – vytvoří se nový záznam o záporné tržbě ve stejné výši
  3. hlášení již bylo odesláno, platba již byla přijata – podle nastavení se buď storno hlášení neodesílá vůbec nebo se odesílá záporná částka (je-li v jiné měně, přepočítá se podle aktuálního kurzu)

Neúspěšná platba

Pokud se zákazník vrátí z platební brány s tím, že platba nebyla provedena, má možnost buď objednávku zrušit, nebo zopakovat platbu nebo ji změnit.
Při změně platby se standardně postupuje tak, že nedochází-li ke změně celkové částky (tj. neliší se poplatek za platbu), tak se již storno hlášení ani nové hlášení neodesílá, a to bez ohledu na to, jaký nový způsob platby zákazník zvolí.
Mění-li se celková částka, původní objednávka se ihned automaticky stornuje a vytváří se nová (obsah objednávky se vloží do košíku). Při stornu původní objednávky se ihned posílá storno hlášení, u nové se pak postupuje podle toho, jaký způsob platby je zvolen (nová objednávka prochází opět pokladnou).
Pokud zákazník neučiní žádnou volbu, zůstane platba objednávky ve stavu Zadána a platba nebude dokončena. Vzhledem k tomu, že již bylo hlášení o tržbě provedeno, bude se čekat na akci obsluhy, tj. zda bude objednávka nakonec stornována či nikoliv.


Proč se s hlášením o tržbě do systému EET nečeká na potvrzení provedení platby z platební brány

Podle zákona o elektronické evidenci tržeb je nutné tržbu hlásit nejpozději v okamžiku, kdy zákazník vydá pokyn k platbě. Tento okamžik se eshop od platební brány však nedozví, resp. V nejlepším případě se eshop o uskutečnění platby dozví těsně po ní, stává se však, že se o ní nedozví vůbec nebo se značným zpožděním.
Proto se vždy posílá hlášení o tržbě před přechodem zákazníka na platební bránu, přestože je možné, že platba ve skutečnosti nebude provedena.
PayU - Při platbě přes bránu agregující více druhů plateb, z nichž některé povinnosti EET podléhají a jiné nikoliv, je situace obdobná. Zákazník si může konkrétní druh platby zvolit až na platební bráně, proto je zapotřebí provést hlášení tržby ještě před přechodem na platební bránu.

 


Export účtenek do ekonomických systémů

Pohoda

Do Pohody lze nyní odeslat účtenku v poznámce objednávky, eventuelně do dalšího textového pole Pohody. Další možnost, kterou Pohoda nabízí, je importovat účtenku k jinému dokladu připojenému k objednávce. Tu v současné chvíli ještě zkoumáme.

Money S3

umožňuje import účtenek pouze jako součást faktury k objednávce, a to jen v případě, že k platbě skutečně dojde. Na implementaci nyní pracujeme.

Money S4/S5

prozatím k možnostem importu EET účtenek do těchto systémů nemáme žádné informace.

Zákon o evidenci tržeb však nevyžaduje, aby se účtenky promítaly do účetnictví nebo na fakturu.


Zabezpečení funkčnosti

Elektronické hlášení tržeb je (pro některé platební metody) zákonná povinnost, při jejímž zanedbání hrozí značné sankce. Pro odeslání hlášení je stanovena maximální lhůta 48 hodin, a to jen v případě nedostupnosti serveru EET či jeho pomalé reakci.
Na zajištění bezporuchového provozu modulu EET proto klademe v Zoneru velký důraz.

Každý pokus o odeslání hlášení je v databázi zaznamenán včetně případné chyby, ke které by došlo.
Pokud by došlo k chybě již při vytváření záznamu o tržbě, nebude úspěšné ani potvrzení objednávky, aby se nemohlo stát, že dojde k tržbě, která nebude zaznamenána a tedy ani nahlášena.
Každý systém se může porouchat nebo přes všechnu snahu obsahovat programovou chybu. Věnovali jsme proto velké úsilí tomu, aby se případná porucha automaticky detekovala a abyste v případě přetrvávajícího problému byli o tom informováni.

Chybná hlášení

Rozlišujeme dvě skupiny chyb, pro každou platí jiné důsledky z hlediska zákona:
  1. Chyby na straně serveru EET (dočasná nedostupnost serveru, pomalé odezvy, případně síťové chyby)  – zákon připouští a umožňuje odesílat hlášení až dodatečně po pominutí problému
    Zákazníkovi je normálně umožněno zaplatit na platební bráně, hlášení zůstane ve frontě jako nedokončené a při nejbližší příležitosti se jej systém pokusí znovu odeslat. Na účtence v emailovém potvrzení objednávky se objeví místo FIK dlouhý kód BKP.
  2. Chyby na straně eshopu (chybné nastavení, systémové selhání, neplatný certifikát apod.) – zákon nepřipouští tržbu nehlásit ani ji nahlásit později.
    V tomto případě neumožní Inshop pokračovat zákazníkovi v platbě na platební bráně.
    Přesněji řečeno pro systémové selhání by bylo možné postupovat obdobně jako pro chyby ve skupině 1, my je však od chyb konfigurace neumíme vždy odlišit nebo se ani nevytvoří požadované kódy BKP a PKP, a proto je zahrnujeme do 2. skupiny chyb.

Dochází-li k chybám, bude zapotřebí zkontrolovat, k jaké chybě dochází a případně upravit nastavení. To je zapotřebí provést co nejdříve. Nevíte-li si s problémem rady, kontaktujte nás.
Po změně nastavení se vždy (je-li EET zapnuto) na serveru provádí základní kontrola nastavení, je-li úspěšná, následuje odeslání zkušebního hlášení (v ověřovacím módu se "hlásí" nulová tržba). Pokud by čekala ve frontě na odeslání chybná hlášení kvůli chybě nastavení, provede se  pokus o jejich odeslání.

Kontroly a hlášení problémů

Každou hodinu se automaticky provádí kontrola funkčnosti modulu EET Inshopu, problémy se hlásí emailem správci prodejny.
  • zda se volá vyřizování fronty
  • zda vyřizování fronty neselhává
  • zda ve frontě nezůstávají hlášení déle než určitou dobu (4,8,16 hodin)
  • zda u nejstarších položek ve frontě nehrozí překročení doby 48 hodin (po 36 hodinách) či zda již nebyla tato doba překročena
  • zda při vytváření hlášení nedochází k chybám (např. kvůli chybě v nastavení základních parametrů, vadný certifikát systémová selhání serveru apod.)
  • zda neodmítá server hlášení jako vadná (např. kvůli chybě v základních parametrech, nesprávný formát DIĆ, nesouhlasící certifikát s DIČ apod., případně i z jiných důvodů)
  • zda se neblíží konec platnosti certifikátu

Při odeslání nastavení EET se dále na serveru provádí kontrola, zda nebyl modul EET vypnut nebo přepnut z ostrého do ověřovacího módu. Pokud ano, posílá o tom hlášení správci prodejny, aby se eliminovala možnost vypnutí chybou obsluhy (např. odesláním na server staré konfigurace).


Monitoring pro správce prodejny

V Zoner inShop Manageru na hlavní stránce (dashboardu) se na widgetu objednávek zobrazuje aktuální stav modulu EET. Z widgetu objednávek je také odkaz na výpis hlášení EET.
eet-dashboard.png
Při automatické kontrole na serveru, je-li zjištěn problém, se posílá email správci prodejny, v případě vážných problémů i administrátorovi Zoneru.

Při dalších kontrolách, nedojde-li mezitím ke změně stavu, se další email posílá až po uplynutí 12 hodin. Jakmile se zjistí, že problém pominul, posílá se o tom zpráva správci prodejny.

EET-Vypis-small.png

Testování

Před zprovozněním modulu EET v ostrém režimu si můžete vyzkoušet spojení se serverem EET zaškrtnutím volby Ověřovací mód. Hlášení o tržbách se v ověřovacím módu budou na server odesílat, ale nebudou platně zaevidována a server EET nebude vracet FIK. Tržby z objednávek, které byly provedeny v ověřovacím módu, se po přepnutí do ostrého módu již neodesílají.

V agendě Nastavení/EET je v menu položka Testování, která umožňuje:
  • zapnout režim simulace dočasné nedostupnosti serveru EET, aby bylo možné vyzkoušet, jak se bude Zoner inShop chovat při řazení hlášení do fronty a při jejich zůstávání ve frontě po určitou dobu.
  • resetovat varovná hlášení – pro ladění zprávy o problému lze resetovat záznam o tom, že bylo určité hlášení již odesláno, takže se při následujícím zjištění přetrvávání problému znovu odešle varovné hlášení


Co Inshop neřeší

  • Nyní nemáme možnost ručně vyvolat hlášení tržby. Vše výšeuvedené se týkalo jen hlášení tržeb při potvrzování objednávky a případných storno hlášení.
  • Je-li část ceny objednávky placena věrnostními body, nepovažujeme je za platbu. Do EET se hlásí pouze zbývající částka zaplacená jiným způsobem.
  • Vzniká-li objednávka při nákupu na Heuréce v rámci služby Heuréka košík, není tato tržba hlášena Inshopem do EET.
  • Nijak nevyužíváme následující položky datové zprávy hlášení:
    cest_sluz, pouzit_zboz1, pouzit_zboz2, pouzit_zboz3, urceno_cerp_zuct, cerp_zuct
  •  

Stanovisko k nové metodice Generálního finančního ředitelství pro online platby ze dne 3.2.2017

Na etrzby.cz bylo vydáno nové vyjádření k online platbám, naleznete jej zde: http://www.etrzby.cz/cs/Online-platby
nazvané Stanovisko Generálního finančního ředitelství k určení okamžiku uskutečnění evidované tržby u platebních operací realizovaných prostřednictvím internetu

Citace: "Finanční a Celní správa bude v případech, kdy poplatník není schopen splnit evidenční povinnost v okamžiku stanoveném v § 18 odst. 2 písm. b) ZoET, akceptovat postup, kdy poplatník zašle správci daně údaje o evidované tržbě a vystaví účtenku tomu, od koho evidovaná tržba plyne, nejpozději v okamžiku, kdy se dozví o tom, že došlo k odepsání platby z účtu plátce (zákazníka) a jejímu odeslání poplatníkovi."

V souvislostí s tím se objevují dotazy, zda nemáme v úmyslu změnit postup tak, aby se hlášení o tržbách do systému EET odesílala až po návratu z platební brány, když to je nyní možné.
Odpověď je ne, nemáme.

Důvodu je několik:
  • Podle našeho výkladu se nová metodika nevztahuje na běžné eshopy, ale pouze na speciální případy, kdy není žádná informace o tom, že si zákazník přeje provést nákup, a tedy kdy není možné postupovat jinak.
    Např. je-li na stránce tlačítko PayPalu, které zákazníka ihned odešle k zaplacení, aniž by se o tom stránka (eshop) dozvěděla. O provedené platbě se pak obchodník obvykle dozvídá s velkým zpožděním. V Inshopu by se to mohlo týkat objednávek vytvořených službou Heureka Košík, o kterých se Inshop dozvídá rovněž až následně.
  • Existuje jisté procento plateb přes platební bránu, o jejichž výsledku se Inshop nedozví. Bylo by nutné ručně sledovat, kdy byla platba provedena a prakticky okamžitě manuálně odesílat EET hlášení.
  • Za soulad se zákonem neseme zodpovědnost před našimi zákazníky – provozovateli eshopů. Postup, kdy jsou evidovány tržby před provedením platby, je nejen možný, ale dřívějšími metodikami na etrzby.cz pro eshopy doporučovaný. Považujeme jej proto za nejméně rizikový.
  • Tak zásadní změnu funkčnosti by již nebylo možné z časových důvodů před uvedením realizovat.
 
Pokud by se v Inshopu hlášení EET vůbec neřešila, možná by se na takovou situaci dalo vztáhnout "...kdy poplatník není schopen...". Ale jaká bude odpověď na otázku kontroly, co brání použití jiného řešení než Inshop, které tržby hlásí?

Nemůžeme vyloučit, že se ve svém výkladu mýlíme, to ukáže praxe a případné pokuty či soudní spory těch, co chápou novou metodiku odlišně.