आज native public output में कौन से e-invoice standards हैं?

Public native output embedded EN 16931 CII XML के साथ Factur-X और ZUGFeRD PDF/A-3b है. Current contract के लिए /api/v1/e-invoice/capabilities check करें.

क्या gPdf मेरे लिए EN 16931 XML generate करता है?

नहीं. XML content आपका system provide करता है. gPdf उसे required attachment metadata के साथ PDF/A-3b e-invoice wrapper में package करता है.

क्या settings.e_invoice JSON Render को भेज सकता हूँ?

नहीं. E-invoice packaging POST /api/v1/e-invoice/render पर belong करती है. Public docs कहती हैं कि settings.e_invoice route-specific है.

Output validate कैसे करना चाहिए?

PDF/A layer और embedded e-invoice XML layer दोनों check करने के लिए gPdf validator या अपना reference-engine workflow use करें.

Compliance और archival

Factur-X और ZUGFeRD PDF/A-3b के लिए E-Invoice API

Public gPdf e-invoice endpoint से embedded EN 16931 CII XML वाले Factur-X और ZUGFeRD PDF/A-3b e-invoices generate करें.

PRIMARY API E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SYSTEMS ERP / finance backend / accounts receivable system / compliance workflow

Playground में आज़माएँ Docs पढ़ें

काम जो पूरा करना है

Human-readable invoice PDF और caller-provided EN 16931 CII XML को Factur-X या ZUGFeRD PDF/A-3b e-invoice में package करें, जिसे external PDF/A और e-invoice reference engines validate कर सकें.

यह API कब इस्तेमाल करें

आपको सिर्फ ordinary invoice PDF नहीं, Factur-X या ZUGFeRD output चाहिए.
आपका system invoice के लिए correct EN 16931 CII XML provide कर सकता है.
आपको PDF/A-3b packaging, attachment metadata और e-invoice XMP wiring चाहिए.
Supported standards और profiles confirm करने के लिए public capabilities endpoint चाहिए.

यह क्या replace नहीं करता

आपको केवल ordinary customer invoice PDF चाहिए. JSON Render या Template Render use करें.
OpenAPI list करने से पहले आपको native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e या GST output चाहिए.
आप incomplete business data से legally correct invoice XML gPdf से बनवाना चाहते हैं.

कौन सा endpoint call करें

PRIMARY

/api/v1/e-invoice/render

E-Invoice Render इस workflow का default path है।

SECONDARY 1

/api/v1/e-invoice/capabilities

जब workflow को related API path, template contract या capabilities lookup चाहिए, तब इसका उपयोग करें।

Minimal request

POST /api/v1/e-invoice/render - minimal 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 क्या handle करता है

POST /api/v1/e-invoice/render से Factur-X या ZUGFeRD PDF/A-3b packaging.
Caller-provided EN 16931 CII XML को associated file के रूप में embed करना.
PDF/A-3b wrapper metadata और standard-specific e-invoice XMP wiring.
GET /api/v1/e-invoice/capabilities से capabilities discovery.

आपका system क्या संभालता है

Invoice business semantics, tax rules, buyer/seller identifiers और EN 16931 XML correctness.
Recipient workflow के लिए Factur-X या ZUGFeRD appropriate है या नहीं, यह चुनना.
Receiver, AP automation system या local compliance process के साथ external acceptance testing.

Production checklist

Standard या profile assume करने से पहले /api/v1/e-invoice/capabilities call करें.
Embed करने से पहले EN 16931 CII XML validate करें.
Output को /validator/ या अपने reference-engine pipeline से चलाएं.
Ordinary invoice PDF generation और legal e-invoice packaging को code में separate रखें.
Request IDs, standard, profile, XML source version और validation evidence log करें.

Claim boundaries

Native public e-invoice output Factur-X / ZUGFeRD with EN 16931 CII XML है.
Other national e-invoice names market context हैं जब तक OpenAPI उन्हें supported standards के रूप में list न करे.
gPdf caller-provided XML package करता है; XML की business correctness आपके system की जिम्मेदारी रहती है.

E-invoice package के लिए एक endpoint

E-invoice endpoint इसलिए exists करता है क्योंकि यह workflow सिर्फ “invoice PDF render” नहीं है. Caller-provided EN 16931 CII XML embed करते हुए इसे correct associated-file metadata और standard-specific XMP के साथ PDF/A-3b wrapper बनाना होता है.

Required output Factur-X या ZUGFeRD हो तो POST /api/v1/e-invoice/render call करें. Integration को काम भेजने से पहले supported standards, profiles, document types और XML formats confirm करने हों तो GET /api/v1/e-invoice/capabilities use करें.

gPdf के बाहर क्या रहता है

XML semantics आपकी responsibility रहती है. gPdf यह नहीं जान सकता कि invoice number legal है या नहीं, tax amount correct है या नहीं, buyer identifier trading partner से match करता है या नहीं, या कोई specific receiver business process variant accept करेगा या नहीं. XML upstream generate और validate करें, फिर PDF/A-3b packaging और rendering के लिए gPdf use करें.

Roadmap terms को native-support claims से बाहर रखें

XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e या GST को market context के रूप में discuss करना valid है. लेकिन जब तक OpenAPI capabilities contract उन्हें list न करे, इन्हें native public renderer output के रूप में present न करें.

FAQ

आज native public output में कौन से e-invoice standards हैं?: Public native output embedded EN 16931 CII XML के साथ Factur-X और ZUGFeRD PDF/A-3b है. Current contract के लिए /api/v1/e-invoice/capabilities check करें.
क्या gPdf मेरे लिए EN 16931 XML generate करता है?: नहीं. XML content आपका system provide करता है. gPdf उसे required attachment metadata के साथ PDF/A-3b e-invoice wrapper में package करता है.
क्या settings.e_invoice JSON Render को भेज सकता हूँ?: नहीं. E-invoice packaging POST /api/v1/e-invoice/render पर belong करती है. Public docs कहती हैं कि settings.e_invoice route-specific है.
Output validate कैसे करना चाहिए?: PDF/A layer और embedded e-invoice XML layer दोनों check करने के लिए gPdf validator या अपना reference-engine workflow use करें.