رسالة Total General Amount is Not Correct في نظام الفوترة الوطني: أسبابها وطريقة إصلاحها

تظهر رسالة Total General Amount is Not Correct حين يرسل برنامجك المحاسبي فاتورة إلى نظام الفوترة الوطني فتعود مرفوضة برمز 400. ومعناها أن مجاميع الفاتورة لا تطابق الحساب الذي يجريه النظام على سطورها.

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

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

ما معنى رسالة Total General Amount is Not Correct

يصف الدليل التقني رمز 400 (Bad Request) بأنه خطأ في القيم المرسلة داخل ملف XML، ويُكتب تفصيله في الحقل EINV_MESSAGE من ملف الاستجابة. ومن الرسائل التي يذكرها تحت هذا الرمز رسالة Total General Amount is Not Correct، ويشرحها بهذا النص:

«خطأ في العملية الحسابية لاحتساب المجموع النهائي للفاتورة (يمكن ان يكون الخطأ في أحد العمليات الحسابية الفرعية تؤدي الى خطأ في المجموع)».

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

كيف تبدو الرسالة في ملف الاستجابة

يعرض الدليل (ص100) مثالًا لاستجابة فاتورة رُفضت بهذه الرسالة. تحمل حالة الفاتورة EINV_STATUS القيمة NOT_SUBMITTED، ويأتي الخطأ داخل المصفوفة ERRORS بثلاثة حقول:

• EINV_CODE وقيمته totalGeneralTaxesAmount.
• EINV_CATEGORY وقيمته invoice.
• EINV_MESSAGE وقيمته Total General Amount is Not Correct.

ويُلاحظ في المثال نفسه أن الملف اجتاز فحص البنية، فالمصفوفة INFO تحمل الرمز XSD_VALID بحالة PASS. أي أن الرفض هنا في الأرقام لا في بنية الملف. وتعود مع الرفض حقول رمز الاستجابة السريع ورقم الفاتورة ومعرّفها والفاتورة الموقّعة فارغة.

ولا يشرح الدليل الرمز totalGeneralTaxesAmount بأكثر من الرسالة المرافقة له. فلا تحصر الفحص في مجموع الضريبة بسبب اسم الرمز، لأن نص الدائرة يجعل الخطأ ممكنًا في أي عملية حسابية فرعية. ولموقع هذه الرسالة بين بقية رموز الرفض (500 و403 و504) راجع مقال أخطاء نظام الفوترة الوطني.

ثلاث طبقات من الحساب في ملف الفاتورة

تُبنى أرقام الفاتورة في الملف على ثلاث طبقات، وكل طبقة تعتمد على التي قبلها:

1. السطر (cac:InvoiceLine). الكمية والسعر والخصم والضريبة ومجموع السطر.
2. عناصر رأس الفاتورة. مجموع الخصومات في cac:AllowanceCharge، ومجموع الضريبة العامة في cac:TaxTotal.
3. المجاميع النهائية (cac:LegalMonetaryTotal). الإجمالي قبل الخصم، ومجموع الخصم، والإجمالي النهائي.

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

معادلات السطر الواحد

يحدد الدليل لكل حقل رقمي في السطر قاعدته أو معادلته:

وخلف هذه المعادلات ثلاث نقاط تستحق الانتباه:

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

معادلات المجاميع في LegalMonetaryTotal

يضم العنصر cac:LegalMonetaryTotal أربعة حقول، ولكل منها معادلة محددة في الدليل:

لاحظ أن TaxInclusiveAmount وPayableAmount يحملان القيمة نفسها، وكلاهما مجموع حقول RoundingAmount في السطور. فأي فرق بينهما، أو بين أحدهما ومجموع السطور، خروج عن معادلة الدليل.

عنصران في رأس الفاتورة تعتمد عليهما المجاميع

إلى جانب الحقول الأربعة، يحمل رأس الفاتورة عنصرين آخرين محسوبين من السطور:

• cac:AllowanceCharge على مستوى الفاتورة. يُرسل بقيمة ChargeIndicator = false وسبب discount، وقيمته cbc:Amount تساوي مجموع خصومات السطور. فمجموع الخصم يظهر في الملف مرتين، هنا وفي AllowanceTotalAmount، والرقمان يساويان مجموع خصومات السطور.
• cac:TaxTotal/cbc:TaxAmount على مستوى الفاتورة. يسمّيه الدليل «مجموع قيمة الضريبة العامة»، ويساوي مجموع ضريبة السطور. ويرد في فواتير ضريبة المبيعات العامة والضريبة الخاصة، ولا يرد في فاتورة الدخل.

