BR-KSA-17الإشعار الدائن أو المدين لا يذكر سبب إصداره
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-17.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-17]-Debit and credit note (invoice type code (BT-3) is equal to 383 or 381) must contain the reason (KSA-10) for this invoice type issuing.
فحوص أخرى تُذكر في التقرير نفسه
BR-KSA-17
[BR-KSA-17]-Debit and credit note (invoice type code (BT-3) is equal to 383 or 381) must contain the reason (KSA-10) for this invoice type issuing.
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
الإشعار الدائن أو المدين لا يذكر سبب إصداره
صورة القيمة في التقريرinstruction_note_missingلا سبب للإصدار
ما الخلل
المستند إشعار دائن 381 أو إشعار مدين 383، ولا يحمل في أي موضع منه العنصر cac:PaymentMeans/cbc:InstructionNote، فسبب الإصدار KSA-10 غائب. وتجعل هيئة الزكاة والضريبة والجمارك هذا السبب إلزامياً على نوعي الإشعار بموجب القاعدة BR-KSA-17 وترفض المستند دونه. والعنصر هو cbc:InstructionNote داخل cac:PaymentMeans، وليس هو cbc:Note. وهذا التمييز هو موضع الإشكال كله: فالعنصر cbc:Note على مستوى المستند هو ما يضع فيه العارف بمعيار UBL سبب الإصدار، وهو موضع يبدو صحيحاً تماماً، ولا يُجيز هذه القاعدة؛ فالفحص يقرأ cac:PaymentMeans/cbc:InstructionNote ولا يقرأ سواه، فالإشعار الحامل لشرح وافٍ في cbc:Note مرفوض مع ذلك. والفحص فحص وجود لا غير، فهو لا ينظر في النص إطلاقاً، والعنصر cbc:InstructionNote الفارغ يجتازه لدى الهيئة؛ ويطابق مطابق ذلك فلا يذكر سبباً خالياً. ويجوز أن يقع العنصر تحت أي عنصر cac:PaymentMeans في المستند، بما في ذلك واحد متداخل تحت خصم أو رسم على مستوى المستند.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
الإشعارات الدائنة والمدينة تحمل سبباً في الغالب الأعم أصلاً — كالمرتجع أو تصحيح السعر أو الإلغاء أو الحسم — إما رمز سبب وإما حقلاً نصياً حراً في ترويسة الإشعار، فهذا نقص في الربط لا في البيانات عادةً. وسببان يفسّران معظم الحالات. الأول العنصر: تحقّق أن الربط يكتب cbc:InstructionNote لا cbc:Note. والثاني الوعاء: فكثير من عمليات التصدير لا تُخرج العنصر cac:PaymentMeans إلا إذا عُرفت وسيلة الدفع، والإشعار الدائن كثيراً ما لا وسيلة دفع له، فلا يجد السبب كتلةً يقع فيها؛ والواجب إخراج الكتلة لكل إشعار بلا شرط. واكتب العنصر cbc:InstructionNote في موضعه من ترتيب UBL داخل cac:PaymentMeans، فالعنصر المكتوب خارج ترتيبه يخفق في فحص المخطط ويُرصد بوصفه MTB-XSD-01.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.
الأسطر التي يختلف فيها عن مستند اجتاز الفحص
− هذا المثال
+ مستند اجتاز الفحص
<cac:PaymentMeans> <cbc:PaymentMeansCode>10</cbc:PaymentMeansCode>+مستند اجتاز الفحص: <cbc:InstructionNote>Goods returned by the customer</cbc:InstructionNote></cac:PaymentMeans><cac:TaxTotal>