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.