مثال رقمي من الدليل: كيف تتطابق المجاميع

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

فاتورة دخل بسطرين (ص19 إلى 21)

وتظهر هذه الأرقام في حقول المجاميع كما يلي:

• TaxExclusiveAmount يساوي 116.000، أي 66.000 + 50.000.
• AllowanceTotalAmount يساوي 7.000، أي 2.000 + 5.000. والقيمة نفسها في AllowanceCharge برأس الفاتورة.
• PayableAmount يساوي 109.000، أي 116.000 − 7.000، وهو مجموع قيمتي السطرين بعد الخصم (64.000 + 45.000).

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

فاتورة مبيعات عامة تجمع سطرًا خاضعًا وسطرًا معفى (ص40 و43 و44)

يجمع هذا المثال في فاتورة واحدة سطرًا بالتصنيف S وآخر بالتصنيف Z بنسبة 0%:

ومجاميع الفاتورة في المثال هي TaxExclusiveAmount بقيمة 116.000، وAllowanceTotalAmount بقيمة 2.000، وTaxTotal بقيمة 4.480، وPayableAmount بقيمة 118.480.

والتحقق الحسابي بطريقتين. الأولى 116.000 − 2.000 + 4.480 = 118.480، والثانية جمع مجموعي السطرين 68.480 + 50.000 = 118.480. فإذا لم تتطابق الطريقتان في فاتورتك، فابحث عن السطر الذي يختلف.

والنسبة 7% هنا هي القيمة المستخدمة في مثال الدليل فقط. أما النسبة التي تنطبق على سلعتك فيحددها قانون الضريبة العامة على المبيعات، لا هذا المثال.

الخصم على مستوى الفاتورة: لماذا يُرفض وكيف توزّعه

ينص الدليل على أن النظام لا يقبل الخصم على الفاتورة بشكل عام، ويضيف هذه القاعدة:

«في حال كان نظام المكلف يحسب الخصم على اجمالي الفاتورة يجب ان يتم توزيع الخصم على السلع و الخدمات قبل ترحيل البيانات الى نظام الفوترة».

ويترتب على ذلك ثلاثة أمور عملية:

• كل خصم يصل إلى الملف خصم سطر، في AllowanceCharge داخل السطر نفسه.
• مجموع خصومات السطور يُكتب في AllowanceCharge برأس الفاتورة وفي AllowanceTotalAmount، بالقيمة نفسها في الموضعين.
• قيمة الخصم موجبة دائمًا، ويقبل الحقل حتى 9 خانات عشرية.

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

التقريب: ثلاث خانات عشرية وفارق لا يتجاوز 0.001

تتكرر تحت كل مبلغ في الدليل الملاحظة نفسها:

«يمكن التقريب لغاية (3) خانات عشرية و بحد أعلى (9) خانات عشرية بحيث أن الفرق يكون أقل من أو يساوي (0.001)».

فالمبلغ قد يحمل حتى 9 خانات عشرية، ويمكن تقريبه إلى 3، بشرط ألا يزيد الفرق الناتج على 0.001. وتكتب أمثلة المجاميع في الدليل المبالغ بثلاث خانات، مثل 116.000 و4.480.

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

سطور الضريبة الخاصة

في فاتورة الضريبة الخاصة يتغير حساب السطر. ويصف الدليل الضريبة الخاصة بأنها «قيمة يتم إدخالها دون عمليات حسابية»، فهي مبلغ يُدخل في السطر لا نسبة تُضرب في قيمته.

• تُرسل في TaxSubtotal مستقل نوعه OTH، دون عنصر cbc:Percent، ويأتي قبل كتلة ضريبة المبيعات العامة.
• تُحسب ضريبة المبيعات العامة على قيمة السطر مضافًا إليها الضريبة الخاصة.
• يحمل TaxAmount في السطر الضريبة العامة وحدها.
• مجموع السطر RoundingAmount يساوي قيمة السطر مضافًا إليها الضريبة الخاصة والضريبة العامة.

ومثال الدليل (ص69 إلى 71) سطر قيمته 10 × 50 − 5 = 495.000، وضريبته الخاصة 10.000. فتكون الضريبة العامة (495 + 10) × 10% = 50.500، ومجموع السطر 555.500.

ويحمل TaxTotal على مستوى الفاتورة الضريبة العامة وحدها. ففي مثال الدليل بسطرين يساوي 101.000، أي 2 × 50.500. ويكتب الدليل إجمالي هذه الفاتورة بهذه الصيغة:

