Files

T

administrator 4f586f4b57 Přidán list ED_PODANI + ED_PODANI_DATA do faktury_report.py; doplněny poznámky o eDávkách

- faktury_report.py: nový list ED_PODANI (ED_BOOKOFSUBMISSIONS) s přehledem podání pojišťovnám
- faktury_report.py: nový list ED_PODANI_DATA s dekódovaným obsahem dávek (KDAVKA, REQUEST XML, odpovědi pojišťoven)
- Opraveno kódování: KDAVKA=cp1250, REQUEST detekce BOM (utf-16/utf-8), SERVERRESPONSE/PROTOCOL=iso-8859-2
- Hyperlinky ED_PODANI ↔ ED_PODANI_DATA a Faktura → FAK
- FakturaceADavky.md: dokumentace ED_* tabulek, portálů pojišťoven, formátů REQUEST XML
- Průzkumné skripty: find_edavky_table, explore_hpn, explore_ed_bookofsubmissions, parse_trace_edavky aj.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-03-30 07:42:46 +02:00

18 KiB

Raw Blame History

Fakturace a dávky – poznámky pro Clauda

Přehled tabulek

FAK – faktury pojišťovnám

844 záznamů (k 2026-03-28)
Primární klíč: ID

Sloupec	Popis
`ID`	primární klíč
`CISFAK`	číslo faktury (10 znaků)
`POJ`	pojišťovna (3 znaky, např. 111=VZP, 205=ČPZP, 207=OZP)
`ICZ`, `ICZ1`	IČZ ordinace
`IDICZ`	FK → ICZ.IDICZ (jen jedna ordinace, neřešit)
`PORCISLO`	pořadové číslo
`DATUMOD`, `DATUMDO`	období faktury (od–do)
`DATVYS`	datum vystavení
`DATODE`	datum odeslání
`OBDOB`	období (5 znaků, např. "20260")
`VYKONY`	částka za výkony (Kč)
`KAPITACE`	kapitační platba (Kč)
`ZALOHA`	záloha
`CENA`	celková cena faktury (Kč)
`DRUH`	druh faktury (např. "konečná")
`TYP`	typ (1 znak)
`ROK`	rok
`SPLAT`	datum splatnosti
`PROPLACENO`	datum proplacení (NULL = nezaplaceno)
`ZAPLACENO`	zaplacená částka
`ZUM`	?
`HOSPAUSAL`	hospitalizační/paušální?
`FDAVKA`	BLOB – odkaz na dávku
`KAPDETAIL`, `AGRDETAIL`	BLOBy – detaily kapitace/agregace
`NAZFAK`, `POZFAK`, `OBDFAK`	název, poznámka, období faktury (texty)
`ICO`, `BANKA`, `UCET`	IČO, banka, účet
`ODJMENO/ULICE/MISTO/PSC`	adresa odesílatele
`PLNAZEV/ULICE/MISTO/PSC`	adresa plátce (pojišťovny)
`DRUHPOJ`	druh pojištění

FAKDET – finanční detail faktury

1021 záznamů
Vazba: IDFAK → FAK.ID
Typicky 1–2 řádky na fakturu (breakdown podle lékaře/IDUZI)

Sloupec	Popis
`ID`	primární klíč
`IDFAK`	FK → FAK.ID
`ICP`	IČP ordinace (např. 09305001)
`ODB`	odbornost (001 = praktický lékař)
`IDUZI`	FK → UZIVATEL.IDUZI – který lékař
`CENAVYK`	výkony (Kč)
`CENALEC`	léky (Kč)
`CENAKAP`	kapitace (Kč)

Poznámka: IDUZI=0 = systémový záznam (kapitace bez konkrétního lékaře).

FAKDAV – dávky zahrnuté ve faktuře

1296 záznamů
Vazba: IDFAK → FAK.ID

Sloupec	Popis
`ID`	primární klíč
`IDFAK`	FK → FAK.ID
`CISDAV`	číslo dávky
`DRUH`	druh dávky
`CENA`	celková cena dávky
`CENAVYK`	výkony
`CENALEC`	léky
`CENAPAU`	paušál
`ODB`	odbornost
`ICP`	IČP

PORTAL – elektronické podání pojišťovně

180 záznamů
Vazba: IDFAK → FAK.ID

