Dokumentové pipeline: od DOCX přes PDF/A-3 po podepsaný archiv v jednom API volání

Pipeline, která konvertuje vstupní dokumenty na vyhovující archivní výstup, zní jako vyřešený problém. V praxi produkuje tiché selhání v každém kroku: písma, která vypadají správně na obrazovce, ale selhávají při validaci PDF/A, textové vrstvy zničené při konverzi, metadata přítomná, ale technicky nesprávná a časová razítka aplikovaná na dokumenty, které ještě nejsou ve své finální podobě.

Tento článek prochází kompletním konverzním řetězcem, co se pokazí v každé fázi a jak vypadá spolehlivá pipeline.

Kompletní řetězec

Source document (DOCX / HTML / existing PDF)
    ↓  conversion
PDF (rendered with correct fonts and layout)
    ↓  PDF/A-3 conformance
PDF/A-3 (embedded fonts, color profiles, XMP metadata, no external references)
    ↓  structured attachment (for hybrid invoices)
PDF/A-3 with embedded XML (Factur-X, ZUGFeRD, XRechnung attachment)
    ↓  digital signature
Signed PDF/A-3 (PAdES signature, LTV information embedded)
    ↓  RFC 3161 timestamp
Timestamped PDF/A-3 (RFC 3161 token from qualified EU TSA)
    ↓  archive + audit trail
Final archive (WORM storage + hash-chained audit trail + evidence pack)

Každá šipka je krok, který může způsobit nesoulad. Každý krok by měl zahrnovat validaci před spuštěním dalšího.

Krok 1: zdroj do PDF

Nejběžnější konverzní cestou je DOCX do PDF. Rizikem je zde substituce písem: pokud písmo použité v DOCX není dostupné na konverzním serveru, renderer nahradí jiné písmo. Výstup vypadá podobně na obrazovce, ale obsahuje jiné písmo, než bylo zadáno. Když später poběží validace PDF/A, může detekovat nesprávné písmo nebo selhat, protože vložené písmo neodpovídá písmu odkazovanému v dokumentu.

Zmírnění: zajistěte, aby konverzní prostředí mělo nainstalována všechna požadovaná písma, nebo použijte přístup konverze, který vkládá písma v době konverze. LibreOffice headless a Gotenberg (Docker-based obálka LibreOffice) jsou spolehlivé open-source možnosti pro konverzi DOCX do PDF. Gotenberg zejména poskytuje předvídatelné izolované prostředí.

Neprovádějte konverzi DOCX do PDF tiskem do PDF ovladače. Tiskové ovladače často rasterizují text, čímž ničí textovou vrstvu a produkují dokument, který je vizuálně identický, ale již není strojově čitelný nebo prohledávatelný. Rasterizované PDF nelze bez opětovného OCR převést na platné PDF/A-3, což zavádí další chyby.

Pro HTML do PDF je renderování v bezhlavém prohlížeči (pomocí renderovacích engine prohlížeče) obecně spolehlivější pro věrnost rozvržení než wkhtmltopdf. Moderní renderovací engine prohlížeče správně zpracovávají CSS. Zkontrolujte, zda HTML zdroj má všechna písma buď vložená nebo specifikovaná jako web-safe písma.

Krok 2: PDF do PDF/A-3

Shoda s PDF/A-3 se automaticky nedosáhne výstupem PDF z knihovny podporující PDF/A-3. Několik věcí se může pokazit:

Chybějící nebo nesprávná metadata XMP: PDF/A vyžaduje sebeopisující blok XMP, který identifikuje úroveň shody. Povinná pole:

<rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
    <pdfaid:part>3</pdfaid:part>
    <pdfaid:conformance>B</pdfaid:conformance>
</rdf:Description>

Bez tohoto bloku dokument technicky není PDF/A-3 bez ohledu na svou strukturu. Mnoho konvertorů produkuje výstup vypadající jako PDF/A, ale vynechává nebo nesprávně konfiguruje blok XMP.

Nevložená písma: i když konverze vložila písma, některé konvertory nechávají písma Type1 nebo TrueType částečně vložená (pouze metriky, nikoli celá data glyfů). PDF/A vyžaduje úplné vložení.

Nepodporované barevné prostory: obrázky v dokumentu musí používat barevné prostory s vloženými ICC profily. RGB obrázek bez ICC profilu selže validací PDF/A. Před zahrnutím do dokumentu převeďte obrázky na sRGB s vloženým profilem.

Průhlednost: PDF/A-1 zakazuje průhlednost. PDF/A-2 a PDF/A-3 ji povolují, ale vyžadují specifické zpracování. Mnoho zdrojových dokumentů používá měkké stíny nebo průsvitné překryvy, které musí být zploštěny před výstupem PDF/A-1.

Šifrování: PDF/A zakazuje šifrování. PDF s uživatelským nebo vlastnickým heslem není kompatibilní s PDF/A bez ohledu na ostatní vlastnosti.

