قواعد التحقق (Validation Rules) للفاتورة

عند بناء نظام يُصدر فواتير إلكترونية متوافقة مع المرحلة الثانية في السعودية، لا يكفي أن يكون ملف XML صحيح البنية. يجب أن يكون منطقيًا وصحيحًا حسابيًا أيضًا. هنا يأتي دور قواعد التحقق (Validation Rules) التي تفرضها هيئة الزكاة والضريبة والجمارك (ZATCA). هذه القواعد تُعرف باسم قواعد العمل (Business Rules) ولها بادئة موحّدة هي BR-KSA في المتطلبات السعودية، وبادئة BR في قواعد المعيار الأوروبي الأساسي الذي بُنيت عليه.

يخلط كثير من المطوّرين بين طبقتين مختلفتين من التحقق: التحقق البنيوي عبر مخطط XSD، والتحقق المنطقي عبر قواعد العمل. الطبقة الأولى تجيب على سؤال «هل البنية سليمة؟»، والثانية تجيب على سؤال «هل المحتوى منطقي وصحيح؟». هذا الدليل يركّز بالكامل على الطبقة الثانية: ما هي قواعد العمل، وكيف تُكتب، وما أشهر رموزها ورسائل أخطائها، وكيف يجتازها نظامك قبل أن تصل الفاتورة إلى منصة فاتورة.

للتعمّق في الطبقة البنيوية، راجع دليلنا المخصص في مخطط الفاتورة (Invoice Schema) والتحقق منه. أما هنا فسنفترض أن الفاتورة اجتازت التحقق من المخطط بالفعل، ونبني فوق ذلك.

ما الفرق الدقيق بين التحقق من المخطط وقواعد العمل؟

الفصل بين الطبقتين ليس تفصيلًا أكاديميًا. كل طبقة تعمل على مستوى مختلف من الفاتورة، وتلتقط نوعًا مختلفًا من الأخطاء، وتُصدر رسائل خطأ بصياغة مختلفة. فهم هذا الفصل يحدد أين تضع منطق التحقق في نظامك.

التحقق من المخطط (Schema Validation) يعتمد على ملف XSD. وظيفته فحص بنية المستند: هل العناصر موجودة؟ هل ترتيبها صحيح؟ هل نوع البيانات في كل حقل مطابق (نص، رقم، تاريخ)؟ هل القيمة ضمن القائمة المغلقة المسموح بها؟ لا يفهم XSD المعنى المحاسبي للأرقام. لو كتبت مبلغ ضريبة سالبًا بصيغة رقم عشري صحيحة، سيمرّ من XSD لأنه «رقم عشري» سليم بنيويًا.

التحقق من قواعد العمل (Business Rules Validation) يعمل على مستوى المعنى. يأخذ القيم التي مرّت من المخطط، ويتحقق من علاقاتها المنطقية: هل مجموع البنود يساوي إجمالي الفاتورة؟ هل قيمة الضريبة تساوي الوعاء الضريبي مضروبًا في النسبة؟ هل الحقل الذي يصبح إلزاميًا عند فئة ضريبية معيّنة موجود فعلًا؟ هذه أسئلة لا يستطيع XSD الإجابة عليها لأنها تتطلب حسابًا ومقارنة بين عدة حقول.

الخلاصة في جملة: المخطط يضمن أن الفاتورة مكتوبة بشكل صحيح، وقواعد العمل تضمن أنها صحيحة فعلًا. الفاتورة قد تكون مكتوبة بشكل سليم تمامًا ومع ذلك تحمل خطأً حسابيًا يجعلها مرفوضة.

جدول مقارنة سريع بين الطبقتين

هذا الجدول يلخّص الفرق العملي الذي يهمّ المطوّر عند تصميم خط التحقق في النظام.

من أين تأتي قواعد العمل؟ مصدران متكاملان

قواعد التحقق التي تطبّقها الهيئة ليست قائمة عشوائية. تأتي من مصدرين يعملان معًا، ويجب أن يلتزم نظامك بهما معًا.

