Zgodność i archiwizacja
API ZUGFeRD dla hybrydowych faktur PDF/A-3b
Generuj faktury ZUGFeRD PDF/A-3b z osadzonym XML CII EN 16931 przez publiczny endpoint gPdf E-Invoice Render.
GŁÓWNE API E-Invoice Render
ENDPOINT
/api/v1/e-invoice/render SYSTEMY ERP / backend bilingowy / niemiecki proces finansowy / usługa automatyzacji wymagań e-fakturowania
Zadanie do wykonania
Spakować wyjście PDF faktury jako ZUGFeRD PDF/A-3b z osadzonym XML CII EN 16931 po tym, jak ERP albo system bilingowy przygotuje poprawne dane faktury.
Kiedy użyć tej API
- Potrzebujesz natywnego wyjścia ZUGFeRD z publicznego endpointu E-Invoice Render.
- Twój system ma już poprawny XML CII EN 16931 dla faktury.
- Potrzebujesz pakowania PDF/A-3b z metadanymi ZUGFeRD i powiązaniem pliku.
- Potrzebujesz czytelnej strony siostrzanej dla szerszych stron e-faktur i Factur-X.
Czego nie zastępuje
- Potrzebujesz natywnego generowania XRechnung albo wysyłki do portalu.
- Potrzebujesz, aby gPdf liczył podatki, wyprowadzał semantykę faktury albo tworzył XML z zapisów księgowych.
- Potrzebujesz standardów niewymienionych w publicznym kontrakcie OpenAPI.
Który endpoint wywołać
/api/v1/e-invoice/render
E-Invoice Render to domyślna ścieżka dla tego procesu.
/api/v1/e-invoice/capabilities
Użyj, gdy proces wymaga powiązanej ścieżki API, kontraktu szablonu albo sprawdzenia capabilities.
Minimalny request
POST /api/v1/e-invoice/render - minimalny kształt pakietu ZUGFeRD.
{
"settings": {
"profile": "pdfa-3b",
"e_invoice": {
"standard": "zugferd",
"profile": "en16931",
"document_type": "invoice",
"xml": {
"format": "cii",
"encoding": "utf8",
"content": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
}
}
},
"pages": [
{
"size": "a4",
"elements": [
{
"type": "text",
"x": 20,
"y": 24,
"content": "ZUGFeRD invoice",
"style": { "font_size": 16, "font_family": "NotoSans-Regular" }
}
]
}
]
}
Co obsługuje gPdf
- Pakowanie ZUGFeRD przez E-Invoice Render.
- Obsługę profilu PDF/A-3b dla hybrydowego wyjścia faktury.
- Osadzanie XML CII jako pliku powiązanego z metadanymi ZUGFeRD.
- Dostarczenie PDF inline albo object delivery zgodnie z dokumentacją.
Co kontroluje Twój system
- Poprawność XML CII EN 16931, dane faktury, logikę podatkową oraz semantykę nabywcy i sprzedawcy.
- Zewnętrzną walidację, wymagania odbiorcy, wysłanie do portalu i interpretację prawną.
- Zachowanie ponowień, przechowywanie, dowody audytowe i dostarczenie do klienta.
Checklist produkcyjny
- Ustaw settings.e_invoice.standard = zugferd i settings.e_invoice.profile = en16931.
- Użyj XML CII z format = cii i encoding = utf8.
- Ustaw settings.profile na pdfa-3b albo pomiń je, aby zadziałała domyślna wartość e-faktury.
- Zweryfikuj zwrócony PDF w swoim procesie walidacji ZUGFeRD.
- Trzymaj XRechnung albo wysyłkę do portalu poza tym endpointem.
Granice deklaracji
- Ta strona obejmuje wyjście ZUGFeRD przez E-Invoice Render.
- Nie deklaruje natywnego generowania XRechnung.
- Twój system odpowiada za dane biznesowe faktury i ważność XML.
ZUGFeRD używa ścieżki E-Invoice Render
ZUGFeRD nie jest osobnym endpointem głównym. Wybiera się go przez pole
settings.e_invoice.standard w POST /api/v1/e-invoice/render. Obowiązuje ta
sama granica: gPdf pakuje hybrydową fakturę PDF/A-3b, a Twój system odpowiada
za fakty na fakturze i ważność XML.
FAQ
- Który endpoint renderuje ZUGFeRD?
- Użyj POST /api/v1/e-invoice/render z settings.e_invoice.standard ustawionym na zugferd.
- Czy ta strona obejmuje XRechnung?
- Nie. Ta strona ogranicza się do publicznego kontraktu ZUGFeRD. XRechnung nie jest tu deklarowany jako natywne wyjście.
- Czy gPdf tworzy XML CII?
- Twój system dostarcza XML CII EN 16931 i odpowiada za jego poprawność.
- Czy mogę zweryfikować wynik?
- Użyj swojego procesu walidacji ZUGFeRD oraz stron walidatora gPdf jako kontekstu walidacyjnego.