Potoki dokumentów: od DOCX do PDF/A-3 do podpisanego archiwum w jednym wywołaniu API
Potok dokumentów konwertujący dokumenty wejściowe do zgodnych wyników archiwalnych brzmi jak rozwiązany problem. W praktyce generuje ciche awarie na każdym kroku: czcionki wyglądające poprawnie na ekranie, ale nie przechodzące walidacji PDF/A, warstwy tekstowe niszczone podczas konwersji, metadane obecne, ale technicznie błędne, i sygnatury czasowe stosowane do dokumentów, które nie są jeszcze w finalnej postaci.
Ten artykuł omawia pełny łańcuch konwersji, co psuje się na każdym etapie i jak wygląda niezawodny potok.
Pełny łańcuch
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żda strzałka to krok, który może wprowadzić niezgodność. Każdy krok powinien obejmować walidację przed uruchomieniem kolejnego.
Krok 1: źródło do PDF
Najczęstszą ścieżką konwersji jest DOCX do PDF. Ryzykiem jest tu podstawianie czcionek: jeśli czcionka używana w DOCX nie jest dostępna na serwerze konwersji, renderer podstawia inną czcionkę. Wynik wygląda podobnie na ekranie, ale zawiera inną czcionkę niż określona. Gdy później uruchomi się walidacja PDF/A, może wykryć błędną czcionkę lub zakończyć się niepowodzeniem, bo osadzona czcionka nie pasuje do tej wskazanej w dokumencie.
Rozwiązanie: upewnij się, że środowisko konwersji ma zainstalowane wszystkie wymagane czcionki lub użyj podejścia konwersji osadzającego czcionki w chwili konwersji. LibreOffice headless i Gotenberg (opakowanie LibreOffice oparte na Dockerze) to niezawodne opcje open-source do konwersji DOCX do PDF. Gotenberg w szczególności zapewnia przewidywalne odizolowane środowisko.
Nie konwertuj DOCX do PDF przez drukowanie do sterownika PDF. Sterowniki druku często rasteryzują tekst, co niszczy warstwę tekstową i daje dokument, który wygląda identycznie, ale nie jest już maszynowo czytelny ani przeszukiwalny. Rasteryzowany PDF nie może zostać przekształcony w ważny PDF/A-3 bez ponownego OCR, co wprowadza dodatkowy błąd.
W przypadku HTML do PDF renderowanie w trybie bezgłowym przeglądarki (używające silników renderujących przeglądarek) jest ogólnie bardziej niezawodne pod względem wierności układu niż wkhtmltopdf. Nowoczesne silniki przeglądarek poprawnie obsługują CSS. Sprawdź, czy źródło HTML ma wszystkie czcionki osadzone lub określone jako czcionki bezpieczne dla sieci.
Krok 2: PDF do PDF/A-3
Zgodność z PDF/A-3 nie jest automatycznie osiągana przez wygenerowanie PDF z biblioteki obsługującej PDF/A-3. Kilka rzeczy może się nie powieść:
Brak lub niepoprawne metadane XMP: PDF/A wymaga samoopisującego bloku XMP identyfikującego poziom zgodności. Wymagane pola:
<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 tego bloku dokument technicznie nie jest PDF/A-3 niezależnie od jego struktury. Wiele konwerterów generuje wyniki wyglądające jak PDF/A, ale pomija lub błędnie konfiguruje blok XMP.
Nieosadzone czcionki: nawet jeśli konwersja osadziła czcionki, niektóre konwertery pozostawiają czcionki Type1 lub TrueType częściowo osadzone (tylko metryki, bez pełnych danych glifów). PDF/A wymaga pełnego osadzenia.
Nieobsługiwane przestrzenie kolorów: obrazy w dokumencie muszą używać przestrzeni kolorów z osadzonymi profilami ICC. Obraz RGB bez profilu ICC nie przechodzi walidacji PDF/A. Konwertuj obrazy na sRGB z osadzonym profilem przed umieszczeniem ich w dokumencie.
Przezroczystość: PDF/A-1 zabrania przezroczystości. PDF/A-2 i PDF/A-3 ją dopuszczają, ale wymagają specyficznej obsługi. Wiele dokumentów źródłowych używa miękkich cieni lub półprzezroczystych nakładek, które muszą być spłaszczone przed generowaniem PDF/A-1.
Szyfrowanie: PDF/A zabrania szyfrowania. PDF z hasłem użytkownika lub właściciela nie jest zgodny z PDF/A niezależnie od innych właściwości.
Uruchom VeraPDF po tym kroku, aby potwierdzić zgodność przed kontynuowaniem. VeraPDF to referencyjna walidator, używana przez archiwa krajowe i regulatorów w całej Europie. Jest open-source i może być uruchamiana w bezgłowym potoku.
Krok 3: osadzanie strukturalnego XML (dokumenty hybrydowe)
Dla faktur (Factur-X, ZUGFeRD, XRechnung), PDF/A-3 musi zawierać fakturę XML jako załącznik z określonymi metadanymi.
Relacja załącznika musi być Alternative dla Factur-X, a nie Data ani Unspecified. Jest to zdefiniowane w specyfikacji Factur-X i jest jedną z najczęstszych awarii zgodności w generatorach faktur PDF/A-3.
Wymagany schemat rozszerzenia XMP dla załącznika 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>Nazwa pliku musi być dokładnie factur-x.xml dla Factur-X, a metadane XMP muszą odwoływać się do tej nazwy. Walidatory sprawdzające zgodność Factur-X (nie tylko PDF/A-3) odrzucą dokumenty, w których nazwa pliku lub odwołanie XMP jest błędne.
Krok 4: podpis cyfrowy
Zastosuj podpis PAdES (PDF Advanced Electronic Signatures), a nie podstawowy podpis PDF. PAdES jest zdefiniowany w ETSI EN 319 132 i obsługuje osadzanie LTV.
W chwili podpisywania osadź pełny łańcuch certyfikatów i odpowiedź OCSP lub migawkę CRL potwierdzającą, że certyfikat podpisujący był ważny w chwili podpisywania. Są to informacje LTV omówione w artykule długoterminowa walidacja PDF. Bez nich podpis może stać się niezweryfikowalny po wygaśnięciu certyfikatu podpisującego.
Nie stosuj sygnatury czasowej przed podpisaniem. Właściwa kolejność to: najpierw podpisz, potem opatrz sygnaturą czasową. Opatrzenie dokumentu sygnaturą przed podpisaniem zmienia skrót dokumentu, co unieważnia podpis.
Krok 5: sygnatura czasowa RFC 3161
Zażądaj sygnatury bezpośrednio po podpisaniu, gdy certyfikat podpisujący jest jeszcze weryfikowalny online. Sygnatura jest stosowana do skrótu podpisanego dokumentu i obejmuje zarówno treść dokumentu, jak i podpis.
Przechowuj token sygnatury wewnątrz PDF (w słowniku DSS dokumentu) oraz w Legal Evidence Pack jako samodzielny plik do niezależnej weryfikacji.
Krok 6: archiwum i ścieżka audytowa
Zapisz finalny dokument do magazynu WORM z zablokowanym okresem retencji. Dołącz zdarzenie archiwizacji do ścieżki audytowej opartej na łańcuchu skrótów.
Wpis ścieżki audytowej dla kroku archiwizacji powinien zawierać: skrót dokumentu, lokalizację magazynu, okres retencji, sygnaturę zdarzenia archiwizacji i skrót poprzedniego wpisu audytowego. Daje to odporny na naruszenia zapis, że dokument był archiwizowany w tej dokładnie postaci w tym dokładnie momencie.
Walidacja na każdym kroku
Trybem awarii, któremu należy zapobiec, jest cicha niezgodność: dokument przechodzący przez wszystkie sześć kroków i produkujący plik wyglądający poprawnie, ale nie przechodzący walidacji po przedstawieniu audytorowi.
Waliduj na krokach 2, 3 i 5:
- Po konwersji PDF/A-3: VeraPDF dla zgodności PDF/A-3
- Po osadzeniu XML (jeśli dotyczy): walidator profilu Factur-X lub ZUGFeRD
- Po opatrzeniu sygnaturą: weryfikator PAdES (DSS lub równoważny) dla ważności podpisu i sygnatury
Jeśli walidacja zakończy się niepowodzeniem na dowolnym kroku, zatrzymaj potok i zwróć ustrukturyzowany błąd. Nie kontynuuj archiwizacji z niezgodnym dokumentem.
SealDoc jako potok dokumentów
SealDoc API implementuje pełny opisany powyżej łańcuch jako pojedynczy punkt końcowy. Przesyłasz dokument źródłowy (DOCX, HTML lub istniejący PDF) wraz z ustrukturyzowanymi metadanymi (dane faktury, informacje o stronach, kategoria retencji). API uruchamia konwersję, walidację PDF/A-3, osadzanie XML, podpisywanie, opatrywanie sygnaturą i archiwizację, zwracając paczkę dowodową w przypadku sukcesu lub ustrukturyzowany błąd walidacji w przypadku niepowodzenia.
Każdy krok w potoku jest zaimplementowany tak, aby szybko kończyć się niepowodzeniem: jeśli VeraPDF zwróci błąd zgodności, potok zatrzymuje się i zwraca konkretną klauzulę, która została naruszona, zamiast kontynuować kolejny krok z niezgodnym dokumentem. Paczka dowodowa jest generowana tylko wtedy, gdy wszystkie kroki walidacji zakończyły się pomyślnie.
Dla organizacji wymagających integracji archiwizacji dokumentów z istniejącymi przepływami API przyjmuje webhooki powiadamiające o zakończeniu lub niepowodzeniu, a paczka dowodowa jest możliwa do pobrania jako ZIP zawierający wszystkie składowe w otwartych, niezależnie weryfikowalnych formatach.