المصدر الأول هو المعيار الأوروبي EN 16931 الذي يحدد النموذج الدلالي الأساسي للفاتورة الإلكترونية. هذا المعيار يحمل مجموعة قواعد عامة برموز تبدأ بـ BR- للقواعد الأساسية، وBR-CO- لقواعد الترابط الحسابي (Calculation)، وBR-S- لقواعد الفئة الضريبية القياسية، وBR-Z- للفئة صفرية النسبة، وBR-E- للفئة المعفاة. الفاتورة السعودية تُبنى على هذا الأساس عبر معيار UBL 2.1.

المصدر الثاني هو القواعد الخاصة بالمملكة التي تضيفها الهيئة فوق المعيار الأوروبي، وتحمل بادئة BR-KSA-. هذه القواعد تعالج متطلبات محلية مثل صيغة الرقم الضريبي السعودي، وحقول التوقيع والختم في المرحلة الثانية، وقواعد رمز QR، ونوع الفاتورة، وحقول الهوية الخاصة بالسوق السعودي.

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

أنواع قواعد التحقق الخمسة الأساسية

قواعد العمل كثيرة، لكنها تقع منطقيًا في خمس عائلات. فهم العائلة قبل القاعدة الفردية يجعل قراءة رسائل الخطأ أسرع، ويساعدك على بناء محرّك تحقق منظّم بدلًا من قائمة شروط مبعثرة.

1. قواعد الوجود الشرطي (Conditional Mandatory)

هذه القواعد تجعل حقلًا معيّنًا إلزاميًا فقط عند تحقق شرط ما. الحقل اختياري في الحالة العامة، لكنه يصبح واجبًا عند ظهور قيمة محددة في حقل آخر.

المثال الأشهر: حقل سبب الإعفاء من الضريبة. لا يُطلب هذا الحقل في الفاتورة العادية، لكنه يصبح إلزاميًا فور أن تصبح الفئة الضريبية لأحد البنود «معفاة» أو «خارج النطاق». القاعدة تقول: «إذا كان رمز الفئة الضريبية يساوي E (معفى)، فيجب وجود نص سبب الإعفاء».

القاعدة BR-S-08 (مبسّطة):
إذا (TaxCategory = "S")
فيجب أن (TaxableAmount > 0)

القاعدة BR-KSA (نمطية، شرطية):
إذا (نوع الفاتورة = "مبسّطة" B2C)
فيجب وجود (حقل رمز QR)

2. قواعد الترابط الحسابي (Calculation)

هذه أهم عائلة وأكثرها تسبّبًا في الرفض. تتحقق من أن المجاميع متّسقة عبر الفاتورة. تحمل عادة بادئة BR-CO- في المعيار الأوروبي.

المنطق بسيط لكنه صارم: مجموع مبالغ البنود يجب أن يساوي إجمالي الفاتورة قبل الضريبة، ومجموع مبالغ الضريبة لكل فئة يجب أن يساوي إجمالي الضريبة، والإجمالي المستحق يجب أن يساوي الإجمالي قبل الضريبة زائد الضريبة ناقص أي مدفوعات مسبقة.

BR-CO-10: مجموع صافي البنود
Σ(LineNetAmount) = Sum of Invoice line net amount

BR-CO-13: الإجمالي الخاضع للضريبة
Σ(TaxBasisPerCategory) = Invoice total amount without VAT

BR-CO-15: الإجمالي المستحق
Total amount with VAT = (Total without VAT) + (Total VAT)

BR-CO-17: قيمة الضريبة لكل فئة
VAT category tax amount = Category taxable amount × (Rate ÷ 100)

أكثر خطأ نراه هنا هو فرق التقريب. لو قرّبت كل بند على حدة ثم جمعت، قد تحصل على مجموع يختلف بهلّلة واحدة عن الناتج المتوقع للهيئة. القاعدة تسمح عادة بهامش تقريب ضئيل (غالبًا 0.01 ر.س)، لكن تجاوز هذا الهامش يعني رفضًا فوريًا.