Sloupec	Popis
`ID`	primární klíč
`IDFAK`	FK → FAK.ID
`ODESLANO`	timestamp odeslání
`DATA`, `KDAVKA`, `FDAVKA`	BLOBy – pravděpodobně XML dávky
`CHYBA`	příznak chyby (1 znak)
`STAV`	stav podání (smallint)
`ID_PODANI`	ID podání u pojišťovny (32 znaků, UUID)
`IDPODANI`	interní ID podání
`IDCERT`	certifikát použitý pro podání
`DAVKA_ROK`, `DAVKA_DISK`, `DAVKA_IDICZ`	metadata dávky
`BB_DAVKA`, `BB_FAKTURA`	?
`DAVKA_DATUMOD`, `DAVKA_DATUMDO`	období dávky
`DAVKA_CASTKA`	částka dávky

Schéma vazeb

FAK (faktura)
 ├── FAKDET  (IDFAK → FAK.ID)  – finanční breakdown podle lékaře
 ├── FAKDAV  (IDFAK → FAK.ID)  – seznam dávek ve faktuře
 ├── PORTAL  (IDFAK → FAK.ID)  – viz níže, IDFAK bývá NULL
 └── ICZ     (IDICZ → ICZ.IDICZ) – ordinace (jen jedna, neřešit)

UZIVATEL – lékaři a uživatelé

IDUZI	Příjmení	Jméno	Zkratka	Aktivní
2	Jourová	Jana	JOU	F (neaktivní)
3	Sestra	—	SES	F (neaktivní)
4	Buzalková	Michaela	MBU	T – lékařka, manželka
5	Ševčíková	Ivana	ISE	T
6	Buzalka	Vladimír	VBU	T – uživatel (já)

Ukázkové záznamy

FAK ID=856 (poslední)

Faktura č. 260026, pojišťovna 205 (ČPZP), prosinec 2025
Vystavena: 2026-03-12, druh: konečná
VYKONY: 2 528,99 Kč, KAPITACE: 0, CENA: 2 528,99 Kč
ZAPLACENO: NULL, PROPLACENO: NULL

FAKDET k FAK ID=856:

ID	IDUZI	CENAVYK	CENALEC	CENAKAP
1034	0 (systém)	0	0	1 902,54
1035	4 (Buzalková)	2 528,99	0	0

FAK ID=855 (předposlední)

Faktura č. 260026, pojišťovna 207 (OZP), prosinec 2025
Vystavena: 2026-03-01, druh: konečná
VYKONY: 85 Kč, KAPITACE: 0, CENA: 85 Kč
ZAPLACENO: NULL, PROPLACENO: NULL

FAKDET k FAK ID=855:

ID	IDUZI	CENAVYK	CENALEC	CENAKAP
1033	6 (Buzalka Vladimír)	85	0	0

PORTAL – upřesnění (zjištěno 2026-03-28)

PORTAL nesouvisí s fakturací. Je to samostatná agenda – evidence registračních dávek odeslaných pojišťovně.

Co PORTAL skutečně je

Medicus přes PORTAL odesílá pojišťovně dávky s přihlášením/odhlášením pacientů k lékaři (MUDr. Buzalková jako praktický lékař)
Bez peněz – čistě administrativní agenda registrací
IDFAK = NULL u všech registračních podání (není vazba na fakturu)

Klíčové sloupce

Sloupec	Popis
`KDAVKA`	odeslaná dávka – pevný formát (hlavička + řádky I = pacienti, RC, datum)
`DATA`	odpověď pojišťovny jako XML (`<statuscode>100</statuscode>` = OK)
`ID_PODANI`	ID přidělené pojišťovnou (např. `D01F260118593316.D01`)
`DAVKA_DISK`	číslo dávky v roce (sekvenční)
`DAVKA_ROK`	rok dávky
`DAVKA_DATUMOD/DO`	období registrací v dávce
`CHYBA`	F = bez chyby

Ukázka KDAVKA (hlavička dávky)

DP80093050000900202506    15  1          0              0.00180:6.2.46
H21109305001    179202506001
I   1Příjmení    Jméno    RC  datum_registrace
I   2...

Ukázka DATA (odpověď pojišťovny)

<ekomunikace timestamp="20260127 063105">
  <session id="ff59b436-...">
    <statusline>Přijetí registrací proběhlo úspěšně</statusline>
    <statuscode>100</statuscode>
    <idpodani>D01F260118593316.D01</idpodani>
  </session>
