BR-KSA-F-01أحد التواريخ في هذه الفاتورة المبسطة ليس مكتوباً بعشرة محارف
يفحص مطابق ملف XML للفاتورة الإلكترونية في المرحلة الثانية قبل إرساله: تحقق مسبق وفق متطلبات هيئة الزكاة والضريبة والجمارك المنشورة، لا اعتماداً من الهيئة. وتشرح هذه الصفحة قاعدة واحدة هي BR-KSA-F-01.
خمس عمليات فحص شهرياً في باقة المجان. يُفحص الملف في الذاكرة ولا يُحفظ.
الرسالة كما تنشرها هيئة الزكاة والضريبة والجمارك
[BR-KSA-F-01]-A date MUST be formatted YYYY-MM-DD, in accordance to the "Calendar date complete representation" as specified by ISO 8601:2004, format YYYY-MM-DD.
ما الذي يذكره مطابق
مدخل لكل حالة تُذكر فيها هذه القاعدة في التقرير.
صورة القيمة في التقرير
صورة القيمة التي وُجدت — empty وnot_15_digits وما شابههما — لا القيمة نفسها.
أحد التواريخ في هذه الفاتورة المبسطة ليس مكتوباً بعشرة محارف
صورة القيمة في التقريرnot_10_charactersليس بطول عشرة محارف
ما الخلل
أحد التواريخ في هذه الفاتورة ليس بطول عشرة محارف بالضبط. وتشترط هيئة الزكاة والضريبة والجمارك أن يُكتب كل تاريخ في الفاتورة المبسطة على الصورة YYYY-MM-DD لا غير، بموجب القاعدة BR-KSA-F-01، وترفض ما زاد عن ذلك أو نقص. وأشيع أسباب الزيادة إلحاق إزاحة منطقة زمنية بالتاريخ؛ فالتاريخ 2026-09-01 إذا أُلحقت به إزاحة صار 2026-09-01+03:00 وطوله ستة عشر محرفاً، وهو تاريخ صحيح تماماً ومع ذلك يُرفض هنا. ويشمل الفحص تاريخ الإصدار وتاريخ الاستحقاق وتاريخ التوريد الفعلي تحت cac:Delivery حيثما وردت في المستند. وتسري هذه القاعدة على الفواتير المبسطة وحدها؛ أما تواريخ الفاتورة الضريبية فلا تُفحص بهذه الطريقة.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
اكتب التواريخ تاريخاً مجرداً: 2026-09-01، بلا وقت ولا إزاحة ولا حرف Z بعده. ويأتي هذا عادةً من ربط يكتب طابعاً زمنياً كاملاً في حقل تاريخ، أو من أداة تسلسل مضبوطة على إخراج معلومات المنطقة الزمنية مع كل تاريخ تكتبه. ووقت الإصدار موضعه العنصر cbc:IssueTime وهو عنصر مستقل؛ ونقل الوقت إليه هو العلاج لا قصّ النص، لأن الإزاحة تحمل معلومة حقيقية في الغالب.
أحد التواريخ في هذه الفاتورة المبسطة ليس تاريخاً تقويمياً حقيقياً
صورة القيمة في التقريرnot_a_dateليس تاريخاً تقويمياً حقيقياً
ما الخلل
أحد التواريخ في هذه الفاتورة بطول عشرة محارف لكنه ليس تاريخاً موجوداً. وتشترط هيئة الزكاة والضريبة والجمارك أن يكون كل تاريخ في الفاتورة المبسطة تاريخاً تقويمياً حقيقياً بموجب القاعدة BR-KSA-F-01، فالقيمتان 2026-02-30 و2026-13-01 مرفوضتان كلتاهما وإن كانت كل منهما عشرة محارف وتبدو تاريخاً. فالطول سليم، وإنما القيمة هي الخاطئة. ويشمل الفحص تاريخ الإصدار وتاريخ الاستحقاق وتاريخ التوريد الفعلي تحت cac:Delivery. وتسري هذه القاعدة على الفواتير المبسطة وحدها.
ما الذي تتحقق منه في وحدة الفوترة الإلكترونية
سببان يفسّران أغلب هذه الحالات. الأول أن اليوم والشهر تبادلا موضعيهما؛ فالقيمة 2026-13-01 هي الأول من يناير كُتب 13-01 ثم أُعيد تركيبه بترتيب مقلوب، فتحقّق مما إذا كان تنسيق التاريخ يُعاد بين نظامك وبين التصدير. والثاني خطوة حساب تواريخ أنتجت يوماً مستحيلاً، كإضافة شهر إلى 31 يناير فينتج 31 فبراير. عالج القيمة في مصدرها؛ فالصيغة سليمة أصلاً.
الفحص الذي يُنفَّذ
منقول حرفياً من ملفات قواعد التحقق التي تنشرها الهيئة، عند الملف والسطر المذكورين أدناه. والتعبير المُنفَّذ هو ما يُقيَّم على المستند، أما التعبير المذكور في التقرير فهو ما يظهر عند الإخفاق، وهما لا يتطابقان دائماً.
التعبير المُنفَّذ
not(string-length(.) = 10 and matches( string(.), '[2-9][0-9]([0-9]{2}[\-]((0[13578]|1[02])[\-](0[1-9]|[12][0-9]|3[01])|(0[469]|11)[\-](0[1-9]|[12][0-9]|30)|(02)[\-](0[1-9]|1[0-9]|2[0-8]))|([02468][048]|[13579][26])[\-](02)[\-]29)') )
التعبير المذكور في التقرير
(string-length(.) = 10 and (string(.) castable as xs:date))
كما يرد في الإصدار 3.4.8 من حزمة أدوات التطوير SDK التي تنشرها الهيئة: النسخة المقتبسة هنا هي الملف الذي يتضمنه ذلك الإصدار بايتاً ببايت. والتاريخ في اسم الملف هو الاسم الذي تعطيه الهيئة للملف، أما القواعد فيه فهي قواعد الإصدار 3.4.8.
مثال عملي
مستند اصطناعي من مجموعة الاختبار المقيسة تُرصد عليه هذه القاعدة، تُعرض منه الأسطر التي يختلف فيها عن مستند اجتاز الفحص. ولا يذكر تقرير مطابق سوى صورة القيمة، لا القيمة نفسها.