# Portál ZP – komunikace exekutora s komunikační branou (test/pilotní prostředí) Zdroje: https://www.portalzp.cz/clanky/komunikacni-brana-pro-klienty, https://www.portalzp.cz/distribuce.ext/AktualniStav.html, https://www.portalzp.cz/casto-kladene-otazky (C1), dokumenty z https://www.portalzp.cz/distribuce.ext/PZP-kom_brana_klient/prilohy/, e-mailová komunikace s V. Benešem (Asseco CE), web ica.cz. Kontakt na Asseco CE (správce Portálu ZP): technické dotazy – vladimir.benes@asseco-ce.com; obchodní dotazy – tomas.butor@asseco-ce.com. ## Stav žádosti (aktuální) - Registrace v pilotním prostředí dokončena, **přiděleno ID klienta: 107655**. - Odesláno Benešovi: žádost o nastavení oprávnění na ID 107655. - Potvrzeno Benešovi: bude se používat výhradně **hromadné dotazování ve Společné zóně napříč pojišťovnami** (ne dotazování zvlášť na jednotlivé brány ZP) – v souladu s jeho doporučením. - Benešovi odeslána i žádost o konkrétní testovací rodné číslo/IČO pro pozitivní nález – **odpověď obdržena** (e-mail 31.8.2026, viz bod 8 níže): dal konkrétní seznam FO/PO existujících v pilotním registru, ale zároveň zásadní upřesnění – **v pilotu se dotazy na straně ZP vůbec nezpracovávají**, takže reálná (pozitivní) odpověď od ZP nikdy nepřijde; místo toho popsal postup, jak si pozitivní odpověď nasimulovat ručně (viz bod 8). Explicitní potvrzení "oprávnění bylo nastaveno" v e-mailu není, ale Beneš už dává přímé pokyny k přihlášení do obou zón – oprávnění tedy zřejmě funkční, nutno ověřit přímým přihlášením. - Žádný veřejně publikovaný seznam fiktivních testovacích subjektů (rodná čísla/IČO) pro pilot neexistuje. Ověřeno v manuálu, AktualniStav.html, demo klientovi a vyčerpávajícím prohledáním FAQ (https://www.portalzp.cz/casto-kladene-otazky, sekce A–E, včetně skrytého obsahu všech rozklikávacích odpovědí) – jediná cesta byla přímý dotaz na Beneše, což se potvrdilo. ## 0. Certifikát pro pilotní/testovací prostředí Portál ZP (dle FAQ C1) podporuje komerční i kvalifikované certifikáty od těchto CA: **I. CA**, **Česká pošta / PostSignum**, **eIdentity**, **NCA**. PostSignum má samostatné odkazy pro kvalifikovaný (qca.postsignum.cz) i komerční (vca.postsignum.cz) certifikát – komerční PostSignum certifikát je tedy oficiálně podporovaný typ. Pilotní prostředí (AktualniStav.html) akceptuje **certifikáty certifikačních autorit zmíněných v otázce C1** (tzn. včetně PostSignum) a navíc i speciální testovací certifikáty I.CA. **› Pokud už má uživatel vlastní reálný komerční certifikát od PostSignum, může ho rovnou použít i pro registraci a přihlášení do pilotního prostředí** (https://pilot-brn-pzp.asseco.cz/registrace/#/, přihlašování certifikátem) – není nutné si zvlášť pořizovat testovací certifikát od I.CA. Pokud by přesto byl potřeba čistě testovací (ne ostrý) certifikát od I.CA: na webu ica.cz není samoobslužné stažení/objednávka – veřejně jsou ke stažení jen kořenové testovací CA certifikáty (https://www.ica.cz/testovaci-korenove-certifikaty, trust anchor, ne cert osoby/firmy). Konkrétní testovací komerční certifikát se získává na vyžádání, typicky e-mailem na podporu I.CA (podpora@ica.cz, +420 284 081 930) s odkazem na účel – test napojení na Portál ZP. **Pro přihlašování do zóny ZP i do společné zóny pilotu se používá stále stejný certifikát** (potvrzeno Benešem). ## 1. Registrace do testovacího (pilotního) prostředí - Registrační formulář: **https://pilot-brn-pzp.asseco.cz/registrace/#/** › volba "Nový klient" (5 kroků: Způsob přihlašování › Kontaktní údaje › Požadovaná oprávnění › Shrnutí › Odeslání registrace a žádosti o oprávnění). - Pro exekutora je nutné zvolit **přihlašování certifikátem** (ne SMS) – žádost exekutora o součinnost lze dle dokumentace použít jen s certifikátem, aktivace SMS je pro tento účel zbytečná. - Stačí certifikát od jedné z podporovaných CA (viz bod 0) – reálný komerční PostSignum certifikát funguje i v pilotu, případně testovací certifikát ICA. - V kroku "Požadovaná oprávnění" je nutné požádat aspoň o jedno oprávnění. Pro exekutora: zvolit oprávnění na **"externí instituci"** (v pilotu nejsou kompletní seznamy PZS/zaměstnavatelů, takže žádost přes IČO exekutora by nemusela projít) – jako IČO lze zadat libovolné, i nesmyslné. - Po odeslání registrace je nutné **ozvat se Beněšovi** (vladimir.benes@asseco-ce.com), aby ručně nastavil (schválil) přístupová práva – automaticky se nepřidělí. **(Hotovo – viz "Stav žádosti" výše, ID klienta 107655.)** - Po zřízení konta se lze přihlásit do pilotu; aktivace SMS přihlašování (Nastavení konta) není pro exekutorský use-case potřeba. - Certifikáty a privátní klíč (pfx) je třeba převést např. přes `openssl pkcs12 -in vstup.pfx -nodes -out vystup.pem`. ## 2. URL komunikačních bran a přihlašovacích zón Produkční brány (per ZP): - ČPZP: https://portal.cpzp.cz/kom_brana.phtml - OZP: https://portal.ozp.cz/kom_brana.phtml - RBP: https://portal.rbp-zp.cz/kom_brana.phtml - VoZP ČR: https://portal.vozp.cz/kom_brana.phtml - ZPŠ: https://portal.zpskoda.cz/kom_brana.phtml - Společná zóna (napříč pojišťovnami): https://b2b.portalzp.cz/kom_brana.phtml (pův. www.portalzp.cz/kom_brana.phtml se ruší) Pilotní (testovací) brány a webová přihlášení: - Brána ZP zóny pilotu: https://pilot-pzp.asseco.cz/kom_brana.phtml; webové přihlášení do ZP zóny: **https://pilot-pzp.asseco.cz/app/prihlaseni** - Brána společné zóny pilotu: https://pilot-brn-pzp.asseco.cz/kom_brana.phtml; webové přihlášení do společné zóny: **https://pilot-brn-pzp.asseco.cz/app/prihlaseni** - DTD pilotu: http://pilot-brn-pzp.asseco.cz/portal_kl.dtd Podpisové certifikáty brány jsou vždy na `https://[hostname portálu]/portal_sign.pem` (např. https://pilot-brn-pzp.asseco.cz/portal_sign.pem) – klient si odtud může stáhnout cert pro ověření podpisu odpovědi. **Exekutor komunikuje přes bránu Společné zóny** (jeden dotaz jde naráz na všechny zúčastněné ZP), ne přes jednotlivé brány ZP. Potvrzeno i v komunikaci s Benešem – bude se používat výhradně tento hromadný způsob. Ve webovém rozhraní společné zóny (https://pilot-brn-pzp.asseco.cz/app/prihlaseni) je i **menu pro exekutory** – přehled zaslaných dotazů a odpovědí (jak od portálu, tak od ZP) – užitečné pro ruční kontrolu vedle vlastní API komunikace. ## 3. Obecný obálkový formát (DTD `portal_kl.dtd`, popsáno i v P4ZP_PHP-APP_KOM_TR06) ```xml ``` Pro exekutora relevantní `Ucel`: **EXE_FO** (dotaz/odpověď na fyzické osoby), **EXE_PO** (dotaz/odpověď na právnické osoby), **SCHRANKA** (čtení zpráv ve schránkách). Autentizace/autorizace = jedna z variant `Podpis` (elektronický podpis certifikátem – u exekutora povinná varianta), `Sms-request`/`Sms-auth` (SMS, pro exekutora nepoužitelné). `Prihlaseni.UnikatniInfo` – libovolný unikátní údaj vůči certifikátu (např. datum+čas, pořadové číslo) sloužící proti replay útoku. Element `Prihlaseni` obsahuje "přihlašovací text" dle ČSN ETSI TS 101 456, např.: "Tímto se přihlašuji k Portálu \. V rámci tohoto přihlášení předávám podání \ v definovaném datovém rozhraní. Po předání tohoto podání a příjmu odpovědi Portálu \ se z Portálu \ odhlašuji." `Data.PZP_Chyba` v odpovědi: 0 = podání zpracováno OK, jiná hodnota = kód chyby. `Data.PZP_IdPodani` = číslo podání přidělené portálem. ### 3a. Kódování obsahu souboru (`Soubor.Format`) – potvrzeno, PHP třída musí řešit všechny 4 varianty Ověřeno přímo v `KOM_TR06` (obecný model tříd obálky). `TypSoubor` (atribut `Format` elementu `Soubor`) má 4 možné hodnoty: - `TEXT` – prostý text, jen HTML-enkódovaný (`<`, `>`, `&`, `'`, ...) - `BASE64` – celý obsah souboru v kódování BASE64 - `ZIP_BASE64` – obsah nejdřív zazipovaný (ZIP), pak base64 - `GZIP_BASE64` – obsah nejdřív zgzipovaný (GZIP), pak base64 Doslovná citace z dokumentace: *"Slouží jen pro správné rozkódování obsahu dat; nemá vliv na vlastní úlohu. V rámci dané úlohy lze tedy použít libovolné kódování vlastních dat souboru."* – tzn. **odesílatel (i ZP, když posílá `exe_fo_XXX_YYY.xml`/`exe_po_XXX_YYY.xml`) si smí zvolit kterýkoli ze 4 způsobů kódování zcela libovolně, nezávisle na typu úlohy.** **Důsledek pro PHP třídu:** při parsování libovolné přijaté odpovědi (EXE_FO/EXE_PO i SCHRANKA/ZPRAVA.XML) se NESMÍ předpokládat konkrétní formát – vždy je nutné přečíst atribut `Format` daného `` elementu a podle něj větvit dekódování (HTML-decode / `base64_decode` / `base64_decode`+unzip / `base64_decode`+gunzip), teprve poté parsovat vnitřní XML (`exe_fo_XXX_YYY.xml` atd.). **Uvnitř samotných dat FO/PO (`OdpovedFO`/`OdpovedPO`) žádné base64 není** – ověřeno prohledáním celého `EXE_P01.doc` (žádný výskyt "BASE64"). Všechna pole (rodné číslo, jméno, adresa, `TypPoj`, číslo účtu, IČO zaměstnavatele...) jsou přímo čitelné textové hodnoty v XML. Base64/zip se týká výhradně vnější obálky (`Soubor.Format`), ne jednotlivých polí uvnitř. ## 4. Dotaz exekutora – fyzické osoby (soubor `exe_fo_dotaz.xml`) DTD: http://b2b.portalzp.cz/exe_fo_dotaz.dtd, kódování ISO-8859-2. Pošle se **najednou dotaz na libovolné množství fyzických osob** (ne po jedné) – přesně dle apelu V. Beneše. Kořen: `SchrankaZadost NazevSchranky="SCHR_SEI_EU_FO" NazevFiltru="FRM_SEI_EU_FO" Verze="3"` - `Verze="3"` je od 25.6.2013/1.1.2015 povinná: jiné znění prohlášení a **zákaz jakýchkoli příloh**. - Obsahuje N × `SkupinaPolozek Nazev="SEI_EU_FO_SKUPINA" Poradi="n"` (unikátní pořadí), pod ním `PolozkaFiltru`: - `Nazev="FO_CPOJ"` – rodné číslo (povinné, celé kladné číslo) - `Nazev="FO_PROHLASENI"` – povinné prohlášení přesně v předepsaném znění (kódování ISO-8859-2), pro exekutora: „Prohlašuji, že o součinnost žádám pro účely exekučního řízení." - (u Verze < 3 by šlo přikládat i scan `FO_SCAN` jako přílohu, ale pro exekutora od Verze 3 přílohy zakázány) Protokol o přijetí (okamžitě): portál pro každou zúčastněnou ZP zkontroluje, zda je FO jejím pojištěncem; u neznámé FO na dané ZP odpoví portál rovnou v protokolu (`Pojistenec="NE"`), u nalezené (`Pojistenec="ANO"`) čeká se na skutečnou odpověď ZP. Odpověď ZP (soubor `exe_fo_XXX_YYY.xml`, XXX=kód ZP, YYY=číslo podání): http://b2b.portalzp.cz/exe_fo_odpoved.dtd, ISO-8859-2 (samotný obsah – nezávisle na tom, jak je `Soubor` zabalený, viz 3a). Element `OdpovedFO` obsahuje kontakt na vyřizujícího pracovníka ZP (jméno, telefon, e-mail), a pro každou FO (`Poradi`, `SpisZnackaEXE`, `CPoj`=rodné číslo, jméno/příjmení, adresy, `TypPoj` (typ pojištění – zaměstnanec/OSVČ/student/důchodce/… s adresou zaměstnavatele), `Info`. ## 5. Dotaz exekutora – právnické osoby (soubor `exe_po_dotaz.xml`) Stejný princip, DTD/URL obdobné (http://b2b.portalzp.cz/exe_po_odpoved.dtd pro odpověď). Kořen `SchrankaZadost NazevSchranky="SCHR_SEI_EU_PO" NazevFiltru="FRM_SEI_EU_PO"`. `PolozkaFiltru`: `PO_ICO` (povinné), `PO_NAZEV`, `PO_ULICE`, `PO_OBEC`, `PO_PSC`, `PO_IDENT_CIS` (spisová značka), `PO_SCAN`, `PO_PROHLASENI` (obdobné prohlášení jako u FO, pro exekutora stejné znění). Odpověď obsahuje `Zamestnavatel="ANO/NE"` (zda PO figuruje v registru zaměstnavatelů dané ZP), případně bankovní účet, adresy. **Dotaz na PO i FO se posílá jednou žádostí na všechny zúčastněné ZP najednou** – ZP se v XML nespecifikuje, portál dotaz rozešle interně. ## 6. Čtení odpovědí / práce se schránkami (SCHRANKA) Popsáno v `P4ZP-PHP_APP_SCH_P01.doc`. V rámci jedné komunikace lze poslat i více příkazů naráz (počet neomezen), lze kombinovat různé druhy příkazů. Pokud je jeden příkaz neplatný, je odmítnuto vše. - **Přehled schránek**: vstup prázdný soubor `SCHRANKY.XML`, výstup přehled dostupných schránek (název, popis, `celkem`, `nove` = počet nepřečtených). - **Stažení zpráv ze schránky**: vstup `pouze_nove="ANO/NE"`, výstup `ZPRAVY.XML` se seznamem zpráv (`id`, `datum`, `nova`) + přílohy. **Lze stáhnout všechny nepřečtené zprávy naráz** (přesně dle apelu V. Beneše). - **Detail jedné zprávy**: výstup `ZPRAVA.XML` (`popis`, `poznamka`, `podani_id`, přílohy s `jmeno`/`typ`, kódování obsahu TEXT/BASE64/ZIP_BASE64 – stejná 4-hodnotová `Format` logika jako v bodě 3a). - **Označení zprávy přečtenou**: `ZPRAVA_PRECTI.XML` (vstup `zprava id="..."`) › prázdný výstup. - **Smazání zprávy**: `ZPRAVA_SMAZ.XML` (vstup `zprava id="..."`) › prázdný výstup. Lze smazat jen vlastní zprávy klienta. Relevantní schránky pro exekutora ve Společné zóně Portálu ZP (ostrý provoz): - `SCHR_PZP_EU_FO` – Exekutorský úřad, fyzické osoby - `SCHR_PZP_EU_PO` – Exekutorský úřad, právnické osoby Zvláštní schránka pro self-test v pilotu (viz bod 8): `_KL2KL_KLIENT` (na bráně ZP zóny, ne společné zóny). ### 6a. Asynchronní charakter a životní cyklus zpráv **Ano, jde o asynchronní/mailbox model, ne request-response.** Podání EXE_FO/EXE_PO dostane hned jen "Protokol o úspěšném příjmu dotazu" (potvrzení přijetí + okamžitá kontrola, zda je osoba u dané ZP vůbec vedena). Skutečnou věcnou odpověď generuje ZP později a doručí ji do schránky klienta – vyzvednout ji je nutné samostatným dotazem `Ucel="SCHRANKA"`. Je to tedy fire-and-forget podání + následný polling schránky, ne jedno synchronní volání. **Ano, staré (přečtené) zprávy ve schránce zůstávají, dokud je klient sám nesmaže.** Detaily: - `pouze_nove="ANO"` vrací jen nepřečtené, `pouze_nove="NE"` vrací úplně všechny (přečtené i nepřečtené). - Každá zpráva má atribut `nova="ANO/NE"` – to je jen stav přečtení, samo o sobě nic nemaže. - Přehled schránek vrací zvlášť `celkem` (všechny zprávy) a `nove` (jen nepřečtené) – `celkem` tedy roste, pokud se nic nemaže. - `ZPRAVA_PRECTI.XML` zprávu jen označí jako přečtenou (`nova="NE"`), fyzicky ji ponechá ve schránce. - **Mazání je samostatný příkaz** `ZPRAVA_SMAZ.XML` (``) – dokumentace výslovně: "Nezávisí na tom, zda byla stažena a zda již byla jako označena přečtená. Klient takto může smazat jen své zprávy." Tzn. lze smazat kdykoli, i nepřečtenou, i už staženou. **Důsledek pro PHP třídu:** po zpracování/uložení odpovědi je vhodné rovnou zavolat `ZPRAVA_SMAZ.XML` na její `id`, jinak schránka poroste bez omezení. ## 7. K dispozici pro implementaci - Kompletní dokumentace (zip): https://www.portalzp.cz/distribuce.ext/PZP-kom_brana_klient.zip - Klíčové dokumenty (adresář .../PZP-kom_brana_klient/prilohy/): - `P4ZP-PHP_APP_EXE_P01.doc` – datové rozhraní podání exekutora (dotaz+odpověď, FO i PO) - `P4ZP-PHP_APP_SCH_P01.doc` – datové rozhraní schránek (čtení/mazání zpráv) - `P4ZP_PHP-APP_KOM_TR06_P01.DOC` – obecný model tříd/obálky komunikace (vč. `Soubor.Format`, viz 3a) - `portal_kl.dtd` – DTD obálky `Komunikace` - Existuje hotová DLL knihovna pro zjednodušení komunikace: `PortalZP_*_pack.zip` (nativní) a `PortalZPCsNet_*_pack.zip` (.NET) – ale pro PHP třídu budeme implementovat XML/HTTP komunikaci dle DTD/dokumentace výše napřímo. - Testovací formulář pro ruční odeslání XML výzvy do pilotu: https://www.portalzp.cz/distribuce.ext/klient_brn-pilot.html - `exe_fo_odpoved.dtd`/`exe_fo_dotaz.dtd` na `b2b.portalzp.cz` nejsou veřejně stažitelné bez klientského certifikátu (produkční brána) – definice polí čerpat z `EXE_P01.doc` (viz body 4–5). ## 8. Testování v pilotu – klíčové omezení a simulace pozitivního nálezu Potvrzeno Benešem (e-mail 31.8.2026): **v pilotním prostředí se dotazy EXE_FO/EXE_PO na straně ZP vůbec nezpracovávají.** Portál sám odpovídá (v okamžitém synchronním protokolu) jen na FO/PO, které daná ZP **nemá** ve svém registru (`Pojistenec="NE"`). Pro FO/PO, které ZP v registru **má**, portál nastaví `Pojistenec="ANO"` a čeká na skutečnou odpověď ZP – ta ale v pilotu **nikdy nepřijde**, protože ZP strana dotazy vůbec nezpracovává. **Plný end-to-end asynchronní cyklus (dotaz › nález u ZP › skutečná odpověď ve schránce) tedy v pilotu reálně otestovat nejde** – jen jeho synchronní protokolová část. ### FO/PO, které JSOU v pilotním registru (dle Beneše) – používat NEOPATRNĚ, reálná odpověď nikdy nedorazí FO (rodná čísla): - 366215055 *(v e-mailu Beneše uvedeno dvakrát – pravděpodobně překlep/duplicita)* - 371222406 - 375422052 - 375515136 PO (IČO): - 15169944 - 15363121 - 29939 - 3697 - 3699 **Praktický důsledek:** tato čísla se hodí jen k ověření, že se pro ně **nevygeneruje** okamžité `Pojistenec="NE"` (tzn. portál je uzná za existující u některé ZP) – žádná další reálná odpověď ale nikdy nedorazí, na plný test čekat nemá smysl. Pro test základního synchronního NE-protokolu naopak použít **jiné, libovolné/smyšlené** rodné číslo/IČO (mimo tento seznam). ### Jak nasimulovat pozitivní nález (obejití toho, že ZP strana v pilotu nic nezpracovává) Jediný způsob, jak otestovat parsování **skutečné pozitivní odpovědi** (formát `exe_fo_XXX_YYY.xml`/`exe_po_XXX_YYY.xml` v přenosovém obalu dle bodu 3a) v pilotu, je poslat si ji ručně sám sobě, jako by ji poslala ZP: 1. Ručně sestavit soubor s odpovědí přesně dle zdokumentovaného datového rozhraní (`OdpovedFO`/`OdpovedPO`, viz body 4–5). 2. Přihlásit se do **ZP zóny** (ne společné zóny!): https://pilot-pzp.asseco.cz/app/prihlaseni (stejný certifikát jako všude jinde). 3. V menu **"Obecné služby / Zprávy klientům PZP"** dohledat vlastní konto jako adresáta a poslat si zprávu s přílohou = tato předem připravená odpověď, s příponou souboru `.txt`. 4. V konfiguraci B2B komunikace (v PHP třídě) pro tento self-test použít: - URL brány: `https://pilot-pzp.asseco.cz/kom_brana.phtml` (brána **ZP zóny**, ne společné zóny) - název schránky: **`_KL2KL_KLIENT`** (zvláštní "klient-klientovi" schránka, odlišná od ostrých exekutorských schránek `SCHR_PZP_EU_FO`/`SCHR_PZP_EU_PO`, viz bod 6). 5. Přes `Ucel="SCHRANKA"` (bod 6) pak lze zprávu z vlastní schránky `_KL2KL_KLIENT` stáhnout stejnou cestou jako ostrou odpověď ZP – ověří se tak čtení/parsování/dekódování/mazání zpráv nezávisle na tom, že reálný dotaz-odpověď cyklus u ZP v pilotu nefunguje. ### Webové UI pro manuální kontrolu (doplněk k API) Ve **společné zóně** (https://pilot-brn-pzp.asseco.cz/app/prihlaseni) je v menu i sekce pro exekutory s přehledem zaslaných dotazů a odpovědí (odpovědi jak od portálu, tak od ZP) – užitečné pro ruční ověřování stavu vedle vlastní API komunikace. ## 9. Otevřené kroky 1. ~~Zaregistrovat se na https://pilot-brn-pzp.asseco.cz/registrace/#/ jako Nový klient~~ – **hotovo, ID klienta 107655**. 2. ~~Napsat Benešovi, že žádost byla odeslána, ať nastaví oprávnění~~ – **hotovo**; zároveň mu potvrzeno, že se bude používat jen hromadné dotazování ve Společné zóně. 3. Ověřit funkčnost oprávnění přímým přihlášením do obou zón (viz bod 5 níže) – Beneš explicitní potvrzení "nastaveno" nenapsal, ale dává už konkrétní pracovní pokyny, což naznačuje, že přístup funguje. 4. ~~Vyžádat od Beneše konkrétní testovací rodné číslo/IČO~~ – **hotovo, odpověď obdržena** (seznam v bodě 8) – s důležitým zjištěním, že ZP strana v pilotu dotazy nezpracovává (viz bod 8). 5. Přihlásit se do **ZP zóny** (https://pilot-pzp.asseco.cz/app/prihlaseni) i **společné zóny** (https://pilot-brn-pzp.asseco.cz/app/prihlaseni) stejným certifikátem, ověřit přístup a menu pro exekutory ve společné zóně. 6. Provést self-test pozitivní odpovědi dle postupu v bodě 8 (ruční sestavení odpovědi › odeslání sám sobě přes "Zprávy klientům PZP" v ZP zóně › stažení přes SCHRANKA na schránce `_KL2KL_KLIENT` na bráně ZP zóny) – ověří parsovací/dekódovací logiku třídy nezávisle na nefunkčním ZP zpracování v pilotu. 7. Otestovat synchronní NE-protokol s libovolným/smyšleným rodným číslem/IČO (mimo seznam v bodě 8). 8. Sestavit finální PHP třídu (obálka bod 3 vč. 4 variant `Soubor.Format`, struktury EXE_FO/EXE_PO bod 4–5, SCHRANKA bod 6) s hromadným dotazem na všechny FO/PO najednou, hromadným stažením nepřečtených zpráv a průběžným mazáním zpracovaných zpráv (bod 6a). Testovat proti oběma bránám: ZP zóna se schránkou `_KL2KL_KLIENT` pro self-test simulace, společná zóna s reálnými exekutorskými schránkami (`SCHR_PZP_EU_FO`/`SCHR_PZP_EU_PO`) pro produkční provoz.