إذا كنت مهندسًا قيل له للتو إن “الفواتير يجب أن تكون PDF/A-3 مع Factur-X بحلول الربع القادم”، وكان كل ما تعرفه أن الفريق القانوني ذكر هذه الكلمات، فهذا المقال لك.

سنبتعد عن لهجة وثائق المعايير ونشرح ما الذي تقيّده هذه الملفات التعريفية فعليًا، ولماذا بدأت الحكومات في إلزامها، وما أصغر مسار عملي لإخراج PDF متوافق من عارض يعتمد على بيانات منظمة.

PDF/A في فقرتين

PDF تنسيق مرن. مرن أكثر من اللازم — فالمواصفة نفسها تسمح بتضمين JavaScript، والربط بموارد خارجية قد لا تكون موجودة بعد 50 عامًا، وتشفير المحتوى بتشفير قابل للعكس، والإشارة إلى خطوط خارجية، وعشرات الأمور الأخرى التي تجعل المستند غير مكتفٍ بذاته.

PDF/A، حيث ترمز “A” إلى Archival، هو ملف تعريفي من PDF يمنع الأجزاء التي قد تمنع المستند من العرض بالشكل نفسه بعد 50 عامًا. القواعد العامة:

يجب تضمين جميع الخطوط.
لا JavaScript، ولا روابط خارجية، ولا صوت أو فيديو.
لا تشفير.
يجب تسطيح كل الشفافية أو أن يدعمها إصدار الملف التعريفي.
يجب أن تكون الألوان مستقلة عن الجهاز، مع ملف ICC مطلوب.
يجب أن يكون كل المحتوى داخل الملف، بلا مراجع تعتمد على الشبكة.

هناك عدة إصدارات، يضيف كل واحد منها قدرًا من التسامح مع ميزات أحدث:

الملف التعريفي	السنة	ما الذي يضيفه
PDF/A-1b	2005	خط الأساس الأصلي، وهو الأكثر صرامة
PDF/A-2b	2011	يسمح بـ JPEG2000 والشفافية والطبقات
PDF/A-3b	2012	يسمح بمرفقات ملفات عشوائية، وهو أساس Factur-X
PDF/A-4	2020	مبني على ISO 32000-2 (PDF 2.0) مع مستويات مطابقة أبسط

لاحقة “b” تعني مطابقة “basic”، أي الحفاظ البصري الأساسي. توجد أيضًا لاحقات “u” لربط النص بـ Unicode و”a” للوسوم الخاصة بإمكانية الوصول. في معظم مسارات الفواتير والإيصالات، “b” هي ما تريده، لأن الأرشفة الضريبية تهتم بإعادة إنتاج الشكل البصري، لا بدلالات قارئات الشاشة.

الخلاصة العملية: إذا قال العارض إنه يدعم PDF/A-3b، فيجب أن يكون ذلك علم إعداد واحدًا مثل { profile: "PDF/A-3b" } أو ما يعادله. إذا احتجت إلى تشغيل أداة ثانية مثل Ghostscript أو qpdf أو Acrobat للتحويل بعد التوليد، فهذه فجوة تشغيلية يجب احتسابها في العمليات.

لماذا يهم PDF/A-3 تحديدًا: إنه حامل الفواتير الإلكترونية

أضاف PDF/A-3 قدرة واحدة بدت عادية لكنها غيرت الواقع: إرفاق ملفات عشوائية داخل ملف PDF.

قد يبدو ذلك مملًا. لكنه ليس كذلك. هذه هي القاعدة التقنية الكاملة لتفويضات الفوترة الإلكترونية التي تنتشر في أوروبا الآن.

البنية هي ملف PDF واحد يكون في الوقت نفسه:

فاتورة يقرأها الإنسان، بتخطيطها البصري وإجمالياتها وعلامتها التجارية.
فاتورة XML تقرؤها الآلات، وهي الجزء الذي يفسره برنامج الجهة الضريبية.

كلاهما داخل ملف واحد، وكلاهما يمثل الفاتورة نفسها، وغلاف PDF/A-3 يضمن بقاء الملف قابلًا للتحليل بعد عقود.

تنسيقات XML الرئيسية:

Factur-X في فرنسا، وهو ملف XML مبني على UN/CEFACT Cross Industry Invoice.
ZUGFeRD في ألمانيا، وهو مطابق جوهريًا لـ Factur-X بعد الاندماج التقني بين المعيارين في 2018.
EN 16931، وهو المعيار الأوروبي الذي تلتزم به هذه التطبيقات.

في معظم مسارات العمل، يمكن استخدام “Factur-X” و”ZUGFeRD” كمصطلحين متبادلين. فهما يشتركان في المخطط، وآلية التضمين، وغالبًا يكون ملف PDF المتوافق مع أحدهما متوافقًا مع الآخر.

ما الإلزامي، وأين، ومتى

هذه لقطة غير شاملة للمهندسين الذين يخططون لإطلاقات الربعين الثاني والثالث من 2026:

البلد	الحالة	التنسيق المطلوب
ألمانيا	استلام فواتير B2B إلزامي من 2025-01-01؛ والإصدار يصبح إلزاميًا أيضًا من 2027	EN 16931 (Factur-X / ZUGFeRD / XRechnung)
فرنسا	إصدار الفواتير إلزامي للشركات الكبيرة في 2026-09؛ وللشركات الصغيرة والمتوسطة في 2027-09	Factur-X عبر Chorus Pro
إيطاليا	B2B إلزامي منذ 2019	FatturaPA عبر SDI
بولندا	إلزامي منذ 2024-07	KSeF
إسبانيا	إلزامي من 2026 في B2B	Facturae عبر FACe
بلجيكا	إلزامي من 2026-01	Peppol BIS 3

