مثال XML لفاتورة الدخل في نظام الفوترة الوطني مشروحًا

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

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

ما مثال XML لفاتورة الدخل في نظام الفوترة الوطني وأين يقع في الدليل

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

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

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

خريطة كتل المثال من الصفحة 10 إلى الصفحة 21

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

بداية الملف ومعلومات الفاتورة الأساسية

يبدأ الملف بسطر التعريف بصيغة XML وترميز UTF-8، ثم العنصر الجذري Invoice ومعه تعريفات النطاقات الأربعة التي يذكرها الدليل في الصفحة 10. ويشترط الدليل أن يأتي وسم Invoice الافتتاحي كله على سطر واحد، وإلا رُفضت الفاتورة برسالة Invalid Invoice Minification. ويليه العنصر cbc:ProfileID بالقيمة الثابتة reporting:1.0 في كل فاتورة. وما يشترطه معيار UBL 2.1 من هذه البنية مشروح في مقال معيار UBL 2.1 في نظام الفوترة الوطني.

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

<cbc:ID><!-- رقم الفاتورة في نظامك --></cbc:ID>
<cbc:UUID><!-- معرّف فريد يولّده نظامك ويحفظه --></cbc:UUID>
<cbc:IssueDate><!-- تاريخ الفاتورة بصيغة yyyy-mm-dd --></cbc:IssueDate>
<cbc:InvoiceTypeCode name="<!-- رمز من ثلاثة أرقام آخره 1 -->">388</cbc:InvoiceTypeCode>
<cbc:Note><!-- ملاحظة اختيارية --></cbc:Note>
<cbc:DocumentCurrencyCode>JOD</cbc:DocumentCurrencyCode>
<cbc:TaxCurrencyCode>JOD</cbc:TaxCurrencyCode>
<cac:AdditionalDocumentReference>
  <cbc:ID>ICV</cbc:ID>
  <cbc:UUID><!-- عداد الفاتورة يبدأ من 1 --></cbc:UUID>
</cac:AdditionalDocumentReference>

يمر هذا المقطع بالعناصر بالترتيب التالي.

• cbc:ID وcbc:UUID. الأول رقم الفاتورة، والثاني معرّف فريد يولّده نظام المكلف. والمفتاح الذي يميّز الفاتورة هو العنصران معًا، لا رقم الفاتورة وحده. ويحذّر الدليل من توليد معرّف جديد عند إعادة الإرسال لأن ذلك ينشئ فاتورة مكررة، والتفصيل في مقال المعرّف الفريد UUID في نظام الفوترة الوطني.
• cbc:IssueDate. يُكتب التاريخ بالصيغة yyyy-mm-dd، كما في جميع أمثلة XML في الدليل. والوصف المنسوخ من ملف الدليل قد يُظهر أجزاء التاريخ بترتيب مختلف في بعض الصفحات، والقاعدة المعتمدة مشروحة في مقال صيغة تاريخ الفاتورة في نظام الفوترة الوطني.
• cbc:InvoiceTypeCode. قيمة العنصر 388 للفاتورة الجديدة، والسمة name رمز من ثلاثة أرقام يأتي شرحه في القسم التالي.
• cbc:Note. ملاحظة أو وصف للفاتورة، وهي مظللة بالأخضر أي اختيارية.
• رمزا العملة. القيمة الافتراضية في العنصرين JOD. ويذكر الدليل أن تغيير العملة يكون على مستوى الفاتورة كاملة فقط.
• عداد الفاتورة ICV. يحمله العنصر cac:AdditionalDocumentReference، ويصفه الدليل في الصفحة 13 بأنه «عداد يتم إنشاؤه من قبل المكلف للفواتير الإلكترونية يبدأ بشكل تسلسلي من 1 الى ما لانهاية».

رمز نوع الفاتورة في عائلة الدخل

يقرأ النظام نوع الفاتورة من موضعين في العنصر cbc:InvoiceTypeCode. فقيمة العنصر تقول إن الفاتورة جديدة (388) أو إرجاع (381)، والسمة name تجمع ثلاث معلومات في ثلاثة أرقام. الرقم الأول نوع التعامل، والثاني طريقة الدفع (1 نقدي و2 ذمم)، والثالث عائلة الضريبة. والرقم الثالث في فاتورة الدخل هو 1 دائمًا، بينما يكون 2 لضريبة المبيعات العامة و3 للضريبة الخاصة.

