# Technická dokumentace: Komunikace exekutorské součinnosti s Centrálním registrem vozidel (CRV)

**Určeno pro:** vývoj PHP knihovny pro součinnost exekutorských úřadů s IS CRV (Ministerstvo dopravy ČR) — **cílem je nový, přímý způsob napojení** (platný od 1. 4. 2016, viz kap. 2.1)
**Relevantní webová služba:** **`ExekutorWS`** — dle přímého potvrzení provozovatele (ICZ a.s., viz kap. 5) je toto **jediná** webová služba CRV určená pro exekutory. `QueryWS` (WSDL `QueryWS.XML`) je určena pro **obce a obecní policii**, nikoliv pro exekutory — v dokumentu je ponechána jen jako referenční ukázka technologie (WS-Security/SOAP), viz kap. 5.2.
**Stav:** aktualizováno na základě reálné odpovědi provozovatele CRV (ICZ a.s. jménem MD ČR) ze dne 2. 9. 2026 — hlavní nejasnosti z předchozí verze jsou vyjasněny, zbývá několik dílčích bodů (viz kap. 9)
**Datum sestavení:** 2. 9. 2026 (aktualizováno po obdržení odpovědi od CRV/ICZ)

---

## 1. Účel a rozsah dokumentu

Tento dokument shrnuje technické a procesní podklady pro napojení exekutorského úřadu na informační systém Centrálního registru vozidel (IS CRV), spravovaný Ministerstvem dopravy ČR (MD ČR). Cílem je poskytnout jednotný referenční materiál pro vývoj PHP knihovny, která bude realizovat SOAP komunikaci s CRV v rámci tzv. exekutorské součinnosti.

Dokument vychází z těchto zdrojů:

| Zdroj | Popis | Poznámka |
|---|---|---|
| `QueryWS.XML` | Aktuální WSDL definice webové služby **QueryWS** (namespace `urn:cz:isvs:mdcr:schemas:crv:query:v1`) | Strojově čitelný, autoritativní zdroj pro rozhraní |
| `CRV_Vydej_dat_Exekutor_Query_WS_v.1_2.pdf` | Textová dokumentace služby **Exekutor Query WS** (verze 1.2, aktualizace 24. 1. 2016), dosud publikovaná jako aktuální na ekcr.cz | Popisuje jinou sadu metod (vyhledávání dle osoby) než WSDL `QueryWS` (vyhledávání dle vozidla) — jde o dvě souběžné služby, viz kap. 5 |
| `Proces_pripojeni_exekutorske_kancelare_vuci_IS_CRV.PDF` | Popis administrativního procesu připojení | |
| `Žádost_o_připojení_exekutorské_kanceláře.pdf` | Formulář žádosti o zřízení přístupu | |
| `crv.png` | Snímek ceníku PostSignum (kvalifikované systémové certifikáty) | |
| https://ekcr.cz/exekutor/centralni_registr_vozidel | Oznámení Exekutorské komory ČR o změně napojení k 31. 3. 2016 | |
| E-mail odpověď ICZ a.s. (David Borovička, Systémový inženýr, Sekce veřejná správa) na dotaz BSP Technology s.r.o. | Odpovědi na 7 konkrétních dotazů k připojení SW dodavatele — viz kap. 5 a 9 | Přijato 2. 9. 2026, odesláno z `webove_sluzby_rsv@i.cz` (v kopii i `servicedesk@crv-md.cz`) — **autoritativní, přímo od provozovatele** |
| E-mail odpověď ICZ a.s. (David Borovička) — 2. doplňující dotaz (certifikát + označení testovacího prostředí v žádosti) | Odpovědi na 2 doplňující dotazy — viz kap. 3, 4.1.2 a 9.1 (body G, H) | Přijato 2. 9. 2026 — **autoritativní, přímo od provozovatele** |
| E-mail odpověď ICZ a.s. (David Borovička) — 3. doplňující dotaz (riziko souběhu testovacího a produkčního přístupu při odlišné IP adrese) | Odpověď na dotaz ohledně dopadu žádosti o testovací prostředí na stávající produkční přístup pilotního úřadu — viz kap. 9.1 (body I, J) a kap. 10 | Přijato 9. 9. 2026 — **autoritativní, přímo od provozovatele** |
| E-mail ICZ a.s. (David Borovička) — provozní oznámení č. 1: výměna certifikátu na `mdcr.cms2.cz` | Avízo o plánované výměně TLS certifikátu na CMS2 endpointu RSV k 16. 9. 2026 | Odesláno 11. 9. 2026 (hromadné oznámení, ne odpověď na dotaz) — viz kap. 5.4 |
| E-mail ICZ a.s. (David Borovička) — provozní oznámení č. 2: výměna certifikátů na `crv-test.mdcr.cz` a `crv.mdcr.cz` | Avízo o plánované výměně TLS certifikátů na testovacím a produkčním koncovém bodu RSV k 15. 9. 2026 — nezávisle potvrzuje URL koncových bodů `ExekutorWS` | Odesláno 11. 9. 2026 (hromadné oznámení, ne odpověď na dotaz) — viz kap. 5.4 a 9.2 (bod 1) |

---

## 2. Právní a organizační kontext

- Přístup exekutorských úřadů k datům CRV se opírá o **zákon č. 120/2001 Sb., exekuční řád, § 33 písm. f)**.
- Data poskytovaná v rámci součinnosti zahrnují dle žádosti o připojení:
  - vlastníka vozidla (u PO: název, sídlo, IČO; u FO: jméno, příjmení, rodné číslo, místo pobytu),
  - provozovatele, pokud není totožný s vlastníkem (stejný rozsah údajů),
  - státní poznávací značku (SPZ/RZ), datum přidělení a odebrání,
  - druh a kategorii vozidla,
  - výrobce, tovární značku, typ a obchodní označení,
  - datum první registrace,
  - účel, pro který je vozidlo určeno,
  - **zástavní práva** váznoucí na vozidle.
- Žadatel se podpisem žádosti zavazuje k mlčenlivosti, ochraně dat proti zneužití a bezodkladnému hlášení bezpečnostních incidentů na Help Desk CRV.

### 2.1 Historie napojení — důležité pro pochopení podkladů

