BR-KSA-F-01 تحذير — الفاتورة تُقبل

تاريخ مكتوب بغير الصيغة YYYY-MM-DD

كل تاريخ في الفاتورة يُكتب ميلاديًا على الصورة YYYY-MM-DD: سنة من أربع خانات وشهر ويوم من خانتين، بلا وقت ولا منطقة زمنية. وهو تحذير، فالفاتورة تُقبل. الذي يوقعه دوال تنسيق التاريخ في لغات البرمجة والتقويم الهجري، وتاريخ بتوقيت UTC يبدو صحيحًا وهو يوم أمس.

نص الرسالة كما ترسلها الهيئة بالإنجليزية، بلا تعديل

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.

ماذا يعني هذا؟

القاعدة على الصيغة لا على القيمة: تاريخ الإصدار (BT-2) في cbc:IssueDate، وتاريخ التوريد (KSA-5) في cac:Delivery/cbc:ActualDeliveryDate، وآخر تاريخ توريد (KSA-24) في cbc:LatestDeliveryDate — كلها تُكتب على «التمثيل الكامل للتاريخ التقويمي» في ISO 8601: 2026-09-22. أربع خانات للسنة، ثم شرطة، ثم خانتان للشهر، ثم شرطة، ثم خانتان لليوم. لا شيء قبلها ولا بعدها.

وثلاثة أشياء تبدو تواريخ وليست على هذه الصورة: التاريخ مع وقته (2026-09-22T10:15:00Z)، فالوقت له حقله الخاص KSA-25 وقاعدته BR-KSA-70؛ والتاريخ بغير الحشو الصفري (2026-9-2)، فالشهر واليوم خانتان دائمًا؛ والتاريخ بمنطقة زمنية (2026-09-22+03:00)، فالتاريخ التقويمي عارٍ. وما هو أوضح: 22/09/2026 و09/22/2026 و22-09-2026 وSep 22, 2026 كلها خارج القاعدة ولو كان اليوم صحيحًا.

والتقويم ميلادي. التاريخ الهجري على الصورة نفسها — 1448-04-10 — يجتاز فحص الصيغة لأنه أربع خانات وخانتان وخانتان، ثم يُقرأ سنة 1448 ميلادية: مستند مؤرَّخ قبل ستة قرون. ولا قاعدة في القائمة التي نفهرسها تصطاده، فـBR-KSA-04 ترفض المستقبل وحده والماضي يمرّ. فهذا الكود يحرس الصيغة، وما بين الصيغة والواقع عليك أنت.

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

لماذا يحدث؟

مرتّبة من الأشيع إلى الأقل شيوعًا — الأرجح أن سببك في الأول أو الثاني.

  • دوال التنسيق الافتراضية في JavaScript: new Date().toString() يعطي Tue Sep 22 2026 10:15:00 GMT+0300، وtoLocaleDateString() يعطي 9/22/2026 على جهاز إنجليزي — وعلى جهاز ضبطه ar-SA يعطي تاريخًا هجريًا بأرقام هندية وعلامات اتجاه خفية بين أجزائه. أشيع سبب على الإطلاق في تكاملات الويب.
  • toISOString() ثم قصّ أول عشرة أحرف: تبدو الحيلة الصحيحة وهي فخّان. بلا قصّ تحمل الوقت وحرف Z؛ وبالقصّ تعطي تاريخ UTC لا الرياض، فمن منتصف الليل إلى الثالثة فجرًا يخرج تاريخ أمس — وأمس يمرّ في BR-KSA-04 بصمت، وفي أول الشهر يقع في الإقرار الضريبي الخاطئ.
  • التقويم الهجري من نظام محاسبي يعمل بتقويم أم القرى، أو من مستخدم كتب التاريخ الهجري في حقل التاريخ، يخرج على صورة ISO ويُقرأ ميلاديًا.
  • إعدادات المنطقة في Windows أو Excel: 22/09/2026 من ورقة عمل، أو الرقم التسلسلي للتاريخ (46287) حين يُقرأ ملف CSV بلا تنسيق.
  • دوال لغات أخرى بصيغتها الافتراضية: date('d/m/Y') في PHP، وDateTime.Now.ToString() في .NET بثقافة الجهاز، وstr(date.today()) في Python التي تصادف أنها صحيحة بينما str(datetime.now()) تحمل الوقت.
  • حقل نصي حرّ في النموذج بلا فحص، أو محرف خفي في القيمة: مسافة في آخرها، أو علامة اتجاه U+200E يزرعها التنسيق المحلي بين الأرقام ولا تراها العين.

كيف تصلحه

