رسالة Invalid Invoice Minification في نظام الفوترة الوطني: السبب والإصلاح

تظهر رسالة Invalid Invoice Minification حين يرسل برنامجك المحاسبي فاتورة إلى نظام الفوترة الوطني فتعود مرفوضة، ويأتي نص الرسالة في الحقل EINV_MESSAGE من ملف الاستجابة. ومعناها بحسب الدليل التقني أن أول وسم في ملف XML، وهو وسم البداية للعنصر Invoice، مكتوب بشكل خاطئ أو موزع على أكثر من سطر، والمطلوب أن يأتي على سطر واحد.

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

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

ما معنى رسالة Invalid Invoice Minification

يصف الدليل التقني رمز 400 (Bad Request) بأنه خطأ في القيم المرسلة داخل ملف XML، ويأتي تفصيله في الحقل EINV_MESSAGE. ومن الرسائل التي يوردها تحت هذا الرمز رسالة Invalid Invoice Minification، ويشرحها في الصفحة 102 كما يلي.

«يدل بأن أول Tag موجود في ال XML مكتوب بشكل خاطئ أو مكتوب بأكثر من سطر ويجب أن يكون على سطر واحد بينهما مسافات».

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

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

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

أين تظهر الرسالة في ملف الاستجابة

يعيد نظام الفوترة الوطني نتيجة الفحص في العنصر EINV_RESULTS، وفيه ثلاث مصفوفات هي INFO وWARNINGS وERRORS. ويحمل كل عنصر فيها الحقول type وstatus وEINV_CODE وEINV_CATEGORY وEINV_MESSAGE، ونص Invalid Invoice Minification يأتي في الحقل الأخير.

ولا يذكر الدليل قيمة EINV_CODE ولا قيمة EINV_CATEGORY التي ترافق هذه الرسالة. لذلك اعتمد على نصها في EINV_MESSAGE حين تبحث عنها في سجلاتك، وانسخه كما يعود إليك.

وإذا رُفضت الفاتورة حملت حالتها EINV_STATUS القيمة NOT_SUBMITTED، وعادت حقول رمز QR والمعرّف الفريد ورقم الفاتورة والفاتورة الموقعة بقيمة null. ويوصي الدليل في إرشاداته بأن تحكم على الفاتورة من EINV_STATUS، لا من رمز حالة الطلب وحده.

ما المقصود بالتصغير في هذه الرسالة

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

ويضيف الدليل في أول إرشاداته العشرة قاعدة أعم، وهي أن ملف الفاتورة يجب أن يطابق معيار UBL 2.1، وأن أي خلل في بنيته يؤدي إلى رفض الفاتورة.

ويجمع الجدول التالي ما يوثقه الدليل عن هذه النقطة وما يسكت عنه، حتى لا تبني إصلاحك على قاعدة غير مكتوبة.

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

كيف يبدو وسم Invoice الصحيح

يعرض الدليل التقني في الصفحة 10 بداية ملف الفاتورة، ويطلبها كما هي. فالملف يبدأ بسطر التعريف الذي يحدد الترميز UTF-8، ثم وسم البداية للعنصر Invoice بمساحات الأسماء الأربع، ثم العنصر cbc:ProfileID بالقيمة reporting:1.0.

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
<cbc:ProfileID>reporting:1.0</cbc:ProfileID>

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

ومساحات الأسماء الأربع هي التي تبدأ بالكلمات xmlns وxmlns:cac وxmlns:cbc وxmlns:ext، وقيمها وصف ثابت يُنسخ دون تعديل. وشرح هذه البداية وموقعها من بنية الملف كلها في مقال معيار UBL 2.1 في نظام الفوترة الوطني، فلا نعيده هنا.

من أين يأتي الوسم الموزع على أكثر من سطر

لا يذكر الدليل أسبابًا لهذه الرسالة غير ما في جملته. والنقاط الآتية ملاحظات عامة منا تساعدك على البحث، لا قواعد من الدائرة.

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

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

خطوات إصلاح رسالة Invalid Invoice Minification

اتبع الخطوات الآتية بالترتيب. وكل خطوة مستندة إلى نص الدليل، إلا حيث نقول إنها ملاحظة عامة منا.

