BR-KSA-26 🔐 التشفير والتوقيع والهاش error

BR-KSA-26: خطأ في احتساب هاش الفاتورة السابقة (PIH / KSA-13)

BR-KSA-26: Invalid Previous Invoice Hash Calculation (PIH / KSA-13)

المواصفة التقنية المعتمدة من زاتكا:

يجب احتساب هاش الفاتورة السابقة عبر تحويل XML المعياري (C14N11) وتشفيره بـ SHA-256 وBase64. وبالنسبة للفاتورة الأولى على الجهاز، يجب استخدام الهاش الصفري المعتمد.

XPath Context: /ubl:Invoice/cac:AdditionalDocumentReference[cbc:ID='PIH']/cac:Attachment/cbc:EmbeddedDocumentBinaryObject

📌 نبذة عن القاعدة وسبب التدقيق

يجب أن يكون هاش الفاتورة السابقة (KSA-13) مشفراً بـ Base64 لترميز SHA-256 للفاتورة السابقة، أو الهاش المبدئي الصفري للفاتورة الأولى.

English Description: Previous invoice hash (KSA-13) must be Base64-encoded SHA-256 digest of the canonicalized previous invoice XML (or the standard zero seed for the 1st invoice).

⚠️ الأسباب الشائعة لظهور الخطأ ورفض الفاتورة

✕ انقطاع تسلسل الهاش بين الفاتورة الحالية والفاتورة السابقة على نفس الجهاز
✕ عدم استخدام الهاش الصفري الصحيح للفاتورة الأولى بعد تهيئة شهادة CSID
✕ احتساب الهاش بعد التوقيع بدلاً من احتسابه على ملف XML بعد إزالة عناصر التوقيع والـ QR
✕ وجود مسافات بيضاء أو أسطر إضافية تؤدي لتغير بصمة SHA-256

✅ خطوات الحل وتصحيح الفاتورة

استخدام الهاش المبدئي للفاتورة الأولى

للفاتورة الأولى على الجهاز، استخدم القيمة: 'NWZIY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiINTdIQ=='.

تطبيق المعيارية C14N11

قم بإزالة عناصر UBLExtensions وعقدة QR والتوقيع، ثم طبق C14N واحتسب SHA-256 وحوله إلى Base64.

حفظ الهاش في قاعدة البيانات للتسلسل

احفظ هاش الفاتورة الحالية في قاعدة البيانات ليكون هو الهاش السابق للفاتورة التالية على نفس الجهاز.

💻 نموذج برمجي لمقارنة ملف XML (قبل وبعد التصحيح)

❌ النموذج الخاطئ (مرفوض من زاتكا) Invalid XML

<cac:AdditionalDocumentReference>
  <cbc:ID>PIH</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">0</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

✓ النموذج الصحيح (المعتمد رسمياً) Valid UBL 2.1

<cac:AdditionalDocumentReference>
  <cbc:ID>PIH</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">NWZIY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiINTdIQ==</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

تحقق من صحة ملف الفاتورة الآن مجاناً

استخدم أدوات قيمة لفحص بنية XML والتأكد من عدم وجود أخطاء قبل إرسال الفواتير لمنصة زاتكا.

فحص XML والهاش ← محلل رمز QR ←

❓ الأسئلة الشائعة حول BR-KSA-26

ماذا يحدث إذا فقدت قاعدة البيانات هاش الفاتورة الأخيرة؟

انقطاع سلسلة الهاش يسبب رفض الفواتير اللاحقة، ويجب استرجاع آخر فاتورة مقبولة أو إعادة تهيئة الجهاز عبر طلب شهادة CSID جديدة.

🔗 قواعد وأخطاء زاتكا ذات صلة

BR-KSA-27

BR-KSA-27: رمز الاستجابة السريعة (QR Code / KSA-14) مفقود أو غير مطابق

يجب أن تحتوي الفاتورة على رمز QR مشفر بنظام Base64 ومبني بترميز TLV وفق متطلبات المرحلة الثانية من هيئة الزكاة.

INVALID-INVOICE-HASH

خطأ هاش الفاتورة غير صالح: عدم تطابق بصمة الفاتورة الرقمية

بصمة SHA-256 المحتسبة لملف XML لا تطابق البصمة المستخرجة بواسطة مدقق زاتكا نتيجة أخطاء في التحويل المعياري C14N.

ودّع مشاكل الربط وأخطاء الفوترة مع برنامج قيمة

يتكفل نظام قيمة بكافة متطلبات هيئة الزكاة والضريبة والجمارك تلقائياً في الخلفية: اعتماد فوري للفواتير، توقيع رقمي، وربط كامل مع منصة فاتورة.

ابدأ تجربتك المجانية الآن ← تصفح باقي قواعد أخطاء زاتكا