وتأتي رموز فاتورة الدخل في جدول الصفحتين 12 و13 على النحو التالي.

ويضرب الدليل في الصفحة 13 مثالين على الرمز هما 011 و321. ويختلف عمود المحددات في عائلة الدخل عن العائلتين الأخريين، فشرط نسبة الضريبة 0% الذي يظهر في أنواع التعامل غير المحلية لا ينطبق هنا، لأن فاتورة الدخل لا تحمل بنود ضريبة أصلًا.

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

بيانات البائع والمشتري وتسلسل مصدر الدخل

الكتل B وC وD في الصفحات 15 إلى 18 لا تختلف في فكرتها عن مثيلاتها في الأمثلة الأخرى، ولذلك يكفي هنا ما يخص كل كتلة باختصار مع الإحالة إلى المقالات التي تشرحها بالتفصيل.

• البائع cac:AccountingSupplierParty (ص15). رمز الدولة JO، والرقم الضريبي للبائع في cbc:CompanyID، واسم البائع في cbc:RegistrationName كما هو مسجل لدى دائرة ضريبة الدخل والمبيعات.
• المشتري cac:AccountingCustomerParty (ص16 و17). نوع رقم المشتري في السمة schemeID بإحدى القيم NIN للرقم الوطني أو PN للرقم الشخصي لغير الأردني أو TN للرقم الضريبي. والرمز البريدي اختياري وبحد أعلى 5 خانات، ورمز المحافظة اختياري، والهاتف اختياري ويقبل الأرقام فقط بين 9 و14 رقمًا. ويصبح اسم المشتري واجبًا إذا كانت الفاتورة ذممًا، أو كانت نقدية وقيمتها، بنص جدول رسائل الخطأ في الصفحة 101، «أكثر من 10 آلاف دينار أو ما يعادلها بالعملات الأجنبية». والتفصيل في مقال بيانات المشتري في ملف فاتورة نظام الفوترة الوطني.
• تسلسل مصدر الدخل cac:SellerSupplierParty (ص18). يحمل العنصر cbc:ID فيه تسلسل مصدر الدخل الذي اختاره المكلف عند ربط الأجهزة. والخطأ في هذه القيمة من الأسباب التي يذكرها الدليل لرسالة الخطأ 500، وشرح التسلسل في مقال تسلسل مصدر الدخل في نظام الفوترة الوطني.

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

ما يغيب عن ملف فاتورة الدخل ولماذا يهمك

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

1. لا مجموع ضريبة في رأس الفاتورة. في فاتورة ضريبة المبيعات العامة يحمل cac:TaxTotal على مستوى الفاتورة مجموع قيمة الضريبة العامة. هذا العنصر غير موجود في مثال الدخل، وتنتقل الإجماليات من كتلة الخصم مباشرة إلى cac:LegalMonetaryTotal.
2. لا فئة ضريبة ولا نسبة في البند. البند في فاتورة الدخل يحمل الكمية والسعر والخصم والاسم فقط. فلا يظهر فيه العنصر الذي يحمل الفئة S أو Z أو O، ولا نسبة الضريبة، ولا قيمة الضريبة، ولا المبلغ الشامل للضريبة في البند.
3. لا تُطبّق قيود نسبة الضريبة. قائمة النسب التي يقبلها النظام، وشرط النسبة 0% في أنواع التعامل غير المحلية، وقاعدة الفئة عند الصفر، كلها قيود على بنود الضريبة. وفاتورة الدخل خالية من هذه البنود.

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

كتلة الإجماليات بلا ضريبة في الصفحتين 18 و19

تأتي الكتلة E بعنوان «المدخلات الخاصة بإجمالي فاتورة الدخل»، وفيها عنصران، هما كتلة الخصم على مستوى الفاتورة ثم cac:LegalMonetaryTotal. ويعرض المقطع التالي ترتيبهما.

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="JO"><!-- مجموع خصومات البنود --></cbc:Amount>
</cac:AllowanceCharge>
<cac:LegalMonetaryTotal>
  <cbc:TaxExclusiveAmount currencyID="JO"><!-- مجموع الكمية × سعر الوحدة --></cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="JO"><!-- إجمالي الفاتورة --></cbc:TaxInclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="JO"><!-- مجموع خصومات البنود --></cbc:AllowanceTotalAmount>
  <cbc:PayableAmount currencyID="JO"><!-- إجمالي الفاتورة --></cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<!-- لا يوجد عنصر cac:TaxTotal في فاتورة الدخل -->

