Názory k článku Jak sakra tohle testovali? JMHZ pohledem jednoho programátora

U nás si spočítám mzdy sám pro HPP a DPP v jedné start verzi účetního SW. A JMHZ tedy byl boj. To co náš systém nepotřeboval, těch pár údajů pro přihlášení, odhlášení, hlášení bylo triviálních a že jsme neměli nastavenou kompletní personalistiku - to nebylo třeba. Ale až s JMHZ jsme to tedy nějak dobojovali, doplnili údaje o mně, duben už byl celkem hladký i s jednou brigádou navíc zadávanou ručně.
Největší problém bylo DPP a tohle byla chyba spíš systému účetního. Viděli jsme, že tam máme DPP, ale když se nám to vracelo, že tam má být T++. Nemohli to najít a pak nějak došli, že musím ručně doplnit v číselníku tuto hodnotu.
Zajímavé je v portále, že na jednom místě portálu jde nahrát čistě xml, ale když se edituje stávající, tak tam jde pouze zip.
Docela jsem ze zadrbal smazáním nefunkčního řádného podání a opravami. To si to pamatovalo to první GUID. Mno po pár pokusech jsem vygeneroval náhodné na webu a vložil do xml a podařilo se.

Při ručním zadávání je veselé, že nepovinně označené položky jsou povinné a také irituje nutnost zaškrtávat, že zaměstnanec není profesionální záchranář (jako dalších pár miliónu zaměstnanců).
Mno snad se za květen zadaří hladce.

A dyť to je dneska standard všude že se dneska nic netestuje a programuje to nějaká opice co vůbec neví co dělá a co zákazník potřebuje a pak se to řeší až za ostrýho provozu, dělá to tak Microsoft a všichni ostatní, nechápu čemu se furt někdo diví, takhle se to prostě dneska dělá, je to špatně, ale je to tak.

Spíš mi to přijde, že zákazník to tak chce, protože přeci jen zákazník je stát a nebylo by to poprvé ani naposled (kolikrát je to tak, že se ty zastaralé postupy jen aplikují do elektronické podoby se všemi zastaralostmi, které si to s sebou nese).

Připomíná mi to jeden takový vtip.
Po smrti přijde chlap do pekla a sám Belzebub ho provází, které peklo si vybere. Za prvními dveřmi je krásná nudapláž plná sexy koček a stánků s dokonalým výběrem občerstvení.
"Tohle je peklo?" diví se chlap.
"Jasně, to je peklo!"
V druhé místnosti je útulný klub se sympatickými hosty a hosteskami a báječnou muzikou.
"A tohle je taky peklo?"
"Jistěže, tohle je také peklo."
Za třetími dveřmi nabodávají čerti hříšníky na vidle, stahují je z kůže a vaří v kotlích s olejem.
"Jo," povídá chlápek, "tak tohle peklo!"
"Jo, to je ovšem taky peklo. Ale jestli nejste katolík, tak si toho ani nemusíte všímat. To tu máme jenom kvůli nim, oni to tak chtějí."

Na můj vkus je ta datová struktura neskutečně komplikovaná a dokumentace extrémně nepřehledná.
Mapování mezi čísly atributů, názvy atributů v XML, a popisky atributů? Mission impossible. Validace? Neprobíhá pořádně. Některé atributy, které by měly být např. číslo, jsou v XSD jako "string". Kompletní validaci JMHZ nedokážete udělat, protože závisí na některých datech z REGZEC (a na tom, jestli se tato data správně propsala do systémů MPSV).

Dostáváte se tak do situace, kdy sice v článku zmíněné (skvělé!) prohlížeče JMHZ data zobrazí a nehlásí chybu, ale JMHZ je na straně MPSV odmítnuto. No bodejť, prohlížeče v tu chvíli nemají kontext (např. že někdo je jednatelem), a tak neví, že například pro jednatele se musí v XML využívat jiný "formulář" (prakticky blok XML tagů a atributů a hodnot) než pro zaměstnance (který má ale stejně půlku atributů stejnou se zaměstnancem).

