ترسل فاتورة إلى نظام الفوترة الوطني فيعود الرد بلا رمز QR، وفي حقل الحالة قيمة واحدة تحسم الأمر. هذه القيمة هي حالة NOT_SUBMITTED في نظام الفوترة الوطني، وهي الحالة الوحيدة بين قيم الرد الثلاث التي تعني أن الفاتورة رُفضت. والخبر الجيد أن الرفض هنا مفهوم السبب، فالرد نفسه يحمل رسالة تشرح ما الذي يجب إصلاحه.
الجواب المختصر أن الدليل التقني الصادر عن دائرة ضريبة الدخل والمبيعات يعرّف هذه الحالة بأن الفاتورة المرسلة لم تُقبل ولم تُعتمد بسبب خطأ معين، وأن رمز الاستجابة الفني فيها لن يكون 200، وأن حقول رمز QR والمعرّف الفريد ورقم الفاتورة والفاتورة الموقعة تعود فارغة. تقرأ السبب في EINV_MESSAGE، وتصلحه في ملف الفاتورة، ثم تعيد الإرسال برقم الفاتورة ID والمعرّف الفريد UUID نفسيهما.
يشرح هذا المقال معنى الحالة كما يعرّفها الدليل، وشكل الرد عند الرفض حقلًا حقلًا، وأين تجد سبب الرفض، وكيف تصلح الفاتورة وتعيد إرسالها دون أن تنشئ فاتورة مكررة، وما الذي لا يذكره الدليل عن هذه الحالة فلا يصح البناء عليه.
ما معنى حالة NOT_SUBMITTED في نظام الفوترة الوطني
يحمل رد النظام بعد كل إرسال عنصرًا اسمه EINV_STATUS، ويذكر الدليل التقني (الإصدار 1.5، ص98) أن له ثلاث قيم. ويعرّف الدليل القيمة NOT_SUBMITTED في ص100 بهذا النص.
«أي أن الفاتورة المرسلة إلى نظام الفوترة لم يتم قبولها ولا اعتمادها وذلك بسبب حدوث خطأ معين. في هذه الحالة فإن Response Status Code لن تكون قيمته 200».
في هذا التعريف ثلاث معلومات عملية.
- الفاتورة مرسلة ومرفوضة. النص يتحدث عن «الفاتورة المرسلة إلى نظام الفوترة»، أي أن النظام تسلّمها وفحصها ثم ردّ بعدم قبولها. ولأن الحالة قيمة داخل الرد، فوجودها يعني أن ردًا وصل إلى نظامك فعلًا.
- للرفض سبب محدد. عبارة «بسبب حدوث خطأ معين» تعني أن الرفض ليس عشوائيًا، وأن السبب مكتوب في الرد كما يأتي في القسم التالي.
- رمز الاستجابة الفني ليس 200. يكتفي الدليل بهذا النفي، ولا يربط الحالة برمز بعينه.
وتقع هذه الحالة إلى جانب قيمتين أخريين. فالقيمة SUBMITTED تعني قبول الفاتورة بنجاح، ويتناولها مقال حالة SUBMITTED في مركز الأخطاء. والقيمة ALREADY_SUBMITTED تعني أن الفاتورة معتمدة مسبقًا، وشرحها في مقال حالة ALREADY_SUBMITTED في نظام الفوترة الوطني. أما NOT_SUBMITTED فهي وحدها حالة الرفض.
شكل الرد عند الرفض والحقول التي تعود فارغة
يعرض الدليل في ص100 مثالًا كاملًا لرد مرفوض. والقيمة التي تهمك أولًا هي EINV_STATUS، ثم الحقول الأربعة التي تأتي بعدها، وكلها بالقيمة null.
يجمع الجدول الآتي عناصر هذا الرد، ووصف كل عنصر في الدليل، وما يعنيه لك حين تكون الحالة NOT_SUBMITTED.
مرِّر الجدول أفقيًا لعرض بقية الأعمدة
وفي المثال تفصيل يستحق الانتباه. فقائمة INFO تحمل نتيجة ناجحة لفحص XSD، برسالة Complied with UBL 2.1 standards، بينما تحمل قائمة ERRORS خطأ في مجموع الضريبة. أي أن الملف في هذا المثال اجتاز فحص XSD ورُفض بسبب قيمة في المجاميع. ولا يذكر الدليل أن كل رفض يجري على هذا النحو، فهذا ما يُظهره المثال وحده.
رمز QR الفارغ يعني أن الفاتورة غير مقبولة
ينص الدليل (ص98) على أن وجود رمز QR في الحقل EINV_QR شرط لاعتبار الفاتورة مستلمة ومقبولة، ويطلب إظهار الرمز على فاتورة البائع. فإذا عاد الحقل فارغًا فلا رمز لديك تظهره، والفاتورة لا تُعد مقبولة حتى تعيد إرسالها وتُقبل.
المعرّف الفريد الفارغ في الرد لا يلغي معرّفك
عودة EINV_INV_UUID فارغًا لا تعني أن عليك توليد معرّف جديد. فالمعرّف الفريد يولّده نظام المكلف ويضعه في ملف الفاتورة داخل الحقل cbc:UUID، أما الحقل في الرد فيعود فارغًا في حالة الرفض كما في مثال الدليل. هذا المعرّف نفسه هو ما ستحتاجه عند إعادة الإرسال، فاحتفظ به كما هو. وشرح من يولّد المعرّف ولماذا يُعاد مع الرقم في مقال المعرّف الفريد UUID في نظام الفوترة الوطني.
لا تحكم على الفاتورة برمز الاستجابة الفني وحده
ينص الإرشاد الرابع في الدليل (ص104)، «التعامل مع الاستجابة»، على أنه «لا يُعتمد على Status Code فقط، وإنما يجب الاعتماد على قيمة EINV_STATUS لتحديد حالة الفاتورة النهائية». وهذا الإرشاد هو مفتاح التعامل مع حالة الرفض لسببين.
- الدليل لا يسمّي رمزًا بعينه لهذه الحالة. كل ما يقوله إن الرمز لن يكون 200. ورسالة المثال في ص100 واردة ضمن الرسائل التي يذكرها الدليل تحت رمز 400، لكن الدليل لا يذكر رمز الاستجابة فوق المثال، ولا يقصر الحالة على رمز واحد. لذلك لا تبنِ منطق برنامجك على رقم بعينه.
- الحالة هي الحكم النهائي. برنامج يقرأ
EINV_STATUSيعرف أن الفاتورة رُفضت مهما كان رمز الاستجابة، ويعرف كذلك أن عليه قراءة الأخطاء قبل أي محاولة جديدة.
ويذكر الدليل (ص101) أربعة رموز استجابة غير 200 مع أسبابها. رمز 400 يدل على خطأ في القيم المرسلة في ملف XML، ويُشرح الخطأ في EINV_MESSAGE، وتفصيله في مقال خطأ 400 في نظام الفوترة الوطني. ورمز 403 يعني رقم مستخدم أو مفتاحًا سريًا غير صحيح، ورمز 500 يرده الدليل أولًا إلى الرقم الضريبي أو تسلسل مصدر الدخل، ورمز 504 يعني تعذّر الوصول إلى النظام. ولكل رمز منها مقال مستقل في مركز الأخطاء، وتجمعها كلها خريطة أخطاء نظام الفوترة الوطني. ولا يذكر الدليل هل يحمل رد 403 أو 500 أو 504 قيمة في EINV_STATUS أصلًا.
أين تجد سبب الرفض في الرد
سبب الرفض موجود داخل العنصر EINV_RESULTS، في قائمة ERRORS. ويحمل كل عنصر في هذه القائمة خمسة حقول هي type وstatus وEINV_CODE وEINV_CATEGORY وEINV_MESSAGE. والحقل الأخير هو موضع الشرح، فالدليل (ص101) يذكر في شرح رمز 400 أنه «يتم توضيح الخطأ في ال EINV_MESSAGE في ملف ال Response».
وفي مثال ص100 يحمل عنصر الخطأ هذه القيم.
- رمز الخطأ
EINV_CODEبالقيمةtotalGeneralTaxesAmount. - فئة الخطأ
EINV_CATEGORYبالقيمةinvoice. - نص الخطأ
EINV_MESSAGEبالقيمةTotal General Amount is Not Correct، وهي رسالة تخص حساب المجاميع، ولها مقال مستقل هو رسالة Total General Amount is Not Correct.
ولكل رسالة يذكرها الدليل سبب محدد وطريقة إصلاح مختلفة، وفهرس هذه الرسائل وطريقة قراءة عناصر الخطأ بالترتيب في مقال خطأ 400 المذكور أعلاه. والقاعدة هنا أن تقرأ الرسالة كما هي، دون ترجمة أو تخمين، ثم تبحث عن القيمة التي تشير إليها في ملف XML الذي أُرسل فعلًا.
كيف تصلح الفاتورة المرفوضة قبل إعادة إرسالها
الخطوات الآتية مبنية على تعريف الحالة وعلى إرشادات الدليل التشغيلية (ص104)، ومرتبة من لحظة وصول الرد إلى لحظة إعادة الإرسال.
- تأكد من الحالة. اقرأ قيمة
EINV_STATUS. إذا كانتNOT_SUBMITTEDفالفاتورة لم تُقبل، ويؤكد ذلك أنEINV_QRفارغ. - اجمع عناصر قائمة ERRORS كلها. القائمة مصفوفة، فلا تكتفِ بعنصرها الأول. وانسخ الحقول الخمسة لكل عنصر كما وردت.
- حدّد القيمة المقصودة في ملف XML. افحص القيمة التي تشير إليها الرسالة في الملف المرسل نفسه، لا في شاشة إدخال البيانات، لأن النظام يحكم على ما وصله في الملف.
- أصلح القيمة وراجع ما حولها. يطلب الإرشاد الثاني، «التحقق قبل الإرسال»، التحقق من المجاميع والضرائب والرقم الضريبي ورقم المشتري والحقول الإلزامية قبل الإرسال. فإذا أصلحت قيمة، فأعد التحقق من المجاميع التي تتأثر بها.
- أبقِ رقم الفاتورة والمعرّف الفريد كما هما. لا تغيّر
cbc:IDولاcbc:UUIDفي الملف المصحح. - سجّل الخطأ ثم أعد الإرسال. سجّل تفاصيل الخطأ في نظامك قبل المحاولة الجديدة، ثم أرسل الملف المصحح واقرأ الحالة في الرد الجديد.
إعادة الإرسال بنفس ID وUUID
ينص الإرشاد الثالث في الدليل، «إدارة إعادة الإرسال»، على أنه «عند فشل الإرسال يجب إعادة الإرسال باستخدام نفس ID و UUID لتجنب إنشاء فاتورة جديدة أو تكرار البيانات».
وسبب هذا الإرشاد أن النظام يعرف الفاتورة بقيمتين معًا، رقم الفاتورة في cbc:ID والمعرّف الفريد في cbc:UUID، ويصفهما الدليل (ص12) بأنهما يشكلان معًا مفتاحًا رئيسيًا «لعدم تكرار الفاتورة المرسلة على النظام». فإذا ولّد برنامجك معرّفًا جديدًا عند كل محاولة، صار للفاتورة الواحدة أكثر من هوية، وهذا تحديدًا ما يحذّر منه الدليل.
وبعد إعادة الإرسال تقرأ الحالة من جديد، وتتصرف بحسب قيمتها.
مرِّر الجدول أفقيًا لعرض بقية الأعمدة
ولا يصف الدليل صراحة شكل الرد على إعادة إرسال فاتورة رُفضت من قبل، ولا يحدد عددًا للمحاولات ولا فاصلًا زمنيًا بينها. لذلك يبقى المرجع في كل محاولة هو قيمة EINV_STATUS، كما يطلب الإرشاد الرابع. وإعادة إرسال الملف نفسه دون إصلاح لا معنى لها، فالخطأ الذي سبّب الرفض ما زال فيه.
ما الذي تسجله في نظامك بعد كل رفض
الرفض حدث يستحق أن يُسجَّل، لا أن يُتجاوز. وثلاثة من إرشادات الدليل (ص104) تحدد ما يسجله النظام المرتبط.
- الإرشاد الخامس، «تخزين البيانات الأساسية». يطلب حفظ ID وUUID وQR Code وEINV_STATUS لضمان التتبع وإعادة الاسترجاع. وفي حالة الرفض يكون الرمز فارغًا، فتحفظ الرقم والمعرّف والحالة، وتبقى الفاتورة في نظامك بانتظار الإصلاح.
- الإرشاد السادس، «إدارة الأخطاء». يطلب تسجيل الأخطاء تفصيليًا في السجل الداخلي، مع عرض رسالة مبسطة للمستخدم النهائي. فالحقول الخمسة لعنصر الخطأ تُحفظ كما هي، والمستخدم يرى جملة يفهمها.
- الإرشاد العاشر، «تتبع العمليات (Audit Trail)». يطلب الاحتفاظ بسجل كامل لعمليات الإرسال والاستجابة وإعادة الإرسال، وهو ما يبيّن لاحقًا متى رُفضت الفاتورة ومتى قُبلت.
وشرح هذه الإرشادات وغيرها في مقال الإرشادات العشر لنظام الفوترة الوطني.
ملاحظة على عنوان المثال في ص100
يضع الدليل فوق مثال الرد المرفوض في ص100 عنوانًا نصه «في حالة الALREADY_SUBMITTED»، لكن المثال نفسه يحمل القيمة NOT_SUBMITTED والحقول الفارغة الخاصة بالرفض. فإذا رجعت إلى الدليل، فاعتمد على تعريف الحالة في الصفحة نفسها وعلى القيمة المكتوبة داخل المثال، لا على العنوان. وأمثلة الدليل عمومًا توضيحية، فلا تنسخها في ملف فعلي.
ما الذي لا يذكره الدليل عن حالة الرفض
يفيدك أن تعرف حدود النص الرسمي، كي لا تبني برنامجك على افتراض. وهذه نقاط لا يذكرها الدليل التقني (الإصدار 1.5).
- رمز استجابة محدد للحالة. يقول الدليل إن الرمز لن يكون 200، ولا يزيد.
- عدد محاولات إعادة الإرسال أو الفاصل بينها. لا يذكر الدليل حدًا ولا توقيتًا.
- مهلة لإعادة إرسال الفاتورة بعد رفضها. لا توجد في المصادر التي نعتمد عليها مدة محددة بالساعات أو الأيام لإرسال الفاتورة إلى النظام.
- شكل الرد على إعادة إرسال فاتورة مرفوضة. لا يصفه الدليل صراحة، والمرجع فيه قيمة
EINV_STATUS.
فإذا احتجت إلى جواب في إحدى هذه النقاط، فالجهة التي تجيب عنه هي دائرة ضريبة الدخل والمبيعات، كما في القسم التالي.
متى تتواصل مع دائرة ضريبة الدخل والمبيعات
إذا تكرر الرفض بعد إصلاح ما تشير إليه الرسالة، أو وصلتك رسالة لا تجد لها شرحًا في الدليل، فالدليل (ص104) يحيل إلى لجنة الدعم الفني لشؤون الفوترة في دائرة ضريبة الدخل والمبيعات عبر موقعها istd.gov.jo. ويسهّل عليك المراجعة أن يكون معك ما يأتي.
- رقم الفاتورة ومعرّفها الفريد كما أُرسلا.
- الحقول الخمسة لكل عنصر في قائمة
ERRORS، منسوخة دون تعديل. - قيمة
EINV_STATUSورمز الاستجابة الفني في كل محاولة. - ما الذي أصلحته في الملف بين محاولة وأخرى.
قائمة فحص سريعة عند ظهور الحالة
إذا ظهرت لك NOT_SUBMITTED في رد النظام، فهذه أسئلة تمر عليها بالترتيب.
- هل قرأت الحالة من
EINV_STATUSلا من رمز الاستجابة الفني؟ - هل جمعت كل عناصر قائمة
ERRORS، لا العنصر الأول وحده؟ - هل وجدت القيمة التي تشير إليها الرسالة في ملف XML المرسل نفسه؟
- هل راجعت المجاميع والضرائب والرقم الضريبي ورقم المشتري والحقول الإلزامية بعد الإصلاح؟
- هل بقي رقم الفاتورة والمعرّف الفريد في الملف المصحح كما كانا؟
- هل سجّلت تفاصيل الخطأ في نظامك قبل إعادة الإرسال؟
- بعد إعادة الإرسال، هل عادت الحالة
SUBMITTEDومعها رمز QR فيEINV_QR؟ إن عادت فاحفظ الرمز وأظهره على فاتورة البائع.
كيف يتعامل قيود مع الفواتير المرفوضة
ما سبق عمل يقع على نظام المكلف المربوط بالنظام. ويعمل تكامل قيود مع نظام الفوترة الوطني على هذه الطبقة كما يلي.
- فحص قبل الإرسال. يفحص قيود كل فاتورة على مستوى الحقول لحظة إنشائها، أي الرقم الضريبي ونوع المستند وطريقة الدفع ونسبة ضريبة المبيعات العامة واكتمال البنود، وينبهك بأي خطأ قبل إرسالها إلى نظام الفوترة الوطني لتقليل حالات الرفض.
- حالة كل فاتورة ورسالة خطئها أمامك. تعيد الدائرة حالة الفاتورة ورسالة الخطأ، ويعرضها قيود في لوحة الحالة، ومنها «لم تُرسل» مع رسالة الخطأ.
- إعادة إرسال بالمعرّف نفسه. تعرض لوحة الحالة الفواتير التي لم تُرسل وتحتاج إلى إعادة إرسال، وحين تعيد إرسال فاتورة منها تُرسل بالمعرّف UUID نفسه.
وإعادة الإرسال هنا خطوة تقوم بها أنت من لوحة الحالة بعد إصلاح سبب الرفض. أما رمز QR فتصدره الدائرة بعد قبول الفاتورة، ويظهر على الفاتورة التي يصدرها قيود. ولصورة أوسع عن النظام وطريقة ربط منشأتك به، اقرأ مقال نظام الفوترة الوطني الالكتروني، أو تعرّف على ما يقدمه قيود في نظام الفوترة الوطني.
فوترة إلكترونية ومحاسبة متكاملة في نظام واحد
ينبهك قيود بأي خطأ في حقول الفاتورة قبل إرسالها إلى نظام الفوترة الوطني، ويعرض حالة كل فاتورة في لوحة الحالة.
الأسئلة الشائعة
ما معنى حالة NOT_SUBMITTED في نظام الفوترة الوطني؟
تعني أن الفاتورة المرسلة لم تُقبل ولم تُعتمد بسبب خطأ معين. يعرّفها الدليل التقني لدائرة ضريبة الدخل والمبيعات بهذا المعنى، ويذكر أن رمز الاستجابة الفني فيها لن يكون 200.
ما الحقول التي تعود فارغة في رد الفاتورة المرفوضة؟
تعود أربعة حقول بالقيمة null، وهي رمز QR في EINV_QR، والمعرّف الفريد في EINV_INV_UUID، ورقم الفاتورة في EINV_NUM، والفاتورة الموقعة في EINV_SINGED_INVOICE، كما في مثال الدليل ص100.
أين أجد سبب رفض الفاتورة؟
تجده في قائمة ERRORS داخل العنصر EINV_RESULTS، وتحديدًا في الحقل EINV_MESSAGE لكل عنصر خطأ. ويرافقه في العنصر نفسه رمز الخطأ EINV_CODE وفئته EINV_CATEGORY.
هل أولّد معرّفًا فريدًا جديدًا قبل إعادة إرسال الفاتورة المرفوضة؟
لا تولّد معرّفًا جديدًا. يطلب الدليل عند فشل الإرسال إعادته بنفس ID وUUID لتجنب إنشاء فاتورة جديدة أو تكرار البيانات، وعودة المعرّف فارغًا في الرد لا تلغي المعرّف الذي في ملفك.
ما رمز الاستجابة الفني الذي يرافق حالة NOT_SUBMITTED؟
يذكر الدليل أنه لن يكون 200، ولا يحدد رمزًا بعينه. ولهذا يطلب الدليل الحكم على الفاتورة بقيمة EINV_STATUS لا برمز الاستجابة الفني وحده.
كم مرة يمكنني إعادة إرسال الفاتورة بعد رفضها؟
لا يحدد الدليل التقني عددًا للمحاولات ولا فاصلًا زمنيًا بينها. والمهم أن تصلح سبب الرفض قبل كل محاولة، وأن تحكم على نتيجتها بقيمة EINV_STATUS.
المراجع
- دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، ص12 وص98 وص100 وص101 وص104.
