رمز الخطأ 1008: مجموع البنود لا يطابق الإجمالي

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

هذا الدليل جزء من دليل الفوترة الإلكترونية من قيود، ويكمّل دليل أخطاء هيئة الزكاة والضريبة والجمارك في الفوترة ودليل أخطاء التحقق (Validation Errors). إذا كنت تريد فهم بنية السطر نفسه أولًا، فارجع إلى صفحة بنود الفاتورة (Invoice Lines) في XML، فهي تشرح كل حقل سنشير إليه هنا.

آخر تحديث: 24 يونيو 2026.

ماذا يعني الخطأ 1008 فعليًا

كل فاتورة إلكترونية في السعودية مبنية على معيار UBL 2.1 الذي اعتمدته هيئة الزكاة والضريبة والجمارك (ZATCA). داخل هذا المعيار يوجد مبدأ صارم: الإجماليات ليست أرقامًا تكتبها بحرية، بل نتيجة حسابية يجب أن تشتقّها من السطور. عنصر الإجماليات اسمه cac:LegalMonetaryTotal، وبداخله عدة خانات لكل منها قاعدة حساب محددة.

أول هذه الخانات هي cbc:LineExtensionAmount داخل عنصر الإجماليات. هذه الخانة يجب أن تساوي مجموع مبالغ السطور قبل الضريبة. القاعدة المرجعية في معيار EN 16931 تحمل المعرّف BR-CO-10، ونصّها: إجمالي صافي مبالغ البنود يجب أن يساوي حاصل جمع مبالغ السطور لكل بنود الفاتورة. حين يخالف ملفك هذه القاعدة، تُرجع منصة فاتورة الرفض، وقد تظهره أنظمة الحلول كرمز محلي رقمه 1008.

لاحظ الفرق المهم: هذا الخطأ ليس خطأ بنية. ملف XML قد يكون سليمًا تمامًا من ناحية المخطط (XSD)، وكل الحقول موجودة وبأنواعها الصحيحة. المشكلة منطقية بحتة: رقمان كان يجب أن يتطابقا، لكنهما اختلفا. لذلك لن يساعدك تعديل بنية الملف، بل مراجعة الحساب نفسه.

الخطأ 1008 يقع تحديدًا على مستوى صافي البنود (قبل الضريبة). هناك أخطاء شقيقة تخص خانات أخرى داخل العنصر نفسه، مثل تطابق الإجمالي شامل الضريبة مع غير شامل الضريبة زائد الضريبة (القاعدة BR-CO-15). تناولنا تلك العائلة في دليل أخطاء التحقق. هنا نركّز على بوابة واحدة: مجموع السطور مقابل إجمالي البنود.

تشريح عنصر الإجماليات وعلاقته بالسطور

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

• صافي البنود (LineExtensionAmount): مجموع مبالغ السطور قبل الضريبة وقبل أي خصم على مستوى الفاتورة. هذه الخانة هي بوابة الخطأ 1008.
• الوعاء غير شامل الضريبة (TaxExclusiveAmount): صافي البنود بعد إضافة الرسوم وطرح الخصومات على مستوى الفاتورة.
• الإجمالي شامل الضريبة (TaxInclusiveAmount): الوعاء غير شامل الضريبة زائد مجموع الضريبة.
• المبلغ القابل للدفع (PayableAmount): الإجمالي شامل الضريبة بعد أي مبلغ مدفوع مقدمًا أو تقريب نهائي مسموح.

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

القاعدة الحاكمة التي يجب أن تثبت في ذهنك: السطور تُغذّي الإجماليات في اتجاه واحد فقط. لا يجوز أبدًا أن تعدّل خانة إجماليات لتطابق رقمًا تتوقعه، بل تعدّل السطور إن أردت تغيير النتيجة. أي محاولة لـ«تصحيح» الإجمالي يدويًا دون لمس السطور هي بالضبط ما يولّد الخطأ 1008.

كيف تبدو رسالة الخطأ

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

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "BR-CO-10",
        "category": "BR",
        "message": "Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)"
      }
    ],
    "warningMessages": [],
    "infoMessages": []
  },
  "reportingStatus": "NOT_REPORTED"
}

اقرأ الرسالة كمعادلة. الطرف الأيسر BT-106 هو إجمالي صافي البنود الذي كتبته في عنصر الإجماليات. الطرف الأيمن هو حاصل جمع كل قيم BT-131، أي مبلغ كل سطر على حدة. القاعدة تطلب تساويهما تمامًا. أي فرق، ولو هللة واحدة، يكفي لرفض الفاتورة.

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

أسباب الخطأ 1008

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

توزيع أسباب الخطأ 1008

السبب الأول: التقريب غير الموحّد

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

