رمز الخطأ 1018: الفاتورة خارج نافذة الإبلاغ 24 ساعة

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

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

ماذا يعني رمز الخطأ 1018 بالضبط

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

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

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

كيف تُحسب نافذة الأربع وعشرين ساعة

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

الجدول التالي يوضّح كيف يتحرّك الفرق الزمني بين الإصدار والإبلاغ، ومتى يقع الرفض.

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

لماذا يُرفض الإبلاغ المتأخر ويُعرّضك للمخالفة

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

عواقب التأخير تتجاوز رسالة الرفض على الشاشة:

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

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

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

الأسباب الآلية التي تؤخّر الإبلاغ

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

التجميع الدفعي (Batching)

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

الأخطر أن خطأ يوم واحد في الدفعة يضرب عشرات الفواتير دفعة واحدة لا فاتورة واحدة. هذا ما يجعل الرمز 1018 يظهر فجأة بأعداد كبيرة بدل ظهوره فرادى.

تأخر الطابور (Queue)

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

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

انحراف الساعة والمنطقة الزمنية (Clock Drift)

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

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

كيف تقرأ رسالة الرفض

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

{
  "validationResults": {
    "infoMessages": [
      {
        "type": "INFO",
        "code": "XSD_ZATCA_VALID",
        "category": "XSD validation",
        "message": "Complied with UBL 2.1 standards"
      }
    ],
    "warningMessages": [],
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1018",
        "category": "Reporting window validation",
        "message": "Simplified invoice reported after the 24-hour window."
      }
    ],
    "status": "ERROR"
  },
  "reportingStatus": "NOT_REPORTED",
  "issueDateTime": "2026-06-24T13:00:00",
  "receivedDateTime": "2026-06-25T14:30:00"
}

المفاتيح التي تهمّك في القراءة:

• code بقيمة 1018 هو ما تعتمد عليه في تصنيف الخطأ. اربط منطق نظامك بالكود لا بالنص الوصفي، لأن الكود ثابت بينما النص قد يصاغ بطرق مختلفة.
• category بقيمة Reporting window validation يؤكد أن الخلل في توقيت الإبلاغ لا في بنية الفاتورة أو حسابها.
• reportingStatus بقيمة NOT_REPORTED يعني أن الفاتورة لم تدخل سجل الهيئة، فهي غير مبلَّغة حتى تعيد إرسالها بنجاح.
• قارن بين issueDateTime وreceivedDateTime. الفرق بينهما هو الفرق الذي رفضته المنصة. في المثال أعلاه الفرق خمس وعشرون ساعة ونصف، أي ساعة ونصف فوق الحد.

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

كيف تشخّص مصدر التأخير في نظامك

التشخيص يبدأ من حجم التأخير الذي قرأته في الاستجابة، لأن الحجم يدلّ على النمط المسبّب:

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

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

كيف تصحّح الفاتورة وتعيد إبلاغها

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

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

أما علاج المصدر فيعتمد على النمط الذي شخّصته:

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

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

كيف تميّز الرمز 1018 عن أخطاء الإبلاغ الأخرى

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

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

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

أين يقع الرمز 1018 في مسار الفاتورة المبسّطة

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

هذا يختلف جذرياً عن الفاتورة القياسية B2B، التي تمرّ بمقاصة فورية قبل تسليمها للمشتري، فلا تملك نافذة إبلاغ مؤجّل. لذلك الرمز 1018 خاص بمسار B2C وحده. ولفهم أعمق للفرق بين المسارين راجع أخطاء الإبلاغ (Reporting Errors) ومفهوم الإبلاغ (Reporting) في الفاتورة الإلكترونية.

سيناريو عملي: مطعم في الرياض يجمّع فواتير اليوم

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

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

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

كيف تمنع تكرار الخطأ نهائياً

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

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

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

كيف يتولى قيود إبلاغ فواتيرك في وقتها

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

يبقى عليك تسجيل معرّف الامتثال CSID لدى الهيئة مرة واحدة عند البدء، ويرشدك قيود خلال الخطوة. ولفهم بقية أخطاء مسار الإبلاغ راجع أخطاء الإبلاغ (Reporting Errors)، ولنظرة شاملة على أخطاء الفوترة راجع مرجع أخطاء هيئة الزكاة والضريبة والجمارك في الفوترة.

الأسئلة الشائعة

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

هل الرمز 1018 يخصّ كل أنواع الفواتير؟
لا. يخصّ الفاتورة المبسّطة B2C وحدها، لأنها الوحيدة التي تُبلَّغ بعد التسليم خلال نافذة مؤجّلة. الفاتورة القياسية B2B تمرّ بمقاصة فورية قبل التسليم، فلا تملك نافذة إبلاغ تتجاوزها.

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

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

كيف أفرّق بين تأخير حقيقي وانحراف ساعة؟
قارن بين issueDateTime وreceivedDateTime في استجابة الرفض. تأخير بدقائق قليلة فوق الحد على فواتير أُرسلت سريعاً يرجّح انحراف الساعة أو المنطقة الزمنية. تأخير بساعات يرجّح طابوراً عالقاً أو دفعة متأخرة.

هل يعفيني قيود من التعامل مع الرمز 1018؟
يرسل قيود كل فاتورة مبسّطة فور إصدارها بتوقيت موحّد، فيبقى الفرق في حدود دقائق ويبتعد عن حدّ الأربع وعشرين ساعة. يبقى عليك تسجيل معرّف الامتثال CSID لدى الهيئة مرة واحدة عند البدء، ويرشدك قيود خلالها.