Zgodność i archiwizacja
API Factur-X dla hybrydowych e-faktur PDF/A-3b
Generuj faktury Factur-X PDF/A-3b z osadzonym XML CII EN 16931 przez publiczny endpoint E-Invoice Render.
GŁÓWNE API E-Invoice Render
ENDPOINT
/api/v1/e-invoice/render SYSTEMY ERP / backend bilingowy / proces obsługi wymagań e-fakturowania / usługa automatyzacji finansów
Zadanie do wykonania
Spakować wyrenderowany PDF faktury jako Factur-X PDF/A-3b z osadzonym XML CII EN 16931 po tym, jak ERP albo system bilingowy przygotuje poprawne strukturalne dane faktury.
Kiedy użyć tej API
- Potrzebujesz natywnego wyjścia Factur-X 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 Factur-X i powiązaniem pliku.
- Chcesz, aby endpoint capabilities potwierdził aktualnie opublikowany kontrakt e-faktury.
Czego nie zastępuje
- Potrzebujesz, aby gPdf tworzył znaczenie biznesowe faktury albo decyzje podatkowe za Ciebie.
- Potrzebujesz natywnego XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e albo innych standardów niewymienionych w OpenAPI.
- Potrzebujesz bezpośredniego wysłania do Chorus Pro albo innego portalu publicznego.
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 Factur-X.
{
"settings": {
"profile": "pdfa-3b",
"e_invoice": {
"standard": "factur_x",
"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": "Factur-X invoice",
"style": { "font_size": 16, "font_family": "NotoSans-Regular" }
}
]
}
]
}
Co obsługuje gPdf
- Pakowanie Factur-X przez E-Invoice Render.
- Obsługę profilu PDF/A-3b dla hybrydowego PDF faktury.
- Osadzanie XML CII jako pliku powiązanego ze standardowymi metadanymi.
- Dostarczenie PDF inline albo zachowanie zadania object-delivery zgodnie z dokumentacją.
Co kontroluje Twój system
- Poprawny XML CII EN 16931, numery faktur, logikę podatkową, dane nabywcy i sprzedawcy oraz kwalifikowalność.
- Zewnętrzną walidację, reguły odbiorcy, wysłanie do portalu i interpretację prawną.
- Przechowywanie, ślad audytowy, logikę ponowień i dostarczenie do klienta albo portalu.
Checklist produkcyjny
- Zweryfikuj XML CII przed wysłaniem go do gPdf.
- Ustaw settings.profile na pdfa-3b albo pomiń je, aby zadziałała domyślna wartość e-faktury.
- Użyj settings.e_invoice.standard = factur_x i settings.e_invoice.profile = en16931.
- Sprawdź zwrócony PDF w swoim procesie walidacji Factur-X.
- Trzymaj wysyłkę i trasowanie do odbiorcy poza API renderowania.
Granice deklaracji
- Natywne publiczne wyjście e-faktury to Factur-X albo ZUGFeRD z XML CII EN 16931.
- gPdf nie wysyła faktur do portali publicznych ani portali nabywców.
- Twój system odpowiada za biznesową, podatkową i XML-ową poprawność danych.
Factur-X jest procesem pakowania e-faktury
Factur-X łączy czytelny dla człowieka PDF z maszynowo czytelnym XML CII EN 16931. Publiczny endpoint gPdf pakuje tę kombinację w wyjście PDF/A-3b. Nie decyduje o semantyce faktury ani nie wysyła pliku do portalu.
FAQ
- Który endpoint renderuje Factur-X?
- Użyj POST /api/v1/e-invoice/render z settings.e_invoice.standard ustawionym na factur_x.
- Czy gPdf generuje XML EN 16931?
- Twój system dostarcza XML CII i odpowiada za jego biznesową poprawność. gPdf pakuje go do hybrydowego PDF.
- Czy ta strona obejmuje XRechnung?
- Nie. Ta strona ogranicza się do publicznego kontraktu Factur-X wymienionego w OpenAPI.
- Czy gPdf wysyła faktury Factur-X do portali?
- Nie. Wysyłka i trasowanie do odbiorcy pozostają poza API renderowania.