عبارة "فواتيرك يجب أن تكون بصيغة UBL 2.1" وعبارة "فواتيرك يجب أن تكون متوافقة مع PINT-OM" تبدوان وكأنهما المتطلب نفسه. لكنهما ليستا الشيء نفسه تمامًا، والفرق بينهما هو بالضبط المكان الذي تخطئ فيه كثير من تطبيقات الفوترة الإلكترونية. هذا هو الشرح غير التقني لما يجب أن تحمله فاتورتك فعليًا.
لماذا تُعدّ الصيغة بهذه الأهمية
الفوترة الإلكترونية بموجب فوترة ليست "أرسل ملف PDF منسّقًا بشكل جيد". فكل فاتورة تنتقل عبر شبكة Peppol كمستند منظّم قابل للقراءة الآلية، ويخضع للتحقق التلقائي في أكثر من نقطة — من نقطة وصول المُرسِل، ونقطة وصول المُستقبِل، ومن هيئة الضرائب نفسها عبر مسار مستند البيانات الضريبية (راجع دليلنا الشامل عن فوترة لمعرفة نموذج الشبكة الكامل). فإذا لم يحمل المستند البنية والمعرّفات الصحيحة بدقة، فقد يفشل في التحقق ويُرفض — وهذه مشكلة امتثال، لا مجرد إزعاج تقني.
UBL 2.1: البنية الأساسية
UBL (لغة الأعمال الموحّدة) 2.1 هو معيار XML الأساسي الذي يحدد الشكل العام لمستند الفاتورة — الترويسة، بيانات المورّد، بيانات العميل، بنود الفاتورة، إجماليات الضريبة، الإجماليات المالية. وهو معيار راسخ ومستخدم دوليًا؛ إلا أنه بحد ذاته عام. فـ UBL 2.1 وحده لا "يعرف" شيئًا عن عُمان أو معدلات ضريبة القيمة المضافة أو قواعد فوترة الخاصة — إنه الهيكل العظمي، لا المستند النهائي.
PINT-OM: الطبقة الخاصة بعُمان فوق ذلك الهيكل
PINT (Peppol الدولي) هو إطار عمل بنته Peppol خصيصًا حتى يمكن تكييف البنية القائمة على UBL نفسها مع قواعد ضريبية مختلفة لكل دولة، دون أن تبتكر كل دولة صيغتها الخاصة غير المتوافقة. يوسّع PINT نموذج الفوترة الأساسي لـ Peppol عبر نظام تحقق متعدد الطبقات: القواعد العامة تُطبَّق في كل مكان، وكل دولة تحصل على تخصيصها الخاص — مجموعة قواعد إضافية خاصة بها — تُضاف فوق المعيار الأساسي لا أن تحل محله.
PINT-OM هو تلك الطبقة الخاصة بعُمان. وهو ما يحوّل مستند UBL 2.1 العام إلى مستند يستوفي فعليًا متطلبات ضريبة القيمة المضافة ونظام فوترة في عُمان. وبشكل محدد، تحمل فاتورة عُمانية متوافقة معرّفات محددة تُخبر كل نظام في السلسلة بالضبط بأي مجموعة قواعد يجب التحقق منها:
| الحقل | القيمة المطلوبة (فاتورة بيع عادية) |
|---|---|
CustomizationID (داخل ملف XML نفسه) | urn:peppol:pint:billing-1@om-1 |
ProfileID | urn:peppol:pint:billing |
| المعرّف الكامل لنوع المستند (في غلاف الشبكة) | urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:peppol:pint:billing-1@om-1::2.1 |
الفاتورة ذاتية الإصدار (حيث يُصدر المشتري الفاتورة نيابة عن المورّد — وهو سيناريو حقيقي ومدعوم) تستخدم قيمة CustomizationID مختلفة: urn:peppol:pint:selfbilling-1@om-1. وتتبع إشعارات الدائن (Credit Notes) النمط المكافئ الخاص بنوع مستندها. فإذا وضعت المعرّف الخاطئ، فإن المستند "يُخبر" كل جهة تحقق لاحقة بأن تتحقق منه وفق مجموعة قواعد خاطئة — حتى لو كانت كل الحقول الأخرى صحيحة تمامًا.
PDF/A-3: النصف القابل للقراءة البشرية
الفاتورة المتوافقة ليست ملف XML فقط. بل تُسلَّم أيضًا بصيغة PDF/A-3 — وهو معيار الأرشفة طويلة الأمد لملفات PDF، وتم اختياره تحديدًا لأن PDF/A-3 يسمح بتضمين ملف داخل ملف PDF نفسه. وهذا يعني أن النسخة القابلة للقراءة البشرية ومستند PINT-OM XML القابل للقراءة الآلية يمكن أن ينتقلا كملف واحد، بدلًا من مستندين منفصلين قد ينحرفان نظريًا عن بعضهما بمرور الوقت.
ماذا يعني هذا عمليًا
إذا كنت تُقيّم مزوّد خدمة أو نظامًا داخليًا، فإن عبارة "نحن ننتج فواتير UBL" ليست نفس الادعاء بأن "نحن ننتج فواتير متوافقة مع PINT-OM". الأسئلة الجديرة بالطرح محددة:
- هل يحمل ملف XML قيمة
CustomizationIDالدقيقةurn:peppol:pint:billing-1@om-1(أو مكافئها لذاتي الإصدار) — لا مجرد مساحة اسم UBL عامة؟ - هل النسخة القابلة للقراءة البشرية فعليًا بصيغة PDF/A-3 مع تضمين ملف XML بداخلها، لا مجرد PDF عادي يُنتج بشكل منفصل؟
- هل يتحقق النظام من مطابقة المستند لحزم قواعد Schematron الرسمية الخاصة بـ PINT-OM قبل الإرسال، بدلًا من افتراض صحة الملف لمجرد أنه لم يُصدر خطأ؟
أخطاء شائعة
- نسخ قيم من أمثلة XML دون التحقق منها مقابل قوائم الأكواد الفعلية. حتى الملفات الرسمية للأمثلة ليست محصّنة من هذا — إحدى مجموعات أمثلة PINT-OM المتداولة على نطاق واسع تستخدم رمز نظام العنوان الإلكتروني
0235في أحد الأمثلة، بينما قائمة أكواد EAS المعتمدة لدى Peppol تسجّل هذا الرمز فعليًا كـ"الرقم الضريبي الإماراتي"، لا كمعرّف عُماني. وهو خطأ نسخ ولصق يسهل توارثه إذا بنيت نظامك اعتمادًا على مثال بدلًا من قائمة الأكواد الفعلية. - التعامل مع "UBL" و"PINT-OM" كمتطلبين متطابقين. يمكن لمستند أن يكون صحيحًا تمامًا كملف UBL 2.1 عام، ومع ذلك يفشل في التحقق الخاص بـ PINT-OM في عُمان، لأن القواعد الخاصة بالدولة تُضاف فوق المعيار، لا تُطبَّق تلقائيًا.
- إنتاج ملف PDF وملف XML بشكل مستقل عن بعضهما، بدلًا من تضمين XML داخل ملف PDF/A-3 حقيقي — وهذا ينتج من الناحية التقنية مستندين منفصلين بدلًا من المستند المتوافق الواحد الذي يصفه المعيار.
- تجاهل أنواع الفاتورة ذاتية الإصدار وإشعارات الدائن لأن البناء الأولي غطّى فقط الفواتير العادية — فكل نوع مستند له
CustomizationIDوقواعد Schematron خاصة به؛ ونمط الفاتورة العادية لا يمتد تلقائيًا ليشمل الأنواع الأخرى.
إلى أين تذهب من هنا
للاطلاع على الجانب القانوني والزمني لكل هذا، راجع دليلنا الشامل عن فوترة. ولمعرفة كيفية التحقق مما إذا كان مزوّد الخدمة مؤهلًا فعليًا لإنتاج هذه الصيغة بشكل صحيح — لا مجرد الادعاء بذلك — راجع دليلنا حول مزوّد الخدمة المعتمد من هيئة الضرائب العُمانية.
مصطلح غير مألوف؟ راجع معجم مصطلحات الفوترة الإلكترونية في عُمان.
المصادر: docs.peppol.eu/poac/om؛ test-docs.peppol.eu/pint/pint-om؛ وثائق مواصفة Peppol PINT.