</ekomunikace>

PORTAL – dva typy dávek

Typ 1 – Registrační dávka (DP80)

KDAVKA začíná DP80
IDFAK = NULL – bez vazby na fakturu
Bez peněz (DAVKA_CASTKA = NULL)
Přihlašuje/odhlašuje pacienty k lékaři (MUDr. Buzalková)
Řádky I = pacient (RC, datum registrace)

Typ 2 – Výkonová dávka (DP98)

KDAVKA začíná DP98
IDFAK = ID faktury – napojeno na FAK
Má peníze (DAVKA_CASTKA, např. 15 452,91 Kč)
STAV = 10 (registrační mají NULL)
Obsahuje výkony vykázané pojišťovně za dané období

Struktura výkonové dávky (KDAVKA):

DP98...   – hlavička dávky (IČP, rok, měsíc, disk, počet případů, částka)
A ...     – ambulantní případ (RC pacienta, diagnóza)
V ...     – výkon (datum, kód výkonu, body)
Z ...     – ZULP (zvlášť účtovaný léčivý přípravek)
L ...     – lékový řádek (kód, množství, cena)
DP05...   – druhá část dávky (prevence / jiný typ)
P ...     – preventivní prohlídka

Odpověď pojišťovny pro výkonovou dávku:

<statusline>Přijetí faktury proběhlo úspěšně</statusline>
<statuscode>100</statuscode>

Poznámky

Faktury jsou vystavovány zvlášť pro každou pojišťovnu
FAKDET má řádky zvlášť pro každého lékaře (IDUZI)
IDUZI=0 v FAKDET = systémový záznam pro kapitaci
Kapitace se v FAK.KAPITACE neukazuje (je 0), ale v FAKDET.CENAKAP ano – nutno ověřit
PORTAL = registrační dávky, nesouvisí s fakturací, IDFAK bývá NULL

eDávky – elektronické odesílání dávek pojišťovnám (zjištěno 2026-03-29)

Přehled tabulek

Modul eDávky v Medicusu používá tabulky s prefixem ED_:

Tabulka	Záznamy	Popis
`ED_BOOKOFSUBMISSIONS`	998	Hlavní tabulka – Kniha podání (od 2016)
`ED_BOOKOFSUBMISSIONATTACH`	0	Přílohy k podáním (zatím nevyužito)
`ED_MAILBOXMESSAGE`	0	Schránka zpráv od pojišťoven (zatím prázdná)
`ED_STORAGE`	5	Konfigurace – certifikáty a přihlašovací údaje

Jak jsme tabulku našli

Přes Firebird trace log – při otevření okna eDávky v Medicusu se nejčastěji dotazuje na ED_BOOKOFSUBMISSIONS (45x) a ED_MAILBOXMESSAGE (4990x).

PORTAL vs ED_BOOKOFSUBMISSIONS

PORTAL (180 záznamů, max 2026-01-27) = starý systém podávání dávek
ED_BOOKOFSUBMISSIONS (998 záznamů, od 2016) = nový systém (přechod ~únor 2026)
Nepřekrývají se – žádný záznam není v obou (různá ID_PODANI/SUBMISSIONID)
PORTAL má data od 2014, ED_BOOKOFSUBMISSIONS od 2016 (oba systémy běžely paralelně)

ED_BOOKOFSUBMISSIONS – hlavní tabulka Knihy podání

Sloupce:

Sloupec	Popis
`ID`	primární klíč
`CREATED`	datum vytvoření
`SENTDATE`	datum odeslání pojišťovně
`CREATOR`	jméno autora (např. "Buzalková Michaela MUDr.")
`HCPCODE`	IČZ ordinace (09305000)
`HCPPERSONNAME`	jméno lékaře
`HICCODE`	kód pojišťovny (111, 201, 205, 207, 209, 211...)
`INVOICENUMBER`	číslo faktury (např. 0000260020) – NULL pro reg. dávky
`PERIODFROM` / `PERIODTO`	období dávky
`REQUESTTYPE`	typ: 0 = registrační (Reg. listy), 1 = výkonová s fakturou
`STATE`	stav podání (0 = odesláno OK)
`SUBMISSIONID`	podací číslo přidělené pojišťovnou (např. 59135047)
`TOTALSUM`	celková částka (0 pro reg. dávky)
`UNIQUEID`	UUID záznamu
`USERDESCRIPTION`	popis (zobrazuje se ve sloupci "Zprávy")
`REQUEST`	XML žádosti odeslané pojišťovně (BLOB)
`SERVERRESPONSE`	odpověď pojišťovny (BLOB, bytes, kódování iso-8859-2)
`FDAVKACONTENT`	obsah FDAVKA (BLOB)
`KDAVKACONTENT`	obsah KDAVKA (BLOB)
`PROTOCOL`	protokol (BLOB)

