Compliance e archiviazione
API Factur-X per fatture elettroniche ibride PDF/A-3b
Genera fatture Factur-X PDF/A-3b con XML CII EN 16931 incorporato tramite l'endpoint pubblico E-Invoice Render.
API PRINCIPALE E-Invoice Render
ENDPOINT
/api/v1/e-invoice/render SISTEMI ERP / backend di fatturazione / processo di conformità / servizio di automazione finance
Lavoro da svolgere
Confezionare una fattura PDF renderizzata come Factur-X PDF/A-3b con XML CII EN 16931 incorporato dopo che il vostro ERP o sistema di fatturazione ha prodotto i dati strutturati corretti della fattura.
Quando usare questa API
- Vi serve output Factur-X nativo dall'endpoint pubblico E-Invoice Render.
- Il vostro sistema possiede già XML CII EN 16931 valido per la fattura.
- Vi serve packaging PDF/A-3b con metadati Factur-X e cablaggio del file associato.
- Volete che l'endpoint delle capacità confermi il contratto e-invoice attualmente pubblicato.
Cosa non sostituisce
- Vi serve che gPdf crei semantica di business della fattura o decisioni fiscali al posto vostro.
- Vi servono XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e o altri standard nativi non elencati in OpenAPI.
- Vi serve invio diretto a Chorus Pro o a un altro portale governativo.
Quale endpoint chiamare
/api/v1/e-invoice/render
E-Invoice Render è il percorso predefinito per questo flusso.
/api/v1/e-invoice/capabilities
Usalo quando il flusso richiede l'API collegata, un contratto di template o una verifica delle capacità.
Request minimo
POST /api/v1/e-invoice/render - forma minima del pacchetto 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" }
}
]
}
]
}
Cosa gestisce gPdf
- Packaging Factur-X tramite E-Invoice Render.
- Gestione del profilo PDF/A-3b per la fattura PDF ibrida.
- Incorporamento dell'XML CII come file associato con metadati standard.
- Consegna PDF inline o comportamento di job con object delivery come documentato.
Cosa controlla il tuo sistema
- XML CII EN 16931 corretto, numeri fattura, logica fiscale, dati acquirente e venditore e idoneità.
- Validazione esterna, regole del destinatario, invio a portali e interpretazione legale.
- Conservazione, audit trail, logica di retry e consegna al cliente o al portale.
Checklist di produzione
- Validate l'XML CII prima di inviarlo a gPdf.
- Impostate settings.profile su pdfa-3b oppure omettetelo per usare il default e-invoice.
- Usate settings.e_invoice.standard = factur_x e settings.e_invoice.profile = en16931.
- Passate il PDF restituito nel vostro processo di validazione Factur-X.
- Tenete invio e instradamento destinatario fuori dall'API di rendering.
Limiti della promessa
- L'output pubblico nativo per e-invoice è Factur-X o ZUGFeRD con XML CII EN 16931.
- gPdf non invia fatture a portali governativi o buyer portal.
- Il vostro sistema possiede correttezza business, fiscale e XML.
Factur-X è un processo di packaging e-invoice
Factur-X combina un PDF leggibile da persone con XML CII EN 16931 leggibile da macchina. L’endpoint pubblico gPdf confeziona questa combinazione in output PDF/A-3b. Non decide la semantica della fattura e non invia il file a un portale.
FAQ
- Quale endpoint renderizza Factur-X?
- Usate POST /api/v1/e-invoice/render con settings.e_invoice.standard impostato su factur_x.
- gPdf genera l'XML EN 16931?
- Il vostro sistema fornisce l'XML CII e ne possiede la correttezza business. gPdf lo confeziona nel PDF ibrido.
- gPdf supporta XRechnung in questa pagina?
- No. Questa pagina è limitata al contratto pubblico Factur-X elencato in OpenAPI.
- gPdf invia fatture Factur-X ai portali?
- No. Invio e instradamento verso destinatari restano fuori dall'API di rendering.