سبب الإرجاع في نظام الفوترة الوطني: عنصر PaymentMeans

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

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

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

سبب الإرجاع في نظام الفوترة الوطني: ما يشترطه الدليل التقني

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

تتكون الكتلة في الدليل من ثلاثة عناصر متداخلة. الوعاء الخارجي cac:PaymentMeans، وبداخله الرمز cbc:PaymentMeansCode بالقيمة 10 والسمة listID="UN/ECE 4461"، ثم cbc:InstructionNote الذي يحمل نص السبب. ويعرض الدليل تحت البنية مثالًا للنص المكتوب هو «تم الإرجاع بسبب خلل في المنتج».

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

تترتب على هذه القراءة نتيجتان عمليتان:

• الرمز 10 لا يُختار. لا يذكر الدليل قيمة أخرى للعنصر cbc:PaymentMeansCode، ولا يشرح دلالة القائمة UN/ECE 4461. فاكتب القيمة 10 والسمة كما وردتا، ولا تضع مكانهما قيمة من خارج الدليل.
• النص هو الجزء الذي يتغير. كل فاتورة إرجاع تحمل سببها الخاص في cbc:InstructionNote، ولا يُترك هذا العنصر فارغًا.

وبهذا الشكل تبدو الكتلة في ملف فاتورة إرجاع، بنص سبب توضيحي من عندنا:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode listID="UN/ECE 4461">10</cbc:PaymentMeansCode>
  <cbc:InstructionNote>إرجاع وحدتين من البند 2 لعيب في التصنيع</cbc:InstructionNote>
</cac:PaymentMeans>

السطران الأولان والسطر الأخير كما في الدليل، والنص بين وسمي cbc:InstructionNote مثال من صياغتنا. وموضع الكتلة بين بقية عناصر الملف يُؤخذ من قالب فاتورة الإرجاع في الدليل نفسه.

لماذا لا يحمل PaymentMeans طريقة الدفع

كلمة PaymentMeans تعني حرفيًا «وسيلة الدفع». لذلك يتوقع المطور أو المحاسب أن يجد فيها ما يميز الفاتورة النقدية من فاتورة الذمم. لكن الدليل لا يستخدم العنصر لهذا الغرض، ويضع طريقة الدفع في رمز من ثلاث خانات تحمله السمة name في عنصر نوع الفاتورة cbc:InvoiceTypeCode.

يقرأ النظام من هذا الرمز ثلاث معلومات. الخانة الأولى لنوع الفاتورة (محلية، تصدير، مناطق تنموية، ترانزيت، تجارة خارجية، تنازل داخل المناطق الحرة). والخانة الثانية لطريقة الدفع، 1 للنقدي و2 للذمم. والخانة الثالثة لفئة الضريبة، 1 للدخل و2 للمبيعات العامة و3 للمبيعات الخاصة.

ويظهر ذلك في جدول رموز فاتورة الدخل أعلاه. الفاتورة المحلية النقدية رمزها 011، والمحلية بالذمم رمزها 021. الفرق بينهما في الخانة الوسطى وحدها، ولا علاقة له بالعنصر cac:PaymentMeans.

أما في فاتورة الإرجاع، فيصف الدليل السمة name بأنها «للدلالة على طريقة الدفع (نقدي، ذمم) ونوع الفاتورة»، ويجعل قيمة العنصر 381 للدلالة على أنها فاتورة إرجاع. وينص على أنه «يتم اختيار نوع فاتورة الإرجاع حسب النوع المختار في الفاتورة الأصلية»، وأن ذلك ينطبق على العملة أيضًا.

فإذا كانت الفاتورة الأصلية فاتورة دخل محلية بالذمم، حملت فاتورة الإرجاع الرمز نفسه 021 مع القيمة 381. وطريقة الدفع في الإرجاع إذن منقولة من الفاتورة الأصلية عبر هذا الرمز، لا من عنصر السبب. وإذا اختلف الرمز عما يسمح به تسجيل المكلف، فالرسالة الموثقة لذلك مشروحة في مقال رسالة This user is not authorized to submit this type of invoice.

