مرجع الفاتورة الأصلية في نظام الفوترة الوطني: BillingReference

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

الجواب المباشر أن الدليل التقني الصادر عن دائرة ضريبة الدخل والمبيعات يطلب في هذه الكتلة ثلاث قيم، كلها مأخوذة من الفاتورة الأصلية لا من فاتورة الإرجاع، وهي رقم الفاتورة الأصلية في cbc:ID، ومعرّفها الفريد في cbc:UUID، وقيمتها الإجمالية في cbc:DocumentDescription. والعنصران الأولان معًا هما المفتاح الذي يعرف به النظام أي فاتورة، فإذا لم يطابقا الفاتورة الأصلية فالمرجع يشير إلى فاتورة أخرى أو إلى لا شيء.

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

ما مرجع الفاتورة الأصلية في نظام الفوترة الوطني؟

فاتورة الإرجاع في نظام الفوترة الوطني هي الفاتورة التي تحمل في رأسها الرمز 381 في العنصر cbc:InvoiceTypeCode، وهي بلغة الدليل التقني فاتورة الإرجاع (إشعار دائن). والصورة الكاملة لهذا المستند، متى تصدره وما أثره، في مقال إشعار الدائن في نظام الفوترة الوطني. أما هذا المقال فيقف عند جزء واحد منه، وهو الجزء الذي يدل النظام على الفاتورة الأصلية.

يضع الدليل قبل قالب فاتورة الإرجاع (الإصدار 1.5، ص23) ملاحظة بثلاثة شروط لعملية الإرجاع. يسمح النظام بالإرجاع على الكميات فقط، ولا يسمح بتجاوز الكمية المباعة في الفاتورة الأصلية، ويسمح بإرسال فاتورة إرجاع على الفاتورة الأصلية مرة واحدة أو أكثر حتى تنتهي كمياتها. وحساب ما بقي من كل بند شرحناه في مقال إرجاع يتجاوز الكمية الأصلية في نظام الفوترة الوطني.

الشروط الثلاثة كلها تُقاس على «الفاتورة الأصلية». وكتلة المرجع هي الموضع الذي يسمّي فيه ملف الإرجاع تلك الفاتورة الأصلية. لهذا يأتي في القالب نفسه، تحت عنوان «معلومات فاتورة الأرجاع والفاتورة المراد الارجاع منها»، رأس فاتورة الإرجاع أولًا، ثم كتلة cac:BillingReference بعد عنصري العملة وقبل كتلة عداد الفاتورة ICV، كما يظهر في الصورة أعلاه.

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

العناصر الثلاثة في BillingReference وما يساويه كل منها

يشرح الدليل في جدول عناصر فاتورة الإرجاع (ص24) كل قيمة من القيم الثلاث بعبارة قصيرة. وهذه العبارات هي المرجع الذي تبني عليه برنامجك، لأنها تحدد مصدر كل قيمة بوضوح. فكلها تنتهي بعبارة «الفاتورة الاصلية المراد الارجاع منها».

اللافت في الجدول أن الدليل لا يطلب في كتلة المرجع أي قيمة تخص فاتورة الإرجاع نفسها. فكل ما في الكتلة صورة من الفاتورة الأصلية. وكل ما يخص الإرجاع (رقمه ومعرّفه وتاريخه وكمياته ومجاميعه) مكانه خارج الكتلة.

رقمان ومعرّفان في ملف واحد: رأس الإرجاع وكتلة المرجع

أكثر ما يربك من يبني ملف فاتورة الإرجاع أول مرة أن العنصرين cbc:ID وcbc:UUID يظهران فيه مرتين، مرة في رأس الملف ومرة داخل كتلة المرجع، ولكل ظهور معنى مختلف.

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

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

ويترتب على ذلك أمر عملي عند فشل الإرسال. يوصي الدليل في إرشاداته (ص104) بإعادة الإرسال بالرقم والمعرّف نفسيهما دون توليد معرّف جديد. وفي فاتورة الإرجاع يعني هذا أن تعيد الإرسال برقم فاتورة الإرجاع ومعرّفها كما هما في رأسها، وأن تبقى كتلة المرجع تشير إلى الفاتورة الأصلية نفسها دون تغيير.

القيمة الإجمالية في DocumentDescription: إجمالي الفاتورة الأصلية لا إجمالي الإرجاع

العنصر الثالث هو الذي يحتاج إلى انتباه أكثر، لأن اسمه لا يدل على محتواه. فكلمة Description توحي بنص وصفي، لكن الدليل يجعله حاملًا لـ«القيمة الاجمالية للفاتورة الاصلية المراد الارجاع منها».

