ترسل فاتورة إلى نظام الفوترة الوطني فيعود الرد بقيمة لم تتوقعها في حقل الحالة. ليست SUBMITTED التي تعني القبول، ولا NOT_SUBMITTED التي تعني الرفض، بل قيمة ثالثة هي حالة ALREADY_SUBMITTED في نظام الفوترة الوطني. وأول ما يجب أن تعرفه عنها أنها ليست خطأ ولا رفضًا، فهي تعني أن الفاتورة نفسها سبق أن أُرسلت وقُبلت.
الجواب المختصر أن الدليل التقني الصادر عن دائرة ضريبة الدخل والمبيعات يصف هذه الحالة بأنها «الفاتورة معتمدة مسبقًا»، ويذكر أنها تظهر عند إرسال الفاتورة مرة أخرى برقمها ID ومعرّفها الفريد UUID نفسيهما، وأن النظام يعيد معها رمز الاستجابة السريعة QR الخاص بالفاتورة الأصلية. ولهذا تصلح الحالة طريقًا موثقًا لاستعادة رمز لم يحفظه نظامك عند الإرسال الأول.
يشرح هذا المقال موقع الحالة بين قيم الرد الثلاث، ولماذا تظهر عند إعادة الإرسال، وكيف تستعيد بها رمز QR خطوة خطوة، وما الذي لا يذكره الدليل عنها فلا يصح البناء عليه.
ما معنى حالة ALREADY_SUBMITTED في نظام الفوترة الوطني
يحمل رد النظام بعد كل إرسال عنصرًا اسمه EINV_STATUS، ويصفه الدليل التقني (الإصدار 1.5، ص98) بأن له ثلاث قيم. ويعرّف الدليل القيمة ALREADY_SUBMITTED في الصفحة التالية (ص99) بهذا النص.
«أي أن الفاتورة مرسلة سابقًا إلى نظام الفوترة الوطني ويتم إرجاع الـ QR CODE الخاص بالفاتورة المرسلة سابقًا في هذه الحالة».
ثم يضيف الدليل ملاحظتين تحت التعريف، الأولى عن سبب الحالة والثانية عن فائدتها.
- السبب. «هذه الحالة تتم عندما يتم إرسال الفاتورة بنفس رقم الـ ID والـ UUID معًا مرة أخرى إلى نظام الفوترة الوطني».
- الفائدة. «تتيح هذه الحالة للمكلف إمكانية استرجاع رمز الاستجابة السريعة (QR Code) الخاص بالفاتورة التي تم إرسالها مسبقًا، في حال تعذّر حفظه أو تخزينه عند الإرسال الأول».
من هذين النصين تخرج بثلاث نتائج عملية. الأولى أن الفاتورة التي تحمل هذه الحالة مقبولة من قبل، فلا شيء فيها يحتاج إلى إصلاح. والثانية أن النظام لم ينشئ فاتورة جديدة، بل تعرّف على فاتورة موجودة. والثالثة أن الرد يحمل رمز QR الأصلي، وهو ما قد تحتاجه إذا ضاع الرد الأول.
القيم الثلاث للحالة وأين تقع ALREADY_SUBMITTED بينها
يضع الدليل القيم الثلاث في جدول واحد، ووصفه لكل قيمة قصير. والجدول الآتي يجمع وصف الدليل مع ما يعود في الرد في كل حالة، كما يذكره الدليل في صفحات الرد.
مرِّر الجدول أفقيًا لعرض بقية الأعمدة
الفرق بين الحالتين الأوليين في التوقيت لا في النتيجة. ففي الحالتين الفاتورة مقبولة ورمزها متاح، لكن SUBMITTED تخص أول إرسال مقبول، وALREADY_SUBMITTED تخص إرسالًا لاحقًا للفاتورة نفسها. أما NOT_SUBMITTED فهي وحدها حالة الرفض، وطريقة قراءة أسبابها في مقال خطأ 400 في نظام الفوترة الوطني. وللصورة الكاملة عن رموز الرد ورسائل الرفض اقرأ مقال أخطاء نظام الفوترة الوطني.
لماذا تظهر الحالة عند إعادة الإرسال بنفس ID وUUID
يعرف النظام الفاتورة بقيمتين معًا، رقم الفاتورة في الحقل cbc:ID والمعرّف الفريد في الحقل cbc:UUID. ويصف الدليل التقني (ص12) القيمتين بأنهما تشكلان معًا مفتاحًا رئيسيًا «لعدم تكرار الفاتورة المرسلة على النظام». فإذا وصل إلى النظام الزوج نفسه مرة ثانية، لم يعامله على أنه فاتورة جديدة، بل ردّ بأن الفاتورة معتمدة مسبقًا. وشرح المفتاح المركّب ومن يولّد المعرّف في مقال المعرّف الفريد UUID في نظام الفوترة الوطني.
وإعادة الإرسال بالزوج نفسه ليست تصرفًا خاطئًا يجب تجنبه، بل هي ما يطلبه الدليل نفسه. ففي إرشاداته التشغيلية (ص104) نصّان يقودان إلى هذه الحالة مباشرة.
- الإرشاد الثالث، إدارة إعادة الإرسال. «عند فشل الإرسال يجب إعادة الإرسال باستخدام نفس ID و UUID لتجنب إنشاء فاتورة جديدة أو تكرار البيانات».
- الإرشاد الثامن، معالجة الانقطاع. «عند حدوث Timeout أو فشل اتصال يجب إعادة المحاولة دون توليد UUID جديد».
تخيّل الموقف الذي يجمع الإرشادين. يرسل برنامجك الفاتورة، فتصل إلى النظام وتُقبل، لكن الاتصال ينقطع قبل أن يصل الرد إلى برنامجك. من جهتك لا تعرف ما حدث، فتعيد الإرسال بالرقم والمعرّف نفسيهما كما يطلب الدليل. هنا يعود الرد بالحالة ALREADY_SUBMITTED، ومعه الرمز الذي فاتك في المحاولة الأولى. أما أسباب تعذّر الوصول إلى النظام أصلًا فلها مقال مستقل هو خطأ 504 في نظام الفوترة الوطني.
ولو أن برنامجك ولّد معرّفًا جديدًا في المحاولة الثانية، لما ظهرت هذه الحالة، لأن الزوج لم يعد هو الزوج الأول. وهذا تحديدًا ما يحذّر منه الدليل حين يطلب إعادة المحاولة دون توليد معرّف جديد. ويجمع مقال الإرشادات العشر لنظام الفوترة الوطني هذه النصوص كلها في مكان واحد.
كيف تستعيد رمز QR لفاتورة لم تحفظ رمزها
الطريقة التي يذكرها الدليل لاستعادة الرمز هي الحالة نفسها. فالملاحظة الثانية في ص99 تقول إن الحالة تتيح للمكلف استرجاع الرمز «في حال تعذّر حفظه أو تخزينه عند الإرسال الأول». والخطوات العملية المبنية على نصوص الدليل كما يلي.
- اعثر على رقم الفاتورة ومعرّفها الفريد كما أُرسلا أول مرة. الاستعادة تقوم على الزوج نفسه، فإن لم يكن المعرّف الأصلي محفوظًا فلن يتعرف النظام على الفاتورة به.
- أعد إرسال الفاتورة بالرقم والمعرّف نفسيهما. لا تولّد معرّفًا جديدًا، ولا تغيّر رقم الفاتورة.
- اقرأ قيمة
EINV_STATUSفي الرد. إذا كانتALREADY_SUBMITTEDفالفاتورة مقبولة من قبل، والرمز في الرد هو رمزها الأصلي. - احفظ الرمز الذي عاد في
EINV_QR. ينص الإرشاد الخامس، «تخزين البيانات الأساسية»، على أنه «يجب حفظ ID و UUID و QR Code و EINV_STATUS لضمان التتبع وإعادة الاسترجاع عند الحاجة». - أظهر الرمز على فاتورة البائع. يطلب الدليل (ص98 وص104) إظهار رمز QR على فاتورة البائع، ولا تُعد الفاتورة مستلمة ومقبولة إلا بوجود الرمز في
EINV_QR.
وإذا عاد الرد في الخطوة الثالثة بقيمة SUBMITTED لا ALREADY_SUBMITTED، فالفاتورة اعتُمدت بهذا الإرسال نفسه، وهذا ما يعنيه وصف الدليل للقيمة «تم اعتماد الفاتورة بنجاح». والنتيجة العملية واحدة، فلديك الآن رمز تحفظه.
ولا يشرح الدليل بنية رمز QR من الداخل، فلا تحاول بناءه أو تعديله في نظامك. والتحقق من الرمز بحسب الدليل (ص105) يتم من خلال تطبيق سند فقط، من خيار «التحقق من المستندات الرقمية».
احكم بقيمة EINV_STATUS لا برمز الاستجابة الفني
ينص الإرشاد الرابع في الدليل، «التعامل مع الاستجابة»، على أنه «لا يُعتمد على Status Code فقط، وإنما يجب الاعتماد على قيمة EINV_STATUS لتحديد حالة الفاتورة النهائية». وهذا الإرشاد مهم هنا تحديدًا لسببين.
- الدليل لا يذكر رمز الاستجابة الفني الذي يرافق هذه الحالة. يذكر الدليل أن رمز الاستجابة في حالة الرفض ليس 200، لكنه لا يحدد الرمز الذي يصاحب
ALREADY_SUBMITTED. لذلك لا تبنِ منطق برنامجك على رقم بعينه في هذه الحالة. - الحكم على الفاتورة يأتي من الحالة. برنامج يقرأ رمز الاستجابة وحده قد يخطئ في تصنيف الفاتورة. أما برنامج يقرأ
EINV_STATUSفيعرف أنALREADY_SUBMITTEDفاتورة مقبولة.
وفي تصميم البرنامج نفسه، يوصي الإرشاد السادس، «إدارة الأخطاء»، بتسجيل الأخطاء تفصيليًا في السجل الداخلي مع عرض رسالة مبسطة للمستخدم النهائي. وبما أن ALREADY_SUBMITTED ليست خطأ، فالأنسب أن يراها المستخدم حالة قبول سابق، لا تنبيه رفض.
ما الذي لا تعنيه حالة ALREADY_SUBMITTED
لأن الحالة تبدو غير مألوفة، يسهل أن تُقرأ على غير معناها. وهذه ثلاث قراءات لا يدعمها الدليل.
- ليست رفضًا ولا خطأ. الرفض في الدليل حالة واحدة هي
NOT_SUBMITTED. أماALREADY_SUBMITTEDفوصفها «الفاتورة معتمدة مسبقًا». - ليست فاتورة ثانية. النظام يعيد رمز الفاتورة المرسلة سابقًا، ولا يذكر الدليل إنشاء فاتورة جديدة في هذه الحالة.
- ليست طريقًا لتغيير فاتورة مقبولة. الفاتورة بعد إصدارها لا تُعدّل، والتصحيح يتم بفاتورة إرجاع على الكميات. ولا يصف الدليل ما يحدث إذا أُرسل الزوج نفسه بمحتوى مختلف، فلا تعتمد على إعادة الإرسال لتغيير أي بيان في فاتورة قُبلت.
ملاحظة على مثال الرد في ص100
يعرض الدليل في ص100 مثالًا لرد النظام تحت عنوان «في حالة الALREADY_SUBMITTED»، لكن المثال نفسه يحمل القيمة NOT_SUBMITTED. فإذا رجعت إلى الدليل لتعرف شكل الرد في هذه الحالة، فاعتمد على التعريف والمثال في ص99، وفيه القيمة ALREADY_SUBMITTED فعلًا ومعها رمز QR، وعلى الجدول في ص98، ولا تأخذ ذلك المثال نموذجًا لرد ALREADY_SUBMITTED. وأمثلة الدليل عمومًا توضيحية، فلا تنسخها في ملف فعلي.
قائمة فحص سريعة عند ظهور الحالة
إذا ظهرت لك ALREADY_SUBMITTED في رد النظام، فهذه أسئلة تمر عليها بالترتيب.
- هل أُرسلت الفاتورة بالرقم والمعرّف الفريد نفسيهما في محاولة سابقة؟ إن كان الجواب نعم فالحالة متوقعة.
- هل رمز QR لهذه الفاتورة محفوظ في نظامك؟ إن لم يكن، فاحفظ الرمز الذي عاد في الرد الآن.
- هل يظهر الرمز على فاتورة البائع؟ الدليل يطلب إظهاره.
- هل تُسجَّل الحالة في نظامك قبولًا سابقًا لا رفضًا؟ إن صنّفها برنامجك خطأ، فراجع منطق قراءة الرد.
- هل يحفظ نظامك المعرّف الفريد قبل كل إرسال؟ من دون ذلك لن تتمكن من استعادة الرمز بهذه الطريقة لاحقًا.
- هل يسجل نظامك كل إرسال ورد وإعادة إرسال؟ هذا ما يطلبه الإرشاد العاشر «تتبع العمليات (Audit Trail)»، وهو ما يكشف لك أن الفاتورة قُبلت من قبل.
كيف يتعامل قيود مع حالة الفاتورة وإعادة إرسالها
ما سبق عمل يقع على نظام المكلف المربوط بالنظام. ويعمل تكامل قيود مع نظام الفوترة الوطني على هذه الطبقة كما يلي.
- بناء الملف والمعرّف. يبني قيود ملف الفاتورة بصيغة UBL 2.1 مع المعرّف الفريد، ويرسله إلى نظام الفوترة الوطني دون أي تدخل يدوي.
- حالة كل فاتورة أمامك. تعيد الدائرة حالة الفاتورة ورسالة الخطأ، ويعرضها قيود في لوحة الحالة، ومنها «مرسلة» و«مرسلة مسبقًا» و«لم تُرسل» مع رسالة الخطأ.
- إعادة إرسال بالمعرّف نفسه. تعرض لوحة الحالة الفواتير التي لم تُرسل وتحتاج إلى إعادة إرسال، وحين تعيد إرسال فاتورة منها تُرسل بالمعرّف UUID نفسه.
وإعادة الإرسال هنا خطوة تقوم بها أنت من لوحة الحالة. أما رمز QR فتصدره الدائرة بعد قبول الفاتورة، ويظهر على الفاتورة التي يصدرها قيود. ولصورة أوسع عن النظام وطريقة ربط منشأتك به، اقرأ مقال نظام الفوترة الوطني الالكتروني، أو تعرّف على ما يقدمه قيود في نظام الفوترة الوطني.
فوترة إلكترونية ومحاسبة متكاملة في نظام واحد
قيود متكامل مع نظام الفوترة الوطني (JoFotara). تُصدر فاتورتك بالدينار الأردني من قيود فتُقيَّد في دفاترك تلقائيًا وتُرسل إلى النظام، وبعد قبولها يعود عليها رمز QR من دائرة ضريبة الدخل والمبيعات.
الأسئلة الشائعة
ما معنى حالة ALREADY_SUBMITTED في نظام الفوترة الوطني؟
تعني أن الفاتورة أُرسلت من قبل وقُبلت. يصفها الدليل التقني لدائرة ضريبة الدخل والمبيعات بأنها «الفاتورة معتمدة مسبقًا»، ويعيد النظام معها رمز QR الخاص بالفاتورة المرسلة سابقًا.
هل حالة ALREADY_SUBMITTED خطأ أو رفض للفاتورة؟
لا تُعد خطأ ولا رفضًا. حالة الرفض في الدليل هي NOT_SUBMITTED وحدها، أما ALREADY_SUBMITTED فتعني أن الفاتورة مقبولة من إرسال سابق.
متى تظهر حالة ALREADY_SUBMITTED؟
تظهر حين تُرسل الفاتورة مرة أخرى برقمها ID ومعرّفها الفريد UUID معًا، كما في إعادة الإرسال بعد انقطاع الاتصال. ويطلب الدليل إعادة الإرسال بالقيمتين نفسيهما دون توليد معرّف جديد.
كيف أستعيد رمز QR لفاتورة لم أحفظ رمزها؟
أعد إرسال الفاتورة برقمها ومعرّفها الفريد الأصليين. إذا كانت مقبولة من قبل يعود الرد بالحالة ALREADY_SUBMITTED ومعه الرمز الأصلي في الحقل EINV_QR، فتحفظه وتظهره على فاتورة البائع.
ما رمز الاستجابة الفني الذي يرافق حالة ALREADY_SUBMITTED؟
لا يذكره الدليل التقني. ولهذا يطلب الدليل الحكم على الفاتورة بقيمة EINV_STATUS لا برمز الاستجابة الفني وحده.
هل تغيّر إعادة الإرسال بالرقم والمعرّف نفسيهما بيانات فاتورة مقبولة؟
لا تعتمد على ذلك. الفاتورة بعد إصدارها لا تُعدّل، والتصحيح يتم بفاتورة إرجاع على الكميات، ولا يصف الدليل ما يحدث إذا أُرسل الزوج نفسه بمحتوى مختلف.
المراجع
- دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، ص12 وص98 وص99 وص100 وص104 وص105.
