BR-E-01الفاتورة فيها توريدات معفاة من الضريبة ولا تفصيل ضريبياً لها
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-E-01.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151 or BT-95 or BT-102) is "Exempt from VAT" shall contain at least one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT".
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
الفاتورة فيها توريدات معفاة من الضريبة ولا تفصيل ضريبياً لها
صورة القيمة في التقريرbreakdown_missingالتفصيل الضريبي غير موجود
ما الخلل
يرد رمز الفئة E، أي المعفى من الضريبة، في المستند تحت النظام الضريبي لضريبة القيمة المضافة، سواء على الفئة المصنَّفة لبند فاتورة في cac:ClassifiedTaxCategory أو على فئة خصم أو رسم في cac:TaxCategory، ولا يوجد عنصر cac:TaxSubtotal له مباشرة تحت كتلة cac:TaxTotal الخاصة بالفاتورة. وتشترط القاعدة BR-E-01 من معيار EN 16931، التي تنفّذها هيئة الزكاة والضريبة والجمارك، تفصيلاً واحداً على الأقل لهذه الفئة على كل فاتورة تستعملها. ويرصد الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة ذلك تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. والعدّ لا يشمل إلا التفاصيل الواقعة مباشرة تحت جذر المستند، فالعنصر cac:TaxSubtotal المكتوب داخل بند فاتورة لا يفي بالقاعدة. وكان الإصدار 3.0.8 يشترط تفصيلاً واحداً بالضبط بدرجة خطأ، ويَعُدّ فئة التفصيل نفسه استعمالاً للفئة؛ أما الإصدار 3.4.8 فيشترط تفصيلاً واحداً على الأقل، ولا يُطلِق القاعدة إلا بند أو خصم أو رسم من هذه الفئة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
يجب أن يحمل التفصيل الضريبي عنصر cac:TaxSubtotal واحداً لكل فئة مستعملة، والفئة المعفاة تحتاج إلى كتلتها كذلك: مبلغ خاضع في cbc:TaxableAmount ومبلغ ضريبة صفري في cbc:TaxAmount ورمز الفئة E ورمز سبب إعفاء من قائمة الهيئة للفئة المعفاة، وهو VATEX-SA-29 أو VATEX-SA-29-7 أو VATEX-SA-30، تطلبه قواعد الهيئة نفسها من كل تفصيل معفى. والسبب المتكرّر تصدير يبني التفصيل من سطور الضريبة المقيَّدة، ولا سطور منها للتوريد المعفى. فابنِه من الملخّص لكل فئة.
أكثر من تفصيل ضريبي واحد للفئة المعفاة في الفاتورة نفسها
صورة القيمة في التقريرbreakdown_duplicatedالتفصيل الضريبي نفسه مكرَّر
ما الخلل
تحمل الفاتورة أكثر من عنصر cac:TaxSubtotal مرمَّز E، أي معفى من الضريبة، تحت النظام الضريبي لضريبة القيمة المضافة، مباشرة تحت كتلة cac:TaxTotal الخاصة بها. ولا ترصد هذه الملاحظة إلا حزم القواعد السابقة للإصدار 2.0.0: فالقاعدة BR-E-01 في الإصدار 3.0.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك كانت تشترط تفصيلاً واحداً بالضبط لكل فئة، والإصدار 3.4.8 الذي تقرؤه حزمة القواعد 2.0.0 يشترط تفصيلاً واحداً على الأقل، فلا يحمل هذه الملاحظة تقرير صادر عن الحزمة 2.0.0. ولا يزال معيار EN 16931 يصف التفصيل الضريبي كتلةً واحدة لكل فئة لا لكل سبب إعفاء.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
لا شيء يلزم تغييره من أجل حزمة القواعد 2.0.0 في هذا الشأن. وإن دمجت الكتل فاجمع بحرف الفئة وحده لا بسبب الإعفاء أو رمزه، واجمع المبالغ الخاضعة في عنصر cac:TaxSubtotal واحد، واستقرّ على رمز السبب الواحد الذي ستحمله تلك الكتلة.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not(((exists(//cac:AllowanceCharge/cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E']) or exists(//cac:ClassifiedTaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E'])) and (count(cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E']) > 0)) or (not(//cac:AllowanceCharge/cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E']) and not(//cac:ClassifiedTaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E'])))
التعبير المذكور في التقرير
((exists(//cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E']) or exists(//cac:ClassifiedTaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E'])) and (count(cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E']) = 1)) or (not(//cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E']) and not(//cac:ClassifiedTaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID[normalize-space(.) = 'E']))
العناصر التي يُقيَّم عليها
/ubl:Invoice | /cn:CreditNote
المصدر
vendor/zatca/schematron/CEN-EN16931-UBL.xsl:791
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.