رمز الخطأ 1010: تنسيق التاريخ والوقت غير صحيح

«رمز الخطأ 1010: تنسيق التاريخ والوقت غير صحيح» من أكثر أخطاء الرفض إرباكًا لأصحاب الأعمال في الفوترة الإلكترونية. الفاتورة تبدو سليمة على الشاشة، الأرقام صحيحة، الطرفان معرّفان، ثم ترفضها منظومة فاتورة لسبب لا علاقة له بالمبالغ: حقل التاريخ أو الوقت مكتوب بصيغة لا يقبلها المعيار. هذا الدليل يشرح الخطأ من جذره: ما الذي تطلبه هيئة الزكاة والضريبة والجمارك (ZATCA) في حقلي IssueDate وIssueTime، ولماذا يفشل التحقق، وكيف تكتشف السبب الفعلي، وكيف تمنعه نهائيًا.

هذا المرجع جزء من سلسلة أخطاء هيئة الزكاة والضريبة والجمارك في الفوترة، وهو يركّز حصرًا على خطأ واحد: تنسيق التاريخ والوقت. إن كنت تبحث عن لائحة أوسع بأخطاء صيغة الحقول، فابدأ من دليل أخطاء التحقق (Validation Errors). ولفهم موقع هذين الحقلين داخل بنية الملف، ارجع إلى ترويسة الفاتورة (Invoice Header) في XML.

ما المقصود برمز الخطأ 1010؟

الرمز 1010 رسالة رفض تطلقها منظومة فاتورة عندما تجد أن قيمة حقل تاريخ أو وقت في ملف الفاتورة لا تطابق الصيغة التي يفرضها المعيار. الرفض هنا لا يعني أن التاريخ خاطئ منطقيًا فقط، بل قد يعني أن طريقة كتابة التاريخ نفسها غير مقبولة. منظومة فاتورة تقرأ ملف XML حرفيًا، وتقارن كل قيمة بقاعدة صارمة. أي انحراف عن الصيغة المتوقعة يوقف المعالجة فورًا.

تظهر رسالة الرفض عادة بهذا الشكل عند الاستجابة من المنصة:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "code": "1010",
        "category": "FORMAT",
        "message": "Invalid date/time format",
        "field": "cbc:IssueDate"
      }
    ]
  }
}

تلاحظ أن الرسالة تحدد الحقل المسبّب بدقة. في هذا المثال المشكلة في cbc:IssueDate. أحيانًا يكون الحقل المذكور cbc:IssueTime، وأحيانًا حقل تاريخ آخر مثل تاريخ التوريد. القراءة الأولى لرسالة الرفض هي أسرع طريق لتحديد مصدر الخطأ.

لماذا تتشدد المنصة في صيغة التاريخ والوقت؟

قد يبدو رفض فاتورة كاملة بسبب شرطة مائلة بدل واصلة تشدّدًا زائدًا. لكن خلف هذا التشدد منطق واضح. منظومة فاتورة تعالج ملايين الفواتير من آلاف الأنظمة المختلفة. لو سمحت لكل نظام بكتابة التاريخ بطريقته، لاختلطت القراءات. التاريخ 06/07/2026 يعني السادس من يوليو في بلد، والسابع من يونيو في بلد آخر. هذا الالتباس غير مقبول في مستند ضريبي رسمي.

لذلك تبنّت الفوترة الإلكترونية في السعودية معيار UBL 2.1 العالمي، وهو يعتمد بدوره صيغة التاريخ والوقت المعرّفة في المعيار الدولي ISO 8601. هذه الصيغة لا تحتمل تأويلًا: السنة أولًا، ثم الشهر، ثم اليوم، بترتيب يبدأ من الأكبر إلى الأصغر. الفائدة أن أي نظام في العالم يقرأ القيمة بالمعنى نفسه، دون لبس. كذلك تتوافق المملكة في هذا مع المواصفة الأوروبية EN 16931 التي تشكّل الأساس الدلالي للفاتورة الإلكترونية في كثير من الدول.