Pojišťovny v datech: 111 (VZP), 201 (VoZP), 205 (ČPZP), 207 (OZP), 209 (ZPŠ), 211 (ZPMV)

Kódování pojišťoven (správné!)

111 = VZP (Všeobecná zdravotní pojišťovna)
201 = VoZP (Vojenská zdravotní pojišťovna)
205 = ČPZP (Česká průmyslová zdravotní pojišťovna)
207 = OZP (Oborová zdravotní pojišťovna)
209 = ZPŠ (Zdravotní pojišťovna Škoda)
211 = ZPMV (Zdravotní pojišťovna ministerstva vnitra)

ED_STORAGE – konfigurace certifikátů a přihlašovacích údajů

Sloupce: ID, NAME, VALUEB (BLOB XML), IDUZI

Záznamy:

ServerSettingsXml (per uživatel, IDUZI=None/2/4/6) – XML s certifikáty pro každou pojišťovnu
LastMessagesDownloadTime (IDUZI=None) – datum posledního stažení zpráv

Struktura ServerSettingsXml:

<Settings>
  <PortalZP>
    <Portal Code="201">
      <SigningCertificate Issuer="..." SerialNumber="..." />
    </Portal>
    <!-- Code: 201, 205, 207, 209, 212, 213, 217, 228, 333 -->
  </PortalZP>
  <PortalZPMV>
    <!-- Pro ZPMV (211): PIN, Password, Email uloženy v plaintextu! -->
    <Portal Code="211" PIN="..." Password="..." Email="ordinace@buzalkova.cz" />
  </PortalZPMV>
  <PortalVZP>
    <!-- Pro VZP (111): SigningCertificate + AuthenticationCertificate -->
    <Portal Code="111" UseAlternativePortal="true">
      <SigningCertificate Issuer="..." SerialNumber="..." />
      <AuthenticationCertificate Issuer="..." SerialNumber="..." />
    </Portal>
  </PortalVZP>
</Settings>

Certifikát Buzalky Vladimíra (IDUZI=6):

Vydavatel: I.CA EU Qualified CA2/RSA 06/2022 (První certifikační autorita, a.s.)
SerialNumber: 0247068517B0049E2E
Platí pro pojišťovny: 201, 205, 207, 209, 213, 217, 228

Formát REQUEST XML – registrační dávka (REQUESTTYPE=0)

<?xml version="1.0" encoding="utf-16"?>
<SubmissionRequest>
  <SubmissionType>RegistrationCards</SubmissionType>
  <InvoiceType>None</InvoiceType>
  <PeriodFrom>2026-03-01T00:00:00.000</PeriodFrom>
  <PeriodTo>2026-03-31T00:00:00.000</PeriodTo>
  <TotalSum>0</TotalSum>
  <HcpCode>09305000</HcpCode>      <!-- IČZ ordinace -->
  <FICZ>09305000</FICZ>
  <HcpOrgNum>68366370</HcpOrgNum>  <!-- IČO -->
  <HcpPersonName>MUDr. Buzalka Vladimír</HcpPersonName>
  <HicCode>111</HicCode>           <!-- kód pojišťovny -->
  <HicName>Všeobecná zdravotní pojišťovna ČR</HicName>
  <HicCity>0900</HicCity>
  <FPOB>0900</FPOB>
  <VDPOJ>1</VDPOJ>
  <InvoiceItems>
    <InvoiceItem>
      <BatchNumber>8</BatchNumber>
      <Type>DP80</Type>            <!-- DP80 = registrační dávka -->
      <Price>0.00</Price>
      <Year>2026</Year>
      <Month>3</Month>
      <DBODY>0</DBODY>
      <DUHR>2</DUHR>
    </InvoiceItem>
  </InvoiceItems>
</SubmissionRequest>

