رمز الخطأ 1003: تجزئة الفاتورة غير متطابقة

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

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

ماذا يعني رمز الخطأ 1003 بالضبط

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

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

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

لماذا تطلب الهيئة تجزئة لكل فاتورة

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

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

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

علاقة الخطأ 1003 بسلسلة تجزئة الفواتير

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

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

لماذا تخرج التجزئة غير متطابقة

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

السبب الأول: حساب التجزئة على نسخة XML مختلفة

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

السبب الثاني: خلط الترميز بين Hex و Base64

تتطلب مواصفة الفوترة أن تُمثَّل قيمة التجزئة بترميز محدّد عند إدراجها في الفاتورة. الخطأ الشائع أن يولّد نظامك التجزئة بصيغة سداسية عشرية (Hex) بينما المنصة تتوقعها بترميز Base64، أو العكس. القيمة الرقمية واحدة، لكن تمثيلها النصي مختلف، فتفشل المقارنة لأن النصين غير متطابقين حرفيًا. هذا سبب خفيّ لأن البصمة تبدو «صحيحة» بصريًا، لكنها مكتوبة بلغة لا تقرؤها المنصة.

السبب الثالث: غياب التقنين (Canonicalization)

قبل حساب التجزئة، يجب تحويل الـ XML إلى صورة قياسية موحّدة عبر عملية التقنين (Canonicalization). هذه العملية توحّد المسافات، وترتيب السمات، وإعلانات النطاقات (Namespaces)، حتى يخرج كل نظام بالبايتات نفسها لنفس المحتوى المنطقي. إذا حسبت التجزئة على XML غير مقنّن، أو طبّقت قاعدة تقنين تختلف عن المعتمدة، خرجت بصمتك مغايرة لبصمة المنصة وإن كان المحتوى المنطقي واحدًا. هذا السبب يربك المطورين كثيرًا لأن الفاتورة تبدو سليمة بالعين، والفرق كله في بايتات لا تراها.

الأسباب الثلاثة لعدم تطابق التجزئة

كيف تقرأ رسالة الرفض

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

{
  "validationResults": {
    "infoMessages": [
      {
        "type": "INFO",
        "code": "XSD_ZATCA_VALID",
        "category": "XSD validation",
        "message": "Complied with UBL 2.1 standards"
      }
    ],
    "warningMessages": [],
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1003",
        "category": "Invoice hash validation",
        "message": "Invoice hash does not match the recomputed SHA-256 hash of the submitted document."
      }
    ],
    "status": "ERROR"
  },
  "clearanceStatus": "NOT_CLEARED",
  "clearedInvoice": null
}

المفاتيح التي تهمّك في القراءة:

• clearanceStatus بقيمة NOT_CLEARED يعني أن المقاصة لم تتم، فالفاتورة لم تُعتمد ولا يجوز تسليمها للمشتري.
• code بقيمة 1003 هو التعريف الدقيق للسبب، والفئة Invoice hash validation تؤكد أن المشكلة في التجزئة لا في حقل بيانات.
• الرسالة النصية تشير صراحة إلى أن التجزئة المدرجة لا تطابق ناتج إعادة حساب SHA-256 على المستند المرسَل، وهذا توجيه مباشر لموضع الخلل.
• clearedInvoice بقيمة null يؤكد أنه لا توجد فاتورة معتمدة مقابلة، فلا تبنِ أي خطوة لاحقة على وجودها.

كيف تقارن البصمتين عمليًا

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

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

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

حالات حافّة تنتج الخطأ 1003

إلى جانب الأسباب الثلاثة الكبرى، هناك حالات حافّة أدقّ تستحق الانتباه لأنها تظهر فجأة بعد فترة استقرار:

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

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

أين توضع التجزئة داخل الفاتورة

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

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

المسار الصحيح لحساب التجزئة

كيف تكتشف موضع الخلل بدقة

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

• التقط البايتات المرسَلة فعليًا. سجّل نسخة طبق الأصل من جسم الطلب الذي يغادر نظامك إلى المنصة، لا النسخة التي بنيتها في الذاكرة. كثير من حالات 1003 تنكشف هنا فورًا حين تجد فرقًا بين النسختين.
• أعد حساب SHA-256 يدويًا. طبّق التجزئة على الـ XML المقنّن نفسه، وقارن الناتج بالقيمة المدرجة في الفاتورة. إن اختلفا، فالمشكلة في الحساب أو التقنين، لا في النقل.
• افحص الترميز. تحقق أن قيمة التجزئة مكتوبة بالترميز المعتمد، لا بصيغة سداسية عشرية حيث يُتوقع Base64 أو العكس. هذا الفحص يحسم السبب الثاني في ثوانٍ.
• راجع التقنين. تأكد أنك تطبّق قاعدة التقنين المطلوبة قبل الحساب، وأن إعلانات النطاقات وترتيب السمات والمسافات موحّدة. اختلاف خوارزمية التقنين سبب صامت لكنه متكرر.
• اعزل لحظة الحساب. تأكد أن لا حقل يتغيّر بعد حساب التجزئة وقبل الإرسال، خاصة الطوابع الزمنية والمعرّفات المولّدة لحظيًا.

