إتقان المرحلة الثانية من زاتكا: معالجة سلاسل الهاش المكسورة في الفواتير الإلكترونية

قد يبدو نظام الفوترة طبيعيًا تمامًا من شاشة المحاسبة — إلى أن يتسبب هاش فاتورة واحد مكسور في تعطيل تدفق الإبلاغ المباشر بالكامل.

بالنسبة لمسؤولي قواعد بيانات أنظمة ERP، ومهندسي الأنظمة، ومراقبي الضرائب في الشركات، فإن الامتثال للمرحلة الثانية من زاتكا في السعودية ZATCA Phase 2 compliance KSA لم يعد متعلقًا فقط بإنشاء فاتورة بصيغة XML. بل أصبح متعلقًا بحماية تسلسل تشفيري تكون فيه كل فاتورة، وإشعار دائن، وإشعار مدين مرتبطًا بالمستند الذي يسبقه.

ولهذا السبب، يمكن أن تتحول الأخطاء المرتبطة بـ الهاش السابق للفاتورة Previous Invoice Hash (PIH)، أو قيمة عداد الفاتورة Invoice Counter Value (ICV)، أو UUID، أو تسلسل الفواتير المكسور إلى عوائق تشغيلية خطيرة. فعندما تكتشف آلية التحقق لدى زاتكا وجود هاش سابق مفقود، أو عداد مكرر، أو تسلسل خارج الترتيب، أو بصمة XML غير متسقة، فقد تتعامل مع المشكلة باعتبارها احتمالًا لوجود خلل في مسار التدقيق الإلكتروني.

وهنا تواجه كثير من الشركات أخطاء تسلسل شبيهة بخطأ KSA-3: قد تكون الفاتورة موجودة داخل نظام ERP، لكن تدفق التكامل مع منصة فاتورة يرفضها لأن النظام لا يستطيع إثبات استمرارية السلسلة.

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

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

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

لماذا تتعامل زاتكا مع الفواتير الإلكترونية كأنها دفتر تشفيري؟

تعتمد البنية خلف تكامل المرحلة الثانية على الثقة، والتسلسل، وإمكانية التتبع.

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

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

من منظور النظام، تصبح كل فاتورة جزءًا من سلسلة:

الفاتورة 1 تنشئ هاش.

الفاتورة 2 تتضمن هاش الفاتورة 1.

الفاتورة 3 تتضمن هاش الفاتورة 2.

الفاتورة 4 تتضمن هاش الفاتورة 3.

هذا ينشئ بصمة إلكترونية مستمرة.

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

ولهذا السبب، تعد آلية تتبع قواعد البيانات المقاومة للتلاعب ضرورية من أجل الامتثال للمرحلة الثانية من زاتكا في السعودية ZATCA Phase 2 compliance KSA. يجب على نظام ERP حماية التسلسل التقني، وليس فقط رقم الفاتورة الظاهر.

بنية سلسلة فاتورة FATOORA

تعتمد سلسلة فاتورة على احتفاظ نظام ERP أو وحدة إنشاء الفواتير الإلكترونية EGS بحالة تقنية سليمة قبل إرسال بيانات الفاتورة عبر طبقة التكامل.

يبدو التدفق المبسط المتوافق كما يلي:

إنشاء بيانات الفاتورة

        ↓

تعيين UUID

        ↓

تعيين قيمة عداد الفاتورة ICV

        ↓

حساب هاش الفاتورة

        ↓

تخزين الهاش الحالي

        ↓

إدراج الهاش السابق للفاتورة داخل الفاتورة التالية

        ↓

الإرسال أو الإبلاغ عبر تكامل فاتورة

توضح الإرشادات التقنية التفصيلية للفوترة الإلكترونية الصادرة عن زاتكا البنية التقنية وراء إنشاء الفاتورة الإلكترونية وتوقيعها وإرسالها، بما في ذلك كيفية دعم هاش الفاتورة وقيم الهاش السابق للفاتورة لسلسلة المستندات المتوافقة.

