ترويسة الفاتورة (Invoice Header) في XML

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

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

ما المقصود بترويسة الفاتورة في XML؟

في معيار UBL 2.1 الذي تعتمده هيئة الزكاة والضريبة والجمارك (ZATCA)، الفاتورة عبارة عن عنصر جذر واحد اسمه <Invoice>. تحته تأتي مجموعتان من المعلومات: حقول على مستوى المستند تصف الفاتورة كوحدة واحدة، وحقول متكررة تصف الأطراف والبنود. الترويسة هي القسم الأول: الحقول التي تظهر مباشرة تحت عنصر الجذر وقبل كتل الأطراف (البائع والمشتري) وقبل بنود الفاتورة.

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

تنتمي معظم حقول الترويسة إلى مساحة الأسماء cbc (وهي اختصار Common Basic Components). الحقول التي تحمل بنية فرعية، مثل المراجع، تنتمي إلى cac (Common Aggregate Components). ستلاحظ هاتين البادئتين في كل مقتطف لاحق. الفرق بينهما بسيط: عناصر cbc تحمل قيمة مفردة مباشرة، بينما عناصر cac تجمع عدة عناصر فرعية تحتها. فهم هذا التمييز يسهّل قراءة أي ملف فاتورة لاحقًا.

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

<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">

  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>INV-2026-000128</cbc:ID>
  <cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cbc:IssueTime>11:42:18</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
  <cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>
</Invoice>

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

رقم الفاتورة (cbc:ID)

الحقل cbc:ID هو رقم الفاتورة التسلسلي الذي يحدده نظامك. هو معرّف قابل للقراءة البشرية يظهر على المستند المطبوع، ويختلف تمامًا عن المعرّف الفريد UUID الذي تولّده الأنظمة تلقائيًا. لا يجوز أن يكون فارغًا، ويجب أن يكون فريدًا داخل سلسلة فواتير المنشأة الواحدة.

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

<cbc:ID>INV-2026-000128</cbc:ID>

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

المعرّف الفريد (cbc:UUID)

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

تتكوّن قيمة UUID من 32 رقمًا ست عشريًا موزّعة على خمس مجموعات يفصلها شرطات، بالنمط 8-4-4-4-12. هذه الشرطات جزء من الصيغة القياسية للمعرّف وليست شرطات نصية في النثر. لا تعدّل القيمة بعد توليدها، فهي تدخل لاحقًا ضمن البيانات التي يُحسب عليها الختم الرقمي ورمز الاستجابة السريعة.

<cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>

الفرق الجوهري بين cbc:ID وcbc:UUID: الأول رقم تجاري يقرأه الإنسان ويتحكم به البائع، والثاني معرّف تقني تقرأه الأنظمة ويولّد آليًا. كلاهما إلزامي، وكلاهما يظهر في الترويسة، لكن لكل منهما دور مختلف تمامًا.

تاريخ الإصدار والوقت (IssueDate و IssueTime)

تُسجَّل لحظة إصدار الفاتورة في حقلين منفصلين. الأول cbc:IssueDate للتاريخ، والثاني cbc:IssueTime للوقت. هذا الفصل مقصود في المعيار، فلا تدمج التاريخ والوقت في حقل واحد.

يأخذ التاريخ صيغة ISO 8601 المختصرة وهي YYYY-MM-DD، أي السنة فالشهر فاليوم مفصولة بشرطات. والوقت يأخذ صيغة HH:MM:SS بنظام أربع وعشرين ساعة. التاريخ ميلادي دائمًا في ملف XML، حتى لو عرض نظامك التاريخ الهجري على واجهة المستخدم.

<cbc:IssueDate>2026-06-24</cbc:IssueDate>
<cbc:IssueTime>11:42:18</cbc:IssueTime>

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

خطأ شائع: استخدام شرطة مائلة بدل الشرطة العادية في التاريخ، أو كتابة الشهر قبل اليوم بالنمط الأمريكي. كلاهما يكسر التحقق من المخطط. التزم دائمًا بالصيغة YYYY-MM-DD حرفيًا.

رمز نوع الفاتورة ونوعها الفرعي (InvoiceTypeCode)

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

قيم نص العنصر: 388 و383 و381

نص العنصر يأخذ إحدى ثلاث قيم رئيسية محددة في قائمة رموز الأمم المتحدة UNCL1001 التي تعتمدها الهيئة:

