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

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

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

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

ما الذي يعرضه مثال XML لإرجاع فاتورة الدخل في نظام الفوترة الوطني

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

1. الإرجاع على الكميات فقط. نص الملاحظة «يسمح النظام بالارجاع على الكميات فقط».
2. لا تجاوز للكمية المباعة. لا يقبل النظام إرجاع كمية أكبر من الكمية المباعة في الفاتورة الأصلية.
3. إرجاع متعدد على الفاتورة نفسها. يسمح النظام بإرسال فاتورة إرجاع على الفاتورة الأصلية مرة واحدة أو أكثر حتى تنتهي جميع كمياتها المباعة.

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

خريطة أقسام المثال من صفحة 23 إلى صفحة 31

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

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

رأس فاتورة الإرجاع ومرجع الفاتورة الأصلية (القسم A)

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

هذا مقطع مختصر يتبع ترتيب القالب، والتعليقات العربية تصف القيمة التي يملؤها نظامك في كل عنصر.

<cbc:ID>…</cbc:ID>  <!-- رقم فاتورة الإرجاع نفسها -->
<cbc:UUID>…</cbc:UUID>  <!-- المعرّف الفريد لفاتورة الإرجاع، يولّده نظامك ويحفظه -->
<cbc:IssueDate>…</cbc:IssueDate>  <!-- تاريخ الإرجاع بالصيغة yyyy-mm-dd -->
<cbc:InvoiceTypeCode name="…">381</cbc:InvoiceTypeCode>  <!-- name هو رمز الفاتورة الأصلية نفسه -->
<cbc:Note>…</cbc:Note>  <!-- اختياري -->
<cbc:DocumentCurrencyCode>…</cbc:DocumentCurrencyCode>  <!-- عملة الفاتورة الأصلية -->
<cbc:TaxCurrencyCode>…</cbc:TaxCurrencyCode>  <!-- عملة الفاتورة الأصلية -->
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>…</cbc:ID>  <!-- رقم الفاتورة الأصلية -->
    <cbc:UUID>…</cbc:UUID>  <!-- المعرّف الفريد للفاتورة الأصلية -->
    <cbc:DocumentDescription>…</cbc:DocumentDescription>  <!-- القيمة الإجمالية للفاتورة الأصلية -->
  </cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>ICV</cbc:ID>  <!-- قيمة ثابتة -->
  <cbc:UUID>…</cbc:UUID>  <!-- قيمة عداد الفاتورة -->
</cac:AdditionalDocumentReference>

وفيما يلي ما يعنيه كل عنصر وما يحكمه.

• رقم فاتورة الإرجاع ومعرّفها الفريد. العنصران cbc:ID وcbc:UUID في الرأس يخصان فاتورة الإرجاع، وهما معًا المفتاح الأساسي لها كما لكل فاتورة. ويولّد نظامك المعرّف ويحفظه، ثم يعيد استعماله إذا أعاد إرسال الفاتورة نفسها، والقاعدة مشروحة في مقال المعرّف الفريد UUID في نظام الفوترة الوطني.
• تاريخ الإرجاع. يُكتب cbc:IssueDate بالصيغة yyyy-mm-dd، كما في جميع أمثلة XML في الدليل.
• الملاحظة. العنصر cbc:Note مظلل بالأخضر، أي اختياري. ويلاحظ أن قالب إرجاع فاتورة الدخل يحتفظ به، في حين يخلو منه قالبا إرجاع ضريبة المبيعات العامة والخاصة (ص23 وص46 وص73).
• العملة. يحمل العنصران cbc:DocumentCurrencyCode وcbc:TaxCurrencyCode القيمة JOD في القالب. وتنص الملاحظة الحمراء في صفحة 24، بعد قاعدة اختيار نوع الإرجاع حسب الفاتورة الأصلية، على أنه «ينطبق هذا ايضا على العملات»، فعملة الإرجاع هي عملة الفاتورة الأصلية.
• مرجع الفاتورة الأصلية. تحمل كتلة cac:InvoiceDocumentReference ثلاثة عناصر، هي رقم الفاتورة الأصلية ومعرّفها الفريد وقيمتها الإجمالية في cbc:DocumentDescription. والقيمة هنا إجمالي الفاتورة الأصلية، لا إجمالي الإرجاع. وتفصيل هذه الكتلة في مقال مرجع الفاتورة الأصلية في نظام الفوترة الوطني.
• عداد الفاتورة. تحمل كتلة cac:AdditionalDocumentReference القيمة الثابتة ICV في المعرّف، وفي cbc:UUID قيمة العداد، وهو بنص الدليل «عداد يتم إنشاؤه من قبل المكلف للفواتير الإلكترونية يبدأ بشكل تسلسلي من 1 الى ما لانهاية» (ص13). وشرحه في مقال عداد الفاتورة ICV في نظام الفوترة الوطني.

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