بالنسبة لفرق قواعد البيانات، يعني ذلك أن قيم الهاش، وUUID، والعدادات، وحالات الإرسال يجب التعامل معها كسجلات امتثال حرجة.

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

تفكيك ثلاثية الإبطال: UUID وICV وPIH

ترتبط معظم حوادث سلاسل الهاش المكسورة بثلاثة حقول تعمل معًا: UUID وICV وPIH.

هي حقول مختلفة، لكنها تدعم الهدف نفسه: إثبات هوية المستند واستمرارية التسلسل.

UUID: هوية المستند الفريدة

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

قد تحدث مشكلات UUID عندما:

• يعيد نظام ERP إنشاء الفاتورة بشكل غير صحيح؛

• يتم إرسال مستند XML مخزن مؤقتًا مرة أخرى؛

• يتم نسخ بيانات بيئة الاختبار إلى بيئة الإنتاج؛

• تعيد عملية استعادة النسخ الاحتياطية قيم UUID قديمة؛

• تتم إعادة محاولة إرسال مستند الفاتورة نفسه مع تغيير في القيم الداخلية.

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

ICV: قيمة عداد الفاتورة غير القابلة لإعادة الضبط

تمثل قيمة عداد الفاتورة Invoice Counter Value (ICV) عنصر تحكم في التسلسل. تشترط لائحة تنفيذ الفوترة الإلكترونية الصادرة عن زاتكا أن يقوم حل الفوترة الإلكترونية المتوافق بزيادة وتسجيل قيمة عداد الفاتورة لكل فاتورة إلكترونية أو إشعار إلكتروني يتم إنشاؤه.

وهنا تقع كثير من فرق ERP وSQL في أخطاء.

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

تشمل نقاط فشل ICV الشائعة:

في بيئات المؤسسات، يجب حماية ICV باستخدام ضوابط على مستوى قاعدة البيانات، وأقفال المعاملات، وإدارة واضحة للحالات.

PIH: الهاش السابق للفاتورة

يمثل الهاش السابق للفاتورة Previous Invoice Hash (PIH) القيمة التي تربط الفاتورة الحالية بالفاتورة السابقة.

وهو يخبر النظام:

“هذه الفاتورة تأتي بعد آخر فاتورة صالحة في السلسلة.”

إذا كان PIH مفقودًا، أو قديمًا، أو مكررًا، أو محسوبًا من مستند سابق خاطئ، فإن السلسلة تنكسر.

قد يحدث PIH مفقود أو غير صحيح عندما:

• لا يتم تخزين هاش الفاتورة السابقة بشكل صحيح؛

• يتم تعديل XML بعد حساب الهاش؛

• يتم تجاوز فاتورة فاشلة دون معالجة صحيحة؛

• تتم إعادة محاولة إرسال XML مخزن مؤقتًا بقيم قديمة؛

• يصدر فرع فواتير دون اتصال ثم يقوم بالمزامنة متأخرًا؛

• تدخل بيانات الاختبار إلى تسلسل الإنتاج.

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

تشريح انفصال قاعدة البيانات عن السلسلة

يحدث انفصال قاعدة البيانات عندما لا يعود تسلسل الفواتير الداخلي في ERP مطابقًا لسلسلة فاتورة المتوقعة.

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

1. إعادة تشغيل الخوادم وإعادة ضبط العدادات

إذا تم تخزين ICV في الذاكرة أو تمت استعادته بطريقة ضعيفة من ذاكرة التطبيق المؤقتة، يمكن أن تؤدي إعادة تشغيل الخادم إلى تلف التسلسل.

مثال:

آخر ICV صالح قبل إعادة التشغيل: 8840

يتم إعادة تشغيل التطبيق

يعيد العداد التحميل بشكل خاطئ كالتالي: 8800

