MTB-PIH-01بصمة الفاتورة السابقة ليست بترميز base64
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي MTB-PIH-01.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
لا يقابلها فحص منشور لدى الهيئة
ليس في قواعد التحقق المنشورة لدى الهيئة فحص واحد يتناول ما تحمله بصمة الفاتورة السابقة: فالفحصان اللذان يقرآنها يتحققان من وجودها ومن نوع المحتوى الذي تعلنه، لا مما تحمله. ويفحص مطابق صورتها وفق قراءته للقسم 13.3.1 من معيار تطبيق XML الذي تنشره الهيئة: بصمة SHA-256 مرمَّزة بترميز base64. وما يجده فيها يُذكر في التقرير بدرجة الخطورة «تحذير». فأي ملاحظة تحت هذه القاعدة صادرة عن فحص خاص بمطابق، لا عن قاعدة تنفّذها الهيئة.
درجة الخطورة في التقرير
تحذير
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
بصمة الفاتورة السابقة ليست بترميز base64
صورة القيمة في التقريرnot_base64ليس بترميز base64
ما الخلل
بصمة الفاتورة السابقة KSA-13 ليست بترميز base64 صحيح، فلا يمكن أن تكون البصمة المرمَّزة التي عُرِّف الحقل ليحملها؛ فإما أن طولها ليس من مضاعفات الأربعة، وإما أنها تحمل محارف خارج أبجدية base64. وتُرصد هذه الحالة بوصفها مخاطرة لا سبب رفض، والسبب جدير بالمعرفة: فليس في قواعد هيئة الزكاة والضريبة والجمارك المنشورة فحص واحد يفكّ هذه القيمة أو يفحص صورتها. والفحوص المنشورة هي وجود العنصر، وعدم خلوّه، وإعلانه نوع المحتوى text/plain، وألّا يتجاوز طوله 255 محرفاً. فالهيئة تقبل بصمة فاتورة سابقة ليست بصمة. غير أن معيار تطبيق XML ومعيار تطبيق خصائص الأمان كلاهما يعرّف الحقل بأنه بصمة SHA-256 مرمَّزة بترميز base64، فالقيمة التي ليست بترميز base64 خاطئة بحسب تعريف الهيئة نفسها للحقل، وإن كانت الأداة تجيزها.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
الأسباب المعتادة: قيمة تحمل محارف لا يستعملها ترميز base64، وأشيعها الشرطة والشرطة السفلية في صورته الصالحة للروابط؛ ورابط من نوع data: أو مسار ملف مكتوب في موضع القيمة؛ ونص بديل مؤقت؛ وأحرف نهاية سطر أو مسافات داخل القيمة تأتي من أداة كتابة XML مضبوطة على التنسيق المرتَّب فتلفّ القيمة الطويلة على أسطر مزاحة. وانتبه إلى أن البصمة المكتوبة نصاً ست عشرياً خاماً لا تُذكر هنا: فالأربعة والستون محرفاً ست عشرياً تصادف أن تكون ترميز base64 صحيحاً، فتظهر تلك الحال في الملاحظة الأخرى الخاصة ببصمة الفاتورة السابقة. عالج ذلك عند ترميز البصمة في الخطوة التي تكتب السلسلة، لا في الملف المصدَّر.
بصمة الفاتورة السابقة ليست على صورة بصمة SHA-256
صورة القيمة في التقريرnot_a_sha256ليس على صورة بصمة SHA-256
ما الخلل
بصمة الفاتورة السابقة KSA-13 مكتوبة بترميز base64 صحيح، لكنها ليست بصمة SHA-256 في أي من الصورتين اللتين تصفهما وثائق هيئة الزكاة والضريبة والجمارك نفسها؛ وهما صورتان لأن صفحة واحدة من تلك الوثائق تصف الحقل مرتين، ووصفاها متعارضان. فمعيار تطبيق XML يذكر طريقة البناء: تُجزَّأ الفاتورة إلى كائن ثنائي، ثم يُرمَّز الكائن الثنائي بترميز base64. وبصمة SHA-256 اثنان وثلاثون بايتاً، فينتج عن ذلك أربعة وأربعون محرفاً. والجملة التالية لها في الصفحة نفسها تعطي القيمة التي تُستعمل لأول فاتورة في السلسلة، وهي تبدأ بالمحارف NWZlY2ViNjZm وتنتهي بعلامتي مساواة، وتصفها بأنها بصمة SHA-256 للمحرف 0 مرمَّزة بترميز base64. وهي ليست كذلك بحسب طريقة البناء المذكورة قبلها بسطر: فطولها ثمانية وثمانون محرفاً، وتُفكّ إلى النص الست عشري للبصمة بأربعة وستين محرفاً، لا إلى بايتاتها الاثنين والثلاثين. ولأن المعيار ينص على الصورتين في الصفحة نفسها فمطابق يقبلهما كلتيهما: القيمة التي تُفكّ إلى اثنين وثلاثين بايتاً، والقيمة التي تُفكّ إلى بصمة ست عشرية من أربعة وستين محرفاً؛ وهذه الملاحظة تعني أن القيمة ليست واحدة منهما. وتُرصد بوصفها مخاطرة لا سبب رفض، لأن ليس في قواعد الهيئة المنشورة ما يفكّ هذه القيمة: فالفحوص المنشورة هي الوجود وعدم الخلوّ ونوع المحتوى text/plain وحد المحارف البالغ 255، فالهيئة تقبل المستند كما هو. ولا يعيد مطابق حساب البصمة، فهذه الملاحظة تقول إن صورة القيمة خاطئة ولا تقول شيئاً عن كونها البصمة الصحيحة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
راجع خطوة التجزئة في وحدة الفوترة الإلكترونية، وفيها إعدادان. الأول الخوارزمية: فبصمة SHA-1 عشرون بايتاً، وبصمة SHA-512 أربعة وستون بايتاً، وكلتاهما تُرمَّز إلى نص base64 سليم بطول خاطئ، فالوحدة المتروكة على إعداد قديم تقع هنا. والثاني ترميز الإخراج، وهو أشيع الاثنين: فالبصمة المكتوبة نصاً ست عشرياً ثم المرمَّزة بترميز base64 هي الصورة ذات الثمانية والثمانين محرفاً وهي مقبولة، أما البصمة الست عشرية الخام المكتوبة مباشرةً في الحقل فليست واحدة من الصورتين، وتصل إلى هذه الملاحظة لا إلى الملاحظة المعنونة: بصمة الفاتورة السابقة ليست بترميز base64، لأن الأربعة والستين محرفاً ست عشرياً تصادف أن تكون ترميزاً صحيحاً. وراجع كذلك ما الذي يُجزَّأ أصلاً: فترميز base64 لملف XML الكامل للفاتورة السابقة، أو لوصف لها، ترميز سليم بطول خاطئ ويظهر هنا. ولأول فاتورة في السلسلة استعمل القيمة التي ينشرها معيار تطبيق XML، لا قيمة فارغة ولا نصاً بديلاً.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.