Jak sakra tohle testovali? JMHZ pohledem jednoho programátora

Dnes

Doba čtení: 6 minut

Vývojář - programátor - digitalizace - JMHZ

Díky počtu klientů jsem si mohl dovolit luxus nepsat program dokonale. Vývojáři větších firem stáli před daleko většími problémy, popisuje své zkušenosti se zaváděním jednotného měsíčního hlášení zaměstnavatele jeden z vývojářů.

Od šéfredaktora Lupy Davida Slížka jsem v reakci na příspěvek na X dostal nabídku, abych napsal článek o jednotném měsíčním hlášení zaměstnanavatele (JMHZ). Nejprve jsem odmítnul s tím, že nejsem ten pravý a kompetentní, že nechci víc bouřit emoce okolo JMHZ a navíc nejsem objektivní. Bylo by lepší vyjádření firem jako Helios, Stormware, MRP a podobných. Odpověď byla, že oni vlastně nechtějí. Následující text tedy není oficiální vyjádření vývojářů SW, je to čistě jen moje osobní shrnutí, jak to vnímám já sám, programátor 60+.

Jen malé ohlédnutí za JMHZ, jak to vidí starý programátor. Moje "ovečky" mají splněno, jo i ta co se ozvala 18.5. i ta co se ozvala 20.5. (odvážné holky 😀). Mám naštěstí jen cca 30 klientek, takže se to dalo. Vlastně od konce dubna se většinou čekalo jen na propsání "rezidencí",…
— Pavel Pitřinec (@PavelPitrinec) May 25, 2026

Říjen 2025

Na JMHZ jsem začal pracovat koncem října 2025. Po stažení dokumentace a krátkém nahlédnutí do ní následovala deprese. REGZEC (registrace zaměstnance, pozn. redakce) – 130 položek, JMHZ – 440 položek.

Takže nejdřív REGZEC – struktura podobná jako “Oznámení o nástupu”. Nic moc, styl diplomová práce. Na pohled líbivé, pro programátora práce navíc. Je to dáno stylem XSD – atributy Povinné, Podmíněně povinné, Nepovinné, Zakázané. Tohle je, podle mě, pro programátora s přímým uvažováním jen zbytečná práce navíc. Tohle je společný rys s XSD šablonou JMHZ.

Co se týká dokumentace – tak ta se skládala z datového slovníku.xlsx, pokynů.pdf a XSD. Při psaní kódu jsem musel postupně pro každou položku nahlížet do všech třech. Nejdřív do slovníku – co je to za položku, povinná/nepovinná. Pak do pokynů – co se tam bude vyplňovat. A nakonec do XSD – kam to vlastně bude padat v XML. Tohle se nedá komentovat slušně. Jako opravdu nešlo tu dokumentaci zpracovat lépe?

Jen malá poznámka k pokynům – nerozumím jazyku úředníků a jazyku zákonodárců. Asi proto tak nenávidím programování mezd. A u některých položek místo vysvětlení jen odkaz na paragraf zákona – ne, to fakt nepomáhá.

Leden 2026

Zhruba v lednu jsem začal testovat. No, testovat. Chtěl jsem se zaregistrovat. Odpověď od týmu – máte již zaregistrovanou jinou datovou schránku – a to vyřizuje jiný odbor. Tečka. Nechtělo se mi to řešit, takže jsem začal využívat jakési anonymní testování přes DS s variabilním symbolem 999×xxxxx. Tak nějak se to vracelo, někdy po dvou hodinách, někdy po deseti dnech, někdy asi vůbec. Ve firmě jsme si dělali srandu, že to tam házejí ručně.

Únor/Březen 2026

Zhruba v půlce února skončilo tohle anonymní testování, tak jsem to odložil jako připravené.

V březnu jsme začali s účetními doplňovat OIČ a IDPPV, informoval jsem účetní, co si mají doplnit, jak to bude asi probíhat.

Jedna podstatná informace – zákazníků, kteří používají modul mezd, máme cca 30. To je počet, který mi umožňuje řešit s nimi vše individuálně. Takže jsem nemusel programově řešit některé věci, které musí řešit firmy se stovkami klientů. Zároveň funguji jako analytik, programátor, školitel i hot-line. V tomto případě to byla vlastně velká výhoda.

Duben 2026

Před 1. 4. kontroluji, jestli není nějaká změna v dokumentaci. Na první pohled nic.

Účetní začínají volat. U všech začínáme podávat REGZEC-3. Celkem to prochází, v mezerách mezi voláním si opravuju chyby v programu, publikuju verze i několikrát denně. JMHZ první dny neposíláme, dávám tak dva dny na propsání dat.