يتم إنشاء الفاتورة التالية بقيمة تسلسل قديمة أو مكررة

قد يؤدي ذلك إلى الرفض لأن الفاتورة لا تتبع آخر حالة تقنية صالحة.

الحل ليس ببساطة “تغيير العداد”. يجب على الفريق تحديد آخر فاتورة مقبولة، وآخر ICV صالح، وآخر هاش مخزن، وPIH الصحيح قبل إنشاء المستند الصالح التالي.

2. تلوث بيانات الاختبار

يجب ألا تدخل بيانات الاختبار أبدًا إلى سلسلة فواتير الإنتاج.

تحدث هذه المشكلة غالبًا عندما يقوم المطورون بـ:

• الاختبار باستخدام بيانات اعتماد الإنتاج؛

• استعادة قواعد بيانات الإنتاج في بيئة الاختبار؛

• دفع سجلات الاختبار مرة أخرى إلى الإنتاج؛

• نسخ أرشيفات XML بين البيئات؛

• إعادة استخدام UUID أو قيم هاش من بيئة الاختبار.

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

3. تأخر مزامنة البيئات متعددة المستأجرين

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

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

مثال:

الفرع A ينشئ ICV 1501

الفرع B ينشئ أيضًا ICV 1501 قبل المزامنة

يتلقى ERP المركزي كلا السجلين

يصبح أحد التسلسلين غير صالح

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

4. العناصر المحظورة المخزنة مؤقتًا

قد تبقى الفاتورة الفاشلة داخل قائمة إعادة المحاولة، أو الذاكرة المؤقتة المحلية، أو مخزن التكامل.

إذا لم يستطع النظام التفريق بوضوح بين الحالات التالية: تم الإنشاء، تم التوقيع، تم الإرسال، تم الإبلاغ، تم التخليص، تم الرفض، تم الحظر، تم الإلغاء، فإن عملية الاسترداد تصبح محفوفة بالمخاطر.

قد تؤدي إعادة محاولة قديمة إلى إعادة إرسال مستند XML قديم مع PIH خاطئ. وقد يؤدي مسح جماعي لقائمة الانتظار إلى حذف أدلة مطلوبة للمراجعة. كما قد يؤدي الإرسال المكرر إلى ارتباك في التقارير الضريبية.

دليل استعادة النظام

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

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

استخدم عملية استعادة منظمة.

الخطوة 1: تجميد نطاق التسلسل المتأثر

أوقف مؤقتًا إنشاء الفواتير الجديدة فقط لوحدة EGS أو الفرع أو الجهاز أو المستأجر المتأثر.

لا توقف كامل الأعمال إلا إذا كانت المشكلة على مستوى النظام كله.

الهدف هو منع إنشاء المزيد من الفواتير فوق سلسلة مكسورة.

الخطوة 2: تحديد آخر حالة مقبولة وصالحة

ابحث عن آخر فاتورة أو إشعار تم تخليصه أو الإبلاغ عنه بنجاح.

راجع:

تصبح هذه هي نقطة الارتكاز للاستعادة.

الخطوة 3: تحديد أول سجل مكسور

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

تحقق من:

• ICV مكرر؛

• PIH مفقود؛

• PIH قديم؛

• مرجع خاطئ للفاتورة السابقة؛

• UUID معاد إنشاؤه؛

• XML تم تغييره بعد حساب الهاش؛

• إعادة محاولة فاشلة؛

• مزامنة فرع خارج الترتيب؛

• إرسال XML مخزن مؤقتًا.

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

الخطوة 4: الفصل بين التصحيح التجاري وإعادة المحاولة التقنية

إعادة المحاولة التقنية ليست مثل التصحيح التجاري.

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

الخطوة 5: مسح قوائم الانتظار المحظورة بأمان

قبل مسح أي عنصر في قائمة الانتظار، قم بتصنيفه.

احفظ السجلات قبل إزالة أو تصحيح أي عنصر محظور.

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