النتيجة العملية أن منظومة فاتورة لا تحاول تخمين ما تقصده. هي تتحقق من القيمة مقابل قاعدة واحدة صارمة، فإن طابقتها قبلتها، وإن انحرفت عنها رفضتها برمز 1010. لا توجد منطقة رمادية. هذا التشدد في الواقع حماية لك: الفاتورة المقبولة لا تحتمل أكثر من تفسير واحد لتاريخها، وهذا يحميك في أي مراجعة أو تدقيق لاحق.

الصيغة التي تطلبها الهيئة لحقل التاريخ

حقل cbc:IssueDate يحمل تاريخ إصدار الفاتورة. الصيغة الوحيدة المقبولة هي الصيغة الدولية المعروفة باسم ISO 8601، أي YYYY-MM-DD. يعني ذلك أربعة أرقام للسنة، ثم شرطة، ثم رقمان للشهر، ثم شرطة، ثم رقمان لليوم. التاريخ يكون ميلاديًا، لا هجريًا.

هذا المثال يوضح الصيغة الصحيحة كما تظهر داخل الملف:

<cbc:IssueDate>2026-06-24</cbc:IssueDate>

القيمة 2026-06-24 تعني الرابع والعشرين من يونيو سنة 2026. لاحظ أن الشهر يأتي قبل اليوم، عكس الترتيب الشائع في الكتابة العربية اليومية. هذا الترتيب جزء من المعيار، ولا يجوز تغييره. الجدول التالي يلخّص ما هو مقبول وما هو مرفوض.

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

الصيغة التي تطلبها الهيئة لحقل الوقت

حقل cbc:IssueTime يحمل توقيت إصدار الفاتورة. صيغته المقبولة هي HH:MM:SS بنظام أربع وعشرين ساعة. يعني ذلك رقمين للساعة، ثم نقطتين رأسيتين، ثم رقمين للدقيقة، ثم نقطتين، ثم رقمين للثانية. الساعة تتراوح بين 00 و23، والدقائق والثواني بين 00 و59.

المثال التالي يوضح الصيغة الصحيحة:

<cbc:IssueTime>14:42:18</cbc:IssueTime>

القيمة 14:42:18 تعني الساعة الثانية والاثنتين والأربعين دقيقة وثماني عشرة ثانية بعد الظهر. لا تستخدم صيغة 12 ساعة مع ص أو م، ولا تكتب الساعة برقم واحد. الجزء الخاص بالثواني مطلوب، وحذفه سبب شائع للرفض.

السؤال الذي يربك الكثيرين: هل أكتب التوقيت المحلي للمملكة أم التوقيت العالمي؟ الإجابة أن الفاتورة الصادرة من منشأة داخل المملكة تُسجَّل بالتوقيت المحلي، وهو توقيت المملكة الموحّد المتقدم على التوقيت العالمي المنسّق (UTC) بثلاث ساعات. المهم أن يكون التوقيت متّسقًا مع تاريخ الإصدار في الحقل الآخر. التضارب بين منطقتين زمنيتين مختلفتين في الملف الواحد سبب خفيّ لكثير من حالات الرفض، خاصة حين يُولّد التاريخ على خادم في منطقة زمنية، ويُولّد الوقت على جهاز في منطقة أخرى.

حالات حدّية في الوقت تستحق الانتباه

منتصف الليل تحديدًا مصدر لبس شائع. اللحظة الأولى من اليوم تُكتب 00:00:00، لا 24:00:00. الساعة لا تصل إلى الرقم 24 أبدًا في نظام الأربع والعشرين ساعة، بل تعود إلى الصفر مع تقدّم اليوم. أي نظام يكتب الساعة 24 يسبّب الرفض، والأخطر أنه قد يدفع التاريخ يومًا كاملًا لو لم يُعالَج الانتقال بشكل صحيح.

