BR-CO-10مجموع مبالغ البنود غير مذكور في إجماليات المستند
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-CO-10.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
مجموع مبالغ البنود غير مذكور في إجماليات المستند
صورة القيمة في التقريرtotal_missingالإجمالي غير موجود
ما الخلل
كتلة إجماليات المستند cac:LegalMonetaryTotal لا تحمل العنصر cbc:LineExtensionAmount. وهذا الحقل هو مجموع مبالغ بنود الفاتورة BT-106، وتشترط القاعدة BR-CO-10 من معيار EN 16931، وهي القاعدة التي تنفّذها هيئة الزكاة والضريبة والجمارك، أن يكون هذا الحقل مساوياً لذلك المجموع. ومع غياب القيمة لا يوجد ما يُقارَن فتخفق القاعدة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
يجب أن تحمل كتلة إجماليات المستند كل إجمالي تتوقعه القواعد لا الإجماليات التي يقرؤها عملاؤك وحدها. راجع قالب التصدير في وحدة الفوترة الإلكترونية: فهذه في العادة عملية ربط تكتب الإجمالي المستحق والإجماليات الضريبية وتغفل إجمالي البنود فوقها. والعنصر مطلوب في مخطط UBL أيضاً، فالمستند في هذه الحالة تُرصد عليه هذه الملاحظة وملاحظة فحص المخطط معاً.
مجموع مبالغ البنود لا يطابق بنود الفاتورة
صورة القيمة في التقريرnot_sum_of_linesلا يساوي مجموع البنود
ما الخلل
العنصر cbc:LineExtensionAmount في كتلة cac:LegalMonetaryTotal ليس مجموع قيم cbc:LineExtensionAmount في بنود الفاتورة المفردة. وتجمع القاعدة BR-CO-10 من معيار EN 16931، التي تنفّذها هيئة الزكاة والضريبة والجمارك، مبالغ البنود ثم تقرّب المجموع إلى منزلتين عشريتين وتشترط أن يساويه الإجمالي مساواة تامة. ولا هامش تسامح هنا. ولاحظ كذلك أن الفاتورة الخالية من البنود تماماً تُقارَن بالصفر بدل أن تُتجاوز، فكتلة إجماليات تحمل إجمالي بنود في مستند بلا بنود تخفق هنا أيضاً.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
راجع موضع التقريب في كل رقم. فالهيئة تجمع مبالغ البنود أولاً ثم تقرّب مرة واحدة في النهاية، والنظام الذي يقرّب كل بند إلى منزلتين ثم يجمعها قد يفترق بهللة أو هللتين في فاتورة كثيرة البنود، وكلما زادت البنود زاد الاحتمال. وتحقّق كذلك مما إذا كان خصم أو رسم يُطبَّق على إجمالي الترويسة دون البنود التي جاء منها: فهذا الحقل للبنود وحدها قبل الخصومات والرسوم على مستوى المستند، وموضعها العنصران cbc:AllowanceTotalAmount وcbc:ChargeTotalAmount.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not((xs:decimal(cbc:LineExtensionAmount) = xs:decimal(round(sum(//(cac:InvoiceLine|cac:CreditNoteLine)/xs:decimal(cbc:LineExtensionAmount)) * 10 * 10) div 100)))
التعبير المذكور في التقرير
(xs:decimal(cbc:LineExtensionAmount) = xs:decimal(round(sum(//(cac:InvoiceLine|cac:CreditNoteLine)/xs:decimal(cbc:LineExtensionAmount)) * 10 * 10) div 100))
العناصر التي يُقيَّم عليها
cac:LegalMonetaryTotal
المصدر
vendor/zatca/schematron/CEN-EN16931-UBL.xsl:431
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.