Názor k článku Technická specifikace k #EET je už online. Podnikatelé mohou být zatím v klidu od P2010 - Ackoli vlastni sluzba je navrzena kupodivu docela normalne...

Ackoli vlastni sluzba je navrzena kupodivu docela normalne (narozdil od jednoho ministerstva, ktere misto WS-Security vymyslelo svuj vlastni naprosto zbytecny paskvil), tak je spolehlivost celeho systemu, vzhledem k sankcim za kazdou ztracenou transakci 500 000 Kc zalostna.

System se chova logicky, tedy predpoklada ze klient (pokladna) vzdy obdrzi odpoved, bud potvrzeni nebo chybu. V realnem prostredi, zvlaste v zemi s tak zoufalym internetovym pripojenim jako v CR, ovsem odpoved bud neprijde nebo dokonce nedorazi na server ani pozadavek. Neexistuje zadny zpusob, jak tyto dve situace od sebe odlisit ! Jedine reseni by byla dalsi metoda, ktera se dotaze na stav transakce na serveru. Tim lze zjistit zda:

a) pozadavek dorazil, bych zpracovan, ale ztratila se odpoved
b) pozadavek na server vubec nedorazil

Vzhledem k tomu, ze v pripade a) server nevi, ze klient (pokladna) odpoved neobdrzel, a automaticky se to bere jako podvod (nevydani uctenky -> 500 000 Kc pokuta), by bylo vhodne celou sluzbu vyrazne rozsirit. Tedy:

a) zavest dalsi metodu na dotaz o stavu transakce (dle atributu uuid_zpravy), tim se rozlisi pripad a) a b) kdyz dojde k chybe v komunikaci

b) pridat druhe potvrzeni prijeti odpovedi.