Zoner vs. EET

Ani nám v Zoner software se nevyhnulo zavedení EET. V tomto článku vám popíšeme, jak jsme EET zaváděli, na jaké překážky jsme přitom narazili a jak se nám je podařilo vyřešit.

Zoner software tvoří řada interně více či méně oddělených poboček, které se věnují rozdílným oblastem činností a využívají různé automatizované systémy pro prodej svých produktů. Zavedení EET měl největší dopad na karetní platby, které poskytují všechny pobočky. Další zásadní vliv mělo na platformy elektronických obchodů, které Zoner poskytuje jako službu (Zoner InShop, InPage). V menší míře pak EET zasáhlo hotovostní prodej a prodej knih.

Příprava implementace

Přípravu na EET jsme zahájili druhý týden v lednu 2017, kdy bylo zřejmé, že legislativně neprojde návrh na zrušení EET pro e-shopy a tedy většina našich služeb spadne pod EET. Jediným zdrojem informací v té době byl portál etrzby.cz a znění zákona o elektronické evidenci tržeb. Velmi rychle jsme zjistili, že ministerstvo financí samo nemá jasno, jak má probíhat hlášení v případě eshopů a dokumentace je naprosto nedostatečná. Chyběly příklady pro situace specifické v prostředí online plateb, příklady pro elektronické peněženky, technická specifikace napojení na EET obsahovala logické nesmysly atd. Katastrofální je i samotné znění zákona, které je tak vágní, stručné a neurčité, že bez dalších informací prakticky není možné podle něj zodpovědně naprogramovat řešení EET.

Klíčové bylo rozhodnutí, jak se má vykládat požadavek zákona vydat účtenku „nejpozději v okamžiku vzniku tržby“. Původní verze instrukcí na etrzby.cz obsahovala výklad, podle kterého bylo nutné vytvořit účtenku ještě před přechodem na platební bránu a v případě nedokončení ji stornovat. To je bohužel velmi častý případ, který realizaci citelně komplikuje. Zákazníci totiž platí metodou pokus-omyl, zahájí několik online plateb a pak je nedokončí. Celý systém EET účtenek jsme tedy začali připravovat dle tohoto výkladu. Cca 14 dnů před spuštěním druhé vlny EET byl výklad přehodnocen, v té době už jsme ale museli mít připravenou implementaci dle původního výkladu. Díky neschopnosti Ministerstva financí dodat včas závazný výklad zákona tak nyní částečně používáme starý výklad a částečně nový výklad.

Protože výklad zákona umožňuje pro online platby poskytnout zákazníkovi účtenku v elektronické formě na jeho zákaznickém účtu, rozhodli jsme se nezasílat účtenky e-mailem, ale pouze je zobrazit na jeho účtu. Výjimkou jsou hotovostní platby, kde vydáváme papírové účtenky. Dalším problémem při přípravě implementace byl fakt, že nikde není jasně řečeno, proč a jak Ministerstvo financí údaje o tržbách sbírá a jakým způsobem je bude následně vyhodnocovat. Při nedostatečné technické specifikaci je pak obtížné si odvodit, jak má hlášení tržeb fungovat. Z pohledu softwarového vývojáře je například absurdní skutečnost, že stornování účtenky se provádí vytvořením druhé účtenky se zápornými částkami. Přitom ale mezi původní a stornovanou účtenkou není žádná technická vazba, takže nikde není jasné které storno, co stornuje.

Situace je ještě kurióznější v případě zahraničních měn, kdy se kurz vůči koruně mění v čase. Nelogické jsou i požadavky pro hlášení tržeb z elektronických peněženek, v našem případě tzv. kreditního systému. Zde je povinnost hlásit vklady do peněženky, ale pouze ty, které proběhly hotovostně nebo online platbou. Čerpání z peněženek se ale musí hlásit všechny bez rozdílu. Takže ve výsledku Finanční úřad uvidí výrazně víc čerpání než vkladů, protože dobíjení peněženek se provádí typicky bankovním převodem, který pod EET nespadá. Jak takové údaje bude Finanční úřad vyhodnocovat a co z nich hodlá dělat za závěry, to je opravdu otázka. Celkově se dá říci, že implementaci jsme dlouho prováděli „dle nejlepšího vědomí a svědomí“ a průběžně upravovali systémy, kdykoliv Ministerstvo financí vydalo další doplnění výkladu. To samozřejmě prodloužilo dobu realizace, zaměstnalo vyšší počet pracovníků a navýšilo náklady.

