PDF/A-3b всегда означает e-invoice?

Нет. PDF/A-3b — archival PDF profile. Factur-X и ZUGFeRD e-invoices используют PDF/A-3b как wrapper для embedded EN 16931 XML.

Какой endpoint создает PDF/A-3b?

Для ordinary PDF/A-3b используйте POST /api/v1/pdf/render с settings.profile. Когда output должен быть Factur-X или ZUGFeRD e-invoice, используйте POST /api/v1/e-invoice/render.

Можно ли прикреплять arbitrary files через эту страницу?

Не предполагайте поддержку arbitrary attachments, если public API docs не перечисляют такой workflow. Эта страница сфокусирована на documented PDF/A-3b и e-invoice use.

Как проверить PDF/A output?

Используйте /validator/ или свой reference-engine pipeline. Для e-invoices проверяйте и PDF/A layer, и embedded XML layer.

Compliance и архивирование

PDF/A-3b API для archival и e-invoice workflows

Генерируйте PDF/A-3b output с gPdf и разделяйте случаи, где PDF/A-3b — только archival profile, а где он является e-invoice wrapper.

ОСНОВНАЯ API JSON Render

ENDPOINT /api/v1/pdf/render

СИСТЕМЫ compliance backend / finance system / legal archive / audit workflow

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

Задача сценария

Генерировать PDF/A-3b documents для archival workflows и выбирать e-invoice endpoint, когда PDF/A-3b должен нести embedded Factur-X или ZUGFeRD EN 16931 XML.

Когда использовать эту API

Нужен PDF/A-3b archival profile для rendered document.
Нужно объяснить границу между ordinary PDF/A и e-invoice packaging.
Ваш compliance workflow валидирует generated PDFs через veraPDF или другой reference engine.
Нужна public page, которая направляет PDF/A-3b search intent к правильному endpoint.

Что она не заменяет

Нужны arbitrary file-attachment workflows, не задокументированные в public API.
Нужны Factur-X или ZUGFeRD e-invoices через JSON Render. Используйте E-Invoice Render.
Нужен validator API. Текущая публичная validator surface — страница /validator/.

Какой endpoint вызывать

ОСНОВНОЙ

/api/v1/pdf/render

JSON Render — путь по умолчанию для этого сценария.

ДОПОЛНИТЕЛЬНЫЙ 1

/api/v1/e-invoice/render

Используйте, когда сценарию нужен связанный API-путь, контракт шаблона или проверка возможностей.

Минимальный запрос

POST /api/v1/pdf/render - запросить PDF/A-3b output для rendered document.

{
  "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 selection через JSON Render settings.
PDF/A-3b e-invoice packaging при использовании POST /api/v1/e-invoice/render.
Renderable PDF output, пригодный для external reference-engine validation.
Ясное разделение между archival profile и legal e-invoice workflow.

Что контролирует ваша система

Retention policy и причину, по которой требуется PDF/A-3b.
Любые business data, XML semantics и external compliance acceptance criteria.
Validation evidence, audit records и long-term storage после rendering.

Production-чеклист

Выбирайте JSON Render для ordinary PDF/A-3b output.
Выбирайте E-Invoice Render, когда требуется embedded EN 16931 XML.
Валидируйте PDF/A output через /validator/ или ваш veraPDF workflow.
Записывайте requested profile и request ID вместе со stored document.
Не заявляйте поддержку arbitrary attachments, если public docs ее не перечисляют.

Границы заявлений

PDF/A-3b — archival profile; e-invoice packaging — более узкий workflow поверх него.
Не подразумевайте поддержку каждого arbitrary embedded-file workflow.
Для Factur-X и ZUGFeRD PDF/A-3b packages требуется e-invoice route.

PDF/A-3b — wrapper, но не весь workflow

PDF/A-3b — archival PDF profile. Он важен потому, что может быть wrapper для hybrid e-invoices, но сам profile не делает документ legal e-invoice. Ordinary archived document может использовать PDF/A-3b без embedded invoice XML.

Для Factur-X и ZUGFeRD используйте POST /api/v1/e-invoice/render. Этот endpoint отвечает за e-invoice-specific metadata и associated-file wiring.

Выбирайте endpoint по intent

Используйте JSON Render, когда цель — “render this document as PDF/A-3b”. Используйте E-Invoice Render, когда цель — “package this invoice as Factur-X or ZUGFeRD with EN 16931 CII XML”. Это разделение сохраняет код понятным и не дает ordinary archival jobs случайно получить e-invoice assumptions.

Валидируйте externally

PDF/A следует проверять reference engine, а не marketing claim. Используйте public validator или собственный validation pipeline и храните report вместе с audit evidence.

FAQ

PDF/A-3b всегда означает e-invoice?: Нет. PDF/A-3b — archival PDF profile. Factur-X и ZUGFeRD e-invoices используют PDF/A-3b как wrapper для embedded EN 16931 XML.
Какой endpoint создает PDF/A-3b?: Для ordinary PDF/A-3b используйте POST /api/v1/pdf/render с settings.profile. Когда output должен быть Factur-X или ZUGFeRD e-invoice, используйте POST /api/v1/e-invoice/render.
Можно ли прикреплять arbitrary files через эту страницу?: Не предполагайте поддержку arbitrary attachments, если public API docs не перечисляют такой workflow. Эта страница сфокусирована на documented PDF/A-3b и e-invoice use.
Как проверить PDF/A output?: Используйте /validator/ или свой reference-engine pipeline. Для e-invoices проверяйте и PDF/A layer, и embedded XML layer.