Do **31. 3. 2016** byl provoz zprostředkován serverem **EK ČR** (Exekutorská komora ČR, server „EXCRV") — exekutorské úřady a jejich softwarová řešení třetích stran (uváděny např. AURA, AISoft, AveSoft) přistupovaly k CRV **nepřímo** přes tento server. V tomto modelu služba spravovala i evidenci jednotlivých "osob třetí strany" pomocí operací `OsobaVytvoreni` / `OsobaZruseni` / `OsobaExistuje` (viz kap. 5.3 — dokumentováno v PDF `CRV_Vydej_dat_Exekutor_Query_WS_v.1_2.pdf`).

Od **1. 4. 2016** MD ČR přešlo na **přímý přístup** — server EK ČR byl vypnut bez přechodového období a každý exekutorský úřad se nově autentizuje vůči CRV vlastním systémovým certifikátem. **Vyvíjená PHP knihovna cílí právě na tento nový, přímý způsob napojení** (nikoliv na starší nepřímý model přes server EK ČR).

**Vyjasněno (potvrzeno přímo provozovatelem CRV — ICZ a.s. — e-mailem ze dne 2. 9. 2026, viz kap. 5):** rozdílná sada operací mezi PDF dokumentací a WSDL `QueryWS.XML` **není** otázka staré vs. nové verze téže služby. Jde o **dvě zcela oddělené webové služby pro odlišné skupiny konzumentů dat z Registru silničních vozidel**:

- **`ExekutorWS`** — určena **výhradně pro exekutory**. Toto je jediná služba relevantní pro projekt BSP Technology.
- **`QueryWS`** (dodaný WSDL) — určena **pro obce a obecní policii**, nikoli pro exekutory. Pro tento projekt tedy **není přímo použitelná** — viz kap. 5.

Historická poznámka o modelu „osob třetí strany" (`OsobaVytvoreni`/`OsobaZruseni`/`OsobaExistuje`, kap. 5.3.1) zůstává v platnosti jako součást aktuální služby `ExekutorWS` — nejde o pozůstatek starého modelu EK ČR, ale o standardní součást rozhraní i dnes (potvrzení konkrétního účelu v přímém modelu je ale stále otevřenou otázkou, viz kap. 9).

---

## 3. Proces připojení exekutorského úřadu k IS CRV

1. **Vyplnění žádosti** — formulář „Žádost o zřízení uživatelského konta a přidělení oprávnění k napojení na IS CRV" (název žadatele, IČO, kontaktní údaje, zodpovědná osoba, e-mail, mobil, veřejná IP adresa úřadu).
2. **Odeslání žádosti** — vyplněný a podepsaný formulář na e-mail **servicedesk@crv-md.cz**; dle webu EK ČR zasílat **současně i na** `webove_sluzby_rsv@i.cz`.
   - **Potvrzeno ICZ a.s. (e-mail 2. 9. 2026):** formulář žádosti sám nemá kolonku pro rozlišení testovacího/produkčního prostředí — je nutné do **průvodního e-mailu k žádosti výslovně napsat, že jde o žádost o přístup do testovacího prostředí**. Po úspěšném otestování se posílá **nová (samostatná) žádost** pro přístup do produkčního prostředí — potvrzuje se tím i doporučení z ekcr.cz.
3. **Systémový certifikát** — ověřit, zda úřad již nedisponuje systémovým certifikátem vydaným **PostSignum** (Česká pošta, s. p.), který lze použít i pro CRV. Pokud ne, je nutné jej vyžádat na PostSignum (viz kap. 4).
4. **Vygenerování přístupu do testovacího prostředí** — CRV zašle:
   - uživatelské jméno e-mailem (text: *„Vytvořili jsme pro vás uživatele do testovacího provozu CRV. Vaše uživatelské jméno je XXXXXXXXXX."*),
   - přístupové heslo formou **SMS** na uvedené telefonní číslo.
5. **Otestování proti testovacímu prostředí** — po úpravě systému dle specifikace webové služby (viz kap. 5) ověřit komunikaci vůči testovacímu nástroji: **https://crv-test.mdcr.cz/qws/ExekutorWS.svc** *(pozn.: viz kap. 9 — ověřit aktuálnost této adresy vůči `QueryWS.XML`)*.
6. **Přístup do produkčního prostředí** — po úspěšném otestování CRV zašle přístupové údaje k produkčnímu prostředí stejným způsobem jako v kroku 4.
7. **Ověření proti produkčnímu testovacímu nástroji**: **https://crv.mdcr.cz/qws/ExekutorWS.svc**.
8. **Ostrý provoz** — po úspěšném testu lze čerpat data dle § 33 písm. f) zákona 120/2001 Sb.

### 3.1 Kontakty

| Účel | Kontakt |
|---|---|
| Webové služby CRV (ICZ a.s., Sekce veřejná správa) | `webove_sluzby_rsv@i.cz` — Martin Jelínek (databázový specialista) a David Borovička (systémový inženýr); tel. 607 869 784 (nejasné, které z obou osob konkrétně patří, ale SMS komunikace na toto číslo funguje) |

### 3.2 Specifika pro softwarového dodavatele exekutorského systému (BSP Technology s.r.o.) — potvrzeno provozovatelem

BSP Technology s.r.o. zaslala dne 2. 9. 2026 dotaz na `servicedesk@crv-md.cz` (v kopii `webove_sluzby_rsv@i.cz`); odpověděl **David Borovička, ICZ a.s.** (viz zdroje, kap. 1 a 10). Shrnutí odpovědí:

1. **Žádná výjimka pro softwarové dodavatele neexistuje.** Registrace do testovacího prostředí je vždy vázána na IČO konkrétního oprávněného subjektu (exekutorské kanceláře) — doslova: *„Pokud víme, vždy pod IČO nějakého oprávněného subjektu (exekutorské kanceláře). Na žádné webové službě takovou výjimku nemáme."* → **cesta „a) Pilotní klient" z předchozí verze tohoto dokumentu je jediná potvrzená možnost**: BSP Technology musí vyvíjet a testovat pod přístupem konkrétního exekutorského úřadu (svého budoucího zákazníka), ne pod vlastním IČO.
2. **Otázku plné moci/zmocnění ICZ nezodpověděla** — *„Toto musíte probrat přímo s ministerstvem dopravy. Nemáme s tímto zkušenost."* Je tedy potřeba samostatně oslovit přímo MD ČR (nikoli servicedesk/ICZ), pokud má být tato cesta prověřena.
3. **Otázka veřejné IP adresy u SaaS/centralizovaného řešení je zodpovězena kladně, s omezením:** *„Toto se děje jen výjimečně, ale děje (veřejný internet). Používejte vždy veřejnou IP adresu, ze které se budete dotazovat."* Pro připojení přes tzv. **CMS2** (viz kap. 5, centrální komunikační infrastruktura veřejné správy) taková konstrukce už možná nepůjde — CMS2 přiděluje adresy per ORP. Pro exekutory/veřejný internet lze tedy nasadit vlastní (hostingovou) veřejnou IP adresu dodavatele.

**Praktický závěr pro BSP Technology:** další krok je domluvit se s pilotním exekutorským úřadem (budoucím zákazníkem), který podá žádost pod svým IČO a certifikátem, případně souběžně vznést dotaz na plnou moc přímo na Ministerstvo dopravy ČR, pokud by bylo žádoucí, aby BSP Technology mohla žádost podávat/spravovat jménem klientů napřímo.

---

## 4. Bezpečnost a autentizace

> **⚡ ZÁSADNÍ AKTUALIZACE (17. 9. 2026) — reálný WSDL `ExekutorWS` stažen a bezpečnostní model potvrzen, viz kap. 4.4.** Skutečná politika `ExekutorWS` je mnohem jednodušší, než celá kapitola 4.1–4.3 níže předpokládala na základě `QueryWS.XML` a hypotéz: **žádný klientský certifikát ani WS-Security podpis se nevyžaduje** — jen HTTPS + HTTP Basic Authentication (uživatelské jméno/heslo z kroku 4 v kap. 3). Text 4.1–4.3 je ponechán jako dokumentace úvahy/postupu (a jako referenční popis `QueryWS`), ale **pro implementaci `ExekutorWS` se jím neřiďte** — použijte přímo kap. 4.4.

### 4.1 Certifikát

- Vyžadován certifikát od certifikační autority **PostSignum**.
- Doporučen **kvalifikovaný systémový certifikát (elektronická značka)** — dle přiloženého ceníku (`crv.png`) aktuální (k datu ceníku 11. 6. 2014) cena **780 Kč vč. DPH / rok** (platnost certifikátu 1 rok).
- EK ČR upozorňuje na možnost odvolat se při nákupu na rámcovou smlouvu mezi PostSignum a EK ČR pro zvýhodněnou cenu.
- Pokud úřad používá systémový certifikát od jiné autority nebo žádný nemá, je nutné o certifikát PostSignum zažádat samostatně.

#### 4.1.1 Kvalifikovaný vs. komerční, a otázka hardwarového tokenu (QSCD)

Přesná formulace požadavku se v podkladech liší: `Proces_pripojeni...PDF` (kap. 3) požaduje jen obecně *„systémový certifikát vydaný Českou poštou s.p. (PostSignum)"*, zatímco ekcr.cz jde dál a explicitně **doporučuje** (nikoli striktně vyžaduje) *„kvalifikovaný systémový certifikát (elektronickou značku)"*. Ceník (`crv.png`) rozlišuje **kvalifikované osobní certifikáty**, **kvalifikované systémové certifikáty (elektronická značka)** a samostatně **komerční certifikáty** jako tři různé produkty PostSignum — tedy komerční systémový certifikát je reálná alternativa, jen v podkladech není explicitně potvrzeno, zda ho CRV pro připojení akceptuje.

Z obecné znalosti fungování PostSignum/eIDAS (nepotvrzeno přímo pro CRV, doporučeno ověřit — viz kap. 9.2):

- **Kvalifikovaný certifikát** (ať osobní, nebo systémový/elektronická značka) musí mít dle eIDAS soukromý klíč chráněný **kvalifikovaným prostředkem (QSCD)** — u PostSignum konkrétně token/čipová karta (TokenME EVO, ProID+Q, eToken 5110 CC, IDPrime), nebo pro serverové/automatizované pečetění jejich řešení **ProID QSeal** (server-based zařízení, stále ale postavené na QSCD čipu). Pokud by byl klíč jen v běžném softwarovém úložišti (např. `.p12` volně nasazený v aplikaci), vznikal by už jen tzv. **„zaručený" elektronický podpis/pečeť**, ne kvalifikovaný — tedy certifikát by fakticky přestal plnit funkci „kvalifikovaného", i kdyby byl jako kvalifikovaný vydán.
- **Komerční certifikát** naproti tomu žádný QSCD nevyžaduje a běžně se dodává jako čistě softwarový (exportovatelný `.p12`) — to odpovídá i vlastní zkušenosti s obdobnou integrací (VZP B2B), kde byl pro autentizaci/přístup použit komerční certifikát ve formě `.p12`/`.pem`, zatímco kvalifikovaný osobní certifikát sloužil jen k podpisu.

**Praktický důsledek pro architekturu BSP Technology (SaaS):** pokud by CRV skutečně vyžadovalo, aby byl certifikát **kvalifikovaný** *a zároveň* na hardwarovém QSCD, znamenalo by to nutnost mít token/HSM fyzicky dostupný serveru, který podepisuje SOAP požadavky — netriviální pro vícenájemnou (multi-tenant) serverovou architekturu. Pokud naopak stačí certifikát komerční (nebo lze QSCD nahradit vzdáleným/cloudovým řešením typu ProID QSeal), je nasazení výrazně jednodušší. **Toto je zásadní architektonická otázka a doporučujeme ji vyjasnit přímo s CRV Help Deskem / ICZ ještě před podáním žádosti** (viz kap. 9.2).

#### 4.1.2 Pracovní hypotéza: osobní komerční certifikát exekutora s pověřenou osobou

Alternativní, dobře podložená varianta (návrh zadavatele, 2. 9. 2026): použít **komerční osobní certifikát vystavený na jméno/subjekt exekutora**, na kterém je konkrétní vývojář/administrátor (Daniel Němec, BSP Technology) veden jako **pověřená osoba** — analogicky k modelu, který se běžně používá pro součinnost se základními registry (ISZR/ROB/ROS).

Argumenty, které tuto variantu podporují:

1. **Procesní dokument (kap. 3, bod 3) sám počítá se znovupoužitím existujícího certifikátu**: *„Zkontrolovat, zdali Vámi využívaný systém pro komunikaci s exekutorskou komorou používá systémový certifikát vydaný Českou poštou... V případě, pokud tomu tak je, je možné jej použít i pro komunikaci s IS CRV."* — slovo „systémový" zde pravděpodobně není použito jako přesný název produktu PostSignum, ale popisně (certifikát používaný systémem/komunikací žadatele).
2. **Rozhraní `ExekutorWS` je samo postavené na modelu jmenovité pověřené osoby**, ne jen anonymního certifikátu úřadu: operace `OsobaVytvoreni` zakládá přístup konkrétní osobě (jméno, příjmení, e-mail, telefon, instituce) pod daným `PracovisteKod` a každý dotaz nese `PracovisteKod` + `PracovisteOsobaID` (kap. 5.3.1) — CRV tedy evidentně chce vědět, která konkrétní osoba se ptá, což s modelem „certifikát exekutora + pověřená osoba" korespondují velmi dobře.
3. **Komerční certifikát (ať osobní, nebo systémový) nevyžaduje QSCD/token** (kap. 4.1.1) — tato varianta tedy zároveň řeší architektonické riziko s hardwarovým prvkem na serveru.

Zbývá ověřit: zda CRV pojem „systémový certifikát" bere doslovně jako produktovou kategorii PostSignum, nebo funkčně (jak naznačuje bod 1). **Doporučený první krok:** zjistit u stávajícího poskytovatele certifikátu pilotního exekutorského úřadu, zda jde skutečně o komerční osobní certifikát PostSignum s pověřenou osobou, a pokud ano, zkusit ho rovnou nahlásit v žádosti o připojení k CRV s odkazem na výše uvedenou větu o znovupoužití; případně to explicitně potvrdit i s ICZ/CRV Help Deskem.

**Aktualizace — skutečný stav (17. 9. 2026):** BSP Technology (Daniel Němec) disponuje vlastním platným komerčním certifikátem **vystaveným na své vlastní jméno** — tedy variantou odlišnou od výše popsané hypotézy (certifikát exekutora + Daniel jako pověřená osoba). Jde o zatím **neověřený scénář**: zda CRV/ExekutorWS akceptuje jako klientský certifikát pro WS-Security certifikát vydaný přímo vývojáři/dodavateli, nezávislý na identitě exekutorského úřadu, případně v kombinaci s registrací Daniela jako osoby přes `OsobaVytvoreni` pod `PracovisteKod` úřadu. **Doporučený další krok:** vyzkoušet přímo — nyní jsou k dispozici jak přístupové údaje (kap. 10, milník 17. 9. 2026), tak tento certifikát, takže lze provést reálný test (pokus o stažení WSDL, případně první SOAP volání `Status`) místo dalšího teoretizování.

**Aktualizace — odpověď ICZ a.s. (e-mail, 2. 9. 2026):** na dotaz, zda je komerční certifikát exekutora s pověřenou osobou dostatečný a jak jej předat CRV, odpověděl David Borovička stručně: *„certifikát by neměl být potřeba."* Tuto odpověď čteme takto: **certifikát není potřeba nikam předem posílat/registrovat** — potvrzuje se tím hypotéza z kap. 4.2, že se certifikát (jeho veřejná část) posílá automaticky jako součást WS-Security hlavičky s každým SOAP požadavkem, a server jej ověřuje za běhu proti důvěryhodnému kořeni. Odpověď byla ale velmi stručná a bez dalšího kontextu, takže nelze zcela vyloučit ani doslovnější výklad („pro tento krok/účel certifikát vůbec nepotřebujete") — to by ovšem bylo v rozporu s tím, že `ExekutorWS` dle WSDL/politiky obdobné `QueryWS` vyžaduje X.509 podpis SOAP zpráv. **Doporučujeme výklad ověřit až v praxi** (první testovací volání) a v případě nejasností se doptat konkrétněji.

