U jednotného měsíčního hlášení zaměstnavatele může úřad vadné podání odmítnout. Příprava firemního softwaru proto začíná kontrolou dat a testováním, ne úpravou konečného formuláře.
Nová zákonná povinnost může změnit evidenci a kontrolu údajů ve mzdovém, účetním nebo provozním softwaru i způsob jejich odesílání úřadu. Software by proto měl umožnit upravit pravidla a výstupy, aniž by se kvůli každé změně předělával celý pracovní postup.
Připravit firemní software neznamená předem naprogramovat konečnou podobu povinnosti, která zatím není závazně popsaná. Je třeba zjistit, kterých dat, lidí, kroků a propojených programů se změna dotkne. Potom lze oddělit přípravu, kterou je možné udělat hned, od částí závislých na závazné technické dokumentaci. Nejistota není důvod přípravu odkládat. Programovat podle odhadů však zvyšuje riziko pozdějších oprav.
Právní úprava nové povinnosti obvykle určuje, co má firma evidovat nebo odesílat. Méně zřetelné bývá, kde požadovaný údaj vzniká, kdo ho opravuje a kolika programy projde. Právě tyto vazby je třeba před úpravou softwaru popsat.
Na první pracovní schůzce je třeba odpovědět na šest otázek:
U jednotného měsíčního hlášení zaměstnavatele, zkráceně JMHZ, například nestačí upravit výsledný soubor pro Českou správu sociálního zabezpečení. JMHZ spojuje elektronické ohlašovací a evidenční povinnosti týkající se zaměstnavatele a zaměstnanců. Když požadovaný údaj ve mzdovém programu chybí, nevytvoří ho ani správně naprogramovaný formulář. Nejdřív se musí určit zdroj údaje, odpovědnost za jeho správnost a okamžik kontroly. Jinak software pouze rychleji odešle neúplná data.
JMHZ zavádí osobní identifikační číslo, zkráceně OIČ, pro fyzickou osobu a identifikátor zaměstnání pro každé zaměstnání zaměstnance. ČSSZ přidělila oba identifikátory stávajícím zaměstnancům hromadně a zaměstnavatel si je může stáhnout ve formátu XML nebo CSV přes službu Seznam zaměstnanců na ePortálu ČSSZ. Od 1. dubna 2026 dostane u nového zaměstnance oba údaje v protokolu o přihlášení. Mzdový program je proto musí uložit ke správnému člověku a zaměstnání, ne jen připojit k výslednému hlášení.
Technická nebo formální chyba může způsobit úplné odmítnutí podání, případně přijetí jen jeho části. Proto je nutné zkontrolovat také návaznosti mezi programy. U automatických propojení lze vycházet ze stejného postupu jako při přípravě API mezi dvěma systémy. API je rozhraní, přes které si aplikace předávají data bez ručního přepisování.
Bez konečné technické specifikace lze zmapovat programy, datové zdroje a odpovědnosti. Lze také zkontrolovat, zda povinná pole nejsou prázdná, zda se změny údajů ukládají do historie a zda dodavatel plánuje aktualizaci. Připravit lze i testovací prostředí, tedy oddělenou kopii programu a dat, na které chyba nezasáhne ostrý provoz. Součástí přípravy má být postup návratu k předchozí verzi při závažném problému.
Přizpůsobitelnost nevzniká tím, že se do programu doplní další formulář. Stabilní část má uchovávat zdrojová data a historii změn, zatímco proměnlivé části, například povinná pole, číselníky, validační pravidla a mapování do výstupního souboru, mají být oddělené v konfiguraci nebo samostatných modulech. Změna formátu podání se pak řeší úpravou exportu a kontrol, nikoli zásahem do evidence zaměstnance nebo výpočtu mzdy. Rozhraní mezi částmi programu musí mít popsané vstupy, výstupy a verzi, aby bylo možné novou variantu otestovat vedle dosavadní.
Ostrou implementaci konkrétní datové struktury, kontrol, výpočtových pravidel a způsobu elektronického podání je vhodné odložit, pokud ještě nebyly závazně zveřejněny. Návrh specifikace lze využít pro prototyp nebo testovací větev, taková verze však nemá být bez ověření použita pro ostré podání. Konfigurovatelné číselníky a validační pravidla lze připravit předem tak, aby se po zveřejnění závazné verze změnily bez zásahu do zbytku programu. Validační pravidlo automaticky kontroluje, zda údaj odpovídá požadovanému formátu a povoleným hodnotám.
Termíny ukazují, proč není vhodné nechat vše na poslední měsíc. Zákon č. 323/2025 Sb. o jednotném měsíčním hlášení zaměstnavatele nabyl účinnosti 1. ledna 2026. Související povinnosti jsou rozdělené do tří hlavních fází k 1. lednu, 1. dubnu a 1. červenci 2026. Další termíny uvádím v přehledu firemních povinností pro rok 2026.
Podobně Evropský akt o kybernetické odolnosti dopadá na výrobce hardwaru a softwaru s digitálními prvky. Vyžaduje řešení bezpečnosti při plánování, vývoji i údržbě produktu. Nařízení vstoupilo v platnost 10. prosince 2024. Ohlašovací povinnosti se použijí od 11. září 2026 a hlavní povinnosti od 11. prosince 2027. Komise 27. července 2026 zveřejnila praktické pokyny, které mají výrobcům, vývojářům a firmám pomoci s plněním povinností. Odpovědnost za aktualizace a zranitelnosti však lze určit už nyní.
První možností je počkat na hotovou aktualizaci od dodavatele. Vyžaduje nejméně práce na straně firmy a dává smysl u běžného programu, který dodavatel pravidelně aktualizuje podle české legislativy. Firma ale méně ovlivní termín, podobu změny a návaznosti na další aplikace. Je proto vhodné nechat si písemně potvrdit rozsah aktualizace, předpokládaný termín a způsob testování.
Druhou cestou je postupná úprava stávajícího softwaru. Nejdřív se doplní data, odpovědnosti a kontroly. Až potom přijde nový výstup nebo elektronické podání. Tento postup rozloží práci a dříve odhalí chybějící údaje. Vyžaduje však čas účetních, personalistů, správce programu a někdy i několika dodavatelů. Při plánování pomůže zkontrolovat zadání podle ceny pozdního rozhodnutí, nikoli podle počtu stran dokumentu.
Třetí možností je výměna nebo přepis systému. Může vyřešit dlouhodobá omezení, například chybějící historii změn nebo nemožnost doplnit nové údaje. Současně přidává migraci dat, tedy jejich převod do nového programu, testování, školení a přípravu návratu k původnímu systému. Není to vhodná zkratka, když je jediným důvodem blížící se formulář. Spojení legislativní změny s výměnou klíčového systému dává dvěma rizikovým akcím stejný termín. Zpoždění jedné pak může ohrozit i druhou.
Nejdřív ověřte, zda program umí potřebné údaje uložit, opravit a zpětně dohledat. Zjistěte, kdo dodá legislativní aktualizaci a které části závisejí na zveřejnění konečných pravidel. Sepište také všechna dotčená napojení. Jedna změna identifikátoru může zasáhnout mzdový program, docházku, personální evidenci, datový sklad i export pro účetní.
Náklady netvoří jen programování. Patří do nich čištění dat, kontrola výstupů, práce lidí při testování, školení a případný výpadek. Cenu výpadku je vhodné vyjádřit podle zpožděného zpracování mezd, faktur nebo podání, nikoli obecným označením „kritické“. Zkouška má proběhnout na kopii skutečných dat s odpovídajícím zabezpečením. Test na prázdné databázi neodhalí chyby, které vznikají ve skutečných záznamech.
Fázování povinností JMHZ zároveň umožňuje rozdělit změny do samostatných verzí místo jednoho společného nasazení. Jedna verze může doplnit evidenci identifikátorů, další upravit kontroly a další obsloužit konkrétní elektronické podání. Každá verze pak dostane vlastní testovací scénáře a schválení. Když se při zkoušce objeví chyba ve výstupu, není nutné vracet současně úpravu evidence, která už funguje.
Při nasazení zůstává rozhodující i zpracování odpovědi úřadu. Úspěšné odeslání souboru samo nepotvrzuje, že bylo podání přijato celé. Program má uchovat protokol, přiřadit vady ke konkrétním záznamům a předat je k opravě dřív, než uplyne lhůta. Technická část tím nenahrazuje právní posouzení konkrétní povinnosti, ale brání tomu, aby odmítnuté nebo jen částečně přijaté hlášení zůstalo bez povšimnutí.
Stejnou obchodní nabídku lze připravit ve Wordu i v aplikaci napojené na několik zdrojů dat, ale zásadní rozdíl je v tom, kolik práce převezme automatizace.
Objednávka projde 4 aplikacemi, ale chyby v přenosu mezi nimi stále hlídá člověk v Excelu.
Rychlá podpora nevyřeší chyby, které vznikají už v nabídce, objednávce nebo fakturaci. Zákaznickou zkušenost proto musí firma řídit napříč odděleními.
Napište nám, co u vás řešíte. Ozveme se do jednoho pracovního dne.
