صيغة PDF/A-3 في الفاتورة الإلكترونية

عند الحديث عن صيغ الفاتورة الإلكترونية في السعودية، يتكرر مصطلح PDF/A-3 بوصفه أحد التنسيقين المعتمدين رسمياً لإصدار الفواتير وحفظها. لكن كثيراً من المطورين والمحاسبين يخلطون بينه وبين ملف PDF العادي الذي اعتادوا إنشاءه من برامج معالجة النصوص. الفرق جوهري، ويترتب عليه قبول الفاتورة أو رفضها لدى هيئة الزكاة والضريبة والجمارك (ZATCA).

هذا التوثيق التقني يشرح صيغة PDF/A-3 وحدها: ما هي، ولماذا اختارتها الهيئة للفواتير المقروءة بشرياً في معاملات الأعمال (B2B)، وكيف تحفظ نسخة الـ XML بداخلها، وما خصائصها في الأرشفة طويلة المدى، وأين تختلف عن ملف PDF التقليدي. أما تفاصيل آلية التضمين نفسها (كيف يُحقن ملف الـ XML داخل بنية الملف على مستوى البايتات) فنفردها في توثيق مستقل بعنوان «تضمين XML داخل PDF/A-3» لتبقى هذه الصفحة مركّزة على الصيغة ذاتها.

ما هي صيغة PDF/A-3 بالضبط؟

صيغة PDF/A هي عائلة من معايير ملفات PDF صُمّمت خصيصاً للأرشفة طويلة المدى. الحرف «A» اختصار لكلمة Archival أي «أرشيفي». هذه العائلة جزء من معيار دولي صادر عن المنظمة الدولية للتوحيد القياسي (ISO)، ولها ثلاثة إصدارات رئيسية:

• PDF/A-1 صدر عام 2005 ضمن المعيار ISO 19005-1. وهو الأكثر تقييداً، ولا يسمح بإرفاق أي ملفات داخل المستند.
• PDF/A-2 صدر عام 2011 ضمن المعيار ISO 19005-2. أضاف دعم الضغط بصيغة JPEG 2000 والشفافية، وسمح بإرفاق ملفات بشرط أن تكون هي نفسها متوافقة مع PDF/A.
• PDF/A-3 صدر عام 2012 ضمن المعيار ISO 19005-3. وهو الإصدار الذي اعتمدته الهيئة، لأنه يسمح بتضمين أي نوع من الملفات داخل المستند، بما في ذلك ملف XML غير متوافق مع PDF/A.

الفارق الحاسم بين PDF/A-3 وما قبله هو هذه النقطة الأخيرة. فالإصداران الأول والثاني إما يمنعان الإرفاق أو يقيّدانه بملفات أرشيفية فقط. أما PDF/A-3 فيفتح الباب لتضمين ملف بيانات منظّم مثل XML بجانب الصفحة المرئية. هذه القدرة بالتحديد هي ما جعلها الخيار المنطقي للفاتورة الإلكترونية المختلطة، حيث تحتاج إلى نسخة يقرأها الإنسان ونسخة تقرأها الآلة في ملف واحد.

لماذا اختارت الهيئة PDF/A-3 للفواتير المقروءة بشرياً؟

تطلب لائحة الفوترة الإلكترونية في السعودية أن تصدر كل فاتورة بصيغة رقمية منظّمة. وحدّدت الهيئة تنسيقين مقبولين: إما ملف XML خالص، أو ملف PDF/A-3 يحمل بداخله نسخة الـ XML. الخيار الثاني موجّه أساساً لفواتير معاملات الأعمال (B2B)، حيث يحتاج الطرف المستلم غالباً إلى رؤية الفاتورة بشكل مرئي مفهوم، لا مجرد سطور برمجية.

تخيّل أن مورّداً أرسل لعميله فاتورة XML خالصة. الـ XML نصّ منظّم تفهمه الأنظمة، لكنه غير مقروء لموظف المشتريات الذي يفتح الملف. أما حين تُرسل الفاتورة بصيغة PDF/A-3 فإن الموظف يرى صفحة فاتورة واضحة فيها اسم المورّد ورقمه الضريبي والبنود والمبالغ ورمز الاستجابة السريعة. وفي الوقت نفسه يستطيع نظام العميل المحاسبي أن يستخرج ملف الـ XML المضمَّن ويعالجه آلياً دون تدخل بشري. هكذا تجمع الصيغة الواحدة بين حاجتين متعارضتين ظاهرياً.

