Opakované zaslání tržby
Closed this issue · 7 comments
Jak řešit případné opakované zaslání tržby při výpadku sítě nebo jiné chybě?
Cituji:
_Může se stát, že je třeba tržbu zaslat opakovaně (například proto, že jste neobdrželi FIK). Při opakovaném odeslání tržby je třeba v datové zprávě:
- změnit v oblasti "Hlavicka"
- UUID zprávy,
- datum a čas odeslání zprávy a
- příznak prvního zaslání a
2. opakovat přesně stejné údaje v oblasti "Data" a "KontrolniKody".
Vlivem odlišných údajů v oblasti "Hlavicka" je třeba celou zprávu znovu podepsat._
Jak tedy správně opakovaně odeslat tržbu, pokud již byl vygenerován a na účtenku zapsán BKP a PKP?
Napadá mě odeslat komplet nový požadavek, ale matoucí je výše uvedený bod 2 "opakovat přesně stejné údaje v oblasti "Data" a "KontrolniKody"" kde Data jsou jasná, ale "KontrolniKody" mi už ne a lze to tedy řešit touto knihovnou?
Přesně jak píšeš,
1, vygeneruješ nové UUID, což za tebe řeší funkce UUID::v4()
2, dáš aktuální datum a čas, tady předáš new \DateTime();
3, a změníš příznak prvního zaslání z TRUE na FALSE což řeší toto
Potom celou zprávu podepíšeš a uchováš si jen povinné kódy.
Opakované platby touhle knihovnou lze řešit, pokud nastavíš všechny příznaky. Ale technologicky to řešené není, neboť je tato konstrukce na samotnou knihovnu zcela složitá. Protože někdo chce toto ukládat třeba do databáze a někdo by si tento stav třeba zaslal skrze REST API. Tak že jde o to aby si každý nad touto knihovnou napsal svůj vlastní ovladač, který toto by opakoval. Už jsem měl i v plánu napsat nějaký obecný FileSystem ovladač, ale bohužel jsem se k tomu ještě nedostal.
#Edit: Vidím že ses ptal na tu sekci KontrolniKody. Tohle si musím ověřit, a dám ti sem vědět. To přesně nevím jak to je. Ale pokud by bylo třeba předat kontrolní kódy, tak to mi příjde jako kravina. Nicméně se na to podívám.
Ano. Ještě se musí pro opakované odeslání nastavit dat_trzby na datum, kdy byla platba fyzicky vytvořená. Datum odeslání jak popisuješ, tedy new \DateTime().
Možná mi jenom není jasné samotné fungování EET v případě opakovaného odesílání. Snad nejsem sám :) Původně jsem si myslel, že se prostě celá zpráva odešle znovu, jak píšeš a jak jsem nyní doplnil. Ale tím dostanu úplně nový BKP a PKP a nebude souhlasit s tím, který je na účtence. A onen druhý bod, který zní: "opakovat přesně stejné údaje v oblasti 'Data' a 'KontrolniKody'." mě dnes zarazil. Data jasné, to jsou informace o platbě, ale Kontrolním kódům zřejmě moc nerozumím a proč je tedy opakovat.
Knihovna se mi moc líbí, z dostupných, jen pokud by tedy byla povinnost nějak opakovat kontrolní kódy, bylo by fajn je mít kam jednoduše doplnit. Nevím, jak je tam jinak nyní dostat :) Ano, stydím se :)
Ano, je v té knihovně chyba a špatně odesílá opakované chyby. Měním tento task na závažnou chybu, a budu se snažit to co nejdřív fixnout. Do půlnoci aby byla verze projetá i testama.
Ale všiml jsem si, že i knihovny v Jave i PHP knihovna od Slevomatu to neřeší. Sice je tam datová položka prvni_zaslani, ale není provázána s poslední EET platbou.
Budu muset upravit i README, kvůli této chybě.
Jako rychlej fix jsem udělal, že do Receiptu jsem přidal nové dvě datové položky BKP a PKP.
S tím že když se generují kódy BKP a PKP tak když Receipt již tyto má, tak se negenerují ale předají se do datové zprávy ty z Receiptu. Řeší se to tady.
Není to zrovna košér řešení, ale jako fix to prozatím stačí. Původníma testama to prošlo, tak že kompatibilní s původní verzí v3.0.0 to je.
Udělal jsem i example.
Popsané je to tady (14. Opakované zaslání tržby).
Jsi skvělý a snad jsi to někde i ověřil, že se to takto má opravdu odesílat, protože ač z toho nejsem úplně chytrý, pochopil jsem to právě takto.
Je to ověřené. Přesně jejich dokumentace píše:
Po několika hodinách je připojení obnoveno a zařízení může zprávu odeslat znovu. Celá zpráva bude totožná s původní zprávou (stejné bude i Datum a čas přijetí tržby, také PKP a BKP). Výjimkou jsou položky elementu , kde se budou údaje při opakovaném odeslání lišit následovně:
Opakovaně zaslaná zpráva má být podepsána stejným certifikátem (resp. privátním klíčem), jako původní zpráva. Při opakovaném zaslání nemá být znovu generováno PKP a BKP, jelikož tyto kódy se při opakovaném zaslání nemění.
Ta závorka je hodně důležitá, tak že ano měl si pravdu. A dává to logiku, že je třeba původní platbu provázat s tou starou. Aby si mohl uživatel vlastně ověřit pomocí BKP v systému a nebo to mohl hodit do té loterie. Tak že verze v3.0.1 dává logiku.
Ještě připravuji nějakou ukázku mimo, jak řešit opakování. Pokud to stihnu, tak to hodím jen do gistu, nebo možná do examples. Uvidím 😄.
Ještě zkusím si tuto skutečnost raději ověřím u úřadu, ale myslím že by to mělo být tak jak píšeš. Tak že spíš já děkuju tobě, chlape! 👍
Kdybys potřeboval, tak tady jsem udělal návrh pro rozšíření základního Dispatcheru, o logování do Firebase + opakování plateb. Je třeba ale nainstalovat nějaká rozšíření.