рахунків ZUGFeRD: API для production-систем
Генерація рахунків ZUGFeRD зі структурованих backend-даних без браузера: gPdf відповідає за PDF-рендеринг, бізнес-правила залишаються у вашій системі.
/api/v1/e-invoice/render Генерація рахунків ZUGFeRD як відтворюваного PDF зі структурованих даних. gPdf створює документ; ваша система відповідає за зміст даних і стан процесу.
Коли використовувати цю API
- Backend уже містить дані для рахунків ZUGFeRD і потрібна стабільна PDF-відповідь.
- Потрібно уникнути Chromium або HTML-to-PDF в операційному документі.
- Потрібен повторюваний результат для передруку, аудиту або пакетної обробки.
Що вона не замінює
- gPdf не купує доставку, не подає податки, не створює зовнішні замовлення і не є фіскальною системою.
- gPdf не замінює бізнес-логіку, перевірку даних та інтеграції з marketplace.
Який endpoint викликати
/api/v1/e-invoice/render
E-Invoice Render — типовий шлях для цього сценарію.
/api/v1/e-invoice/capabilities
Використовуйте, коли сценарію потрібен пов’язаний API-шлях, контракт шаблону або перевірка можливостей.
Мінімальний request
/api/v1/e-invoice/render - рахунків 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" }
}
]
}
]
}
Що виконує gPdf
- PDF-рендеринг для рахунків ZUGFeRD зі структурованого request.
- Текст, таблиці, лінії, штрихкоди, сторінки, метадані та параметри виводу згідно з request.
- Детермінований вивід для retries, передруку й аудиту.
Що контролює ваша система
- Коректні дані для рахунків ZUGFeRD, бізнес-правила і стан операції.
- Автентифікація, зберігання, зовнішні workflow і приймальні перевірки.
Production checklist
- Перевірте на реальних даних і в системах, які прийматимуть PDF.
- Зберігайте request ID і докази перевірки для підтримки, аудиту та передруку.
- Переведіть затверджений layout у template, якщо ним користуються кілька систем.
Межі заявлених можливостей
- gPdf використовує публічний e-invoice endpoint для Factur-X / ZUGFeRD PDF/A-3b.
- Податкові портали, PDP, SDI, KSeF, ZATCA, IRP, Peppol і юридичні обов’язки поза scope.
- Ваша система відповідає за buyer data, податкову логіку, routing і локальну юридичну оцінку.
Форма API
API: рахунків ZUGFeRD — production workflow на публічних API gPdf. Request описує дані, layout, settings і PDF-частини для рендерингу. gPdf створює PDF, а ваша система зберігає зміст бізнес-події.
Вибір endpoint
Для цього сценарію endpoint за замовчуванням — /api/v1/e-invoice/render. Template Render використовуйте після затвердження layout. E-Invoice Render використовуйте лише для Factur-X / ZUGFeRD PDF/A-3b із вбудованим EN 16931 CII XML.
Перевірка перед production
Перевіряйте рахунків ZUGFeRD на реальних даних і в downstream-системах. Зберігайте request ID, PDF і результати перевірок для підтримки, аудиту та передруку.
FAQ
- Це окремий endpoint?
- API: рахунків ZUGFeRD використовує публічний e-invoice endpoint, коли потрібен Factur-X / ZUGFeRD PDF/A-3b. Це не окрема продуктова поверхня.
- Чи покриває це локальні clearance-мережі?
- Ні. gPdf рендерить і пакує PDF/e-invoice; податкові портали та юридичний routing залишаються у вашій системі.
- Чи можна продовжувати використовувати JSON Render?
- Так, для звичайних PDF. E-Invoice Render потрібен лише для структурованого e-invoice пакета з публічної API.