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

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.

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.

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í."

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.

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

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.

na to se mi "líbil" argument jedné státní hni..y.. sice ty údaje máme, ale my ze zákona na ně nemůžeme, protože to má někdo jinde a v zákoně není že zrovna my můžeme.

Takže místo toho, aby se změnil zákon, aby tahle státní parta mohla čerpat data od jiné státní party, tak otravujou lidi..

arogance státních vš..í v přímém přenosu

Jenže taky jich má spoustu (většinu?) v dobrém stavu, a vidím tu riziko, že to narovnávání tam může zanést chyby.
(Třeba proto, že zaměstnanci museli doplňovat historické informace, o kterých už nemají spolehlivý zdroj, přestože je stát již zná. Kupříkladu IČO dávno zkrachovalé firmy nebo identifikační údaje VŠ, která už se transformovala na jinou... - vybírám, co mi utkvělo z paměti v jedenáctistrán­kového dotazníku.)

Je to šité horkou jehlou, nepromyšlené a některé věci jsou tam naprosto zbytečně (třea posílání věcí co už stát dávno má a zná).

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ší.

Můžete.
Ale bude to v tomhle objemu někdo dělat - nebo to skončí u platí to novější? Nebo snad: platí to, co se úředníkovi víc líbí?
Případně: Dolož, že to je správně, a pokud není, dostaneš pokutu za klamání úřadu!?

Jen taková anekdota z mého příbuzenstva: stalo ce v 70. letech, že se narodil chlapeček, ale dostal přidělené holčičí rodné číslo. V 90. letech, v dobách privatizace a čištění identifikačních údajů (opravy rodných čísel) se v počítači na tento rozpor přišlo, takže byl opraven: podle rodného čísla úředník nastavil atribut pohlaví. Aby to bylo zajímavější, měl ten nebožák křestní jméno, které mohlo být stejně dobře mužské, jako ženské. Takže při nejbližším prodloužení OP se mu pokusili prostě přechýlit i příjmení...
Dodávám, že změna pohlaví tenkrát ještě nebyla v módě a náprava trvala několik let, dokazování na úřadech, předkládání rodného listu - a on sám se divil, že nemusel při každém z těch úkonů stáhnout kalhoty, aby se úředníci přesvědčili, co má mezi nohama.

To by nebyl Jirsak, aby neobhajoval slendrian ve statnich IS. To, ze sam je soucasti dodavek toho slendrianu pro stat samozrejme neprizna ;-)

Problém je, že zdaleka ne všechny informace, které stát má, jsou v dobrém stavu. Třeba proto, že to tam před lety zadával někdo ručně – ať třeba účetní, nebo někdo na straně státu z papírových podání. Teď je docela dobrá příležitost to narovnat – zároveň ty chybné informace by způsobovaly v JMHZ ještě daleko víc problémů.

Správný postup by navíc byl načíst data, která stát má jinde (propojit databáze směrem do JMHZ) a předložit je účetním/zaměs­tnancům ke kontrole. Pak zkontrolovaná a opravená data vzít a uložit je i jinde (propojit databáze směrem z JMHZ). Pokud tato úvaha neproběhla při návrhu JMHZ (psaní zákona/prováděcí vyhlášky/archi­tektonického návrhu IT systému) tak pochybuji, že se kdy opravená data z JMHZ propíšou do stávajících systémů.

Přidám i já názor. Na zelené louce se nestavělo. Zadání bylo celkem jasné. Co má být obsahem hlášení - PVPOJ, daně, rozpisy mezd podrobně, statistika, děti atd. U všeho už existovaly systémy, struktury. Úkolem bylo toto sloučit do jednoho hlášení. Neříkám, že je to jednoduché. Ale zadání jasné, bylo z čeho vycházet. Schválně pomíjím sběr dat z hlediska např. GDPR, nejsem právník. Ale třeba údaje o daňové rezidenci přece nemuseli vyžadovat vůbec - evidenci zaměstnanců mají tu původní. Nebo na to v dokumentaci upozornit pořádně napoprvé. Na zelené louce se stavělo DSŘ, jenže to je úplně jiný případ.

Jak už jsem psal moje doména to není, jen mi nepřijde, že tohle je změna požadavků pro leta fungující systém, ale úplně nový systém který má stávající nahradit. Proto na zelené louce. Přepis "legacy" řešení bolí. Že někde systém fungoval roky opravdu neznamená, že si tam roky drželi odborníky, kteří pracovali na další verzi.

Obecně mi nějaké překvapení nebo rozhořčení nad stavem věcí, který je přesně takový jaký byl vždycky, přijde zvláštní.

Prekvapeni z rozhorceni nad stavem veci ktery je presne takovy jaky byl neni vubec prekvapive. Kdyz se odprostite od technickeho a analytickeho pristupu a date do toho trochu psychologie.
Clovek velmi rychle zapomina. Tim spise nejake vykazy ktere mu akorat zabiraji cas a neprinasi nic. Takze snadno zapomene ze ty same podivne informace ktere po nem chteji v jednotnem hlaseni mu ob rok ci dva chodily kumulativne od ruznych uradu kdy kazdy urad chtel zdibec nejake informace.

Co se tyce legacy reseni mohu to same rici o stavebnim zakonu. Pokud budeme to co je strukturalne spatne implementovat do elektronicke podoby bude to porad spatne.

Když máte dva rozporné údaje, můžete řešit, který z nich je správný.