Ako riešiť timeout pri odosielaní eFaktúry?
Krátka odpoveď
Timeout znamená neznámy stav, nie automatické zlyhanie. Najprv zistite, či partner request spracoval, či vzniklo transakčné ID a či faktúra nebola zaradená do fronty. Opakované odoslanie robte až cez idempotentný mechanizmus alebo po jasnom potvrdení, že pôvodný pokus nevznikol.
Nie automatický fail
Timeout môže znamenať, že partner spracovanie dokončil.
Rovnaký kľúč
Retry musí byť bezpečný voči duplicite.
Overenie pokusu
Skontrolujte stav podľa submissionId alebo vlastného ID.
Záznam incidentu
Uložte čas, request ID a ďalší postup.
Podrobné vysvetlenie
Pri timeoute môže byť problém na sieti, v API bráne, u partnera alebo vo vašom systéme. Ak systém bezhlavo pošle rovnakú faktúru znova, môže vzniknúť duplicita. Preto má byť každý send attempt evidovaný a retry má používať rovnaký idempotency key.
Ako to vyplýva zo zákona
Dôkazná stopa musí vysvetliť aj neúspešné alebo neisté pokusy. Pri spore nestačí povedať, že systém spadol; treba vedieť ukázať, čo sa dialo.
Praktické príklady
- API timeoutne po 30 sekundách, ale partner neskôr pošle webhook queued.
- Systém opakuje request s rovnakým idempotency key a partner nevyrobí druhý pokus.
- Podpora podľa request ID zistí, že prvé volanie neprešlo autentifikáciou.
Najčastejšie chyby
- „Timeout znamená pošli znova.“ Bez idempotencie to môže vytvoriť duplicitu.
- „Timeout nemusím logovať.“ Je to dôležitý incidentný stav.
- „Používateľ nech klikne ešte raz.“ Ručné opakovanie má byť kontrolované.
Záver
Timeout riešte ako neznámy stav s idempotenciou, lookupom a auditom.
Právny základ
- Zákon č. 222/2004 Z. z. o DPH, § 76a
- Interné integračné pravidlá
- SLA doručovacieho partnera
Súvisiace otázky
Nie je to právne poradenstvo. Zdroje: zákon č. 222/2004 Z. z. o DPH, Finančná správa SR eFaktúra FAQ, OpenPeppol BIS Billing 3.0 a interný validačný model eFaktúra centra. Overené 7. 7. 2026.