رمز النوع 381 وسمة name في إرجاع فاتورة الدخل

يحمل العنصر cbc:InvoiceTypeCode معلومتين. قيمته تبيّن هل الفاتورة جديدة أم إرجاع، وسمته name تحمل رمزًا من ثلاث خانات يصف نوع الفاتورة. والقيمة في كل فاتورة إرجاع هي 381، مقابل 388 للفاتورة الجديدة.

أما رمز السمة فلا يُختار من جديد. فالدليل ينص على أنه «يتم اختيار نوع فاتورة الارجاع حسب النوع المختار في الفاتورة الاصلية»، ثم يورد أمثلة لإرجاع فواتير الدخل هي 011 و021 و111 و121، ويصفها بأنها «على سبيل المثال لا الحصر». وقراءة الخانات الثلاث على هذا النحو.

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

فإذا كانت الفاتورة الأصلية فاتورة دخل محلية نقدية برمز 011، كُتب الإرجاع name="011" بالقيمة 381. ويستخدم مثال الدليل هذا الرمز نفسه. ولا يتضمن الدليل مثالًا كاملًا لإرجاع فاتورة ذمم أو لأي نوع غير محلي، وإنما سطور رمز النوع وحدها.

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

البائع والمشتري وتسلسل مصدر الدخل (الأقسام B وC وD)

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

بيانات البائع (القسم B). تحمل الكتلة cac:AccountingSupplierParty رمز الدولة JO، والرقم الضريبي للبائع في cbc:CompanyID، والقيمة الثابتة VAT في نظام الضريبة، واسم البائع في cbc:RegistrationName كما هو مسجل في دائرة ضريبة الدخل والمبيعات.

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

تسلسل مصدر الدخل (القسم D). تحمل الكتلة cac:SellerSupplierParty في cbc:ID قيمة تسلسل مصدر الدخل، وهي إجبارية في كل إرسال. ويذكر الدليل في صفحة 101 أن من أسباب خطأ الخادم 500 «خطأ في الرقم الضريبي أو تسلسل مصدر الدخل وبدرجة أقل يكون الخطأ في ال Client_ID أو ال Secret_Key». ومعنى هذا الحقل ومكانه في مقال تسلسل مصدر الدخل في نظام الفوترة الوطني.

سبب الإرجاع في PaymentMeans (القسم E)

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

تتكون الكتلة cac:PaymentMeans من عنصرين.

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

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

مجاميع الإرجاع دون كتلة ضريبة (القسم F)

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

تقع المجاميع في القسم F في صفحتي 28 و29، وتتبع معادلات الدليل نفسها التي تتبعها فاتورة البيع.

• cac:AllowanceCharge على مستوى الفاتورة. يحمل ChargeIndicator بالقيمة false، والسبب discount، وقيمة تساوي مجموع خصومات البنود.
• TaxExclusiveAmount. مجموع حاصل ضرب الكمية في سعر الوحدة لكل البنود.
• AllowanceTotalAmount. مجموع خصومات البنود، ويجب أن يساوي القيمة في AllowanceCharge أعلاه.
• TaxInclusiveAmount وPayableAmount. إجمالي الفاتورة. وفي مثال فاتورة الدخل يساوي كل منهما قيمة البنود قبل الخصم مطروحًا منها الخصم، أي 116.000 ناقص 7.000 يساوي 109.000.

وبما أن بنود الإرجاع تُكتب بالكميات المرجعة وحدها، وبما أن كل هذه المجاميع تُحسب من البنود، فإن مجاميع الإرجاع تخص الجزء المرجع فقط، لا الفاتورة الأصلية كلها. وهذا ما يصفه الدليل صراحة في قسم إرجاع ضريبة المبيعات العامة بعبارة «الجزء المراد ارجاعه» (ص51 وص52)، وفي قسم إرجاع ضريبة المبيعات الخاصة بعبارة «المراد ارجاعها» (ص78 وص79). ولا تخلط بين هذه المجاميع والقيمة في cbc:DocumentDescription داخل الرأس، فتلك إجمالي الفاتورة الأصلية كما سبق.

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