لنوضّح بمثال رقمي. افترض فاتورة فيها بندان: الأول بقيمة 33.33 ر.س والثاني بقيمة 33.34 ر.س، وكلاهما خاضع للنسبة القياسية 15%. ضريبة البند الأول 5.00 ر.س بعد التقريب، وضريبة البند الثاني 5.00 ر.س بعد التقريب، فيكون مجموع الضريبة على مستوى البنود 10.00 ر.س. لكن لو حسبت الضريبة على الوعاء الإجمالي 66.67 ر.س مباشرة، تحصل على 10.0005 ر.س التي تُقرّب إلى 10.00 ر.س. هنا تطابقا بالصدفة. غيّر القيم قليلًا وستجد انحرافًا يتجاوز الهامش. الدرس: احسب الضريبة على مستوى الفئة المجمّعة لا على مستوى البند المنفرد، فهذا ما تتوقعه قاعدة BR-CO-17.

نقطة ثانية كثيرًا ما تُهمَل: نوع البيانات في الكود. استخدام نوع عائم (float) في حساب المبالغ يُدخل أخطاء دقة خفية تتراكم عبر عشرات البنود. استخدم نوعًا عشريًا دقيقًا (decimal أو ما يكافئه في لغتك)، وحدّد عدد المنازل العشرية صراحة عند التقريب النهائي. هذا وحده يزيل نسبة كبيرة من حالات رفض BR-CO.

3. قواعد الصيغة والنمط (Format)

هذه القواعد تتحقق من أن قيمة الحقل تتبع نمطًا محددًا. تختلف عن قواعد XSD لأنها قد تشمل منطقًا لا يستطيع XSD التعبير عنه، مثل خوارزمية تحقق من رقم.

المثال السعودي الكلاسيكي هو الرقم الضريبي. القاعدة لا تكتفي بأنه نص من 15 خانة، بل تشترط أن يبدأ بالرقم 3 وينتهي بالرقم 3، وأن تكون الخانة الأخيرة قبل النهاية رمز فرع صحيحًا.

BR-KSA-39 / BR-KSA-40 (نمطية):
الرقم الضريبي (VAT Registration Number)
- طول ثابت: 15 خانة
- يبدأ بـ 3
- ينتهي بـ 3
- نمط: ^3[0-9]{13}3$

4. قواعد التاريخ والتسلسل (Date & Sequence)

تتحقق من منطقية التواريخ وتسلسل الفواتير. تاريخ التوريد لا يجوز أن يكون بعد تاريخ الإصدار بفارق غير مبرّر، وتاريخ استحقاق الدفع يجب ألّا يسبق تاريخ الإصدار، وعدّاد الفاتورة يجب أن يتزايد دون فجوات.

في المرحلة الثانية يدخل بُعد إضافي: ربط الفاتورة بسابقتها عبر المعرّف الفريد UUID وتجزئة الفاتورة السابقة. أي كسر في هذه السلسلة يُلتقط هنا.

القاعدة (تسلسل، مبسّطة):
تاريخ الإصدار (IssueDate) ≤ التاريخ الحالي
تاريخ الاستحقاق (DueDate) ≥ تاريخ الإصدار
عدّاد الفاتورة (ICV) = العدّاد السابق + 1

5. قواعد القوائم المغلقة (Code List)

تتحقق من أن قيمة الحقل تنتمي إلى قائمة قيم معتمدة. رمز العملة يجب أن يكون من قائمة ISO 4217، ورمز نوع الفاتورة يجب أن يكون من القائمة التي تحددها الهيئة (388 لفاتورة ضريبية، 383 لإشعار مدين، 381 لإشعار دائن)، ورمز الفئة الضريبية يجب أن يكون من المجموعة المعتمدة (S، Z، E، O).

تتقاطع هذه العائلة جزئيًا مع XSD لأن المخطط نفسه يفرض بعض القوائم المغلقة. لكن قواعد العمل تضيف منطقًا فوقها، مثل ربط رمز الفئة برمز السبب المناسب.

أمثلة عملية على رموز قواعد العمل ورسائل أخطائها

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

كيف تقرأ رسالة خطأ قاعدة عمل؟

رسالة الخطأ من منصة فاتورة تأتي بصيغة منظّمة. لنأخذ مثالًا واقعيًا لرد على فاتورة فيها خطأ حسابي:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "BR-CO-15",
        "category": "BR",
        "message": "Invoice total amount with VAT (LegalMonetaryTotal/TaxInclusiveAmount) = Invoice total amount without VAT + Invoice total VAT amount"
      }
    ]
  }
}

