BR-KSA-31راية الطرف الثالث ليست 0 ولا 1 في فاتورة مبسطة
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-31.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-31]- For Simplified Tax Invoices and associated credit notes and debit notes (KSA-2, position 1 and 2 = 02), transaction types "self-billing" (KSA-2, position 7 = True) is not allowed.
فحوص أخرى تُذكر في التقرير نفسه
BR-KSA-06
[BR-KSA-06]-The invoice transaction code (KSA-2) must exist and respect the following structure: NNPNESBCG where NN (positions 1 and 2) = invoice subtype: - 01 for tax invoice - 02 for simplified tax invoice P (position 3) = 3rd Party invoice transaction, 0 for false, 1 for true; N (position 4) = Nominal invoice transaction, 0 for false, 1 for true; E (position 5) = Exports invoice transaction, 0 for false, 1 for true; S (position 6) = Summary invoice transaction, 0 for false, 1 for true; B (position 7) = Self billed invoice transaction, 0 for false, 1 for true; C (position 8) = Continuous Supply invoice transaction, 0 for false, 1 for true; G (position 9) = B2G invoice transaction, 0 for false, 1 for true
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
راية الطرف الثالث ليست 0 ولا 1 في فاتورة مبسطة
صورة القيمة في التقريرthird_party_flag_invalidراية الطرف الثالث ليست 0 ولا 1
ما الخلل
الفاتورة مبسطة، إذ يبدأ رمز نوع معاملة الفاتورة KSA-2 بـ 02، والموضع 3 من هذا الرمز وهو راية الطرف الثالث يحمل قيمة غير 0 و1. وتفحص هيئة الزكاة والضريبة والجمارك مواضع الرايات الخمسة في الفاتورة المبسطة موضعاً موضعاً بموجب القاعدة BR-KSA-31 وترفض ما ليس 0 أو 1. والمحرف نفسه يخالف كذلك القاعدة BR-KSA-06 السارية على كل فاتورة، فترصد الهيئة هذا الخلل بموجب قاعدتين في آن واحد.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
رمز المعاملة سبعة محارف تُكتب نصاً: 02 للفاتورة المبسطة ثم خمس رايات قيمة كل منها 0 أو 1، دون فواصل ولا مسافات ولا حروف. والمحرف الخارج عن ذلك في الموضع 3 يعني غالباً أن حقلاً نصياً حراً يُربط بالسمة، أو أن الرايات تُجمَّع من قيم ليست كلها مضبوطة. والفاتورة المبسطة التي لا طرف ثالث فيها رمزها 0200000.
راية التوريد الصوري ليست 0 ولا 1 في فاتورة مبسطة
صورة القيمة في التقريرnominal_flag_invalidراية التوريد الصوري ليست 0 ولا 1
ما الخلل
الفاتورة مبسطة، إذ يبدأ رمز نوع معاملة الفاتورة KSA-2 بـ 02، والموضع 4 من هذا الرمز وهو راية التوريد الصوري يحمل قيمة غير 0 و1. وتفحص هيئة الزكاة والضريبة والجمارك مواضع الرايات الخمسة في الفاتورة المبسطة موضعاً موضعاً بموجب القاعدة BR-KSA-31 وترفض ما ليس 0 أو 1. والمحرف نفسه يخالف كذلك القاعدة BR-KSA-06 السارية على كل فاتورة، فترصد الهيئة هذا الخلل بموجب قاعدتين في آن واحد.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
رمز المعاملة سبعة محارف تُكتب نصاً: 02 للفاتورة المبسطة ثم خمس رايات قيمة كل منها 0 أو 1، دون فواصل ولا مسافات ولا حروف. والتوريد الصوري توريد بغير مقابل، والراية تكون 1 له وحده؛ أما البيع المبسط المعتاد فرمزه 0200000. والمحرف الخارج عن 0 و1 في الموضع 4 يعني غالباً أن بحثاً في جدول لم يُرجع شيئاً وكُتبت نتيجته في الرمز دون تحقّق.
فاتورة مبسطة موسومة بالتصدير
صورة القيمة في التقريرexport_not_allowedموسوم بالتصدير حيث لا يجوز
ما الخلل
الفاتورة مبسطة، إذ يبدأ رمز نوع معاملة الفاتورة KSA-2 بـ 02، والموضع 5 من هذا الرمز وهو راية التصدير ليس 0. ولا ترصد هذه الملاحظة إلا حزم القواعد السابقة للإصدار 2.0.0: فالقاعدة BR-KSA-31 في الإصدار 3.0.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك كانت تشترط أن تكون راية التصدير في الفاتورة المبسطة 0. أما في الإصدار 3.4.8 الذي تقرؤه حزمة القواعد 2.0.0 فالقاعدة BR-KSA-31 تقبل 0 أو 1 في الموضع 5، ولا ترفض إلا الفاتورة المبسطة ذاتية الفوترة (الموضع 7)، فلا يحمل هذه الملاحظة تقرير صادر عن الحزمة 2.0.0؛ والموضع 5 الذي ليس 0 ولا 1 يُرصد بوصفه راية تصدير غير صالحة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
الفاتورة المبسطة الموسومة بالتصدير غير مرفوضة في حزمة القواعد 2.0.0. وإن لم يكن البيع تصديراً فاضبط الراية على 0 مع ذلك؛ فالفاتورة المبسطة لعميل حضر إلى نقطة البيع رمزها 0200000. وتحقّق من إعداد العميل أو الوجهة الذي يغذّي الموضع 5 من الرمز.
راية الفاتورة الملخَّصة ليست 0 ولا 1 في فاتورة مبسطة
صورة القيمة في التقريرsummary_flag_invalidراية الفاتورة الملخَّصة ليست 0 ولا 1
ما الخلل
الفاتورة مبسطة، إذ يبدأ رمز نوع معاملة الفاتورة KSA-2 بـ 02، والموضع 6 من هذا الرمز وهو راية الفاتورة الملخَّصة يحمل قيمة غير 0 و1. وتفحص هيئة الزكاة والضريبة والجمارك مواضع الرايات الخمسة في الفاتورة المبسطة موضعاً موضعاً بموجب القاعدة BR-KSA-31 وترفض ما ليس 0 أو 1. والمحرف نفسه يخالف كذلك القاعدة BR-KSA-06 السارية على كل فاتورة، فترصد الهيئة هذا الخلل بموجب قاعدتين في آن واحد.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
رمز المعاملة سبعة محارف تُكتب نصاً: 02 للفاتورة المبسطة ثم خمس رايات قيمة كل منها 0 أو 1، دون فواصل ولا مسافات ولا حروف. وراية الفاتورة الملخَّصة تكون 1 حيث يلخّص المستند عدة توريدات خلال مدة؛ أما البيع المبسط المعتاد فرمزه 0200000. والمحرف الخارج عن 0 و1 في الموضع 6 يعني غالباً أن الرايات تُبنى من سلسلة نصية غير متساوية الطول لا موضعاً بموضع.
فاتورة مبسطة موسومة بالفوترة الذاتية
صورة القيمة في التقريرself_billed_not_allowedموسوم بالفوترة الذاتية حيث لا يجوز
ما الخلل
الفاتورة مبسطة، إذ يبدأ رمز نوع معاملة الفاتورة KSA-2 بـ 02، والموضع 7 من هذا الرمز وهو راية الفوترة الذاتية ليس 0. وترفض هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-31: فالفوترة الذاتية، وهي أن يصدر العميل الفاتورة نيابة عن المورّد، ترتيب بين منشآت مسجَّلة، وهي غير متاحة على فاتورة مبسطة. وثمة قاعدة أخرى هي BR-KSA-07 تمنع الراية نفسها على فاتورة تصدير.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
نوع المستند وراية الفوترة الذاتية متعارضان. فالفاتورة بالفوترة الذاتية تصدر فاتورةً ضريبية، أي أن رمز المعاملة يبدأ بـ 01، مثل 0100001. وإن كان هذا توريداً معتاداً في نقطة بيع لمستهلك نهائي فاضبط الراية على 0؛ فرمز الفاتورة المبسطة 0200000. وتُضبط الراية عادة من اتفاق فوترة ذاتية مسجَّل على العميل، فتحقّق من ألّا يُطبَّق الاتفاق على مستندات خارجه.
راية التصدير في رمز نوع المعاملة ليست 0 ولا 1
صورة القيمة في التقريرexport_flag_invalidراية التصدير ليست 0 ولا 1
ما الخلل
في فاتورة مبسطة (تبدأ السمة name للعنصر cbc:InvoiceTypeCode فيها بـ 02)، المحرف الخامس من هذه السمة، وهو راية التصدير، ليس 0 ولا 1. فترفض هيئة الزكاة والضريبة والجمارك المستند بموجب القاعدة BR-KSA-31، وهي تشترط أن تكون الخانات من 3 إلى 6 إما 0 وإما 1، وأن تكون الخانة 7، الفوترة الذاتية، 0. وكانت الإصدارات السابقة من أداة الفحص لدى الهيئة ترفض راية التصدير في الفاتورة المبسطة أصلاً، أما الإصدار الحالي فيقبل القيمتين.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
راجع طريقة بناء رمز نوع المعاملة ذي المحارف السبعة. فكل خانة من خانات الرايات يجب أن تكون 0 أو 1 بالضبط؛ والمسافة أو الحرف أو المحرف الناقص في الخانة 5 يأتي في العادة من رمز حُشي أو قُطع إلى طول خاطئ.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not( (substring(./@name, 3,1) = '1' or substring(./@name, 3,1) = '0') and (substring(./@name, 4,1) = '1' or substring(./@name, 4,1) = '0') and (substring(./@name, 5,1) = '1' or substring(./@name, 5,1) = '0') and (substring(./@name, 6,1) = '1' or substring(./@name, 6,1) = '0') and (substring(./@name, 7,1) = '0'))
التعبير المذكور في التقرير
(substring(./@name, 3,1) = '1' or substring(./@name, 3,1) = '0') and (substring(./@name, 4,1) = '1' or substring(./@name, 4,1) = '0') and (substring(./@name, 5,1) = '0') and (substring(./@name, 6,1) = '1' or substring(./@name, 6,1) = '0') and (substring(./@name, 7,1) = '0')
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.