التجزئة (Hashing) في الفاتورة الإلكترونية

عند انتقال منشأتك إلى المرحلة الثانية من الفوترة الإلكترونية، تتغير الفاتورة من مستند بصري إلى مستند رقمي موقَّع ومُسلسَل. وفي قلب هذه السلسلة تقنية واحدة تضمن أن كل فاتورة لم تُمسّ بعد إصدارها: التجزئة (Hashing). هذا التوثيق التقني يشرح مفهوم التجزئة كما تستخدمه هيئة الزكاة والضريبة والجمارك (ZATCA)، وخصائصه الرياضية، وما الذي يُجزَّأ بالضبط، والفرق بينه وبين التشفير والتوقيع الرقمي، مع أمثلة برمجية عملية.

هذا المحتوى موجَّه للمطوّرين ومسؤولي التكامل التقني الذين يبنون أو يدمجون أنظمة فوترة مع منصة فاتورة. إن كنت تبحث عن الصورة الكاملة لمتطلبات الفوترة الإلكترونية، فابدأ من دليل الفاتورة الإلكترونية من قيود، ثم عُد إلى هنا للتفصيل التقني. كثير من المطوّرين يصلون إلى مرحلة التكامل وهم يفهمون متطلبات الفاتورة الوظيفية، لكنهم يتعثّرون في الطبقة التشفيرية. والتجزئة هي حجر الزاوية في هذه الطبقة، فمن دون فهمها يصعب تشخيص أسباب رفض الفواتير من المنصة.

ما هي دالة التجزئة (Hash Function)؟

دالة التجزئة هي خوارزمية رياضية تأخذ مدخلًا بأي حجم (نص، ملف، رسالة) وتُنتج مخرجًا بطول ثابت يُسمى قيمة التجزئة أو البصمة الرقمية (digest). مهما كان حجم المدخل، يبقى طول المخرج ثابتًا. فمثلًا تُنتج دالة SHA-256 دائمًا بصمة بطول 256 بت (64 رمزًا في النظام الست عشري)، سواء كان المدخل كلمة واحدة أو فاتورة من مئة بند.

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

يمكن تشبيه البصمة ببصمة الإصبع البشرية. البصمة لا تحمل صورة الشخص ولا تخبرك بطوله أو لونه، لكنها تميّزه تمييزًا فريدًا، ويكفي اختلاف بسيط ليتغير شكلها. كذلك بصمة الفاتورة لا تكشف محتواها، لكنها تمثّله تمثيلًا فريدًا، فإن تطابقت بصمتان فالمستندان متطابقان، وإن اختلفتا فقد اختلف المستندان ولو بحرف. هذا التشبيه يوضّح لماذا تصلح التجزئة للتحقق من الهوية والسلامة معًا.

من المفيد التمييز بين دوال التجزئة العامة ودوال التجزئة التعموية (Cryptographic Hash Functions). الأولى تُستخدم في هياكل البيانات مثل جداول التجزئة لتسريع البحث، ولا يشترط فيها مقاومة الهجمات. أما الثانية، وهي ما يهمنا في الفوترة الإلكترونية، فمصمَّمة خصيصًا لمقاومة محاولات التزوير والاصطدام، وهي وحدها المعتمدة في تطبيقات الأمان والامتثال.

لنوضّح بمثال ملموس. لو جزّأنا النص "فاتورة" ثم جزّأنا النص "فاتوره" (بتاء مفتوحة بدل المربوطة)، سنحصل على بصمتين مختلفتين كليًا رغم أن الفرق حرف واحد:

SHA-256("فاتورة") = 7d3a9f2c8b1e4f6a0d5c2b8e9a1f4d7c...
SHA-256("فاتوره") = e2b8c1a4f9d6037e5a8b2c1d4e7f0a93...

لاحظ أن البصمتين لا تشتركان في أي نمط، رغم أن المدخلين متشابهان بنسبة تكاد تكون كاملة. هذا السلوك ليس صدفة، بل نتيجة مباشرة للخصائص الرياضية التي صُمّمت دوال التجزئة عليها. ولفهم سبب اعتماد الهيئة على هذه التقنية تحديدًا، لا بد من الوقوف على خصائصها الثلاث.

الخصائص الثلاث لدوال التجزئة

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

1. أحادية الاتجاه (One-Way / Pre-image Resistance)

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

