يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-61.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-61]-Previous invoice hash (KSA-13) must exist in an invoice.
فحوص أخرى تُذكر في التقرير نفسه
BR-KSA-26
[BR-KSA-26]-If the invoice contains the previous invoice hash (KSA-13), this hash must be base64 encoded SHA256. The hash shall be computed using the following method as described in the ds:transforms block in the XML Invoice Specifications: 1. Remove the <Invoice><ext:UBLExtensions/> block 2. Remove the <Invoice><cac:AdditionalDocumentReference/> block where <cbc:ID/> = QR 3. Remove the <Invoice><cac:Signature/> block 4. Canonicalize the Invoice using the C14N11 standard 5. Hash the resulting string using SHA256 to a binary object 6. Base64 encode the binary object to generate the digest value For the first invoice, the previous invoice hash is "NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzljMmRiYzIzOWRkNGU5MWI0NjcyOWQ3M2EyN2ZiNTdlOQ==", the equivalent for base64 encoded SHA256 of "0" (zero) character.
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
الفاتورة لا تحمل بصمة الفاتورة السابقة
صورة القيمة في التقريرreference_missingالمرجع غير موجود
ما الخلل
لا يحمل المستند أي عنصر cac:AdditionalDocumentReference قيمة cbc:ID فيه هي PIH، فهو لا يذكر بصمة الفاتورة السابقة KSA-13. وترصد هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-61 التي تنص رسالتها على وجوب وجود بصمة الفاتورة السابقة KSA-13 في الفاتورة؛ وتصنّف الهيئة هذه القاعدة تحذيراً لا خطأً في أداة الفحص الحالية لديها، فالتحذير وحده لا يؤدي إلى رفض المستند. والبصمة هي ما يربط هذا المستند بالمستند الصادر قبله على الجهاز أو النظام نفسه: فكل فاتورة تحمل بصمة سابقتها، فتتشكّل من المستندات سلسلة يُكشف بها ما فُقد منها أو غُيِّر. وبغير هذا المرجع لا رابط. وتُقارن قيمة المعرِّف بعد تسوية المسافات وحرفياً فيما عدا ذلك، فالمرجع المعنون pih بحروف صغيرة ليس المرجع الذي تبحث عنه القاعدة ويُقرأ غائباً. وتسري القاعدة على كل فاتورة، ضريبية كانت أو مبسطة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
تُكتب البصمة في كتلة مرجع مستند خاصة بها: عنصر cac:AdditionalDocumentReference قيمة cbc:ID فيه هي النص PIH حرفياً، ويحمل بداخله العنصر cac:Attachment/cbc:EmbeddedDocumentBinaryObject الذي تُكتب فيه القيمة بترميز base64. والأسباب المعتادة: وحدة فوترة إلكترونية مضبوطة على المرحلة الأولى، فلا سلسلة لديها تحفظها ولا تكتب الكتلة أصلاً؛ وقالب تصدير يكتب كتلة ICV وكتلة رمز الاستجابة السريعة ولم تُضف إليه كتلة البصمة؛ وسلسلة تُحفظ داخلياً ولا تُصدَّر. وانتبه إلى أن أول فاتورة في السلسلة ليست استثناءً: فهي تحمل الكتلة كذلك، بالقيمة التي ينشرها معيار تطبيق XML لهذه الحال، فخلوّ السلسلة ليس سبباً لإسقاط المرجع.
كتلة بصمة الفاتورة السابقة لا تحمل عنصر القيمة
صورة القيمة في التقريرpayload_element_missingعنصر الحمولة غير موجود
ما الخلل
يحمل المستند عنصر cac:AdditionalDocumentReference قيمة cbc:ID فيه هي PIH، لكن ليس بداخله عنصر cac:Attachment/cbc:EmbeddedDocumentBinaryObject؛ فكتلة المرجع موجودة والعنصر الذي يحمل البصمة غير موجود. وترصد هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-61، وتصنّف هذه القاعدة تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. وكل شق من هذا الفحص يُقاس على مرجع PIH نفسه، فالكلام هنا عن بصمة فاتورتك السابقة لا عن مرفق آخر في المستند. وستظهر لك على الأرجح ملاحظة ثانية على العنصر نفسه بموجب القاعدة BR-KSA-26، وهذا متوقَّع وشرحه هناك.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
راجع بنية الكتلة التي يكتبها التصدير: مستويان داخل المرجع، عنصر cac:Attachment ثم عنصر cbc:EmbeddedDocumentBinaryObject بداخله، وتكون القيمة بترميز base64 هي المحتوى النصي للعنصر الثاني. والأسباب المعتادة: قالب يكتب المرجع ومعرِّفه من حلقة ويكتب المرفق من حلقة أخرى لم تُنفَّذ، وبصمة تُكتب في نص المرجع نفسه أو في عنصر وصف بدل المرفق، ومستوى تداخل سقط فصار العنصر الثنائي واقعاً مباشرة تحت المرجع. أما عنصر القيمة الموجود الفارغ فخلل آخر يُذكر في ملاحظة مستقلة.
بصمة الفاتورة السابقة فارغة
صورة القيمة في التقريرpayload_emptyالحمولة فارغة
ما الخلل
تحمل كتلة PIH عنصرها cac:Attachment/cbc:EmbeddedDocumentBinaryObject، لكن العنصر لا قيمة فيه، فالمستند لا يذكر بصمة فاتورة سابقة. وترصد هيئة الزكاة والضريبة والجمارك ذلك بموجب القاعدة BR-KSA-61 التي تشترط وجود العنصر وألّا يكون فارغاً، وتصنّف هذه القاعدة تحذيراً لا خطأً، فالتحذير وحده لا يؤدي إلى رفض المستند. والعنصر الفارغ يُعامل هنا معاملة العنصر الغائب تماماً. وستظهر لك على الأرجح ملاحظة ثانية على العنصر نفسه بموجب القاعدة BR-KSA-26، وهذا متوقَّع وشرحه هناك.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
العنصر يُكتب والقيمة خلفه لا تُكتب، فالربط يُنتج كتلة البصمة دون شرط بينما الخطوة التي تحسب البصمة أو تجلبها لا تعمل أو لا تُرجع شيئاً. تحقّق من أن بصمة المستند السابق متاحة لحظة بناء ملف XML، ومن أنها محفوظة بين المستندات لا محسوبة من سجل تجاوزه النظام. وأول فاتورة في السلسلة ليست فارغة القيمة كذلك: فمعيار تطبيق XML ينشر القيمة التي تُستعمل في تلك الحال، والعنصر الفارغ ليس هو.
بصمة الفاتورة السابقة غير معلَنة بنوع المحتوى text/plain
صورة القيمة في التقريرnot_text_plainغير معلَن بنوع المحتوى text/plain
ما الخلل
عنصر بصمة الفاتورة السابقة لا يحمل السمة mimeCode بالقيمة text/plain. وتشترط هيئة الزكاة والضريبة والجمارك هذا الإعلان وترصد غيابه بموجب القاعدة BR-KSA-61، وتصنّف الهيئة هذه القاعدة تحذيراً لا خطأً في أداة الفحص الحالية لديها، فالتحذير وحده لا يؤدي إلى رفض المستند. وتُقارن قيمة السمة بعد تسوية المسافات وحرفياً فيما عدا ذلك: فالمطلوب text/plain، والقيمتان application/octet-stream وbase64Binary والسمة الفارغة وغياب السمة أصلاً كلها تخفق. وكل شق من هذا الفحص يُقاس على مرجع PIH نفسه. وستظهر لك على الأرجح ملاحظة ثانية على العنصر نفسه بموجب القاعدة BR-KSA-26، وهذا متوقَّع وشرحه هناك.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
موضع السمة هو العنصر الذي يحمل القيمة نفسه لا العنصر cac:Attachment الذي فوقه: السمة mimeCode بالقيمة text/plain على العنصر cbc:EmbeddedDocumentBinaryObject. ولا تستنتج القيمة من محتوى الحقل: فالمحتوى نص بترميز base64، ولذلك تبدو القيمة application/octet-stream أدقّ الاثنتين وتُرصد عليها الملاحظة؛ فالمطلوب هو text/plain لا ما يصفه المحتوى. والأسباب المعتادة: أداة تسلسل تكتب المرفق عبر دالة عامة للمرفقات الثنائية تحمل نوعها الافتراضي، وسمة تُقرأ من جدول إدارة المستندات، وقالب يغفلها. ومرفق رمز الاستجابة السريعة في المستند نفسه يحتاج إلى الإعلان نفسه، فالنظام الذي يصيب في أحدهما ويخطئ في الآخر يكتب الكتلتين من موضعين مختلفين في العادة.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not((cac:AdditionalDocumentReference[normalize-space(cbc:ID) = 'PIH'] and exists(cac:AdditionalDocumentReference[normalize-space(cbc:ID) = 'PIH']/cac:Attachment/cbc:EmbeddedDocumentBinaryObject) and (cac:AdditionalDocumentReference[normalize-space(cbc:ID) = 'PIH']/cac:Attachment/cbc:EmbeddedDocumentBinaryObject) != '' and (cac:AdditionalDocumentReference[normalize-space(cbc:ID) = 'PIH']/cac:Attachment/cbc:EmbeddedDocumentBinaryObject[normalize-space(@mimeCode) = 'text/plain'])))
التعبير المذكور في التقرير
(cac:AdditionalDocumentReference[normalize-space(cbc:ID) = 'PIH'] and exists(cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject) and (cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject) != '' and (cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject[normalize-space(@mimeCode) = 'text/plain']))
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.