الخطوة 6: التحقق قبل الإرسال المباشر

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

يجب أن يؤكد تسلسل الفاتورة المعاد بناؤه:

• ICV التالي الصحيح؛

• UUID جديد وصالح عند الحاجة؛

• PIH الصحيح من آخر هاش فاتورة صالح؛

• عدم تغيير XML بعد الهاش/التوقيع؛

• سياق شهادة EGS الصحيح؛

• نطاق الفرع/الجهاز الصحيح؛

• حفظ سجلات التدقيق.

الخطوة 7: توثيق الحادثة

سلسلة الهاش المكسورة ليست خطأ تقنيًا فقط. إنها حادثة امتثال.

وثّق:

• السبب الجذري؛

• نطاق الفواتير المتأثرة؛

• وحدة EGS أو الفرع المتأثر؛

• آخر فاتورة صالحة؛

• أول فاتورة مكسورة؛

• الإجراء التصحيحي؛

• مالك الموافقة؛

• ضابط الوقاية؛

• دليل الاختبار؛

• وقت الاسترداد.

يساعد ذلك الشركة على إثبات السيطرة أثناء أي تدقيق أو مراجعة داخلية مستقبلية.

ضوابط قاعدة البيانات التي تمنع فشل سلاسل الهاش

الوقاية أفضل من الاسترداد الطارئ.

يجب على كل بيئة ERP مؤسسية الحفاظ على ضوابط تقنية حول UUID وICV وPIH وأرشيفات XML وحالات الإبلاغ.

تتعامل أقوى المؤسسات مع تسلسل الفواتير كخدمة امتثال حرجة، وليس كمهمة ERP خلفية فقط.

لماذا تتطلب جاهزية المرحلة الثانية والثالثة تدريبًا؟

تتعلم كثير من المؤسسات عن سلاسل هاش الفواتير فقط عندما تكون الفوترة قد تعطلت بالفعل.

وهذا متأخر جدًا.

قد يفهم مراقب الضرائب تقارير ضريبة القيمة المضافة، لكنه لا يفهم قفل تسلسل SQL. وقد يفهم مسؤول قاعدة البيانات عزل المعاملات، لكنه لا يفهم معنى PIH من ناحية الامتثال. وقد يفهم المطور إنشاء XML، لكنه لا يدرك أثر إعادة المحاولة من الذاكرة المؤقتة على التدقيق.

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

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

هذا النضج هو ما يحافظ على استقرار مسارات فوترة المؤسسات.

قائمة تحقق تشخيصية عملية

استخدم هذه القائمة قبل تصعيد حادثة سلسلة هاش مكسورة:

يجب مشاركة هذه القائمة بين فرق ERP، والضرائب، وقواعد البيانات، والامتثال.

الخلاصة

وفق بروتوكولات تكامل المرحلة الثانية، لا يعد تسلسل قاعدة البيانات المكسور مشكلة خلفية بسيطة. بل يمكن أن يتحول إلى عائق فوري أمام الفوترة.

من أجل الامتثال للمرحلة الثانية من زاتكا في السعودية ZATCA Phase 2 compliance KSA، يجب أن تكون كل فاتورة جزءًا من بصمة إلكترونية موثوقة مدعومة بـ UUID، وقيمة عداد الفاتورة، والهاش السابق للفاتورة، وXML الموقّع، وحالة الإبلاغ أو التخليص المضبوطة.

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

الشركات التي تتعامل مع تكامل فاتورة باعتباره دفترًا تشفيريًا ستكون أكثر مرونة من الشركات التي تتعامل معه كمتطلب رفع ملفات فقط.

يساعد التدريب المتعمق من خلال  الامتثال للفوترة الإلكترونية (فاتورة) ZATCA  الفرق التقنية والمالية على حماية استمرارية الفوترة، وتقليل مخاطر الرفض، والحفاظ على الثقة اللازمة لإبقاء فوترة المؤسسات دون انقطاع.