1. اقرأ الحالة والرسالة. تأكد أن EINV_STATUS يحمل NOT_SUBMITTED، وأن نص Invalid Invoice Minification هو ما في EINV_MESSAGE. فإن كانت في القائمة رسائل أخرى، فلكل منها إصلاحها.
2. استرجع ملف XML الذي أرسلته. ابدأ من النسخة المحفوظة في سجلاتك قبل الترميز. ويوصي الدليل بتسجيل الأخطاء تفصيليًا داخليًا، فاحتفاظك بالملف المرسل يجعل هذه الخطوة ممكنة.
3. افتح الملف في محرر نصوص عادي. انظر إلى السطر الذي يبدأ بالعلامة <Invoice، وتأكد أن العلامة > التي تغلق الوسم في السطر نفسه.
4. قارن الوسم بالصفحة 10. تأكد من اسم العنصر ومن مساحات الأسماء الأربع وقيمها وعلامات التنصيص، وأن بين كل سمة والتي تليها مسافة.
5. أصلح المصدر لا الملف وحده. هذه ملاحظة عامة منا. إن أصلحت الملف يدويًا وبقي القالب أو الشيفرة التي تولده كما هي، فستعود الرسالة مع الفاتورة التالية.
6. رمّز الملف المصحح من جديد. رمّزه كاملًا بترميز Base64 من سطر التعريف حتى وسم الإغلاق، وضع الناتج قيمةً للمفتاح invoice في جسم الطلب.
7. أعد الإرسال بالرقم والمعرّف نفسيهما. يطلب الدليل إعادة الإرسال بالقيمتين cbc:ID وcbc:UUID نفسيهما، دون توليد معرّف فريد جديد.
8. اقرأ الحالة الجديدة. إذا جاءت SUBMITTED فاحفظ رقم الفاتورة والمعرّف الفريد ورمز QR والحالة كما يوصي الدليل. وإذا عادت رسالة أخرى، فارجع إلى فهرس الرسائل.

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

علاقة الرسالة بترميز Base64

يمر ملف XML قبل الإرسال بترميز Base64، ثم يوضع الناتج في جسم الطلب بصيغة JSON تحت المفتاح invoice. وهذه الخطوة مشروحة في مقال ترميز Base64 في نظام الفوترة الوطني. ولها ثلاث صلات بهذه الرسالة.

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

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

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

راجع هذه البنود في بداية ملف الفاتورة قبل أن يخرج من برنامجك.

• الملف يبدأ بسطر التعريف بترميز UTF-8 كما في الصفحة 10.
• وسم البداية للعنصر Invoice على سطر واحد، من <Invoice حتى >.
• مساحات الأسماء الأربع موجودة بقيمها كما وردت في الدليل، وبين كل سمة والتي تليها مسافة.
• العنصر cbc:ProfileID يحمل القيمة reporting:1.0.
• لا أداة تنسيق تعمل على الملف بين الفحص والترميز.
• ما يُرمَّز هو ملف XML وحده، لا نص JSON كاملًا.
• الرقم cbc:ID والمعرّف cbc:UUID محفوظان، لتعيد الإرسال بهما إذا رُفضت الفاتورة.

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

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

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

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

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

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

• بقية رسائل الرمز 400. في مقال خطأ 400 في نظام الفوترة الوطني.
• بنية ملف الفاتورة كلها. في مقال معيار UBL 2.1 في نظام الفوترة الوطني.
• خطوات تجهيز جسم الطلب. في مقال ترميز Base64 في نظام الفوترة الوطني.
• الصورة الكاملة للنظام. كيف يعمل وكيف تربط منشأتك به، في مقال نظام الفوترة الوطني الالكتروني.

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

ما معنى رسالة Invalid Invoice Minification؟

تعني أن أول وسم في ملف XML، وهو وسم البداية للعنصر Invoice، مكتوب بشكل خاطئ أو موزع على أكثر من سطر. ويطلب الدليل التقني أن يأتي على سطر واحد تفصل بين أجزائه مسافات (ص102).

هل يجب أن يكون ملف XML كله في سطر واحد؟

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

هل يصلح ترميز Base64 الوسم الموزع على أكثر من سطر؟

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

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

لا تولّد معرّفًا جديدًا. يطلب الدليل التقني إعادة الإرسال بالرقم cbc:ID والمعرّف cbc:UUID نفسيهما، ثم قراءة EINV_STATUS في الاستجابة الجديدة لمعرفة حالة الفاتورة.

هل أنسخ وسم Invoice من صفحة الدليل كما يظهر؟

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

المراجع

• دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، الصفحات 10 و96 و98 و100 و101 و102 و104.