وتنتج عن هذا الفصل قاعدتان في التعامل مع العنصر:

• لا تبحث عن طريقة الدفع في PaymentMeans. إن احتاج نظامك أن يعرف هل الإرجاع نقدي أم ذمم، فالمرجع هو الخانة الثانية من رمز الفاتورة.
• لا تنقل العنصر إلى الفاتورة الجديدة اجتهادًا. يوثق الدليل العنصر cac:PaymentMeans في فاتورة الإرجاع وحدها، ولا يتناول وروده في الفاتورة الجديدة ذات القيمة 388. فالتزم بقالب كل نوع كما ورد.

السبب في InstructionNote لا في Note

يحمل رأس الفاتورة في نظام الفوترة الوطني عنصرًا آخر للنص الحر هو cbc:Note، وقد يبدو مكانًا مناسبًا لكتابة السبب. لكن الدليل يفصل بين العنصرين بوضوح:

• cbc:InstructionNote هو مكان سبب الإرجاع، وهو إجباري في كل فاتورة إرجاع.
• cbc:Note ملاحظة عامة اختيارية. وهو باقٍ في رأس إرجاع فاتورة الدخل اختياريًا، ولا يظهر أصلًا في رأس إرجاع فاتورة ضريبة المبيعات العامة ولا فاتورة الضريبة الخاصة.

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

كيف تكتب سببًا واضحًا (اقتراح من قيود)

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

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

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

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

السبب واحد من عدة شروط تجتمع في فاتورة الإرجاع (إشعار دائن) قبل أن تُقبل. ويحسن أن تراه في سياقها:

• النوع. قيمة cbc:InvoiceTypeCode هي 381، مع رمز name والعملة كما في الفاتورة الأصلية.
• المرجع. عنصر cac:BillingReference يحمل رقم الفاتورة الأصلية ومعرّفها الفريد وإجماليها. وهذه الكتلة يشرحها مقال «مرجع الفاتورة الأصلية في نظام الفوترة الوطني» من السلسلة نفسها.
• السبب. الكتلة cac:PaymentMeans بالرمز 10 ونص السبب.
• المشتري. ينص الدليل على أنه «يجب أن تتوافق بيانات المشتري في فاتورة الإرجاع مع بياناته في فاتورة البيع الأصلية المرتبطة بها».
• البنود. الإرجاع على الكميات فقط، ورقم البند ووصفه وسعر وحدته كما في الفاتورة الأصلية، والكمية لا تتجاوز المباع. وحساب الكمية المتبقية عبر أكثر من إرجاع في مقال إرجاع يتجاوز الكمية الأصلية في نظام الفوترة الوطني.
• المجاميع. تغطي الجزء المراد إرجاعه وحده، والخصم في الإرجاع الجزئي جزء من خصم البند حسب الكمية المرجعة.

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

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

سبب الإرجاع في البوابة الإلكترونية

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

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

إذا رُفضت فاتورة الإرجاع

لا يوثق الدليل التقني رسالة خطأ بعينها لغياب سبب الإرجاع أو لقيمة غير صحيحة في cbc:PaymentMeansCode. لذلك لا تفترض أن الرفض سببه هذه الكتلة قبل أن تقرأ الرد:

1. اقرأ الحالة. القرار النهائي في EINV_STATUS لا في رمز الاستجابة. الحالة NOT_SUBMITTED تعني أن الفاتورة رُفضت، ولا يعود معها رمز QR.
2. اقرأ تفاصيل الخطأ. يحمل EINV_MESSAGE سبب الرفض كما أعاده النظام، ومنه تعرف العنصر المقصود.
3. راجع كتلة السبب. تأكد أن cbc:InstructionNote غير فارغ، وأن الرمز 10 والسمة listID="UN/ECE 4461" كما في الدليل، وأن السبب لم يُكتب في cbc:Note بدلًا منه.
4. راجع بقية الشروط. المرجع والمشتري والبنود والمجاميع، فقد يكون الرفض في عنصر آخر تمامًا.
5. أعد الإرسال برقم الفاتورة ومعرّفها نفسيهما. توصي إرشادات الدليل عند فشل الإرسال بإعادته بالرقم والمعرّف الفريد نفسيهما، لا بمعرّف جديد.

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

