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

Factur-X API для hybrid PDF/A-3b e-invoices

Генерируйте Factur-X PDF/A-3b invoices со встроенным EN 16931 CII XML через публичный E-Invoice Render endpoint.

ОСНОВНАЯ API E-Invoice Render
ENDPOINT /api/v1/e-invoice/render
СИСТЕМЫ ERP / billing backend / compliance workflow / finance automation service
Задача сценария

Упаковать rendered invoice PDF как Factur-X PDF/A-3b со встроенным EN 16931 CII XML после того, как ваша ERP или billing system подготовила корректные structured invoice data.

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

  • Нужен native Factur-X output из публичного E-Invoice Render endpoint.
  • В вашей системе уже есть valid EN 16931 CII XML для invoice.
  • Нужны PDF/A-3b packaging с Factur-X metadata и associated-file wiring.
  • Нужно через capabilities endpoint подтвердить текущий опубликованный e-invoice contract.

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

  • Нужно, чтобы gPdf создавал invoice business semantics или tax decisions за вас.
  • Нужен native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e или другие standards, не перечисленные в OpenAPI.
  • Нужна direct submission в Chorus Pro или другой government portal.

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

ОСНОВНОЙ

/api/v1/e-invoice/render

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

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

/api/v1/e-invoice/capabilities

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

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

POST /api/v1/e-invoice/render - минимальная форма Factur-X package.

{
  "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 packaging через E-Invoice Render.
  • PDF/A-3b profile handling для hybrid invoice PDF.
  • Встраивание CII XML как associated file со standard metadata.
  • Inline PDF delivery или object-delivery job behavior согласно документации.

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

  • Корректный EN 16931 CII XML, invoice numbers, tax logic, buyer and seller data и eligibility.
  • External validation, recipient rules, portal submission и legal interpretation.
  • Storage, audit trail, retry logic и delivery to the customer or portal.

Production-чеклист

  1. Проверяйте CII XML перед отправкой в gPdf.
  2. Установите settings.profile в pdfa-3b или опустите его, чтобы сработал e-invoice default.
  3. Используйте settings.e_invoice.standard = factur_x и settings.e_invoice.profile = en16931.
  4. Прогоняйте возвращенный PDF через ваш Factur-X validator workflow.
  5. Держите submission и recipient routing вне render API.

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

  • Native public e-invoice output — Factur-X или ZUGFeRD с EN 16931 CII XML.
  • gPdf не отправляет invoices в government или buyer portals.
  • Ваша система отвечает за business, tax и XML correctness.

Factur-X — это e-invoice packaging workflow

Factur-X объединяет человекочитаемый PDF и machine-readable EN 16931 CII XML. Публичный endpoint gPdf упаковывает эту комбинацию в PDF/A-3b output. Он не решает invoice semantics и не отправляет файл в portal.

FAQ

Какой endpoint рендерит Factur-X?
Используйте POST /api/v1/e-invoice/render с settings.e_invoice.standard = factur_x.
Создает ли gPdf EN 16931 XML?
Ваша система предоставляет CII XML и отвечает за его business correctness. gPdf упаковывает его в hybrid PDF.
Поддерживает ли gPdf XRechnung на этой странице?
Нет. Эта страница ограничена публичным Factur-X contract, указанным в OpenAPI.
Отправляет ли gPdf Factur-X invoices в portals?
Нет. Submission и recipient routing остаются вне render API.