مسألة أخرى تخص بعض الأنظمة التي تضيف معلومة المنطقة الزمنية إلى قيمة الوقت، مثل لاحقة تشير إلى الفارق عن التوقيت العالمي. المهم أن يلتزم نظامك بالصيغة التي تتوقعها المنصة، وألا يخلط بين كتابة الوقت محليًا وكتابته معياريًا بلاحقة منطقة زمنية في الفاتورة نفسها. الاتساق هو القاعدة: صيغة واحدة في كل الفواتير، لا صيغة هنا وأخرى هناك.

وأخيرًا، انتبه إلى الفاتورة التي تُصدر قرب منتصف الليل. لو وُلّد التاريخ في الثانية الأخيرة من اليوم، ووُلّد الوقت في الثانية الأولى من اليوم التالي، تصبح اللحظتان متضاربتين رغم أن كلًا منهما سليم منفردًا. توليد الحقلين من المصدر الزمني نفسه في اللحظة نفسها يمنع هذا التضارب تمامًا.

الأسباب الشائعة للخطأ 1010

رمز واحد، لكن أسبابه متعددة. فهم السبب الدقيق يختصر وقت الحل. هذه أكثر الأسباب تكرارًا في فواتير المنشآت السعودية.

الفاصل الخاطئ بين أجزاء التاريخ

أكثر سبب شيوعًا. النظام الذي يولّد الفاتورة يكتب التاريخ بصيغة محلية مثل 24/06/2026 بدل الصيغة المعيارية. الشرطة المائلة غير مقبولة، والمطلوب واصلة. هذا يحدث غالبًا حين يعتمد النظام على إعدادات التاريخ في جهاز المستخدم بدلًا من صيغة ثابتة.

السنة الهجرية بدل الميلادية

بعض الأنظمة تكتب التاريخ الهجري لأنه التقويم الرسمي في كثير من المعاملات المحلية. المعيار في الفوترة الإلكترونية يطلب التاريخ الميلادي حصرًا. كتابة 1447-12-09 ترفضها المنصة حتى لو كان التاريخ صحيحًا هجريًا.

حذف خانة الثواني من الوقت

الوقت يجب أن يحمل الثواني. كتابة 14:42 دون الثواني تكسر الصيغة. الصيغة الكاملة 14:42:18.

الخانة المفردة بدل المزدوجة

كل جزء يجب أن يأخذ عدد خاناته الكامل. الشهر السادس يُكتب 06 لا 6، والساعة التاسعة تُكتب 09 لا 9. حذف الصفر المتقدم يكسر الصيغة.

تاريخ في المستقبل

تاريخ الإصدار لا يجوز أن يسبق اللحظة الحالية. الفاتورة المؤرَّخة بيوم لم يأتِ بعد تُرفض، لأن منظومة فاتورة في النموذج الفوري تتلقى الفاتورة قرب لحظة إصدارها. هذا الخطأ يظهر غالبًا حين يكون توقيت الخادم متقدمًا عن التوقيت الفعلي بسبب إعداد منطقة زمنية خاطئ، فيصبح وقت الإصدار في نظر المنصة وقتًا لم يحلّ بعد.

تضارب المنطقة الزمنية بين الحقول

حين يُولَّد التاريخ على خادم بتوقيت عالمي، ويُولَّد الوقت بتوقيت محلي، قد تتضارب القيمتان عند حساب اللحظة الفعلية. النتيجة فاتورة يبدو وقتها سابقًا لتاريخها أو لاحقًا له بفارق ساعات. الاتساق بين الحقلين شرط للقبول.

كيف تكتشف السبب الفعلي خطوة بخطوة

التشخيص أهم من التخمين. اتبع هذا الترتيب لتصل إلى مصدر الخطأ بأقصر طريق.

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

ثانيًا، افتح ملف XML المرفوض، وانظر إلى القيمة الفعلية في ذلك الحقل. قارنها بالصيغة المعيارية: هل الفاصل واصلة؟ هل التاريخ ميلادي؟ هل كل جزء بعدد خاناته الكامل؟ هل الوقت يحمل الثواني؟

ثالثًا، تحقق من اتساق التاريخ مع الوقت. احسب اللحظة الكاملة وتأكد أنها ليست في المستقبل، وأنها لا تتضارب بين منطقتين زمنيتين. راجع إعداد المنطقة الزمنية على الخادم الذي يولّد الفاتورة.