اقرأها من الأعلى للأسفل. status يخبرك أن الفاتورة رُفضت. code هو رمز القاعدة المكسورة، وهو مفتاحك للبحث في وثيقة قواعد الهيئة. category يصنّف القاعدة (هنا قاعدة BR حسابية). message يشرح القاعدة كصياغة معادلة. الإصلاح هنا واضح: أعد حساب الإجمالي المستحق بحيث يساوي الوعاء زائد الضريبة بالضبط.

كيف يجتاز نظامك قواعد التحقق برمجيًا؟

الهدف العملي ألّا تعتمد على رفض المنصة لاكتشاف أخطائك. النظام الجيد يطبّق قواعد العمل محليًا قبل الإرسال، فيوفّر دورات شبكة ويتجنّب تأخير المقاصة. الهيئة تنشر قواعدها بصيغة Schematron قابلة للتشغيل الآلي، وهي امتداد لـ XPath يصف القاعدة كتعبير منطقي على شجرة XML.

تعبير Schematron مبسّط لقاعدة الترابط الحسابي يبدو هكذا:

<rule context="cac:LegalMonetaryTotal">
  <assert test="
    xs:decimal(cbc:TaxInclusiveAmount) =
    (xs:decimal(cbc:TaxExclusiveAmount) +
     xs:decimal(../cac:TaxTotal/cbc:TaxAmount))"
    flag="BR-CO-15">
    الإجمالي مع الضريبة يجب أن يساوي الإجمالي بدون ضريبة زائد الضريبة
  </assert>
</rule>

إن لم تستخدم محرّك Schematron جاهزًا، يمكنك ترجمة المنطق نفسه إلى دالة في لغتك. المهم أن تطبّق هامش التقريب نفسه الذي تطبّقه الهيئة:

def validate_br_co_15(inv):
    expected = inv.tax_exclusive + inv.tax_amount
    actual = inv.tax_inclusive
    # هامش تقريب 0.01 ر.س
    if abs(actual - expected) > 0.01:
        return Error(
            code="BR-CO-15",
            message=f"المتوقع {expected:.2f} والموجود {actual:.2f}"
        )
    return OK

الترتيب الصحيح للتنفيذ في خط الإصدار: أصدر XML، تحقق من المخطط أولًا، فإن مرّ شغّل قواعد العمل، فإن مرّت وقّع وأرسل إلى المنصة. أي قاعدة تكسرها محليًا توقف الفاتورة قبل أن تلمس الشبكة.

أين تقع قواعد التحقق في رحلة الفاتورة؟

في فاتورة المقاصة (B2B)، يطبّق نظام الهيئة قواعد العمل قبل أن يصدر شهادة المقاصة. الفاتورة لا تُعتبر صالحة للتسليم إلا بعد اجتيازها. راجع المقاصة (Clearance) في الفاتورة الإلكترونية لتفاصيل هذه الرحلة.

في الفاتورة المبسّطة (B2C)، تُسلَّم الفاتورة للعميل فورًا، ثم تُبلَّغ الهيئة خلال 24 ساعة، وعندها تُطبَّق قواعد العمل. هذا يعني أن خطأ قاعدة في فاتورة B2C قد يُكتشف بعد تسليمها للعميل، ما يجعل التحقق المحلي المسبق أهم. راجع الإبلاغ (Reporting) في الفاتورة الإلكترونية لفهم هذه الدورة.

أخطاء قواعد العمل الأكثر شيوعًا وكيفية تجنّبها

من واقع بيئة الإنتاج السعودية، تتركز معظم حالات الرفض في عدد محدود من القواعد. معرفتها مسبقًا توفّر عليك ساعات تصحيح.

1. فرق التقريب في الترابط الحسابي

أكثر سبب للرفض على الإطلاق. ينشأ حين تقرّب على مستوى البند ثم تجمع، أو حين تستخدم نوع بيانات عائم (float) يفقد الدقة. الحل: استخدم نوعًا عشريًا دقيقًا (decimal) في كل العمليات، وطبّق التقريب في نهاية السلسلة لا في وسطها، والتزم بهامش 0.01 ر.س.