4 خطوات، ثم أعد إرسال الفاتورة.

  1. 1
    ابنِ التاريخ من أجزائه لا من دالة التنسيق الافتراضية

    في JavaScript: `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')}` من كائن تاريخ محلي. في PHP: $date->format('Y-m-d'). في .NET: ToString("yyyy-MM-dd", CultureInfo.InvariantCulture). في Python: strftime('%Y-%m-%d'). القاعدة العامة: صيغة صريحة بحروفها، لا صيغة تعتمد على لغة الجهاز.

  2. 2
    احسب اليوم بتوقيت الرياض ثم نسّقه

    المنطقة الزمنية أولًا والتنسيق ثانيًا: حوّل اللحظة إلى Asia/Riyadh ثم خذ منها السنة والشهر واليوم. الترتيب المعكوس — تنسيق بتوقيت UTC ثم إرسال — يعطي صيغة صحيحة ليوم خاطئ. والوقت الذي يرافق التاريخ يؤخذ من اللحظة نفسها، فراجع BR-KSA-70.

  3. 3
    ميلادي في الـ XML، والهجري للقارئ إن أردت

    إن كان نظامك يعمل بالهجري فحوّل عند المصدر بجدول أم القرى إلى الميلادي قبل بناء المستند، ولا ترسل ثلاثية هجرية في ثوب ISO. التاريخ الهجري له مكانه المطبوع على PDF إلى جانب الميلادي إن أراده عملاؤك؛ أما الـ XML فميلادي فقط.

  4. 4
    افحص الصيغة قبل التوقيع

    قبل أن تُوقَّع الفاتورة افحص كل تاريخ بتعبير يطابق الصورة حرفًا حرفًا — ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$ — ثم تحقّق أنه يوم حقيقي في التقويم (لا 31 فبراير) وأن سنته سنة هذا العصر. الفحص المسبق يمنع التحذير على كل فاتورة بدل أن تقرأه في الرد بعد التوقيع.

هذا الكود لا يمنع القبول، فالفاتورة الحالية نظامية. صحّح البيانات لتختفي التحذيرات من الفواتير القادمة.

هل يمنعه ZATCA Tools؟

نعم على كل الأبواب، مع حدّين. التاريخ لا يُكتب في الـ XML إلا من كائن تاريخ يُصاغ لحظة الإرسال بالصيغة الصحيحة — تاريخ الإصدار وتاريخ التوريد معًا — واليوم الافتراضي يُحسب بتوقيت الرياض في الخادم لا بالتوقيت العالمي ولا بجهاز المستخدم. وحقل التاريخ في نموذج الفاتورة من صنعنا، ميلادي، يحمل القيمة نصًا على الصورة YYYY-MM-DD ولا يعطي غيرها، بعد أن كان الحقل الأصلي على جهاز مضبوط على ar-SA يجيب بالهجري. والـ API يقرأ issue_date كما وصله: ما لم يستطع قراءته يُفشل الطلب قبل بناء أي مستند، وما استطاع قراءته يعيد كتابته على الصيغة الصحيحة. والحدّان على عاتق المرسل: القيمة 09/10/2026 تُقرأ على الطريقة الأمريكية فتصير العاشر من سبتمبر لا التاسع من أكتوبر، والتاريخ الهجري على صورة ISO مثل 1448-04-10 يمرّ عندنا كما يمرّ عند الهيئة على أنه ميلادي.

أكواد لها علاقة

BR-KSA-04 يرفض الفاتورة
تاريخ الفاتورة في المستقبل
BR-KSA-70 يرفض الفاتورة
وقت إصدار الفاتورة (KSA-25) ناقص أو بصيغة خاطئة
BR-KSA-15 تحذير
الفاتورة الضريبية بلا تاريخ توريد (KSA-5)

أسئلة شائعة

هل رُفضت فاتورتي بسبب هذا الكود؟ +
لا. BR-KSA-F-01 تحذير: الفاتورة تُقبل ويُسجَّل التحذير معها. فإن كانت مرفوضة فعلًا فالسبب كود آخر في errorMessages؛ وعلى التاريخ تحديدًا راجع BR-KSA-04 إن كان في المستقبل وBR-KSA-70 إن كان الوقت هو الناقص. وطريقة قراءة الرد في فاتورتي مرفوضة من الهيئة.
هل يجوز أن أكتب التاريخ الهجري في الفاتورة؟ +
مطبوعًا للقارئ نعم، إلى جانب الميلادي. أما في الـ XML فالقاعدة تسمّي ISO 8601 بعينه وهو تقويم ميلادي. والهجري على صورة ISO لا يُرفض ولا يُحذَّر منه — يُقرأ ميلاديًا ويؤرَّخ المستند قبل ستة قرون بصمت، وهذا أسوأ من التحذير.
أرسلت 2026-09-22T00:00:00 فظهر التحذير — أليس هذا ISO 8601؟ +
هو ISO 8601 لكنه تمثيل «تاريخ ووقت» لا «التاريخ التقويمي الكامل» الذي تسمّيه الرسالة. حقل التاريخ يأخذ التاريخ وحده، والوقت له حقل KSA-25 على الصورة hh:mm:ss بقاعدته BR-KSA-70.
نظامي يعمل بتوقيت UTC — هل أغيّر توقيت الخادم؟ +
لا حاجة. اترك الخادم على UTC وحوّل عند بناء الفاتورة فقط: خذ اللحظة، انقلها إلى Asia/Riyadh، ثم اقرأ منها التاريخ والوقت معًا. تغيير توقيت الخادم كله يصلح هذا ويكسر أشياء أخرى.
هل تنطبق القاعدة على تاريخ التوريد وتاريخ الفاتورة الأصلية في الإشعار؟ +
على كل تاريخ في المستند؛ الرسالة تقول «a date» بلا تخصيص. تاريخ التوريد (KSA-5) على الصورة نفسها، ووجوده في الفاتورة الضريبية له قاعدته BR-KSA-15. أما الإشعار فيحيل إلى فاتورته الأصلية برقمها لا بتاريخها، راجع BR-KSA-56.
أصلحت هذه — ولا تريد التالية

ZATCA Tools يبني التوقيع والبصمة والعدّاد والترميز عنك، ويتحقق من البيانات قبل الإرسال. ابدأ مجانًا، وبدون بطاقة ائتمانية.

ابدأ مجانًا

← كل أكواد أخطاء ZATCA