GINTA: Mas 48 hodin na opravu.

Kazdopadne z toho ctu ze musis zejmena dokazat zes udelal vsechno proto aby doslo k naprave.

Dle povahy pak asi zrovit inventuru a hromadny doklad - se pise na tech odkazech.

KOC256:
Vygooglil si s vykřičníkem informace, kde popisují, jak pokračovat v účtování po tom co se mi posere HW.
Já se ptal co dělat s účtenkama vydanýma v offline režimu, kdy je HW kaput a já nevím kolik jich je a ani za kolik.

GINTA:
Google!

http://epodpora.mfcr.cz/...-evidence-trzeb-eet/jake-pokladni-zarizeni-pro-elektronickou-4402#porucha

Porucha pokladního zařízení | etržby
http://www.etrzby.cz/cs/porucha-pokladniho-zarizeni

GINTA: Vytahnout uctenky ze zalohy/cloudu kde je urcite mas (/rejp). Nevim co ohledne financaku. Ale alespon pro priste budes vedet, ze dulezita data maji bejt zalohovana.

Ahoj, dnes nám na tabletu vypadával internet a každá pátá účtenka se neodeslala. Říkal jsem si, že ty neodeslané pošlu večer až dojedu domů. Mezitím tablet umřel a je HW dead. Jak mám teď postupovat?

H_U_N_T_E_R: Presne tyvole, nasi na ne kleknou a bude pohoda:)

Pronájmy přes Airbnb mohou spadat pod EET, tvrdí Finanční správa - Lupa.cz
https://www.lupa.cz/aktuality/pronajmy-pres-airbnb-mohou-spadat-pod-eet-tvrdi-financni-sprava/

ILIBOR:
EDI, vytezovani faktur

NECROMAN: Myslím, že stejně jako u QR. Také obsahuje redundanci a je možné číst i poškozený kód.

PDF417 v ČR používá například sazka na svých tiketech a má na kontrolu sázky i mobilní aplikaci.

I kdyby kódu rozuměli a načetli ho v aplikaci, vůbec nic jim to neřekne, jen uvidí nějaký dlouhý string, takže je třeba u obou formátů stejně někde uvést jakou aplikací kód načíst.

NECROMAN: To je malý rozdíl v počtu modulů a získá se tím rozšiřitelnost. Je ale také otázka, zda je QR vůbec vhodný formát, myslím, že na účtenky by se díky svým vlastnostem nejlépe hodil PDF417.

89 znaků v PDF417:

SA213: user-friendly string má cca 60 alphanum znaků, na druhou stranu je to Version 3 QR kód (29x29) opoti Version 2 (24x24) u binárního zápisu, to asi nebude problém :)
BKP:1234567890abcedf;DIC:1234567890;KC:432.50;DT:201708011640

NECROMAN: Spíše jde o tu rozšiřitelnost.

SA213: to je otázka, zda preferovat lidskou čitelnost nebo minimální velikost v bajtech? Pokud je cílem, aby se to vešlo na účtenku, tak je každý ušetřený mm účtenky znát.

NECROMAN: Navrhovaný formát se mi moc nelíbí. Není rozšiřitelný ani čitelný. Inspiroval bych se QR platbou a jen zaměnil parametry které uvádí v dokumentaci. Není pak třeba ani vymýšlet další parsery, implementace co přečte QR platbu by měla i tohle, jen s budou jiné atributy.

QR Platba: "Výhodou navrženého formátu je relativně dobrá lidská čitelnost a potenciální rozšiřitelnost o specifické atributy."

SA213: dnes jsem si s tim začal hrát, první pokusy zde:
qreet/EetBinInfo.cs at master · martinsuchan/qreet · GitHub
https://github.com/martinsuchan/qreet/blob/master/Source/QREET.Lib/EetBinInfo.cs

Pro odeslání účtenky je třeba jen prvních 16 znaků BKP, dále DIČ, cena, datum s přesností na minuty a režim pokladny. Pro zakódování těchto údajů stačí jen 20 bajtů, což se vejde do QR kódu Version 2, např takto:


Zde vzorová účtenka v base64. QR lze zakódovat i binárně, ale ZXing libka z nějakého dvodu umí jen text.
Zkoušel jsem i to OCR v aplikaci Účtenkovka na účtence z Billy, ale nepřečetlo to vůbec nic. QR s dobrým error correction formátem bude úplně jinde s šancí na načtení.


Během týdne plánuji začistit tu demo aplikaci a parsování + sepsat README.md o formátu.
Bylo by fajn, pokud by se toho potom někdo chytil, i když kdo ví, jak to bude po volbách :)

ILIBOR: Často se také účtenky skenují, kdyby tam byl QR, dá se rovnou dekódovat a doplnit údaje o dodavateli.

SA213: tak že by účetní trápilo opisování údajů z účtenek jsem ještě neslyšel, ale co všechny vyloženě štve je zaskladnovani zboží z faktur..

NECROMAN:
ILIBOR:

Myslím, že takový formát má smysl nehledě na situaci s EET, tam bych využití viděl spíše jako vedlejší. Potřeba opisovat údaje z účtenek byla i před EET.