النمط واضح: كل دولة عضو في الاتحاد الأوروبي تنفذ شكلًا من الفوترة الإلكترونية المتوافقة مع EN 16931 ضمن جدول 2024-2027. إذا كان عملاؤك يعملون في أي من هذه الأسواق، فسيحتاج مولد PDF لديك إلى إخراج XML مرفق بجانب الفاتورة المرئية.

أصغر مسار عملي

انسَ ما تمليه وثائق المعايير للحظة. هذه هي النظرة الهندسية:

   ┌─────────────────────┐
   │  بيانات فاتورتك    │  (هي غالبًا كائن JSON في مكان ما)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ بناء XML وفق        │  (ربط حتمي؛ توجد مكتبات مجربة)
   │ EN 16931            │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ توليد PDF/A-3b +    │
   │ إرفاق XML           │  (طلب API واحد إلى gPdf، أو خطوتان في أنظمة أخرى)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  التسليم إلى        │
   │  Chorus Pro / SDI / │
   │  Peppol / etc       │
   └─────────────────────┘

الخطوتان غير البديهيتين:

الخطوة 1: بناء XML

هذه خطوة مزعجة لكنها ميكانيكية. تربط بيانات الفاتورة لديك، مثل البنود والضرائب والإجماليات والأطراف، بأسماء حقول XML الخاصة بـ EN 16931. توجد مكتبات Java وNode وPython تفعل ذلك لك؛ ابحث عن “factur-x library” في لغتك. لا تكتبها من الصفر إلا إذا كنت تستمتع فعلًا بمواصفات مخططات XML.

الخطوة 2: توليد PDF/A-3 وإرفاق XML

هنا يصبح اختيار العارض مهمًا.

من دون دعم مدمج: تولد PDF عاديًا، ثم تعالجه بأداة تحول الملف إلى PDF/A-3 وتضيف XML كملف مدمج. من التركيبات الشائعة Ghostscript مع qpdf، أو أداة مدفوعة مثل Aspose. هذه خطوتان إضافيتان ونقطتا فشل إضافيتان، وعليك التأكد من أن المعالجة اللاحقة لا تغير التخطيط البصري.

مع دعم مدمج، وهو نهج gPdf: طلب واحد.

curl -X POST https://gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "document": {
      "pages": [{ "size": "a4", "elements": [...] }]
    },
    "einvoice": {
      "format": "factur-x",
      "profile": "BASIC",
      "xml": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
    }
  }' \
  --output invoice-with-einvoice.pdf

هذا هو المسار كاملًا. يخرج العارض PDF/A-3b، ويرفق XML لديك باسم factur-x.xml أو zugferd-invoice.xml، وكلاهما تتعرف عليه الجهات المستهلكة، ثم يعيد البايتات.

الأخطاء الشائعة

بعض الأشياء يتعلمها الناس بالطريقة الصعبة:

“PDF/A” و”مع خطوط متوافقة مع PDF/A” ليسا الشيء نفسه

يتطلب ملف PDF/A-3 تضمين كل الخطوط مع تغطية كاملة للحروف المستخدمة. إذا احتوت فاتورتك على اسم عميل ياباني وعاد العارض إلى خط لا يمكن تضمينه بالكامل، فسترفضه أدوات التحقق. تأكد أن العارض يضمن خطوط CJK في وضع PDF/A، فالكثير لا يفعل ذلك افتراضيًا.

يجب أن يتطابق الشكل البصري مع XML

من المفترض أن تمثل فاتورة XML والفاتورة المرئية الفاتورة نفسها. سيراجع المدققون الضريبيون الفروقات بينهما. إذا أخرج الكود XML فيه total: 119.00 بينما يعرض PDF المرئي Total: 120.00 بسبب خطأ تقريب أو قالب قديم، فقد أصبح لديك اختلاف ضريبي محفوظ. أنشئ الاثنين من مصدر حقيقة واحد، ويفضل أن يكونا في مسار الكود نفسه.

مستويات “profile” في EN 16931

لدى Factur-X ملفات تعريف: MINIMUM وBASIC وEN 16931 وEXTENDED. تختلف في كمية البيانات داخل XML. استخدم BASIC ما لم يطلب العميل أكثر صراحة، فهو يغطي رموز الضرائب والبنود والأطراف والإجماليات، وهذا يكفي لنحو 95% من فواتير B2B. يضيف ملف EN 16931 تفاصيل أخرى للحالات الطرفية.

التحقق قبل الإرسال

تحقق دائمًا من PDF الناتج باستخدام مدقق PDF/A، وveraPDF هو المعيار مفتوح المصدر، وتحقق أيضًا من XML مقابل مخطط EN 16931 قبل الإرسال إلى الجهة الضريبية. الإرسالات الفاشلة إلى Chorus Pro أو SDI تؤثر في مقاييس موثوقيتك لدى الجهة المنظمة.

TL;DR

PDF/A هو ملف تعريفي لمستند مكتفٍ بذاته. PDF/A-3 يتيح إرفاق الملفات. Factur-X / ZUGFeRD يعني “XML وفق EN 16931 مرفق داخل PDF/A-3”. تجعل تفويضات الفوترة الإلكترونية في الاتحاد الأوروبي هذا المزيج صيغة B2B الفعلية بين 2025 و2027.

إذا كان العارض يعامل PDF/A-3 + Factur-X كعلم إعداد واحد، فالهجرة ميكانيكية. وإذا لم يفعل، فأنت تبني مسار عمليات متعدد الخطوات. endpoint ‏/api/v1/e-invoice/render في gPdf هو نسخة العلم الواحد؛ يتضمن مرجع API المخطط الكامل، أو يمكنك تجربة توليد عينة في Playground.