### 4.2 WS-Security (dle WSDL `QueryWS.XML`)

Služba `QueryWS` je zabezpečena na dvou úrovních současně:

- **Transport**: HTTPS (`HttpsToken`, `RequireClientCertificate=false` — tedy TLS bez vyžadování klientského TLS certifikátu na této úrovni), `Basic256` algoritmy.
- **Message-level (WS-Security)**: podpis a/nebo šifrování SOAP těla pomocí **X.509 v3 certifikátu** (`WssX509V3Token10`), s referencí přes `RequireThumbprintReference`. Všechny operace mají definovánu politiku `SignedParts` na `soap:Body` — tělo požadavku i odpovědi je podepisováno.
- **HTTP Basic Authentication** je navíc vyžadována jako doplňková vrstva (`http:BasicAuthentication`) — to odpovídá kroku 4 procesu připojení, kde je úřadu přiděleno uživatelské jméno a heslo.
- **Trust10 / WSS11**: `MustSupportIssuedTokens`, `RequireClientEntropy`, `RequireServerEntropy`, `MustSupportRefThumbprint`, `MustSupportRefEncryptedKey`.

WSDL definuje **dva bindingy / dva porty služby**, které se liší typem kryptografické vazby:

| Port (binding) | Typ vazby | Endpoint (testovací prostředí) |
|---|---|---|
| `QueryEP1` | **SymmetricBinding** — sdílený tajný klíč odvozený z certifikátu (`X509Token`, `IncludeToken=Never` u ProtectionToken, `AlwaysToRecipient` u EndorsingSupportingTokens) | `https://crv-test.mdcr.cz/services/QueryWS.svc/SecCfg1` |
| `QueryEP2` | **AsymmetricBinding** — klasický asymetrický WS-Security model (Initiator/Recipient token) | `https://crv-test.mdcr.cz/services/QueryWS.svc/SecCfg2` |

Produkční adresy nebyly v podkladech explicitně uvedeny (WSDL obsahuje pouze testovací `crv-test.mdcr.cz`); dle procesního dokumentu lze očekávat produkční ekvivalent na `crv.mdcr.cz`, analogicky ke vzoru `.../qws/ExekutorWS.svc` → `crv.mdcr.cz/qws/ExekutorWS.svc` — **je třeba ověřit přesnou produkční URL pro QueryWS** (viz kap. 9).

### 4.3 Důsledky pro PHP implementaci (platí pro `QueryWS` — referenční, viz kap. 4.4 pro `ExekutorWS`)

Nativní PHP `SoapClient` **nepodporuje WS-Security (podpis/šifrování zprávy X.509 certifikátem)** bez rozšíření. Pro implementaci `QueryWS` by bylo nutné buď:

- použít knihovnu s podporou WS-Security, např. `robrichards/wse-php` (rozšiřuje `SoapClient` o podpis/šifrování WS-Security hlaviček) v kombinaci s HTTP Basic Auth stream kontextem, nebo
- ruční sestavení SOAP envelope s `wsse:Security` hlavičkou a podpisem přes `openssl` (XML-DSig), pokud hotová knihovna nebude vyhovovat všem požadovaným politikám (Basic128/Basic256, Strict layout, timestamp),
- ověřit, zda CRV v praxi vyžaduje **oba** mechanismy současně (message-level podpis **i** Basic Auth), nebo jde o alternativní politiky vážené `wsp:ExactlyOne`/`wsp:All` (ve WSDL je vnořeno do `ExactlyOne > All`, což znamená, že **všechny** prvky uvnitř `All` musí být splněny současně — tedy ano, oba mechanismy jsou vyžadovány zároveň).

**Toto vše je pro `ExekutorWS` irelevantní — viz kap. 4.4: tam nic z výše uvedeného není potřeba.**

### 4.4 Potvrzený reálný bezpečnostní model `ExekutorWS` (ověřeno 17. 9. 2026, přímo z WSDL)

Daniel Němec stáhl reálný WSDL testovacího prostředí příkazem:

```bash
curl -u 'UZIVATELSKE_JMENO:SMS_HESLO' "https://crv-test.mdcr.cz/qws/ExekutorWS.svc?wsdl"
```

→ **HTTP 200 OK**, bez jakéhokoli klientského certifikátu — jen s uživatelským jménem a heslem přidělenými v kroku 4 (kap. 3). Bezpečnostní politika ve WSDL (`ExekutorEP_policy`) obsahuje jen:

```xml
<http:BasicAuthentication/>
<sp:TransportBinding>
  <sp:TransportToken><sp:HttpsToken RequireClientCertificate="false"/></sp:TransportToken>
  <sp:AlgorithmSuite><sp:Basic256/></sp:AlgorithmSuite>
</sp:TransportBinding>
```

Žádný `sp:AsymmetricBinding`/`SymmetricBinding`, žádný `X509Token`, žádné `EndorsingSupportingTokens`, žádné `SignedParts` na těle zprávy — na rozdíl od `QueryWS` (kap. 4.2) **`ExekutorWS` nepoužívá WS-Security message-level podpis vůbec**. Zabezpečení je jen:

1. **Transport**: HTTPS, `RequireClientCertificate="false"` — žádný klientský TLS certifikát se nevyžaduje ani nepoužívá.
2. **HTTP Basic Authentication** — uživatelské jméno + heslo (přidělené SMS/e-mailem, kap. 3 bod 4) v hlavičce `Authorization: Basic ...`.