2. حقل شرطي مفقود

يحدث حين تكون الفئة الضريبية معفاة أو صفرية دون إرفاق سبب الإعفاء، أو حين تكون الفاتورة مبسّطة دون رمز QR. الحل: اربط منطق الإلزامية بالفئة برمجيًا، بحيث يُفرض الحقل تلقائيًا عند ظهور شرطه.

3. رقم ضريبي بصيغة خاطئة

الرقم لا يبدأ بـ 3 أو لا ينتهي به أو ليس 15 خانة. الحل: طبّق فحص النمط ^3[0-9]{13}3$ عند إدخال بيانات المنشأة، لا عند إصدار الفاتورة.

4. رمز فئة ضريبية لا يطابق النسبة

مثل وضع فئة قياسية S مع نسبة صفر، أو فئة صفرية Z مع نسبة 15%. الحل: اربط النسبة برمز الفئة في طبقة بيانات واحدة لا تسمح بالتعارض.

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

قواعد الفئات الضريبية: حيث يلتقي المنطق بالضريبة السعودية

عائلة خاصة من قواعد العمل تستحق وقفة لأنها مصدر رفض متكرر، وهي قواعد الفئة الضريبية. كل بند في الفاتورة يحمل رمز فئة ضريبية، وكل رمز يجرّ خلفه مجموعة قواعد صارمة تربط النسبة بالوعاء بالسبب. الفئات الأربع المعتمدة في السعودية هي: قياسية (S) بنسبة 15%، صفرية (Z) بنسبة 0%، معفاة (E)، وخارج النطاق (O).

القاعدة الأولى أن النسبة يجب أن تطابق الفئة. الفئة القياسية S لا تقبل إلا نسبة 15% في السياق العادي، والفئة الصفرية Z تشترط نسبة 0% بالضبط. لو وضعت بندًا برمز S ونسبة 0%، يرفض النظام الفاتورة لأن الرمز والنسبة متعارضان. هذه القاعدة تحمل رموزًا مثل BR-S-05 وBR-Z-05 في المعيار الأوروبي.

القاعدة الثانية أن الفئة الصفرية والمعفاة وخارج النطاق تتطلب سبب الإعفاء. لا يكفي أن تضع النسبة صفرًا، بل يجب أن ترفق نص السبب ورمزه من قائمة الأسباب المعتمدة. الفاتورة التي تحمل بندًا معفى دون سبب تُرفض بقاعدة BR-E-10 أو ما يماثلها. السبب أن الهيئة تحتاج توثيق علّة الإعفاء لأغراض التدقيق.

القاعدة الثالثة أن مجموع الوعاء لكل فئة يجب أن يساوي مجموع أوعية البنود المنتمية لتلك الفئة. لو كان لديك ثلاثة بنود قياسية، فإن الوعاء القياسي على مستوى الفاتورة يجب أن يساوي مجموع أوعية هذه البنود الثلاثة بالضبط. هذه قاعدة ترابط حسابي تتقاطع مع عائلة الحساب، وتحمل رمزًا مثل BR-CO-18.

قواعد الفئة القياسية S (مبسّطة):
BR-S-05: نسبة الفئة القياسية = 15
BR-S-06: قيمة ضريبة الفئة القياسية = الوعاء × 0.15
BR-S-08: الوعاء القياسي > 0

قواعد الفئة المعفاة E (مبسّطة):
BR-E-05: نسبة الفئة المعفاة = 0
BR-E-10: يجب وجود نص سبب الإعفاء

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

لماذا فصلت الهيئة قواعد العمل عن المخطط؟

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

كيف تتعامل قيود مع طبقة قواعد التحقق نيابة عنك

إن كنت تستخدم برنامج الفاتورة الإلكترونية من قيود، فإن طبقة قواعد العمل مدمجة في خط الإصدار. تتولّى قيود توليد فاتورة XML ضمن بنية الفاتورة الإلكترونية الصحيحة، ثم تطبّق قواعد الترابط الحسابي والصيغة والوجود الشرطي قبل التوقيع والإرسال.

