BR-CO-13الإجمالي قبل الضريبة غير مذكور في إجماليات المستند
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-CO-13.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-CO-13]-Invoice total amount without VAT (BT-109) = Σ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108).
فحوص أخرى تُذكر في التقرير نفسه
BR-CO-13
[BR-CO-13]-Invoice total amount without VAT (BT-109) = Σ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108).
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
الإجمالي قبل الضريبة غير مذكور في إجماليات المستند
صورة القيمة في التقريرtotal_missingالإجمالي غير موجود
ما الخلل
كتلة إجماليات المستند cac:LegalMonetaryTotal لا تحمل العنصر cbc:TaxExclusiveAmount. وهذا الحقل هو إجمالي الفاتورة قبل ضريبة القيمة المضافة BT-109، وتشترط القاعدة BR-CO-13 من معيار EN 16931، التي تنفّذها هيئة الزكاة والضريبة والجمارك، أن يكون هذا الحقل مساوياً لإجمالي البنود مضافاً إليه الرسوم ومطروحاً منه الخصومات. ومع غياب القيمة لا يوجد ما يُقارَن فتخفق القاعدة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
راجع قالب التصدير في وحدة الفوترة الإلكترونية: فهذه في العادة عملية ربط تكتب الإجمالي شاملاً الضريبة والمبلغ المستحق وتغفل الإجمالي قبل الضريبة. والعنصر مطلوب في مخطط UBL أيضاً، فالمستند في هذه الحالة تُرصد عليه هذه الملاحظة وملاحظة فحص المخطط معاً.
الإجمالي قبل الضريبة لا يطابق البنود والرسوم والخصومات
صورة القيمة في التقريرnot_lines_plus_charges_less_allowancesلا يساوي البنود مضافاً إليها الرسوم مطروحاً منها الخصومات
ما الخلل
العنصر cbc:TaxExclusiveAmount في كتلة cac:LegalMonetaryTotal ليس إجمالي البنود مضافاً إليه إجمالي الرسوم ومطروحاً منه إجمالي الخصومات. وتفحص القاعدة BR-CO-13 من معيار EN 16931، التي تنفّذها هيئة الزكاة والضريبة والجمارك، أيّاً من هذين الإجماليين الاختياريين يحمله مستندك، ثم تقرّب الناتج إلى منزلتين عشريتين وتشترط تطابقاً تاماً. وثمة حالة أشدّ من غيرها كثيراً ما تُغفل: فحين لا يحمل المستند إجمالي رسوم ولا إجمالي خصومات تشترط الهيئة أن يساوي المبلغ قبل الضريبة إجمالي البنود دون أي تقريب، فإجمالي بنود مكتوب 100.001 مقابل مبلغ قبل الضريبة 100.00 يخفق، بينما كان سيُقرَّب أولاً في كل حالة أخرى.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
ابدأ بالتحقّق من أن المبالغ الداخلة في هذا الجمع هي التي تتوقعها الهيئة: cbc:LineExtensionAmount للبنود، وcbc:ChargeTotalAmount لرسوم المستند، وcbc:AllowanceTotalAmount لخصوماته. ثم راجع عدد المنازل العشرية التي يكتبها نظامك. فإن حمل أي مبلغ ثلاث منازل أو أكثر فاكتبه بمنزلتين؛ فالحالة الأشدّ أعلاه تقارن تلك الأرقام مقارنة صارمة، والمنزلة الثالثة التي تختفي بالتقريب في تقاريرك لا تختفي هنا.
مجموع الرسوم على مستوى المستند فارغ فلا يمكن فحص الإجمالي قبل الضريبة
صورة القيمة في التقريرcharge_total_blankمجموع الرسوم موجود لكنه فارغ
ما الخلل
العنصر cbc:ChargeTotalAmount موجود في كتلة cac:LegalMonetaryTotal لكنه فارغ. والقاعدة BR-CO-13، التي تفحص أن الإجمالي قبل الضريبة (BT-109) يساوي مجموع مبالغ البنود مطروحاً منه الخصومات على مستوى المستند ومضافاً إليه الرسوم على مستوى المستند، ترصد هذه الحالة وحدها قبل أي حساب. وتصنّف الهيئة هذه القاعدة تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. وترصد القاعدة BR-CO-12 العنصر الفارغ نفسه خطأً.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
إما أن تكتب مجموع الرسوم، وهو 0.00 حين لا يحمل المستند رسماً على مستوى المستند، وإما أن تحذف العنصر. والعنصر الفارغ يأتي في العادة من قالب يكتب الوسم دائماً ولا يملؤه إلا حين يوجد رسم.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
exists (cbc:ChargeTotalAmount) and normalize-space(cbc:ChargeTotalAmount)=''
التعبير المذكور في التقرير
((cbc:ChargeTotalAmount) and (cbc:AllowanceTotalAmount) and (xs:decimal(cbc:TaxExclusiveAmount) = round((xs:decimal(cbc:LineExtensionAmount) + xs:decimal(cbc:ChargeTotalAmount) - xs:decimal(cbc:AllowanceTotalAmount)) * 10 * 10) div 100 )) or (not(cbc:ChargeTotalAmount) and (cbc:AllowanceTotalAmount) and (xs:decimal(cbc:TaxExclusiveAmount) = round((xs:decimal(cbc:LineExtensionAmount) - xs:decimal(cbc:AllowanceTotalAmount)) * 10 * 10 ) div 100)) or ((cbc:ChargeTotalAmount) and not(cbc:AllowanceTotalAmount) and (xs:decimal(cbc:TaxExclusiveAmount) = round((xs:decimal(cbc:LineExtensionAmount) + xs:decimal(cbc:ChargeTotalAmount)) * 10 * 10 ) div 100)) or (not(cbc:ChargeTotalAmount) and not(cbc:AllowanceTotalAmount) and (xs:decimal(cbc:TaxExclusiveAmount) = xs:decimal(cbc:LineExtensionAmount)))
العناصر التي يُقيَّم عليها
cac:LegalMonetaryTotal
المصدر
vendor/zatca/schematron/CEN-EN16931-UBL.xsl:470
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.