API Factur-X para facturas electrónicas híbridas PDF/A-3b
Genere facturas Factur-X PDF/A-3b con XML CII EN 16931 incrustado mediante el endpoint público E-Invoice Render.
/api/v1/e-invoice/render Empaquetar una factura PDF renderizada como Factur-X PDF/A-3b con XML CII EN 16931 incrustado después de que su ERP o sistema de facturación haya producido los datos estructurados correctos de la factura.
Cuándo usar esta API
- Necesita salida Factur-X nativa desde el endpoint público E-Invoice Render.
- Su sistema ya tiene XML CII EN 16931 válido para la factura.
- Necesita empaquetado PDF/A-3b con metadatos Factur-X y cableado de archivo asociado.
- Quiere que el endpoint de capacidades confirme el contrato de factura electrónica publicado actualmente.
Qué no sustituye
- Necesita que gPdf cree semántica empresarial de factura o decisiones fiscales por usted.
- Necesita salida nativa XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e u otros estándares no listados en OpenAPI.
- Necesita envío directo a Chorus Pro u otro portal gubernamental.
Qué endpoint llamar
/api/v1/e-invoice/render
E-Invoice Render es la ruta predeterminada para este flujo.
/api/v1/e-invoice/capabilities
Úsalo cuando el flujo necesite la ruta API relacionada, un contrato de plantilla o una consulta de capacidades.
Solicitud mínima
POST /api/v1/e-invoice/render - forma mínima de un paquete 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" }
}
]
}
]
}
Qué gestiona gPdf
- Empaquetado Factur-X mediante E-Invoice Render.
- Manejo del perfil PDF/A-3b para la factura PDF híbrida.
- Incrustación de XML CII como archivo asociado con metadatos del estándar.
- Entrega PDF inline o comportamiento de trabajo con entrega por objeto según la documentación.
Qué controla su sistema
- XML CII EN 16931 correcto, números de factura, lógica fiscal, datos de comprador y vendedor, y elegibilidad.
- Validación externa, reglas del destinatario, envío a portales e interpretación legal.
- Almacenamiento, trazabilidad de auditoría, lógica de reintento y entrega al cliente o portal.
Checklist de producción
- Valide el XML CII antes de enviarlo a gPdf.
- Defina settings.profile como pdfa-3b u omítalo para que se aplique el valor por defecto de factura electrónica.
- Use settings.e_invoice.standard = factur_x y settings.e_invoice.profile = en16931.
- Pase el PDF devuelto por su flujo de validación Factur-X.
- Mantenga el envío y enrutamiento del destinatario fuera de la API de renderizado.
Límites de la promesa
- La salida pública nativa de factura electrónica es Factur-X o ZUGFeRD con XML CII EN 16931.
- gPdf no envía facturas a portales gubernamentales ni de compradores.
- Su sistema conserva la corrección empresarial, fiscal y XML.
Factur-X es un flujo de empaquetado de factura electrónica
Factur-X combina un PDF legible por humanos con XML CII EN 16931 legible por máquina. El endpoint público de gPdf empaqueta esa combinación en salida PDF/A-3b. No decide la semántica de la factura ni envía el archivo a un portal.
FAQ
- ¿Qué endpoint renderiza Factur-X?
- Use POST /api/v1/e-invoice/render con settings.e_invoice.standard establecido en factur_x.
- ¿gPdf genera el XML EN 16931?
- Su sistema proporciona el XML CII y controla su corrección empresarial. gPdf lo empaqueta dentro del PDF híbrido.
- ¿Esta página cubre XRechnung?
- No. Esta página se limita al contrato público Factur-X listado en OpenAPI.
- ¿gPdf envía facturas Factur-X a portales?
- No. El envío y el enrutamiento del destinatario quedan fuera de la API de renderizado.