Compliance and archival

счетов Factur-X: API для production-систем

Генерация счетов Factur-X из структурированных backend-данных без браузера: gPdf отвечает за PDF-рендеринг, бизнес-правила остаются в вашей системе.

ОСНОВНАЯ API E-Invoice Render
ENDPOINT /api/v1/e-invoice/render
СИСТЕМЫ операционный backend / финансовая система / workflow compliance / сервис документов
Задача сценария

Генерация счетов Factur-X как воспроизводимого PDF из структурированных данных. gPdf создает документ; ваша система отвечает за смысл данных и состояние процесса.

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

  • Backend уже содержит данные для счетов Factur-X и нужен стабильный PDF-ответ.
  • Нужно избежать Chromium или HTML-to-PDF в операционном документе.
  • Нужен повторяемый результат для перепечатки, аудита или пакетной обработки.

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

  • gPdf не покупает доставку, не подает налоги, не создает внешние заказы и не является фискальной системой.
  • gPdf не заменяет бизнес-логику, проверку данных и интеграции с marketplace.

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

ОСНОВНОЙ

/api/v1/e-invoice/render

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

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

/api/v1/e-invoice/capabilities

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

Минимальный request

/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

  • PDF-рендеринг для счетов Factur-X из структурированного request.
  • Текст, таблицы, линии, штрихкоды, страницы, метаданные и параметры вывода согласно request.
  • Детерминированный вывод для retries, перепечатки и аудита.

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

  • Корректные данные для счетов Factur-X, бизнес-правила и состояние операции.
  • Аутентификация, хранение, внешние workflow и приемочные проверки.

Production checklist

  1. Проверьте на реальных данных и в системах, которые будут принимать PDF.
  2. Сохраняйте request ID и доказательства проверки для поддержки, аудита и перепечатки.
  3. Переведите утвержденный layout в template, если им пользуются несколько систем.

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

  • gPdf использует публичный e-invoice endpoint для Factur-X / ZUGFeRD PDF/A-3b.
  • Налоговые порталы, PDP, SDI, KSeF, ZATCA, IRP, Peppol и юридические обязательства вне scope.
  • Ваша система отвечает за buyer data, налоговую логику, routing и локальную юридическую оценку.

Форма API

API: счетов Factur-X — 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

Проверяйте счетов Factur-X на реальных данных и в downstream-системах. Храните request ID, PDF и результаты проверок для поддержки, аудита и перепечатки.

FAQ

Это отдельный endpoint?
API: счетов Factur-X использует публичный e-invoice endpoint, когда нужен Factur-X / ZUGFeRD PDF/A-3b. Это не отдельная продуктовая поверхность.
Покрывает ли это локальные clearance-сети?
Нет. gPdf рендерит и упаковывает PDF/e-invoice; налоговые порталы и юридический routing остаются в вашей системе.
Можно ли продолжать использовать JSON Render?
Да, для обычных PDF. E-Invoice Render нужен только для структурированного e-invoice пакета из публичной API.