BR-KSA-26مرفق بصمة الفاتورة السابقة لا يحمل عنصر القيمة
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-26.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-26]-If the invoice contains the previous invoice hash (KSA-13), this hash must be base64 encoded SHA256. The hash shall be computed using the following method as described in the ds:transforms block in the XML Invoice Specifications: 1. Remove the <Invoice><ext:UBLExtensions/> block 2. Remove the <Invoice><cac:AdditionalDocumentReference/> block where <cbc:ID/> = QR 3. Remove the <Invoice><cac:Signature/> block 4. Canonicalize the Invoice using the C14N11 standard 5. Hash the resulting string using SHA256 to a binary object 6. Base64 encode the binary object to generate the digest value For the first invoice, the previous invoice hash is "NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTdlOQ==", the equivalent for base64 encoded SHA256 of "0" (zero) character.
فحوص أخرى تُذكر في التقرير نفسه
BR-KSA-61
[BR-KSA-61]-Previous invoice hash (KSA-13) must exist in an invoice.
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
مرفق بصمة الفاتورة السابقة لا يحمل عنصر القيمة
صورة القيمة في التقريرpayload_element_missingعنصر الحمولة غير موجود
ما الخلل
العنصر cac:Attachment داخل كتلة مرجع PIH لا يحمل عنصر cbc:EmbeddedDocumentBinaryObject، فالمرفق لا يحمل بصمة فاتورة سابقة. وترصد هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-26، وتصنّف هذه القاعدة تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. وستظهر لك هذه الملاحظة غالباً إلى جانب القاعدة BR-KSA-61، وهذا صحيح لا تكرار: فالهيئة تنشر فحصين منفصلين على هذا العنصر الواحد، أحدهما مثبَّت عند جذر المستند وهو BR-KSA-61 والآخر مثبَّت على المرفق نفسه وهو BR-KSA-26، وتنفّذهما معاً؛ فينتج عن خلل واحد ملاحظتان ورمزان، وإصلاح العنصر يرفعهما معاً. وأمر لا تفعله هذه القاعدة رغم نص رسالتها: فرسالة BR-KSA-26 المنشورة تقول إن البصمة يجب أن تكون بصمة SHA-256 مرمَّزة بترميز base64، بينما الفحص خلفها لا يتحقق إلا من وجود العنصر وعدم خلوّه وإعلانه نوع المحتوى؛ فهو لا يفكّ القيمة ولا يقيسها. أما كون القيمة بصمة SHA-256 مرمَّزة بترميز base64 حقاً فيُذكر في هذا التقرير في ملاحظة مستقلة، بوصفه مخاطرة لا سبب رفض.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
البنية داخل كتلة PIH هي عنصر cac:Attachment ثم عنصر cbc:EmbeddedDocumentBinaryObject بداخله، وتكون القيمة بترميز base64 هي المحتوى النصي لذلك العنصر. ولأن هذه القاعدة مثبَّتة على المرفق فهي تُذكر مرة عن كل مرفق PIH في المستند، فالتصدير الذي يكتب أكثر من كتلة واحدة يُذكر عن كل كتلة خاطئة منها. والأسباب المعتادة: قالب يُخرج غلاف المرفق ويملؤه من خطوة ثانية لم تُنفَّذ، وبصمة كُتبت في مستوى أعلى مما ينبغي، إما مباشرةً تحت cac:Attachment وإما تحت المرجع نفسه.
مرفق بصمة الفاتورة السابقة فارغ
صورة القيمة في التقريرpayload_emptyالحمولة فارغة
ما الخلل
العنصر cbc:EmbeddedDocumentBinaryObject داخل مرفق PIH موجود لكن لا قيمة فيه، فالمرفق لا يذكر بصمة فاتورة سابقة. وترصد هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-26، وتصنّف هذه القاعدة تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. وتوقَّع ظهور هذه الملاحظة إلى جانب القاعدة BR-KSA-61 على العنصر نفسه: فالهيئة تنشر فحصين على هذا العنصر، أحدهما مثبَّت عند جذر المستند والآخر مثبَّت على المرفق، وتنفّذهما معاً، فتنتج عن قيمة فارغة واحدة ملاحظتان ورمزان. وانتبه كذلك إلى ما لا تفحصه هذه القاعدة: فرسالة BR-KSA-26 المنشورة تقول إن البصمة يجب أن تكون بصمة SHA-256 مرمَّزة بترميز base64، بينما الفحص خلفها يتحقق من الوجود وعدم الخلوّ ونوع المحتوى، ولا يتحقق من محتوى القيمة في شيء. وصورة القيمة تُذكر في ملاحظة مستقلة، بوصفها مخاطرة لا سبب رفض.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
العنصر يُكتب والقيمة لا تُكتب، فالكتلة تُنتَج دون شرط بينما البصمة خلفها غائبة لحظة بناء ملف XML. راجع أين تُحفظ بصمة المستند السابق بين الفواتير: فهذه الحال تظهر عادةً حين تُحفظ السلسلة في الذاكرة فتضيع عند إعادة التشغيل، أو حين لا يجد أول مستند بعد تغيير في الإعدادات سابقاً مسجَّلاً، أو حين تُحسب البصمة بعد تسلسل المستند لا قبله. وأول فاتورة في السلسلة ليست فارغة كذلك: فمعيار تطبيق XML ينشر القيمة التي تُستعمل فيها.
مرفق بصمة الفاتورة السابقة غير معلَن بنوع المحتوى text/plain
صورة القيمة في التقريرnot_text_plainغير معلَن بنوع المحتوى text/plain
ما الخلل
العنصر cbc:EmbeddedDocumentBinaryObject داخل مرفق PIH لا يحمل السمة mimeCode بالقيمة text/plain، وترصد هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-26، وتصنّف الهيئة هذه القاعدة تحذيراً لا خطأً في أداة الفحص الحالية لديها، فالتحذير وحده لا يؤدي إلى رفض المستند. وتُقارن القيمة بعد تسوية المسافات وحرفياً فيما عدا ذلك: فالقيمتان application/octet-stream وbase64Binary والسمة الفارغة والسمة الغائبة كلها تخفق. وتوقَّع ظهور هذه الملاحظة إلى جانب القاعدة BR-KSA-61 التي تفحص العنصر نفسه من جذر المستند؛ فالهيئة تنفّذ الفحصين معاً، فينتج عن نوع محتوى خاطئ واحد ملاحظتان ورمزان. وانتبه إلى حدّ هذه القاعدة رغم نص رسالتها: فالقاعدة BR-KSA-26 تقول صراحةً إن البصمة يجب أن تكون بصمة SHA-256 مرمَّزة بترميز base64، بينما الفحص لا يتحقق إلا من الوجود وعدم الخلوّ ونوع المحتوى هذا. أما كون القيمة بصمة أصلاً فيُذكر في ملاحظة مستقلة، بوصفه مخاطرة لا سبب رفض.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
اضبط السمة mimeCode على القيمة text/plain على العنصر cbc:EmbeddedDocumentBinaryObject نفسه لا على العنصر cac:Attachment الذي فوقه. ولا تشتقّ القيمة من المحتوى: فالمحتوى نص بترميز base64، ولذلك تبدو القيمة application/octet-stream أدقّ وصفاً وتُرصد عليها الملاحظة. والأسباب المعتادة: دالة عامة للمرفقات تحمل نوع محتوى افتراضياً خاصاً بها، وقيمة تُقرأ من جدول إدارة المستندات، وقالب يغفل السمة كلياً. ومرفق رمز الاستجابة السريعة يحتاج إلى الإعلان نفسه، فراجع الكتلتين معاً.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not(exists(cbc:EmbeddedDocumentBinaryObject) and (cbc:EmbeddedDocumentBinaryObject) != '' and (cbc:EmbeddedDocumentBinaryObject[normalize-space(@mimeCode) = 'text/plain']))
التعبير المذكور في التقرير
exists(cbc:EmbeddedDocumentBinaryObject) and (cbc:EmbeddedDocumentBinaryObject) != '' and (cbc:EmbeddedDocumentBinaryObject[normalize-space(@mimeCode) = 'text/plain'])
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.