تجزئة الفاتورة السابقة PIH

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

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

المرجع الرسمي هو متطلبات هيئة الزكاة والضريبة والجمارك (ZATCA) للفوترة الإلكترونية، ومخطط الفاتورة المبني على معيار UBL 2.1. عند أي تعارض بين ما هنا وبين المخطط الرسمي، يُعتمد المخطط الرسمي للهيئة.

ما هي تجزئة الفاتورة السابقة PIH بالتحديد؟

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

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

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

من المهم التفريق منذ البداية: PIH ليس مفهوم التجزئة نفسه، بل هو الحقل الذي يحمل ناتج تجزئة الفاتورة السابقة. مفهوم التجزئة كعملية رياضية، وخوارزمية SHA-256 التي تنفّذها، موضوعان مستقلان. هنا نتعامل مع الحقل وموقعه ودوره في السلسلة.

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

تقع قيمة PIH داخل كتلة AdditionalDocumentReference مخصصة، يميّزها المعرّف PIH في عنصر ID. القيمة نفسها تُكتب داخل عنصر EmbeddedDocumentBinaryObject الذي يحمل سمة mimeCode بالقيمة text/plain.

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

مثال XML كامل لكتلة PIH

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

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

لاحظ ثلاثة عناصر أساسية. الأول عنصر ID بالقيمة PIH الذي يحدد نوع المرجع. الثاني عنصر Attachment الحاوي. الثالث EmbeddedDocumentBinaryObject الذي يحمل البصمة مُرمّزة بصيغة Base64 مع mimeCode بقيمة text/plain.

موقع PIH بين كتل AdditionalDocumentReference الأخرى

تظهر كتلة PIH عادة بعد كتلة عدّاد الفاتورة ICV ضمن سلسلة من كتل AdditionalDocumentReference. المثال التالي يوضّح الترتيب التقريبي:

<cac:AdditionalDocumentReference>
    <cbc:ID>ICV</cbc:ID>
    <cbc:UUID>124</cbc:UUID>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
    <cbc:ID>PIH</cbc:ID>
    <cac:Attachment>
        <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
            NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzI=
        </cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
</cac:AdditionalDocumentReference>

كتلة ICV تحمل عدّاد الفاتورة، وهو رقم صحيح متسلسل تجده في دليل عدّاد الفاتورة ICV. كتلة PIH تحمل بصمة الفاتورة السابقة. الحقلان مرتبطان وظيفيًا لكنهما منفصلان بنيويًا، ولكل منهما كتلته الخاصة.

كيف تربط تجزئة الفاتورة السابقة الفواتير في سلسلة؟

هنا يكمن جوهر الفكرة. كل فاتورة تحمل في داخلها بصمة الفاتورة التي سبقتها. هذا يبني ما يشبه السلسلة المعدنية، حلقة متصلة بالتي قبلها.

تخيّل ثلاث فواتير متتالية على الجهاز نفسه. الفاتورة الأولى لها بصمتها الخاصة. الفاتورة الثانية تكتب بصمة الأولى في حقل PIH الخاص بها. الفاتورة الثالثة تكتب بصمة الثانية في حقل PIH الخاص بها. وهكذا تستمر السلسلة.

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

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

العلاقة بين PIH و ICV خطوة بخطوة

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

1. يصدر الجهاز فاتورة جديدة، فيزيد عدّاد الفاتورة ICV بمقدار واحد عن الفاتورة السابقة.
2. يجلب النظام بصمة الفاتورة السابقة المخزّنة، ويكتبها في حقل PIH للفاتورة الجديدة.
3. تُحسب بصمة الفاتورة الجديدة بالكامل، ويُحتفظ بها لتكون قيمة PIH للفاتورة التالية.
4. تُرسل الفاتورة إلى منصة فاتورة للاعتماد أو الإبلاغ بحسب نوعها.

العدّاد يقول «هذه الفاتورة رقم 125 على هذا الجهاز». التجزئة تقول «وهي مرتبطة بالفاتورة رقم 124 ببصمتها كما هي تمامًا». الرقمان معًا يثبتان التسلسل والسلامة في آن واحد.

ما الحالة الأساسية لأول فاتورة على الجهاز؟

سؤال منطقي يطرحه كل مطوّر: ما الذي يُكتب في حقل PIH للفاتورة الأولى، ولا توجد قبلها فاتورة سابقة أصلًا؟ هذه هي الحالة الأساسية في السلسلة.

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

القيمة الثابتة المستخدمة هي:

NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTc=

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

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

لماذا يجب أن تكون السلسلة متصلة دون انقطاع؟

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

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

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

الأخطاء الشائعة التي تكسر السلسلة

تتكرر مجموعة من الأخطاء عند تنفيذ حقل PIH، وكلها تؤدي إلى رفض الفاتورة أو كسر السلسلة:

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

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

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

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

عدّاد الفاتورة ICV رقم صحيح متسلسل يجيب عن سؤال «كم فاتورة أصدر هذا الجهاز؟». تجزئة الفاتورة السابقة PIH بصمة رقمية تجيب عن سؤال «هل الفاتورة السابقة سليمة لم يُعبث بها؟». الأول يقيس الترتيب، والثاني يقيس السلامة.

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