اختارت الهيئة هذه الصيغة لأنها معيار دولي راسخ معترف به في أنظمة ضريبية كثيرة حول العالم. فمعيار ZUGFeRD الألماني والمعيار الفرنسي Factur-X يعتمدان المبدأ نفسه: ملف PDF/A-3 يحمل XML مضمّناً. هذا يعني أن البنية التحتية البرمجية لتوليد هذه الملفات وقراءتها موجودة ومجرَّبة، ولا تحتاج الشركات إلى ابتكار صيغة محلية جديدة من الصفر.

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

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

متى تُستخدم PDF/A-3 ومتى يكفي XML الخالص؟

التمييز العملي بسيط في جوهره:

• الفاتورة الضريبية المعيارية (B2B) تُرسَل عادةً إلى المشتري بعد إجازتها (Clearance) من الهيئة، ولذلك تكون صيغة PDF/A-3 مناسبة لأنها تحمل التمثيل المرئي بجانب البيانات المنظّمة.
• الفاتورة الضريبية المبسّطة (B2C) تُسلَّم للمستهلك مباشرة وتُبلَّغ بها الهيئة خلال 24 ساعة. وهنا يكفي غالباً إيصال يحمل رمز الاستجابة السريعة، دون اشتراط ملف PDF/A-3 كامل.

القاعدة الذهنية: كلما زادت حاجة الطرف المقابل إلى قراءة الفاتورة بصرياً ومعالجتها آلياً في آنٍ واحد، صارت PDF/A-3 الخيار الأنسب.

إصدارات عائلة PDF/A في سطر واحد

الفرق بين PDF/A-3 وملف PDF العادي

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

1. الاكتفاء الذاتي للملف

ملف PDF العادي قد يعتمد على خطوط مثبّتة على جهاز المُصدِر، أو على روابط خارجية، أو على عناصر لا تُحفظ داخل الملف نفسه. بعد سنوات قد يُفتح الملف على جهاز آخر فتختفي الخطوط أو تتغير المحاذاة. أما PDF/A-3 فيشترط أن يكون الملف مكتفياً ذاتياً: كل الخطوط مضمَّنة بداخله، وكل الألوان معرّفة بمساحات لونية مستقلة عن الجهاز. الهدف أن يُعرَض الملف بعد عشر سنوات تماماً كما عُرض يوم إصداره.

2. منع المحتوى الديناميكي

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

3. الملف المضمَّن (XML)

هذا هو الفرق الأهم وظيفياً. ملف PDF العادي لا يحمل بالضرورة نسخة بيانات منظّمة قابلة للمعالجة الآلية. أما PDF/A-3 في سياق الفوترة فيحمل بداخله ملف XML مرفقاً ومُعرّفاً بعلاقة محددة، بحيث يعرف أي نظام يقرأ الملف أن هذا المرفق هو التمثيل المنظّم للفاتورة المرئية. تفاصيل كيفية حقن هذا المرفق وتعريف علاقته نشرحها في توثيق «تضمين XML داخل PDF/A-3» المخصص لذلك.

4. التوافق مع معيار ISO صارم

أي ملف يدّعي أنه PDF/A-3 يجب أن يجتاز التحقق (Validation) مقابل بنود المعيار ISO 19005-3. هناك أدوات مثل veraPDF تفحص الملف وتؤكد مطابقته. ملف PDF العادي ليس مطالباً بهذا التحقق، ولذلك قد يحوي مخالفات لا تظهر بصرياً لكنها تُسقط صفة الأرشفة عنه.

الخلاصة العملية: PDF/A-3 ليس «نوعاً أجمل» من PDF، بل هو ملف محكوم بقيود تجعله صالحاً للأرشفة القانونية وحاملاً للبيانات المنظّمة معاً. ملف PDF العادي لا يفي بأي من الشرطين بشكل مضمون.

PDF عادي مقابل PDF/A-3 في أربعة شروط

خصائص الأرشفة طويلة المدى في PDF/A-3

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