**Praktický důsledek — zásadní zjednodušení:**
- **Komerční certifikát BSP Technology / Daniela Němce se pro `ExekutorWS` vůbec nepoužije.** Celá diskuze v kap. 4.1–4.1.2 (kvalifikovaný vs. komerční certifikát, QSCD/token, „certifikát exekutora s pověřenou osobou") se ukázala jako **irelevantní pro tuto konkrétní službu** — patrně platí jen pro `QueryWS` (obce). Odpověď ICZ „certifikát by neměl být potřeba" (kap. 9.1, bod H) tedy měla být čtena **doslovně**, ne jako „posílá se automaticky s WS-Security hlavičkou" — žádná WS-Security hlavička s certifikátem u `ExekutorWS` vůbec neexistuje.
- Role Daniela jako „pověřené osoby" (operace `OsobaVytvoreni`, kap. 5.3.1) je tedy zjevně **administrativní/auditní evidence konkrétní osoby u úřadu**, nezávislá na jakémkoli certifikátu — přihlašování k `ExekutorWS` samotnému jde čistě přes uživatelské jméno/heslo úřadu.
- **PHP implementace se výrazně zjednodušuje:** stačí nativní `SoapClient` s HTTP Basic Auth (`login`/`password` v konstruktoru, nebo stream context), **žádná knihovna pro WS-Security (`robrichards/wse-php`) ani správa certifikátu/klíče v aplikaci není potřeba.**
- Doporučujeme (kap. 5.4) **nepoužívat certificate pinning** vůči serverovému certifikátu `crv-test.mdcr.cz`/`crv.mdcr.cz` a spolehnout se na standardní ověření řetězu důvěry (PostSignum Public CA 5) — server ho dle plánu i tak pravidelně mění.

**Přímo stažený a ověřený WSDL** potvrzuje i endpoint (`soap:address location="https://crv-test.mdcr.cz/qws/ExekutorWS.svc"`) a operace `Status`, `VyhledejICO`, `VyhledejRC`, `OsobaVytvoreni` (parametry `PracovisteKod` [50 zn.], `Jmeno` [100], `Prijmeni` [100], `Email` [150], `Telefon` [50], `Instituce` [150], `Poznamka` [100]), `OsobaZruseni`, `OsobaExistuje` — přesně odpovídá tabulce v kap. 5.3.1. Výčtové typy (`VozidloStatusKod` apod.) nejsou ve WSDL přímo, ale v importovaných XSD schématech (`?xsd=xsd0`…`xsd4`) — doporučeno stáhnout je v dalším kroku.

---

## 5. Přehled webových služeb

**Potvrzeno provozovatelem (ICZ a.s., e-mail 2. 9. 2026):** *„Registr silničních vozidel má pro různé subjekty různé webové služby. QueryWS je pro obce a obecní policii, ExekutorWS pro exekutory. Nevíme o případu, kdy by to měl uživatel jinak."*

Pro PHP knihovnu BSP Technology je tedy relevantní **pouze `ExekutorWS`** (kap. 5.3). Přehled `QueryWS` (kap. 5.2) je v dokumentu ponechán jako referenční materiál — ukazuje stejný technologický základ (SOAP, WS-Security, X.509), který dle potvrzení ICZ (bod 4 jejich odpovědi) sdílí i `ExekutorWS`: *„Ano. Obě jsou to SOAP webové služby. WSDL jde stáhnout z jejich koncových bodů (v testovacím i produkčním prostředí)."* — tedy **i pro `ExekutorWS` existuje strojově čitelný WSDL**, stažitelný přímo z endpointu služby (typicky přidáním `?wsdl` k URL), stejně jako jsme jej dostali pro `QueryWS`. Doporučujeme jej stáhnout a použít jako primární zdroj pro generování SOAP klienta — PDF popis v kap. 5.3 slouží jen jako doplňkový/obchodní kontext, ne jako závazná technická specifikace.

ICZ dále zmínila existenci alternativního přístupového kanálu **CMS2** (centrální místo služeb, komunikační infrastruktura veřejné správy pro ORP a další orgány) coby druhou možnost vedle připojení přes veřejný internet — se stejnou URL, lišící se jen tím, jaká IP adresa se vrací při překladu adresy. Pro BSP Technology / exekutory je relevantní varianta přes **veřejný internet**, ne CMS2 (ta je typicky pro ORP).

### 5.1 Service Status (společné oběma službám)

Obě služby nabízejí operaci **`Status`**, která vrací informaci o tom, zda je služba a jednotlivé metody zapnuty. Pokud je konkrétní metoda vypnuta, volání vrací chybu `SluzbaVypnuta`. Doporučuje se, aby PHP knihovna před dávkovým zpracováním nebo periodicky ověřovala stav služby přes `Status`.

### 5.2 Služba `QueryWS` — REFERENČNÍ, není určena pro exekutory

> **Upozornění:** dle ICZ a.s. je tato služba určena **pro obce a obecní policii**, ne pro exekutory (kap. 5). Ponecháno v dokumentu jako technická ukázka; pro implementaci PHP knihovny použijte `ExekutorWS` (kap. 5.3).

**Namespace:** `urn:cz:isvs:mdcr:schemas:crv:query:v1`
**Vyhledávání:** podle **registrační značky (RZ)** nebo **VIN** (nikoli podle RČ/IČO vlastníka).
**Produkční URL (potvrzeno ICZ, 2. 9. 2026):** `https://crvt.mdcr.cz/services/QueryWS.svc` — pozn.: doména je `crvt.mdcr.cz`, nikoli `crv.mdcr.cz`; totožná URL slouží pro přístup jak přes CMS2, tak přes veřejný internet, liší se jen tím, na jakou IP adresu se přeloží.

#### 5.2.1 Operace

| Operace | Vstup | Výstup | Popis |
|---|---|---|---|
| `Status` | — | `StatusStructure` | Stav služby a jednotlivých metod |
| `CtiVozidloRZ` | `ZadatelInfo`, `RegistracniZnacka`, `PlatnostKeDni` | `VozidloStructure` | Základní údaje o vozidle dle RZ, platné k danému dni |
| `CtiVozidloVIN` | `ZadatelInfo`, `IdentifikacniCisloVozidla`, `PlatnostKeDni` | `VozidloStructure` | Základní údaje o vozidle dle VIN |
| `CtiVozidloSPopisemRZ` | `ZadatelInfo`, `RegistracniZnacka`, `PlatnostKeDni` | `VozidloSPopisemStructure` | Základní údaje + technický popis dle RZ |
| `CtiVozidloSPopisemVIN` | `ZadatelInfo`, `IdentifikacniCisloVozidla`, `PlatnostKeDni` | `VozidloSPopisemStructure` | Základní údaje + technický popis dle VIN |
| `CtiVozidloKompletRZ` | `ZadatelInfo`, `RegistracniZnacka`, `PlatnostKeDni` | `VozidloKompletStructure` | Kompletní údaje (+ majitel) dle RZ |
| `CtiVozidloKompletVIN` | `ZadatelInfo`, `IdentifikacniCisloVozidla`, `PlatnostKeDni` | `VozidloKompletStructure` | Kompletní údaje (+ majitel) dle VIN |

Všechny vyhledávací operace vyžadují:
- `ZadatelInfo` (typ `ZadatelInfoStructure`): `DotazDuvod` (důvod dotazu — text, pro audit), `PracovisteKod` (kód pracoviště).
- `PlatnostKeDni` (`dateTime`) — den, ke kterému má být platnost údajů posuzována (umožňuje dotaz na historický stav).

#### 5.2.2 Datové struktury

**`VozidloStructure`** (základní údaje):

| Element | Typ | Occurs | Popis |
|---|---|---|---|
| `Barva` | string | 0..1 | Barva karoserie |
| `IdentifikacniCislo` | string | 1 | VIN, příp. číslo karoserie |
| `Provozovatel` | `SubjektStructure` | 0..1 | Provozovatel vozidla |
| `RegistraceOsvedceniCislo` | string | 0..1 | Číslo osvědčení o registraci |
| `RegistracniZnacka` | string | 0..1 | RZ vozidla |
| `Status` | `VozidloStatusKod` | 1 | Stav vozidla (výčet níže) |
| `TechnickyPrukazCislo` | string | 0..1 | Číslo technického průkazu |
| `TovarniTypNazev` | string | 1 | Tovární označení typu |
| `VozidloID` | int | 1 | Interní identifikátor záznamu |

**`VozidloSPopisemStructure`** = `VozidloStructure` + `TechnickyPopis` (`ZakladniTechnickyPopisStructure`):
`Hmotnosti`, `Karoserie`, `Motor`, `Napravy`, `ObchodniOznaceni`, `Rozmery`, `TovarniTyp`, `TovarniZnacka`, `Varianta`, `Verze`, `VozidloDruhNazev`, `VozidloKategorieKod`.

- `HmotnostiStructure`: `Celkova`, `JizdniSoupravaCelkem`, `Naprava1..4`, `PripojneVozidloBrzdene`, `PripojneVozidloNebrzdene`, `Provozni`, `ZatizeniSpojovacihoZarizeni`.
- `KaroserieStructure`: `KaroserieTypNazev`, `LuzkaPocet`, `MistaSezeniPocet`, `MistaStaniPocet`.
- `MotorStructure`: `MotorTypNazev`, `MotorZdvihovyObjem`, `PalivoDruh`.
- `NapravyStructure`: `CelkemPocet`, `PohanenePocet`.
- `RozmeryStructure`: `Delka`, `Rozvor`, `Sirka`, `Vyska`.

**`VozidloKompletStructure`** = `VozidloSPopisemStructure` + `Majitel` (`SubjektStructure`), `ZaevidovanoPoprveCRDatum` (první registrace v ČR), `ZaevidovanoPoprveDatum` (první registrace ve světě).

**`SubjektStructure`** (abstraktní, rozlišeno přes `DruhKod`) — konkrétní subtypy nejsou ve zkoumaném WSDL fragmentu plně rozvedeny nad rámec `common:datatypes:v1` schématu, ale schéma definuje minimálně:
- `EkonomickySubjektStructure`: `SubjektIdentifikacniCislo` (IČO), `SubjektNazev`, `SidloAdresniMisto`.
- `ObyvatelStructure`: `ObyvatelRodneCislo`, `Jmeno`, `Prijmeni`, `PrijmeniRodne`, `NarozenDatum`, `PobytAdresniMisto`.
- `CiziOsobaStructure`: `CiziOsobaID`, `Identifikace`, `SubjektNazev`, `SubjektIdentifikacniCislo`, `OsobaJmeno`, `OsobaPrijmeni`, `OsobaNarozenDatum`, `OsobaRodneCislo`, adresní údaje (`UliceNazev`, `ObjektCisloPopisne`, `CastObceNazev`, `ObecNazev`, `OkresNazev`, `KrajNazev`, `StatNazev`).
- `AdresniMistoStructure`: `ObjektKod`, `ObjektCisloPopisne`, `ObjektCisloOrientacni`, `UliceKod`, `UliceNazev`, `CastObceKod`, `CastObceNazev`, `ObecKod`, `ObecNazev`, `PSC`, `ObecRozsirenaPusobnostKod`, `ObecRozsirenaPusobnostNazev`, `OkresKod`, `OkresNazev`, `KrajKod`, `KrajNazev`.

#### 5.2.3 Výčtové typy

**`SubjektDruhKod`**: `Obyvatel` (1), `EkonomickySubjekt` (2), `CiziOsoba` (3).

**`VozidloStatusKod`**: `Nezjisteno`, `Provozovane`, `Odhlaseno`, `OdhlasenoCizina`, `TrvaleVyrazeno`, `VracenoVGaranci`, `Odcizeno`, `ZadejPisemne`, `DocasneVyrazeno`, `VPrevodu`, `Paragraf15`.

**`QueryFaultKod`** (chyby SOAP Fault typu `QueryFaultStructure`, s elementy `Kod` a `Popis`):

| Kód (číslo) | Hodnota | Význam |
|---|---|---|
| 1 | `ChybiPovinnyParametr` | Nebyl zadán povinný vstupní parametr |
| 2 | `NepovolenaKombinaceParametru` | Nepovolená kombinace vstupních parametrů |
| 3 | `HodnotaMimoRozsah` | Vstupní parametr má hodnotu mimo povolený rozsah |
| 4 | `KratkaHodnotaProHledani` | Do hledání zadán příliš krátký řetězec |
| 5 | `NejednoznacneHledani` | Výsledek hledání je nejednoznačný (více záznamů) |
| 6 | `SluzbaVypnuta` | Služba (nebo metoda) je vypnuta |

Každá operace vrací tento fault jako svůj jediný definovaný `wsdl:fault` (`QueryFaultStructureFault`).

### 5.3 Služba `ExekutorWS` / „Exekutor Query WS" — HLAVNÍ CÍLOVÁ SLUŽBA pro tuto knihovnu

> **✅ Reálné XSD schéma stažené a ověřené (17. 9. 2026)** — vše níže v 5.3.1–5.3.2 je nyní **přímo z autoritativního zdroje** (`?xsd=xsd0` až `xsd4` z `https://crv-test.mdcr.cz/qws/ExekutorWS.svc`), ne odvozeno z PDF v1.2. Kde se to lišilo od PDF, platí XSD.

**Vyhledávání:** podle **rodného čísla (RČ)** nebo **IČO** vlastníka/provozovatele (nikoli dle RZ/VIN).
Zahrnuje **správu uživatelů třetí strany** (`OsobaVytvoreni`/`OsobaZruseni`/`OsobaExistuje`).

#### 5.3.1 Operace — přesné vstupy a výstupy (dle XSD)

| Operace | Vstup | Výstup |
|---|---|---|
| `Status()` | *(žádný)* | `StatusResult`: `StatusStructure` |
| `VyhledejICO(ZadatelInfo, Ico, Strana, NaStranu)` | `ZadatelInfo`: `ZadatelInfoStructure` (povinné); `Ico`: string (povinné); `Strana`: int (povinné); `NaStranu`: int (povinné) | `VyhledejICOResult`: `ArrayOfVozidloStructure` |
| `VyhledejRC(ZadatelInfo, Rc, Strana, NaStranu)` | `ZadatelInfo`: `ZadatelInfoStructure` (povinné); `Rc`: string (povinné); `Strana`: int; `NaStranu`: int | `VyhledejRCResult`: `ArrayOfVozidloStructure` |
| `OsobaVytvoreni(PracovisteKod, Jmeno, Prijmeni, Email, Telefon, Instituce, Poznamka)` | Všechny parametry `string`, všechny povinné | `OsobaVytvoreniResult`: `int` (ID nově založené osoby) |
| `OsobaZruseni(PracovisteKod, OsobaID)` | `PracovisteKod`: string; `OsobaID`: int | `OsobaZruseniResult`: `bool` |
| `OsobaExistuje(PracovisteKod, OsobaID)` | `PracovisteKod`: string; `OsobaID`: int | `OsobaExistujeResult`: `bool` |

> **Oprava názvu parametru:** vstupní struktura pro `VyhledejICO`/`VyhledejRC` se ve skutečném XSD jmenuje **`ZadatelInfo`** (ne `ZadavatelInfo`, jak jsme dřív předpokládali z PDF) — v PHP kódu použijte přesně tento název.

> **Zjištěno živým testem (23. 9. 2026):** „žádné vozidlo" může od `VyhledejRC`/`VyhledejICO` přijít **dvěma různými způsoby**, ne jen jako chyba `Nenalezeno`:
> 1. SOAP Fault s `Kod = "Nenalezeno"` (pozorováno u zjevně neplatných/krátkých RČ, viz kap. 5.3.2),
> 2. **běžná úspěšná odpověď** s prázdným `VyhledejRCResult`/`VyhledejICOResult` (žádný `VozidloStructure` uvnitř) — pozorováno u validně vyhlížejících RČ (viz testovací RČ níže).
>
> Není potvrzeno, co přesně rozhoduje, kterou z variant CRV zvolí (možná: `Nenalezeno` = RČ/IČO vůbec neodpovídá žádné evidované osobě, zatímco prázdný úspěšný výsledek = osoba existuje, ale nemá žádné vozidlo) — viz otevřená otázka v kap. 9.2.

**`ZadatelInfoStructure`** (namespace `...exekutor:datatypes:v1`):

| Pole | Typ | Popis |
|---|---|---|
| `DotazDuvod` | string (nullable v XSD, ale prakticky povinný) | Důvod dotazu (volný text, pro auditní účely, kap. 6). **Povinnost ověřena přímo (23. 9. 2026):** prázdný řetězec CRV odmítne chybou `ChybiPovinnyParametr` na `ZadatelInfo.DotazDuvod` — XSD ho sice označuje jako nullable, ale byznysově je vyžadován neprázdný obsah. Přesný formát/náležitosti obsahu ICZ nepotvrdila. |
| `PracovisteKod` | string | Kód pracoviště exekutorského úřadu — **volí si ho BSP Technology sama, viz 5.3.3.** |
| `PracovisteOsobaID` | int | ID konkrétní osoby pod daným pracovištěm — **vrací ho `OsobaVytvoreni`, viz 5.3.3.** |

**`StatusStructure`** (namespace `...query:datatypes:v1` — sdílená s `QueryWS`):

| Pole | Typ | Popis |
|---|---|---|
| `PocetNaStranu` | int | Aktuální max. počet záznamů na stránku |
| `Zapnuto` | bool | Služba jako celek zapnuta |
| `ZapnutoICO` | bool | Metoda `VyhledejICO` zapnuta |
| `ZapnutoOsoba` | bool | Metody správy osob zapnuty |
| `ZapnutoRC` | bool | Metoda `VyhledejRC` zapnuta |

Stránkování: `Strana` a `NaStranu` — max. velikost stránky je vidět v `StatusStructure.PocetNaStranu`.

> **Zjištěno živým testem (24. 9. 2026): `Strana` je číslovaná od 0, ne od 1.** Subjekty s málo vozidly (typicky fyzické osoby na RČ) při `Strana=1` vrátí prázdný, ale úspěšný výsledek (žádný `<s:Fault>`, jen prázdné `VyhledejRCResult`/`VyhledejICOResult`) — `Strana=1` je totiž **druhá** stránka, ne první. Objeveno na třech RČ, u kterých ICZ (David Borovička, 23. 9. 2026 a Martin Jelínek, 24. 9. 2026) potvrdila aktivní vozidla v systému, ale `VyhledejRC` se `Strana=1` u nich vracelo prázdno; se `Strana=0` vozidla našlo. Ani jedno z toho nebyl `ChybnyFormat`/`HodnotaMimoRozsah` — obojí bylo tiché, „validní" chování, což tuhle chybu činí zvlášť zákeřnou (vypadá jako „subjekt nemá auto", ne jako chyba dotazu). Nedokumentováno nikde v PDF ani WSDL/XSD — žádná anotace neuvádí, od kolika se `Strana` čísluje. Viz kap. 9.1, bod S.

