আজ native public output হিসেবে কোন e-invoice standard আছে?

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 করে?

না। আপনার system XML content দেয়। 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-এ থাকে। Public docs বলে settings.e_invoice route-specific।

Output কীভাবে validate করব?

PDF/A layer এবং embedded e-invoice XML layer দুটোই check করতে gPdf validator বা আপনার নিজের reference-engine workflow ব্যবহার করুন।

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-invoice তৈরি করুন।

প্রাথমিক API E-Invoice Render

Endpoint /api/v1/e-invoice/render

System 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 engine দিয়ে validate করা যায়।

কখন এই API ব্যবহার করবেন

শুধু সাধারণ invoice PDF নয়, Factur-X বা ZUGFeRD output দরকার।
আপনার system invoice-এর জন্য সঠিক EN 16931 CII XML দিতে পারে।
PDF/A-3b packaging, attachment metadata এবং e-invoice XMP wiring দরকার।
Supported standard ও profile confirm করতে public capabilities endpoint ব্যবহার করতে চান।

এটি কী replace করে না

শুধু সাধারণ customer invoice PDF দরকার। JSON Render বা Template Render ব্যবহার করুন।
OpenAPI-তে list হওয়ার আগে native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e বা GST output দরকার।
Incomplete business data থেকে gPdf legally correct invoice XML তৈরি করবে বলে আশা করছেন।

কোন endpoint call করবেন

প্রাথমিক

/api/v1/e-invoice/render

E-Invoice Render এই workflow-এর default path।

সহায়ক 1

/api/v1/e-invoice/capabilities

Workflow-তে related API path, template contract অথবা capabilities lookup দরকার হলে ব্যবহার করুন।

নূন্যতম 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 কী করে

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 rule, buyer/seller identifier এবং EN 16931 XML correctness।
Recipient workflow-এর জন্য Factur-X নাকি ZUGFeRD উপযুক্ত তা নির্বাচন করা।
Receiver, AP automation system বা local compliance process-এর সাথে external acceptance testing।

Production checklist

কোন standard বা profile ধরে নেওয়ার আগে /api/v1/e-invoice/capabilities call করুন।
Embed করার আগে EN 16931 CII XML validate করুন।
Output /validator/ বা আপনার নিজের reference-engine pipeline দিয়ে চালান।
Code-এ সাধারণ invoice PDF generation এবং legal e-invoice packaging আলাদা রাখুন।
Request ID, standard, profile, XML source version এবং validation evidence log করুন।

দাবির সীমা

Native public e-invoice output হলো EN 16931 CII XML-সহ Factur-X / ZUGFeRD।
OpenAPI supported standard হিসেবে list না করলে অন্য national e-invoice name market context মাত্র।
gPdf caller-provided XML package করে; XML business correctness আপনার system-এর দায়িত্বে থাকে।

E-invoice package-এর জন্য এক endpoint

E-invoice endpoint আছে কারণ এই workflow শুধু “invoice PDF render” নয়। এটিকে correct associated file metadata এবং standard-specific XMP-সহ PDF/A-3b wrapper তৈরি করতে হয়, এবং caller-provided EN 16931 CII XML embed করতে হয়।

Required output যদি Factur-X বা ZUGFeRD হয়, POST /api/v1/e-invoice/render call করুন। Integration supported standard, profile, document type এবং XML format confirm করতে চাইলে work পাঠানোর আগে GET /api/v1/e-invoice/capabilities ব্যবহার করুন।

gPdf-এর বাইরে যা থাকে

XML semantics আপনার দায়িত্ব। Invoice number legal কি না, tax amount correct কি না, buyer identifier trading partner-এর সাথে মেলে কি না, বা কোনো specific receiver কোনো business process variant accept করবে কি না, gPdf জানতে পারে না। XML upstream-এ generate ও validate করুন, তারপর PDF/A-3b packaging এবং rendering-এর জন্য gPdf ব্যবহার করুন।

Native-support claim-এ roadmap term রাখবেন না

XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e বা GST market context হিসেবে আলোচনা করা valid। কিন্তু OpenAPI capabilities contract list না করলে এগুলোকে native public renderer output হিসেবে উপস্থাপন করবেন না।

FAQ

আজ native public output হিসেবে কোন e-invoice standard আছে?: 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 করে?: না। আপনার system XML content দেয়। 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-এ থাকে। Public docs বলে settings.e_invoice route-specific।
Output কীভাবে validate করব?: PDF/A layer এবং embedded e-invoice XML layer দুটোই check করতে gPdf validator বা আপনার নিজের reference-engine workflow ব্যবহার করুন।