عندما تصدر إشعارًا مدينًا أو دائنًا (383 أو 381)، يجب أن تربطه بالفاتورة الأصلية عبر كتلة المراجع التي نشرحها لاحقًا. الإشعار المعلّق دون فاتورة مرجعية يُرفض.

الرمز الفرعي في خاصية name

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

لذلك فاتورة ضريبية قياسية عادية تأخذ الرمز الفرعي 0100000، بينما الفاتورة المبسطة تأخذ 0200000. مقتطف لفاتورة قياسية:

<cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>

ومقتطف لفاتورة مبسّطة (B2C):

<cbc:InvoiceTypeCode name="0200000">388</cbc:InvoiceTypeCode>

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

عملة المستند وعملة الضريبة (DocumentCurrencyCode و TaxCurrencyCode)

تحمل الترويسة حقلين للعملة. الأول cbc:DocumentCurrencyCode يحدد العملة التي حُرّرت بها الفاتورة، والثاني cbc:TaxCurrencyCode يحدد العملة التي تُحسب بها الضريبة وتُبلَّغ بها الهيئة.

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

<cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
<cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>

القاعدة المهمة: عملة الضريبة يجب أن تكون SAR دائمًا للمنشآت العاملة في السعودية، حتى لو حُرّرت الفاتورة بعملة أجنبية. فلو أصدرت فاتورة تصدير بالدولار الأمريكي، يصبح DocumentCurrencyCode هو USD، بينما يبقى TaxCurrencyCode هو SAR، ويُضاف عندئذٍ حقل لسعر صرف الضريبة ضمن الفاتورة. هذا يضمن أن تصل قيمة الضريبة للهيئة بالعملة المحلية دائمًا.

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

المراجع: الفاتورة الأصلية والطلب والعقد (Billing References)

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

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

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>INV-2026-000110</cbc:ID>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

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

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

يُستخدم cac:AdditionalDocumentReference أيضًا لحمل معرّف بيانات التطبيق ورمز الاستجابة السريعة الذي يُولَّد بعد توقيع الفاتورة. ورغم ظهوره في الترويسة، فإن محتواه يعتمد على عملية التوقيع الرقمي التي تجري عبر شهادة CSID الخاصة بالمنشأة.

الملاحظات (cbc:Note)

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

<cbc:Note>إشعار دائن مقابل مرتجع جزئي على الفاتورة INV-2026-000110</cbc:Note>

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

معرّف الملف الشخصي ورقم العدّاد (ProfileID و ICV)

يكتمل وصف الترويسة بحقلين تقنيين يصفان سياق الفاتورة داخل المنظومة. الأول cbc:ProfileID الذي يحدد إصدار ملف الأعمال الذي تتبعه الفاتورة، وقيمته الثابتة في المرحلة الثانية هي reporting:1.0. هذا الحقل يظهر عادة في مقدمة الترويسة قبل رقم الفاتورة.

الثاني هو عدّاد قيمة الفاتورة (Invoice Counter Value) ويُعرف اختصارًا بـ ICV. هو رقم تسلسلي متزايد يربط كل فاتورة بسابقتها لضمان تسلسل غير منقطع داخل سلسلة المنشأة. يأتي ضمن cac:AdditionalDocumentReference بمعرّف ICV:

<cac:AdditionalDocumentReference>
  <cbc:ID>ICV</cbc:ID>
  <cbc:UUID>128</cbc:UUID>
</cac:AdditionalDocumentReference>

قيمة العدّاد هنا (128) ترتبط بترتيب الفاتورة ضمن السلسلة، وتُستخدم مع تجزئة الفاتورة السابقة (Previous Invoice Hash) لبناء سلسلة سلامة متصلة. هذا الربط هو ما يمنع التلاعب بالفواتير أو حذفها من المنتصف دون أثر.

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

مثال كامل: ترويسة فاتورة قياسية مقابل مبسّطة

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

ترويسة فاتورة ضريبية قياسية (B2B):

<cbc:ProfileID>reporting:1.0</cbc:ProfileID>
<cbc:ID>INV-2026-000128</cbc:ID>
<cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>
<cbc:IssueDate>2026-06-24</cbc:IssueDate>
<cbc:IssueTime>11:42:18</cbc:IssueTime>
<cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
<cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>

ترويسة فاتورة مبسّطة (B2C):

