يرسل برنامجك فاتورة إلى نظام الفوترة الوطني فيعود الرد وفيه القيمة SUBMITTED. هذه هي حالة SUBMITTED في نظام الفوترة الوطني، وهي النتيجة التي يُرسل كل ملف من أجلها، لأنها تعني أن الفاتورة قُبلت. لكن قبول الفاتورة لا ينهي عمل نظامك، فبعده خطوتان ينص عليهما الدليل التقني صراحة، أن تحفظ بيانات الفاتورة الأساسية، وأن تُظهر رمز QR على فاتورة البائع.
الجواب المختصر أن الدليل التقني الصادر عن دائرة ضريبة الدخل والمبيعات يصف القيمة SUBMITTED بأنها «تم اعتماد الفاتورة بنجاح»، ويطلب التحقق من وجود رمز QR في العنصر EINV_QR لاكتمال استلام الفاتورة واعتمادها، ثم إظهار الرمز على فاتورة البائع، وحفظ ID وUUID وQR Code وEINV_STATUS لكل فاتورة.
يشرح هذا المقال ما يعود في الرد مع هذه الحالة، وكيف تتأكد أن القبول اكتمل، وما الذي تحفظه وما الذي تعرضه، وما الذي لا يذكره الدليل عنها فلا يصح البناء عليه.
ما معنى حالة SUBMITTED في نظام الفوترة الوطني
يحمل رد النظام بعد كل إرسال عنصرًا اسمه EINV_STATUS، وله بحسب الدليل التقني (الإصدار 1.5، ص98) ثلاث قيم. والقيمة SUBMITTED أولاها، ووصفها في جدول الدليل «تم اعتماد الفاتورة بنجاح». ثم يشرحها الدليل تحت الجدول بهذا النص.
«أي أن الفاتورة موافق عليها من قبل نظام الفوترة الوطني ويتم إرجاع الـ QR CODE الخاص بالفاتورة المرسلة».
فالحالة تجمع في رد واحد أمرين، حكمًا على الفاتورة بأنها مقبولة، ورمزًا يعود معها. والقيمتان الأخريان تكملان الصورة. القيمة ALREADY_SUBMITTED تعني أن الفاتورة نفسها أُرسلت وقُبلت من قبل، ويعود معها رمز الفاتورة الأصلية، وشرحها في مقال حالة ALREADY_SUBMITTED في نظام الفوترة الوطني. أما NOT_SUBMITTED فهي حالة الرفض الوحيدة، وتعود فيها حقول الرمز والمعرّف ورقم الفاتورة فارغة، ولها مقال مستقل عن حالة NOT_SUBMITTED.
والفرق بين القيمتين الأوليين في التوقيت لا في النتيجة. فالقيمة SUBMITTED تخص أول إرسال مقبول للفاتورة، والقيمة ALREADY_SUBMITTED تخص إرسالًا لاحقًا للفاتورة نفسها بعد قبولها. وفي الحالتين أمامك فاتورة مقبولة ورمز تحفظه.
أين تقرأ نتيجة القبول في رد النظام
يسرد الدليل (ص97) عناصر ملف الاستجابة ووصف كل عنصر. والعناصر التي تهمك بعد القبول أربعة.
EINV_STATUS. يصفه الدليل بأنه «يوضح الحالة النهائية للفاتورة»، وهو العنصر الذي تحكم به على الفاتورة.EINV_QR. وصفه في الدليل «يحتوي على QR Code الخاص بالفاتورة».EINV_NUM. وصفه «رقم الفاتورة المرسل».EINV_INV_UUID. وصفه «الرقم الفريد العالمي للفاتورة (UUID)».
ويذكر الدليل في الصفحة نفسها ستة أغراض لملف الاستجابة، منها «معرفة ما إذا تم اعتماد الفاتورة أو رفضها»، واسترجاع رمز QR، واسترجاع الرقم الفريد للفاتورة، و«تمكين الأنظمة المرتبطة من معالجة نتيجة الإرسال بشكل آلي». فالرد مصمم ليقرأه برنامجك ويبني عليه خطوته التالية، لا ليُعرض على المستخدم كما هو.
وفي مثال الرد الذي يعرضه الدليل لهذه الحالة (ص98) تأتي نتيجة التحقق في العنصر EINV_RESULTS بالقيمة PASS، ومعها رسالة معلومات تقول إن الملف Complied with UBL 2.1 standards، وتأتي قائمتا التنبيهات والأخطاء فارغتين. وأمثلة الدليل توضيحية، فلا تنسخ قيمها في ملف فعلي.
وجود الرمز في EINV_QR شرط اكتمال القبول
تحت شرح القيمة SUBMITTED يضع الدليل ملاحظة باللون الأحمر، ثم يكررها في ملاحظاته التشغيلية (ص104).
«يجب التحقق من وجود رمز الاستجابة السريع QR CODE في العنصر EINV_QR ضمن ملف الاستجابة الصادر من نظام الفوترة الوطني لاكتمال عملية استلام الفاتورة واعتمادها من نظام الفوترة الوطني، كما يجب إظهار QR CODE رمز الاستجابة السريع على فاتورة البائع».
الشطر الأول من الملاحظة يجعل قراءة الرد فحصين لا فحصًا واحدًا. الأول أن تكون قيمة EINV_STATUS هي SUBMITTED، والثاني أن يحمل العنصر EINV_QR رمزًا فعلًا. فإن غاب الرمز، فنص الملاحظة لا يعدّ عملية الاستلام والاعتماد مكتملة. ولا يصف الدليل هذه الحالة بعينها ولا يذكر خطوة لمعالجتها، فلا تفترض لها حلًا لم يرد فيه. وللاستفسار عن حالة لا يغطيها الدليل، يحيل الدليل نفسه (ص104) إلى لجنة الدعم الفني لشؤون الفوترة في دائرة ضريبة الدخل والمبيعات.
والرمز يأتي من النظام لا من برنامجك. فالدائرة تعيده في الرد بعد قبول الفاتورة، ولا يولّده البرنامج المرتبط محليًا. لذلك لا معنى لأن يضع نظامك على الفاتورة رمزًا من عنده قبل وصول الرد. وشرح العنصر نفسه ومصدره في مقال مستقل عن رمز QR الصادر من الدائرة في العنصر EINV_QR.
إظهار رمز QR على فاتورة البائع
الشطر الثاني من الملاحظة نفسها يطلب «إظهار» الرمز على فاتورة البائع، ويرد الطلب نفسه في ص98 وص104. والفعل الوارد في نص الدليل هو الإظهار، أي أن يكون الرمز ظاهرًا على الفاتورة التي يصدرها البائع. ولا يحدد الدليل وسيلة الإظهار، ولا حجم الرمز ولا موضعه على الفاتورة ولا شكله، فلا تقرأ في النص اشتراطًا لم يرد فيه.
والعملي من هذا النص ثلاثة أمور.
- اعرض الرمز الذي عاد في الرد كما هو. لا يشرح الدليل بنية الرمز من الداخل، فلا تبنِه من جديد ولا تغيّر محتواه في نظامك.
- اربط الرمز بفاتورته. الرمز يخص فاتورة بعينها، فاحفظه مع رقم الفاتورة ومعرّفها الفريد حتى يظهر على الفاتورة الصحيحة في كل مرة تعرضها فيها.
- تحقق من الرمز بالطريقة التي يذكرها الدليل. التحقق بحسب الدليل (ص105) يتم بمسح الرمز من خلال تطبيق سند فقط، من خيار «التحقق من المستندات الرقمية». وخطوات ذلك في مقال التحقق من صحة الفاتورة الإلكترونية في الأردن.
ما الذي تحفظه بعد حالة SUBMITTED في نظام الفوترة الوطني
الإرشاد الخامس من إرشادات الدليل التشغيلية (ص104) عنوانه «تخزين البيانات الأساسية»، ونصه «يجب حفظ ID و UUID و QR Code و EINV_STATUS لضمان التتبع وإعادة الاسترجاع عند الحاجة».
والجدول الآتي يربط كل عنصر من الأربعة بموضعه وسبب حفظه كما يظهر من نصوص الدليل.
ويصف الدليل في ملاحظاته التشغيلية (ص104) رقم الفاتورة بأنه لا يقتصر على رقم ID وحده، بل يتكوّن من ID وUUID معًا مفتاحًا رئيسيًا (Primary Key). ولهذا يأتي العنصران الأولان في الجدول متلازمين، فحفظ أحدهما دون الآخر لا يكفي لتتبع الفاتورة. وتفصيل ذلك في مقال المعرّف الفريد UUID في نظام الفوترة الوطني.
وفي الدليل نصان آخران يتصلان بالحفظ، وإن لم يردا ضمن الإرشاد الخامس.
- رقم ID لكل سلعة. تقول الملاحظات التشغيلية (ص104) إنه «يجب الاحتفاظ برقم الـ ID الخاص بالسلعة عند إصدار فاتورة البيع، ليتم استخدامه لاحقًا في حال إجراء عمليات إرجاع الفاتورة»، لأن الاعتماد عليه يكون في مطابقة السلعة المرتجعة مع بيانات الفاتورة الأصلية.
- سجل الإرسال والردود. الإرشاد العاشر «تتبع العمليات (Audit Trail)» يطلب الاحتفاظ بسجل كامل لعمليات الإرسال والاستجابة وإعادة الإرسال.
والإرشادات العشر كلها مشروحة واحدًا واحدًا في مقال الإرشادات العشر لنظام الفوترة الوطني. أما حفظ هذه البيانات فشأن تقني يخص نظامك المرتبط، وهو غير مدة الاحتفاظ بالفواتير التي تنظمها المادة (8) من نظام تنظيم شؤون الفوترة والرقابة عليها. وتفصيل المدة في مقال الاحتفاظ بفواتير نظام الفوترة الوطني.
لماذا تحفظ الرمز من أول رد
يعلل الإرشاد الخامس الحفظ بأمرين، «التتبع» و«إعادة الاسترجاع عند الحاجة». والحاجة تظهر حين يضيع الرمز من نظامك بعد القبول. والطريقة التي يذكرها الدليل (ص99) لاستعادته هي إعادة إرسال الفاتورة بالرقم والمعرّف نفسيهما، فيعود الرد بالحالة ALREADY_SUBMITTED ومعه الرمز الأصلي.
لكن هذه الطريقة نفسها تقوم على أن المعرّف الفريد الأصلي محفوظ، لأن الدليل (ص99) يربط هذه الحالة بإرسال الفاتورة برقم ID والمعرّف UUID نفسيهما معًا. ولذلك يبدأ الحفظ بالمعرّف قبل الإرسال، ثم يكتمل بالرمز والحالة بعد وصول الرد. وخطوات الاستعادة مفصلة في مقال حالة ALREADY_SUBMITTED المذكور أعلاه.
الفاتورة الموقعة في العنصر EINV_SINGED_INVOICE
يحمل مثال الرد في حالة SUBMITTED (ص98) عنصرًا آخر هو EINV_SINGED_INVOICE، ويرد اسمه في الدليل بهذا الهجاء. وهذا العنصر يحمل الفاتورة الموقعة التي يعيدها النظام في الرد. فالدليل لا يطلب من المكلف أن يوقّع الفاتورة بنفسه، ولا يطلب منه شهادة رقمية، والنظام هو الذي يعيد الفاتورة موقعة.
وفي المقابل يقف الدليل عند هذا الحد. فهو لا يشرح بنية هذا العنصر ولا طريقة قراءته، كما لا يشرح بنية رمز QR من الداخل. ولا يذكر الإرشاد الخامس هذا العنصر ضمن البيانات التي يجب حفظها. لذلك لا تبنِ في نظامك منطقًا يفكّ محتوى العنصر أو يعتمد على بنيته، ما دام الدليل لا يشرحها. وفي حالة الرفض يعود هذا العنصر فارغًا مع الرمز والمعرّف ورقم الفاتورة.
احكم بقيمة EINV_STATUS لا برمز الاستجابة الفني
يصف الدليل (ص97) العنصر Response Status Code بأنه «يوضح نتيجة معالجة الطلب فنيًا»، ويصف EINV_STATUS بأنه «يوضح الحالة النهائية للفاتورة». والفرق بينهما هو ما ينص عليه الإرشاد الرابع «التعامل مع الاستجابة»، إذ يقول «لا يُعتمد على Status Code فقط، وإنما يجب الاعتماد على قيمة EINV_STATUS لتحديد حالة الفاتورة النهائية».
فالرمز 200 يعني أن الطلب استُلم وعولج فنيًا، ولا يكفي وحده لتعدّ الفاتورة مقبولة. والحكم بالقبول يأتي من القيمة SUBMITTED ومعها رمز في EINV_QR. وإن جاءت القيمة NOT_SUBMITTED، فسبب الرفض في EINV_MESSAGE ضمن قائمة الأخطاء، وطريقة قراءته في مقال خطأ 400 في نظام الفوترة الوطني. وللصورة الكاملة عن رموز الرد ورسائل الرفض اقرأ مقال أخطاء نظام الفوترة الوطني.
وفي تصميم البرنامج نفسه، يوصي الإرشاد السادس «إدارة الأخطاء» بتسجيل الأخطاء تفصيليًا في السجل الداخلي مع عرض رسالة مبسطة للمستخدم النهائي. وحالة القبول أولى بالتبسيط، فيكفي المستخدم أن يرى أن فاتورته قُبلت وأن رمزها ظاهر عليها.
ما لا تفعله بفاتورة قُبلت
بعد القبول تصبح الفاتورة سجلًا في النظام، وهذه أربعة تصرفات لا تدعمها نصوص الدليل.
- لا ترسلها بمعرّف جديد. إذا أرسلتها مرة أخرى، فبالرقم والمعرّف نفسيهما، فبهما تعود بالحالة ALREADY_SUBMITTED (ص99). ويطلب الإرشادان الثالث والثامن الأمر نفسه عند فشل الإرسال أو انقطاع الاتصال، دون توليد معرّف جديد.
- لا تغيّر بياناتها بعد إصدارها. الفاتورة الصادرة لا تُعدَّل، والتصحيح يتم بفاتورة إرجاع على الكميات.
- لا تضع عليها رمزًا من عندك. الرمز الذي تُظهره على فاتورة البائع هو الذي عاد في
EINV_QR، لا رمز يولّده نظامك. - لا تفك محتوى الرمز أو الفاتورة الموقعة. الدليل لا يشرح بنية أي منهما، فلا تبنِ عليها منطقًا في برنامجك.
قائمة فحص بعد قبول الفاتورة
إذا عادت الحالة SUBMITTED في رد النظام، فهذه أسئلة تمر عليها بالترتيب قبل أن تعدّ الفاتورة منتهية.
- هل قرأ نظامك قيمة
EINV_STATUSنفسها، لا رمز الاستجابة الفني وحده؟ - هل يحمل العنصر
EINV_QRرمزًا فعلًا؟ الدليل يربط اكتمال الاستلام والاعتماد بوجوده. - هل حُفظ رقم الفاتورة ID ومعرّفها الفريد UUID معًا؟
- هل حُفظ رمز QR وقيمة
EINV_STATUSمع الفاتورة نفسها؟ - هل يظهر الرمز على فاتورة البائع؟ الدليل يطلب إظهاره.
- هل حُفظ رقم ID لكل سلعة في الفاتورة؟ عليه تعتمد مطابقة أي إرجاع لاحق.
- هل سُجّل الإرسال والرد في سجل العمليات؟ هذا ما يطلبه الإرشاد العاشر.
كيف يتعامل قيود مع الفاتورة بعد قبولها
ما سبق عمل يقع على نظام المكلف المربوط بالنظام. ويعمل تكامل قيود مع نظام الفوترة الوطني على هذه الطبقة كما يلي.
- بناء الملف والمعرّف. يبني قيود ملف الفاتورة بصيغة UBL 2.1 مع المعرّف الفريد، ويرسله إلى نظام الفوترة الوطني دون أي تدخل يدوي.
- حالة كل فاتورة أمامك. تعيد الدائرة حالة الفاتورة ورسالة الخطأ، ويعرضها قيود في لوحة الحالة، ومنها «مرسلة» و«مرسلة مسبقًا» و«لم تُرسل» مع رسالة الخطأ.
- رمز QR من الدائرة. تصدر الدائرة الرمز بعد قبول الفاتورة، ويظهر على الفاتورة التي يصدرها قيود.
- إعادة إرسال بالمعرّف نفسه. تعرض لوحة الحالة الفواتير التي لم تُرسل وتحتاج إلى إعادة إرسال، وحين تعيد إرسال فاتورة منها تُرسل بالمعرّف UUID نفسه.
وإعادة الإرسال هنا خطوة تقوم بها أنت من لوحة الحالة. ولصورة أوسع عن النظام وطريقة ربط منشأتك به، اقرأ مقال نظام الفوترة الوطني الالكتروني، أو تعرّف على ما يقدمه قيود في نظام الفوترة الوطني.
فوترة إلكترونية ومحاسبة متكاملة في نظام واحد
قيود متكامل مع نظام الفوترة الوطني (JoFotara). تُصدر فاتورتك بالدينار الأردني من قيود فتُقيَّد في دفاترك تلقائيًا وتُرسل إلى النظام، وبعد قبولها يعود عليها رمز QR من دائرة ضريبة الدخل والمبيعات.
الأسئلة الشائعة
ما معنى حالة SUBMITTED في نظام الفوترة الوطني؟
تعني أن الفاتورة قُبلت. يصفها الدليل التقني لدائرة ضريبة الدخل والمبيعات بأنها «تم اعتماد الفاتورة بنجاح»، ويعيد النظام معها رمز QR الخاص بالفاتورة في العنصر EINV_QR.
هل تكفي قيمة SUBMITTED وحدها لاكتمال قبول الفاتورة؟
يطلب الدليل فحصًا ثانيًا معها. فعليك التحقق من وجود رمز QR في العنصر EINV_QR ضمن ملف الاستجابة، لأن الدليل يربط اكتمال استلام الفاتورة واعتمادها بوجود الرمز.
ما البيانات التي أحفظها بعد قبول الفاتورة؟
يطلب الإرشاد الخامس حفظ ID وUUID وQR Code وEINV_STATUS لضمان التتبع وإعادة الاسترجاع. ويطلب الدليل أيضًا الاحتفاظ برقم ID لكل سلعة لاستخدامه في الإرجاع، والاحتفاظ بسجل كامل لعمليات الإرسال والاستجابة.
هل يحدد الدليل طريقة إظهار رمز QR على الفاتورة؟
يطلب الدليل إظهار الرمز على فاتورة البائع فقط. ولا يحدد وسيلة الإظهار ولا حجم الرمز ولا موضعه على الفاتورة.
هل يولّد نظامي رمز QR بنفسه؟
لا يولّده نظامك. تعيد الدائرة الرمز في العنصر EINV_QR بعد قبول الفاتورة، والتحقق منه بحسب الدليل يتم من خلال تطبيق سند فقط.
ما العنصر EINV_SINGED_INVOICE في رد النظام؟
يحمل الفاتورة الموقعة التي يعيدها النظام في الرد، ويرد اسمه في الدليل بهذا الهجاء. ولا يشرح الدليل بنيته ولا طريقة قراءته، ويعود فارغًا في حالة الرفض.
المراجع
- دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، ص97 وص98 وص99 وص100 وص104 وص105.
