Відповідність і архівування
Factur-X API для гібридних електронних рахунків PDF/A-3b
Генеруйте рахунки Factur-X PDF/A-3b із вбудованим EN 16931 CII XML через публічний маршрут API E-Invoice Render.
ОСНОВНА API E-Invoice Render
ШЛЯХ API
/api/v1/e-invoice/render СИСТЕМИ ERP / білінговий бекенд / процес відповідності / сервіс фінансової автоматизації
Задача сценарію
Запакувати відрендерений PDF рахунку як Factur-X PDF/A-3b із вбудованим EN 16931 CII XML після того, як ваша ERP або білінгова система створила коректні структуровані дані рахунку.
Коли використовувати цю API
- Потрібен нативний вивід Factur-X із публічного маршруту API E-Invoice Render.
- У вашій системі вже є валідний EN 16931 CII XML для рахунку.
- Потрібне пакування PDF/A-3b з метаданими Factur-X і прив’язкою associated file.
- Потрібно, щоб маршрут API capabilities підтвердив поточний опублікований контракт e-invoice.
Що вона не замінює
- Потрібно, щоб gPdf створював бізнес-семантику рахунку або податкові рішення за вас.
- Потрібен нативний XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e або інші стандарти, не перелічені в OpenAPI.
- Потрібне пряме подання до Chorus Pro або іншого державного порталу.
Який шлях API викликати
/api/v1/e-invoice/render
E-Invoice Render — типовий шлях для цього сценарію.
/api/v1/e-invoice/capabilities
Використовуйте, коли сценарію потрібен пов’язаний API-шлях, контракт шаблону або перевірка можливостей.
Мінімальний запит
POST /api/v1/e-invoice/render - мінімальна форма пакета 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" }
}
]
}
]
}
Що виконує gPdf
- Пакування Factur-X через E-Invoice Render.
- Обробку PDF/A-3b profile для hybrid invoice PDF.
- Вбудовування CII XML як associated file зі standard metadata.
- Inline PDF delivery або object-delivery job behavior відповідно до документації.
Що контролює ваша система
- Коректний EN 16931 CII XML, номери рахунків, податкову логіку, дані покупця й продавця та eligibility.
- Зовнішню валідацію, правила отримувача, подання на портал і юридичне тлумачення.
- Зберігання, аудиторський слід, логіку повторних спроб і доставку клієнту або на портал.
Чеклист для робочого запуску
- Валідуйте CII XML перед надсиланням у gPdf.
- Встановіть settings.profile = pdfa-3b або пропустіть його, щоб застосувався e-invoice default.
- Використовуйте settings.e_invoice.standard = factur_x і settings.e_invoice.profile = en16931.
- Пропустіть повернений PDF через ваш процес валідації Factur-X.
- Тримайте подання і маршрутизацію до отримувача поза render API.
Межі заявлених можливостей
- Нативний публічний e-invoice output — Factur-X або ZUGFeRD з EN 16931 CII XML.
- gPdf не подає рахунки до державних порталів або порталів покупців.
- Ваша система відповідає за бізнес-дані, податки й коректність XML.
Factur-X — це процес пакування електронного рахунку
Factur-X поєднує читабельний для людини PDF із machine-readable EN 16931 CII XML. Публічний маршрут API gPdf пакує цю комбінацію у PDF/A-3b-вивід. Він не вирішує семантику рахунку і не подає файл до порталу.
FAQ
- Який маршрут API рендерить Factur-X?
- Використовуйте POST /api/v1/e-invoice/render із settings.e_invoice.standard = factur_x.
- Чи генерує gPdf EN 16931 XML?
- Ваша система надає CII XML і відповідає за його бізнес-коректність. gPdf пакує його в hybrid PDF.
- Чи підтримує gPdf XRechnung на цій сторінці?
- Ні. Ця сторінка обмежена публічним контрактом Factur-X, переліченим в OpenAPI.
- Чи подає gPdf рахунки Factur-X до порталів?
- Ні. Submission і recipient routing залишаються поза render API.