الحقول الثلاثة في نظرة واحدة

إضافة إلى العدّاد والتجزئة، يظهر المعرّف الفريد UUID. الجدول التالي يفرّق بين الثلاثة:

للتعمق في عدّاد الفاتورة راجع دليل عدّاد الفاتورة ICV، وللتعمق في المعرّف الفريد راجع دليل المعرّف الفريد UUID. الحقول الثلاثة جزء من بنية الفاتورة الإلكترونية الكاملة.

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

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

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

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

بهذا الفصل يبقى دليلنا مركّزًا: نتعامل مع الحقل وموقعه ودوره في السلسلة، ونحيل تفاصيل المفهوم والخوارزمية إلى موضعهما المناسب.

اعتبارات عملية للمطوّرين عند تنفيذ حقل PIH

عند بناء التكامل مع الفوترة الإلكترونية، تتكرر مجموعة اعتبارات عملية حول تجزئة الفاتورة السابقة:

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

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

قائمة تحقّق سريعة قبل الإرسال

قبل إرسال الفاتورة إلى منصة فاتورة، راجع النقاط التالية المتعلقة بحقل PIH:

• هل قيمة PIH هي بصمة الفاتورة السابقة مباشرة على الجهاز نفسه؟
• هل الفاتورة الأولى فقط تحمل قيمة الحالة الأساسية؟
• هل البصمة مُرمّزة بصيغة Base64 صحيحة دون مسافات أو فواصل أسطر زائدة؟
• هل كتلة PIH داخل AdditionalDocumentReference بالمعرّف الصحيح PIH؟
• هل عدّاد الفاتورة ICV متسق مع موقع الفاتورة في السلسلة؟

تخزين البصمة والأثر الرقابي طويل المدى

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

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

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

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

سيناريو سلسلة كاملة على جهاز واحد

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

الفاتورة الأولى تصدر بعدّاد ICV قيمته 1. لا توجد قبلها فاتورة، فيكتب النظام في حقل PIH قيمة الحالة الأساسية الثابتة. تُحسب بصمة هذه الفاتورة الأولى ويُحتفظ بها.

الفاتورة الثانية تصدر بعدّاد قيمته 2. يكتب النظام في حقل PIH بصمة الفاتورة الأولى التي حُفظت للتو. تُحسب بصمة الفاتورة الثانية ويُحتفظ بها بدورها.

الفاتورة الثالثة تصدر بعدّاد قيمته 3. يكتب النظام في حقل PIH بصمة الفاتورة الثانية. وهكذا تمضي السلسلة، كل فاتورة ترفع العدّاد واحدًا وتحمل بصمة سابقتها.

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

سلاسل متعددة في منشأة بأكثر من جهاز

كثير من المنشآت تشغّل أكثر من جهاز إصدار. متجر له ثلاثة أجهزة كاشير مثال شائع. كل جهاز من هذه الأجهزة يبني سلسلة تجزئة مستقلة تمامًا.

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

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

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

كيف يتحقق نظام الهيئة من قيمة PIH؟

عند استلام الفاتورة، لا يكتفي نظام التحقق بقراءة حقل PIH كما هو. بل يعيد حساب بصمة الفاتورة السابقة ويقارنها بالقيمة المكتوبة. لو تطابقتا، تمرّ الفاتورة من هذه الناحية. لو اختلفتا، تُرفض.

هذا يعني أن قيمة PIH ليست مجرد نص يُنسخ، بل التزام رياضي. النظام المُصدِر يقول «هذه بصمة فاتورتي السابقة»، ونظام التحقق يتأكد بنفسه. لا مجال للثقة العمياء، التحقق حسابي بحت.

من الأخطاء التي تُرفض عندها الفاتورة: قيمة PIH لا تطابق بصمة الفاتورة السابقة الفعلية، أو استخدام قيمة الحالة الأساسية في غير الفاتورة الأولى، أو ترميز Base64 معطوب. كل خطأ من هذه يوقف الفاتورة عند بوابة التحقق قبل أن تُعتمد أو يُبلَّغ عنها.

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

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

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

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

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

أسئلة شائعة

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

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

ماذا يُكتب في حقل PIH للفاتورة الأولى؟

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

ماذا يحدث لو تعدّلت فاتورة قديمة في السلسلة؟

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

هل ترتبط تجزئة الفاتورة السابقة بعدّاد الفاتورة؟

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

أين تُكتب قيمة PIH داخل XML؟

داخل كتلة AdditionalDocumentReference بالمعرّف PIH، تحديدًا في عنصر EmbeddedDocumentBinaryObject بسمة mimeCode بقيمة text/plain، والقيمة مُرمّزة بصيغة Base64.

هل يحسب قيود قيمة PIH تلقائيًا؟

نعم، يتولّى قيود حساب بصمة كل فاتورة وكتابتها في حقل PIH للفاتورة التالية، ويدير الحالة الأساسية للفاتورة الأولى، دون أي تدخل يدوي من المستخدم.

هل تتغيّر قيمة الحالة الأساسية بين منشأة وأخرى؟

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