مثال عملي: ثلاثة بنود سعر كل منها 3.335 ريال. لو قرّبت كل سطر أولًا، يصبح كل سطر 3.34، والمجموع 10.02. ولو جمعت القيم الكاملة 10.005 ثم قرّبت، تحصل على 10.01. الفرق هللة واحدة، لكنه يكفي لرفض الفاتورة. الحل المعتمد: قرّب مبلغ كل سطر أولًا، ثم اجمع المبالغ المقرَّبة لتكوين الإجمالي. أي اجعل السطر هو الوحدة التي يُبنى عليها كل شيء.

السبب الثاني: خصم أو رسم على مستوى الفاتورة

كثيرون يخطئون في فهم موقع الخصم. الخطأ 1008 يقارن مجموع السطور بخانة صافي البنود (LineExtensionAmount) فقط، وليس بالإجمالي القابل للدفع. الخصم على مستوى الفاتورة (cac:AllowanceCharge) لا يُطرح من صافي البنود، بل يدخل في خانة لاحقة هي الوعاء الضريبي (TaxExclusiveAmount).

الخطأ النموذجي: تطرح الخصم من مجموع السطور وتكتب الناتج في خانة صافي البنود. عندها لن يطابق إجمالي البنود مجموع السطور، فيُرفض الملف. الصواب أن صافي البنود يساوي مجموع السطور كما هي قبل أي خصم على مستوى الفاتورة، ثم يأتي الخصم في خطوة الوعاء الضريبي وفق القاعدة BR-CO-13: الوعاء غير شامل الضريبة = صافي البنود + الرسوم على مستوى الفاتورة − الخصومات على مستوى الفاتورة.

السبب الثالث: الخلط بين السعر شامل الضريبة وغير شامله

في معيار الفاتورة الإلكترونية، مبلغ السطر (LineExtensionAmount) هو القيمة غير شاملة للضريبة. حين يبيع التاجر بأسعار يراها العميل شاملة الضريبة (وهو شائع في البيع المباشر للمستهلك)، يجب أن يفصل النظام السعر إلى مكوّنيه قبل بناء الملف.

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

السبب الرابع: تعديل سطر يدويًا دون إعادة حساب

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

كيف تكتشف موضع الفرق بدقة

لا تبدأ بالتخمين. ابدأ بقياس الفرق رقميًا، فالرقم نفسه يدلّك على العائلة المسؤولة. اتبع هذه الخطوات بالترتيب.

خطوات تشخيص الخطأ 1008

الخطوة الأولى: اجمع السطور يدويًا. استخرج قيمة cbc:LineExtensionAmount من كل عنصر cac:InvoiceLine في الملف، واجمعها يدويًا أو بأداة بسيطة. احتفظ بالمجموع.

الخطوة الثانية: اقرأ الإجمالي المعلَن. اقرأ قيمة cbc:LineExtensionAmount الموجودة داخل عنصر cac:LegalMonetaryTotal. هذا هو الرقم الذي يعترض عليه النظام.

الخطوة الثالثة: احسب الفرق وصنّفه. اطرح المجموع اليدوي من الإجمالي المعلَن. حجم الفرق دليلك:

• فرق بمقدار 0.01 أو 0.02 ريال غالبًا مشكلة تقريب (السبب الأول).
• فرق يساوي بالضبط قيمة خصم أو رسم تعرفه يعني أن الخصم دخل في الخانة الخطأ (السبب الثاني).
• فرق يقارب نسبة الضريبة 15% من قيمة الفاتورة يعني خلطًا بين السعر شامل الضريبة وغير شامله (السبب الثالث).
• فرق عشوائي غير منتظم يعني على الأرجح تعديلًا يدويًا متأخرًا على أحد السطور (السبب الرابع).

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

سيناريوهات واقعية يظهر فيها الخطأ

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

الموقف الأول: متجر تجزئة يبيع بأسعار شاملة الضريبة. يضع التاجر على الرف سعرًا نهائيًا للعميل، مثلًا 23 ريالًا للصنف. عند إصدار الفاتورة، يجب على النظام أن يفصل هذا السعر إلى 20 ريالًا قيمة غير شاملة و3 ريالات ضريبة. إذا كتب النظام 23 في مبلغ السطر بدلًا من 20، يختلف مجموع السطور عن صافي البنود المحسوب على الأساس الصحيح، فيظهر الخطأ. الحل أن تكون آلية الفصل ثابتة وموحّدة قبل بناء أي سطر.

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

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

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

كيف تصلح الخطأ 1008

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

أولًا، طبّع قيم السطور. تأكد أن مبلغ كل سطر غير شامل الضريبة، وأنه مقرَّب إلى خانتين عشريتين. لكل سطر: مبلغ السطر = (الكمية × سعر الوحدة) مطروحًا منه أي خصم على مستوى السطر، ثم قرّب الناتج لخانتين.

ثانيًا، احسب صافي البنود بالجمع. اجمع مبالغ السطور المقرَّبة، واكتب الناتج في cac:LegalMonetaryTotal/cbc:LineExtensionAmount كما هو، دون طرح أي خصم على مستوى الفاتورة. هنا يُحل الخطأ 1008 مباشرة لأن الطرفين سيتطابقان حتمًا.

