عند توليد فاتورة إلكترونية بصيغة PDF/A-3، لا يكفي أن تضع ملف الـ XML في مكان ما داخل المستند. هناك بنية دقيقة يفرضها المعيار الدولي ISO 19005-3 تحدد كيف يُحقن الملف، وكيف يُعرَّف، وكيف يربطه القارئ بالصفحة المرئية. هذا التوثيق التقني يفكّك آلية التضمين هذه على مستوى بنية الملف: كيف يصبح ملف الـ XML جزءاً من المستند ككائن EmbeddedFile، وكيف تربطه علاقة الملفات المرافقة (Associated Files) بالفاتورة، وما دور قاموس مواصفات الملف (File Specification Dictionary) ومفتاح /AFRelationship، وكيف يستخرج النظام المستلم نسخة الـ XML آلياً.
هذه الصفحة تفترض أنك تعرف مسبقاً ما هي صيغة PDF/A-3 ولماذا اعتمدتها هيئة الزكاة والضريبة والجمارك (ZATCA) للفواتير المقروءة بشرياً. إن لم تكن قد اطّلعت على ذلك بعد، فابدأ بتوثيق صيغة PDF/A-3 في الفاتورة الإلكترونية الذي يشرح الصيغة وخصائص الأرشفة فيها. أما هنا فنركّز على آلية التضمين وحدها، لأنها الجزء الذي يخطئ فيه المطورون غالباً عند بناء مولّد فواتير من الصفر.
لماذا ملف مختلط أصلاً: صفحة للإنسان وبيانات للآلة
الفاتورة الإلكترونية في معاملات الأعمال (B2B) تحتاج إلى تمثيلين في الوقت نفسه. التمثيل الأول صفحة مرئية يقرأها موظف المشتريات: اسم المورّد، رقمه الضريبي، البنود، المبالغ، رمز الاستجابة السريعة. التمثيل الثاني ملف بيانات منظّم يقرأه نظام المحاسبة المستلم دون تدخل بشري. لو أرسلت كل تمثيل في ملف منفصل، لتعرّض المستلم لخطر أن يحمل ملفاً ويفقد الآخر، أو أن يتعامل مع نسختين متناقضتين للفاتورة ذاتها.
الملف المختلط (Hybrid File) يحسم هذا التعارض. فهو ملف PDF/A-3 واحد يحمل في طبقته المرئية صفحة الفاتورة، ويحمل في بنيته الداخلية ملف XML مضمّناً يطابق محتوى الصفحة. المستلم البشري يفتح الملف فيرى الفاتورة، ونظام المستلم الآلي يستخرج الـ XML فيعالجه. النسختان في ملف واحد، فلا انفصال ولا تناقض. هذا المبدأ نفسه تقوم عليه معايير دولية راسخة مثل ZUGFeRD الألماني وFactur-X الفرنسي، وكلها تعتمد ملف PDF/A-3 حاملاً لـ XML مضمّن.
النقطة الجوهرية أن الـ XML المضمّن ليس مرفقاً عابراً مثل صورة تضعها في بريد إلكتروني. إنه يُعرَّف داخل بنية الملف بوصفه التمثيل البديل الرسمي للفاتورة المرئية. هذا التعريف هو ما يميّز التضمين الصحيح عن مجرد إلصاق ملف. وللوصول إليه نحتاج إلى فهم عدة كائنات في بنية PDF تعمل معاً.
يترتب على هذا المبدأ شرط ضمني مهم: تطابق المحتوى بين الطبقتين. الصفحة المرئية وملف الـ XML المضمّن يجب أن يحملا البيانات ذاتها: المبالغ نفسها، والبنود نفسها، والرقم الضريبي نفسه. أي تباين بينهما يجعل الفاتورة متناقضة مع ذاتها، فالموظف يرى رقماً وينقل النظام رقماً آخر. لهذا لا يُبنى التمثيلان بشكل منفصل، بل يُولَّدان من مصدر بيانات واحد، فتكون الصفحة المرئية عرضاً بصرياً لنفس البيانات التي يحملها الـ XML. هذا التطابق شرط عملي لقبول الفاتورة في معاملات الأعمال، لا تفصيلاً شكلياً.
الكائنات الأربعة التي تبني التضمين
يقوم تضمين ملف داخل PDF/A-3 على سلسلة من الكائنات (Objects) المترابطة. كل كائن قاموس (Dictionary) يحمل أزواج مفتاح وقيمة، ويشير إلى الكائن التالي في السلسلة. فهم هذه السلسلة شرط لتوليد ملف صحيح أو لتشخيص ملف مرفوض. الكائنات الأربعة هي:
- تدفق الملف المضمّن (Embedded File Stream): الكائن الذي يحمل بايتات ملف الـ XML نفسها، من نوع
/EmbeddedFile. - قاموس مواصفات الملف (File Specification Dictionary): الكائن الذي يصف الملف المضمّن: اسمه، علاقته بالمستند، نوعه، من نوع
/Filespec. - شجرة أسماء الملفات المضمّنة (EmbeddedFiles Name Tree): الفهرس الذي يسجّل الملف المضمّن في كتالوج المستند ليجده القارئ.
- مصفوفة الملفات المرافقة (Associated Files Array): المصفوفة التي تربط الملف بالمستند أو بالصفحة بوصفه ملفاً مرافقاً، عبر مفتاح
/AF.
تعمل هذه الكائنات معاً لتُجيب عن ثلاثة أسئلة: أين بايتات الملف؟ وما اسمه وعلاقته؟ وكيف يجده القارئ ويعرف أنه ملف مرافق لا مجرد مرفق؟ نتناول كلاً منها بالترتيب.
الكتالوج (Catalog) يحوي مصفوفة /AF
شجرة أسماء الملفات المضمّنة /EmbeddedFiles
قاموس مواصفات الملف /Filespec
مجرى الملف المضمّن /EmbeddedFile
تدفق الملف المضمّن: أين تُحفظ بايتات XML
في قلب التضمين يوجد كائن من نوع تدفق (Stream) يحمل المحتوى الفعلي لملف الـ XML بايتاً بايتاً. هذا الكائن يحمل قاموساً يصفه يليه البايتات الخام بين كلمتي stream وendstream. القاموس يحدد نوع الكائن الفرعي بأنه /EmbeddedFile، ويحدد نوع المحتوى عبر مفتاح /Subtype، ويسجّل الطول وبيانات إضافية اختيارية مثل تاريخ الإنشاء وحجم الملف الأصلي.
لاحظ قيمة /Subtype. تكتب أنواع MIME داخل PDF بترميز خاص يستبدل المحرف / بالتسلسل #2F، فيصبح text/xml مكتوباً text#2Fxml. هذا تفصيل دقيق يخطئ فيه من يكتب البنية يدوياً، فينتج ملف يفشل التحقق. بعض المولّدات تستخدم application#2Fxml بدلاً منه، وكلاهما مقبول ما دام يصف محتوى الملف بدقة.
قاموس /Params اختياري لكنه مستحسن. يحمل بيانات وصفية عن الملف الأصلي قبل التضمين: حجمه بالبايت في /Size، وتاريخ آخر تعديل في /ModDate، وأحياناً بصمة تحقق (Checksum). هذه البيانات تساعد النظام المستخرِج على التحقق من سلامة الملف بعد استخراجه، ومقارنة حجمه بما هو مسجّل.
قاموس مواصفات الملف: بطاقة هوية الـ XML المضمّن
تدفق الملف وحده لا يكفي. يحتاج المستند إلى كائن يصف هذا التدفق: ما اسم الملف الظاهر للمستخدم، وأين يجد بايتاته، وما علاقته بالمستند. هذا الكائن هو قاموس مواصفات الملف من نوع /Filespec. هو بطاقة هوية الملف المضمّن، والكائن المركزي الذي تدور حوله بقية السلسلة.
نفكّك مفاتيح هذا القاموس واحداً واحداً، لأن كلاً منها يحمل معنى يؤثر على قبول الملف:
/Type /Filespec: يعلن أن هذا الكائن قاموس مواصفات ملف. شرط في PDF/A-3./Fو/UF: اسم الملف كما يظهر للمستخدم./Fالصيغة التقليدية، و/UFصيغة Unicode الأحدث. ينبغي تطابقهما. اسم مثلinvoice.xmlواضح ودال./AFRelationship: أهم مفتاح في التضمين. يحدد علاقة الملف المضمّن بالمستند الحاوي. نفرد له القسم التالي بالكامل./Desc: وصف نصّي قصير للملف. اختياري لكنه مفيد للقارئ البشري الذي يتصفح المرفقات./EF(Embedded File): القاموس الذي يربط مواصفات الملف بتدفق البايتات الفعلي. القيمة5 0 Rمرجع غير مباشر يشير إلى الكائن رقم 5 الذي يحمل بايتات XML. هنا تكتمل الحلقة بين الوصف والمحتوى.
المرجع 5 0 R هو ما يسمى مرجعاً غير مباشر (Indirect Reference) في بنية PDF. الرقم الأول معرّف الكائن، والثاني رقم الجيل، والحرف R يدل على أنه إشارة لا قيمة مباشرة. بهذه الإشارة يربط قاموس /Filespec نفسه بتدفق /EmbeddedFile دون تكرار البايتات.
مفتاح /AFRelationship: ما الذي يجعل الملف مرافقاً لا مجرد مرفق
هذا المفتاح هو جوهر ما يميّز ملف الفاتورة المختلط الصحيح. يحدد /AFRelationship طبيعة العلاقة بين الملف المضمّن والمحتوى المرئي للمستند. المعيار ISO 19005-3 يعرّف عدة قيم ممكنة لهذا المفتاح، أبرزها:
/Source: الملف المضمّن هو المصدر الذي اشتُقّت منه الصفحة المرئية./Data: الملف يحمل بيانات منظّمة تُستخدم لاستخراج محتوى المستند./Alternative: الملف تمثيل بديل لنفس محتوى الصفحة المرئية، بصيغة أخرى تقرأها الآلة./Supplement: الملف محتوى تكميلي يضيف إلى الصفحة دون أن يكون تمثيلاً بديلاً لها./Unspecified: العلاقة غير محددة. لا يُنصح بها في الفواتير لأنها تترك القارئ بلا دلالة.
في فاتورة الأعمال، القيمة الصحيحة عادةً هي /Alternative أو /Data بحسب المعيار الذي تتبعه. المنطق وراء /Alternative أن ملف الـ XML ليس مرفقاً منفصلاً، بل هو الفاتورة نفسها معبَّراً عنها بصيغة تقرأها الأنظمة. الصفحة المرئية وملف الـ XML يحملان المحتوى ذاته، أحدهما للإنسان والآخر للآلة. هذا التعريف بالتحديد هو ما يحول الملف من «PDF فيه مرفق» إلى «فاتورة مختلطة معترف بها».
الخطأ الشائع هنا أن يضمّن المطوّر ملف XML دون ضبط /AFRelationship، أو أن يتركه على قيمة لا تعبّر عن العلاقة الحقيقية. النتيجة ملف قد يفتحه قارئ PDF عادي ويرى المرفق، لكن نظاماً يبحث عن فاتورة مرافقة لن يتعرّف عليها بوصفها التمثيل البديل المعتمد. الضبط الصحيح لهذا المفتاح شرط في قبول الفاتورة لدى الأنظمة المتوافقة مع المعيار.
| القيمة | الدلالة |
|---|---|
| /Source | المصدر الأصلي للمستند |
| /Data | بيانات تابعة |
| /Alternative | نسخة بديلة (موصى بها للفاتورة) |
| /Supplement | مكمّل |
| /Unspecified | غير محدّد |
مصفوفة الملفات المرافقة: ربط الملف بالمستند
تعريف ملف بقاموس /Filespec سليم لا يكفي وحده ليُعدّ الملف مرافقاً معترفاً به. يجب أن يُسجَّل في مصفوفة الملفات المرافقة عبر مفتاح /AF على مستوى المستند، أو على مستوى صفحة بعينها. هذه المصفوفة هي ما أضافه المعيار PDF/A-3 على وجه التحديد لدعم الملفات المرافقة، وهي ما يميّزه عن الإصدارات الأقدم.
كائن الكتالوج (Catalog) هو جذر بنية المستند. مفتاح /AF هنا مصفوفة تحوي مرجعاً واحداً 6 0 R يشير إلى قاموس مواصفات الملف الذي عرّفناه. بهذا التسجيل يصبح الملف مرافقاً على مستوى المستند بأكمله، أي مرتبطاً بالفاتورة ككل لا بصفحة بعينها. في الفاتورة، حيث يمثّل ملف الـ XML الفاتورة كلها، هذا هو الربط المنطقي الصحيح.
يمكن بدل ذلك ربط الملف المرافق بصفحة محددة بوضع مفتاح /AF داخل قاموس الصفحة نفسها. لكن في الفاتورة المختلطة، الربط على مستوى المستند هو الممارسة المعتمدة، لأن البيانات المنظّمة تخص الوثيقة كاملة. الجمع بين تسجيل الملف في مصفوفة /AF وفي شجرة الأسماء (التالية) هو ما يضمن أن كل قارئ متوافق سيجد الملف ويتعرّف على علاقته.
شجرة أسماء الملفات المضمّنة: كيف يجد القارئ الملف
إلى جانب مصفوفة /AF، يجب أن يُسجَّل الملف في شجرة أسماء الملفات المضمّنة (EmbeddedFiles Name Tree). هذه الشجرة فهرس يربط اسم كل ملف مضمّن بقاموس مواصفاته، ويعيش داخل قاموس الأسماء (Names Dictionary) في الكتالوج. هي الآلية التقليدية التي تعتمدها قارئات PDF لعرض قائمة المرفقات للمستخدم.
قاموس الأسماء 3 0 obj يشير عبر مفتاح /EmbeddedFiles إلى شجرة الأسماء 4 0 obj. هذه الأخيرة تحمل مصفوفة /Names تتكون من أزواج: اسم الملف كسلسلة نصية، يليه مرجع قاموس مواصفاته. هنا الزوج (invoice.xml) 6 0 R يربط الاسم المعروض بالقاموس رقم 6 الذي يحمل كل تفاصيل الملف.
قد يبدو وجود الملف في مكانين، مصفوفة /AF وشجرة الأسماء، تكراراً. لكنهما يخدمان غرضين مختلفين. شجرة الأسماء آلية قديمة تجعل الملف ظاهراً كمرفق في أي قارئ PDF. مصفوفة /AF آلية أحدث تعرّفه كملف مرافق ذي علاقة محددة. القارئ القديم يرى المرفق عبر الشجرة، والقارئ المتوافق مع PDF/A-3 يفهم العلاقة عبر /AF. تسجيل الملف في الاثنين يضمن أوسع توافق ممكن.
الفرق بين الملف المرافق والمرفق التقليدي
قبل المعيار PDF/A-3 كان بإمكان ملف PDF أن يحمل مرفقات عبر شجرة الأسماء وحدها، أو عبر تعليقات مرفقات الملف (File Attachment Annotations) المرتبطة بنقطة على صفحة. هذه المرفقات التقليدية ملفات يحملها المستند دون أن تربطها به علاقة دلالية. القارئ يراها كمشابك ورق على هامش الوثيقة، ولا يعرف هل هي مصدر المحتوى أم بيانات مكمّلة أم نسخة بديلة.
المعيار PDF/A-3 نقل هذه الملفات من هامش الوثيقة إلى صلب بنيتها. الملف المرافق ليس مشبك ورق، بل جزء معرّف من المستند له علاقة منصوص عليها عبر /AFRelationship، ومسجّل في مصفوفة /AF على مستوى المستند أو الصفحة. هذا التحول الدلالي هو ما مكّن الفاتورة المختلطة. فلولا العلاقة المحددة، لما استطاع نظام المستلم أن يميّز ملف الـ XML الذي يمثّل الفاتورة من أي ملف آخر قد يكون ملصقاً بالمستند لغرض مختلف.
عملياً، هذا يعني أن المطوّر لا يكفيه أن «يرفق» ملف XML بالطريقة القديمة. لو فعل، لأنتج ملفاً يفتحه قارئ PDF عادي ويرى المرفق، لكنه يفشل أمام نظام يبحث عن فاتورة مرافقة معتمدة. الفرق ليس في وجود الملف، بل في كيفية تعريفه وتسجيله وربطه. هذا بالضبط ما تضيفه سلسلة الكائنات التي شرحناها على المرفق التقليدي.
ترتيب التضمين مع التوقيع التشفيري
الفاتورة الإلكترونية لا تكتفي بتضمين XML، بل تحمل توقيعاً تشفيرياً يضمن سلامتها وعدم التلاعب بها بعد الإصدار. هنا يبرز سؤال الترتيب: هل يُضمَّن الـ XML قبل التوقيع أم بعده؟ الإجابة حاسمة، لأن خطأ الترتيب يُبطل التوقيع.
القاعدة أن يكتمل بناء بنية الملف، بما فيها تضمين الـ XML وتسجيله في مصفوفة الملفات المرافقة، قبل تطبيق التوقيع التشفيري. التوقيع يحسب بصمة على محتوى الملف في حالته النهائية. لو أُضيف الملف المضمّن بعد التوقيع، لتغيّر محتوى المستند، فتصبح البصمة الموقّعة غير مطابقة، ويُرفض التوقيع عند التحقق. لذلك يكون التضمين خطوة سابقة على الختم، لا لاحقة له.
هذا الترتيب يفسّر لماذا يُنصح بترك توليد الفاتورة لنظام معتمد. فبناء البنية ثم التوقيع ثم التحقق سلسلة متتابعة، أي خلل في تسلسلها يُسقط إما صفة PDF/A-3 وإما صحة التوقيع. النظام المعتمد ينفّذ هذه الخطوات بالترتيب الصحيح آلياً، فيخرج الملف موقّعاً ومتوافقاً ومحمّلاً بالـ XML المضمّن في عملية واحدة متّسقة.
دع نظامك يبني بنية PDF/A-3 الصحيحة آلياً
بدل بناء سلسلة الكائنات يدوياً والمخاطرة بمخالفة تُسقط صفة الفاتورة، يولّد قيود فاتورة PDF/A-3 متوافقة مع الهيئة بـ XML مضمّن وعلاقة ملفات مرافقة مضبوطة تلقائياً.
كيف يستخرج النظام المستلم ملف XML
الغاية من كل هذه البنية أن يستطيع نظام المستلم استخراج ملف الـ XML آلياً ومعالجته. الاستخراج يسير عكس الترتيب الذي بنينا به الملف. النظام يبدأ من جذر المستند ويتتبّع المراجع حتى يصل إلى البايتات. الخطوات بالترتيب:
- يفتح النظام كائن الكتالوج (Catalog) ويبحث عن مفتاح
/AF. وجوده يعني أن المستند يحمل ملفات مرافقة. - يتبع المرجع في مصفوفة
/AFإلى قاموس مواصفات الملف/Filespec. - يقرأ مفتاح
/AFRelationshipليعرف طبيعة الملف. قيمة/Alternativeأو/Dataتدل على أنه التمثيل المنظّم للفاتورة. - يتبع مفتاح
/EFثم مفتاحه الفرعي/Fإلى تدفق/EmbeddedFileالحامل للبايتات. - يقرأ البايتات بين
streamوendstream، ويفكّ ضغطها إن كانت مضغوطة، فيحصل على نص XML الخام. - يتحقق من سلامة الملف بمقارنة حجمه بقيمة
/Sizeفي/Paramsإن وُجدت، ثم يمرّره على مُحلّل XML لمعالجة الفاتورة.
هذا التسلسل هو ما يجعل الملف المختلط قابلاً للمعالجة الآلية الكاملة. النظام لا يحتاج إلى أن يقرأ الصفحة المرئية أو يفسّر الرسوم. يكفيه أن يتبع سلسلة المراجع ليصل إلى بيانات الفاتورة المنظّمة. ولأن المعيار يحدد هذا المسار بدقة، فإن أي نظام متوافق يستخرج الملف بالطريقة نفسها، بصرف النظر عن البرنامج الذي ولّد الفاتورة.
تظهر هنا قيمة ضبط /AFRelationship الذي شرحناه. لو تركه المولّد على قيمة خاطئة، فقد يستخرج النظام الملف لكنه لن يثق بأنه التمثيل البديل المعتمد، فيتعامل معه كمرفق عابر. الضبط الصحيح هو ما يجعل الاستخراج موثوقاً ومعتمداً، لا مجرد قراءة بايتات.
فتح الكتالوج
قراءة مصفوفة /AF
الوصول إلى /Filespec
استخراج مجرى XML وتمريره للمحلّل
الأخطاء الشائعة التي تُسقط صفة الفاتورة
بناء سلسلة الكائنات يدوياً عرضة لمخالفات دقيقة تجعل الملف يفشل التحقق أو يُرفض لدى الأنظمة المتوافقة. أكثرها تكراراً:
- غياب مصفوفة
/AF: تضمين الملف في شجرة الأسماء فقط دون تسجيله كملف مرافق. النتيجة مرفق عادي لا فاتورة مرافقة معترف بها. - قيمة
/AFRelationshipخاطئة أو مفقودة: ترك المفتاح أو ضبطه على/Unspecifiedيفقد الملف دلالته كتمثيل بديل للفاتورة. - ترميز
/Subtypeغير سليم: كتابةtext/xmlدون استبدال/بـ#2Fينتج قيمة غير صالحة في بنية PDF. - عدم تطابق
/Fو/UF: اسمان مختلفان للملف يربكان بعض القارئات. - خطوط غير مضمّنة في الصفحة المرئية: مخالفة لشرط PDF/A الأساسي، تُسقط الصفة بصرف النظر عن صحة التضمين.
- محتوى ممنوع في الصفحة: جافاسكربت أو محتوى ديناميكي أو تشفير، وكلها يمنعها المعيار.
للتحقق من سلامة الملف بعد توليده، مرّره على أداة تحقق متخصصة مثل veraPDF بالمستوى المطلوب. تُخرج الأداة تقريراً يفصّل كل مخالفة عن المعيار، بما في ذلك مشكلات التضمين وعلاقة الملفات المرافقة. هذه خطوة لا غنى عنها قبل إرسال الفاتورة في بيئة الإنتاج.
الخلاصة العملية أن توليد ملف PDF/A-3 يدوياً في بيئة الإنتاج محفوف بالمخاطر. سلسلة الكائنات دقيقة، وأي خطأ في مرجع أو ترميز أو علاقة يُسقط صفة الفاتورة دون إنذار ظاهر للمستخدم. الأفضل أن يتولى نظام محاسبي معتمد بناء هذه البنية تلقائياً.
كيف يتعامل قيود مع تضمين XML داخل PDF/A-3
يولّد قيود فاتورة PDF/A-3 متوافقة مع متطلبات الهيئة دون أن يضطر المطوّر أو المحاسب إلى التعامل مع سلسلة الكائنات يدوياً. يبني النظام تدفق الملف المضمّن، وقاموس مواصفات الملف، ويضبط مفتاح /AFRelationship على القيمة الصحيحة، ويسجّل الملف في مصفوفة الملفات المرافقة وشجرة الأسماء معاً، فينتج ملفاً مختلطاً صالحاً للقراءة البشرية والمعالجة الآلية في آن.
إلى جانب التضمين، يتولى قيود ضبط بقية اشتراطات الفاتورة الإلكترونية: تضمين الخطوط في الصفحة المرئية، والتوقيع التشفيري، وإدارة شهادة معرّف الختم التشفيري (CSID) آلياً، وتوليد رمز الاستجابة السريعة، وربط الفاتورة بمنصة فاتورة. هكذا يخرج الملف متوافقاً مع الهيئة من أول توليد، دون مخاطر المخالفات الدقيقة التي يقع فيها البناء اليدوي.
أسئلة شائعة
ما الفرق بين الملف المضمّن (EmbeddedFile) والملف المرافق (Associated File)؟
الملف المضمّن مفهوم قديم يعني أن بايتات ملف محفوظة داخل المستند. الملف المرافق مفهوم أضافه PDF/A-3، ويعني ملفاً مضمّناً مسجّلاً في مصفوفة /AF وله علاقة محددة بالمحتوى عبر /AFRelationship. كل ملف مرافق ملف مضمّن، لكن ليس كل ملف مضمّن مرافقاً.
ما القيمة الصحيحة لمفتاح /AFRelationship في فاتورة الأعمال؟
عادةً /Alternative، لأن ملف الـ XML تمثيل بديل للصفحة المرئية يحمل المحتوى ذاته بصيغة تقرأها الآلة. بعض المعايير تستخدم /Data بدلاً منها. الأهم ألا تُترك القيمة فارغة أو على /Unspecified.
لماذا يُسجَّل الملف في مصفوفة /AF وشجرة الأسماء معاً؟
شجرة الأسماء تجعل الملف ظاهراً كمرفق في أي قارئ PDF قديم، ومصفوفة /AF تعرّفه كملف مرافق ذي علاقة محددة للقارئ المتوافق مع PDF/A-3. التسجيل في الاثنين يضمن أوسع توافق بين الأنظمة.
هل أحتاج إلى ضغط ملف XML قبل تضمينه؟
الضغط اختياري. يمكن تضمين الـ XML خاماً أو مضغوطاً بمرشّح مثل /FlateDecode يُعلَن في قاموس التدفق. الضغط يقلّل حجم الملف، والنظام المستخرِج يفكّه آلياً قبل قراءة البايتات.
هل يمكنني بناء بنية التضمين يدوياً كمطوّر؟
تقنياً نعم، لكن لا يُنصح به في الإنتاج. سلسلة الكائنات دقيقة، وأي خطأ في مرجع أو ترميز أو علاقة يُسقط صفة الفاتورة. الأفضل الاعتماد على نظام محاسبي معتمد يبني البنية متوافقة مع الهيئة آلياً.
كيف أتأكد أن التضمين سليم قبل الإرسال؟
مرّر الملف على أداة تحقق مثل veraPDF بالمستوى المطلوب. تفحص الأداة بنية التضمين وعلاقة الملفات المرافقة وبقية اشتراطات المعيار، وتُخرج تقريراً بكل مخالفة. عالج كل خطأ قبل اعتماد الملف في بيئة الإنتاج.
خلاصة عملية
تضمين XML داخل PDF/A-3 ليس مجرد إلصاق ملف، بل بناء سلسلة كائنات مترابطة: تدفق /EmbeddedFile يحمل البايتات، وقاموس /Filespec يصفه، ومفتاح /AFRelationship يحدد علاقته بالفاتورة، ومصفوفة /AF وشجرة الأسماء تسجّلانه ليجده القارئ ويتعرّف عليه. هذه البنية بالتحديد هي ما يحوّل ملفاً عادياً إلى فاتورة مختلطة معترف بها.
الضبط الصحيح لكل مفتاح شرط في قبول الفاتورة ومعالجتها آلياً. وإذا أردت التعمق في صيغ التمثيل التقني للفاتورة، فراجع توثيق فاتورة XML: التنسيق التقني للفاتورة الإلكترونية وتوثيق بنية الفاتورة الإلكترونية. ولفهم الصيغة الحاوية نفسها وخصائص أرشفتها، ابدأ من توثيق صيغة PDF/A-3 في الفاتورة الإلكترونية. ولرؤية الصورة الكاملة لمتطلبات الفوترة الإلكترونية في السعودية، راجع صفحة برنامج الفاتورة الإلكترونية من قيود.