وتقرأ هذا المقطع على النحو التالي.

• الخصم على مستوى الفاتورة. العنصر ChargeIndicator قيمته الثابتة false، وسبب الخصم discount، والمبلغ هو مجموع خصومات البنود. ويقول الدليل إن النظام لا يقبل الخصم على الفاتورة بشكل عام، فإذا كان نظامك يحسب الخصم على إجمالي الفاتورة وجب توزيعه على البنود قبل الإرسال.
• TaxExclusiveAmount. إجمالي الفاتورة قبل الخصم، أي مجموع حاصل ضرب الكمية في سعر الوحدة لكل البنود.
• AllowanceTotalAmount. مجموع قيمة الخصم، ويجب أن يساوي هو ومبلغ كتلة الخصم السابقة مجموع خصومات البنود.
• TaxInclusiveAmount وPayableAmount. يصف القالب العنصرين بالعبارة نفسها «إجمالي الفاتورة».

وتكرر الصفحة نفسها ملاحظة التقريب التي ترافق كل مبلغ في الدليل، ونصها «يمكن التقريب لغاية (3) خانات عشرية و بحد أعلى (9) خانات عشرية بحيث أن الفرق يكون أقل من أو يساوي (0.001)». وتستخدم أمثلة الدليل القيمة JO في السمة currencyID لكل مبلغ، والدليل لا يذكر هل يقبل النظام قيمًا غيرها في هذه السمة.

البنود InvoiceLine في الصفحتين 20 و21

الكتلة F هي البنود، ويتكرر فيها العنصر cac:InvoiceLine مرة لكل سلعة أو خدمة. ويعرض المقطع التالي بندًا واحدًا بالترتيب الذي يورده الدليل.

<cac:InvoiceLine>
  <cbc:ID><!-- رقم تسلسلي لا يتكرر في الفاتورة --></cbc:ID>
  <cbc:InvoicedQuantity unitCode="PCE"><!-- الكمية أكبر من صفر --></cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="JO"><!-- الكمية × سعر الوحدة − الخصم --></cbc:LineExtensionAmount>
  <cac:Item>
    <cbc:Name><!-- وصف السلعة أو الخدمة --></cbc:Name>
  </cac:Item>
  <cac:Price>
    <cbc:PriceAmount currencyID="JO"><!-- سعر الوحدة --></cbc:PriceAmount>
    <cac:AllowanceCharge>
      <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
      <cbc:AllowanceChargeReason>DISCOUNT</cbc:AllowanceChargeReason>
      <cbc:Amount currencyID="JO"><!-- قيمة خصم البند بالموجب --></cbc:Amount>
    </cac:AllowanceCharge>
  </cac:Price>
</cac:InvoiceLine>

ولكل عنصر في البند قاعدة يذكرها الدليل.

• cbc:ID. رقم تسلسلي خاص بكل سلعة أو خدمة، ولا يتكرر على مستوى الفاتورة الواحدة. وتكراره يُرفض برسالة The ID number must be unique. واحفظ هذا الرقم في نظامك، لأن فاتورة الإرجاع تطابق البنود به.
• cbc:InvoicedQuantity. الكمية أكبر من صفر وبحد أعلى 9 خانات عشرية. والوحدة PCE هي الوحدة الوحيدة الظاهرة في بنود الفواتير الجديدة، ولا يذكر الدليل قائمة بوحدات أخرى.
• cbc:LineExtensionAmount. حاصل ضرب الكمية في سعر الوحدة مطروحًا منه خصم البند.
• cbc:PriceAmount. سعر الوحدة، عدد صحيح أو عشري أكبر من صفر وبحد أعلى 9 خانات عشرية.
• خصم البند. قيمة بالموجب فقط وبحد أعلى 9 خانات عشرية.

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

أرقام المثال خطوة بخطوة

يضم مثال الدليل بندين، ويمكن تتبع أرقامهما حتى الإجمالي كما يلي.