السبب أن التجزئة عملية فاقدة للبيانات. تختزل الدالة مدخلًا قد يبلغ آلاف الرموز في 256 بت ثابتة، فتُفقَد المعلومات الكافية لإعادة البناء. الطريقة الوحيدة نظريًا لإيجاد مدخل يطابق بصمة معينة هي التجربة العمياء لعدد هائل من الاحتمالات، وهو أمر يفوق القدرة الحاسوبية المتاحة. هذه الخاصية تعني أن نشر بصمة الفاتورة لا يكشف أي شيء عن محتواها الفعلي.

2. الحتمية (Deterministic)

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

لو كانت الدالة تُنتج قيمة مختلفة في كل مرة، لانعدمت إمكانية التحقق تمامًا. الحتمية هي ما يجعل البصمة مرجعًا ثابتًا يُعتمد عليه عبر الأطراف والأنظمة المختلفة، وهي شرط لا غنى عنه في أي بروتوكول تحقق موزَّع.

3. أثر الانهيار (Avalanche Effect)

أي تغيير بسيط في المدخل، ولو بمقدار بت واحد، يُحدث تغييرًا جذريًا وغير متوقع في البصمة الناتجة. تتغير قرابة نصف بتات المخرج في المتوسط. هذا يعني أنه لا يمكن التنبؤ بكيفية تأثير تعديل صغير على البصمة، ولا يمكن صياغة تعديل محسوب يُبقي البصمة ثابتة.

في سياق الفاتورة، لو حاول طرف ما تغيير المبلغ من 1,000 ر.س إلى 10,000 ر.س، فإن بصمة الفاتورة ستتغير كليًا. ولأن البصمة مُسجَّلة ومربوطة بسلسلة الفواتير، يُكشف التلاعب فورًا عند أي عملية تحقق. أثر الانهيار هو ما يمنع المتلاعب من إجراء تعديلات تجميلية على الفاتورة دون أن تترك أثرًا واضحًا.

خاصية رابعة داعمة: مقاومة التصادم (Collision Resistance)

إلى جانب الخصائص الثلاث، تتميز دوال التجزئة التعموية بمقاومة التصادم. التصادم يعني أن يجد مهاجم مدخلين مختلفين يُنتجان البصمة نفسها. لو أمكن ذلك بسهولة، لاستطاع شخص استبدال فاتورة بأخرى مزوّرة تحمل البصمة نفسها، فيمرّ التزوير دون كشف.

دوال مثل SHA-256 مصمَّمة بحيث يكون إيجاد تصادم متعمَّد أمرًا يفوق القدرة الحاسوبية الواقعية. ولهذا السبب تتجنّب الأنظمة الحديثة الدوال القديمة الضعيفة مثل MD5 و SHA-1، التي ثبت ضعفها أمام هجمات التصادم، وتعتمد دالة حديثة قوية. هذه المقاومة هي ما يجعل البصمة دليلًا يُعتدّ به على هوية المستند.

لماذا تعتمد الهيئة على التجزئة في الفوترة الإلكترونية؟

اختارت الهيئة التجزئة لأنها تحقق هدفين جوهريين في المرحلة الثانية: إثبات سلامة المستند (Integrity) وكشف العبث (Tamper-evidence). دعنا نفصّل كلًا منهما، فهما يفسّران لماذا أصبحت البصمة حقلًا إلزاميًا في كل فاتورة.

إثبات سلامة المستند

عندما تُصدر منشأتك فاتورة وفق المرحلة الثانية، يُحسَب لها بصمة تجزئة من محتواها بصيغته القانونية. تُرفَق هذه البصمة بالفاتورة وتُرسَل ضمن البيانات إلى منصة فاتورة. يستطيع أي طرف لاحقًا، سواء الهيئة أو المشتري أو مدقق حسابات، إعادة حساب البصمة من نسخة الفاتورة التي بحوزته ومقارنتها بالبصمة الأصلية. التطابق يُثبت أن الفاتورة لم تتغير منذ لحظة إصدارها.

هذا النموذج يحوّل الثقة من اعتماد على حسن النية إلى اعتماد على البرهان الرياضي. لم يعد أحد مضطرًا لتصديق أن الفاتورة لم تُعدَّل، بل يستطيع التحقق من ذلك بنفسه عبر إعادة حساب البصمة. وهذا تحوّل جوهري في طبيعة المستند المحاسبي.

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