**`VozidloStructure`** (kompletní, dle XSD) — toto vrací `VyhledejICO`/`VyhledejRC` jako pole (`ArrayOfVozidloStructure`):

| Pole | Typ | Povinné | Popis |
|---|---|---|---|
| `VozidloID` | int | ano | Interní ID vozidla v CRV |
| `IdentifikacniCislo` | string | ne | VIN |
| `RegistracniZnacka` | string | ne | SPZ |
| `Barva` | string | ne | Barva |
| `TovarniZnacka` | string | ne | Výrobce/značka |
| `TovarniTypNazev` | string | ne | Typ |
| `ObchodniOznaceni` | string | ne | Obchodní označení |
| `VyrobaRok` | unsignedShort | ano | Rok výroby |
| `Status` | `VozidloStatusKod` | ano | Stav vozidla |
| `Majitel` | `SubjektStructure` (polymorfní) | ne | Vlastník |
| `Provozovatel` | `SubjektStructure` (polymorfní) | ne | Provozovatel (pokud jiný než vlastník) |
| `PlatnostRZ` | dateTime | ne | Platnost registrační značky |
| `ZaevidovanoPoprveDatum` | dateTime | ne | Datum první registrace |
| `ZastavniPravo` | bool | ne | **Zástavní právo — klíčové pro exekuční účely** |
| `VozidloAutonomniStupen` | string | ne | Stupeň autonomního řízení (nový/neočekávaný údaj) |

**`SubjektStructure`** (`Majitel`/`Provozovatel`) je **polymorfní** — základní typ nese jen `DruhKod` (`SubjektDruhKod`), skutečný obsah je v jednom z těchto rozšíření podle `DruhKod`:

- **`ObyvatelStructure`** (`DruhKod = Obyvatel`): `ObyvatelRodneCislo` (ne), `Jmeno` (ano), `Prijmeni` (ano), `PrijmeniRodne` (ne), `NarozenDatum` (ano), `PobytAdresniMisto`: `AdresniMistoStructure` (ano).
- **`EkonomickySubjektStructure`** (`DruhKod = EkonomickySubjekt`): `SubjektIdentifikacniCislo` (IČO, int, ano), `SubjektNazev` (ano), `SidloAdresniMisto`: `AdresniMistoStructure` (ano).
- **`CiziOsobaStructure`** (`DruhKod = CiziOsoba`): `CiziOsobaID` (ano), + volitelné plošší adresní/osobní pole (`Identifikace`, `SubjektNazev`, `SubjektIdentifikacniCislo`, `OsobaJmeno`, `OsobaPrijmeni`, `OsobaNarozenDatum`, `OsobaRodneCislo`, `UliceNazev`, `ObjektCisloPopisne`, `CastObceNazev`, `ObecNazev`, `PSC` [string!], `OkresNazev`, `KrajNazev`, `StatNazev`) — bez strukturovaného `AdresniMistoStructure`.

**`AdresniMistoStructure`**: `ObjektKod` (ano), `ObjektCisloPopisne`/`ObjektCisloOrientacni`/`ObjektCisloOrientacniPismeno` (ne), `UliceKod`/`UliceNazev` (ne), `CastObceKod`/`CastObceNazev` (ne), `ObecKod`/`ObecNazev` (ano), `PSC` (int, ano), `ObecRozsirenaPusobnostKod`/`ObecRozsirenaPusobnostNazev` (ano), `OkresKod`/`OkresNazev` (ano), `KrajKod`/`KrajNazev` (ano). Shodné s `AdresniMistoStructure` u `QueryWS` (kap. 5.2.2).

**Poznámka k PHP mapování:** `SubjektStructure`/`ObyvatelStructure`/atd. je typický XML-Schema polymorfismus (`xs:extension`) — nativní PHP `SoapClient` ho obvykle deserializuje jako `stdClass` s poli obou úrovní sloučenými dohromady, bez explicitní informace o tom, který podtyp to je. **V PHP knihovně bude nutné podtyp odvodit z `DruhKod`** a podle něj mapovat na příslušnou PHP třídu/DTO.

#### 5.3.2 Výčtové typy (dle XSD, s číselnými hodnotami)

**`ExekutorFaultKod`** (struktura chyby: `Kod` + `Popis`):

**Opraveno (ověřeno reálným voláním, 23. 9. 2026):** element `Kod` v SOAP Fault nese **textový název hodnoty výčtu** (např. `"ChybiPovinnyParametr"`), ne číslo z levého sloupce tabulky níže — to číslo je zjevně jen pořadí ve výčtu podle XSD anotace, ne skutečně přenášená hodnota. Potvrzeno reálnou chybou `OsobaVytvoreni` s prázdným `Telefon`, která přišla jako `Kod="ChybiPovinnyParametr"` (ne `Kod="1"`). **PHP knihovna proto musí porovnávat podle textového názvu ve sloupci Hodnota, ne podle čísla.**

| Kód | Hodnota | Význam |
|---|---|---|
| 1 | `ChybiPovinnyParametr` | Nebyl zadán povinný vstupní parametr |
| 2 | `Nejednoznacne` | Výsledek hledání je nejednoznačný (RČ nebo IČO) |
| 3 | `ChybnyFormat` | Chybný formát RČ nebo IČO |
| 4 | `HodnotaMimoRozsah` | Hodnota mimo rozsah |
| 5 | `NeznamePracoviste` | Neznámé pracoviště (`PracovisteKod` nebo `PracovisteOsobaID`) |
| 6 | `Nenalezeno` | Nenalezeno (RČ nebo IČO) |
| 7 | `SluzbaVypnuta` | Služba vypnuta |

**Zjištěno živým testem (23. 9. 2026):** `VyhledejRC` s podezřele krátkým/nevalidním RČ (`"760"`, 3 číslice) nevrátilo `ChybnyFormat`, ale `Nenalezeno` (`Popis` = `"rc: 760"`) — CRV tedy formát RČ před samotným hledáním nekontroluje tak přísně, jak by název `ChybnyFormat` naznačoval, aspoň ne pro tenhle případ. Co přesně `ChybnyFormat` vyvolá, zůstává nepotvrzené (viz kap. 9.2, bod 5).

**`VozidloStatusKod`** — **opraveno oproti dřívějšímu odhadu z PDF** (ten byl nesprávně sloučen s výčtem `QueryWS`, kap. 5.2.3 — `ExekutorWS` má vlastní, jiný výčet):

| Hodnota | Číselný kód |
|---|---|
| `Nezjisteno` | *(bez čísla v anotaci)* |
| `Provozovane` | *(bez čísla v anotaci)* |
| `DocasneVyrazeno` | 8 |
| `VPrevodu` | 9 |
| `Paragraf8a` | 102 |

**`SubjektDruhKod`**: `Neznamy`, `Obyvatel`, `EkonomickySubjekt`, `CiziOsoba`.

#### 5.3.3 `PracovisteKod` a `PracovisteOsobaID` — vyřešeno (ICZ, 22. 9. 2026)