Spusťte VeraPDF po tomto kroku pro potvrzení shody před pokračováním. VeraPDF je referenční validátor používaný národními archivy a regulátory po celé Evropě. Je open-source a lze jej spustit v bezhlavé pipeline.

Krok 3: vložení strukturovaného XML (hybridní dokumenty)

Pro faktury (Factur-X, ZUGFeRD, XRechnung) musí PDF/A-3 obsahovat XML fakturu jako přílohu s konkrétními metadaty.

Vztah přílohy musí být Alternative pro Factur-X, nikoli Data nebo Unspecified. To je definováno specifikací Factur-X a je jednou z nejčastějších selhání shody v generátorech faktur PDF/A-3.

Požadované rozšíření schématu XMP pro přílohu Factur-X:

<fx:ConformanceLevel>EN 16931</fx:ConformanceLevel>
<fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
<fx:DocumentType>INVOICE</fx:DocumentType>
<fx:Version>1.0</fx:Version>

Název souboru musí být přesně factur-x.xml pro Factur-X a metadata XMP musí na tento název souboru odkazovat. Validátory kontrolující shodu s Factur-X (nejen PDF/A-3) odmítnou dokumenty, kde je název souboru nebo odkaz XMP nesprávný.

Krok 4: digitální podpis

Aplikujte podpis PAdES (PDF Advanced Electronic Signatures), nikoli základní podpis PDF. PAdES je definován v ETSI EN 319 132 a podporuje vložení LTV.

V době podpisu vložte kompletní řetěz certifikátů a odpověď OCSP nebo snímek CRL, který prokazuje, že podpisový certifikát byl platný v okamžiku podpisu. To jsou informace LTV popsané v dlouhodobé validaci PDF. Bez nich se podpis může stát neověřitelným, když podpisový certifikát vyprší.

Nerazítkujte před podpisem. Správné pořadí je: nejprve podepište, poté orazítkujte podpis. Razítkování dokumentu před podpisem mění haš dokumentu, čímž zneplatní podpis.

Krok 5: RFC 3161 časové razítko

Vyžádejte razítko ihned po podpisu, dokud je podpisový certifikát stále online ověřitelný. Razítko se aplikuje na haš podepsaného dokumentu a pokrývá jak obsah dokumentu, tak podpis.

Uložte token razítka uvnitř PDF (ve slovníku DSS dokumentu) a také v balíčku právních důkazů jako samostatný soubor pro nezávislé ověření.

Krok 6: archivace a auditní stopa

Zapište finální dokument do WORM úložiště se zamčenou dobou uchovávání. Přidejte událost archivace do auditní stopy hašového řetězce.

Záznam auditní stopy pro krok archivace by měl obsahovat: haš dokumentu, umístění úložiště, dobu uchovávání, časové razítko události archivace a haš předchozího záznamu auditu. Tím vzniká záznam odolný vůči manipulaci, že dokument byl archivován v přesně této podobě v přesně tento čas.

Validace v každém kroku

Způsob selhání, kterému je třeba se vyhnout, je tiché nesoulad: dokument, který projde všemi šesti kroky a produkuje soubor, který vypadá správně, ale selže při validaci při předložení auditorovi.

Validujte v krocích 2, 3 a 5:

• Po konverzi PDF/A-3: VeraPDF pro shodu s PDF/A-3
• Po vložení XML (pokud je aplikovatelné): validátor profilu Factur-X nebo ZUGFeRD
• Po razítkování: ověřovatel PAdES (DSS nebo ekvivalent) pro platnost podpisu a razítka

Pokud validace selže v jakémkoli kroku, zastavte pipeline a vraťte strukturovanou chybu. Nepokračujte v archivaci s nesoulad dokumentem.

SealDoc jako dokumentová pipeline

SealDoc API implementuje kompletní výše popsaný řetězec jako jeden endpoint. Odešlete zdrojový dokument (DOCX, HTML nebo existující PDF) spolu se strukturovanými metadaty (data faktury, informace o stranách, kategorie uchovávání). API spustí konverzi, validaci PDF/A-3, vložení XML, podepisování, razítkování a archivaci, přičemž při úspěchu vrátí balíček důkazů nebo strukturovanou chybu validace při selhání.

Každý krok v pipeline je implementován tak, aby rychle selhal: pokud VeraPDF vrátí chybu shody, pipeline se zastaví a vrátí specifickou doložku, která byla porušena, místo aby pokračovala v dalším kroku s nesoulad dokumentem. Balíček důkazů se generuje pouze tehdy, když všechny kroky validace proběhnou.

Pro organizace, které potřebují integrovat archivaci dokumentů do stávajících workflowsů, API přijímá webhooks upozorňující na dokončení nebo selhání, a balíček důkazů je načitatelný jako ZIP obsahující všechny komponenty v otevřených, nezávisle ověřitelných formátech.