API PDF/A do archiwalnego generowania PDF
Generuj pliki PDF/A z żądań JSON Render dla procesów archiwizacji, z jasną granicą między profilami PDF/A a pakowaniem e-faktur.
/api/v1/pdf/render Generuj wynik w profilu PDF/A ze strukturalnych żądań dokumentu, gdy proces biznesowy potrzebuje plików PDF przyjaznych archiwizacji, a E-Invoice Render wybieraj tylko wtedy, gdy wymagane jest pakowanie faktury z osadzonym XML.
Kiedy użyć tej API
- Twój proces wymaga profilu PDF/A wybranego w ustawieniach renderowania.
- Potrzebujesz archiwalnych faktur, zestawień, raportów albo innych dokumentów.
- Potrzebujesz ogólnej strony PDF/A, szerszej niż pakowanie e-faktur w PDF/A-3b.
- Możesz sprawdzić wygenerowany plik w swoim procesie akceptacji archiwalnej.
Czego nie zastępuje
- Potrzebujesz Factur-X albo ZUGFeRD z osadzonym XML CII EN 16931. Użyj E-Invoice Render.
- Potrzebujesz wyłącznie procesu sprawdzania poprawności. Użyj stron walidatora jako kontekstu.
- Potrzebujesz szyfrowanego wyjścia i PDF/A w tym samym żądaniu. Publiczne Render API traktuje ustawienia zabezpieczeń i profilu PDF/A jako wzajemnie wykluczające się.
Który endpoint wywołać
/api/v1/pdf/render
JSON Render to domyślna ścieżka dla tego procesu.
/api/v1/e-invoice/render
Użyj, gdy proces wymaga powiązanej ścieżki API, kontraktu szablonu albo sprawdzenia capabilities.
Minimalny request
POST /api/v1/pdf/render - zwykłe ustawienie wyjścia PDF/A.
{
"settings": {
"profile": "pdfa-2b"
},
"pages": [
{
"size": "a4",
"elements": [
{
"type": "text",
"x": 20,
"y": 24,
"content": "Archive-ready document",
"style": { "font_size": 16, "font_family": "NotoSans-Regular" }
}
]
}
]
}
Co obsługuje gPdf
- Ustawienia profilu PDF/A w żądaniach JSON Render.
- Renderowanie dokumentów z tekstem, tabelami, obrazami, kodami kreskowymi, metadanymi i wyjściem profilowym.
- Pakowanie e-faktur PDF/A-3b tylko przez ścieżkę E-Invoice Render.
- Binarną odpowiedź PDF ze wspólnym zachowaniem błędów.
Co kontroluje Twój system
- Politykę archiwizacji, wybór profilu, proces walidacji, retencję i akceptację prawną.
- Semantykę dokumentu, dane biznesowe i wszelkie wymagane dowody zewnętrzne.
- Przechowywanie, kontrolę dostępu i przyszłą politykę migracji.
Checklist produkcyjny
- Wybierz profil PDF/A wymagany przez Twoje archiwum albo klienta.
- Przepuść wynik przez swój walidator i proces akceptacji retencji.
- Trzymaj ustawienia PDF/A i zabezpieczeń w oddzielnych ścieżkach renderowania, dopóki publiczna dokumentacja nie doda zgodnego kontraktu.
- Użyj E-Invoice Render, gdy wymagany jest osadzony XML CII.
- Przechowuj dane źródłowe albo zwrócony PDF zgodnie z polityką retencji.
Granice deklaracji
- Wyjście PDF/A nie jest tym samym co prawne pakowanie e-faktury.
- gPdf nie zastępuje Twojego procesu akceptacji archiwalnej ani procesu walidacji.
- Twój system odpowiada za retencję i interpretację wymagań.
PDF/A to wybór profilu
Dla zwykłych dokumentów archiwalnych PDF/A wybiera się w ustawieniach renderowania. Dzięki temu proces pozostaje blisko JSON Render: Twój system opisuje dokument i ustawia potrzebny profil.
Pakowanie e-faktur jest innym przypadkiem. Gdy dokument wymaga Factur-X albo ZUGFeRD z osadzonym XML CII, użyj endpointu E-Invoice Render.
FAQ
- Którego endpointu użyć do ogólnego wyjścia PDF/A?
- Do zwykłego wyjścia PDF/A użyj POST /api/v1/pdf/render z odpowiednią wartością settings.profile.
- Kiedy potrzebuję E-Invoice Render?
- Użyj E-Invoice Render, gdy dokument musi być pakietem Factur-X albo ZUGFeRD PDF/A-3b z osadzonym XML CII.
- Czy gPdf waliduje akceptację archiwalną?
- Nie. gPdf renderuje wyjście PDF/A. Twój system powinien sprawdzić wynik względem polityki akceptacji archiwum albo klienta.
- Czy PDF/A można połączyć z ustawieniami zabezpieczeń?
- Nie w obecnym publicznym Render API. settings.profile i settings.security wzajemnie się wykluczają, a nieprawidłowe kombinacje kończą się błędem walidacji.