يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-16.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-16]-Payment means code (BT-81) in an invoice exist, then it must contain one of the values from subset of UNTDID 4461 code list
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
رمز وسيلة الدفع ليس مما تقبله الهيئة
صورة القيمة في التقريرcode_not_permittedرمز لا تقبله الهيئة
ما الخلل
المستند فاتورة ضريبية، والعنصر cbc:PaymentMeansCode فيه يحمل قيمة لا يجدها فحص هيئة الزكاة والضريبة والجمارك في قائمتها. واقرأ ما يلي قبل تغيير شيء، فالفحص أوسع من الرسالة، والفحص هو ما يقرّر. تذكر الرسالة خمسة رموز هي 10 و30 و42 و48 و1، بينما الفحص خلفها يبحث عن قيمتك بوصفها قطعة نص داخل السلسلة ' 10 30 42 48 1 ' دون أن يحفّها بفواصل أولاً. فهو يقبل قيماً لا تذكرها الرسالة: فالقيمة 8 توجد داخل 48 فتجتاز، وكذلك 0 و2 و3 و4، بل والعنصر cbc:PaymentMeansCode الفارغ، لأن البحث النصي يجد النص الخالي داخل أي نص. فلا تُذكر هذه الملاحظة إلا على قيمة لا ترد في تلك السلسلة إطلاقاً، مثل 57 أو ZZ أو CASH. والأثر عليك في الاتجاه الآخر: فسكوت الفحص هنا ليس تأكيداً أن رمزك أحد الخمسة، ومطابق يطابق الفحص ولا يعد بأشد منه. وثمة حدّ ثانٍ جدير بالمعرفة: إن حمل المستند أكثر من عنصر cbc:PaymentMeansCode فإن تعبير الهيئة يسلّم مجموعة عناصر إلى دالة لا تقبل إلا نصاً واحداً، وهذا خطأ في التنفيذ لدى الهيئة لا حكم، فلا يُعوَّل على جواب في مستند كهذا؛ ويقرأ مطابق أول رمز فيه احتياطاً. ولا يسري هذا إلا على الفاتورة الضريبية وإشعاراتها الدائنة والمدينة، أي ما يبدأ رمز نوع معاملة الفاتورة KSA-2 فيه بـ 01، والرسالة المنشورة تنص على ذلك: فرمز وسيلة الدفع اختياري في الفاتورة المبسطة. وانتبه كذلك إلى أن قاموس بيانات الهيئة يصف الحقل BT-81 بأنه اختياري في أنواع المستندات الستة كلها، بينما تجعله هذه القاعدة إلزامياً في الأنواع الثلاثة القياسية؛ والقاعدة هي ما تنفّذه الهيئة وهي ما يقرّر النتيجة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
القيمة تأتي من جدول وسائل الدفع أو شروط الدفع عندك، والأسباب المعتادة: رمز داخلي يُمرَّر كما هو مثل CASH أو BANK أو CC أو مفتاح رقمي من جدولك الخاص؛ ورمز صحيح في قائمة UNTDID 4461 لكنه خارج القائمة المختصرة التي تقبلها الهيئة، كالرمز 20 للشيك أو 31 للتحويل المدين؛ ورمز حُشي أو سُبق ببادئة في خطوة تنسيق. اربط وسائل الدفع عندك صراحةً بالرموز الخمسة، وهي 10 للنقد و30 للتحويل الدائن و42 للدفع إلى حساب مصرفي و48 لبطاقة مصرفية و1 لأداة غير محدَّدة، بدل تمرير قيمك الخاصة، وتحقّق أن كتلة واحدة فقط من كتل cac:PaymentMeans تحمل رمزاً.
الفاتورة الضريبية لا تحمل كتلة وسيلة الدفع
صورة القيمة في التقريرpayment_means_missingكتلة وسيلة الدفع غير موجودة
ما الخلل
المستند فاتورة ضريبية، ولا يحمل في أي موضع منه عنصر cac:PaymentMeans. ولا ترصد هذه الملاحظة إلا حزم القواعد السابقة للإصدار 2.0.0: فالقاعدة BR-KSA-16 في الإصدار 3.0.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك كانت تشترط ثلاثة أمور مرتّبة: وجود عنصر cac:PaymentMeans، ثم وجود عنصر cbc:PaymentMeansCode داخل أحدها، ثم أن يكون الرمز موجوداً في نص القائمة ' 10 30 42 48 1 '، وقد أخفق أولها هنا. أما في الإصدار 3.4.8 الذي تقرؤه حزمة القواعد 2.0.0 فالقاعدة BR-KSA-16 لا تفحص إلا رموز وسيلة الدفع التي يحملها المستند، كلاً منها على مجموعة جزئية من قائمة الرموز UNTDID 4461، وتصنّف ذلك تحذيراً؛ والمستند الخالي من وسيلة الدفع لا يترك لها ما تفحصه، فلا يحمل هذه الملاحظة تقرير صادر عن الحزمة 2.0.0.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
لا شيء يلزم تغييره من أجل حزمة القواعد 2.0.0 في هذا الشأن: فالقاعدة BR-KSA-16 لم تعد تطلب كتلة وسيلة الدفع. وحيث يكتب تصديرك الكتلة فيجب أن يكون رمزها ضمن المجموعة الجزئية من قائمة UNTDID 4461 التي تحملها أداة الفحص؛ والرموز الخمسة التي كانت القائمة السابقة تقبلها، وهي 10 للنقد و30 للتحويل الدائن و42 للدفع إلى حساب مصرفي و48 لبطاقة مصرفية و1 حين تكون الأداة غير محدَّدة، كلها ضمنها.
كتلة وسيلة الدفع لا تحمل رمز وسيلة الدفع
صورة القيمة في التقريرcode_element_missingعنصر الرمز غير موجود
ما الخلل
المستند فاتورة ضريبية ويحمل عنصر cac:PaymentMeans واحداً على الأقل، لكن لا يحمل أيٌّ منها عنصر cbc:PaymentMeansCode. ولا ترصد هذه الملاحظة إلا حزم القواعد السابقة للإصدار 2.0.0: فالقاعدة BR-KSA-16 في الإصدار 3.0.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك كانت تشترط عنصر cbc:PaymentMeansCode داخل عنصر cac:PaymentMeans في الفاتورة الضريبية، وهذا العنصر غائب هنا، وكان العنصر الفارغ سيفي بالشرط. أما في الإصدار 3.4.8 الذي تقرؤه حزمة القواعد 2.0.0 فالقاعدة BR-KSA-16 لا تفحص إلا رموز وسيلة الدفع التي يحملها المستند، كلاً منها على مجموعة جزئية من قائمة الرموز UNTDID 4461، وتصنّف ذلك تحذيراً؛ والكتلة الخالية من الرمز لا تترك لها ما تفحصه، فلا يحمل هذه الملاحظة تقرير صادر عن الحزمة 2.0.0.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
لا شيء يلزم تغييره من أجل حزمة القواعد 2.0.0 في هذا الشأن: فالقاعدة BR-KSA-16 لم تعد تطلب الرمز. وإن كتبته فيجب أن يكون ضمن المجموعة الجزئية من قائمة UNTDID 4461 التي تحملها أداة الفحص، ولا تكتب العنصر إلا إذا كانت له قيمة، لأن عنصر الرمز الفارغ تُرصد عليه الملاحظة.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.