Formát REQUEST XML – výkonová dávka s fakturou (REQUESTTYPE=1)

<?xml version="1.0" encoding="utf-16"?>
<SubmissionRequest>
  <SubmissionType>HealthCareBilling</SubmissionType>
  <InvoiceNumber>0000260026</InvoiceNumber>
  <InvoiceType>HealthCareInvoice</InvoiceType>
  <DateOfIssue>2026-03-01T00:00:00.000</DateOfIssue>
  <DateOfDispatch>2026-03-01T00:00:00.000</DateOfDispatch>
  <DateOfMaturity>2026-03-31T00:00:00.000</DateOfMaturity>
  <PeriodFrom>2025-12-01T00:00:00.000</PeriodFrom>
  <PeriodTo>2025-12-31T00:00:00.000</PeriodTo>
  <TotalSum>85</TotalSum>
  <HcpCode>09305000</HcpCode>
  <HcpOrgNum>68366370</HcpOrgNum>
  <HcpAccountNumber>2800046620</HcpAccountNumber>
  <HcpAccountPrefix>000000</HcpAccountPrefix>
  <HcpAccountBankCode>2010</HcpAccountBankCode>
  <HcpName>Praktický lékař pro dospělé</HcpName>
  <HcpStreet>Lovosická 440/40</HcpStreet>
  <HcpCity>Praha 9-Prosek</HcpCity>
  <HcpZipCode>19000</HcpZipCode>
  <HcpPersonName>MUDr. Buzalková Michaela</HcpPersonName>
  <HicCode>207</HicCode>
  <HicStreet>Ročkotova 1225/1</HicStreet>
  <HicCity>Praha 4</HicCity>
  <HicZipCode>140 21</HicZipCode>
  <FPOB>0900</FPOB>
  <VDPECE>51</VDPECE>
  <InvoiceItems>
    <InvoiceItem>
      <BatchNumber>34</BatchNumber>
      <Type>DP05</Type>            <!-- DP05 = výkonová dávka -->
      <Year>2025</Year>
      <Month>12</Month>
      <DBODY>85</DBODY>
      <DUHR>1</DUHR>
    </InvoiceItem>
  </InvoiceItems>
</SubmissionRequest>

Poznámka k diakritice v REQUEST: Medicus ukládá XML v UTF-16, ale česká diakritika v polích jako HcpPersonName, HicName apod. bývá uložena bez háčků/čárek (bug Medicusu při tvorbě XML). Toto není chyba dekódování.

Formát SERVERRESPONSE (odpověď pojišťovny)

Kódování: iso-8859-2 (bytes)
Struktura: XML <Komunikace><Data ...><Soubor ...>text</Soubor></Data><Podpis>PKCS7</Podpis></Komunikace>
PZP_IdPodani = přidělené podací číslo
PZP_Chyba="0" = bez chyby
Odpověď je podepsána pojišťovnou (PKCS7)

Plán: skript pro automatické odeslání žádosti o seznam registrovaných

Portály pojišťoven – 3 skupiny

Skupina 1 – Společný portál (201, 205, 207, 209, 213, 217, 228)

Jeden společný portál pro všechny tyto pojišťovny
Autentizace a podepisování: kvalifikovaný certifikát I.CA EU Qualified CA2/RSA 06/2022
SerialNumber (Buzalka): 0247068517B0049E2E
Vydavatel: První certifikační autorita, a.s.

Skupina 2 – VZP (111) – vlastní portál

VZP má samostatný portál (UseAlternativePortal="true" v konfiguraci)
Podepisování: komerční certifikát I.CA Public CA/RSA 06/2022 (nižší stupeň než kvalifikovaný)
- SerialNumber: 01DE0F46B713505F1F
Autentizace vůči portálu: certifikát Komerční banky (DCS CA KB)
- SerialNumber: 46E67A

Skupina 3 – ZPMV (211) – samostatní exoti

Žádný certifikát, přihlašování heslem
Konfigurace: PIN, Password, Email (uloženo v plaintextu v ED_STORAGE)
Email: ordinace@buzalkova.cz

Formáty odpovědí v PORTAL.DATA (historické)

Různé pojišťovny vracely různé formáty:

ČPZP/ZPMV (D01 portál): XML <ekomunikace><statuscode>100</statuscode><idpodani>D01F...</idpodani>
OZP a ostatní (starý portál): XML <Komunikace><Data ...><Soubor Format="BASE64">HTML protokol</Soubor></Data></Komunikace>
- HTML protokol je v iso-8859-2, obsahuje tabulku s detaily dávky

Kódování BLOBů v ED_BOOKOFSUBMISSIONS

Sloupec	Kódování	Poznámka
`KDAVKACONTENT`	CP1250	fdb vrací str přes win1250 spojení – použít přímo
`REQUEST`	ASCII/UTF-8 nebo UTF-16	Detekovat podle BOM: `FF FE`/`FE FF` → utf-16, začíná `<` → utf-8
`SERVERRESPONSE`	iso-8859-2	latin-1 re-encoding → decode iso-8859-2
`PROTOCOL`	iso-8859-2	latin-1 re-encoding → decode iso-8859-2

Důležité: Pro re-encoding str→bytes vždy používat latin-1 (ne cp1250), protože latin-1 zachová všechny bajty 0–255 beze změny včetně null bajtů. Pro utf-16 nikdy nezkoušet decode bez ověření BOM – bez BOM Python tiše vrátí čínské znaky místo chyby.

Co potřebujeme ještě zjistit:

URL endpointů jednotlivých portálů (zachytit přes síťový trace)
Jak přesně se REQUEST podepisuje certifikátem (PKCS12 / Windows certificate store)

Co už máme:

Formát REQUEST XML (viz výše)
Certifikáty a přihlašovací údaje z ED_STORAGE
Strukturu odpovědi pojišťovny
Rozdělení pojišťoven do 3 skupin podle způsobu přístupu

Kódování KDAVKA/FDAVKA – důležité!

Dávkové soubory (KDAVKA, FDAVKA) jsou uloženy v CP852 (DOS Latin-2, prahistorické kódování).

fdb je čte přes connection charset win1250 a vrací je jako Python str (špatně dekódované).

Správný postup dekódování:

# fdb vrátil string dekódovaný jako win1250 – musíme to zvrátit
raw_bytes = s.encode('cp1250', errors='replace')
spravny_text = raw_bytes.decode('cp852', errors='replace')

KDAVKA, FDAVKA → cp852
DATA (XML odpověď pojišťovny) → cp1250 (win1250), fdb dekóduje správně

18 KiB Raw Blame History Unescape Escape

Fakturace a dávky – poznámky pro Clauda

Přehled tabulek

FAK – faktury pojišťovnám

FAKDET – finanční detail faktury

FAKDAV – dávky zahrnuté ve faktuře

PORTAL – elektronické podání pojišťovně

Schéma vazeb

UZIVATEL – lékaři a uživatelé

Ukázkové záznamy

FAK ID=856 (poslední)

FAK ID=855 (předposlední)

PORTAL – upřesnění (zjištěno 2026-03-28)

Co PORTAL skutečně je

Klíčové sloupce

Ukázka KDAVKA (hlavička dávky)

Ukázka DATA (odpověď pojišťovny)

PORTAL – dva typy dávek

Typ 1 – Registrační dávka (DP80)

Typ 2 – Výkonová dávka (DP98)

Poznámky

eDávky – elektronické odesílání dávek pojišťovnám (zjištěno 2026-03-29)

Přehled tabulek

Jak jsme tabulku našli

PORTAL vs ED_BOOKOFSUBMISSIONS

ED_BOOKOFSUBMISSIONS – hlavní tabulka Knihy podání

Kódování pojišťoven (správné!)

ED_STORAGE – konfigurace certifikátů a přihlašovacích údajů

Formát REQUEST XML – registrační dávka (REQUESTTYPE=0)

Formát REQUEST XML – výkonová dávka s fakturou (REQUESTTYPE=1)

Formát SERVERRESPONSE (odpověď pojišťovny)

Plán: skript pro automatické odeslání žádosti o seznam registrovaných

Portály pojišťoven – 3 skupiny

Skupina 1 – Společný portál (201, 205, 207, 209, 213, 217, 228)

Skupina 2 – VZP (111) – vlastní portál

Skupina 3 – ZPMV (211) – samostatní exoti

Formáty odpovědí v PORTAL.DATA (historické)

Kódování BLOBů v ED_BOOKOFSUBMISSIONS

Kódování KDAVKA/FDAVKA – důležité!

18 KiB

Raw Blame History