تضمين الخطوط بالكامل

يُلزِم المعيار بتضمين كل الخطوط المستخدمة داخل الملف نفسه. لا يجوز الاعتماد على خط مثبّت على نظام التشغيل. فلو فُتح الملف على جهاز لا يحوي ذلك الخط، يجب أن يظل النص ظاهراً بشكله الصحيح. هذا يحمي الفاتورة من «انهيار المظهر» مع مرور الزمن.

مساحات لونية مستقلة عن الجهاز

تُعرّف الألوان في PDF/A-3 بطريقة لا تعتمد على شاشة بعينها أو طابعة بعينها، عبر تضمين ملف تعريف لوني (ICC Profile). الهدف أن يبدو اللون نفسه على أي وسيلة عرض، فلا يتحول الأحمر الذي يميّز مبلغاً ما إلى لون مختلف يربك القارئ بعد سنوات.

البيانات الوصفية بصيغة XMP

يحمل الملف بياناته الوصفية (Metadata) بصيغة قياسية تُعرف بـ XMP، مدمجة داخل بنية الملف. تتضمن هذه البيانات معلومات عن المستند وتاريخ إنشائه وإصدار PDF/A الذي يتبعه. وجود هذه البيانات بصيغة موحّدة يسهّل على أنظمة الأرشفة فهرسة الملفات والبحث فيها بعد سنوات.

منع التشفير والقيود الخارجية

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

ثبات بنية الملف نفسها

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

هذه الخصائص مجتمعة تجعل ملف PDF/A-3 وثيقة مستقرة لا تتأثر بتغير البيئات البرمجية. وهذا بالضبط ما تحتاجه فاتورة قد يُطلب إبرازها أمام الهيئة بعد سنوات من إصدارها. ولأن متطلبات الاحتفاظ بالسجلات في السعودية تمتد لسنوات، فإن صيغة مصمَّمة للأرشفة طويلة المدى ليست رفاهية، بل ضرورة تتقاطع مباشرة مع التزام المنشأة الضريبي.

خصائص الأرشفة داخل ملف واحد

البنية المفاهيمية للفاتورة بصيغة PDF/A-3

لتقريب الصورة للمطوّر، يمكن النظر إلى فاتورة PDF/A-3 على أنها طبقتان متلازمتان داخل ملف واحد:

• الطبقة المرئية: صفحات PDF التي يراها الإنسان، وفيها ترويسة الفاتورة وبيانات البائع والمشتري وجدول البنود والإجماليات ورمز الاستجابة السريعة.
• الطبقة المنظّمة: ملف XML مضمَّن يحمل البيانات نفسها بصيغة منظّمة تفهمها الأنظمة، وفق نموذج بيانات الفاتورة المعتمد لدى الهيئة.

الطبقتان يجب أن تتطابقا. أي اختلاف بين ما تراه العين في الطبقة المرئية وما تقرأه الآلة في الطبقة المنظّمة يُعدّ مخالفة. ولهذا فإن توليد الملف لا يكون يدوياً، بل عبر نظام محاسبي يضمن أن البيانات المرئية تُشتق من المصدر نفسه الذي يولّد الـ XML.

لتوضيح خطورة عدم التطابق، تخيّل فاتورة تعرض في طبقتها المرئية إجمالياً قدره 1,150 ر.س، بينما يحمل ملف الـ XML المضمَّن قيمة 1,510 ر.س نتيجة خطأ برمجي في القالب. الموظف الذي يقرأ الصفحة يرى رقماً، ونظام الطرف الآخر يسجّل رقماً مختلفاً، وتنشأ فجوة قد تتحول إلى نزاع أو مخالفة عند المراجعة. هذا بالضبط ما تمنعه قاعدة التطابق: مصدر بيانات واحد يغذّي الطبقتين معاً، فلا مجال لتباعدهما.

هذا المبدأ يفسّر لماذا يُنصح دائماً بأن يولّد النظام المحاسبي كلتا الطبقتين في عملية واحدة متزامنة. فحين تُولَّد صفحة العرض من مصدر، ويُولَّد ملف الـ XML من مصدر آخر أو في خطوة لاحقة منفصلة، يزداد احتمال التباعد بينهما. أما التوليد المتزامن من نموذج بيانات موحّد فيضمن أن الرقم الذي يُطبع هو الرقم الذي يُرسَل، حرفاً بحرف.