Chybové kódy mají sice hezkou tabulku (https://developers.mpsv.cz/api-list/jednotne-mesicni-hlaseni-zamestnavatelu/documentation/katalog-kontrol-mh), ale v reportech jsou čísla chyb začínající 2xxxx nebo 4xxxx, a uživatel si musí těch 20000 resp. 40000 od čísla chyby odečíst, a až pak chybu hledat v tabulce. Chybové hlášky JMHZ jsou nepřátelské, například místo lidského identifikátoru zaměstnance, tedy jména, příjmení, identifikátorů MPSV (pokud již takové mapování existuje) se zobrazí jen GUID. Učíme účetní, co je to GUID! (Mimochodem, každý zaměstnanec má dva identifikátory, ID zaměstnání a OIČ).

Aplikace na eportálu jsou taky skvělé, třeba přehled zaměstnanců (https://eportal.cssz.cz/web/portal/seznam-zamestnancu#/) ještě v dubnu dokázal vypsat všechny zadáním hvězdičky, nyní musíte zadat alespoň dva znaky z jména/příjmení a nedokážete tedy vypsat celou firmu najednou. Nebo formulář, u kterého je u spousty polí nápis "nepovinné", ale pole jsou vlastně povinná (podmíněně, v závislosti na hodnotách jiných atributů nebo obsahu REGZEC).

Zpracování je samostatný level pekla: pošlete dokument, ten proběhne validací vůči XSD (kde, jak už víme, část kontrol chybí, část přijme jakýkoli nesmysl), aby následně zůstal až několik hodin (!) ve frontě - až po zpracování v této frontě zjistíte, jestli v hlášení není nějaká logická chyba, která skrze XSD validaci prošla. Do datové schránky vám ovšem report přijde za 5 až 10 dní (!!), a tak účetní ručně kontrolují ePortál, v jakém stavu podání jsou.

Podobně bohužel fungují i registrace zaměstnanců: pošlete registraci a dlouho čekáte, kdy vám systém přidělí identifikátory.

Tohle je jen něco málo z toho, co jsem zažil já. Dalších chyb je v systému tolik, že Ivan Bartoš by za ně už byl pětkrát defenestrován. Jen pánům Jurečkovi a Juchelkovi to přijde v pohodě a považují systém za zcela funkční.

Dokážu si představit systém, kde registrace i JMHZ budou chodit přes API a účetní nebudou muset řešit nic ručně. Zatím to ale vesměs účetní řeší exportem XML, občas ruční opravou XML (!!!!), nahráním na portál nebo zasláním datovou schránkou, a čekáním na výsledek. Pak opravit chybu, a znovu.

V téhle oblasti se nevyznám, ale přijde mi to jako docela normální stav, kdy se něco staví na zelené louce. Sebelepší dokumentace má nedostatky, věci se doplňují postupně a komunikace vázne. Tohle je, naneštěstí, běžný stav u většího projektu, klidně i v jedné firmě natož mezi ruznými odděleními, odbory, ministerstvy a veřejností.

Obačas mám při řešení těhle nedostatků pocit, že Franta sice udělal co šlo ale v nějakou chvíli už na přemýšlení hodil bobek, a přenes zodpovědnost za validaci vlastní práce na lidi co to budou používat. Když Jarda i Maruna vidí, že to Frantovi prošlo zvolí stejný přístup. Tak snad už to odteď bude jen lepší.

Toto nebylo stavění na zelené louce. MPSV a ČSSZ mají v tomto dlouholeté zkušenosti. REGZEC měl být vylepšené ONZ a JMH kompilátem již existujících výkazů, které se státu posílají. A bohužel to dopadlo jako vždy když má v něčem ČSSZ. Amatérsky. Obdobný systém se před 11 lety řešil v podobě ISoSS pro státní zaměstnance. To připravovalo MVČR. Tam byla situace úplně jiná. Dokumentace připravená rok dopředu a prakticky nic se na ní do ostrého startu neměnilo. JMH a REGZEC? Změny jak na běžícím pásu i pár dní před ostrým startem. A to některé dost zásadní. A jako třešnička na dortu potom jistá Alexandra D. z ČSSZ při jednání s vývojáři HR systémů pouští pusu na špacír a obviňuje je z toho, že si realizaci nechali na poslední chvíli a že za to můžou oni a ne ČSSZ a MPSV. Vývojáři HR systémů půl roku nedělali nic jiného než že pořád předělávali už hotové jak zadavatel měnil podmínky.

No, jak tohle testovali... účetní mají už od začátku dubna pocit, že testování probíhá na nich a jejich ostrých datech, resp. že testování systému děláme tak nějak my. Možná v rámci akce "každá účetní programátorem" (prý nás na účtárnách nahradí AI), protože už jen rozluštit chybové hlášky vyžaduje studium dokumentace ve vývojářské sekci portálu MPSV. A ano, na ruční úpravy datové věty v XML také došlo...
Věřím, že si to časem sedne (jako všechno), ale zatím to není nic radostného.
Ohledně praktického použití systému JMHZ mi nejvíc vadí nemožnost dát nové podání bez zpracování předchozího. Jako... to je divná digitalizace, ne? Člověk je zvyklý (třeba z katastru nemovitostí), že má-li podání, která na sebe logicky navazují, musí je podat ve správném pořadí - a pohlídat si, aby mezi podáními byla nějaká viditelná prodleva, třeba 20 minut, to už je pak sichr. A podání jsou pak zpracována v pořadí, jakém byla doručena na podatelnu. Samozřejmě s rizikem, že když první podání je chybné, nebude zpracované ani druhé, to dá rozum.
Ne tak JMHZ. Jak zmíněno i v článku, (do)registrace nestačí řádně podat, je třeba počkat na jejich kompletní zpracování - a pak teprve podávat další, navazující podání. Proč proboha? Navíc když nikdy nevím, jak dlouho bude ten první krok (zpracování registrace) trvat. Mám i jinou práci, nemohu u toho furt sedět a hlídat, jestli už... a také mám zákonem dané termíny, které potřebuji dodržet, a opravdu se všechna práce plánovaná na 2 týdny nedá stihnout za pár minut poslední den, až systém konečně dá vědět, že schroupal první podání.

2. 6. 2026, 16:55 editováno autorem komentáře