رابعًا، إن كانت القيمة سليمة شكلًا لكنها تُرفض، فالمشكلة غالبًا في إعداد المنطقة الزمنية أو في ساعة النظام نفسها. صحّح الإعداد ثم أعد التوليد. الجدول التالي يربط كل عرض بسببه المرجّح.

كيف تصلح الفاتورة المرفوضة

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

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

إن كنت تستخدم نظامًا محاسبيًا معتمدًا، فالأرجح أنك لن تواجه هذا الخطأ أصلًا، لأن النظام يولّد التاريخ والوقت بالصيغة المعيارية تلقائيًا. الخطأ 1010 يظهر غالبًا في الأنظمة التي تبني ملف XML يدويًا أو عبر تكامل مخصّص لم يلتزم بالمعيار حرفيًا.

مثال عملي كامل: من الرفض إلى القبول

لنتابع حالة واقعية بالكامل لتترسخ الفكرة. منشأة أرسلت فاتورة فرُفضت برمز 1010، والحقل المذكور cbc:IssueDate. عند فتح الملف ظهر هذا المقطع من الترويسة:

<cbc:ID>INV-2026-000128</cbc:ID>
<cbc:IssueDate>24/6/2026</cbc:IssueDate>
<cbc:IssueTime>14:42</cbc:IssueTime>

القراءة الأولى تكشف خطأين معًا في الحقلين. في حقل التاريخ، الفاصل شرطة مائلة لا واصلة، والترتيب يبدأ باليوم، والشهر بخانة واحدة. كل واحد من هذه الثلاثة كافٍ وحده للرفض. وفي حقل الوقت، خانة الثواني محذوفة. التصحيح يعيد كتابة الحقلين بالصيغة المعيارية:

<cbc:ID>INV-2026-000128</cbc:ID>
<cbc:IssueDate>2026-06-24</cbc:IssueDate>
<cbc:IssueTime>14:42:18</cbc:IssueTime>

بعد التصحيح، السنة أولًا بأربع خانات، الشهر بخانتين 06، اليوم بخانتين، والفاصل واصلة. والوقت اكتمل بخانة الثواني. أُعيد الإرسال فقُبلت الفاتورة من أول محاولة. لاحظ أن رقم الفاتورة لم يتغير، لأن الفاتورة المرفوضة لم تُسجَّل أصلًا، فلا حاجة لرقم جديد ولا لإشعار دائن.

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

علاقة التاريخ والوقت بباقي حقول الفاتورة

حقلا الإصدار ليسا الوحيدين اللذين يحملان قيمة زمنية في الفاتورة. تحتوي بعض الفواتير على تواريخ إضافية، مثل تاريخ التوريد الفعلي للسلعة أو الخدمة، وتواريخ ضمن المراجع إلى مستندات سابقة في حالة الإشعارات الدائنة والمدينة. كل هذه التواريخ تخضع لقاعدة الصيغة نفسها YYYY-MM-DD. لذلك حين يظهر رمز 1010، اقرأ الحقل المذكور بدقة، فقد لا يكون تاريخ الإصدار بل تاريخًا آخر في الملف.

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

كيف تمنع تكرار الخطأ 1010

الوقاية أرخص من المعالجة. الخطأ 1010 ليس خطأ يحدث مرة ويزول، بل عرض لإعداد غير سليم في طبقة توليد الفاتورة. إصلاح الإعداد مرة واحدة يقفل الباب أمام كل تكرار. هذه أربع ممارسات تُجنّبك الرفض من الأساس.

اعتمد صيغة ثابتة لا تتأثر بالجهاز

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

وحّد المنطقة الزمنية على كل المكوّنات

