gPdf render/edge
المدونة

شرح PDF/A-3: وكيف تتأكد أن ملفك متوافق فعلًا

PDF/A-3 هو ملف PDF/A الشائع الذي يسمح بالمرفقات القانونية داخل الأرشيف، وهو أساس فواتير Factur-X / ZUGFeRD الإلكترونية. الفروق ونقاط الفحص والتحقق المزدوج.

by فريق هندسة gPdf
#pdf-a#compliance#archival#e-invoice

PDF/A هو إصدار PDF المخصص للأرشفة: وعد بأن يظهر المستند في 2050 بالشكل نفسه الذي يظهر به في 2026. توجد ملفات تعريف رئيسية هي PDF/A-1 و2 و3 و4، ولكل منها مستويات مطابقة. من بينها، PDF/A-3 هو الملف الذي يشغّل الفوترة الإلكترونية الأوروبية بهدوء، وهو الملف الشائع الوحيد في عائلة PDF/A الذي يسمح بمرفقات ملفات عشوائية داخل غلاف الأرشفة.

إذا كنت تتعامل مع فواتير أو ملفات تنظيمية أو أي مسار “PDF + بيانات منظمة”، فستقابل PDF/A-3. هذا شرح عملي لما هو، وكيف يختلف، وكيف تتحقق من أن الملف متوافق حقًا.

عائلة PDF/A في نظرة واحدة

الملفجزء ISOالسنةالميزة المحددة
PDF/A-119005-12005أول ملف أرشفة. بلا شفافية، بلا JavaScript، والخطوط مضمّنة.
PDF/A-219005-22011يضيف JPEG2000 والشفافية والطبقات. دقة طباعة أفضل.
PDF/A-319005-32012يضيف مرفقات الملفات المضمّنة. غلاف Factur-X / ZUGFeRD.
PDF/A-419005-42020مراجعة حديثة؛ نموذج مطابقة أوضح، بلا فصل b مقابل a.

وتوجد مستويات فرعية:

  • b (basic): يحافظ على الشكل البصري، بلا ضمانات دلالية.
  • a (accessible): وسوم بنيوية وربط Unicode حتى تستخرج قارئات الشاشة النص بالترتيب الصحيح.
  • u (Unicode): ربط Unicode من دون بنية كاملة؛ حل وسط.
  • e / f (في PDF/A-4 فقط): محتوى هندسي ثلاثي الأبعاد ونماذج كاملة.

لذلك يعني “PDF/A-3b”: ملف أرشفة من الجيل الثالث يسمح بالمرفقات، مع مستوى basic لا يفرض وسوم إمكانية الوصول. وهذا أكثر خيار شائع في الفواتير.

ما الذي يميّز PDF/A-3

PDF/A-1 وPDF/A-2 يمنعان الملفات المضمّنة العشوائية. السبب أن PDF الأرشيفي يجب أن يكون مكتفيًا بذاته؛ مرفق مثل data.xlsx قد يتلف أو يصبح غير قابل للفتح بمعزل عن PDF، فيكسر وعد الأرشفة.

PDF/A-3 يرخّي هذه القاعدة بشرط صارم: يجب أن يصرّح كل ملف مضمّن بسمة AFRelationship التي تشرح علاقته بالمحتوى المرئي في PDF. القيم الصالحة هي Source وData وAlternative وSupplement وUnspecified. يجب أيضًا أن يدرج PDF المرفق في مصفوفة /AF وأن يخرج metadata XMP تصف الملف المرفق.

بكلمات أبسط: يقول PDF/A-3 “يمكنك إرفاق ملفات، لكن يجب أن تصرّح بدقة ما هي وكيف ترتبط بما يراه الإنسان”. هذا الإعلان هو ما جعل PDF/A-3 مركبة الفوترة الإلكترونية: الفاتورة المقروءة للبشر داخل PDF، وXML CII وفق EN 16931 داخل المرفق، وAFRelationship="Alternative" يعلن أن الاثنين تمثيلان بديلان للفاتورة نفسها.

أين يستخدم PDF/A-3 في الإنتاج

  • Factur-X (فرنسا، B2B إلزامي تدريجيًا من 2026): PDF/A-3 + CII XML مع namespace XMP هو urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
  • ZUGFeRD 2.x (ألمانيا، الاستلام إلزامي من 2025): PDF/A-3 + CII XML مع namespace XMP هو urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
  • أرشفة CAD الهندسية: PDF/A-3 مع ملف CAD الأصلي مرفقًا. PDF هو العرض، وCAD هو المصدر.
  • التقارير التنظيمية: PDF/A-3 مع payloads XML مرفقة، مثل FDA submissions أو تقارير ESEF للشركات الأوروبية المدرجة.

