Odoo: فحص ملف الفاتورة الإلكترونية

الملف الذي يحتاجه مطابق

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

ما تقوله الوثائق المنشورة

• توثّق Odoo الفوترة الإلكترونية المطلوبة من الهيئة بوصفها جزءاً من توطينها الخاص بالمملكة العربية السعودية؛ فإن كان هذا ما تعمل به، فملف XML يُنشأ داخل Odoo نفسها لا في منتج منفصل (وثائق Odoo، المملكة العربية السعودية).
• وتقرأ الوثائق بيانات البائع من سجل المنشأة وبيانات المشتري من سجل العميل، فالقيمة الغائبة من ملف XML غائبة في الغالب من أحد هذين السجلين أولاً (بيانات المنشأة).
• وتقول الوثائق إن الفواتير المرفوضة وحدها هي التي يمكن إعادتها إلى مسودة وتعديلها في Odoo (الاختبار).
• والوثائق التي قُرئت لهذا الدليل هي وثائق الإصدار Odoo 18.0. وكثير من المنشآت تعمل بإصدار أقدم، أو بوحدة للهيئة بناها أحد شركاء Odoo، وقد تقرأ هذه الوحدة قيمها من مواضع أخرى. غير أن عناصر XML التي يجب أن تكتبها هي نفسها، فالفحوص التالية تنطبق عليها كما هي.

أين يوجد الملف عادةً

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

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

افحص الملف كما أنشأه نظامك. فالنسخة التي تُفتح وتُحفظ من جديد في برنامج آخر قد لا تبقى الملف الذي تتسلّمه الهيئة.

ما الذي تتحقق منه في الملف المصدَّر

• عنوان البائع: تحقّق من أن cac:AccountingSupplierParty/cac:Party/cac:PostalAddress يحمل العناصر الستة التي تقرؤها الهيئة: cbc:StreetName وcbc:BuildingNumber وcbc:CityName وcbc:PostalZone وcbc:CitySubdivisionName (الحي) وcac:Country/cbc:IdentificationCode. ويذكر مطابق غياب أحدها بموجب MTB-BR-KSA-09 بدرجة تحذير. ولم يعد الرقم الإضافي (cbc:PlotIdentification) بينها في أداة الفحص الحالية لدى الهيئة، وإن بقي جزءاً من العنوان الوطني.
• وعنوان المشتري في الفاتورة الضريبية لعميل سعودي: العناصر الستة نفسها تحت cac:AccountingCustomerParty، كلٌّ منها موجود غير خالٍ، ويذكرها MTB-BR-KSA-63 بدرجة تحذير.
• يُقرأ معرِّف البائع من cac:PartyIdentification/cbc:ID مع السمة schemeID. تحقّق من أن السمة أحد الرموز CRN أو MOM أو MLS أو SAG أو OTH أو 700 (الرقم 700 الذي يذكره معيار تطبيق XML الصادر عن الهيئة في البند 13.3.1، وتقبله أداة الفحص الحالية لديها)؛ ويذكر MTB-BR-KSA-08 ما عدا ذلك، بدرجة تحذير.
• يُقرأ رقم التسجيل في ضريبة القيمة المضافة من cac:PartyTaxScheme/cbc:CompanyID. تحقّق من أنه الأرقام الخمسة عشر وحدها، يبدأ بالرقم 3 وينتهي به، بلا مسافات ولا شرطات ولا بادئة؛ ويذكر MTB-BR-KSA-40 رقم البائع وMTB-BR-KSA-44 رقم المشتري.
• رمز النوع والعملة. تحقّق من أن cbc:InvoiceTypeCode يحمل 388 أو 381 أو 383، ومن أن cbc:DocumentCurrencyCode والسمة currencyID على كل مبلغ تحمل SAR في الفاتورة المحلية. ويذكر MTB-BR-CL-04 رمز عملة المستند الذي ليس من رموز المعيار ISO 4217.
• وتحقّق من أن السمة name على رمز النوع سبعة محارف أو ثمانية أو تسعة: 01 أو 02، ثم 0 أو 1 لكل راية من رايات المعاملة، مثل 0100000 أو 0200000، ومن أن التصدير لا يحشوها ولا يكتب العنصر بالتنسيق المرتَّب في سطر مستقل؛ ويذكر MTB-STRUCT-01 رمز نوع معاملة الفاتورة.
• التوريدات الخاضعة بنسبة الصفر والمعفاة: يُقرأ رمز السبب من cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode، وهو خاصية من خصائص التفصيل الضريبي لا من خصائص البند. تحقّق من أن كل تفصيل خاضع بنسبة الصفر أو معفى يحمل أحد رموز VATEX-SA المنشورة لفئته؛ ويذكر MTB-BR-KSA-CL-04 الرمز غير المدرج، وMTB-BR-KSA-69 التفصيل الخاضع بنسبة الصفر الذي لا رمز فيه أصلاً، وكلاهما بدرجة تحذير. وأداة الفحص الحالية لدى الهيئة تطلب الرمز وحده، لا نص السبب إلى جواره.
• وتحقّق من أن المستند يحمل كتلة cac:AdditionalDocumentReference قيمة cbc:ID فيها ICV ويحمل عنصر cbc:UUID فيها العدّاد أرقاماً لا غير، ومن أن العدّاد يزيد مع كل مستند يصدر، بما في ذلك الإشعارات الدائنة والمدينة؛ ويذكر MTB-BR-KSA-33 العدّاد الغائب.
• وتحقّق من أن مرجع PIH المجاور له يحمل cac:Attachment/cbc:EmbeddedDocumentBinaryObject بالسمة mimeCode="text/plain" وقيمة غير فارغة بترميز base64، في أول مستند في السلسلة كما في سائرها.
• وتحقّق من أنك تفحص مستنداً من الاتصال الفعلي لا من تشغيل تجريبي أو تشغيل محاكاة: فمستند التجربة ليس هو المستند الذي تتسلّمه الهيئة لاحقاً.

ما الذي تفعله بالملاحظات

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

المصادر

• وثائق Odoo 18.0، التوطينات المالية: المملكة العربية السعودية

قُرئت هذه الصفحات في 2026-09-11. ووثائق المزوِّدين تتغيّر.