Dodavatel slíbil podporu EET, ale podnikatel stále neví, kdo připraví certifikát, označení jednotky a kontrolu neodeslaných tržeb. Právě tyto mezery je potřeba uzavřít před spuštěním. Za připravenou pokladnu považujte až sestavu s potvrzeným nastavením, proškolenou obsluhou a dohledatelným výsledkem zkoušek. Samotná aktualizace aplikace není celý projekt.
Průvodce vychází ze zákona č. 180/2026 Sb. a veřejných postupů ověřovaných 25. října 2026. Je psaný před dostupností nových funkcí EET v DIS+ oznámenou od 1. listopadu 2026. Nejde proto o tvrzení, že jsme budoucí rozhraní sami použili. Popisujeme přípravu a přejímací podmínky, které následně provedete podle skutečně dostupných pokynů.
Nejdříve určete rozsah povinnosti
Než začnete generovat technické údaje, popište vlastní platby a možné výjimky. Jinou situací je osobní úhrada na provozovně a jinou vzdálené placení. Také internetová objednávka může skončit platbou až při převzetí. Název prodejního kanálu tedy nestačí k nastavení jedné obecné volby pro všechny případy.
Uložte si seznam používaných platebních cest, prodávajících subjektů a příjemců peněz. Pokud pracujete se zprostředkovatelem, zjistěte jeho smluvní roli. Technik potřebuje jednoznačné zadání, který tok má jak zachytit. Neměl by sám odhadovat právní klasifikaci podle toho, že aplikace označuje objednávku jako online.
Provozní mapu vysvětluje článek EET u pokladny, QR plateb a rozvozu. Jakmile je rozsah vyjasněný, lze přidělit odpovědnosti za nastavení. Nejasné výjimky nebo zastupování dořešte před ostrým provozem, nikoli prvním ručním přepsáním transakce.
Sepište zařízení a verze
Připravte seznam hlavních pokladen, mobilních zařízení a aplikací, které mohou vytvářet evidenční událost. U každé zapište verzi, dodavatele a způsob připojení. Samostatně evidujte objednávkové aplikace a terminály. Jedna značka zařízení neprokazuje shodnou verzi softwaru ve všech provozovnách.
Dodavateli pošlete přesnou sestavu. Požadujte potvrzení, zda potřebuje aktualizaci, změnu tarifu nebo zásah technika. Pokud je zařízení starší, ověřte podporovaný operační systém a dobu další podpory. Vlastnictví pokladny z původní EET samo nezaručuje kompatibilitu s novým řešením.
Nákup nového hardware nemusí být automaticky nutný. Podstatná je schopnost podporovaného řešení odeslat požadované údaje a přijmout výsledek. Přesto nehodnoťte jen technické minimum: pracovníci potřebují čitelný stav a použitelný postup při chybě. Zařízení schopné odeslat zprávu může být pro celý provoz stále nevhodné.
Připravte oprávněný přístup do DIS+
Veřejný postup počítá s přihlášením k evidenci přes Daňovou informační schránku plus na portálu MOJE daně. Nejdříve ověřte, kdo za podnik jedná a kdo má potřebné oprávnění. Nepředávejte dodavateli vlastní bankovní identitu nebo přihlašovací prostředek jen kvůli pohodlí instalace.
Pokud má část úkonů provádět zástupce, vyřešte rozsah oprávnění odpovídajícím způsobem. Je rozdíl mezi pomocí s instalací a přístupem k daňovým údajům. Technik může potřebovat pokladní certifikát a návod, nikoli možnost neomezeně prohlížet další agendu. Rozsah přístupu přizpůsobte skutečnému úkolu.
Při přípravě si ověřte dostupnost přihlášení ještě před plánovaným termínem instalace. Zapomenutý přístup nebo neaktivní schránka mohou zdržet celý projekt. Údaje neukládejte do společného veřejně dostupného dokumentu u pokladny. Provozní návod pro směnu má obsahovat postup a kontakty, nikoli citlivé přihlašovací prostředky.
Evidenční jednotka není pouze kamenná provozovna
Zákon vymezuje evidenční jednotku šířeji. Může jít o provozovnu, web nebo aplikaci umožňující přístup ke zboží či službám, dopravní prostředek nebo samotného poplatníka v příslušném rozsahu. Neomezujte proto soupis automaticky na adresy obchodů. Posuďte i rozvoz a další způsob činnosti.
Před získáním certifikátu se oznamují potřebné údaje o jednotkách. Připravte jejich druh, identifikaci, převažující činnost a informaci o evidovaných tržbách. Konkrétní povinnost vychází ze skutečného uspořádání podniku. Dvě pokladny na jednom místě nejsou automaticky dvě samostatné jednotky.
Vytvořte vlastní přehled srozumitelných názvů. U každé jednotky pak přiřaďte zařízení a odpovědnou osobu. Číselné označení přidělené systémem uchovejte přesně; nepřepisujte je podle názvu pobočky. Při pozdější změně umístění potřebujete vědět, které údaje se mají upravit a kde jsou používané.
Certifikát chraňte jako součást oprávnění
Pokladní certifikát slouží k autentizaci datových zpráv. Získává se podle zveřejněného postupu a instaluje do použitého řešení. Nemá se stát volně sdílenou přílohou v interním chatu. Zákon ukládá zacházení bránící zneužití a řešení situace, kdy ke zneužití došlo nebo hrozí.
Určete, kdo certifikát vytvoří, uloží a předá k instalaci. Zjistěte, kde je jeho bezpečná záloha, kdo k ní smí a jak se postupuje při ztrátě zařízení. Pokud dodavatel spravuje více klientů, ověřte správnou identitu před nahráním. Certifikát jiného subjektu nelze napravit pouhou změnou názvu na displeji.
Ptejte se také na obnovu platnosti. Podpora automatické obnovy závisí na řešení a příslušném postupu. Nezaměňujte ji za automatický příslib bezúdržbovosti. Podnik má vědět, kde uvidí stav a kdo zasáhne, pokud obnova neproběhne. Záznam odpovědnosti může být součástí předávacího protokolu.
Instalace se liší podle aplikace
Nevytvářejte jeden univerzální návod kliknutí pro všechny pokladny. Umístění nastavení, způsob importu a potřebná oprávnění se liší. Použijte aktuální dokumentaci konkrétní verze. Pokud postup provádí technik, požadujte záznam výsledného nastavení v rozsahu, který neodhaluje citlivé klíče.
Po instalaci ověřte identitu poplatníka, označení jednotky a zařízení. Kontrola názvu firmy v záhlaví dokladu sama nestačí; údaje použité pro evidenci mohou být nastavené odděleně. Technik má ukázat, kde se informace kontrolují a co smí případně měnit vedoucí provozu.
Zároveň ověřte datum a čas zařízení i chování po restartu. Provozní záznamy musejí být časově vysvětlitelné. Neprovádějte ale náhodné přenastavení hodin jako způsob řešení neodeslané operace. Při závadě zachovejte původní údaje a postupujte podle podporovaného návodu.
Doba odezvy není odklad evidence
Zákon stanoví mezní dobu odezvy nejméně dvě sekundy, s přihlédnutím k povaze činnosti a kvalitě připojení. Jde o komunikaci zařízení se správcem daně, nikoli o obecné pravidlo, že můžete s evidencí běžně čekat. Nastavení má odpovídat skutečným podmínkám a nesmí mařit průběh evidence.
Požadujte vysvětlení, co obsluha uvidí při překročení této doby. Může jít o čekající záznam, chybu nebo jiný stav podle aplikace. Pracovník potřebuje rozpoznat další krok a přitom nebrzdit běžnou práci zbytečným ručním přepisováním. Přesný postup musí dodat poskytovatel použitého řešení.
Při překročení mezní doby se údaje zasílají bezodkladně po odstranění příčiny, nejpozději do 48 hodin od uskutečnění tržby. Tuto hranici nepočítejte až od objevení závady. Do provozního postupu patří pravidelná kontrola čekajících zpráv, aby neodeslané operace nezůstaly několik směn bez povšimnutí.
Testovací a produkční prostředí nezaměňujte
Zkouška v testovacím prostředí slouží k ověření komunikace a integrace. Není důkazem, že je produkční konfigurace hotová. Před ostrým spuštěním musí být správně zvolené prostředí, identita a certifikát. Záznam o úspěchu má obsahovat i informaci, kde byla zkouška provedena.
Se skutečnými platbami zacházejte odlišně od modelových požadavků. Nevytvářejte smyšlené ostré tržby jen kvůli demonstraci tlačítka. S dodavatelem určete podporovaný způsob přejímky a první skutečné transakce. Pokud vznikne chybný produkční záznam, jeho náprava musí být dohledatelná podle správného postupu.
Přejímací protokol nemusí obsahovat citlivé identifikátory v plném rozsahu. Potřebuje ale prokazatelný vztah ke konkrétní sestavě a výsledku. Věta otestováno bez uvedení prostředí, verze a scénáře poskytuje málo informací. Při pozdější závadě z ní nezjistíte, co bylo skutečně ověřeno.
Projděte pět přejímacích situací
Nechte předvést běžnou platbu a přijetí odpovědi. Potom výpadek spojení, pozdější odeslání a správné dohledání. Přidejte částečnou opravu a platební tok z další aplikace, pokud jej používáte. Každý scénář musí mít očekávaný výsledek, skutečný výsledek a odpovědnou osobu.
| Scénář | Co má přejímka prokázat |
|---|---|
| Běžná platba | Správné údaje a dohledatelná odpověď |
| Nedostupné spojení | Uchování operace a viditelný čekající stav |
| Obnovení spojení | Správné doslání bez nového nezávislého prodeje |
| Částečná oprava | Peněžní a evidenční návaznost |
| Další platební kanál | Jednoznačně určený evidující systém |
Podmínky testu přizpůsobte skutečné sestavě. Bezpečné přerušení připojení má proběhnout podle dohody s technikem a v určené chvíli, ne během cizího živého prodeje. Při zkouškách nepoužívejte zbytečně osobní údaje zákazníků. Cílem je ověřit proces, nikoli vytvářet nepotřebná ostrá data.
Každá integrace potřebuje vlastní potvrzení
Pokladna může správně evidovat hotovost a přesto nesprávně přijímat platby z QR aplikace. Při více systémech proto nezakončete kontrolu běžnou účtenkou z POS. Nechte projít všechny relevantní cesty a ověřte, kde vzniká zpráva. Jeden účet se nemá bez vědomého důvodu proměnit ve dva nezávislé evidenční prodeje.
U objednávkových platforem a zastupování předem vyjasněte právní zadání. Dodavatel technicky nastaví výsledek, ale potřebuje vědět, kdo je poplatníkem a kdo je případně pověřený. Smluvní vztah neodvozujte z textu integrace na webu. Vzor vypořádání a dohoda partnerů jsou důležitější než obecný marketingový popis.
Školení rozdělte podle rolí
Obsluha má poznat běžný stav, chybu a nejasný výsledek. Vedoucí potřebuje seznam neodeslaných operací, možnost dohledání a kontakt podpory. Majitel musí znát přístupy, správu certifikátu a změny sestavy. Účetní potřebuje rozumět podkladům a tomu, jak se opravuje prodej oproti refundaci.
Pro každou roli připravte krátký vlastní postup. Neopisujte celou technickou dokumentaci na papír u pultu. Uveďte několik konkrétních situací a bezpečný další krok. Citlivá administrace nemá být součástí běžného přístupu brigádníka jen proto, aby se k ní vedoucí někdy rychle dostal.
Ověřte školení prakticky. Pracovník má bez nápovědy obchodníka najít čekající operaci a vysvětlit, komu ji předá. Pokud postup neumí, doplňte návod a zkoušku zopakujte. Podpis prezenční listiny sám neprokazuje schopnost řešit konkrétní závadu během směny.
Plán prvního týdne
Před spuštěním stanovte, kdo každý den kontroluje stav a kdy eskaluje závady. V prvních dnech mohou být důležité i drobné změny personálu nebo nabídky. Sledujte zejména neodeslané záznamy a neočekávané rozdíly mezi kanály. Neměňte ale plošně nastavení bez vysvětlení příčiny.
Ukládejte záznam konkrétního případu: čas, zařízení, typ operace, zjištěný stav a výsledek řešení. Nepište do běžné podpůrné komunikace více osobních údajů, než je potřeba. Důležitá je identita transakce, nikoli seznam zákazníků. Dodavatel má dostat dostatek podkladů pro dohledání bez zbytečného sdílení.
Po týdnu vyhodnoťte otevřené závady a aktualizujte provozní návod. Příprava nekončí prvním zeleným potvrzením. Končí stavem, ve kterém běžná směna zvládá provoz a vedení dokáže doložit postup při chybě. Přesně tuto vlastnost by měla zachytit přejímka od dodavatele.
Než podepíšete převzetí
- Potvrďte identitu poplatníka, jednotek a zařízení.
- Uložte verzi aplikace a seznam podporovaných platebních cest.
- Zkontrolujte správu certifikátu a odpovědnost za obnovu.
- Projděte výpadek, doslání a opravu v určeném prostředí.
- Vyžádejte návod pro obsluhu, podporu a kontrolu neodeslaných údajů.
Neznámý výsledek označte jako neověřený. Není poctivé převzít budoucí funkci jen na základě příslibu, pokud ještě nebyla pro danou sestavu předvedena. Současně není nutné automaticky kupovat nový hardware bez posouzení stávajícího řešení. Rozhodujte podle konkrétní schopnosti a doložených podmínek.
Připravte přehled odpovědností pro dvě provozovny
Vlastní model může zahrnovat obchod a mobilní prodejní místo jedné firmy. Majitel odpovídá za zadání a oprávnění, technik za konkrétní instalaci, vedoucí každého místa za provozní kontrolu. Účetní posuzuje návaznost podkladů. Takové rozdělení neřeší všechny právní odpovědnosti smluvně, ale pomáhá zabránit tomu, aby důležitý úkon nepovažoval každý za práci někoho jiného.
Ke každé jednotce přiřaďte hlavní a náhradní zařízení. Ověřte, zda se při použití zálohy mění technická identifikace a jaký postup vyžaduje software. Přenosná pokladna používaná na více místech potřebuje jasné zadání podle skutečné činnosti. Není správné měnit označení náhodně podle toho, kdo ji zrovna drží.
U společné správy uchovejte rozlišení přístupů. Vedoucí obchodu nemusí spravovat certifikáty celé firmy. Technik zase nemusí znát přihlášení k další daňové agendě. Vymezte oprávnění a způsob předání potřebných prostředků tak, aby bylo možné spolupráci ukončit bez ztráty přehledu nad nastavením.
Před ostrým startem proveďte samostatnou přejímku obou míst. Úspěch na hlavní provozovně neprokazuje připojení mobilního stanoviště nebo správnou identifikaci druhého zařízení. Uložte výsledek každé sestavy a seznam rozdílů. Teprve potom lze označit celý model za připravený v deklarovaném rozsahu.
Správa změn a obnova certifikátu
Do provozní evidence zapište, kdo sleduje platnost certifikátu a kde se zobrazuje stav. Pokud aplikace podporuje automatickou obnovu, vyžádejte způsob kontroly jejího výsledku. Automatický proces může selhat a jeho existence nesmí znamenat, že odpovědnost zmizí. Náhradní postup připravte před uplynutím platnosti.
Při ztrátě zařízení nebo ukončení přístupu dodavatele posuďte stav uložených prostředků. Certifikát nelze chápat pouze jako neškodný soubor nastavení. Pokud existuje riziko zneužití, postupujte podle oficiálních pravidel a dostupné správy. Nesnažte se problém vyřešit jen změnou názvu pokladny v interním seznamu.
Po výměně zařízení znovu ověřte běžnou komunikaci a návaznost historie. Záloha katalogu neobsahuje automaticky všechny potřebné přístupy, identifikace a čekající zprávy. Při přenosu si nechte přesně určit, co se obnovuje a co nastavuje znovu. Tento rozdíl má být součástí servisního postupu.
Významná aktualizace aplikace si zaslouží cílenou kontrolu dotčených funkcí. Není nutné pokaždé opakovat celý projekt, ale je potřeba znát rozsah změny. Ověřte zejména platební integrace a dohledání neodeslaných údajů, pokud byly upraveny. Záznam o verzi pak pomůže při případné pozdější závadě.
U předávaného technického přehledu rozlišujte:
- Běžný návod: obsahuje postupy pro směnu a kontakty, nikoli soukromé přihlašovací prostředky.
- Správu oprávnění: uvádí odpovědné osoby a způsob odebrání přístupů při změně spolupráce.
- Obnovu sestavy: vysvětluje, co obsahuje záloha a které údaje nebo kroky je nutné připravit samostatně.
Při servisní výměně si nechte potvrdit zachování či správnou obnovu čekajících operací. Připravený nový katalog neprokazuje, že původní neodeslaná tržba nezůstala pouze na porouchaném zařízení. Tento rozdíl je zvlášť důležitý, pokud se současně mění aplikace nebo identifikace pokladny. Převzetí zahrnuje i rozpracovaný stav, nejen další nový prodej. Do servisního záznamu proto patří výsledek jeho dohledání a odpovědnost za dokončení.
Pro náhradní provoz využijte také průvodce výpadkem internetu a pokladny. Přeneste z něj do vlastního návodu jen podporované situace a konkrétní kroky. Přejímací protokol má potvrdit jejich proveditelnost pro vaši sestavu; obecné doporučení z článku nemůže nahradit chybějící technickou schopnost nebo oprávnění pracovníka.
Časté otázky
Lze celý postup provést už 25. října 2026?
Tento text je přípravou před oznámenou dostupností nových funkcí EET v DIS+ od listopadu. Skutečné úkony proveďte podle dostupného rozhraní a aktuálních pokynů.
Musím předat technikovi přihlašování k bankovní identitě?
Nejde o nutný obecný předpoklad instalace. Rozsah oprávnění a bezpečný způsob spolupráce nastavte podle konkrétního úkolu.
Je testovací úspěch potvrzením produkčního nastavení?
Ne. Prostředí, identita a certifikát se musejí ověřit pro ostrou sestavu zvlášť.
Od kdy běží nejzazší lhůta při výpadku?
Zákonná hranice 48 hodin se vztahuje k uskutečnění evidované tržby, nikoli až k objevení závady.