الفاتورة تمر عادة بعدة طبقات: قاعدة البيانات التي تخزّن وقت الإنشاء، الخادم الذي يبني الملف، وواجهة المستخدم التي تعرض القيمة. لو اختلفت المنطقة الزمنية بين هذه الطبقات، نشأ التضارب الذي يسبّب الرفض. القاعدة بسيطة: منطقة زمنية واحدة موحّدة عبر كل المكوّنات، هي توقيت المملكة، أو مرجع زمني واحد يُحوَّل منه للمحلي عند العرض فقط.

زامِن ساعات الخوادم باستمرار

ساعة الخادم تنحرف ببطء مع الوقت إن لم تُزامَن مع مصدر موثوق. انحراف بضع دقائق كافٍ لجعل وقت الإصدار يبدو في المستقبل، فترفضه المنصة. فعّل المزامنة التلقائية للوقت على كل خادم يولّد فواتير، وتحقق منها دوريًا، فهذه الخطوة تمنع فئة كاملة من حالات الرفض الغامضة التي تبدو فيها القيمة سليمة شكلًا.

اختبر قبل الإطلاق الفعلي

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

الفرق العملي بين منشأة تعاني من هذا الخطأ ومنشأة لا تراه أبدًا هو في طبقة توليد الملف. حين تتولى منصة معتمدة بناء كل الحقول وفق المعيار، تختفي هذه الفئة من الأخطاء كليًا، ويتفرّغ صاحب العمل لإدارة منشأته بدل تتبّع تفاصيل ملف XML.

ماذا لو تكرر الرفض بعد التصحيح؟

أحيانًا تصحّح الصيغة، تعيد الإرسال، ثم يعود الرفض برمز 1010 مرة أخرى. هذا التكرار محبط، لكنه يحمل دلالة واضحة: الخطأ ليس في القيمة التي تراها، بل في طبقة أعمق تولّدها.

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

ثانيًا، افحص ساعة الخادم ومنطقته الزمنية مرة أخرى. القيمة قد تبدو سليمة في الملف، لكن لحظة الإرسال الفعلية تختلف عما تظنه بسبب انحراف الساعة. صحّح المزامنة، ثم أعد التوليد والإرسال في اللحظة نفسها.

ثالثًا، تأكد أن الحقل المذكور في رسالة الرفض هو الحقل الذي عدّلته فعلًا. قد تكون أصلحت تاريخ الإصدار بينما المشكلة في تاريخ آخر داخل الملف. رسالة الرفض تسمّي الحقل بدقة، فاقرأها حرفيًا قبل أي تعديل.

إن استمر الرفض رغم سلامة كل ما سبق، فالأرجح أن المشكلة في التكامل المخصّص الذي يبني الملف. هنا يكون الانتقال إلى منصة معتمدة تولّد الحقول وفق المعيار تلقائيًا أوفر وأكثر أمانًا من إصلاح التكامل اليدوي حقلًا حقلًا.

كيف يساعدك قيود في تجنّب الخطأ 1010

يولّد برنامج الفاتورة الإلكترونية من قيود حقلي التاريخ والوقت بالصيغة المعيارية تلقائيًا، فلا تكتب أنت أي قيمة يدويًا ولا تتعرض لخطأ الصيغة من الأساس. هذه أبرز ما يقدّمه النظام في هذا الجانب:

• توليد حقل تاريخ الإصدار بصيغة YYYY-MM-DD الميلادية تلقائيًا، دون اعتماد على إعدادات جهاز المستخدم.
• كتابة حقل الوقت بصيغة HH:MM:SS الكاملة مع الثواني، بتوقيت المملكة الموحّد، ومتّسقًا مع تاريخ الإصدار.
• الربط المباشر مع منصة فاتورة في المرحلة الثانية، مع توليد كل حقول الترويسة بالترتيب الذي يفرضه المعيار.
• إدارة شهادة الختم المشفّر (CSID) تلقائيًا، فيتفرّغ صاحب العمل لتشغيل منشأته بدل متابعة تفاصيل ملف XML.

النتيجة فاتورة تُقبل من أول إرسال، بلا رمز رفض 1010 ولا غيره من أخطاء الصيغة، لأن طبقة التوليد تلتزم بالمعيار حرفيًا في كل حقل.