وفيما يلي تمثيل مبسّط جداً لكيفية ظهور هيكل ملف PDF/A-3 من الداخل على مستوى الكائنات (Objects)، بصورة تعليمية لا تمثّل الملف الفعلي بايتاً ببايت:

%PDF-1.7
% بنية مبسّطة لملف PDF/A-3 يحمل فاتورة

1 0 obj
  << /Type /Catalog
     /Pages 2 0 R
     /Metadata 8 0 R        % البيانات الوصفية XMP
     /Names 9 0 R           % شجرة أسماء الملفات المضمّنة
  >>
endobj

2 0 obj
  << /Type /Pages /Kids [3 0 R] /Count 1 >>   % الطبقة المرئية
endobj

7 0 obj
  << /Type /EmbeddedFile
     /Subtype /text#2Fxml          % ملف XML المضمّن (الطبقة المنظّمة)
     /Params << /Size 4096 >>
  >>
stream
  ... محتوى الفاتورة بصيغة XML ...
endstream
endobj

الكائن رقم 7 في المثال أعلاه هو ملف الـ XML المضمَّن، وهو قلب الفرق بين PDF عادي وPDF/A-3 في سياق الفوترة. لاحظ نوعه EmbeddedFile ونوعه الفرعي text/xml. أما الطريقة التي يُربط بها هذا الكائن بالمستند ويُعلَن عنه كتمثيل بديل للفاتورة فهي موضوع توثيق التضمين المنفصل.

التحقق من مطابقة الملف للمعيار

قبل أن تطمئن إلى أن ملفك فعلاً PDF/A-3 صالح، لا بد من تمريره على أداة تحقق. أشهر الأدوات المفتوحة هي veraPDF، وهي المرجع الذي تتبناه مؤسسة PDF Association للتحقق من توافق ملفات PDF/A. الأداة تفحص الملف وتُخرج تقريراً بكل مخالفة.

إليك مثالاً على استدعاء الأداة من سطر الأوامر للتحقق من مطابقة ملف لمستوى PDF/A-3B:

# التحقق من ملف فاتورة مقابل ملف PDF/A-3 المستوى B
verapdf --flavour 3b invoice-2026-001.pdf

# إخراج التقرير بصيغة قابلة للمعالجة الآلية
verapdf --flavour 3b --format mrr invoice-2026-001.pdf > report.xml

المستوى «B» (اختصاراً لـ Basic) يضمن أن الملف قابل للعرض البصري الموثوق. هناك مستوى أعلى يُعرف بـ «A» (اختصاراً لـ Accessible) يضيف اشتراطات تتعلق بإتاحة الوصول وبنية النص المنطقية. في سياق الفواتير يكفي عادةً المستوى B، لأن الغاية هي ثبات العرض وحمل البيانات المنظّمة، لا قراءة الشاشة لذوي الإعاقة البصرية.

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

من المفيد للمطوّر أن يفهم لماذا تتكرر هذه المخالفات تحديداً. الخط غير المضمَّن ينشأ غالباً حين تُولَّد الفاتورة من قالب يفترض وجود خط معيّن على نظام التشغيل دون تضمينه فعلياً في الملف. المساحة اللونية المعتمدة على الجهاز تظهر حين تُحدَّد الألوان بقيم RGB مباشرة دون ربطها بملف تعريف لوني مستقل. أما المحتوى الممنوع فيتسلل أحياناً من مكتبات توليد PDF التي تضيف طبقات تفاعلية افتراضياً دون أن ينتبه المطوّر.

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

علاقة PDF/A-3 بالمعايير الدولية للفاتورة الهجينة

اختيار الهيئة لصيغة PDF/A-3 لم يأتِ من فراغ، بل يستند إلى ممارسة دولية راسخة تُعرف باسم «الفاتورة الهجينة» (Hybrid Invoice). الفكرة الأساسية أن يحمل ملف واحد طبقتين: تمثيلاً مرئياً يقرؤه الإنسان، وتمثيلاً منظّماً تعالجه الآلة. وقد سبقت أنظمة ضريبية أوروبية السعودية إلى تبنّي هذا النهج، ما يجعل البنية البرمجية لتوليد هذه الملفات ناضجة ومجرَّبة.

