No jo, to je tak kdyz tupci mluvi o necem, cemu vubec nerozumi. Prave ze s pomalym si nevystaci, kdyz si nekde stanovili podminku vyrizeni transakce do 2 vterin, pritom jen odeslani dat pres GPRS/EDGE ma bezne latenci az 3 vteriny. Takze cela transakce (pozadavek, vyrizeni, odpoved) se razem dostane az na cca 8 vterin.
Take jim jaksi nedochazi, ze u levnejsich tarifu nekteri operatori pocitaji minimalni jednotku 1 MB za jedno pripojeni. Takze onech 8 kB bude uctovano jako 1 MB.
Ale co chcete od podobnych "odborniku".
V podstatě máte pravdu. Je to tak, že je často (a různými ouředníky např. na MF zvláště) zaměňována rychlost přenosu dat (ve významu přenosu velkého objemu dat za jednotku času) a latence, tedy doba, která uplyne mezi odesláním paketu odesilatelm a jeho přijetí příjemcem.
A zatímco například u posílání obrázků či videa je důležité to první, a latence je nepodstatná, tak například u VoIP telefonie, aby odpovídala normám (ITU), by neměla latence vnitrostátně překročit cca 50 ms, ale "rychlost internetu", pokud je nad nějakých 100 kB, je téměř nepodstatná.
A pokud má být u EET celková odezva serveru finanční správy do 2 sekund (2000 ms), je evidentní že je zcela nevhodná technologie GPRS (latence běžně 600 - 1200 ms) a jen podmíněně použitelná je technologie EDGE (zhruba poloviční hodnoty). Navíc v tuzemských GSM sítích velmi často trvá iniciace spojení (výměna prvních paketů) podstatně déle, než je průměr. Jiná je situace u 3G či LTE, tedy "rychlého internetu", protože vedle schopnosti přenosu větších objemů dat mají tyto technologie i nízkou latenci.
Čili resumé je, že ve většině případů bude při využití této technologie "pomalého internetu" zařízení obchodníka čekat maximální nastavenou dobu na odezvu serveru finanční správy, která ovšem nedorazí včas, načež vydá účtenku bez kódu... (a vykomunikuje to se serverem dodatečně).
Takže lze očekávat, že mnohé EET transakce někde na vsi budou díky EET trvat i při plynulém provozu o nějaké 3 sekundy déle než doposud při účtování "na lokálu". A ještě budou účtenky většinou bez "fiskálního kódu". Zajímavé bude, když v nějakém tom Horním Dolíkově bude najednou telefonovat víc lidí (Fronta v konzumu: "hele Máňo, dovezli nakládačky za dvanáct, mám ti nějaké vzít...") protože BTS má k dispozici sedm kanálů buď pro hlas, nebo pro data, a hlas má vyšší prioritu... Takže data nepotečou.
Pokud se týká toho účtování po MB, to je dost lapálie. Ale v každé mobilní síti se myslím už dnes najde nějaký ten virtuál, který umí účtovat po kB.
To ja nevim. Velky problem je asi vse, staci si jen precit jak amatersky to cele vznika http://forum.mesec.cz/index.php?topic=6909.0
Prodloužení na 15 s je nepříliš rozumné, neb pak by se tu dobu čekalo na vytištění účtenky :-).
On ten "bazmek" tu účtenku vydá, ale s nějakým náhradním lokálně generovaným kódem, nikoli s tím, který by tam měl být, leč nestihne dorazit včas. Ten správný se (možná) dodá obchodníkovi až později...
Hlavní důsledek bude, že se u většiny (někde u všech) účtenek bude čekat tu maximální dobu a pak se stejně vytiskne jen "polodoklad".
A nedovzdělaní kontroloři z FÚ budou otravovat venkovské obchodníčky a hostinské z malých vesnic kde "zemřel pejsek", protože jejich "komunikace se serverem FÚ bude vykazovat odchylky od normálu".
(Jelikož těm kontrolorům na "politickém školení mužstva" jiní polovzdělaní z ministerstva říkali, že Hornochová říkala, a ta to přeci muší vědět, bo je kapacita!, že pomalý internet je v poho, prože datová zpráva má 8kB ;)).
nějakým náhradním lokálně generovaným kódem
Tak to mozna neni. Z te diskuse vyplyva, ze ten kod je obycejny UUID (Guid), stejne jako v Chorvatsku, ktery lze bezpecne generovat lokalne i bez centralniho serveru. Coz jen ukazuje zbytecnou komplikovanost celeho reseni, vyzadujici zbytecne "online" komunikaci. Lze se domnivat, ze to jde zase na ruku operatorum ...
Generovat UUID a castku by slo lokalne a pak to davkou, treba jednou za tyden/mesic posilat na server MF. Zadne z reseni stejne nezabrani tomu, aby probehla platba zcela mimo ten system.
protože jejich "komunikace se serverem FÚ bude vykazovat odchylky od normálu".
Zvlastne na mistni wifi siti z kravina, s napadenym DNS. Ale tohle je zcela mimo jejich chapani.
Když platíš kartou, tak to také trvá různě dlouho. Tohle je v principu stejné.
Platba kartou je dobrovolny akt mezi dvema (temer) rovnopravnymi subjekty, obchodnik - poskytovatel. Z nepovedene, opakovane nebo prilis dlouhotrvajici platby kartou nevyplyvaji zadne zavazne (likvidacni) sankce pro obchodnika.
Narozdil od EET nesmyslu, kde kazda platba trvajici celkove dele nez 2 sekundy (coz v praxi bude velmi caste) je problematicka. Mozna to stale neni jasne, ale nepovedenou EET transakci (ktera vyprsela, typicky kvuli problemum na siti) neni mozne "beztrestne" jen tak zopakovat. Je potreba o kazde takove platbe informovat do 48 hodin datovou schrankou, jinak hrozi likvidacni postihy do 500 000 Kc.
Jiná je situace u 3G či LTE, tedy "rychlého internetu", protože vedle schopnosti přenosu větších objemů dat mají tyto technologie i nízkou latenci.
Drobna poznamka, ta iniciace spojeni je prave u 3G dost pomala, zatimco u 4G/LTE to takove neni. Jenze levnych pristroju s podporou LTE, zvlaste pak pasma 900 MHz pro "specificke" (4x pomalejsi nez 3G) LTE od Vodafone moc neni.
Ano, ze data nepotecou je videt prave v tech lokalitach, kde nic jineho nez 2G (GPRS/EDGE) neni. Tam je casto odezva bud pres 3000 ms nebo to jde do timeoutu uplne.
No jo, ale kolik lidi o existenci virtualu neco tusi a dokazi si prave podle tohoto parametru uctovani lepe vybrat. Tady opet zcela selhava stat, viz http://www.lupa.cz/clanky/vodafone-potaji-meni-uctovani-dat/
(2) Mezní dobu odezvy nastaví poplatník pro pokladní zařízení DELŠÍ než 2 sekundy podle druhu a způsobu vykonávané činnosti tak, aby se jejím stanovením nemařil průběh evidence tržeb vzhledem k druhu a kvalitě připojení k veřejné datové síti.
Takže znova: Z ceho vyplyva, ze byla stanovena doba odezvy do 2 sekund?
Ty si asi opravdu ty problémy vymýšlíš, abys mohl trollovat.
Zajimava informace http://www.mfcr.cz/cs/aktualne/aktuality/2015/vypadek-informacnich-systemu-ares-ariswe-22937
V pátek 6.11.2015 v ranních hodinách došlo k havárii hardwaru. Nefunkční jsou aplikace ARES, ARIS, UFIS, IS SDPF, IS KSP, IS o platech, ZBAPA, BK, Exekutor, DMS portál (technologicky portál ICR). Omlouváme se za způsobené obtíže. Na odstranění závady se intenzivně pracuje.
To je panecku SLA. Bude takto fungovat i EET ? :-)
Problém není v "hledání důvodů, proč to nejde", ale v tom, že reálný fakt, "že to nemusí jít" dopadne na hlavy podnikatelů: něco, co je mimo jejich kontrolu (kvalita spojení) ovlivňuje, jakým způsobem (on-line/dodatečně) budou plnit stítem uložené povinnosti - a hrozí jim poměrně citelný postih.
Obávám se, že procento těch, kteří budou muset po večerech "odesílat", bude poměrně vysoké.
Predstavme si ted na chvili, ze ten system bude technicky opravdu fungovat (coz nebude, viz prakticky vypadek vsech online sluzeb MFCR ktery trva jiz 4 dny, viz odkaz v jinem prispevku). Co si myslite ze se tim skutecne zlepsi, krome zvysenych prijmu operatoru a uplatku/zneuziti z prodeje takto nasbiranych citlivych dat ?
A tak, ono to "z většího" patrně fungovat bude. ale nevěřím tomu, že to přinese ten tvrzený finanční efekt a bude to patrně dost nákladné. (Jinak mně to je celkem šuma fuk, neb hotovost nepřijímám...)
Mimochodem, viděl jste někdo ty OVM? Mně přijde, že Hornochová vůbec netuší, jak fungují (z většího) vesnické hospody, založené na "štamgastech". Takže také nepochopila podstatu toho, co tam říkal na začátku ten hostinský o tom, že se štamgasti přesunou "do garáže"....
Me osobne se to sice take netyka, ale z pohledu zakaznika to vse jen zkomplikuje (a zdrazi).
Silene jsou predevsim ty likvidacni sankce za nesplneni obrovsky komplikovaneho administrativniho postupu pri kazde selhane EET transakci. Bez ohledu na to, ci vina (server MF, operator, dodavatel software) to byla.
Nedokazu si predstavit napriklad situaci, kdy majitel obchodu zamestnava prodavace. Prodavac bude muset prakticky okamzite majiteli hlasit vsechny EET transakce kde doslo (k jakekoli) chybe a majitel osobne bude muset toto odesilat datovou schrankou (tezko asi preda prodavaci prihlasovaci udaje). Neni jasne jak komplikovane to hlaseni vubec bude, ze by opet 602 XML Filler ? :-) Pokud to cele nestihne do 48 hodin (paragraf 22), hrozi likvidacni pokuta az 500 000 Kc (paragraf 29). Protoze vime, ze vyse pokuty "az" se stanovuje jen dle nalady urednika, otvira to obrovsky prostor k dalsi korupci.
Vzhledem k tomu ze jen samotne pouziti datove schranky je pro mnohe lidi sci-fi je cely ten navrh zakona neuveritelna zrudnost, zcela odtrzena od reality.
Prosinec 2015: Projednání zákona o EET blokováno obstrukcemi.
Leden 2016: Zákon o EET v PS schválen a předán do senátu.
Březen 2016: Senát zákon o EET neschvaluje a vrací do PS.
Duben 2016: PS zákon schvaluje navzdory senátu (blafování demisí se p. Burešovi vydařilo).
Květen 2016: odhadované náklady na EET se navýšily na trojnásobek, první žaloby na porušení zákona o veřejné soutěži.
Červenec 2016: Operátoři smolí speciální tarify, v praxi se ukazují jako to nejdražší.
Září 2016: Spuštění EET se odkládá na duben 2017.
Únor 2017: První testování EET v reálných podmínkách. Po zadání 1000 požadavků během pěti minut systém kolabuje. Ministr uklidňuje, že půjde o kosmetické opravy.
Květen 2017: Volby. Voliči zoufale hledají pravicovou stranu s pravicovými sliby, u které je alespoň teoretická šance na pravicovou politiku po celou dobu volebního období. Ano získalo 1,9% a zůstalo "pod čarou".
Září 2017: Systém funguje, zvládl 2000 účtenek během týdne, ostré nasazení bude od února 2018.
Leden 2018: 20% drobných živnostníků ukončuje činnost. Počet nový drobných živnostníků klesá na třetinu. V poslanecké sněmovně se objevuje návrh na EEP - elektronické evidence plateb - pokud chce kdokoliv cokoliv zaplatit, musí to mít předem schváleno Ministerstvem financí.
Únor 2019: Počet offline účtenek přesahuje 85%.
Duben 2019: Ministr financí zdůvodňuje propad výběru daní hospodářskou recesí.
Květen 2019: Ztráty karuselovými podvody přesáhly 300 mld. Podle ministra financí s tím nejde nic dělat.
Červen 2019: Podíl šedé ekonomiky dosáhl 25%, hotovostní platba mezi známými se u drobných živnostníků bere jako běžná. Neznámý člověk při nákupu ve vesnické prodejně musí o nákup poprosit před prodejnou místního občana, jinak riskuje výprask od obyvatel - ti se obávají kontroly a následného uzavření prodejny.
Tohle je pripad http://www.mfcr.cz/cs/aktualne/aktuality/2015/vypadek-informacnich-systemu-ares-ariswe-22937 ktery by se mel medializovat. Uz paty den nefunguji online sluzby Ministerstava financi. Tohle by si normalni firma nemohla dovolit.
S takovou kvalitou sluzeb chteji postihovat podnikatele pokutou 500 000 Kc za nedodani informace o selhane EET transakci Datovou schrankou do 48 hodin ? Absurdni.
Tak, ona elektronizace FÚ je prostě pohádka. 5.11. jsem poskytl službu slovenskému klientovi, díky čemuž jsem se stal "identifikovanou osobou" a vznikla mi jako dosavadnímu neplátci DPH povinnost a čerstvé "identifikované osobě", přihlásit se do 15 dnů jako "plátce DPH" při obchodech s ostatními státy EU.
Chtěl jsem to mít za sebou, takže jsem hned toho 5. poslal přes EPO přihlášku (se zaručeným podpisem). EPO systém mi hlásil, že je vše v pořádku - kontroloval jsem každou stránku a ještě na konci vyjel protokol chyb. Čili jsem to odeslal, a čekal... No, dnes to dorazilo na cílový finanční úřad (za pět dnů). A dopoledne mi volá paní z registračního, že to "mám celé nějaké zvojtěné".
Takže jsme to postupně začali probírat a nakonec se šla podívat do zákona.... Výsledkem je, že "celé zvojtěné" spočívá v tom, že ve formuláři je kolonka "obrat za posledních 12 po sobě jdoucích měsíců", která u identifikované osoby reálně postrádá smysl (kdyby byl nadlimitní, tak jsem už plátcem DPH), takže jsem ji přeskočil, neb při vyplňování jsem ten obrat neznal, s tím, že se k tomu na konci vrátím a vytáhnučíslo z evidence. Ovšem když jsem došel na konec stránky a spustil její kontrolu, tak EPO ohlásilo, že je vše OK. (Ani kritická ani propustná chyba, prostě bez chyb.) Totéž při vyplňění celého formuláře... Takže jsem to odeslal a potřebné číslo nehledal. Nenapadlo mne totiž, že chybějící "nezbytný" údaj by nebyl ošetřen! Ale jak je vidět, na registračním oddělení místního FÚ mají jiný názor na možnou chybu, než měl autor kontrol celostátního systému EPO :-)
Resumé je, že zítra jdu na FÚ osobně dopsat do nového formuláře přihlášky jedno číslo (úřednice to prý udělat nesmí, no, asi ne) a podepsat papír... Přitom by stačilo pro kontrolu nastavit, že dotčený chlíveček nesmí být prázdný. A pro případ zahájení podnikání dát do informace třeba text "Nebyl-li v předchozích 12 po sobě jdoucích měsících žádný obrat, vepište nulu..."