عمليًا، هذا يعني أنك لا تكتب تعبير Schematron ولا دالة تحقق ولا تتعامل مع هامش التقريب. تُدخل بيانات الفاتورة، وتتولّى قيود حساب المجاميع بدقة عشرية، وفرض الحقول الشرطية حسب الفئة الضريبية، والتحقق من صيغة الرقم الضريبي، وضبط نوع الفاتورة. الفاتورة لا تغادر النظام نحو منصة فاتورة إلا وهي خالية من أخطاء BR المعروفة.

هذه الطبقة تكمّل طبقة المخطط: قيود تضمن أن الفاتورة سليمة البنية (XSD) وسليمة المنطق (BR-KSA) معًا، فتصل إلى المقاصة جاهزة للقبول من المحاولة الأولى.

أين تذهب بعد هذا الدليل؟

قواعد التحقق هي الطبقة المنطقية فوق البنية. لإكمال الصورة التقنية:

• مخطط الفاتورة (Invoice Schema) والتحقق منه: الطبقة البنيوية عبر XSD التي تسبق قواعد العمل.
• معيار UBL 2.1: الأساس الذي تُبنى عليه قواعد المعيار الأوروبي والسعودي.
• بنية الفاتورة الإلكترونية: الحقول التي تعمل عليها قواعد التحقق.
• المقاصة (Clearance): حيث تُطبَّق قواعد العمل على فواتير B2B.

الأسئلة الشائعة

ما الفرق بين قواعد التحقق (Validation Rules) والتحقق من المخطط (Schema Validation)؟

التحقق من المخطط يفحص البنية عبر XSD: هل الحقول موجودة وبأنواع بيانات صحيحة وترتيب سليم. قواعد التحقق (قواعد العمل) تفحص المنطق: هل المجاميع متّسقة، وهل الضريبة محسوبة صحيحًا، وهل الحقول الشرطية موجودة. الأولى تسبق الثانية في خط التنفيذ.

ماذا تعني بادئة BR-KSA في رمز الخطأ؟

BR اختصار Business Rule، وKSA يشير إلى القواعد الخاصة بالمملكة التي تضيفها الهيئة فوق المعيار الأوروبي EN 16931. الرموز التي تبدأ بـ BR-CO تخص الترابط الحسابي، وBR-S وBR-Z وBR-E تخص الفئات الضريبية القياسية والصفرية والمعفاة.

ما أكثر قاعدة تسبّب رفض الفواتير؟

قواعد الترابط الحسابي، وتحديدًا BR-CO-15 وBR-CO-17، بسبب فروق التقريب. عند جمع بنود مقرّبة على حدة قد ينحرف الإجمالي بهلّلة عن الناتج المتوقع. الحل استخدام نوع عشري دقيق وتطبيق التقريب في نهاية السلسلة فقط.

هل اجتياز التحقق من المخطط يعني اجتياز قواعد العمل؟

لا. الفاتورة قد تكون سليمة البنية تمامًا (تمرّ من XSD) ومع ذلك تحمل خطأً منطقيًا مثل مجموع لا يطابق أو ضريبة محسوبة خطأ. الطبقتان مستقلتان، ويجب اجتيازهما معًا.

هل أحتاج إلى كتابة قواعد Schematron بنفسي؟

إن بنيت نظامك من الصفر، نعم، إما بتشغيل ملفات Schematron التي تنشرها الهيئة أو بترجمة منطقها إلى دوال. إن استخدمت برنامجًا متوافقًا مثل قيود، فالطبقة مدمجة ولا تحتاج لكتابة أي قاعدة.

متى تُطبَّق قواعد التحقق على الفاتورة المبسّطة B2C؟

الفاتورة المبسّطة تُسلَّم للعميل فورًا، ثم تُبلَّغ الهيئة خلال 24 ساعة، وعندها تُطبَّق قواعد العمل. لذلك يُنصح بشدة بتطبيق التحقق محليًا قبل التسليم، حتى لا تُكتشف الأخطاء بعد وصول الفاتورة للعميل.