وفي ملف فاتورة الإرجاع رقمان إجماليان مختلفان، ولكل منهما موضعه.

• مجاميع فاتورة الإرجاع في كتلة cac:LegalMonetaryTotal الخاصة بها. ينص الدليل على أنها تغطي «الجزء المراد ارجاعه» فقط، وأن ضريبتها هي «مجموع قيم الضريبة المراد ارجاعها من الفاتورة».
• إجمالي الفاتورة الأصلية في cbc:DocumentDescription داخل كتلة المرجع، كما هو في الفاتورة الأصلية.

فإذا بيعت بضاعة بفاتورة إجماليها 500.000 دينار، وأُرجع منها ما قيمته 120.000 دينار، فمجاميع فاتورة الإرجاع تُبنى على 120.000، وكتلة المرجع تحمل 500.000. والأرقام هنا توضيح من إعدادنا، لا مثال من الدليل.

وتبقى ثلاث مسائل حول هذا العنصر نعرضها كما هي في الدليل، مع فصل ما هو نص عما هو قراءتنا.

1. في الإرجاع الجزئي المتكرر. يسمح الدليل بأكثر من فاتورة إرجاع على الفاتورة الأصلية نفسها، ووصف العنصر في كل القوالب هو القيمة الإجمالية للفاتورة الأصلية. ولا يذكر الدليل رصيدًا متبقيًا ولا قيمة بعد خصم ما أُرجع سابقًا. وقراءتنا لهذا النص أن القيمة نفسها تتكرر في كل فاتورة إرجاع على الفاتورة ذاتها.
2. أي مجموع من مجاميع الفاتورة الأصلية. لا يسمي الدليل عنصرًا بعينه من كتلة cac:LegalMonetaryTotal في الفاتورة الأصلية. لكن معادلاته تجعل TaxInclusiveAmount وPayableAmount كليهما مساويًا لـSum(RoundingAmount)، أي أنهما في الفاتورة الأصلية قيمة واحدة. والأقرب في قراءتنا أن «القيمة الإجمالية» هي هذه القيمة، وهي قراءة لا نص صريح فيها.
3. العملة. فاتورة الإرجاع تأخذ رمز العملة نفسه الذي في الفاتورة الأصلية، بحسب الدليل. فالإجمالي في كتلة المرجع والمبالغ في فاتورة الإرجاع تأتي بعملة واحدة هي عملة الفاتورة الأصلية.

من أين يأخذ نظامك قيم مرجع الفاتورة الأصلية

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

يطلب الدليل في الإرشاد الخامس من إرشاداته العشر (ص104) تخزين البيانات الأساسية لكل فاتورة، وهي الرقم ID والمعرّف UUID ورمز الاستجابة السريع وحالة الفاتورة EINV_STATUS، لأغراض التتبع وإعادة الاسترجاع. ويعيد النظام في رده على كل فاتورة مقبولة رقمها في EINV_NUM ومعرّفها في EINV_INV_UUID. فالعنصران الأولان في كتلة المرجع يأتيان من هذا السجل المحفوظ.

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

1. اختر الفاتورة الأصلية من سجلاتك، وهي فاتورة قُبلت وعاد ردها برقمها ومعرّفها. فالرد على الفاتورة المرفوضة يأتي فيه الرقم والمعرّف ورمز الاستجابة السريع بقيمة null بحسب الدليل.
2. انسخ رقمها ومعرّفها كما حُفظا إلى cbc:ID وcbc:UUID داخل الكتلة، دون إعادة كتابة أو تنسيق.
3. انسخ إجماليها إلى cbc:DocumentDescription من مجاميع الفاتورة الأصلية، لا من مجاميع الإرجاع.
4. ولّد لفاتورة الإرجاع رقمًا ومعرّفًا جديدين لرأسها، واحفظهما قبل أول محاولة إرسال.

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

ما ينتقل أيضًا من الفاتورة الأصلية إلى فاتورة الإرجاع

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

ويضاف إلى ذلك سبب الإرجاع، وهو إجباري في كل فاتورة إرجاع ويُكتب نصًا حرًا في كتلة مستقلة، ونتناوله في مقال مستقل عن سبب الإرجاع ضمن هذه السلسلة. أما رقم البند فالدليل يوصي بالاحتفاظ به من فاتورة البيع لأن الإرجاع يُطابَق عليه، وقاعدة تفرّده داخل الفاتورة مشروحة في مقال رسالة The ID number must be unique في نظام الفوترة الوطني.