بهذا التسلسل تنتقل من «الفاتورة مرفوضة» إلى «أعرف بالضبط أي طبقة كسرت التطابق»، وهذا هو نصف الحل.

كيف تصحّح الفاتورة وتعيد إرسالها

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

• ثبّت لحظة الحساب على البايتات النهائية. ابنِ الـ XML كاملًا، طبّق التقنين، احسب SHA-256 على الناتج، وأدرج القيمة، ثم لا تمسّ المستند بعدها إطلاقًا قبل الإرسال.
• وحّد الترميز. أصلح طبقة الترميز لتكتب قيمة التجزئة بالصيغة المعتمدة في المواصفة، واضبط كل أدوات الاختبار على القراءة بالصيغة نفسها.
• طبّق التقنين الصحيح. اعتمد خوارزمية التقنين المطلوبة قبل الحساب، وثبّتها في خط الإنتاج حتى لا تتغيّر بين بيئة وأخرى.
• أعد التوليد والتوقيع. بعد تصحيح المحتوى، أعد توليد الفاتورة، احسب التجزئة من جديد، ثم وقّع بشهادة CSID قبل إرسالها إلى المقاصة. لا تعيد استخدام بصمة أو توقيع قديمين.
• أرسل وتحقق. أرسل النسخة المصحّحة، وتأكد أن clearanceStatus عاد بقيمة معتمدة وأن قائمة الأخطاء فارغة.

القاعدة المختصرة: احسب على ما سترسل، ووقّع على ما حسبت، وأرسل ما وقّعت دون لمسه. هذا التسلسل وحده يغلق باب الخطأ 1003.

كيف تمنع تكرار الخطأ 1003

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

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

قائمة الفحص قبل الإرسال

أخطاء شائعة عند معالجة الخطأ 1003

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

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

القاعدة الجامعة أن تعامل الخطأ 1003 كمشكلة في خط الإنتاج كله، لا كعيب في فاتورة مفردة. فمتى ضبطت الخط مرة واحدة، اختفى الخطأ عن كل الفواتير لا عن واحدة فقط.

كيف يساعدك قيود في تجنّب خطأ 1003

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

• يولّد قيود ملف الفاتورة وفق مواصفة UBL 2.1 تلقائيًا، فلا تكتب الـ XML يدويًا ولا تتدخّل في بنيته بين الحساب والإرسال.
• يحسب قيود تجزئة الفاتورة بخوارزمية SHA-256 على النسخة النهائية ذاتها التي ترسلها، ضمن خط واحد لا يفصل بين الحساب والتوقيع والإرسال.
• يطبّق قيود التقنين والترميز المعتمدين داخليًا، فلا يقع خلط بين Hex وBase64 ولا تختلف قاعدة التقنين بين بيئة وأخرى.
• يدير قيود شهادة CSID تلقائيًا ويخزّن سلسلة تجزئة الفواتير للتحقق من سلامتها، فتبقى الفواتير مترابطة ومتطابقة مع ما تقرؤه المنصة.
• يتولّى قيود المقاصة الفورية لفواتير المنشآت والإبلاغ خلال 24 ساعة لفواتير الأفراد، فتمرّ فواتيرك من بوابة سلامة المحتوى دون رفض.

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

ما الفرق بين خطأ التجزئة 1003 وأخطاء التوقيع؟
خطأ 1003 يقول إن قيمة التجزئة المدرجة لا تطابق ناتج إعادة حساب SHA-256 على المستند المرسَل، أي مشكلة في «ماذا حسبت». أما أخطاء التوقيع فتقول إن الختم التشفيري نفسه غير صالح أو لا يطابق الشهادة، أي مشكلة في «بماذا وقّعت». عالج كل واحد في طبقته.

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

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

هل يمكن أن يكون السبب مجرد ترميز Hex بدل Base64؟
نعم، وهو سبب شائع. القيمة الرقمية للتجزئة قد تكون صحيحة، لكن تمثيلها النصي بصيغة غير الصيغة المعتمدة يجعل المقارنة النصية تفشل. وحّد الترميز في دالة واحدة لكل النظام.

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

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