أبرز معيارين دوليين يعتمدان PDF/A-3 كحاوية للفاتورة الهجينة:

• ZUGFeRD المعيار الألماني الذي يضمّن ملف XML داخل ملف PDF/A-3، ويُستخدم على نطاق واسع في معاملات الأعمال داخل ألمانيا.
• Factur-X المعيار الفرنسي المتوافق مع ZUGFeRD، ويعتمد المبدأ نفسه: ملف PDF/A-3 يحمل XML مضمّناً بنموذج بيانات موحّد.

القاسم المشترك بين هذه المعايير هو فصل «الحاوية» عن «المحتوى». الحاوية دائماً ملف PDF/A-3 لأنه يضمن الأرشفة طويلة المدى وثبات العرض. أما المحتوى المنظّم فيختلف نموذج بياناته من نظام ضريبي لآخر. السعودية تعتمد نموذج بياناتها الخاص المبني على معيار UBL 2.1، بينما تعتمد المعايير الأوروبية نماذج أخرى. لكن الحاوية واحدة في الحالتين، وهذا ما يجعل المطوّر القادم من خلفية أوروبية يجد نفسه في أرض مألوفة عند التعامل مع متطلبات الهيئة.

الدرس العملي للمطوّر هنا مزدوج. أولاً، أن أدوات النظام البيئي المفتوحة (مكتبات توليد PDF/A-3 وأدوات التحقق مثل veraPDF) صالحة للاستخدام في السياق السعودي، لأن الحاوية معيارية عالمياً. ثانياً، أن ما يتغيّر فعلاً هو بنية ملف الـ XML المضمَّن ونموذج بياناته، لا صيغة الملف الحاوية. ولهذا تبقى آلية التضمين نفسها (المشروحة في توثيق منفصل) متشابهة عبر هذه المعايير، بينما يختلف ما يوضَع داخل المرفق.

اعتبارات الأداء وحجم الملف عند توليد PDF/A-3

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

لتقليل هذا الأثر دون مخالفة المعيار، تلجأ الأنظمة الناضجة إلى تقنية «تجزئة الخط» (Font Subsetting). بدل تضمين الخط كاملاً بآلاف الرموز، يُضمَّن فقط مجموعة الرموز المستخدمة فعلاً في الفاتورة: الأرقام والحروف العربية واللاتينية الواردة في البنود. هذا يحافظ على شرط الاكتفاء الذاتي ويبقي حجم الملف معقولاً.

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

أما على مستوى الأداء، فتوليد PDF/A-3 أبطأ قليلاً من توليد PDF عادي، لأن النظام يؤدي خطوات إضافية: تضمين الخطوط، وكتابة البيانات الوصفية بصيغة XMP، وإرفاق ملف الـ XML وربطه، وأحياناً التحقق الداخلي من المطابقة قبل إخراج الملف. في عملية فردية الفارق غير محسوس، لكنه يصبح مؤثراً عند التوليد بالجملة. ولهذا تفصل الأنظمة المصمَّمة جيداً بين توليد الفاتورة وإرسالها، وتعالج التوليد في طوابير خلفية بدل حجب طلب المستخدم.

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

كيف يتعامل قيود مع صيغة PDF/A-3؟

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

يدير قيود أيضاً شهادة الختم التشفيري (المعرّف CSID) تلقائياً، ويحفظ سلسلة قيم التجزئة (Hash) لكل فاتورة بما يضمن سلامة التسلسل. وكل هذا يجري في الخلفية، فلا يرى المستخدم سوى فاتورة جاهزة متوافقة مع متطلبات الهيئة.

تبقى مسؤوليات معينة على عاتق المنشأة نفسها، أبرزها تسجيل شهادة الـ CSID لدى الهيئة، إذ يرشدك قيود خلال الخطوات لكنه لا يتولى التسجيل نيابةً عنك. كذلك تقديم الإقرار الضريبي ودفع الضريبة يتمان مباشرة عبر بوابة الهيئة، لا من داخل البرنامج.