<cbc:ProfileID>reporting:1.0</cbc:ProfileID>
<cbc:ID>SI-2026-004519</cbc:ID>
<cbc:UUID>9b1d77a2-0c54-4f0e-bb71-5e2a9f1c33aa</cbc:UUID>
<cbc:IssueDate>2026-06-24</cbc:IssueDate>
<cbc:IssueTime>19:05:44</cbc:IssueTime>
<cbc:InvoiceTypeCode name="0200000">388</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
<cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>

القيمتان متطابقتان في نص InvoiceTypeCode (388 لأن كلتيهما فاتورة بيع)، والفرق الوحيد في خاصية name: القياسية تبدأ بـ 01 والمبسطة بـ 02. هذا الفرق الصغير يقرر المسار بالكامل: القياسية تذهب للمقاصة الفورية، والمبسطة للإبلاغ خلال 24 ساعة. كثير من حالات الرفض المبكر تنشأ من خطأ في هذه الخانة وحدها.

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

مراجع المستندات الإضافية بالتفصيل

كتلة cac:AdditionalDocumentReference تستحق وقفة، فهي تظهر أكثر من مرة في الترويسة بمعرّفات مختلفة، وكل ظهور له دور. أبرز ثلاثة معرّفات تستخدمها المرحلة الثانية:

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

<cac:AdditionalDocumentReference>
  <cbc:ID>PIH</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
      NWZlY2ViNjZmZmM4NmYzOGQ5NTI3ODZjNmQ2OTZjNzk=
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

القيمة هنا مرمّزة بصيغة Base64. لا تحاول قراءتها أو تعديلها يدويًا، فهي ناتج عملية تجزئة آلية. أي تغيير فيها يكسر سلسلة السلامة ويؤدي لرفض الفاتورة الحالية وكل ما يليها.

أما أمر الشراء فيأتي في كتلة منفصلة هي cac:OrderReference، وهو اختياري لكنه مفيد لربط الفاتورة بطلب الشراء الذي سبقها في دورة المشتريات:

<cac:OrderReference>
  <cbc:ID>PO-2026-0457</cbc:ID>
</cac:OrderReference>

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

كيف يتحقق النظام من صحة الترويسة قبل الإرسال؟

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

أول فحص هو التحقق من المخطط (XSD Validation). يتأكد المخطط من وجود الحقول الإلزامية، ومن صحة أنواع البيانات، ومن ترتيب العناصر الصحيح. لو غاب cbc:UUID أو جاء التاريخ بصيغة خاطئة، يفشل هذا الفحص فورًا.

الفحص الثاني هو فحص القواعد التجارية (Business Rules). هنا تُطبَّق منطقيات أعمق: هل الإشعار الدائن مرتبط بفاتورة أصلية؟ هل الرمز الفرعي يطابق نوع الفاتورة؟ هل عملة الضريبة هي SAR؟ هذه القواعد لا يفحصها المخطط وحده.

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

ممارسات جيدة عند التعامل مع حقول الترويسة

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

أولًا، ثبّت نمطًا واحدًا لرقم الفاتورة cbc:ID ولا تغيّره في منتصف السنة المالية. تغيير النمط يربك التسلسل ويصعّب التتبع. النمط الجيد يجمع بادئة تميّز نوع المستند (مثل INV للفواتير وSI للمبسطة وCN للإشعارات الدائنة) مع السنة ورقم متزايد بعدد خانات ثابت.

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

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

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

أين تقع الترويسة من بقية أجزاء الفاتورة؟

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

للاطلاع على الصورة الكاملة لترتيب هذه الكتل وعلاقتها ببعضها، راجع دليل بنية الفاتورة الإلكترونية (Invoice Structure). وللتعمق في كيفية تمثيل البنود والكميات والضرائب على مستوى السطر، فذلك موضوع دليل بنود الفاتورة (Invoice Lines) المنفصل الذي يكمل هذا المرجع.

ولفهم المعيار الذي تُبنى عليه كل هذه الحقول، اطّلع على معيار UBL 2.1 الذي يحدد مساحات الأسماء والعناصر، وعلى مخطط الفاتورة (Invoice Schema) الذي يفرض القيود البنيوية. أما لمحة عامة عن ملف الفاتورة بصيغة XML فتجدها في دليل فاتورة XML. والشهادة التي يُوقَّع بها الملف بعد اكتمال الترويسة موضحة في دليل شهادة CSID.

خلاصة مرجعية لحقول الترويسة

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

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