Какие e-invoice standards сегодня являются native public output?

Публичный native output — Factur-X и ZUGFeRD PDF/A-3b со встроенным EN 16931 CII XML. Текущий контракт проверяйте через /api/v1/e-invoice/capabilities.

Создает ли gPdf EN 16931 XML за меня?

Нет. XML content предоставляет ваша система. gPdf упаковывает его в PDF/A-3b e-invoice wrapper с нужными attachment metadata.

Можно ли отправить settings.e_invoice в JSON Render?

Нет. E-invoice packaging находится на POST /api/v1/e-invoice/render. Публичная документация говорит, что settings.e_invoice является route-specific.

Как валидировать output?

Используйте gPdf validator или собственный reference-engine workflow, чтобы проверить и PDF/A layer, и встроенный e-invoice XML layer.

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

E-Invoice API для Factur-X и ZUGFeRD PDF/A-3b

Генерируйте Factur-X и ZUGFeRD PDF/A-3b e-invoices со встроенным EN 16931 CII XML через публичный endpoint gPdf для e-invoice.

ОСНОВНАЯ API E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

СИСТЕМЫ ERP / finance backend / accounts receivable system / compliance workflow

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

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

Упаковать человекочитаемый invoice PDF и предоставленный caller EN 16931 CII XML в Factur-X или ZUGFeRD PDF/A-3b e-invoice, который можно проверить внешними PDF/A и e-invoice reference engines.

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

Нужен Factur-X или ZUGFeRD output, а не только обычный invoice PDF.
Ваша система может предоставить корректный EN 16931 CII XML для invoice.
Нужны PDF/A-3b packaging, attachment metadata и e-invoice XMP wiring.
Нужно через public capabilities endpoint подтвердить поддерживаемые standards и profiles.

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

Нужен только обычный customer invoice PDF. Используйте JSON Render или Template Render.
Нужен native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e или GST output до того, как OpenAPI перечислит его.
Вы ожидаете, что gPdf создаст legally correct invoice XML из неполных business data.

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

ОСНОВНОЙ

/api/v1/e-invoice/render

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

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

/api/v1/e-invoice/capabilities

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

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

POST /api/v1/e-invoice/render - минимальный Factur-X PDF/A-3b request.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Invoice INV-1007",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

Что выполняет gPdf

Factur-X или ZUGFeRD PDF/A-3b packaging через POST /api/v1/e-invoice/render.
Встраивание caller-provided EN 16931 CII XML как associated file.
PDF/A-3b wrapper metadata и standard-specific e-invoice XMP wiring.
Capabilities discovery через GET /api/v1/e-invoice/capabilities.

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

Invoice business semantics, tax rules, buyer/seller identifiers и корректность EN 16931 XML.
Выбор того, подходит ли Factur-X или ZUGFeRD для recipient workflow.
External acceptance testing с receiver, AP automation system или local compliance process.

Production-чеклист

Вызывайте /api/v1/e-invoice/capabilities до того, как предполагать standard или profile.
Проверяйте EN 16931 CII XML перед встраиванием.
Прогоняйте output через /validator/ или собственный reference-engine pipeline.
Держите обычную генерацию invoice PDF и legal e-invoice packaging раздельными в коде.
Логируйте request IDs, standard, profile, XML source version и validation evidence.

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

Native public e-invoice output — это Factur-X / ZUGFeRD с EN 16931 CII XML.
Названия других national e-invoice standards являются market context, пока OpenAPI не перечислит их как supported standards.
gPdf упаковывает caller-provided XML; ваша система отвечает за business correctness XML.

Один endpoint для e-invoice package

E-invoice endpoint существует потому, что этот workflow — не просто “отрендерить invoice PDF”. Он должен создать PDF/A-3b wrapper с корректными associated file metadata и standard-specific XMP, одновременно встраивая предоставленный caller EN 16931 CII XML.

Вызывайте POST /api/v1/e-invoice/render, когда нужен Factur-X или ZUGFeRD. Используйте GET /api/v1/e-invoice/capabilities, когда integration должен подтвердить supported standards, profiles, document types и XML formats перед отправкой работы.

Что остается вне gPdf

XML semantics остаются вашей ответственностью. gPdf не может знать, легален ли invoice number, корректна ли tax amount, соответствует ли buyer identifier trading partner или примет ли конкретный receiver вариант business process. Генерируйте и валидируйте XML upstream, затем используйте gPdf для PDF/A-3b packaging и rendering.

Не превращайте roadmap terms в native-support claims

XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e или GST можно обсуждать как market context. Не представляйте эти названия как native public renderer output, если OpenAPI capabilities contract их не перечисляет.

FAQ

Какие e-invoice standards сегодня являются native public output?: Публичный native output — Factur-X и ZUGFeRD PDF/A-3b со встроенным EN 16931 CII XML. Текущий контракт проверяйте через /api/v1/e-invoice/capabilities.
Создает ли gPdf EN 16931 XML за меня?: Нет. XML content предоставляет ваша система. gPdf упаковывает его в PDF/A-3b e-invoice wrapper с нужными attachment metadata.
Можно ли отправить settings.e_invoice в JSON Render?: Нет. E-invoice packaging находится на POST /api/v1/e-invoice/render. Публичная документация говорит, что settings.e_invoice является route-specific.
Как валидировать output?: Используйте gPdf validator или собственный reference-engine workflow, чтобы проверить и PDF/A layer, и встроенный e-invoice XML layer.