PDF/A-3b завжди означає електронний рахунок?

Ні. PDF/A-3b — це архівний PDF profile. Електронні рахунки Factur-X і ZUGFeRD використовують PDF/A-3b як оболонку для вбудованого EN 16931 XML.

Який маршрут API створює PDF/A-3b?

Для звичайного PDF/A-3b використовуйте POST /api/v1/pdf/render із settings.profile. Використовуйте POST /api/v1/e-invoice/render, коли вивід має бути електронним рахунком Factur-X або ZUGFeRD.

Чи можу я прикріплювати довільні файли через цю сторінку?

Не припускайте підтримку довільних attachments, якщо публічна API-документація не перелічує такий процес. Ця сторінка фокусується на задокументованому PDF/A-3b і e-invoice use.

Як перевірити PDF/A-вивід?

Використовуйте /validator/ або власний reference-engine pipeline. Для електронних рахунків перевіряйте і шар PDF/A, і вбудований XML-шар.

Відповідність і архівування

PDF/A-3b API для архівних процесів і електронних рахунків

Генеруйте PDF/A-3b-вивід з gPdf і розумійте, коли PDF/A-3b є лише архівним профілем, а коли — оболонкою електронного рахунку.

ОСНОВНА API JSON Render

ШЛЯХ API /api/v1/pdf/render

СИСТЕМИ compliance-бекенд / фінансова система / юридичний архів / аудиторський процес

Спробувати в Playground Читати документацію

Задача сценарію

Генерувати документи PDF/A-3b для архівних процесів і обирати маршрут API електронного рахунку, коли PDF/A-3b має нести вбудований Factur-X або ZUGFeRD EN 16931 XML.

Коли використовувати цю API

Потрібен архівний profile PDF/A-3b для відрендереного документа.
Потрібно пояснити межу між звичайним PDF/A і пакуванням електронного рахунку.
Ваш процес відповідності валідує згенеровані PDF через veraPDF або інший reference engine.
Потрібна публічна сторінка, яка скеровує PDF/A-3b search intent до правильного маршруту API.

Що вона не замінює

Потрібні довільні процеси вкладень, не задокументовані в публічному API.
Потрібні Factur-X або ZUGFeRD електронні рахунки через JSON Render. Використовуйте E-Invoice Render.
Потрібен validator API. Поточна публічна validator surface — сторінка /validator/.

Який шлях API викликати

ОСНОВНИЙ

/api/v1/pdf/render

JSON Render — типовий шлях для цього сценарію.

ДОДАТКОВИЙ 1

/api/v1/e-invoice/render

Використовуйте, коли сценарію потрібен пов’язаний API-шлях, контракт шаблону або перевірка можливостей.

Мінімальний запит

POST /api/v1/pdf/render - запитати PDF/A-3b-вивід для відрендереного документа.

{
  "settings": {
    "profile": "pdfa-3b"
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Archive copy",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

Що виконує gPdf

Вибір PDF/A profile через налаштування JSON Render.
Пакування PDF/A-3b електронного рахунку під час використання POST /api/v1/e-invoice/render.
PDF-вивід, який можна валідувати зовнішнім reference engine.
Чіткий поділ між архівним profile і юридичним e-invoice процесом.

Що контролює ваша система

Retention policy і причину, чому потрібен PDF/A-3b.
Будь-які бізнес-дані, XML-семантику й зовнішні критерії прийняття відповідності.
Validation evidence, audit records і long-term storage після рендерингу.

Чеклист для робочого запуску

Оберіть JSON Render для звичайного PDF/A-3b-виводу.
Оберіть E-Invoice Render, коли потрібен вбудований EN 16931 XML.
Валідуйте PDF/A-вивід через /validator/ або власний veraPDF процес.
Записуйте запитаний profile і request ID разом зі збереженим документом.
Не заявляйте підтримку довільних attachments, якщо публічна документація її не перелічує.

Межі заявлених можливостей

PDF/A-3b — архівний profile; пакування електронного рахунку є вужчим процесом поверх нього.
Не натякайте, що підтримується кожен довільний embedded-file процес.
Для пакетів Factur-X і ZUGFeRD PDF/A-3b потрібен e-invoice route.

PDF/A-3b — це оболонка, а не весь процес

PDF/A-3b — архівний PDF profile. Він важливий, бо може бути оболонкою для hybrid e-invoices, але сам profile не робить документ юридичним електронним рахунком. Звичайний архівний документ може використовувати PDF/A-3b без вбудованого invoice XML.

Для Factur-X і ZUGFeRD використовуйте POST /api/v1/e-invoice/render. Цей маршрут API відповідає за e-invoice-specific metadata і wiring associated file.

Обирайте маршрут API за наміром

Використовуйте JSON Render, коли ваша мета — “відрендерити цей документ як PDF/A-3b”. Використовуйте E-Invoice Render, коли ваша мета — “запакувати цей рахунок як Factur-X або ZUGFeRD з EN 16931 CII XML”. Це розмежування тримає код зрозумілим і не дає звичайним архівним задачам випадково нести припущення електронних рахунків.

Валідуйте зовнішньо

PDF/A потрібно перевіряти reference engine, а не маркетинговою заявою. Використовуйте публічний validator або власний validation pipeline і зберігайте звіт разом з аудиторськими доказами.

FAQ

PDF/A-3b завжди означає електронний рахунок?: Ні. PDF/A-3b — це архівний PDF profile. Електронні рахунки Factur-X і ZUGFeRD використовують PDF/A-3b як оболонку для вбудованого EN 16931 XML.
Який маршрут API створює PDF/A-3b?: Для звичайного PDF/A-3b використовуйте POST /api/v1/pdf/render із settings.profile. Використовуйте POST /api/v1/e-invoice/render, коли вивід має бути електронним рахунком Factur-X або ZUGFeRD.
Чи можу я прикріплювати довільні файли через цю сторінку?: Не припускайте підтримку довільних attachments, якщо публічна API-документація не перелічує такий процес. Ця сторінка фокусується на задокументованому PDF/A-3b і e-invoice use.
Як перевірити PDF/A-вивід?: Використовуйте /validator/ або власний reference-engine pipeline. Для електронних рахунків перевіряйте і шар PDF/A, і вбудований XML-шар.