# ČSSZ — kompletní přehled a technická specifikace (VREP/EXIDVK) Sloučeno z původně dvou dokumentů projektu ČSSZ: technické specifikace k VREP/EXIDVK a přehledu materiálů ze stránky ekcr.cz. Sloučeno 26. 8. 2026. --- Zdroj: dokumenty z ekcr.cz/exekutor/CSSZ (distribuční balíček 2013, aktuální produkční formulář 1.ZFO z 10/2020, registrační tabulka pověřených osob, XSD schéma EXI_2010_1_0.xsd) + oficiální web ČSSZ (cssz.gov.cz, dřív cssz.cz). Prostudováno a rozbaleno 24. 8. 2026, doplněno o oficiální dokumentaci ČSSZ 24. 8. 2026, doplněno o finální stav komunikace a vyjasnění VS 26. 8. 2026, doplněno o potvrzení dávkového dotazování 26. 8. 2026, doplněno o skutečnou transportní strukturu protokolu (přečten napřímo, viz níže) a první výsledky živého testu 1. 9. 2026. ## Dávkové (hromadné) dotazování — POTVRZENO, až 1500 dotazů v jednom podání Ověřeno přímo ve dvou nezávislých, na sobě neležících zdrojích, které se shodují: - `tech_specifikace/EXI_2010_1_0.xsd` z `distribuce2013.zip` (ekcr.cz) - aktuální produkční šablona `1.ZFO` (form.fo, 10/2020, ekcr.cz) Struktura jednoho podání (jeden XML dokument, jedno odeslání na VREP): ``` EXIDVK (verze="2010.1") ├── Okres / KodOSSZ (101), NazevOSSZ — hlavička, JEDNOU za celé podání ├── ExekutorskyUrad │ ├── VS — variabilní symbol, JEDNOU za podání │ ├── Nazev │ └── Pracovnik (Jmeno, Prijmeni, RodneCislo) — kdo podání dělá, JEDNOU za podání ├── SifrovaciCertifikaty (nepovinné, 1–10× Certifikat) — šifrování odpovědi pro víc příjemců ├── Poznamka (nepovinné) └── Dotazy — SEZNAM, JEDNOU za podání └── Dotaz [poradoveCislo] (1× až 1500×) — KAŽDÝ je samostatný subjekt ├── RodneCislo ├── NazevSubjektu └── ExekucniCisloPripadu — spisová značka/exekuční číslo PRO TENTO KONKRÉTNÍ dotaz ``` Odpověď na tvoji otázku: - **Ano, dávkově to jde.** Jedno XML podání může obsahovat 1 až 1500 položek `Dotaz`, každou s vlastním `poradoveCislo` (pořadové číslo pro spárování požadavku a odpovědi). XSD dokumentace k elementu doslova říká: „Pole dotazů (platné podání musí obsahovat alespoň jeden dotaz)." - **Spisová značka (`ExekucniCisloPripadu`) je vázaná na každý jednotlivý `Dotaz`, ne na celé podání.** Není to tedy „jedna spisová značka pro víc subjektů" ani „jeden dotaz = navždy jen jeden izolovaný subjekt bez možnosti dávky" — je to obojí zároveň jinak, než by se čekalo: **každý subjekt v dávce nese svou vlastní spisovou značku**, ale těchto párů (rodné číslo + spisová značka) můžeš v jednom souboru/podání poslat najednou až 1500. - Odpověď (`Odpovedi/Odpoved`) je stavěná stejně — každá položka nese svoje `poradoveCislo`, echované `RodneCislo`/`NazevSubjektu`/`ExekucniCisloPripadu` a **vlastní** `Zpracovani/Vysledek` + `Kod`. Validace a chyby jsou tedy per-item, ne per-podání — když jeden dotaz v dávce selže (např. chybný formát RČ), ostatní se zpracují nezávisle. --- ## KDO JE KDO V TÉTO KOMUNIKACI **Skutečný kontext:** Daniel Němec / **BSP Technology s.r.o.** (IČO 24675008, Politických vězňů 1272/21, Praha) je **softwarový dodavatel/vývojář**, který vyvíjí aplikaci **pro** exekutory – **není** to samotný exekutorský úřad. Komunikace s ČSSZ (Ing. Jiří Trnka) proto neprobíhá standardní cestou přes Exekutorskou komoru ČR (registrační tabulka `pov_osoby_cssz.xlsx` na `ekcr@cssz.cz`, viz níže) – ta je určena pro registraci exekutorských úřadů samotných. Místo toho BSP Technology komunikuje s ČSSZ **napřímo e-mailem** jako vývojář žádající o testovací/vývojářský přístup k API. Pro účely testování bude BSP Technology (konkrétně Daniel Němec jako zmocněnec) **fiktivně vystupovat jako exekutor vyžadující součinnost** – tj. testovací podání budou technicky odpovídat formátu EXIDVK (žádost exekutora o součinnost), i když je reálně posílá vývojářská firma, ne exekutorský úřad. ### Průběh jednání s ČSSZ (Ing. Jiří Trnka) — kompletní vlákno 1. **Původní e-mail BSP Technology → Trnka (24. 8. 2026, 13:19):** představení jako vývojář aplikace pro exekutory, dotaz na testovací přístup; podle tehdejší (starší) dokumentace žádali o testovací registrační číslo, testovací VS „začínající 999" a certifikát. 2. **Odpověď Trnky (24. 8. 2026, 14:11):** testovací VS začínající „999" **už není potřeba**. Testovat lze přímo přes **VS = 1162035057**. Potřeboval vědět, kdo bude posílat testovací podání – tuto osobu nastaví jako **zmocněnce** pro VS 1162035057. Pro testování přes VREP potřeboval **zaregistrovat kvalifikovaný certifikát** dané osoby – název vystavitele a sériové číslo. 3. **Odpověď BSP Technology (24. 8. 2026, 15:23):** odesláno jméno zmocněnce (Daniel Němec) + údaje k certifikátu (PostSignum Qualified CA 4, sériové číslo 016F5791 hex, .pem přiložen) + dotaz, odkud se VS 1162035057 vzal. 4. **Odpověď Trnky (26. 8. 2026, 8:40) – vysvětlení původu VS:** *„našel jsem, že VS = 1162035057 patří firmě BSP Technology s.r.o., která přes něj podává podání v PP."* Zároveň si vyžádal datum narození Daniela Němce (nutné k registraci certifikátu). 5. **Odpověď BSP Technology (26. 8. 2026, 8:48):** datum narození Daniela Němce – 27. 2. 1976. 6. **Finální potvrzení Trnky (26. 8. 2026):** Daniel Němec nastaven jako zmocněnec k VS 1162035057, certifikát zaregistrován. **Testování lze zahájit** (kontakt Trnky pro případné problémy zůstává v platnosti). ### Vyjasnění: co je VS 1162035057 (26. 8. 2026) VS 1162035057 je **standardní variabilní symbol BSP Technology s.r.o. u ČSSZ pro odvody sociálního pojištění** (běžná mzdová agenda za zaměstnance firmy) – přesně to je „podání v PP", které Trnka zmínil. **V BSP Technology nikdy nikdo nevyvíjel žádnou aplikaci pro exekutory ani jinou elektronickou komunikaci s ČSSZ přes API/VREP** – firma s ČSSZ dosud komunikovala jen v téhle běžné odvodové agendě, ne elektronicky přes VREP/EXIDVK. Jde tedy o **dvě oddělené větve použití stejného VS**: (a) existující, nesouvisející odvody pojistného, a (b) nově zřizovaná testovací/vývojářská větev pro EXIDVK součinnosti přes VREP. Sdílení VS mezi nimi je v pořádku a neznamená kolizi – různá agenda, různé zpracování na straně ČSSZ. ### Stav k 26. 8. 2026 — HOTOVO, lze testovat - Zmocněncem pro VS 1162035057 je **Daniel Němec** (nar. 27. 2. 1976). - Certifikát: kvalifikovaný osobní certifikát Daniela Němce, vystavitel **PostSignum Qualified CA 4** (Česká pošta, s.p., organizationIdentifier NTRCZ-47114983), sériové číslo **016F5791** (hex) / 24074129 (dekadicky), platnost do 5. 12. 2026 — zaregistrován u ČSSZ. - Původ a povaha VS 1162035057 vyjasněny (viz výše) — žádné otevřené riziko kolize s existujícím provozem firmy. - **Endpoint pro testování vyjasněn: pouze testovací** (`https://t-epodani.cssz.cz/VREP/...`). Na produkční endpoint (`epodani.cssz.cz`) BSP Technology jako vývojář přístup nemá a mít nebude – ten se zřizuje až s konkrétním skutečným exekutorem coby klientem aplikace, ne pro vývojáře samotného. Vývoj a testování EXIDVK tedy probíhá výhradně proti testovacímu VREP. --- ## AKTUALIZACE: testovací prostředí i WSDL EXISTUJÍ a jsou veřejně zdokumentované Původní zjištění (níže) bylo, že v materiálech Exekutorské komory (ekcr.cz) není testovací prostředí zmíněno. To platí jen pro materiály EKČR — na **oficiálním webu ČSSZ** (dnes `cssz.gov.cz`, staré odkazy na `cssz.cz` přesměrovávají) je testovací prostředí i webová služba s WSDL popsané veřejně, na stránce „Testování a fiktivní údaje". Shrnutí: ### Testovací VREP - **POX (obálka GovTalk přes HTTPS):** - podání: `https://t-epodani.cssz.cz/VREP/submission` - dotaz na stav: `https://t-epodani.cssz.cz/VREP/poll` - **Web Service (SOAP):** - endpoint: `https://t-epodani.cssz.cz/VREP/ws/public.svc` - **WSDL: `https://t-epodani.cssz.cz/VREP/ws/APEP.wsdl`** (staženo a ověřeno — služba „Public", rozhraní `IBusinessTransactions`, operace `Submit`, `Poll`, `Dispose`, `DataRequest`; WS-Addressing, šifrování Basic256, chybová výjimka `GGErrorException`) - Data poslaná na testovací VREP (nebo přes testovací ISDS) se zpracovávají **pouze fiktivně** — nejde do produkce. - Pro testování je potřeba **samostatná registrace** u ČSSZ (jednorázová), po které přidělí: - testovací registrační číslo, - **testovací variabilní symbol začínající „999"** (v ukázce v dokumentaci `1111234567` — pozor, dva různé formáty se v pramenech objevují; **u BSP Technology se ale ukázalo, že tento krok Trnka přeskočil a rovnou přidělil existující firemní VS 1162035057, viz sekce výše**), - případně testovací IČPE (jen pro HPN). - Kontakt pro přidělení testovacích údajů: **Call centrum technické podpory 800 050 248**, nebo přímo **Ing. Jiří Trnka, Jiri.Trnka@cssz.gov.cz**. - Vyžaduje se i pro testovací provoz kvalifikovaný certifikát, podpis a šifrování stejně jako v produkci (jen s testovacím VS a proti testovacímu endpointu). ### Testovací ISDS (datové schránky) — alternativa bez registrace - Testovací schránka ČSSZ: ID **`9tsaf6s`**, název „e-Podání TEST". - Doporučuje se registrace i tak, ale není podmínkou. - Omezení: jedna XML příloha na zprávu; testovací a produkční ISDS spolu nekomunikují. ### Produkční WSDL a POX adresy (pro srovnání, oficiálně zdokumentované) - POX podání: `https://epodani.cssz.cz/VREP/submission` - POX dotaz na stav: `https://epodani.cssz.cz/VREP/poll` - WS endpoint: `https://epodani.cssz.cz/VREP/ws/public.svc` - **WSDL: `https://epodani.cssz.cz/VREP/ws/APEP.wsdl`** - Validace XML (samostatná služba): `https://epodani.cssz.cz/ePodaniValidace.svc`, WSDL `https://epodani.cssz.cz/wsdl/ePodaniValidace.wsdl` Pozn.: cesta `/VREP/submission` a `Class=CSSZ_EXI` z formuláře 1.ZFO (viz produkční endpoint níže) přesně odpovídá tomuto obecnému VREP/APEP rozhraní — jde tedy o stejnou infrastrukturu, exekutorská podání (EXIDVK) v ní jedou pod `Class=CSSZ_EXI` / `classtype=EXIDVK10`. To znamená, že **testovací VREP výše by měl jít použít i pro testování exekutorských podání EXIDVK** — ale to není v dokumentaci explicitně potvrzeno pro tento konkrétní typ podání, takže je rozumné si to při registraci s ČSSZ ověřit (viz doporučený další krok). ### GovTalk obálka — potvrzená přesná struktura (z „CSSZ Podávací a dotazovací protokol", skutečná verze **1.47**, 11. 2. 2025 — dřív jsme tuhle verzi špatně citovali jako „1.7"; PDF stažen a přečten napřímo 1. 9. 2026 přes `pdftotext`, ne jen odhad z citací) - Kořenový element `GovTalkMessage`, namespace `http://www.govtalk.gov.uk/CM/envelope` (tj. jde skutečně o variantu britského GovTalk standardu, ne o českou obdobu jen podobného jména). - `EnvelopeVersion` = `2.0` (povinné) - `Header/MessageDetails`: `Class`, `Qualifier` (`request`/`poll`/`acknowledgement`/`response`/`error`), `Function` (`submit`/`delete`), `CorrelationID` — **žádný `TransactionID`** ve skutečném příkladu (dokumentační tabulka ho sice zmiňuje jako povinný, ale reálný XML příklad v protokolu ho neobsahuje a sloupce tabulky jsou navíc zjevně rozházené extrakcí z PDF — řiď se příkladem, ne tabulkou). - **`CorrelationID` musí být na podání (`submission request`) PRÁZDNÉ** — přiděluje ho ČSSZ a vrací v `submission acknowledgement`; pro `submission poll` se pak posílá TO vrácené ID (vyplněné). - `Header/SenderDetails`: nepovinné, VREP ho nevyužívá — ve skutečném příkladu úplně chybí, klidně vynechat. - `GovTalkDetails/Keys`: klíč typu `vars` = variabilní symbol, **povinné pro podání vázaná na organizaci** (což EXIDVK je). - `GovTalkDetails/GatewayAdditions/Flags/TimestampVersion` = `xmldsig` — doporučeno posílat vždy (žádá si moderní formát vracené podepsané časové značky se SHA-2; starší `ggdsig` je jen kvůli zpětné kompatibilitě). - `Body`: **u podání (submission request) musí nést „CSSZ Message" (viz níže), nebo musí být prázdné** (poll/delete request). U odpovědí je ve `Body` buď podepsaná časová značka VREP (`acknowledgement`), CSSZ Message (`response`/`error`), nebo je prázdné. Příklad (z protokolu, submission request pro jiný typ podání „CSSZ_PRIHL" — struktura je pro všechny typy podání stejná, mění se jen `Class` a `Message/@eType`): ```xml 2.0
CSSZ_PRIHL request submit
1111234567 xmldsig ``` ### CSSZ Message („obálka CSSZ") — nese podpis a zašifrovaná data, vkládá se přímo jako XML do `Body` (NE jako base64 text!) ```xml
BASE64_PODPIS
BASE64_ZAKOMPRIMOVANA_A_ZASIFROVANA_DATA ``` - `@version` = aktuální verze obálky CSSZ, doporučeno vždy `"1.2"`. - `@eType` = podtyp/verze podání. Pro EXIDVK je to `"EXIDVK10"` (potvrdil Ing. Trnka). U odpovědi je `@eType` vždy `"response"`. - **Podpis** (`Header/Signature`): detached PKCS#7/CMS podpis (ne XML-DSig), base64. Podepisují se PŮVODNÍ data podání (tj. samotné EXIDVK XML) — před kompresí, šifrováním a kódováním. ČSSZ z certifikátu použitého k podpisu identifikuje podepisující osobu proti registrační databázi (autentizace). V PHP: `openssl cms -sign -binary -outform DER` (bez `-nodetach` = detached, cert podepisujícího je ve výstupu automaticky). - **Data** (`Header/Body`, atributy `encrypted="yes" contentEncoding="gzip"`): stejná původní data (to samé EXIDVK XML, co se podepisuje) se **nejdřív zkomprimují (gzip/LZ77), pak zašifrují** (v tomto pořadí — jinak by šifrováním vznikla binární data se špatným kompresním poměrem), výsledek se zakóduje Base64. Šifrování je PKCS/CMS, asymetrické, veřejným certifikátem ČSSZ (`dis.cssz.aktualni.cer`) — jen ČSSZ (držitel privátního klíče) to umí rozšifrovat. V PHP: `gzencode()` → `openssl cms -encrypt -binary -aes256 -outform DER `. - `Vendor` (`productName`, `version`): informace o podávající aplikaci, nepovinné, ale doporučené „pro pomoc při řešení případných problémů". ### Odpověď — struktura potvrzená živým testem `Message/Body` v odpovědi je NEŠIFROVANÉ XML (bez `encrypted="yes"`), přímo obsahuje: - `ProcessingResult` — výsledek zpracování (`@result="OK"/"ERROR"`, `@errNumber`, `@errMsg`) a per-položku `Details/Item` (`@sqnr`, `@identifier`, `@result`, `@errNum`, `@errMsg`). - `ProcessingResponse/Data` — samostatně zašifrovaná skutečná data odpovědi (vlastní atribut `@encryptionAlgorithm`, u ČSSZ pozorováno `aes128` — jiný algoritmus, než kterým šifrujeme podání my). Po dešifrování (stejný postup jako u podání, jen obráceně) je uvnitř XSD schéma `EXIDVK/Odpovedi/Odpoved` (`RodneCislo`, `NazevSubjektu`, `AktualniNazevSubjektu`, `Adresa`, `Vyplata`/`Polozka`, `Zpracovani`) — živě potvrzeno včetně `Vyplata`. ### Časování odpovědi a povinné uzavření transakce (delete) — z kap. „Komunikační vzor" - **Doporučený interval mezi dotazy (poll)** = hodnota `PollInterval` (ve vteřinách) vrácená v doručence/acknowledgementu — pokud chybí, doporučeno 5 minut. **Neposílat dotazy častěji**, klidně interval prodloužit, ale ne zkrátit (kvůli plynulosti zpracování na straně ČSSZ). - **Běžný čas doručení odpovědi**: 5 minut až 1 hodina (pro podání do 300 formulářů/dotazů). Krajně až 24 hodin — větší objem se odkládá mimo špičku (večerní hodiny); delší doba než 24 h může znamenat předání na ruční zpracování. - Dokud ČSSZ zpracování nedokončila, poll vrací znovu jen doručenku (acknowledgement) — je potřeba počkat interval a zkusit znovu. Až je hotovo, vrátí `submission response` (úspěch/částečný úspěch) nebo `submission error` (zamítnuto). - **Po obdržení finální odpovědi (response/error) je POVINNÉ poslat `delete request`** (`Function=delete`) k uzavření transakce — VREP odpoví `delete response`. Aplikace, které transakce neuzavírají, porušují pravidla pro zasílání e-podání a můžou způsobit provozní problémy. Neruší business podání ani jeho účinky, jen uzavírá transportní transakci. Implementováno jako `csszLibrary.php::uzavriTransakci($correlationId)`. - `delete` je **idempotentní** — i na náhodné/neexistující `CorrelationID` odpoví ČSSZ stejným úspěšným `Qualifier=response` (žádná chyba). Úspěšná odpověď tedy nepotvrzuje, že reálně existovala transakce k uzavření. ### Další dokumenty ke stažení z oficiálního webu ČSSZ (`cssz.gov.cz/ke-stazeni`) - **Podávací a dotazovací protokol, verze 1.47** (PDF, 638 kB): `https://www.cssz.gov.cz/documents/20143/99641/CSSZ+Podavaci+a+dotazovaci+protokol.pdf/68d0570f-df42-f4e8-3256-71ece6fd56b4` — **přečten napřímo 1. 9. 2026**, viz struktura výše. - **Demo zdrojový kód (C#, ZIP)** — ukázka Submit/Poll přes VREP: `https://www.cssz.gov.cz/documents/20143/181606/CSSZSubmissionDemo.zip/f8e75709-a6a8-45f1-f24b-ee0ba88e58c6` — zatím jen dohledán, ne stažen/prostudován (C# úryvky pro Sign/Encrypt/Compress už ale máme přímo z PDF protokolu, viz výše). - **Provozní řád VREP** (DOC, 2013): `https://www.cssz.gov.cz/documents/20143/181606/Provozni_rad_VREP_130906.doc/0b607398-05a5-fd16-7e50-c957ff56df8d` **Nebylo ale nikde na cssz.gov.cz dohledáno**: samostatné XSD schéma EXIDVK ani explicitní zmínka exekutorských podání/EXIDVK v obecné vývojářské sekci — ta se soustředí na zaměstnavatele/mzdové systémy. XSD schéma EXI_2010_1_0.xsd tedy pořád nejlépe zůstává jen v distribučním balíčku na ekcr.cz (viz níže). --- ## Implementace `public/libs/lustrace/socialka/csszLibrary.php` obsahuje implementaci (třída `Exemaster\Lustrace\cssz`), volanou testovacím blokem v `public/controllers/PublicController.php::indexAction()`. ### Stav — CELÁ PIPELINE FUNKČNÍ A ŽIVĚ OVĚŘENÁ END-TO-END Testovací podání EXIDVK proti `t-epodani.cssz.cz` proběhne kompletně: obálka, podpis, šifrování, doručení, zpracování na straně ČSSZ i vyzvednutí věcné odpovědi s reálnými (testovacími) daty subjektu. - `Message/@eType` musí být `"EXIDVK10"` (ne `"EXIDVK"`). - `EXIDVK/Okres/NazevOSSZ` je povinné, musí odpovídat `KodOSSZ` — v kódu `Praha` pro `KodOSSZ=101`. - `ExekutorskyUrad/Pracovnik/RodneCislo` (zmocněnec) - `sestavPozadavekXml()` před odesláním odstraní vše kromě číslic, takže formát v `CSSZ_CONFIG_JSON.pracovnikRodneCislo` (s lomítkem i bez) nevadí. - Podpis (`podepsatDataDetached()`): `openssl cms -sign -binary -outform DER`. - Šifrování podání (`zasifrujData()`): `openssl cms -encrypt -binary -aes256 -outform DER` — **AES-256 funguje bez problémů**, dřívější neúspěch s ním byl způsobený špatným `eType`, ne algoritmem. `-provider legacy` proto už není potřeba. - Dešifrování odpovědi (`odsifrujData()`): `openssl cms -decrypt -binary -provider legacy -provider default -inform DER` — `-provider legacy` tu zůstává, protože ČSSZ odpověď šifruje sama a algoritmus si volí sama (pozorováno `aes128`); `openssl cms -decrypt` algoritmus detekuje automaticky z CMS struktury. - **Struktura odpovědi** (`rozparsujGovTalkOdpoved()`): `Message/Body` přijde jako nešifrované XML s `ProcessingResult` (výsledek zpracování, `result="OK"/"ERROR"`, per-item `Details/Item`) a `ProcessingResponse/Data` (zvlášť zašifrovaná skutečná data odpovědi). Po dešifrování `ProcessingResponse/Data` je uvnitř schéma `EXIDVK/Odpovedi/Odpoved` přesně dle XSD (`RodneCislo`, `NazevSubjektu`, `AktualniNazevSubjektu`, `Adresa`, `Vyplata`/`Polozka`, `Zpracovani`) — živě potvrzeno včetně `Vyplata`. - **Testovací prostředí ČSSZ vrací pro dané RČ vždy stejná pevná fiktivní data** (`AktualniNazevSubjektu`, `Adresa`, případné `Vyplata`) nezávisle na tom, jaké `NazevSubjektu` pošleme — odpovídá to na dřívější otevřenou otázku, jak testovací prostředí na libovolné RČ reaguje. - `uzavriTransakci()` (delete) je idempotentní a nemaže podkladová data — poll na uzavřenou transakci dál vrací stejnou finální odpověď. - ČSSZ detekuje duplicitní podání dle obsahu (stejné RČ/exekuční číslo) napříč testy — pro nový test je nutné použít jiná testovací data. ## Fiktivní testovací subjekty Žádný veřejný seznam garantovaných testovacích rodných čísel neexistuje (ověřeno na `cssz.gov.cz/testovani-a-fiktivni-udaje`, v protokolu i obecně). Není to ale potřeba — stačí poslat dotaz s **náhodně vygenerovaným, ale syntakticky platným rodným číslem** (platný kontrolní součet dle běžného algoritmu). Testovací prostředí má vlastní fiktivní databázi subjektů, takže některá z takto vygenerovaných čísel „chytnou" a vrátí reálná testovací data (`AktualniNazevSubjektu`, `Adresa`, případně `Vyplata`) — nezávisle na tom, jaké jméno se pošle v `NazevSubjektu`. Ověřený příklad rodného čísla, které vrací data včetně `Vyplata`/`Polozka` (invalidní důchod): **`951120/0006`** — vrací `AktualniNazevSubjektu` „Nový Petr", `Adresa` „Řecká 1216/19, Děčín VI-Letná, Děčín 2, 40502, CZ". --- ## Původní zjištění (24. 8. 2026, ekcr.cz materiály) — testovací prostředí v materiálech EKČR Ve všem, co je na ekcr.cz k dispozici (distribuční balíček z r. 2013, technická příručka pro exekutory 2010–2011, aktuální .ZFO formulář z 10/2020, XSD schéma), je uvedena **pouze jedna, produkční adresa**. Žádný dokument EKČR nezmiňuje samostatné testovací/staging URL, sandbox, ani jiný postup pro zkušební podání specificky pro exekutory. Testovací prostředí obecně (VREP i ISDS) ale existuje a je zdokumentované přímo ČSSZ — viz aktualizace výše. Zůstává otevřené, jestli funguje i pro `Class=CSSZ_EXI`/EXIDVK bez dalšího dojednání. ## Produkční endpoint a protokol (vytaženo přímo z aktuálního formuláře 1.ZFO, form.fo → fm:submit) ``` method = govtalk action = https://epodani.cssz.cz/vrep/submission govtalk = CSSZ_EXI (identifikátor e-služby) pluginname = cssz.dll classtype = EXIDVK10 crypturl = https://www.cssz.cz/stranky/certifikaty/dis.cssz.aktualni.cer (veřejný šifrovací certifikát ČSSZ, kterým se šifruje podání) usevrep = true ``` Historie adres (z aktualit na ekcr.cz): starší rozhraní bylo na `vrep1.cssz.cz` a `vrep2.cssz.cz`, od 10/2020 nahrazeno adresou `epodani.cssz.cz` (cesta `/vrep/submission`). Toto **není** klasické SOAP (WSDL) ani REST API s veřejnou specifikací pro libovolného vývojáře. Je to protokol "GovTalk" (obálkový formát, viz přesná struktura výše — jde o known standard, ne o vymyšlený proprietární formát ČSSZ), který v praxi realizuje výhradně modul **602 XML Filler** (Software602) přes plugin `cssz.dll`. Aby PHP třída komunikovala přímo bez Filleru, musí sama (aktuální, protokolem v1.47 potvrzený postup — viz sekce „GovTalk obálka" a „CSSZ Message" výše): 1. Sestavit XML podání dle schématu EXIDVK (hlavička + `Dotazy` s 1–1500 `Dotaz`). 2. Podepsat PŮVODNÍ (nezkomprimovaná, nezašifrovaná) data podání **detached PKCS#7/CMS podpisem** (ne XML-DSig!) kvalifikovaným certifikátem pověřené osoby, výsledek zakódovat Base64. 3. Zkomprimovat (gzip) a **v tomto pořadí** zašifrovat stejná původní data veřejným certifikátem ČSSZ (aktuálně `dis.cssz.aktualni.cer` na `cssz.gov.cz`, stahuje se dynamicky) — PKCS/CMS, výsledek zakódovat Base64. 4. Zabalit podpis a zašifrovaná data do „CSSZ Message" (`Message/Header/Signature` + `Header/Vendor` + `Body[encrypted,contentEncoding=gzip]`). 5. CSSZ Message vložit jako přímé XML (ne jako base64 text) do `Body` GovTalk obálky s variabilním symbolem (VS) v `GovTalkDetails/Keys` a **prázdným** `CorrelationID`. 6. Odeslat POST na `https://epodani.cssz.cz/vrep/submission` (POX), nebo použít WSDL `APEP.wsdl` a volat `Submit`/`Poll` přes SOAP. 7. Zpracovat odpověď: obálka je čitelné XML, ale `Body` opět nese CSSZ Message se zašifrovanými daty (u acknowledgementu místo toho podepsanou časovou značku) — dešifrovat a rozbalit (gzip) stejným postupem obráceně. Toto je netriviální — jde fakticky o reimplementaci toho, co dělá 602XML Filler — ale je teď realističtější, protože WSDL i demo C# kód existují (viz odkazy výše), a protokol v1.47 jsme si přímo přečetli (kap. „Podpis", „Šifrování", „Komprimace" obsahují i C# vzory). ## Co je nutné mít, abyste se mohli připojit (produkční provoz, standardní cesta pro exekutorský úřad) Pozn.: toto platí pro exekutorský úřad registrující se přes EKČR. BSP Technology jako vývojář jde jinou, přímou cestou s Trnkou — viz sekce „Kdo je kdo" nahoře. - Kvalifikovaný osobní certifikát pro každou pověřenou osobu (např. PostSignum Qualified CA, I.CA Qualified) — jím se podání podepisuje. - Registraci pověřené osoby u ČSSZ, kterou zprostředkovává Exekutorská komora ČR (ne přímo ČSSZ). Posílá se tabulka `pov_osoby_cssz.xlsx` se sloupci: Exekutorský úřad, Soudní exekutor, Název úřadu, Adresa úřadu, PSČ, Pověřený zaměstnanec (jméno/příjmení), rodné číslo, e-mail, Variabilní symbol (přidělí ČSSZ), Vystavitel certifikátu, sériové číslo certifikátu (hex), typ požadované změny (nové pověření/obnova/zánik). Tabulka se posílá na sběrný e-mail `ekcr@cssz.cz`. - Po registraci ČSSZ přidělí **variabilní symbol (VS)** — ten se musí shodovat s VS v GovTalk obálce podání (jinak chyba 101 „Variabilní symbol z GovTalk obálky … není shodný s VS ve formuláři"). - Aktuální veřejný šifrovací certifikát ČSSZ (z `https://www.cssz.cz/stranky/certifikaty/dis.cssz.aktualni.cer`) pro šifrování podání. - Formulář/verzi schématu: aktuální verze EXIDVK je `verze="2010.1"`, poslední .ZFO šablona `exekutor_exi_v6...` (z 12/2012, aktualizace formuláře 10/2020). ## Struktura požadavku/odpovědi (namespace `http://schemas.cssz.cz/EXI/EXI2010`, kořenový element `EXIDVK`) Viz podrobný diagram v sekci „Dávkové (hromadné) dotazování" nahoře. Shrnutí polí: Požadavek (pozadavekType) obsahuje mj.: - `Okres/KodOSSZ` (kód OSSZ/PSSZ, v praxi jen hodnota 101), `NazevOSSZ` - `ExekutorskyUrad/VS`, `ExekutorskyUrad/Nazev`, `ExekutorskyUrad/Pracovnik` (Jmeno, Prijmeni, RodneCislo) - `SifrovaciCertifikaty` (nepovinné, 1–10× `Certifikat` base64Binary) - `Poznamka` (nepovinné) - `Dotazy/Dotaz[poradoveCislo]` (1–1500×), každý s `RodneCislo`, `NazevSubjektu`, `ExekucniCisloPripadu` (4–10 znaků) Odpověď (odpovedType) obsahuje mj., per položku `Odpoved[poradoveCislo]`: - echované `RodneCislo`, `NazevSubjektu`, `ExekucniCisloPripadu` - `AktualniNazevSubjektu`, `AktualniRodneCislo`, `Adresa` - `Vyplata` (KodAgendy, KodDruhVyplaty, PopisDruhVyplaty, DatumNarokuNaPlatbu, CastkaKVyplaceni, KodStatu, JinyPrijemce) - `Polozka` (KodDavkySrazky, PopisDavkySrazky, CastkaBrutto, CastkaSrazky, CastkaNetto) - `Zpracovani/Vysledek`, `Zpracovani/Kod` (chybové kódy, viz níže) — vlastní pro každou položku Plné XSD (EXI_2010_1_0.xsd + baseTypes.xsd) je v distribučním balíčku `distribuce2013.zip` na ekcr.cz — lze dál rozebrat detailně, pokud budeme stavět mapování polí do PHP. ## Známé chybové kódy (z příručky) - 002 – povinná položka `ExekucniCisloPripadu`/`RodneCislo` chybí - 004/005 – nepovolené znaky v `NazevSubjektu` - 100 – dokument neprošel validaci XSD - 101 – VS z GovTalk obálky neodpovídá VS ve formuláři - 103 – neplatné RČ (kolize EČP a rozšířeného tvaru RČ) - 105 – neplatný base64 řetězec certifikátu (neplatný X.509 certifikát) - 311/314 – neplatné rodné číslo (nedělitelné 11 / datum narození v budoucnu) - PVS 1046 – nesouhlas přihlašovacích údajů (ID, heslo, var. symbol) - PVS 2000 – CorrID (evidenční číslo e-podání) nenalezeno při vyzvednutí odpovědi ## Kontakty - **BSP Technology s.r.o. ↔ ČSSZ (přímý kontakt k testovacímu přístupu):** Ing. Jiří Trnka, `Jiri.Trnka@cssz.gov.cz` - Registrace pověřených osob (exekutoři, přes EKČR — jiná cesta než BSP Technology): e-mail `ekcr@cssz.cz` (od 10/2016; dřív přes EKČR na `komora@ekcr.cz`) - Registrace testovacích údajů (obecně, VREP/HPN): Call centrum **800 050 248**, nebo **Ing. Jiří Trnka, Jiri.Trnka@cssz.gov.cz** - Technická pomoc ČSSZ (dle příručky 2011): telefon 257 063 343 - Technický kontakt na straně EKČR/dodavatele: Ing. Hana Princová (`hana.princova@eucheb.cz`) - Novější technické kontakty ČSSZ (z aktuality 2015, k XML validaci EP, možná použitelné i obecně): Ing. Roman Makovička (`roman.makovicka@cssz.cz`, 724 880 715), Jindřiška Kubátová (`jindriska.kubatova@cssz.cz`) - Podpora EKČR k součinnostem: Vladimír Kubíček, `podpora@ekcr.cz` ## Doporučený další krok 1. ~~Odeslat Trnkovi odpověď se jménem zmocněnce a údaji k certifikátu.~~ **Hotovo** — zmocněnec i certifikát zaregistrovány, Trnka potvrdil, že lze testovat. 2. ~~Ověřit, že sdílení VS s běžnou agendou sociálního pojištění firmy není problém.~~ **Hotovo** — vyjasněno, jde o oddělené, nekolidující větve. 3. ~~Ověřit, zda testovat na produkčním nebo testovacím endpointu.~~ **Hotovo** — testuje se výhradně na testovacím VREP (`t-epodani.cssz.cz`); na produkční endpoint BSP Technology přístup nemá (ten se zřizuje až ke konkrétnímu skutečnému exekutorovi jako klientovi). 4. ~~Ověřit, jestli EXIDVK podporuje dávkové dotazování a jak je vázaná spisová značka.~~ **Hotovo** — potvrzeno: 1–1500 dotazů na podání, spisová značka per dotaz (viz sekce nahoře). 5. ~~Zkusit první testovací podání proti `t-epodani.cssz.cz`~~ **Hotovo** — celá pipeline funguje end-to-end (viz sekce „Implementace" výše). 6. ~~Zjistit, jak se testovací prostředí chová na libovolné validní rodné číslo.~~ **Zjištěno živým testem** — vrací pevná fiktivní data podle RČ, nezávisle na poslaném jméně. 7. ~~Ověřit funkčnost celé transportní/šifrovací vrstvy živým testem.~~ **Hotovo**, včetně `Vyplata`/`Polozka` ve věcné odpovědi. 8. ~~Doplnit do `csszLibrary.php` povinný `delete request` po obdržení finální odpovědi.~~ **Hotovo** — `uzavriTransakci()`. 9. Až bude aplikace hotová a nasazovaná ke konkrétnímu exekutorskému úřadu, teprve tehdy řešit se ČSSZ zřízení produkčního přístupu (to je samostatný krok, mimo tento vývojářský testovací VS). --- ## Příloha: přehled aktualit a dokumentů ze stránky ekcr.cz/exekutor/CSSZ Zdroj: https://ekcr.cz/exekutor/CSSZ (interní stránka Exekutorské komory ČR, vyžaduje přihlášení) Studováno: 24. 8. 2026 Stránka je chronologický přehled aktualit a dokumentace k elektronické výměně dat mezi Exekutorskou komorou ČR a ČSSZ, založené na Dohodě o elektronické výměně dat podepsané 16. 2. 2010 (ostrý provoz od 9. 4. 2010). ### Aktuality (od nejnovější) - **7. 10. 2020** – Nový součinnostní formulář na rozhraní „epodani.cssz.cz" (nahrazuje „vrep1.cssz.cz" a „vrep2.cssz.cz"). Soubor: https://ekcr.cz/uploads/2024/03/21/ac96116658/1.ZFO - **2. 9. 2020** – Verze formuláře s certifikáty Qualified CA 4. Soubor: https://ekcr.cz/uploads/2024/03/21/5d9ea6d4fd/2.xlsx - **24. 9. 2019** – Aktualizované kódy dávek (ČSSZ i Úřad práce). Soubor: https://ekcr.cz/uploads/2024/03/21/9a6a4b364f/3.ZIP - **25. 9. 2018** – Nová verze formuláře s opraveným HTTPS linkem. Soubor: https://ekcr.cz/uploads/2024/03/21/a5fa01f86d/4.zfo - **6. 8. 2018** – Návod na opravu chyby „Nebyl nalezen šifrovací certifikát ČSSZ" ve FormFilleru: změnit link na certifikát na `https://www.cssz.cz/stranky/certifikaty/dis.cssz.aktualni.cer` (bez přílohy) - **19. 9. 2016** – Nová forma zasílání seznamu pověřených osob (registrace certifikátů). Sběrný email ČSSZ: `ekcr@cssz.cz` (nahradil dřívější zasílání na komora@ekcr.cz). Tabulka pověřených osob: https://ekcr.cz/uploads/2024/03/21/631cc82134/5.xlsx - **11. 5. 2015** – Dokumentace k povinnosti zasílat exekuční příkazy (EP) v XML (povinnost od 1. 7. 2013, dle vyhl. č. 418/2001 Sb. a č. 149/2013 Sb.). Vysoký podíl nevalidních/PDF podání (~13 000 EP/měsíc). Kontakty ČSSZ: Ing. Roman Makovička (roman.makovicka@cssz.cz, 724 880 715), Jindřiška Kubátová (jindriska.kubatova@cssz.cz). Příloha: https://ekcr.cz/uploads/2024/03/21/07fd305324/6.ZIP - **5. 3. 2014** – Nová verze formuláře žádosti o součinnost „exekutor_exi_8_publikovano_24.1.2014.zfo", kompatibilní pouze s FormFillerem 4.53.41. Soubor: https://ekcr.cz/uploads/2024/03/21/77baa1c955/7.zfo ### Základní dokumentace k dohodě z roku 2010 - Dohoda o elektronické výměně dat: https://ekcr.cz/uploads/2024/03/21/6f93aee411/8.pdf - Základní informace k výměně dat s ČSSZ: https://ekcr.cz/uploads/2024/03/07/77aeec026c/zakladni_info_2013-01.pdf - Distribuční balíček: https://ekcr.cz/uploads/2024/03/07/94a238161f/distribuce2013.zip - Přihlašovací tabulka k vyplnění: https://ekcr.cz/uploads/2024/03/21/5aac029f7c/9.xls - Formulář žádosti o součinnost (verze 2013, exekutor_exi_7): https://ekcr.cz/uploads/2024/03/21/f9db15ab15/10.zfo - Číselníky kódů dávek ÚP: https://ekcr.cz/uploads/2024/03/21/e9ab802eef/11.zip ### Věcný obsah dohody ČSSZ poskytuje soudním exekutorům (příp. pověřeným zaměstnancům) elektronicky tyto údaje o povinném (dle § 33/3 EŘ): rodné/evidenční číslo pojištěnce, jméno a příjmení, aktuální adresu pro výplatu důchodu, způsob a druh výplaty důchodu, výši důchodu, výši předchozích srážek, výši důchodu po srážkách, údaje o jiném příjemci důchodu, u zahraničních příjemců stát výplaty, příplatky/příspěvky k důchodům. Data se poskytují za poslední 3 měsíce před podáním žádosti. Od 20. 2. 2013 rozšířeno o nepojistné dávky vyplácené úřady práce. Kontaktní osoba pro registraci pověřených osob u ČSSZ: email `ekcr@cssz.cz` (od 1. 10. 2016). EK ČR nemá přístup do seznamu pověřených osob na straně ČSSZ.