كشف العبث عبر سلسلة الفواتير

لا تقف التجزئة عند الفاتورة الواحدة. تشترط الهيئة أن تحمل كل فاتورة بصمة الفاتورة السابقة لها في حقل يُعرف بـ PIH (Previous Invoice Hash). بهذا تترابط الفواتير في سلسلة متصلة، كل حلقة فيها تعتمد على الحلقة التي قبلها. هذا الترابط هو ما يجعل دفتر فواتير المنشأة سجلًا لا يقبل الحذف ولا الإدراج الخفي بأثر رجعي.

لو حاول أحدهم تعديل فاتورة قديمة في منتصف السلسلة، ستتغير بصمتها، ولن تعود مطابقة لحقل PIH المخزَّن في الفاتورة التالية. ينكسر التطابق وتنكشف السلسلة كلها. لإخفاء التلاعب، سيضطر المتلاعب إلى إعادة حساب بصمات كل الفواتير اللاحقة وإعادة توقيعها، وهو أمر غير ممكن عمليًا لأن الفواتير سبق أن أُرسلت ووُثّقت لدى الهيئة. هذا المبدأ مستعار من تقنية سلاسل الكتل (blockchain) ويمنح دفتر الفواتير خاصية عدم القابلية للتغيير.

للتوسع في حقل بصمة الفاتورة السابقة وكيفية حسابه في أول فاتورة من السلسلة، خصّصنا له توثيقًا تقنيًا مستقلًا حول حقل PIH ضمن هذا القسم. أما الخوارزمية المحددة التي تعتمدها الهيئة لحساب البصمات (SHA-256) فلها كذلك توثيق مفصّل يشرح بنيتها وطول مخرجها وأسباب اختيارها. والفكرة المحورية هنا أن الفاتورة الأولى من السلسلة لا تملك فاتورة سابقة، فتُعطى قيمة افتراضية محددة في حقل PIH، ثم تنطلق السلسلة منها.

ما الذي يُجزَّأ بالضبط؟

هنا تكمن نقطة دقيقة كثيرًا ما يخطئ فيها المطوّرون. الهيئة لا تُجزّئ الفاتورة كما تراها بصريًا (PDF أو صورة)، بل تُجزّئ الصيغة القانونية للفاتورة بلغة XML وفق معيار UBL 2.1. هذه الصيغة هي المستند الرسمي، والتمثيل البصري مجرد عرض لها. أي محاولة لحساب البصمة من ملف PDF أو من النص المرئي ستفشل، لأن المستند المعتمد لدى الهيئة هو ملف XML المهيكل.

لكن قبل التجزئة، تمرّ الفاتورة بخطوة حاسمة تُسمى التقنين (Canonicalization). ملف XML يمكن كتابته بطرق متعددة تؤدي المعنى نفسه: مسافات بادئة مختلفة، ترتيب سمات مختلف، أسطر فارغة، فروق في الترميز. كل هذه الفروق الشكلية لا تغيّر معنى الفاتورة، لكنها تغيّر البايتات، وبالتالي تغيّر البصمة الناتجة.

لحل هذه المشكلة، تُطبَّق خوارزمية تقنين قياسية (C14N) تحوّل ملف XML إلى صيغة موحَّدة لا لبس فيها قبل حساب البصمة. بهذا يحصل المُصدِر والمُستقبِل على البصمة نفسها انطلاقًا من الفاتورة نفسها، بصرف النظر عن الفروق الشكلية في كتابة الملف. التقنين ليس تفصيلًا اختياريًا، بل شرط أساسي لتطابق البصمات عبر الأنظمة.

الخطوات العملية لحساب بصمة فاتورة وفق متطلبات الهيئة تجري على هذا النحو:

1. توليد الفاتورة بصيغة XML وفق معيار UBL 2.1
2. تطبيق التقنين (C14N) لتوحيد صيغة الملف
3. حساب البصمة بخوارزمية SHA-256 على الناتج المُقنَّن
4. ترميز البصمة بصيغة Base64 لإدراجها في الحقول
5. ربط البصمة بسلسلة الفواتير عبر حقل PIH

إليك مثالًا توضيحيًا بلغة Python يحسب بصمة محتوى نصي بخوارزمية SHA-256 ثم يرمّزها بصيغة Base64، وهو جوهر ما يجري على ملف XML المُقنَّن:

import hashlib
import base64

# محتوى الفاتورة بصيغة XML بعد التقنين
canonical_xml = "<Invoice>...</Invoice>".encode("utf-8")

# حساب البصمة بخوارزمية SHA-256
digest = hashlib.sha256(canonical_xml).digest()

# الترميز بصيغة Base64 لإدراجها في الفاتورة
invoice_hash = base64.b64encode(digest).decode("utf-8")

print(invoice_hash)
# مثال للمخرج: NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzk=

ولأن الكثير من أنظمة الفوترة تعمل بلغة JavaScript على الواجهة الخلفية، إليك المكافئ نفسه:

const crypto = require("crypto");

// محتوى الفاتورة بصيغة XML بعد التقنين
const canonicalXml = "<Invoice>...</Invoice>";

// حساب البصمة بخوارزمية SHA-256 ثم ترميزها Base64
const invoiceHash = crypto
  .createHash("sha256")
  .update(canonicalXml, "utf8")
  .digest("base64");

console.log(invoiceHash);

ولمن يتحقق يدويًا أثناء التطوير، يمكن حساب البصمة الست عشرية لملف مُقنَّن من سطر الأوامر مباشرة:

openssl dgst -sha256 invoice_canonical.xml
# SHA256(invoice_canonical.xml)= 5fececb6ffc86f38d952786c6d696c79...

ملاحظة مهمة للمطوّرين: لا تحسب البصمة على ملف XML الخام مباشرة. التقنين خطوة إلزامية، وإغفالها هو السبب الأكثر شيوعًا لرفض الفاتورة من منصة فاتورة بسبب عدم تطابق البصمة. ملف XML نفسه الذي تُحسب منه البصمة هو موضوع توثيق فاتورة XML الإلكترونية، أما الحقول الإلزامية وترتيبها فمشروحة في توثيق هيكل الفاتورة الإلكترونية، ويُنصح بمراجعتهما جنبًا إلى جنب مع هذا التوثيق.

التجزئة مقابل التشفير مقابل التوقيع الرقمي

يخلط كثيرون بين هذه المفاهيم الثلاثة لأنها كلها تنتمي إلى علم التعمية (Cryptography)، لكنها تخدم أغراضًا مختلفة كليًا. التمييز بينها ضروري لفهم منظومة المرحلة الثانية، ولتشخيص الأخطاء عند التكامل.

الفروق الجوهرية تتلخص فيما يلي:

التجزئة (Hashing): عملية أحادية الاتجاه لا تحتاج مفتاحًا. غرضها إثبات سلامة البيانات وكشف أي تغيير عليها. لا يمكن عكسها ولا استعادة المدخل منها. هي ما يضمن أن الفاتورة لم تُعدَّل. والمخرج بطول ثابت مهما كان حجم المدخل.

التشفير (Encryption): عملية عكوسة تحتاج مفتاحًا. غرضها إخفاء البيانات عن الأطراف غير المصرَّح لها (السرية). يمكن فك التشفير واستعادة البيانات الأصلية بالمفتاح الصحيح. التشفير يخفي المحتوى، أما التجزئة فلا تخفيه بل تبصمه. ومن المهم ملاحظة أن الفاتورة في المرحلة الثانية ليست مشفّرة، بل مُوقَّعة ومبصومة، لأن الهدف هو الإثبات لا الإخفاء. الفاتورة وثيقة ضريبية يجب أن تكون مقروءة للأطراف المعنية، لا مخفية عنها.

التوقيع الرقمي (Digital Signature): يبني على التجزئة ويضيف إليها عنصر الأصالة. يُحسَب أولًا بصمة المستند، ثم تُشفَّر هذه البصمة بالمفتاح الخاص للمُصدِر. النتيجة توقيع يُثبت أمرين معًا: أن المستند لم يتغير (سلامة، من التجزئة)، وأنه صادر فعلًا عن صاحب المفتاح الخاص (أصالة). التوقيع الرقمي في المرحلة الثانية يُعرف بالختم التشفيري (Cryptographic Stamp) ويعتمد على شهادة CSID صادرة عن الهيئة.