Datový model je kompletní a postup je teď potvrzený:

- **`PracovisteKod` si BSP Technology volí a vytváří sama** — **potvrzeno ICZ (David Borovička, e-mail 22. 9. 2026):** *„Pracoviště a osoby si vytváříte sami. Ministerstvo je vyžaduje z auditních důvodů."* Není to tedy žádný centrálně přidělovaný kód (ani totožný s číslem exekutorského úřadu u EK ČR, např. „184" pro Praha 9 — to byla jen naše hypotéza, zamítnuto) — je to libovolný string (max. 50 znaků dle XSD), který si BSP Technology sama zvolí jako identifikátor „pracoviště" v rámci vlastního systému, a CRV ho eviduje pro auditní účely. Žádné „vytvoření pracoviště" jako samostatná operace ve WSDL není — pracoviště vznikne implicitně prvním voláním `OsobaVytvoreni` s daným `PracovisteKod`. **Doporučení:** použít smysluplnou, stabilní hodnotu, např. IČO exekutorského úřadu (`72694041`) nebo vlastní interní kód BSP Technology pro daného klienta.
- **Postup `OsobaVytvoreni` → `PracovisteOsobaID` potvrzen jako správný** — **potvrzeno ICZ (e-mail 22. 9. 2026):** *„Ano, váš postup je správný."* Tedy: zavolat jednou `OsobaVytvoreni` (s vlastním zvoleným `PracovisteKod` a údaji o Danielovi), uložit vrácené `OsobaVytvoreniResult` a používat ho jako `PracovisteOsobaID` ve všech následujících `VyhledejICO`/`VyhledejRC` voláních.
- **`DotazDuvod`** (v `ZadatelInfoStructure`) — povinnost ověřena přímo (23. 9. 2026, viz kap. 9.1 bod P): musí být neprázdný, přesný formát/náležitosti obsahu zůstávají nepotvrzené (kap. 9.2).

**Shrnutí: nic už neblokuje první reálné volání.** Doporučený postup: (1) `Status()` — ověřit dostupnost; (2) `OsobaVytvoreni` s vlastním zvoleným `PracovisteKod` (např. IČO úřadu) — získat `PracovisteOsobaID`; (3) `VyhledejICO`/`VyhledejRC` s tímto `PracovisteOsobaID`.

#### 5.3.4 Provozní poznámky ze zdrojového dokumentu

- Provoz služby je monitorován správci CRV (Performance Counters, Microsoft Operations Manager) i uvnitř aplikace CRV (auditní log).
- Výkon lze na straně CRV upravit: snížením počtu záznamů na stránku (1–50), vypnutím jednotlivých metod, nebo vypnutím celé služby.
- Scénář přetížení: správci CRV zátěž zaznamenají a řeší dostupnými opatřeními, případně eskalují k zadavateli (tj. exekutorskému úřadu / jeho SW dodavateli) — PHP knihovna by proto měla počítat s možností dočasné nedostupnosti či omezení metod a implementovat odpovídající retry/backoff a srozumitelné logování chyby `SluzbaVypnuta`.

### 5.4 Provozní oznámení — výměna TLS certifikátů na koncových bodech (9/2026)

ICZ a.s. rozeslala (nevyžádaně, formou provozního oznámení) dvě avíza o plánované výměně TLS certifikátů na koncových bodech webových služeb RSV:

| Datum výměny | URL koncového bodu | Prostředí | Poznámka |
|---|---|---|---|
| **15. 9. 2026** | `crv-test.mdcr.cz` | testovací | Certifikát lze stáhnout z endpointu po výměně, nebo předem z odkazu v e-mailu ICZ |
| **15. 9. 2026** | `crv.mdcr.cz` | produkční | Totéž |
| **16. 9. 2026** | `mdcr.cms2.cz` | CMS2 (produkční i testovací) | Endpoint přístupný jen ze sítě CMS2 — netýká se přímé přístupové cesty BSP Technology (veřejný internet), viz kap. 5 |

**Významné potvrzení:** e-mail o výměně certifikátů na `crv-test.mdcr.cz` a `crv.mdcr.cz` **nezávisle potvrzuje správnost hypotézy o URL koncových bodů `ExekutorWS`** z kap. 9.2 (bod 1) — ICZ tyto dvě URL sama aktivně používá a spravuje jako testovací/produkční koncové body RSV webových služeb na veřejném internetu, tedy přesně tam, kam bude BSP Technology směřovat SOAP požadavky `ExekutorWS`.

**Praktický dopad pro BSP Technology:**
- Jde o výměnu **serverového** TLS certifikátu (identita endpointu CRV), nikoli o klientský certifikát BSP Technology/exekutora — této výměny se tedy netýká dřívější zjištění o nutnosti klientského certifikátu pro stažení WSDL (kap. 9.2, bod 1), to platí i nadále.
- Pokud PHP knihovna bude v budoucnu ověřovat serverový certifikát/CA napevno (certificate pinning) místo standardní validace přes důvěryhodné kořenové autority, je nutné po 15. 9. 2026 použít nový certifikát — **doporučujeme pinning nepoužívat** a spolehnout se na standardní ověření řetězu důvěry, právě kvůli podobným rotacím.
- Odkazy na stažení certifikátů (`https://share.iczgroup.com/...`) nebyly touto dokumentací staženy/otevřeny — pokud by bylo potřeba certifikát mít k dispozici (např. pro pinning, diagnostiku nebo test spojení), je možné je stáhnout na vyžádání.
- Drobná nesrovnalost oproti dřívějšímu zjištění v kap. 5: tam se uvádí, že CMS2 a veřejný internet sdílejí **stejnou URL** s odlišným DNS překladem podle sítě dotazujícího; toto oznámení ale uvádí pro CMS2 endpoint **jinou, vlastní doménu** (`mdcr.cms2.cz`) než pro veřejný internet (`crv.mdcr.cz`/`crv-test.mdcr.cz`). Možné vysvětlení: jde o interní/administrativní název endpointu, který ICZ používá ve vlastní evidenci, zatímco navenek (pro OVM v CMS2) může být přesto publikován pod stejnou doménou jako pro veřejný internet. Nemá vliv na přístupovou cestu BSP Technology, ponecháno jako drobná otevřená nejasnost.

---

## 6. Auditovatelnost a účel dotazu

Obě služby vyžadují u každého dotazu identifikaci žadatele a **důvod dotazu** (`DotazDuvod` u `QueryWS`, obdobně řešeno přes `ZadavatelInfo`/`PracovisteKod` u `ExekutorWS`) — tyto údaje se zapisují do auditních logů CRV. PHP knihovna by měla vynucovat, aby volající aplikace vždy předala smysluplný `PracovisteKod` a (u `QueryWS`) `DotazDuvod` (např. číslo jednací exekučního spisu), a měla by si sama vést lokální log odeslaných dotazů (kdo, kdy, jaký spis, jaký typ dotazu) pro účely doložení oprávněnosti přístupu.

---

## 7. Doporučení pro architekturu PHP knihovny

1. **Konfigurace prostředí** — knihovna by měla podporovat přepínání mezi testovacím (`crv-test.mdcr.cz`) a produkčním (`crv.mdcr.cz`) prostředím čistě změnou konfigurace (base URL, cesta k certifikátu, přihlašovací údaje), nikoli změnou kódu.
2. **Správa certifikátu** — načtení PostSignum certifikátu (pravděpodobně dodávaného jako `.p12`, viz analogická zkušenost s VZP/PostSignum) a jeho konverze do formátu potřebného pro podpis WS-Security hlaviček (PEM/klíč + certifikát zvlášť).
3. **SOAP vrstva — zjednodušeno (ověřeno 17. 9. 2026, kap. 4.4):** `ExekutorWS` nepoužívá WS-Security ani klientský certifikát, jen HTTP Basic Auth přes HTTPS — postačí tedy **nativní `SoapClient`** s `login`/`password`, žádná knihovna typu `robrichards/wse-php` není potřeba. (Otázka `SecCfg1`/`SecCfg2` bindingů se týkala jen referenčního `QueryWS`, kap. 4.2 — `ExekutorWS` má jen jeden, jednoduchý binding.) Zapouzdřit i tak do vlastního klienta kvůli logování, retry/backoff (kap. 5.3.3) a budoucí flexibilitě.
4. **Mapování chyb** — přemapovat `QueryFaultStructure`/`ExekutorFaultStructure` SOAP Fault na doménové výjimky PHP knihovny (např. `CrvMissingParameterException`, `CrvAmbiguousResultException`, `CrvServiceDisabledException` apod.), aby volající kód nemusel parsovat SOAP Fault ručně.
5. **Status-check** — helper metoda/health-check využívající operaci `Status` před dávkovým zpracováním, s možností zjistit, které konkrétní metody jsou aktuálně zapnuté.
6. **Auditní log** — každé volání logovat lokálně (typ dotazu, `PracovisteKod`, `DotazDuvod`/spisová značka, časová značka, výsledek/chyba) nezávisle na auditu na straně CRV.
7. **Retry/backoff** — u chyby `SluzbaVypnuta` a síťových/timeoutových chyb implementovat omezený počet opakování s odstupem, s explicitním logováním do aplikační vrstvy (ne tiché opakování).
8. **Validace vstupů před odesláním** — lokální validace formátu RZ/VIN (příp. RČ/IČO u `ExekutorWS`) předejde chybám typu `ChybiPovinnyParametr` / `ChybnyFormat` / `HodnotaMimoRozsah` a zbytečným voláním služby.
9. **Datum platnosti (`PlatnostKeDni`)** — výchozí hodnota "dnes", ale umožnit explicitní zadání pro historické dotazy.

---

## 8. Přehled zjištěných rozdílů oproti podkladům z projektu ČSSZ

Poznámka: aktuální relace neměla přímý přístup k dřívější dokumentaci z projektu ČSSZ (nebyla nalezena v tomto projektu ani v uložených poznámkách), dokument tedy strukturou vychází z obecné osvědčené praxe pro tento typ integrační dokumentace (kontext → proces připojení → bezpečnost → specifikace rozhraní → datové struktury → chybové stavy → doporučení pro implementaci → otevřené otázky). Pokud má být struktura sjednocena s konkrétní šablonou použitou u ČSSZ, prosím dodejte ji (soubor nebo odkaz) a dokument podle ní upravím.

---

## 9. Otevřené otázky

### 9.1 Vyřešeno (odpověď ICZ a.s., 2. 9. 2026)

