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

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

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.

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

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.

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.

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.