لا تنسخ أمثلة الإرجاع الواردة في الدليل التقني

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

• مثال فاتورة إرجاع الدخل (ص24 و25). يلاحظ في المثال أن cbc:DocumentDescription يحمل 64.000، بينما إجمالي فاتورة الدخل الأصلية في مثال الدليل 109.000.
• مثال فاتورة إرجاع المبيعات العامة (ص47). يشير المثال إلى معرّف فريد يختلف عن معرّف الفاتورة الأصلية في مثالها.
• مثال فاتورة إرجاع المبيعات الخاصة (ص74). ينقل المثال رأس فاتورة إرجاع المبيعات العامة كما هو.

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

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>ORIGINAL_INVOICE_ID</cbc:ID>
    <cbc:UUID>ORIGINAL_INVOICE_UUID</cbc:UUID>
    <cbc:DocumentDescription>ORIGINAL_INVOICE_TOTAL</cbc:DocumentDescription>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

الأسماء الثلاثة بالأحرف الكبيرة ليست قيمًا تُرسل، بل تدل على ما يوضع مكانها، وكلها من الفاتورة الأصلية.

إذا رُفضت فاتورة الإرجاع: ما يوثقه الدليل وما لا يوثقه

لا يوثق الدليل رسالة بعينها لخطأ في كتلة المرجع. فلا نجد في قائمة الأخطاء التي يوردها (ص101 و102) رسالة تذكر رقم الفاتورة الأصلية أو معرّفها أو إجماليها. لذلك لا نستطيع أن نقول لك ما النص الذي سيظهر لو اختلفت قيمة في الكتلة عن الفاتورة الأصلية، ولا أن نقول هل يرفض النظام الفاتورة في كل حالة اختلاف.

ما يوثقه الدليل هو طريقة قراءة النتيجة. فالحكم على الفاتورة يكون من حالة الفاتورة في EINV_STATUS لا من رمز الحالة (Status Code) وحده، وحين تُرفض تكون الحالة NOT_SUBMITTED وتظهر تفاصيل الخطأ في EINV_MESSAGE. فإذا رُفضت فاتورة إرجاع، فهذه خطوات المراجعة بترتيبها.

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

وإذا بقي الرفض دون سبب واضح بعد هذه المراجعة، فالدليل يحيل الاستفسارات إلى لجنة الدعم الفني لشؤون الفوترة في دائرة ضريبة الدخل والمبيعات عبر موقعها istd.gov.jo.

كيف يتعامل قيود مع فواتير الإرجاع

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

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

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

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

ما مرجع الفاتورة الأصلية في نظام الفوترة الوطني؟

يقصد به كتلة cac:BillingReference في ملف فاتورة الإرجاع، وداخلها cac:InvoiceDocumentReference. يضع فيها نظام البائع رقم الفاتورة الأصلية ومعرّفها الفريد وقيمتها الإجمالية، ليعرف نظام الفوترة الوطني الفاتورة التي يُرجع منها.

هل أضع رقم فاتورة الإرجاع في كتلة المرجع؟

لا تضعه فيها. كتلة المرجع تحمل رقم الفاتورة الأصلية ومعرّفها، أما رقم فاتورة الإرجاع ومعرّفها الجديدان فمكانهما رأس فاتورة الإرجاع.

ما القيمة التي توضع في DocumentDescription؟

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

هل تتغير القيمة في DocumentDescription عند الإرجاع الجزئي للمرة الثانية؟

لا يذكر الدليل التقني رصيدًا متبقيًا في هذا العنصر، ووصفه في كل القوالب هو القيمة الإجمالية للفاتورة الأصلية. وقراءتنا أن القيمة نفسها تتكرر في كل فاتورة إرجاع على الفاتورة ذاتها.

ما رسالة الخطأ التي تظهر إذا كان مرجع الفاتورة الأصلية خاطئًا؟

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

هل يمكنني نسخ مثال فاتورة الإرجاع من الدليل التقني؟

لا تنسخه. أمثلة الإرجاع في الدليل (ص24 و25 وص47 وص74) لا تتطابق مع فواتيرها الأصلية، فمثال الدخل مثلًا يحمل إجماليًا مختلفًا عن إجمالي الفاتورة الأصلية. ابنِ الكتلة من القالب وخذ القيم من سجلك.

المراجع

• دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، ص12 وص23 إلى ص26 وص47 وص74 وص100 إلى ص102 وص104 إلى ص107.