ميزة الاعتماد على نظام محاسبي متكامل هنا أنك تتفادى الأخطاء التقنية الدقيقة التي تُسقط صفة PDF/A-3 عن الملف. فالبرنامج يضمن تضمين الخطوط، ويمنع المحتوى الديناميكي، ويولّد البيانات الوصفية بالصيغة الصحيحة، ويربط ملف الـ XML المضمّن بالطبقة المرئية بشكل سليم. باختصار، يحوّل متطلباً تقنياً معقداً إلى زر إصدار فاتورة.

أسئلة شائعة حول صيغة PDF/A-3

هل ملف PDF/A-3 هو نفسه ملف PDF لكن باسم مختلف؟

لا. صيغة PDF/A-3 نسخة محكومة بمعيار ISO 19005-3 تشترط تضمين الخطوط، وتمنع المحتوى الديناميكي والتشفير، وتسمح بحمل ملف XML مضمّن. ملف PDF العادي لا يلتزم بأي من هذه الشروط بالضرورة، ولذلك لا يُقبل بديلاً عنه لدى الهيئة.

لماذا تحتاج فاتورة الأعمال إلى PDF/A-3 بينما يكفي XML الخالص أحياناً؟

لأن الطرف المستلم في معاملات الأعمال غالباً يحتاج إلى رؤية الفاتورة بصرياً ومعالجتها آلياً معاً. صيغة PDF/A-3 تجمع الطبقتين في ملف واحد: صفحة مقروءة للإنسان وملف XML للأنظمة. أما XML الخالص فيكفي حين لا يلزم تمثيل مرئي.

ما الفرق بين مستوى PDF/A-3B ومستوى PDF/A-3A؟

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

كيف أتأكد أن الفاتورة التي ولّدها نظامي مطابقة فعلاً للمعيار؟

مرّر الملف على أداة تحقق مثل veraPDF بالمستوى المطلوب. تُخرج الأداة تقريراً بكل مخالفة. الأخطاء الشائعة خط غير مضمَّن أو مساحة لونية تعتمد على الجهاز أو محتوى ممنوع. مع نظام محاسبي معتمد تُعالَج هذه النقاط تلقائياً.

أين تُحفظ بيانات الفاتورة المنظّمة داخل ملف PDF/A-3؟

تُحفظ في ملف XML مضمَّن داخل بنية المستند ككائن من نوع EmbeddedFile، مرتبط بالمستند بعلاقة محددة تعرّفه كتمثيل بديل للفاتورة المرئية. تفاصيل آلية التضمين هذه نفردها في توثيق «تضمين XML داخل PDF/A-3».

هل أحتاج إلى توليد ملف PDF/A-3 يدوياً كمطوّر؟

لا يُنصح بذلك في بيئة الإنتاج. توليد الملف يدوياً عرضة لمخالفات دقيقة تُسقط صفة PDF/A-3. الأفضل الاعتماد على نظام محاسبي يولّد الملف متوافقاً مع الهيئة، فيتولى تضمين الخطوط والتوقيع التشفيري وربط ملف الـ XML المضمّن آلياً.

خلاصة عملية

صيغة PDF/A-3 ليست رفاهية شكلية، بل اختيار تقني محسوب من الهيئة ليجمع بين قراءة الإنسان ومعالجة الآلة في ملف واحد قابل للأرشفة عقوداً. هي إصدار من عائلة PDF/A الصادرة عن ISO، يتميّز بقدرته على تضمين ملف XML بداخله، وبخصائص أرشفة صارمة تجعله صالحاً للمراجعة الضريبية بعد سنوات.

الفرق بينها وبين ملف PDF العادي ليس في المظهر، بل في الاكتفاء الذاتي ومنع المحتوى الديناميكي وحمل البيانات المنظّمة واجتياز التحقق مقابل المعيار. وإذا أردت التعمق في صيغ التمثيل التقني الأخرى للفاتورة، راجع توثيق فاتورة XML وتوثيق بنية الفاتورة الإلكترونية. أما آلية حقن ملف الـ XML داخل ملف PDF/A-3 على مستوى البنية فنخصص لها توثيق «تضمين XML داخل PDF/A-3» ليبقى هذا التوثيق مركّزاً على الصيغة وحدها.