Vlákno názorů k článku Jak EET dopadne na e-shopy: bude se zdražovat, komfort poklesne od Karel - Ve chvíli, kdy dostane web shop informaci z...
-
Karel (neregistrovaný)
Ve chvíli, kdy dostane web shop informaci z clearingového centra, tak už je na EET pozdě. Vy musíte zaregistrovat účtenku nejpozději v okamžik platby a ne až ve chvíli, kdy vám platbu potvrdí platební brána atd. Takže pokud se vám třebas stane, že zákazník zadá a odmáčkne platbu kartou a vám potvrzení dojde až za 20 minut (to se tak v jednom ze sta případů stane), tak jste porušil zákon o EET a hrozí vám obrovská pokuta.
Řečeno jinak to samé: EET se musí stát nejpozději v okamžik, kdy zákazníkovi odešly peníze. Ne v okamžik, kdy to zprostředkovatel oznámil obchodníkovi a už vůbec ne až v okamžik, kdy vám dojdou peníze.
Co jsem viděl návrh řešení, tak byl dost legrační: EET evidovat ihned, jak zákazník přejde do platební brány. A pokud k platbě nedojde do 24 hodin, tak to EET zase zrušit. Vaše "zaeviduj_platbu() do funkce zpracuj_prichozi_platbu() " řešením není, je to pozdě.
Metodicky to bylo připravené tak, že EET bude registrovat platební brána, která jediná je u platby přítomna. Ale z toho sešlo, protože řada jich není ani v ČR a navíc by ta evidence byla k ničemu. Pro přepravní společnosti a dobírku to tam ale stále zůstalo, tam EET nevystavuje ten, kdo vám zboží prodal, ale řidič, kterému dáte peníze.
-
Skřetík (neregistrovaný)
Pokud vám to přijde implementačně zásadně jednodušší než u kamenného miniobchůdku, pak to skutečně nechápete. Pokud má ten miniobchůdek málo plateb, může to řešit skrze tablet či appku. Do e-shopu ale nic takového nemáte, je to třeba doprogramovat, a to jsou bez potíží jednotky MD, zvlášť u starších e-shopů.
-
Tomáš2 (neregistrovaný)
ano, první věc je implementace, řada systémů nemá žádné callbacky, volání či eventy poté co v administraci změníš stav nebo naopak příjde platba, musí se tohle na míru do eshopu doprogramovat, to je věcí je nákladů.
Zásadní problém je ale v různorodosti nákupního procesu, u řady způsobů platby prostě žádné volání do eshopu neputuje a nebo eshop neví konkrétní částku v korunách. Existují brány (prodejní portály), který za tebe vyberou platbu (vč. daní a poštovného - například Amazon) a zákazníkovi poskytnout produkt (buď ho pošlou nebo ho nechají elektronicky stáhnout umožňuje-li to jeho povaha), přitom prodejcem jsi ty, ale o samotném nákupu se dozvíš až později.
EET vyžaduje, aby celý proces byl realtime a zákazník měl vystavenou účtenku v momentě platby, jenže eshop se dozví o platbě klidně desítky minut později nebo až v souhrnech či získá informace jen o části samotné platby (v eurech a bez poštovného např.).
-
Jasně, tyhle problémy (hlavně ve vztahu k platbám kartou, kdy třeba platbu z Číny může ještě autorizovat nějaký živý filtr) si představit dokážu. Právě pro ně mě ale přijde samozřejmé a jednoduché to Vaše "legrační řešení".
Dalo by se stejně samozřejmě řešit i situaci "obchodník se o platbách dovídá až dodatečně v jednom balíku", tedy evidovat EET v okamžiku vytvoření objednávky a v případě jejího nedokončení (zákazník nezaplatí a objednávka expiruje) to zase v EET vystornovat.
-
Pokud je e-shop v takovémto "plně outsourcovaném" módu, kdy nedostává online ani objednávky, tak má holt s EET smůlu. V takovém případě může (a měl by) EET řešit přímo ten prodejní portál, který má data online. Portál, který tuto službu prodejcům nenabídne, asi ve světě EET dlouho nepřežije (nepůjde ho legálně používat).
Zahraniční portály jsou samozřejmě jiná kapitola, viz můj příspěvek níže.
-
České portály se budou muset holt nějak přizpůsobit nové právní situaci. Zahraniční portály typu Amazon jsou samozřejmě mrzutost, která může být ve vztahu k EET úplně nepoužitelná. Každopádně ale prodejce využívající zahraniční portál od začátku ví, že veškeré problémy se slaďováním prodeje s českým právem jdou za ním. Jde tedy o značně rizikový prodejní kanál, který se může ze dne na den stát noční můrou.
Nemusí to být jen případ EET, jak by se takový prodejce vypořádal třeba s přechodem na Euro, kdyby třeba probíhal stejně jako na Slovensku? Tam bylo třeba v přechodném období ukazovat každou cenu zároveň jak ve Sk, tak v eurech, přičemž navíc "slovenská" eurová cena byla jiná od eurové ceny pro zbytek světa.
-
Skřetík (neregistrovaný)
Jenže pokud to zboží prodáváte vy, musíte informace o platbách zasílat vy, nikoli portál. Ergo:
* buď portál nabídne řešení, ale pak mu musíte dát k dispozici své klíče (bez nich informace nepodepíše) - pak to máte za 50 000 Kč (povinnost... blablabla klíče)
* nebo portál řešení nenabídne, pak máte případný prodej za 500 000 Kč
* nebo musíte přes portál přestat prodávat -
Portál spadne pod §8 (nepřímé zastoupení). V principu jde o to stejné, jako když svěříte autobazaru auto, aby Vám ho v komisi prodal. Vztah komisionář-komitent.
Pak opravdu eviduje Portál (autobazar), i když to zboží (software/auto) vůbec není jeho. Eviduje dokonce i v případě, že celou tržbu (100%) pošle majiteli zboží.
Eviduje na svoje DIČ, se svým klíčem (ano.. i když to vůbec není jeho tržba).
Pokud vám portál pošle peníze na účet (což je pravděpodobné), tak už nic neevidujete.
Jo.. Nedává to smysl, ale takto to autoři EET chtějí. EEt není o účetnictví, o tržbách, daních. Je to jenom sledování toku peněz. Je to v tom Metodickém pokynu vysloveně napsané.
Mrkněte prosím na ten §8 zákona 112/2016(zákon o EET), do Metodického pokynu, na místo, kde se nepřímým zastoupením zaobírá (strana 9 dole a dále), případně na důvodovou zprávu k zákonu o EET. Tam je to nepřímé zastoupení taky docela dobře vysvětleno.
IMHO můžete být docela v klidu (i když samozřejmě jistě to říct nemohu bez toho abych znal přesnou podstatu obchodního vztahu, který máte s portálem).
-
fd (neregistrovaný)
Zjevne nemate znalosti dostatecne, spise podle vaseho vyjadrovani vubec zadne. Platbu je treba zaevidovat nejpozdeji k casu jejiho uskutecneni, a ten v moha pripadech prodejce vubec nezna a ani nikdy znat nebude.
Prodejce se tak maximalne dozvi, ze za dane obdobi mu bylo pripsano v sume Y plateb za X penez. Klidne s nekolikamesicnim zpozdenim - coz je naprosto bezne treba u prodeje SW.
A to jsme stale u primitivni casti - odeslani nejakeho XML. Co teprve kdyz zakaznici zacnou (jiz zaplacene) objednavky menit, zbozi vracet, a vy jim asi tak tisicem ruznych zpusobu vracite penize. Dokonce jim je v mnoha pripadech nemusite vracet ani vy, ale nektery z clanku distribuce. A vy se o tom nemusite ani dozvedet. Presto k nejakemu pohybu penez doslo a tudiz mate povinost evidovat, jen jaksi nevite jak a co.
Predstavte si pak, ze mnohe eshopy funguji jako sberny, zadna online komunikace s nejakym ucetnicvim, proste jen posbiraji objednavky, jednou za cas (treba den) se prenesou data, a terpve v tento okamzik se prodejce dozvi, co kdo chce. A nekdy, ve specialnich pripadech, jak to zaplatil. Prevazne ovsem vi tak maximalne ze to zaplaceno (asi) je, ale take byt nemusi, zalezi na mnoha okolnostech.
-
Článek vypadá kvalitně, ale ani po jeho přečtení stále nechápu, proč zrovna kolem e-shopů je takové extra haló. Jelikož u e-shopů stejně každá platba prochází nějakým clearingovým systémem, mělo by snad stačit přidat jedno volání API zaeviduj_platbu() do funkce zpracuj_prichozi_platbu() + ekvivalent do funkce vystavující dobropisy, ne? Pořád mi to přijde implementačně zásadně jednodušší, než u kamenného miniobchůdku vypisujícího nyní papírové paragony.
Zmatek kolem toho, jaké všechny platby evidovat, by se dal jednoduše rozseknout: Evidovat úplně všechno bez rozdílu. Nebo zákon výslovně zakazuje evidovat i třeba ty bankovní převody? (Pokud ano, zajímala by mě motivace; samozřejmě jsem líný hledat to někde v důvodové zprávě.)
Příklad o brigádnících vyřizujících vratky mi taky moc nedává smysl - už teď snad firma potřebuje mít podchycené, že všechny vratky jsou reálné (existuje k ním příslušná faktura/příchozí platba) a brigádník jen nerozdává z firemního svým kolemjdoucím kámošům, ne? Oč je dobropis složitější/citlivější, než vydaná faktura?
-
Podle toho, co vidím jako uživatel, tak malé e-shopy v 99% běží na hotovém prefabrikovaném řešení a dostanou EET na podnose s ním (sami musí zařídit jen tu registraci/certifikát, což je jen další kapka v běžném administrativně-byrokratickém moři). Kdo má nějaké vlastní bastlřešení, je stejně dávno zvyklý, že jeho údržba a rozvoj pořád něco stojí. Jednotky MD jsou (nemáte-li pekelně dobře placené programátory nebo nejste na hraně krachu) jen zlomkem ročního zisku.
-
Tomáš2 (neregistrovaný)
právěže ne, je to běžný způsob prodeje mnoha komodit. Např. u prodeje SW si ho neprodávám sám, ale mám ho třeba na steam.com nebo slunecnice.cz (jen příklad) a přitom jsem prodávající já a zákazník ho kupuje přes prostředníka (portál ode mě) a portál zajistí i distribuci, o žádné platbě se několik týdnů nedozvím, mohou max. sledovat nějaké statistiky.
-
Tomáš2 (neregistrovaný)
to jasně, riziko změny legislativy chápu, ale tady se jedná o dost rázný zásah do možností českých firem prodávat zboží zahraničním zákazníkům na mezinárodních portálech.
Jedná se o mnohamiliardový byznys, který se tím utne, ebay, amazon a stovky dalších používaných portálů nebude možné snadno používat. Přitom se nejedná o zákaz v zákoně, ale jen o nedomyšlený způsob jak procesně něco řešit, neřeší se tím žádné krácení, žádné jiné problémy.
Prodej SW a her v podstatě ani jinak nefunguje, málokdo má infrastrukturu, aby si to sám prodával, zasílání na CD již není běžné.
-
Tohle vypadá jako řešení.
Povinnost evidovat do EET a vystavit účtenku má ten, komu se kartou platí, tedy ten portál. Ovšem jen pokud je to český subjekt, jinak ji nemá. Takže Amazon.de nemusí.
A našemu podnikateli pak posílá peníze nejsíš převodem (nebo na kartu?), takže už to také nemusí evidovat.
ČLÁNKY DO MAILU