الخلاصة أن التجزئة هي اللبنة الأساس. التوقيع الرقمي يستخدمها داخليًا، والمنظومة كلها تقوم عليها. فكل توقيع رقمي يبدأ بحساب بصمة تجزئة، ولا يمكن إنشاء توقيع سليم دون تجزئة سليمة قبله. تفاصيل التوقيع الرقمي والختم التشفيري وشهادة CSID موضوعة في توثيقين مستقلين ضمن هذا القسم، أحدهما لمواصفة التوقيع الرقمي والآخر لمواصفة الختم التشفيري.

أين تظهر البصمة في الفاتورة؟

بعد حساب البصمة بصيغة Base64، تظهر في موضعين أساسيين ضمن منظومة المرحلة الثانية. أولهما رمز الاستجابة السريعة (QR Code) على الفاتورة المبسّطة (B2C)، حيث تُضمَّن البصمة ضمن بيانات الرمز ليتمكن أي طرف من التحقق بمسح الرمز. وثانيهما الحقول الداخلية لملف XML، حيث تُسجَّل بصمة الفاتورة الحالية وحقل PIH لبصمة الفاتورة السابقة.

هذا الربط الثلاثي بين البصمة والتوقيع والرمز هو ما يحوّل الفاتورة من مستند بصري إلى وثيقة رقمية قابلة للتحقق آليًا من أي جهة في أي وقت. وبفضله، تستطيع الهيئة فحص ملايين الفواتير آليًا والتأكد من سلامتها دون تدخل بشري.

إلى جانب البصمة، تحمل الفاتورة معرّفات أخرى تكمّل منظومة التتبع، أبرزها المعرّف الفريد للفاتورة (UUID) وعدّاد الفواتير المتسلسل (ICV). العلاقة بين هذه المعرّفات وبصمة التجزئة وثيقة، إذ تتكامل جميعها لتثبت تسلسل الفواتير وعدم وجود فجوات أو حذف. لمن يريد التوسع في عدّاد الفواتير المتسلسل وكيفية ترقيمه، خصّصنا له توثيق عدّاد الفواتير ICV ضمن هذا القسم.

كيف تجري عملية التحقق عند الطرف المستقبِل؟

التحقق من سلامة الفاتورة عملية مباشرة تستفيد من الحتمية وأحادية الاتجاه معًا. عندما يستلم طرف ما الفاتورة (المنصة أو المشتري أو المدقق)، يجري الخطوات التالية:

• يأخذ ملف XML المستلم ويطبّق عليه خطوة التقنين نفسها التي طبّقها المُصدِر.
• يحسب بصمة SHA-256 على الناتج المُقنَّن.
• يقارن البصمة التي حسبها بالبصمة المرفقة في الفاتورة.
• إذا تطابقتا، فالفاتورة سليمة لم تُمسّ. إذا اختلفتا، فقد طرأ تغيير على الفاتورة ويُرفَض المستند.

الجمال في هذه العملية أن المستقبِل لا يحتاج للوثوق بالمرسِل، ولا لقناة آمنة، ولا لمفتاح سري. كل ما يحتاجه هو الفاتورة نفسها وخوارزمية التجزئة المعلنة. هذا ما يجعل التحقق متاحًا لأي طرف وفي أي وقت، وهو جوهر فكرة عدم القابلية للإنكار في المستندات الرقمية. وعند إضافة التوقيع الرقمي فوق البصمة، يصبح التحقق شاملًا للأصالة كذلك، فيُثبت من أصدر الفاتورة إلى جانب إثبات سلامتها.

القيمة الافتراضية لأول فاتورة في السلسلة

الفاتورة الأولى التي تصدرها منشأتك لا تملك فاتورة سابقة تستند إليها. في هذه الحالة، يُملأ حقل PIH بقيمة افتراضية محددة تمثّل بداية السلسلة، وهي بصمة قيمة معيارية تعرّفها الهيئة. من تلك النقطة، تبدأ كل فاتورة لاحقة بحمل بصمة سابقتها، فتنمو السلسلة فاتورة بعد فاتورة. الخطأ في هذه القيمة الافتراضية يكسر السلسلة من بدايتها، لذا تُعدّ نقطة تحقق أساسية عند التكامل لأول مرة.

كيف يساعدك قيود في التجزئة والفوترة الإلكترونية؟

التعقيد التقني الذي شرحناه أعلاه، من التقنين إلى حساب البصمة إلى ربط السلسلة، يجري بالكامل خلف الكواليس في قيود دون أي تدخل منك. لست بحاجة لكتابة سطر برمجي واحد ولا لفهم خوارزمية SHA-256 لتُصدر فاتورة متوافقة.