فمجموع الكمية مضروبة في السعر للبندين 66 و50، أي 116.000، وهو TaxExclusiveAmount. ومجموع الخصمين 2 و5 هو 7.000، ويظهر في كتلة الخصم وفي AllowanceTotalAmount. والمبلغ المستحق 109.000، وهو في المثال الفرق بين 116.000 و7.000، ويساوي مجموع LineExtensionAmount للبندين (64 و45). وهذا التحقق البسيط يفيدك قبل الإرسال، فرسائل الرفض المرتبطة بحساب المجاميع مشروحة في مقال رسالة Total General Amount is Not Correct.

مقارنة مثال الدخل بمثال ضريبة المبيعات العامة

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

وطريقة حساب بنود مثال ضريبة المبيعات العامة مشروحة في مقال فاتورة فيها بند خاضع وبند معفى في نظام الفوترة الوطني.

ما لا تنقله من مثال فاتورة الدخل حرفيًا

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

• المعرّف الفريد في صفحة 14. يلاحظ في المثال أن المعرّف الفريد لا يأتي بالصيغة القياسية، فلا تنقله إلى ملفك. ويولّد نظامك المعرّف بنفسه ويحفظه.
• صيغة التاريخ. اعتمد الصيغة yyyy-mm-dd كما في أمثلة XML كلها، ولا تأخذ ترتيبًا آخر من نص منسوخ من الدليل.
• القيم التوضيحية. الأرقام والأسماء في المثال توضيحية، والمتغيرات المظللة تملؤها من بيانات فاتورتك. أما الوصف الثابت فتنقله كما هو.

ومواضع الانتباه في أمثلة الدليل كلها مجمعة بصفحاتها في مقال أمثلة الدليل التقني لنظام الفوترة الوطني. ومثال إرجاع فاتورة الدخل الذي يلي هذا المثال في الصفحات 22 إلى 31 يتناوله مقال مستقل عن مثال XML لإرجاع فاتورة الدخل، وفيه يعيد الإرجاع استخدام رمز name الخاص بالفاتورة الأصلية مع تغيير قيمة العنصر إلى 381.

قائمة فحص قبل بناء ملف فاتورة دخل

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

1. وسم Invoice الافتتاحي على سطر واحد، وcbc:ProfileID بالقيمة reporting:1.0.
2. رقم الفاتورة والمعرّف الفريد محفوظان في نظامك، ويُعاد استخدامهما كما هما عند إعادة الإرسال.
3. التاريخ بالصيغة yyyy-mm-dd.
4. قيمة InvoiceTypeCode هي 388، والرقم الثالث في السمة name هو 1.
5. عداد الفاتورة ICV تسلسلي يبدأ من 1.
6. تسلسل مصدر الدخل في cac:SellerSupplierParty مطابق للتسلسل المرتبط ببيانات الربط.
7. اسم المشتري موجود إذا كانت الفاتورة ذممًا أو نقدية تتجاوز الحد المذكور.
8. لا توجد أي كتلة cac:TaxTotal في الملف، لا في الرأس ولا في البنود.
9. أرقام البنود غير مكررة، والكميات والأسعار أكبر من صفر، والخصومات بالموجب.
10. مبلغ كتلة الخصم وAllowanceTotalAmount يساويان مجموع خصومات البنود.
11. TaxExclusiveAmount يساوي مجموع الكمية مضروبة في السعر لكل البنود.
12. الحكم على نتيجة الإرسال يكون من حالة الفاتورة العائدة في الرد، لا من رمز الاستجابة التقني وحده.

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

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

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

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

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

هل يحتوي مثال XML لفاتورة الدخل على عنصر TaxTotal؟

لا يحتوي عليه. فاتورة الدخل لا تحمل كتلة cac:TaxTotal على مستوى الفاتورة ولا على مستوى البند، وتنتقل الإجماليات في المثال من كتلة الخصم إلى cac:LegalMonetaryTotal مباشرة.

ما رمز نوع فاتورة الدخل المحلية في ملف XML؟

يكون الرمز 011 للفاتورة المحلية النقدية و021 للفاتورة المحلية الذمم، ويوضع في السمة name للعنصر cbc:InvoiceTypeCode، بينما تكون قيمة العنصر 388 للفاتورة الجديدة.

كيف يُحسب إجمالي فاتورة الدخل في مثال الدليل؟

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

هل أستطيع إرسال مثال الدليل كما هو لاختبار الربط؟

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

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

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

هل اسم المشتري إجباري في فاتورة الدخل؟

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

المراجع

• دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، ص10 إلى ص21 وص33 وص40 وص43 وص44 وص101 وص102 وص104.