ثالثًا، طبّق الخصومات والرسوم في خانتها الصحيحة. احسب الوعاء الضريبي = صافي البنود + الرسوم على مستوى الفاتورة − الخصومات على مستوى الفاتورة، واكتبه في cbc:TaxExclusiveAmount.

رابعًا، اشتقّ بقية الإجماليات. الإجمالي شامل الضريبة = الوعاء الضريبي + مجموع الضريبة. المبلغ القابل للدفع يُحسب بعده. كل خانة تُبنى على سابقتها بالترتيب، فلا يبقى مجال لتناقض.

هذا المثال يوضح القيم المتطابقة الصحيحة لفاتورة بثلاثة بنود بعد تطبيق التسلسل أعلاه:

<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="SAR">100.00</cbc:LineExtensionAmount> </cac:InvoiceLine>
<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="SAR">55.50</cbc:LineExtensionAmount>  </cac:InvoiceLine>
<cac:InvoiceLine> <cbc:LineExtensionAmount currencyID="SAR">44.50</cbc:LineExtensionAmount>  </cac:InvoiceLine>

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="SAR">200.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount  currencyID="SAR">200.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount  currencyID="SAR">230.00</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount       currencyID="SAR">230.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

لاحظ كيف أن مجموع السطور (100.00 + 55.50 + 44.50) يساوي 200.00 تمامًا، وهو نفسه صافي البنود المعلَن. هذا التطابق هو ما تبحث عنه قاعدة BR-CO-10.

ماذا لو استمر الخطأ بعد الإصلاح؟

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

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

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

خصم على مستوى السطر مقابل خصم على مستوى الفاتورة. خصم السطر يُطرح من مبلغ السطر نفسه قبل الجمع، فيدخل ضمن صافي البنود. أما خصم الفاتورة فيُطرح لاحقًا في الوعاء الضريبي. الخلط بين الموضعين يولّد الفرق. راجع كل خصم واسأل: هل هو على بند بعينه أم على الفاتورة كلها؟ وضعه في موضعه الصحيح.

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

كيف يمنع قيود الخطأ 1008

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

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

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

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

رابعًا، قيود معتمد رسميًا للمرحلة الثانية من الفوترة الإلكترونية ومربوط مع منصة فاتورة. يدير النظام معرّف الختم التشفيري للامتثال (CSID) آليًا، ويولّد ملف XML والرمز المربّع (QR) وفق المواصفة، فتصل فاتورتك للهيئة بصيغة صحيدة من حيث البنية والحساب معًا.

مقارنة: حساب يدوي مقابل قيود

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

قائمة تحقق سريعة قبل الإرسال

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

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

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

ما الفرق بين الخطأ 1008 والخطأ الخاص بالإجمالي شامل الضريبة؟

الخطأ 1008 يخص طبقة صافي البنود قبل الضريبة: مجموع مبالغ السطور مقابل خانة صافي البنود وفق القاعدة BR-CO-10. أما خطأ الإجمالي شامل الضريبة فيخص طبقة أعلى: تطابق الإجمالي شامل الضريبة مع الوعاء غير شامل الضريبة زائد مجموع الضريبة وفق القاعدة BR-CO-15. قد تظهر الطبقتان معًا، لكن إصلاح صافي البنود أولًا غالبًا ما يحلّ ما يليه.

الفرق عندي هللة واحدة فقط، فهل أهمله؟

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

أين أضع خصم الفاتورة الكلي حتى لا يسبب الخطأ؟

ضعه في عنصر الخصم على مستوى الفاتورة (cac:AllowanceCharge على مستوى المستند)، ودعه يؤثر في حساب الوعاء الضريبي فقط. لا تطرحه من صافي البنود، لأن صافي البنود يجب أن يبقى مساويًا لمجموع السطور كما هي.

هل سبب الخطأ قد يكون ضريبة القيمة المضافة على مستوى السطر؟

الخطأ 1008 يقارن مبالغ السطور غير شاملة الضريبة فقط، فالضريبة لا تدخل في هذه المقارنة مباشرة. لكن إذا كان نظامك قد كتب مبلغ السطر شاملًا الضريبة بالخطأ، فستظهر المشكلة هنا. تأكد أن مبلغ السطر هو القيمة غير شاملة الضريبة دائمًا.

هل يحدث الخطأ مع الفاتورة المبسّطة (B2C) كما مع الضريبية؟

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

كيف أتجنب هذا الخطأ نهائيًا دون مراجعة كل فاتورة؟

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

مقالات ذات صلة

• أخطاء هيئة الزكاة والضريبة والجمارك في الفوترة
• أخطاء التحقق (Validation Errors)
• بنود الفاتورة (Invoice Lines) في XML
• دليل الفوترة الإلكترونية من قيود