• توليد XML وتقنينه تلقائيًا: يُنشئ قيود الفاتورة بصيغة UBL 2.1 ويطبّق التقنين القياسي قبل حساب البصمة، فلا مجال لخطأ المسافات أو الترميز الذي يرفض الفاتورة.
• حساب البصمة وربط السلسلة: يحسب قيود بصمة كل فاتورة ويربطها تلقائيًا ببصمة الفاتورة السابقة عبر حقل PIH، ويحفظ سلسلة الفواتير كاملة للتحقق والتدقيق.
• إدارة شهادة CSID والختم التشفيري: يتولى قيود إدارة شهادة الختم التشفيري الصادرة عن الهيئة ويوقّع كل فاتورة آليًا دون عبء فني عليك.
• الربط مع منصة فاتورة: يرسل قيود الفواتير القياسية (B2B) للتصفية الفورية والفواتير المبسّطة (B2C) للإبلاغ خلال 24 ساعة، مع توليد رمز الاستجابة السريعة المتضمّن للبصمة.

أخطاء تقنية شائعة عند التعامل مع البصمة

من واقع التكامل مع منصة فاتورة، تتكرر مجموعة من الأخطاء التي تؤدي إلى رفض الفاتورة. الانتباه إليها يوفّر ساعات من تتبّع الأخطاء عند بناء نظام فوترة:

• إهمال التقنين: حساب البصمة على XML خام دون تطبيق C14N. أكثر الأسباب شيوعًا لعدم تطابق البصمة.
• اختلاف الترميز: استخدام ترميز غير UTF-8 عند تحويل النص إلى بايتات قبل التجزئة، ما يغيّر البصمة الناتجة.
• الخلط بين صيغ المخرج: إرسال البصمة بصيغة ست عشرية (hex) بينما تتوقعها المنصة بصيغة Base64، أو العكس.
• كسر سلسلة الـ PIH: إدراج بصمة الفاتورة السابقة الخاطئة أو إهمال القيمة الافتراضية لأول فاتورة في السلسلة.
• تعديل XML بعد الحساب: أي تعديل على الملف بعد حساب البصمة، ولو إضافة سطر فارغ، يُبطل التطابق ويجب إعادة الحساب من جديد.

الأسئلة الشائعة

هل يمكن استعادة بيانات الفاتورة من بصمة التجزئة؟

لا. التجزئة عملية أحادية الاتجاه بطبيعتها. البصمة تمثّل البيانات تمثيلًا فريدًا لكنها لا تحملها، فلا توجد طريقة عملية لعكس العملية واستعادة محتوى الفاتورة من البصمة وحدها.

ما الفرق بين التجزئة والتشفير في الفاتورة الإلكترونية؟

التجزئة عملية أحادية الاتجاه تثبت سلامة الفاتورة وتكشف العبث عليها دون إخفاء محتواها. التشفير عملية عكوسة تخفي المحتوى عن غير المصرَّح لهم. الفاتورة في المرحلة الثانية مبصومة وموقَّعة، وليست مشفّرة، لأن الهدف الإثبات لا الإخفاء.

ما الخوارزمية التي تعتمدها الهيئة لحساب البصمة؟

تعتمد الهيئة خوارزمية SHA-256 التي تُنتج بصمة بطول ثابت 256 بت من أي مدخل. لها توثيق تقني مستقل ضمن هذا القسم يشرح بنيتها وطول مخرجها وأسباب اختيارها.

لماذا يجب تطبيق التقنين قبل حساب البصمة؟

لأن ملف XML يمكن كتابته بطرق شكلية متعددة (مسافات، ترتيب سمات، أسطر فارغة) تؤدي المعنى نفسه لكنها تغيّر البايتات وبالتالي البصمة. التقنين يوحّد الصيغة قبل التجزئة ليحصل المُصدِر والمُستقبِل على البصمة نفسها.

ما علاقة التجزئة بسلسلة الفواتير؟

تحمل كل فاتورة بصمة الفاتورة السابقة في حقل PIH، فتترابط الفواتير في سلسلة كل حلقة فيها تعتمد على ما قبلها. تعديل أي فاتورة يكسر هذا الترابط ويكشف التلاعب فورًا.

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

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