في كل هذه الحالات، الغلاف ليس حاوية فقط. إنه عقد يقول إن PDF وهذا المرفق هما المستند نفسه، ويجب أن ينجح كلاهما في التحقق.

كيف تتحقق من توافق PDF/A-3

أداة التحقق الرسمية هي veraPDF (verapdf.org)، وتديرها PDF Association. تنفذ قواعد ISO 19005-3؛ إذا قال التقرير “Pass — PDF/A-3b”، فهذه أقوى إشارة يمكن أن يعطيها محرك واحد.

لكن “Pass” من محرك واحد ليس معيارًا كافيًا للتدقيق (Why two PDF/A validators are better than one يشرح السبب). النمط الأقوى هو تشغيل محركين مستقلين واعتبار الملف متوافقًا فقط عندما ينجح الاثنان.

في ملف الفاتورة الإلكترونية تحتاج أيضًا إلى محرك ثانٍ على مستوى البيانات: Mustang (mustangproject.org). وهو المدقق العملي الأشهر لـ Factur-X / ZUGFeRD، إذ يتحقق من CII XML المضمّن وفق EN 16931 Schematron. توافق PDF/A-3 وحده لا يكفي؛ يجب أن يكون XML المرفق صالحًا وفق EN 16931 وإلا سيرفضه نظام AP لدى المستلم.

كثير من الفرق تثبت Java وveraPDF CLI وMustang ثم تكتب shell script يجمع النتائج. هذا يعمل، لكنه مزعج.

validator يشغّل الثلاثة في المتصفح:

  1. veraPDF: المرجع الرسمي لتوافق PDF/A-3.
  2. محرك gPdf Rust+WASM على edge: تنفيذ مستقل يعطي رأيًا ثانيًا.
  3. Mustang: EN 16931 CII XML Schematron للـ payloads المضمّنة في الفواتير.

أسقط الملف، تعمل المحركات الثلاثة بالتوازي، وتظهر التقارير جنبًا إلى جنب. يمكنك تنزيل JSON كدليل QA. بلا تسجيل دخول وبلا quota.

ما الذي تبحث عنه في التقرير

تتجمع الأخطاء عادة في هذه المناطق:

  • نقص metadata للملف المضمّن: مصفوفة /AF غير موجودة، أو الملف المرفق غير مدرج فيها.
  • AFRelationship مفقود أو خطأ: في الفواتير الإلكترونية يجب أن يكون Alternative؛ كثير من مكتبات PDF تستخدم Source أو Data افتراضيًا.
  • namespace XMP مفقود أو خطأ: لدى Factur-X وZUGFeRD عناوين URI محددة؛ خطأ حرف واحد يكفي للفشل.
  • الخطوط غير مجزأة أو غير مضمّنة: يتطلب PDF/A تضمين كل glyph مستخدم مع الخط. حتى مرجع خط معلن وغير مستخدم قد يفشل في بعض الحالات.
  • غياب output intent: يتطلب PDF/A نية لون مثل sRGB أو ملف ICC آخر حتى لو كان المستند نصًا أسود وأبيض.
  • metadata المستند ناقصة: يجب أن توجد /Title و/Producer و/CreationDate في قاموس معلومات المستند.

عادة يربط التقرير كل فشل بقسم محدد من المواصفة. أصلح السبب في المصدر؛ وإذا كنت تولد عبر gPdf، تتكفل API بهذه التفاصيل ويكون validator إيصالك العام.

TL;DR

PDF/A-3 = PDF/A-2 + القدرة على تضمين ملفات عشوائية بشكل قانوني. هذه القدرة هي ما يجعل الفوترة الإلكترونية الأوروبية عملية: فاتورة مقروءة للبشر + XML CII وفق EN 16931 داخل غلاف أرشيفي واحد. يجب أن ينجح غلاف PDF/A-3 وXML المرفق معًا قبل الإرسال.

ولّد عبر POST /api/v1/e-invoice/render. تحقق في validator. ثلاثة محركات (veraPDF + gPdf edge + Mustang)، رفع واحد، مجانًا.