O Elektronické evidenci tržeb (EET) je v poslední době slyšet opravdu hodně. Ostrý provoz má začít 1. prosince 2016 a druhá vlna je naplánovaná na 1.3.2017. Právě ta se dotkne také mnoha e-shopů. Podívejme se tedy na to, co pro ně vlastně implementace Etržeb může znamenat. V článku budu předpokládat, že metodické pokyny zůstanou v současné podobě - tedy že EET se dotkne elektronických obchodů s platbou kartou.
Vydal jsem aktualizovaný článek, kdy již byla situace o něco jasnější.
Základní informace o etržbách naleznete v článku Petra Soukupa. Ministerstvo financí dále vydalo pokyn, který se týká právě souvislosti EET a e-shopů s platebními kartami. Bohužel je situace stále poněkud nejasná, protože je velice těžké pochopit, jak to úředníci myslí. S překladem do lidské řeči nám nedokázala pomoci ani daňová poradkyně. Ministr financí Andrej Babiš se nás nicméně snaží přesvědčit, že implementace EET do e-shopu je velmi snadná. Pojďme si to tedy rozbrat.
Situace 1 - malý e-shop bez účetního systému
Elektronický obchod přijme objednávku, obsluha ji zkontroluje, vytiskne v administraci doklad a pošle ho spolu se zbožím. Zhruba takto dnes funguje mnoho malých obchodů. Vše řeší ručně v administraci.
1. Odeslání objednávky FÚ
V případě úspěšné platby kartou e-shop odešle data o transakci na finanční úřad. Zákon hovoří o tom, že k odeslání musí dojít "nejpozději v okamžiku uskutečnění evidované tržby". Dá se usuzovat, že zde bude tolerance několika vteřin. To je velmi podstatná informace - pokud se podíváme například na platební metody GoPay, zjistíme, že se o uskutečnění platby dozvíme klidně s 10 minutovým zpožděním. Pokud tedy máme dostát zákonu, bude se muset informace o platbě přenést ještě před přesměrováním zákazníka na platební bránu. Stejná situace může nastat i u dalších bran, jako je PayPal apod. Tento bod nebude náročný na programování, schopný programátor si s tím poradí během pár hodin.
Poznámka pod čarou: Pokud by se ukázalo, že data není nutné odesílat před zaplacením, vztáhněte si následujicí body na obyčejné storno objednávky. Bude to platit úplně stejně až na ten detail, že k situaci nebude docházet tak často. Naprogramovat to ale musíme tak jako tak
Poznámka č. 2: V některých případech může dojít k situaci, kdy neznáte ani částku, kterou uživatel zaplatí. Týká se to například různých příspěvků (donation) apod. Stanovisko FÚ je momentálně takové, že pokud nemůžete platbu nahlásit do EET, nesmíte ji využívat.
2. Zpracování nezaplacených objednávek
Protože jsme poslali informaci o platbě s předstihem, budeme muset vyřešit neuhrazené objednávky. Vytvoříme modul, který bude hlídat nezaplacené objednávky a po určité době je stornuje. Není neobvyklé, že se zákazník s e-shopem domluví na jiném způsobu platby (například převodem, hotově). To nás naštěstí nijak neovlivní, taková platba už EET nebude podléhat, nebo by ji měl evidovat systém pro hotovostní platby. Tady ale trochu riskujeme kontrolu, protože budeme do EET posílat poměrně hodně stornovaných částek a to má být jedna z oblastí, na kterou se budou úředníci zaměřovat.
Mnoho e-shopů nabízí možnost opakované platby kartou v případě, kdy se platba nepovedla. Tady musíme dát pozor na to, abychom data na FÚ znovu neposlali (pokud objednávka mezitím nebyla stornována v EET systému) či naopak aby se znovu zaevidovala (pokud už ke stornu došlo). Zároveň s tím je nutné posunout datum, kdy má dojít k automatickému stornu platby, protože to původní už nebude platit. Trochu se nám to komplikuje. Pořád ale mluvíme rámcově o hodinách práce programátora.
3. Když vyprší časový limit
Obchodník má povinnost čekat minimálně 2 vteřiny při pokusu o odeslání platby do EET. Dnes už víme, že přes sliby v médiích bude s odesíláním velký problém. Musíme tedy počítat s tím, že se komunikace nepodaří a vytvoříme frontu pro opakované odesílání objednávek.
Nyní ale musíme vyřešit situaci, kdy se zatím nepodařilo objednávku odeslat na FÚ a máme platbu stornovat. Upravíme frontu, aby se platba neposlala? Nebo nyní odešleme storno a později samotnou objednávku? Dobrá a co když se nepodaří odeslat ani storno a to spadne do fronty? Zdá se, že nejjednodušší bude vše naposílat do fronty a ve zbytku systému pracovat s informacemi tak, jako kdyby došlo ke korektnímu odeslání dat.
4. Storno objednávky
Přijmete objednávku i platbu a potřebujete objednávku stornovat. Proces je stejný, jako v případě storna nezaplacené objednávky, takže to už máme vyřešeno v rámci předchozího bodu (a pokud platbu nebude třeba posílat do EET předem, musíme vše vyřešit zde). Důležité je pamatovat na skutečnost, že obsluha e-shopu musí objednávku řádně stornovat a nestačí pouze vrátit peníze. Zdá se to jako maličkost, ale hlídání těchto stavů může majitelům přidělat poměrně dost práce. Malé e-shopy se často jen domluví se zákazníkem a formálně už se s objednávkou dále nepracuje (tj. nezmění stav na storno). Zde se tedy jedná spíše o administrativní zátěž.
5. Částečné storno
Zákazník objedná různé zboží a obchodník některé položky už nemá na skladě. Dojde k částečnému stornu a zákazníkovi se vrátí část platby. Zde si troufnu odhadnout, že drtivá většina malých e-shopů toto dnes vůbec neumí řešit (nemusí) a programátor to bude muset implementovat.
6. Změna platební metody
Není výjimka, že si uživatel zvolí platbu převodem a později ji chce změnit na platbu kartou. Pokud e-shop tento proces umožňuje, je nutné opět myslet na odeslání ceny do EET. Tento krok by už pro vývojáře měl být poměrně triviální.
Situace 2 - E-shop napojený na ekonomický software
Každý systém má jinou metodiku napojení na e-shop. Pro demonstraci jsem vybral program Pohoda, nicméně to není pro účely článku podstatné - ekonomický software vám totiž (až na výjimky) s EET v e-shopu nijak nepomůže, spíše naopak. Účetní program totiž obvykle funguje v offline režimu, kdy se do něj objednávky stahují až s určitým zpožděním (často na pokyn administrátora). Z vyjádření technické podpory Pohody navíc vyplynulo, že objednávky z e-shopu nebudou vůči elektronické evidenci nijak řešit a vše je v režii programátorů obchodu. Pohoda tak bude očekávat, že při importu dat už objednávka bude mít identifikátor od EET (jinými slovy e-shop již objednávku do evidence odeslal a získal tak kód FIK).
Z toho vyplývá, že musíte řešit ty samé problémy jako e-shop bez účetního SW, plus některé další:
1. Storno objednávky
Daňový doklad k přijaté platbě musíte vystavit do 15 dnů od zaplacení. To znamená, že pokud dojde ke stornu objednávky do 14 dní, nemusíte vystavovat fakturu a ani dobropis, stačí vrátit peníze. Teoreticky tedy objednávku ani nemusíte importovat do Pohody. V takovém případě se ale e-shop musí postarat o odeslání zaplacené částky i storna do EET.
Většina obchodů ale v tomto případě objednávku naimportuje ihned a vystaví zálohovou fakturu. Pokud dojde ke stornu, odešle informaci o něm do EET sama Pohoda. Nyní tedy už e-shop nesmí odeslat storno - finanční úřad by ho dostal 2x. A protože se posílají pouze částky a nikoli například číslo objednávky, není jak tyto 2 storna sprárovat a můžete se dostat do problémů s úřady. Musíte si tak pamatovat, zda jste objednávku do Pohody odeslali (k tomu se ještě vrátím).
2. Časový limit
Teď si situaci trochu zkomplikujeme - uživatel odešle objednávku a komunikace s EET se nepovede. Dojde ke stažení dat do Pohody - kam se objednávka dostane bez FIK - a následně proběhne úspěšné odeslání částky do Etržeb. Zde zatím nemá jasno ani technická podpora Pohody, jak se tyto situace budou řešit. Pravděpodobně bude třeba naprogramovat aktualizaci, která FIK pošle do Pohody. Nicméně pokud dojde ještě předtím ke stornu objednávky, už se dostáváme do velkých problémů, co máme poslat.
3. Změna platební metody
Zákazník objedná s platbou převodem a objednávka se stáhne do Pohody. V tomto stavu nepodléhá EET, takže se nikam nic neposílá. Pokud ale dojde ke změně platební metody, máme opět problém - tentokrát se musí e-shop postarat o kompletní komunikaci s úřady bez ohledu na další podmínky.
Lidský faktor
Ještě jste se neztratili? Dobrá, podívejme se na poslední bod.
I pokud zvládneme rozklíčovat všechny stavy, správně je implementovat a otestovat, pořád můžeme narazit na lidský faktor. Co když vám například obsluha e-shopu omylem stáhne již stornovanou objednávku do účetního software? Logiky ji potom bude muset stornovat i tam, ale bude se muset ošetřit, aby nedošlo k odeslání záporné částky na EET - protože ji už odeslal e-shop.
Nebo naopak - co když obsluha stáhne objednávku ručně, ale už ji reálně do Pohody nenaimportuje? E-shop pak přenechá komunikaci s EET na Pohodě, tam ale objednávka vůbec nebude.
Závěr
Nepopírám, že některé případy budou hodně okrajové, ale na to se zákon ptát nebude. Pokud budete chtít nabízet platby kartou i po 1.3.2017, čeká vás docela hodně práce. Musíte především analyzovat procesy v e-shopu a odchytit všechny výjimky, které mohou nastat. Samotná komunikace s s FÚ opravdu není tak složitá, ale to je jen špička ledovce.
Posouzení, zda ministr Babiš říká pravdu, když tvrdí, že EET nepředstavuje žádný velký náklad, již nechám na vás.