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.

ماذا يعني؟

قيمة تجزئة الفاتورة السابقة (KSA-13) يجب أن تكون SHA-256 مرمّزة بـ Base64 ومحسوبة بالطريقة المحددة في المعيار. وفي أول فاتورة تُستخدم القيمة الثابتة الخاصة بتجزئة "0".

السبب الشائع

حساب التجزئة على الملف كاملاً دون حذف الأجزاء المحددة، أو أخذها من فاتورة غير السابقة فعلياً في السلسلة.

طريقة التصحيح

احفظ تجزئة كل فاتورة بعد توقيعها، واستخدمها في الفاتورة التالية من الجهاز نفسه دون تخطٍ أو تكرار.

هل الرمز يرفض الفاتورة أم يكتفي بتحذير؟ العبرة برد المنصة نفسه: ما يأتي تحت الأخطاء يعني الرفض، وما يأتي تحت التحذيرات تمرّ معه الفاتورة.

رموز قريبة

النص الرسمي من جدول قواعد التحقق في معيار تنفيذ الفاتورة الإلكترونية بصيغة XML الصادر عن الهيئة (الإصدار 1.2، القسم 13) · الوثيقة الرسمية. الشرح صياغتنا التوضيحية، وليس رأيًا نظاميًا.