| # | Otázka | Odpověď |
|---|---|---|
| A | Je `ExekutorWS`, nebo `QueryWS` služba pro exekutory? | **`ExekutorWS`** — `QueryWS` je pro obce/obecní policii. Viz kap. 5. |
| B | Existuje WSDL i pro `ExekutorWS`? | **Ano**, stažitelný z jejího koncového bodu (test i produkce). Viz kap. 5.3. |
| C | Může se SW dodavatel registrovat pod vlastním IČO? | **Ne**, vždy jen pod IČO konkrétního oprávněného subjektu (exekutorského úřadu). Viz kap. 3.2. |
| D | Který binding (`SecCfg1`/`SecCfg2`) použít u `QueryWS`? | Volba je na klientovi, CRV nepreferuje žádný. (Zjištěno pro `QueryWS` — u `ExekutorWS` ověřit proti jejímu vlastnímu WSDL, zda binding volby nabízí také.) |
| E | Jak řešit veřejnou IP adresu při SaaS/centralizovaném řešení? | Uvést skutečnou veřejnou IP adresu, ze které se bude dotazovat (tj. IP dodavatele/hostingu) — funguje to, byť výjimečně, přes veřejný internet. Přes CMS2 to možné není. Viz kap. 3.2. |
| F | Produkční URL `QueryWS`? | `https://crvt.mdcr.cz/services/QueryWS.svc` (pozn.: netýká se přímo `ExekutorWS`, jen pro referenci/analogii). |
| G | Jak v žádosti o připojení označit, že jde o **testovací** prostředí, když formulář pro to nemá kolonku? | **Potvrzeno ICZ (e-mail 2. 9. 2026):** uvést výslovně v **průvodním e-mailu** k žádosti. Po úspěšném otestování se podává **nová, samostatná žádost** o přístup do produkčního prostředí. Viz kap. 3. |
| H | Je nutné komerční certifikát exekutora (s BSP Technology jako pověřenou osobou) předem zaslat nebo zaregistrovat u CRV/ICZ? | **Odpověď ICZ (e-mail 2. 9. 2026):** „certifikát by neměl být potřeba." Interpretujeme jako: certifikát se nikam předem neposílá/neregistruje, ověřuje se automaticky v rámci WS-Security hlavičky u každého požadavku (viz kap. 4.1.2). Odpověď je stručná — doporučeno ověřit prakticky u prvního testovacího volání. |
| I | Ohrozí žádost o testovací prostředí (s jinou IP adresou) stávající produkční přístup pilotního úřadu? | **Potvrzeno ICZ (e-mail 9. 9. 2026):** **Ne.** Testovací a produkční prostředí jsou oddělená — loginy i povolené IP adresy se mohou lišit. Omezení je jen v rámci jednoho prostředí: subjekt v něm může mít nejvýše jednu IP adresu z internetu a jednu ze sítě CMS2 (CMS2 se exekutorů typicky netýká). Nová žádost o testovací přístup s IP adresou BSP Technology tedy nijak nekoliduje se stávajícím produkčním přístupem úřadu z jeho pražské IP. Viz i bod J. |
| J | Musí se po úspěšném otestování podávat úplně nová produkční žádost, i když úřad už produkční přístup má? | **Zjištěno ICZ (e-mail 9. 9. 2026):** Ne nutně — protože pilotní úřad **již produkční přístup má**, stačí k testování jen **login do testovacího prostředí**; po otestování lze **rovnou převést již existující produkční přístup** (přesný mechanismus „převodu" zatím nebyl upřesněn, viz 9.2 bod 3). |
| K | Přesná URL a cesta koncového bodu `ExekutorWS` (test)? | **Ověřeno přímo (17. 9. 2026):** `https://crv-test.mdcr.cz/qws/ExekutorWS.svc` — `curl -u 'jméno:heslo' ".../ExekutorWS.svc?wsdl"` vrátil HTTP 200 a kompletní WSDL. Produkční ekvivalent (`https://crv.mdcr.cz/qws/ExekutorWS.svc`) zůstává neotestovaný, ale dle stejného vzoru a potvrzení domény z kap. 5.4 vysoce pravděpodobný. |
| L | Jaký je skutečný bezpečnostní model `ExekutorWS` — certifikát/WS-Security, nebo jen Basic Auth? | **Potvrzeno přímo z WSDL (17. 9. 2026), viz kap. 4.4: jen HTTPS + HTTP Basic Authentication, žádný klientský certifikát, žádné WS-Security.** Tím se **vysvětluje i dřívější 403 chyba** ze 2. 9. 2026 (bod K výše) — nešlo o chybějící certifikát, ale o chybějící Basic Auth přihlašovací údaje, které tehdy BSP Technology ještě neměla. Zpřesňuje/nahrazuje výklad bodu H. |
| M | Musí být certifikát kvalifikovaný/komerční, na QSCD? (kap. 4.1.1, 9.2 dřívější body 5–7) | **Bezpředmětné pro `ExekutorWS`** — viz bod L: žádný certifikát se nepoužívá vůbec, takže volba typu certifikátu, formátu (`.p12`/PEM) ani QSCD požadavek pro tuto službu nikdy nenastanou. |
| N | Odkud se bere `PracovisteKod`? Je to oficiální číslo exekutorského úřadu vedené u EK ČR? | **Potvrzeno ICZ (e-mail 22. 9. 2026):** *„Pracoviště a osoby si vytváříte sami. Ministerstvo je vyžaduje z auditních důvodů."* Není to centrálně přidělovaný kód — BSP Technology si ho **volí sama** (libovolný string, viz kap. 5.3.3). Hypotéza, že jde o číslo úřadu u EK ČR (184 pro Praha 9), se nepotvrdila jako nutnost — lze ho tak ale klidně použít jako vlastní volbu. |
| O | Je postup „zavolat jednou `OsobaVytvoreni`, výsledné ID použít jako `PracovisteOsobaID`" správný? | **Potvrzeno ICZ (e-mail 22. 9. 2026):** *„Ano, váš postup je správný."* Viz kap. 5.3.3. |
| P | Je pole `DotazDuvod` v `ZadatelInfo` skutečně povinné, i když ho XSD označuje jako nullable? | **Ověřeno přímo živým voláním (23. 9. 2026):** Ano — `VyhledejRC` s prázdným `DotazDuvod` vrátilo chybu `ChybiPovinnyParametr` na `ZadatelInfo.DotazDuvod`. XSD „nullable" tedy neznamená, že prázdná hodnota projde byznys validací. Viz kap. 5.3.1. |
| Q | Nese element `Kod` v `ExekutorFaultStructure` číslo, nebo textový název hodnoty výčtu? | **Ověřeno přímo živou chybou (23. 9. 2026):** textový název (např. `"ChybiPovinnyParametr"`), ne číslo uvedené v tabulce kap. 5.3.2 — to číslo je jen pořadí ve výčtu dle XSD anotace. Viz oprava v kap. 5.3.2. |
| R | Existují pro testovací prostředí vzorová RČ, na kterých lze ověřit kladnou odpověď? | **Poskytnuto ICZ (e-mail 23. 9. 2026):** ano, tři testovací RČ: `6805037985`, `530819374`, `495805912`. K vyzkoušení přes `VyhledejRC`. |
| S | Od kolika je číslovaná `Strana` u `VyhledejICO`/`VyhledejRC` — od 0, nebo od 1? | **Ověřeno živým testem (24. 9. 2026):** **od 0.** `Strana=1` u subjektu s méně vozidly, než je `NaStranu`, vrátí prázdný (ale úspěšný) výsledek, protože jde o druhou stránku, ne první. Potvrzeno na třech RČ, u kterých ICZ potvrdila aktivní vozidla. Viz kap. 5.3.1. Vysvětluje to zpětně i body 5 a 6 v kap. 9.2 (viz „Vyřešeno" níže). |

### 9.2 Stále otevřeno

1. ~~**Přesný formát/náležitosti obsahu pole `DotazDuvod`**~~ — **vyřešeno (24. 9. 2026):** je to volný text (vyzkoušeno živě, např. `"Lustrace majetku dlužníka - test"` bez problémů přijato) — žádný pevný formát (číslo jednací, min. délka apod.) není vyžadován, jen nesmí být prázdný (kap. 9.1 bod P).
2. **Forma a náležitosti plné moci**, pokud by BSP Technology chtěla podávat/spravovat žádost jménem exekutorského úřadu — dle ICZ nutno řešit přímo s **Ministerstvem dopravy ČR** (ne s ICZ/CRV Help Deskem).
3. **Přesný mechanismus „převodu" stávajícího produkčního přístupu pilotního úřadu na BSP Technology** — ICZ potvrdila (bod J v 9.1), že po otestování lze existující produkční přístup úřadu „rovnou převést", ale neupřesnila jak. Doporučeno doptat se ICZ konkrétně, až se bude blížit fáze přechodu do produkce (viz kap. 10, bod 7).
4. **Co skutečně vyvolá `ChybnyFormat` u `VyhledejRC`/`VyhledejICO`** — živý test s krátkým RČ (`"760"`) vrátil místo toho `Nenalezeno` (viz kap. 5.3.2), takže hranice mezi oběma chybami není jasná. Nepotvrzeno, zda `ChybnyFormat` u `ExekutorWS` vůbec nastává, nebo jen za jiných podmínek (např. nečíselné znaky).
5. ~~**Kdy CRV vrátí `Nenalezeno` (chyba) a kdy prázdný, ale úspěšný `VyhledejRCResult`/`VyhledejICOResult`**~~ — **vysvětleno (24. 9. 2026, viz kap. 9.1 bod S):** `Nenalezeno` = identita vůbec neexistuje; prázdný úspěšný výsledek = identita existuje, ale dotázaná stránka (`Strana`) je mimo rozsah — typicky proto, že šlo o `Strana=1` (druhá stránka), zatímco data byla na `Strana=0` (první). Zbývá jen teoretická možnost, že existuje i „identita existuje, ale opravdu nemá žádné vozidlo" jako třetí, od tohohle nerozlišitelný případ — nepotvrzeno, ale pro praxi už nedůležité, protože knihovna teď posílá `Strana=0` správně.
6. ~~**Zda testovací prostředí `ExekutorWS` pracuje s ostrými daty registru vozidel**~~ — **vyřešeno (24. 9. 2026):** ano, pracuje. `VyhledejICO("93925107", ...)` se správným `Strana=0` vrátilo reálná data (20 konkrétních vozidel na první stránce — VIN, RZ, barva, výrobce, majitel „ServisAbc" s adresou), ne jen testovací/syntetická data. Předchozí dojem, že testovací RČ od ICZ vrací prázdno, byl způsoben naší chybou (`Strana=1` místo `0`, viz bod S v kap. 9.1), ne chybějícími daty.
7. ~~**Existuje hromadný/dávkový dotaz na více subjektů (např. 100 RČ/IČO) v jednom volání?**~~ — **vyřešeno (ICZ, e-mail 25. 9. 2026, David Borovička):** ne, dávkové operace nejsou k dispozici — potvrzeno, že `VyhledejICO`/`VyhledejRC` umí jen jeden subjekt na volání. Jednotlivé dotazy za sebou jsou v pořádku, ale platí přísný **rate limit: max. 5 dotazů za minutu a zároveň min. 2000 ms mezi jednotlivými dotazy** — při překročení vrací služba chybu. **Důsledek pro PHP implementaci:** klient musí mezi voláními `VyhledejICO`/`VyhledejRC` vynucovat prodlevu ≥ 2 s (např. `usleep`/frontou s limitem) a nesmí posílat víc než 5 dotazů/min ani paralelně z více vláken/procesů současně — jinak hrozí zablokování. Dotaz na 100 subjektů tak sekvenčně zabere cca 3,5 minuty (100 × 2 s). Viz doporučení pro architekturu, kap. 7.

---

## 10. Aktuální stav a další kroky

**Milník (2. 9. 2026):** BSP Technology má dohodnutého reálného spolupracujícího exekutorský úřad ochotný vystupovat jako pilotní žadatel/klient (varianta „a) Pilotní klient" z kap. 3.2). Tím je zásadní organizační překážka z kap. 3.2/9 vyřešena.

**Milník (17. 9. 2026):** Žádost o testovací prostředí byla podána a **CRV přidělila přístupové údaje do testovacího prostředí** — uživatelské jméno e-mailem a heslo SMS (dle kroku 4 v kap. 3). **Téhož dne se podařilo úspěšně stáhnout reálný WSDL `ExekutorWS`** (`curl -u jméno:heslo https://crv-test.mdcr.cz/qws/ExekutorWS.svc?wsdl` → HTTP 200) a potvrdit, že bezpečnostní model je jen HTTP Basic Auth — **žádný certifikát není pro tuto službu vůbec potřeba** (viz kap. 4.4). Kroky 1 a 4 postupu níže jsou hotové; krok 2 (certifikát) odpadá jako nepotřebný; krok 5 (datové struktury) hotov (kap. 5.3).

**Milník (23. 9. 2026):** **První reálné SOAP volání proběhlo úspěšně** — celý řetězec (Basic Auth, vlastní zvolený `PracovisteKod`, `OsobaVytvoreni` → `PracovisteOsobaID`, kap. 5.3.3) funguje. Při ladění se přímo v kódu potvrdily dvě další věci (viz kap. 9.1 body P, Q): pole `DotazDuvod` je prakticky povinné (prázdné vrací `ChybiPovinnyParametr`), a chybový element `Kod` nese textový název hodnoty výčtu, ne číslo. Dotaz `VyhledejICO` na IČO pilotního exekutorského úřadu (72694041) vrátil `ExekutorFaultKod.Nenalezeno` — tedy ne chybu spojení/autentizace, ale platnou odpověď „nic nenalezeno". **Testovací prostředí zjevně obsahuje vlastní syntetická/testovací data, ne kopii produkčních dat.** ICZ na dotaz (23. 9. 2026) obratem poskytla tři funkční testovací RČ (viz kap. 9.1, bod R): `6805037985`, `530819374`, `495805912`. **Všechna tři byla vyzkoušena** — u všech vrátil `VyhledejRC` úspěšnou, ale prázdnou odpověď (žádná chyba, ale `VyhledejRCResult` bez jakékoli `VozidloStructure`) — jde tedy patrně o platné/existující identity bez přiřazeného vozidla. Odhalilo to zároveň druhý způsob, jakým CRV signalizuje „nic k zobrazení" (viz kap. 5.3.1, 9.2 bod 5). Žádné z těchto RČ zatím neumožnilo ověřit plně obsazenou `VozidloStructure` — další krok byl vyžádat si od ICZ RČ/IČO s alespoň jedním evidovaným vozidlem (kap. 9.2, bod 6, k tomuto datu vyřešeno — viz milník níže).

**Milník (24. 9. 2026):** **Objevena a opravena chyba v číslování stránek** — `Strana` se čísluje od 0, ne od 1 (kap. 9.1, bod S). Testovací RČ z 23. 9. 2026 se jevila jako „bez vozidla" jen proto, že dotazy chybně používaly `Strana=1`. Po opravě na `Strana=0` vrátil `VyhledejICO` na IČO `93925107` reálná data — 20 konkrétních vozidel (VIN, RZ, barva, výrobce, majitel) — čímž se potvrdilo, že **testovací prostředí pracuje s ostrými, ne syntetickými daty** (kap. 9.2, bod 6, vyřešeno). Zároveň se živě ověřilo, že pole `DotazDuvod` přijímá libovolný volný text bez pevného formátu (kap. 9.2, bod 1, vyřešeno). Tím jsou vyřešeny všechny dosud otevřené otázky kolem chování `VyhledejICO`/`VyhledejRC` — zbývají už jen organizační otázky v kap. 9.2 (body 2–4).

### 10.1 Identifikace pilotního exekutorského úřadu

Údaje ověřeny 8. 9. 2026 v registru ARES (ROS/RES, primární zdroj) dle IČO **72694041**:

| Položka | Hodnota |
|---|---|
| Obchodní jméno | **Svoboda Ondřej, Mgr. — soudní exekutor** |
| IČO | 72694041 |
| DIČ | CZ8211131126 (plátce DPH) |
| Právní forma | Fyzická osoba podnikající dle jiných zákonů (kód 105) — soudní exekutor |
| Sídlo | Beranových 130, Letňany, 199 00 Praha 9 |
| Datum vzniku (zápisu do ROS) | 15. 11. 2002 |
| Obor činnosti (CZ-NACE) | 69100 (právní činnosti), 56110 a 80010/800 — vedlejší záznamy v RZP, hlavní činností je funkce soudního exekutora |
| Stav v registrech | ROS aktivní, RES aktivní, RZP aktivní, DPH aktivní; ve veřejném rejstříku (VR) nezapsán (u fyzické osoby — exekutora obvyklé) |

Poznámka: ARES eviduje u tohoto IČO i starší/vedlejší záznam ze živnostenského rejstříku pod jménem „Mgr. Ondřej Svoboda" se sídlem č.p. 120, 470 02 Stružnice (okres Česká Lípa) — jde o dřívější/doplňkovou adresu vázanou na registraci v RZP, nikoli o aktuální sídlo exekutorského úřadu; pro žádost o připojení k CRV a veškerou komunikaci je rozhodující primární záznam ROS/RES uvedený výše (Beranových 130, Praha 9).

Tyto údaje (obchodní jméno, IČO, DIČ, sídlo) budou potřeba přímo do formuláře `Žádost_o_připojení_exekutorské_kanceláře.pdf` (kap. 3) a do zpracovatelské smlouvy (DPA) s úřadem (kap. 10, bod 3).

Doporučený další postup:

1. **Podání žádosti o testovací prostředí** (kap. 3, formulář `Žádost_o_připojení_exekutorské_kanceláře.pdf`) — podá **exekutorský úřad pod svým IČO a jménem** na `servicedesk@crv-md.cz` (kopie `webove_sluzby_rsv@i.cz`), s výslovným požadavkem na **testovací** prostředí. Jako „veřejnou IP adresu úřadu" lze dle potvrzení ICZ (kap. 9.1, bod E) uvést skutečnou veřejnou IP adresu, ze které bude BSP Technology dotazy reálně odesílat (tj. IP hostingu/infrastruktury BSP Technology). **Potvrzeno ICZ (kap. 9.1, bod I):** testovací a produkční prostředí mají oddělené IP adresy/loginy, takže tím nehrozí ovlivnění stávajícího produkčního přístupu úřadu z jeho pražské IP.
2. **Certifikát PostSignum** — zjistit, zda úřad již disponuje systémovým certifikátem (kvalifikovaná elektronická značka); pokud ne, zahájit žádost o něj co nejdřív souběžně s bodem 1 — vyřízení certifikátu bývá časově náročné (viz i vlastní zkušenost s obdobným procesem u jiného projektu). Zároveň je třeba domluvit s úřadem, jak bude privátní klíč certifikátu bezpečně předán/nasazen do infrastruktury, kde poběží software BSP Technology.
3. **Zpracovatelská smlouva (DPA) mezi BSP Technology a exekutorským úřadem** — osobní údaje z CRV (RČ, adresy, vlastníci vozidel) budou procházet systémem BSP Technology; úřad se v žádosti o připojení zavazuje k mlčenlivosti a ochraně dat (kap. 2). Doporučeno formalizovat vztah smlouvou o zpracování osobních údajů dle čl. 28 GDPR, aby byl závazek úřadu vůči CRV pokrytý i navazujícím vztahem s dodavatelem.
4. **Po obdržení přístupových údajů** (uživatelské jméno + SMS heslo, kap. 3 bod 4) zkusit znovu stáhnout WSDL `ExekutorWS` z testovacího koncového bodu — nyní už s klientským certifikátem (viz kap. 9.2, bod 1 — bez certifikátu vracel endpoint 403).
5. **Ověřit/doplnit** datové struktury a operace v kap. 5.3 proti reálnému WSDL, opravit případné rozdíly oproti textovému PDF popisu v1.2.
6. **Otestovat SOAP komunikaci** (`Status`, `VyhledejICO`, `VyhledejRC`) proti testovacímu prostředí.
7. **Po úspěšném testu přejít do produkce.** Protože pilotní úřad **již produkční přístup má**, dle ICZ (kap. 9.1, bod J) postačí existující produkční přístup „rovnou převést" — přesný mechanismus převodu (zda stačí jen doplnit/upravit IP adresu a certifikát u stávající registrace, nebo je i tak potřeba nějaká forma žádosti/oznámení) je ale ještě potřeba upřesnit s ICZ (viz kap. 9.2, bod 8), než se k tomuto kroku dojde.

Mohu podle potřeby připravit: (a) návrh vyplněné žádosti o připojení pro exekutorský úřad k podpisu, (b) osnovu zpracovatelské smlouvy mezi BSP Technology a úřadem, nebo (c) navazující e-mail/dotaz na ICZ ohledně WSDL/URL pro `ExekutorWS`, jakmile budou k dispozici další konkrétní údaje (název úřadu, IČO, kontaktní osoba).

---

## 11. Přílohy — zdrojové podklady

- `QueryWS.XML` — WSDL definice služby QueryWS (referenční, není určena pro exekutory — viz kap. 5)
- `Žádost_o_připojení_exekutorské_kanceláře.pdf`
- `Proces_pripojeni_exekutorske_kancelare_vuci_IS_CRV.PDF`
- `CRV_Vydej_dat_Exekutor_Query_WS_v.1_2.pdf`
- `crv.png` — ceník PostSignum
- https://ekcr.cz/exekutor/centralni_registr_vozidel (staženo 2. 9. 2026)
- E-mailová odpověď ICZ a.s. (David Borovička) na dotaz BSP Technology s.r.o., přijato 2. 9. 2026 z `webove_sluzby_rsv@i.cz`