بنود الإرجاع: ما يبقى كما في الأصلية وما يتغير (القسم G)

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

ثلاث نتائج عملية تترتب على هذه القواعد لمن يبرمج الإرجاع.

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

أرقام المثال لا تطابق فاتورة الدخل الأصلية

قبل أن تستعمل المثال في اختبار، انتبه إلى أن أرقامه لا تتطابق مع مثال فاتورة الدخل الذي يسبقه في الدليل. فقيمة cbc:DocumentDescription في مثال الإرجاع 64.000، في حين أن إجمالي فاتورة الدخل الأصلية في مثالها 109.000 (ص19 وص25). والمفترض في هذا العنصر أن يحمل إجمالي الفاتورة الأصلية كما تقدم.

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

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

قائمة فحص قبل إرسال إرجاع فاتورة دخل

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

1. الفاتورة الأصلية مقبولة ومحفوظة. لديك رقمها ومعرّفها الفريد وإجماليها وبيانات مشتريها وبنودها كما أُرسلت.
2. رأس الإرجاع له رقمه ومعرّفه. ولّد معرّفًا فريدًا للإرجاع واحفظه قبل أول إرسال، واكتب التاريخ بالصيغة yyyy-mm-dd.
3. رمز النوع منقول من الأصلية. السمة name هي رمز الفاتورة الأصلية نفسه، والقيمة 381، والعملة عملة الأصلية.
4. كتلة المرجع مكتملة. رقم الأصلية ومعرّفها وإجماليها في عناصرها الثلاثة.
5. بيانات المشتري مطابقة. منقولة من سجل الأصلية دون تعديل أو إضافة.
6. سبب الإرجاع مكتوب. الرمز 10 ونص السبب في cbc:InstructionNote.
7. البنود صحيحة. الرقم والاسم والسعر كما في الأصلية، والكمية المرجعة أكبر من صفر ولا تتجاوز الرصيد المتبقي، والخصم كامل أو جزئي حسب الكمية.
8. المجاميع محسوبة من بنود الإرجاع. لا كتلة ضريبة، والخصم على مستوى الفاتورة يساوي مجموع خصومات البنود.
9. الملف سليم البنية. وسم الفاتورة الافتتاحي في سطر واحد، والعنصر cbc:ProfileID بالقيمة reporting:1.0، ثم ترميز Base64.
10. الرد مقروء من الحالة. احكم على النتيجة من EINV_STATUS، فالحالة SUBMITTED تعني القبول ويعود معها رمز QR، والحالة NOT_SUBMITTED تعني الرفض مع رسالة الخطأ.

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

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

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

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

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

هل تحمل فاتورة إرجاع الدخل كتلة TaxTotal؟

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

ما قيمة InvoiceTypeCode في إرجاع فاتورة دخل محلية نقدية؟

تُكتب القيمة 381 مع السمة name=”011″، لأن رمز الإرجاع يُنقل من الفاتورة الأصلية. ويورد الدليل أيضًا 021 و111 و121 أمثلة لإرجاع فواتير الدخل الأخرى.

ماذا أكتب في DocumentDescription داخل كتلة المرجع؟

يُكتب فيه الإجمالي الكامل للفاتورة الأصلية المراد الإرجاع منها، لا إجمالي فاتورة الإرجاع. ولا تأخذ القيمة من مثال الدليل، فقيمة المثال 64.000 لا تطابق إجمالي فاتورة الدخل الأصلية في مثالها وهو 109.000.

هل أستطيع إرجاع جزء من كمية البند أكثر من مرة؟

يسمح الدليل بإرسال فاتورة إرجاع على الفاتورة الأصلية مرة واحدة أو أكثر حتى تنتهي جميع كمياتها المباعة. والشرط ألا يتجاوز مجموع ما يُرجع الكمية المباعة في الفاتورة الأصلية.

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

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

هل أنسخ مثال الإرجاع من الدليل وأرسله للتجربة؟

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

المراجع

• دائرة ضريبة الدخل والمبيعات، الدليل التقني للربط مع نظام الفوترة الوطني من خلال واجهة برمجة التطبيقات (API)، الإصدار 1.5، 2026، ص10 وص12 وص13 وص19 وص22 إلى ص31 وص46 وص51 وص52 وص73 وص78 وص79 وص101.