BR-KSA-29كتلة التوقيع لا تحمل معرِّف التوقيع المطلوب
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-29.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-29]-If the cryptographic stamp (KSA-15) exists in the invoice, this cryptographic stamp (KSA-15) must contain the exact "urn:oasis:names:specification:ubl:signature:Invoice" value for referenced signature ID and signature ID.
فحوص أخرى تُذكر في التقرير نفسه
BR-KSA-28
[BR-KSA-28]-If the cryptographic stamp (KSA-15) exists in the invoice, this cryptographic stamp (KSA-15) must contain the exact "urn:oasis:names:specification:ubl:signature:1" value for signature information ID.
BR-KSA-60
[BR-KSA-60]-Cryptographic stamp (KSA-15) must exist in simplified tax invoices and associated credit notes and debit notes (KSA-2, position 1 and 2 = 02).
BR-KSA-27
[BR-KSA-27]-The document must contain a QR code (KSA-14), and this code must be base64Binary.
BR-KSA-30
[BR-KSA-30]-The document cryptographic stamp (KSA-15) must contain the exact "urn:oasis:names:specification:ubl:dsig:enveloped:xades" value for signature method.
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
كتلة التوقيع لا تحمل معرِّف التوقيع المطلوب
صورة القيمة في التقريرsignature_id_mismatchليس معرِّف التوقيع المطلوب
ما الخلل
المستند فاتورة مبسطة، ولا يحمل أي عنصر cac:Signature فيه عنصر cbc:ID قيمته urn:oasis:names:specification:ubl:signature:Invoice بالضبط. وترصد هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-29، وتصنّف الهيئة هذه القاعدة تحذيراً لا خطأً في أداة الفحص الحالية لديها، فالتحذير وحده لا يؤدي إلى رفض المستند. وهذه القيمة معرِّف موحد URN ثابت في معيار UBL لا غير: فهي غير محسوبة، وغير مشتقّة من شيء في هذه الفاتورة، ولا صلة لها بالختم المميز ولا بشهادة ولا بمفتاح خاص. يكتبها نظامك حرفياً، والفحص مقارنة صارمة بهذا النص؛ فالمعرِّف الذي غُيِّر جزء منه، والمبتور، والمكتوب بحالة أحرف مختلفة، والمنقول عن معيار آخر، والمستند الخالي من عنصر cac:Signature أصلاً، كلها تخفق على النحو نفسه. وتجري المقارنة على كل عنصر cac:Signature في المستند مهما عمق موضعه، ويكفي أن تحمل كتلة واحدة القيمة المطلوبة؛ فقد تحمل كتلة أخرى، كالمعلَّقة على شهادة صنف في أحد البنود، معرِّفاً خاصاً بها دون أن يكون ذلك خللاً. واقرأ سكوت القاعدة BR-KSA-60 بحذر: فهي لا تطلب إلا وجود كتلة cac:Signature وألّا تكون خالية، فالكتلة الحاملة لمعرِّف خاطئ تجتازها وتُرصد هنا. وتسمّي رسالة الهيئة في هذه القاعدة المطلوبَ الختم المميز KSA-15، والفحص خلفها لا يفحص ختماً. وتسري القاعدة على الفاتورة المبسطة وإشعاراتها الدائنة والمدينة، أي ما يبدأ رمز نوع معاملة الفاتورة KSA-2 فيه بـ 02.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
اكتب القيمة الثابتة كما هي: العنصر cbc:ID داخل العنصر cac:Signature، ونصه urn:oasis:names:specification:ubl:signature:Invoice بحروفه وحالة أحرفه. ويمكن كتابته من قالب التصدير دون شرط، فهو لا يتغيّر من فاتورة إلى أخرى ولا يتوقف على تنفيذ خطوة التوقيع. وفواتير الهيئة المبسطة النموذجية تحمله، وإلى جانبه العنصر cbc:SignatureMethod بالقيمة urn:oasis:names:specification:ubl:dsig:enveloped:xades؛ فتحقّق منه وأنت هناك، فهو موضوع القاعدة المجاورة BR-KSA-30، ويخفق المستند فيها على حدة. والأسباب المعتادة: قالب يملأ هذا العنصر بقيمة خاصة بالفاتورة كرقمها أو كمعرِّف مولَّد، ومكتبة UBL عامة تُخرج كتلة مرجع توقيع بمعرِّف افتراضي خاص بها، وقيمة أُعيدت كتابتها باليد فتصحّف جزء منها، وقالب منقول عن نموذج سابق للمرحلة الثانية. وإن كان المستند خالياً من عنصر cac:Signature أصلاً فستظهر معه ملاحظة القاعدة BR-KSA-60؛ وإضافة الكتلة بالقيمتين الثابتتين تُغلق الملاحظتين معاً.
الختم المميز لا يشير إلى توقيع الفاتورة
صورة القيمة في التقريرreferenced_signature_id_mismatchلا يشير إلى توقيع الفاتورة
ما الخلل
معرّف التوقيع المشار إليه داخل الختم المميز (sac:SignatureInformation/sbc:ReferencedSignatureID تحت ext:UBLExtensions) غير موجود، أو ليس urn:oasis:names:specification:ubl:signature:Invoice. والقاعدة BR-KSA-29 تشترط أن يحمل هذا العنصر والعنصر cac:Signature/cbc:ID هذه القيمة بعينها. وتصنّف الهيئة هذه القاعدة تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. والفاتورة المبسطة التي لم تُوقَّع بعد لا ختم فيها، فهذه الملاحظة متوقعة فيها إلى أن تُوقَّع.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
إن كان حل الفوترة الإلكترونية لديك يوقّع الفاتورة فتحقّق أن خطوة التوقيع تكتب القيمة في الموضعين دون تغيير. وإن كنت تفحص ملف XML قبل توقيعه فستزول هذه الملاحظة بعد إضافة التوقيع.
أحد مرفقات الفاتورة لا يحمل عنصر الحمولة
صورة القيمة في التقريرpayload_element_missingعنصر الحمولة غير موجود
ما الخلل
ولا ترصد هذه الملاحظة إلا حزم القواعد السابقة للإصدار 2.0.0. ففي الإصدار 3.0.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك كانت القاعدة BR-KSA-29 مكتوبة في ثلاثة شروط، وشرطها الثالث وحده هو المعنيّ بمعرِّف التوقيع؛ أما الشرطان الأولان فعن المرفقات: إذ كانت الهيئة تفحص القاعدة مرة عن كل مرفق cac:AdditionalDocumentReference/cac:Attachment في المستند، عدا مرفق بصمة الفاتورة السابقة، وتشترط أن يحمل كل واحد منها عنصر cbc:EmbeddedDocumentBinaryObject غير فارغ. وهنا مرفق من تلك المرفقات، وهو في الفاتورة المبسطة مرفق رمز الاستجابة السريعة عادةً، لا يحمل عنصر الحمولة أصلاً، فكانت القاعدة تخفق عند هذا الشرط. أما في الإصدار 3.4.8 الذي تقرؤه حزمة القواعد 2.0.0 فالقاعدة BR-KSA-29 لم تعد تنظر في حمولة المرفق: بل تقارن معرِّف التوقيع ومعرّف التوقيع المشار إليه في الختم المميز، وتصنّف ذلك تحذيراً، فلا يحمل هذه الملاحظة تقرير صادر عن الحزمة 2.0.0. والخلل نفسه ما زال يُرصد: فالقاعدة BR-KSA-30 أبقت شرطي الحمولة وترفض المستند بموجبهما، وتذكر قواعد رمز الاستجابة السريعة العنصر نفسه. وليست هذه الملاحظة دليلاً على خلل في كتلة cac:Signature عندك.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
عالج المرفق لا كتلة التوقيع. والبنية مستويان داخل المرجع: عنصر cac:Attachment ثم عنصر cbc:EmbeddedDocumentBinaryObject بداخله، وتكون الحمولة بترميز base64 هي محتواه النصي. والأسباب المعتادة: قالب يكتب المرجع ومعرِّفه من حلقة ويكتب المرفق من حلقة أخرى لم تُنفَّذ، وقيمة تُكتب في نص المرجع نفسه أو في عنصر وصف بدل المرفق، ومستوى تداخل سقط فصار العنصر الثنائي واقعاً مباشرة تحت المرجع. وإن كان تصديرك يكتب إلى جانب مرجع الرمز مرجع مستند خاصاً به، كإشعار تسليم أو عقد، فمرفقه محكوم بالقاعدة BR-KSA-30 كذلك؛ فالكتلة التي تُكتب بلا حمولتها لغرض عندك تبلغ تلك القاعدة أيضاً. أما عنصر الحمولة الموجود الفارغ فخلل آخر يُذكر في ملاحظة مستقلة.
حمولة أحد مرفقات الفاتورة فارغة
صورة القيمة في التقريرpayload_emptyالحمولة فارغة
ما الخلل
ولا ترصد هذه الملاحظة إلا حزم القواعد السابقة للإصدار 2.0.0. ففي الإصدار 3.0.8 من حزمة أدوات التطوير SDK التي تنشرها هيئة الزكاة والضريبة والجمارك كانت القاعدة BR-KSA-29 مكتوبة في ثلاثة شروط، وشرطها الثالث وحده هو المعنيّ بمعرِّف التوقيع؛ أما الشرطان الأولان فعن المرفقات: إذ كانت الهيئة تفحص القاعدة مرة عن كل مرفق cac:AdditionalDocumentReference/cac:Attachment في المستند، عدا مرفق بصمة الفاتورة السابقة، وتشترط أن يحمل كل واحد منها عنصر cbc:EmbeddedDocumentBinaryObject غير فارغ. وهنا مرفق من تلك المرفقات، وهو في الفاتورة المبسطة مرفق رمز الاستجابة السريعة عادةً، يحمل عنصر الحمولة ولا شيء فيه، فكانت القاعدة تخفق عند هذا الشرط: فإفراغ حمولة رمز الاستجابة السريعة في فاتورة مبسطة مجتازة للفحص كان يجعل الإصدار 3.0.8 يُخرج القواعد BR-KSA-28 وBR-KSA-29 وBR-KSA-30. أما في الإصدار 3.4.8 الذي تقرؤه حزمة القواعد 2.0.0 فالقاعدة BR-KSA-29 لم تعد تنظر في حمولة المرفق: بل تقارن معرِّف التوقيع ومعرّف التوقيع المشار إليه في الختم المميز، وتصنّف ذلك تحذيراً، فلا يحمل هذه الملاحظة تقرير صادر عن الحزمة 2.0.0. والخلل نفسه ما زال يُرصد: فالقاعدة BR-KSA-30 أبقت شرطي الحمولة وترفض المستند بموجبهما، وترصد قاعدة طول رمز الاستجابة السريعة حمولة الرمز الفارغة كذلك. وليست هذه الملاحظة دليلاً على خلل في كتلة cac:Signature عندك.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
العنصر يُكتب والقيمة خلفه لا تُكتب، فالربط يُنتج المرفق دون شرط بينما الخطوة التي تملؤه لا تعمل أو لا تُرجع شيئاً. وهذه الخطوة في الفاتورة المبسطة هي مولّد رمز الاستجابة السريعة عادةً: تحقّق من أنه يعمل قبل تسلسل المستند، ومن أنه مفعَّل لنوع المستند هذا. وعالج المولّد أو الربط، لا بحذف العنصر الفارغ: فحذف كتلة الرمز ينقل المستند إلى القاعدة BR-KSA-27 لغياب مرجع رمز الاستجابة السريعة. ولا تحتاج كتلة cac:Signature عندك إلى تغيير من أجل هذه الملاحظة، لكن تأكّد وأنت هناك من أن العنصرين cbc:ID وcbc:SignatureMethod فيها يحملان المعرِّفين الموحدين الثابتين: فالقاعدة BR-KSA-30 لا تبلغ شرط طريقة التوقيع إلا بعد امتلاء الحمولة، فقد يكون خلف خلل الحمولة معرِّف خاطئ ينتظر.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not((//cac:Signature/cbc:ID) = 'urn:oasis:names:specification:ubl:signature:Invoice' and (normalize-space(//ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/sig:UBLDocumentSignatures/sac:SignatureInformation/sbc:ReferencedSignatureID)) = 'urn:oasis:names:specification:ubl:signature:Invoice' )
التعبير المذكور في التقرير
exists(cbc:EmbeddedDocumentBinaryObject) and (cbc:EmbeddedDocumentBinaryObject) != '' and (//cac:Signature/cbc:ID) = 'urn:oasis:names:specification:ubl:signature:Invoice'
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.