Vývoj evidence tržeb

Aby se řešení EET v Zoneru co nejvíc zjednodušilo, rozhodli jsme se vytvořit jeden centrální servis pro správu EET účtenek, který zajišťuje veškerou komunikaci se systémem EET. Všechna platební rozhraní internetové a softwarové divize tedy používají pro EET tento společný servis. Bohužel, uvedené řešení nebylo možné použít pro InShop a InPage, takže tyto produkty mají své vlastní servisy pro správu účtenek.

Naprogramovat komunikaci se servery EET bylo poměrně jednoduché, protože v té době již existovaly hotové knihovny třetích stran, které jsme s drobnými změnami použili. Po prostudování dokumentace jsme dokázali první testovací účtenky odeslat během pár hodin. Výraznou komplikací při vytváření účtenek jsou časové limity, do kdy má být dle zákona tržba nahlášena a vysoké pokuty za jejich nedodržení. Konkrétně, pokud vznikne technický problém, máme povinnost vytvořit účtenku nejpozději do 48 hodin od vzniku tržby. V praxi to znamená, že nemůžeme spoléhat na lidskou obsluhu pro řešení výpadků, protože o víkendech a svátcích bychom nedokázali včas reagovat na problém. Tedy každá tržba musí být zaznamenaná v databázi a servis pro odesílání účtenek se opakovaně pokouší tržbu nahlásit, dokud nedostane od serverů EET platnou odpověď s FIK kódem. Zároveň je nutné sledovat dobu od vzniku tržby, a pokud se blíží hranice 48 hodin, vyvolat poplach a informovat obsluhu.

Dále, protože i samotný servis pro hlášení tržeb může havarovat, je nutné ho nezávisle monitorovat, aby bylo garantované, že tržbu se podaří do 48 hodin nahlásit. Všechny tyto problémy vyplývají z faktu, že e-shopy na rozdíl od kamenných provozoven pracují 24 hodin denně bez lidské obsluhy.

Časově nejnáročnější ovšem bylo napojení evidence tržeb na všechna místa, kde dochází k online platbám, platbám z kreditního systému nebo v hotovosti. Tyto zásahy si vyžádaly několik týdnů práce a zaměstnaly řadu vývojářů z několika oddělení. V některých případech nebylo možné EET jednoduše zapojit do stávajícího systému a bylo nutné přeprogramovat rozsáhlejší části platebních rozhraní. Protože přístup k účtenkám a evidenci tržeb vydaných Zonerem musí mít i zákaznická podpora a administrativní pracovníci Zoneru, byli jsme nuceni dodělat podporu EET účtenek i do interního informačního systému, přes který spravujeme zákaznické služby. Specifickým případem jsou pak produkty InPage a InShop. Zde zprostředkováváme hlášení tržeb do EET majitelům e-shopů, a proto bylo nutné ještě navíc dodělat funkcionalitu odpovídající celé EET pokladně. Tedy správu certifikátů, rozhraní pro manipulaci s certifikáty, přístup k účtenkám daného e-shopu, možnost jejich stornování atd. Vývoj těchto funkcí trval více než dva měsíce.

Závěr

Vývoj a nasazení evidence tržeb v Zoneru trvalo zhruba tři měsíce, především kvůli povinnosti hlásit online platby. Zaměstnalo ve větší či menší míře cca 12 vývojářů, plus další administrativní pracovníky, účetní, zákaznickou podporu atd. Protože EET vyžadovalo zapojení klíčových programátorů, prakticky se tím pozastavila a odsunula většina plánů na první kvartál roku 2017. Celkové náklady na vývoj a nasazení EET je obtížné vyčíslit. Přímé náklady, především mzda programátorů, jsou v řádech statisíců Kč.

Nepřímé náklady, kdy místo dalšího rozvoje služeb jsme byli nuceni téměř na 3 měsíce přehodnotit plány a vytvářet systém, který firmě nepřenesl ani korunu navíc, si netroufám odhadovat. Na mezinárodním trhu IT soupeří tisíce firem o to, kdo přijde na trh dřív s novými službami, takže každá ztráta času může znamenat výraznou konkurenční nevýhodu.