BR-KSA-39البائع لا يحمل تسجيلاً في ضريبة القيمة المضافة
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-39.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-39]-The invoice must contain the seller VAT registration number or seller group VAT registration number (BT-31).
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
البائع لا يحمل تسجيلاً في ضريبة القيمة المضافة
صورة القيمة في التقريرno_vat_registrationلا تسجيل في ضريبة القيمة المضافة
ما الخلل
تشترط القاعدة BR-KSA-39 أن يحمل البائع رقم التسجيل في ضريبة القيمة المضافة BT-31، وفي الإصدار 3.4.8 الذي تقرؤه حزمة القواعد 2.0.0 لا يجتاز المستند هذا الشرط إلا بطريق واحد: أن يكون أحد عناصر cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID غير فارغ، وأن يحمل أحد عناصر cac:PartyTaxScheme عنصر cac:TaxScheme معرِّفه cbc:ID يساوي VAT. ولم يتحقق ذلك في هذا المستند، فترفضه هيئة الزكاة والضريبة والجمارك. وتذكر رسالة الهيئة كذلك رقم تسجيل مجموعة البائع في ضريبة القيمة المضافة، وكانت الإصدارات السابقة (3.0.8) تقبل طريقاً ثانياً، هو عنصر cac:PartyIdentification/cbc:ID غير فارغ يحمل السمة schemeID بالقيمة HQ، لكن الإصدار 3.4.8 أسقطه، فلم يعد التعريف الحامل للرمز HQ يفي بهذه القاعدة. وتفصيلان في قراءة الفحص. الأول أن شقّيه غير مربوطين بعنصر واحد: فالبائع الحامل لكتلتي cac:PartyTaxScheme يجتاز الفحص إذا حملت إحداهما عنصر cbc:CompanyID غير فارغ وحملت الأخرى عنصر cac:TaxScheme بقيمة VAT. والثاني أن مقارنة VAT هنا تتجاهل المسافات المحيطة، فالعنصر cbc:ID الحامل للقيمة VAT محفوفةً بمسافات مقبول في هذه القاعدة، وليست هذه قراءة القاعدة BR-KSA-40 للعنصر نفسه. وتسري هذه القاعدة على الفاتورة الضريبية والفاتورة المبسطة سواء.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
رقم تسجيل البائع في ضريبة القيمة المضافة يقع في سجل منشأتك أو فرعك، فهذا نقص في الإعداد لا في المستند، ويعني عادةً أن كل فاتورة تصدر عن هذه المنشأة مصابة به. والأسباب الجديرة بالفحص مرتَّبة: أن يكون حقل التسجيل في ضريبة القيمة المضافة خالياً في المنشأة المُصدِرة، وهي حال شائعة في فرع أو كيان نظامي أُنشئ بعد إعداد وحدة الفوترة الإلكترونية، وفي منشأة تجريبية استُعملت لإنتاج ملف نموذجي؛ وأن تكون كتلة cac:PartyTaxScheme لا تُكتب إلا إذا مُلئ الحقل، فيُسقط الحقلُ الخالي الكتلةَ كلها بدل أن يترك عنصراً فارغاً؛ وألّا يكون معرِّف النظام الضريبي هو VAT بالضبط، فالقيم مثل Tax أو S أو اسم نظام محلي لا تفي بالقاعدة مهما صحّ الرقم إلى جوارها. وانتبه كذلك إلى أن تعريف البائع في cac:PartyIdentification لا يفي بهذه القاعدة، سواء حمل السمة schemeID بالقيمة CRN، أي رقم السجل التجاري، أو بالقيمة HQ: فلا يفي بها إلا النظام الضريبي.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not(((cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID) != '' and (cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme[normalize-space(cbc:ID) = 'VAT'])))
التعبير المذكور في التقرير
not(((cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID) != '' and (cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme[normalize-space(cbc:ID) = 'VAT'])))
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.