قائمة فحص لسبب الإرجاع قبل الإرسال

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

1. الكتلة cac:PaymentMeans موجودة في فاتورة الإرجاع.
2. cbc:PaymentMeansCode قيمته 10 وسمته listID="UN/ECE 4461" كما في الدليل.
3. cbc:InstructionNote يحمل نصًا يصف سبب الإرجاع، وليس فارغًا.
4. السبب مكتوب في cbc:InstructionNote لا في cbc:Note.
5. طريقة الدفع مأخوذة من الخانة الثانية لرمز الفاتورة الأصلية، لا من كتلة السبب.
6. قيمة cbc:InvoiceTypeCode هي 381، ورمز name والعملة كما في الفاتورة الأصلية.
7. النص متسق مع البنود والكميات المرجعة.
8. السبب محفوظ في نظامك مع رقم فاتورة الإرجاع ومعرّفها وحالتها، ضمن سجل العمليات.

كيف يساعدك قيود

حين تصدر فواتيرك من برنامج محاسبي، لا تكتب ملف XML بيدك. يبني تكامل قيود مع نظام الفوترة الوطني ملف الفاتورة بصيغة UBL 2.1 ومعرّفها الفريد، ويرسله دون أي تدخل يدوي، وفاتورة الإرجاع من أنواع المستندات التي يتعامل معها.

• فحص قبل الإرسال. يفحص قيود كل فاتورة لحظة إنشائها في أربعة حقول، هي الرقم الضريبي، ونوع المستند وطريقة الدفع، ونسبة ضريبة المبيعات العامة، واكتمال البنود، وينبهك بأي خطأ قبل إرسالها لتقليل حالات الرفض.
• حالة كل فاتورة أمامك. تعيد الدائرة حالة الفاتورة ورسالة الخطأ، ويعرضها قيود في لوحة الحالة.
• إعادة إرسال بالمعرّف نفسه. تعيد إرسال الفاتورة بالمعرّف الفريد (UUID) نفسه.

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

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

هل سبب الإرجاع إلزامي في نظام الفوترة الوطني؟

يشترطه الدليل التقني في كل فاتورة إرجاع بعبارة «يجب إدخال سبب الإرجاع». ويُكتب نصًا حرًا في العنصر cbc:InstructionNote داخل الكتلة cac:PaymentMeans.

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

يحدد الدليل القيمة 10 مع السمة listID="UN/ECE 4461"، ولا يذكر قيمة غيرها. وهذا الجزء غير مظلل في الدليل، فيُنسخ كما هو في كل فاتورة إرجاع.

هل يحدد PaymentMeans إن كان الإرجاع نقديًا أم بالذمم؟

لا يحدده. تحمل طريقة الدفع الخانة الثانية من رمز السمة name في cbc:InvoiceTypeCode، 1 للنقدي و2 للذمم، وفاتورة الإرجاع تأخذ الرمز نفسه من الفاتورة الأصلية.

هل توجد قائمة بأسباب الإرجاع المقبولة؟

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

هل أضيف PaymentMeans إلى الفاتورة الجديدة؟

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

ما رسالة الخطأ إذا نسيت كتابة السبب؟

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

المراجع

• دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، الصفحات 12 و24 و26 و27 و104.
• دائرة ضريبة الدخل والمبيعات، دليل الأسئلة والأجوبة لنظام الفوترة الوطني، 2026.
• دليل المستخدم الخاص بمنصة نظام الفوترة الوطني، 2024 (مصدر غير صادر عن الدائرة، استُخدم لخطوة البوابة وحدها).