Tady bych chtěl pochválit naprostou většinu “mých” účetních. Pečlivě doplněná personalistika, žádná červená povinná pole – udělal jsem si tam zvýraznění, aby bylo vidět co chybí speciálně pro REGZEC-3. Účetní mě příjemně překvapily. Holky, děkuju.

REGZEC prochází, začínáme podávat JMHZ. Zjišťuju, že potřebuju validaci XML, bez toho to nepůjde. Píšu si vlastní, není to úplně ono. V půlce dubna mi ChatGPT náhodou nabídne validační službu na ČSSZ. Kolega mi pomůže a super. Funguje dobře.

A musím se ptát – proč tahle služba nebyla v dokumentaci už někde do začátku května? Taková skvělá věc? Proč?

Tak znovu podáváme JMHZ – začíná to procházet, v “Moje dokumenty” se objevuje, že podáno. Čekáme na zpracování. Po pár dnech studená sprcha, prakticky všechno je přijato částečně. Chyba – nerezident. Proč, když Franta Novák je přece český rezident?

Po pátrání zjišťuju, že ten Nepovinný atribut o daňovém rezidentství v REGZEC-3 je sice nepovinný, ale nezbytný. Jak sakra tohle testovali? Jak mohl procházet pilotní provoz? Proč k tomuhle problému MPSV informuje jen tak mimochodem v nějakých pokynech pro účetní? Proč to nesvítilo na stránce s dokumentací pro vývojáře červeně velkým písmem? Neodpustitelné.

Upravuju program, znova podáváme REGZEC-3. Čekáme většinou dva dny, pak podáváme znovu JMHZ. Stále stejná chyba, asi není propsáno v systému.

Konečně – 23. 4. podáváme v Třeboni, 24. 4. volá účetní – prošlo, stav podání kompletní a bezvadné. Ta úleva a radost se nedá popsat. Konečně průlom. Rychle kontroluju složení mezd – běžné mzdy, lidi s dětmi, jednatel, statutáři, dohody. To, co mají i ostatní. Při pátku super zpráva. Končí nejhorší tři týdny, kdy jsem chodil domů napůl slepý, vymluvený, stresovaný.

Dál už je to celkem nezajímavé, občas upravím program, podáváme a hlavně – čekáme na propis REGZEC v systému. A tady je taková zajímavost – REGZEC podle mých informací z více zdrojů na pobočkách ČSSZ úřednice ručně přesouvají z jednoho systému do druhého. Komentář asi netřeba.

Květen 2026

V květnu už mám celkem klid, dodělávám nějaké resty, úpravy, podávám s účetními hlášení za duben, hodně jich to už zvládá samostatně a ani o nich nevím. Po 11. květnu nastává zpomalení systému po osmé ranní, odezvy už nejsou na počkání. No, větší firmy pustily do světa nové verze s JMHZ.

Jak jsem již napsal, díky počtu klientů jsem si mohl dovolit luxus nepsat program dokonale. Vývojáři větších firem stáli před daleko většími problémy, třeba jak ošetřit chyby, které vrací portál, jak to otestovat, když se výsledek vrací klidně i za týden. To se nedá. A testovat jde jen na ostrých datech, už z principu věci.

Pár slov k ePortálu. To, že se mi nelíbí vzhled, je opravdu můj pohled technika. Ten průvodcovský režim bych asi odpustil, plýtvání místem na obrazovce ne. Jak by měl vypadat přehledný formulář by se tým JMHZ měl poučit např. u firmy ABRA nebo IDEA (mají skvělé prohlížeče JMHZ/REGZEC a kluci díky za to, pomohli jste mi tím moc).

ePortál mi přijde vlastně uživatelsky vyloženě nepřátelský. Nějak nejsem schopen tam to hlášení jednoduše upravit a odeslat. Nejde mi to. Chybí mi přehlednost, jednoduché zobrazení, co je špatně a tlačítko Zkontrolovat. Takové, které mi opravdu do hloubky hlášení zkontroluje a ukáže, co je špatně. Tohle jediné mi asi chybí. A veliká škoda, že nejsou zahrnuty i zdravotní pojišťovny. Proč? Co tomu bránilo?

Problémů je samozřejmě daleko víc, Facebook je toho plný. Sám mám na tom ještě dost práce, vím, že někde mám nedodělky a chyby.

Už to nechci víc rozebírat. Tohle je opravdu jen takový pohled jednoho programátora a byl bych rád, aby nebyl brán jako argument proti JMHZ. Nebylo to tak opravdu myšleno. S několika účetními jsme se shodli, že to nebude tak špatné. Až to bude fungovat, jak má.