لماذا تُرفض فاتورتك رغم أن التوقيع «صحيح»

المصلحة لا تقبل JSON عاديًا موقّعًا. المستند يُحوَّل أولًا بخوارزمية تسلسل خاصة بالمنظومة، ثم يُحسب على الناتج تجزئة SHA-256، ثم يُبنى توقيع CAdES-BES.

الخلط الشائع

كثير من فرق التطوير تستخدم RFC 8785 المعروف بـ JCS ظنًا أنه المعيار المقصود. الخوارزميتان مختلفتان تمامًا، وناتج JCS تُرفضه البوابة. أسماء الخصائص في خوارزمية المصلحة تُكتب بحروف كبيرة بين علامتي تنصيص، والقيم تُكتب بنصها الخام، والمصفوفات يتكرر فيها اسم الخاصية.

لماذا يصعب اكتشافه

لأن كل شيء آخر يبدو سليمًا: الشهادة صالحة، والتوقيع رياضيًا صحيح، والمستند مكتمل. الخطأ في الصورة التي وُقِّع عليها لا في التوقيع.

كيف نتحقق

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

المعرّف أيضًا

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