«اجمالي الفاتورة = (اجمالي الفاتورة قبل الخصم − مجموع قيمة الخصم + مجموع الضريبة الخاصة + مجموع قيمة الضريبة العامة)».

وأرقام مثاله 1000.000 − 10.000 + 20.000 + 101.000 = 1111.000، وهو نفسه مجموع RoundingAmount في السطرين. فإذا حسب برنامجك الضريبة العامة على قيمة السطر وحدها، أو وضع الضريبة الخاصة في TaxAmount، اختلف مجموع السطر عن المعادلة.

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

يوصي الدليل في إرشاداته بالتحقق من المجاميع والضرائب والحقول الإلزامية قبل الإرسال، لتقليل أخطاء 400. وهذه القائمة تجمع المعادلات السابقة في خطوات مرتبة:

1. سعر الوحدة في كل سطر قبل الضريبة وأكبر من صفر، والكمية أكبر من صفر.
2. قيمة كل سطر تساوي (الكمية × سعر الوحدة) − الخصم.
3. ضريبة كل سطر محسوبة على قيمته بعد الخصم مضافًا إليها الضريبة الخاصة إن وُجدت.
4. مجموع كل سطر (RoundingAmount) يساوي قيمته مضافًا إليها ضريبته العامة، والضريبة الخاصة إن وُجدت.
5. لا خصم على الفاتورة ككل. كل خصم موزّع على السطور وقيمته موجبة.
6. AllowanceCharge في رأس الفاتورة يساوي AllowanceTotalAmount، وكلاهما مجموع خصومات السطور.
7. TaxExclusiveAmount يساوي مجموع (الكمية × سعر الوحدة) قبل الخصم.
8. TaxInclusiveAmount يساوي PayableAmount، وكلاهما مجموع RoundingAmount في السطور.
9. TaxTotal في رأس فاتورة ضريبة المبيعات العامة أو الضريبة الخاصة يساوي مجموع الضريبة العامة في السطور، ولا يرد في فاتورة الدخل.
10. لا يتجاوز أي مبلغ 9 خانات عشرية، ولا يزيد فرق أي تقريب على 0.001، والمجاميع محسوبة من القيم المرسلة نفسها.

وراجع كذلك نسبة الضريبة في كل سطر. فالنسبة التي لا تقبلها الواجهة البرمجية في الحقل cbc:Percent يذكرها الدليل بين أسباب رمز 500 لا بين رسائل رمز 400، وتفصيلها في مقال خطأ 500 في نظام الفوترة الوطني.

بعد الإصلاح: أعد الإرسال بالرقم والمعرّف نفسيهما

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

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

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

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

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

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

أين تذهب بعد هذا المقال

• بقية رموز الرفض ورسائله: في مقال أخطاء نظام الفوترة الوطني: لماذا تُرفض فاتورتك وكيف تصلحها.
• الصورة الكاملة للنظام: كيف يعمل وكيف تربط منشأتك به، في مقال نظام الفوترة الوطني الإلكتروني في الأردن.
• رمز 500: الرقم الضريبي وتسلسل مصدر الدخل ونسب الضريبة، في مقال خطأ 500 في نظام الفوترة الوطني.
• رمز 403: رقم المستخدم والمفتاح السري المرسلان في ترويسة الطلب، في مقال خطأ 403 في نظام الفوترة الوطني.

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

ما معنى رسالة Total General Amount is Not Correct؟

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

لماذا تُرفض الفاتورة مع أن إجماليها يبدو صحيحًا في برنامجي؟

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

هل يقبل نظام الفوترة الوطني خصمًا على إجمالي الفاتورة؟

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

كم خانة عشرية تقبلها المبالغ في ملف الفاتورة؟

يسمح الدليل بالتقريب حتى 3 خانات عشرية، وبحد أعلى 9 خانات، بشرط ألا يزيد الفرق الناتج على 0.001. وتكتب أمثلة المجاميع في الدليل المبالغ بثلاث خانات.

هل TaxInclusiveAmount وPayableAmount قيمة واحدة؟

يحمل الحقلان القيمة نفسها في معادلات الدليل، فكلاهما مجموع حقول RoundingAmount في سطور الفاتورة. وأي فرق بينهما خروج عن المعادلة.

هل أولّد معرّفًا فريدًا جديدًا عند إعادة الإرسال بعد الإصلاح؟

يوصي الدليل بإعادة الإرسال برقم الفاتورة ومعرّفها الفريد نفسيهما. فتوليد معرّف جديد عند إعادة الإرسال قد يؤدي إلى تكرار الفاتورة.

المراجع

• دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026.