المعرّف الفريد UUID في الفاتورة الإلكترونية

المعرّف الفريد UUID حقل إلزامي في كل فاتورة إلكترونية تصدر ضمن المرحلة الثانية من الفوترة الإلكترونية في السعودية. وظيفته بسيطة في جوهرها: يمنح كل مستند فاتورة بصمة عالمية لا تتكرر، تميّزه عن أي فاتورة أخرى صدرت أو ستصدر، سواء في نظامك أو في أي نظام آخر في العالم. هذا التوثيق التقني موجّه للمطوّرين ومسؤولي التكامل الذين يبنون أو يصلون أنظمتهم مع منصة الفاتورة الإلكترونية ومنصة فاتورة التابعة لهيئة الزكاة والضريبة والجمارك (ZATCA).

سنركّز هنا على حقل UUID وحده: ما هو، ما صيغته، أين يقع داخل ملف XML، كيف يختلف عن رقم الفاتورة المقروء (cbc:ID) وعن العدّاد التسلسلي ICV، وكيف تولّده الأنظمة المحاسبية. أما حقل العدّاد ICV وحقل تجزئة الفاتورة السابقة PIH فلكلٍّ منهما توثيق منفصل نشير إليه في موضعه.

ما هو المعرّف الفريد UUID؟

UUID اختصار لـ Universally Unique Identifier، أي «المعرّف الفريد عالميًا». وهو سلسلة من 32 رقمًا سداسيًا عشريًا (hexadecimal) موزّعة على خمس مجموعات يفصل بينها أربع شرطات، بطول إجمالي 36 محرفًا. الهدف من المعيار أن يولّد نظامان مختلفان قيمتين دون أي تنسيق بينهما، مع احتمال تطابق ضئيل إلى درجة يمكن إهماله عمليًا.

في سياق الفوترة الإلكترونية، تطلب الهيئة أن تحمل كل فاتورة قيمة UUID خاصة بها داخل ملف XML. هذه القيمة هي المعرّف الذي تستخدمه منصة فاتورة لتمييز المستند في عمليات المصادقة (Clearance) للفواتير بين المنشآت، والإبلاغ (Reporting) لفواتير المستهلك. القيمة تُولّد مرة واحدة عند إنشاء الفاتورة، ولا تتغير بعدها أبدًا.

المعيار الذي يحكم بنية UUID هو RFC 4122. ويعرّف هذا المعيار عدة إصدارات (versions) من المعرّف، تختلف في طريقة التوليد. الإصدار المستخدم في الفوترة الإلكترونية هو الإصدار الرابع (UUID version 4)، وهو الإصدار المبني على أرقام عشوائية، وسنفصّله بعد قليل.

صيغة UUID ومكوّناته

تتكوّن قيمة UUID من خمس مجموعات من المحارف السداسية العشرية، على النمط 8-4-4-4-12. أي ثماني محارف، ثم أربع، ثم أربع، ثم أربع، ثم اثنتا عشرة، يفصل بينها شرطات. إليك مثالًا فعليًا لقيمة صالحة:

3cf5a3b9-7b1e-4f2a-9c84-1d6e2f0a8b47

كل محرف يأخذ قيمة من المجموعة 0-9 وa-f، وهي طريقة تمثيل البايتات الستة عشر التي يتكوّن منها المعرّف (128 بت). توزيع المحارف على النحو التالي:

• المجموعة الأولى: 8 محارف.
• المجموعة الثانية: 4 محارف.
• المجموعة الثالثة: 4 محارف، وتبدأ بالرقم 4 في الإصدار الرابع.
• المجموعة الرابعة: 4 محارف، ويأخذ محرفها الأول إحدى القيم 8 أو 9 أو a أو b.
• المجموعة الخامسة: 12 محرفًا.

هذان الموضعان المحجوزان (الرقم 4 في بداية المجموعة الثالثة، والقيمة المحدّدة في بداية المجموعة الرابعة) ليسا تفصيلًا شكليًا. هما اللذان يخبران أي نظام يقرأ القيمة أنها من الإصدار الرابع وأنها تتبع تخطيط المتغير القياسي (variant) في RFC 4122. أي مولّد صحيح لـ UUID v4 يضبط هذين الموضعين تلقائيًا.

لماذا الإصدار الرابع تحديدًا؟

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

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

تشريح بنية المعرّف الفريد

البنية الداخلية على مستوى البتات

قيمة UUID في جوهرها عدد طوله 128 بت، أي 16 بايت. تمثيل المحارف السداسية العشرية الست والثلاثين ليس إلا طريقة قراءة بشرية لهذه البتات. عند توليد الإصدار الرابع، يجري حجز ست بتات لأغراض المعيار: أربع بتات تحدّد رقم الإصدار، وتُضبط على القيمة الثنائية المقابلة للرقم 4، وبتّان أو ثلاث تحدّد المتغير (variant) وتُضبط على نمط RFC 4122 القياسي. تبقى 122 بت تُملأ بقيم شبه عشوائية.

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

يترتّب على ذلك مبدأ عملي مهم: لا تعتمد على ترتيب قيم UUID لاستنتاج ترتيب زمني. القيمة عشوائية بالكامل، فلا تدل على من صدر أولًا، ولا تصلح مفتاحًا للفرز الزمني. إن احتجت ترتيبًا زمنيًا فاعتمد على تاريخ ووقت الإصدار cbc:IssueDate وcbc:IssueTime، أو على عدّاد ICV التسلسلي.

أين يقع UUID داخل ملف XML؟

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

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>INV-2026-000142</cbc:ID>
  <cbc:UUID>3cf5a3b9-7b1e-4f2a-9c84-1d6e2f0a8b47</cbc:UUID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cbc:IssueTime>13:45:30</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
</Invoice>

لاحظ الفرق بين السطرين: cbc:ID يحمل رقم الفاتورة الذي يراه المحاسب والعميل (مثل INV-2026-000142)، بينما cbc:UUID يحمل المعرّف الفريد التقني الذي تتعامل معه الأنظمة ومنصة فاتورة. كلاهما إلزامي، ولكلٍّ دور مختلف تمامًا.

المعرّف الفريد UUID نفسه يدخل لاحقًا ضمن البيانات التي يُحسب عليها الختم المشفّر وتجزئة المستند، فهو جزء من سلامة الفاتورة وليس حقلًا تجميليًا. أي تعديل عليه بعد التوليد يفسد المستند ويجعله غير مقبول لدى الهيئة.

الفرق بين UUID ورقم الفاتورة cbc:ID

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

رقم الفاتورة cbc:ID رقم تسلسلي تجاري مقروء للبشر. تختاره المنشأة وتنظّمه كما تشاء، غالبًا بتسلسل متصاعد مثل INV-2026-000142. هذا الرقم يظهر على نسخة العميل، ويُستخدم في المراسلات والمطابقات المحاسبية. شرطه الأساسي أن يكون فريدًا داخل سجلات المنشأة نفسها.

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

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

UUID مقابل رقم الفاتورة في لمحة

التحقق من صحة قيمة UUID

قبل أن يقبل أي نظام قيمة UUID، يتحقق من مطابقتها للصيغة المتوقعة. التحقق هنا شكلي بحت: لا يتأكد من «صحة» الفاتورة، بل من أن السلسلة مكتوبة بالنمط الصحيح وأنها فعلًا من الإصدار الرابع. أبسط أداة لذلك تعبير نمطي (regular expression) يفحص النمط 8-4-4-4-12 ويتأكد من موضع رقم الإصدار وموضع المتغير.

// نمط تحقق من UUID v4 (أحرف صغيرة)
^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

لاحظ في التعبير أعلاه أن المجموعة الثالثة تبدأ حتمًا بالرقم 4، وأن المجموعة الرابعة تبدأ بإحدى القيم 8 أو 9 أو a أو b. هذان الشرطان هما ما يميّز الإصدار الرابع عن غيره من الإصدارات. لو سمح التعبير بأي محرف في هذين الموضعين، لقَبِل قيمًا من إصدارات أخرى لا تتوافق مع متطلب الفوترة الإلكترونية.

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

تخزين UUID وربطه عبر الـ API

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

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

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

UUID عبر دورة حياة الفاتورة

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

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

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

UUID في بيئة متعددة الفروع ونقاط البيع

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

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

الفرق بين UUID والعدّاد ICV

إلى جانب رقم الفاتورة والمعرّف الفريد، تطلب المرحلة الثانية حقلًا ثالثًا هو عدّاد الفاتورة ICV (Invoice Counter Value). والخلط بين UUID وICV شائع لأن كليهما حقل تقني يولّده النظام. لكن الفرق جوهري.

عدّاد ICV رقم صحيح تسلسلي متصاعد يبدأ من 1 ويزداد بمقدار واحد مع كل فاتورة يصدرها الجهاز نفسه. مهمته إثبات أن تسلسل الفواتير متصل لا فجوة فيه، فلو قفز العدّاد من 50 إلى 52 دلّ ذلك على فاتورة محذوفة أو مفقودة. أي أن ICV حقل تسلسلي ترتيبي بطبيعته.

المعرّف الفريد UUID على النقيض تمامًا: قيمة عشوائية لا ترتيب فيها ولا تتابع. لا يمكن من قيمتين UUID أن تعرف أيهما صدرت أولًا، بينما عدّاد ICV يخبرك بذلك فورًا. باختصار: UUID يجيب عن «هل هذه الفاتورة فريدة؟»، وICV يجيب عن «هل تسلسل الفواتير متصل؟». لكلٍّ دور لا يغني عن الآخر، ولتفصيل عدّاد ICV توثيق مستقل ضمن هذا القسم التقني.

علاقة UUID بتجزئة الفاتورة السابقة PIH

الحقل التقني الثالث في سلسلة سلامة الفاتورة هو تجزئة الفاتورة السابقة PIH (Previous Invoice Hash). وهو بصمة SHA-256 للفاتورة التي سبقت الفاتورة الحالية، تُدرج داخل الفاتورة الحالية لتربطها بسابقتها في سلسلة متصلة لا يمكن العبث بها دون كشف.

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

الحقول الثلاثة في سلسلة سلامة الفاتورة

كيف تولّد الأنظمة قيمة UUID؟

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

// JavaScript (Node.js 14.17+ أو المتصفح الحديث)
const uuid = crypto.randomUUID();
// النتيجة: "3cf5a3b9-7b1e-4f2a-9c84-1d6e2f0a8b47"

# Python
import uuid
value = str(uuid.uuid4())

// PHP (مكتبة ramsey/uuid)
use Ramsey\Uuid\Uuid;
$value = Uuid::uuid4()->toString();

// Java
import java.util.UUID;
String value = UUID.randomUUID().toString();

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

أخطاء شائعة عند توليد UUID

• استخدام إصدار غير الرابع (مثل الإصدار الأول المبني على الوقت وعنوان الجهاز) دون قصد. تحقّق أن الدالة المستخدمة هي uuid4 أو ما يكافئها.
• إعادة توليد القيمة في كل بناء للملف بدل تخزينها، فينتج معرّف مختلف عن المرسل سابقًا.
• كتابة المحارف بأحرف كبيرة (uppercase) حين يتوقع النظام أحرفًا صغيرة. اعتمد الأحرف الصغيرة لتفادي اختلافات المطابقة.
• إقحام الشرطات في غير مواضعها أو حذفها كليًا، فيرفض المتحقّق الصيغة.
• الخلط بين قيمة UUID ورقم الفاتورة cbc:ID في الكود، فتوضع إحداهما مكان الأخرى داخل XML.

UUID في تنسيق UBL 2.1 ورمز QR

الفوترة الإلكترونية في السعودية تعتمد تنسيق UBL 2.1 لمستند XML. وحقل cbc:UUID جزء قياسي من هذا التنسيق، يقع في رأس المستند ولا يتكرر. المعرّف الفريد لا يدخل ضمن وسوم رمز الاستجابة السريعة QR التسعة المطلوبة للفاتورة المبسّطة بشكل مباشر، لكنه جزء من بيانات المستند التي يُبنى عليها الختم المشفّر، والختم نفسه أحد وسوم QR.

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

لماذا يهتم المتحقّق بقيمة UUID؟

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

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

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

كيف يتعامل قيود مع المعرّف الفريد UUID؟

قيود نظام محاسبي متوافق مع المرحلة الثانية من الفوترة الإلكترونية. عند إصدار أي فاتورة ضريبية أو إشعار دائن أو مدين، يولّد قيود قيمة UUID صالحة بصيغة الإصدار الرابع ويدرجها في الموضع الصحيح داخل ملف XML المبني وفق UBL 2.1، دون أي إعداد يدوي من المستخدم.

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

للمطوّرين الذين يحتاجون الملف الخام، يوفّر قيود زر تنزيل XML للفاتورة، كما يصدر نسخة PDF/A-3 يُضمَّن داخلها ملف XML الضريبي كمرفق، بما يطابق متطلب الصيغة العرضية في المرحلة الثانية. هذا يعني ملفًا واحدًا للعميل بدل ملفين منفصلين.

أسئلة شائعة عن المعرّف الفريد UUID

هل يجب أن أكتب قيمة UUID بنفسي؟

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

هل يمكن أن تتكرر قيمتا UUID لفاتورتين؟

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

ما الفرق بين UUID ورقم الفاتورة؟

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

أين أجد قيمة UUID في الفاتورة؟

تقع في العنصر cbc:UUID في رأس ملف XML، بعد رقم الفاتورة cbc:ID وقبل تاريخ الإصدار. لا تظهر عادة على النسخة المطبوعة للعميل.

هل يتغير UUID إذا عدّلت الفاتورة؟

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

ما علاقة UUID بعدّاد ICV وتجزئة PIH؟

الثلاثة معًا يثبتون سلامة الفاتورة: UUID يميّز المستند، وعدّاد ICV يثبت اتصال التسلسل، وتجزئة PIH تربط الفاتورة بسابقتها في سلسلة محمية من العبث.

خلاصة تقنية

المعرّف الفريد UUID حقل إلزامي بصيغة الإصدار الرابع، يقع في العنصر cbc:UUID داخل ملف XML بتنسيق UBL 2.1، ويميّز كل فاتورة تمييزًا عالميًا. يختلف عن رقم الفاتورة cbc:ID المقروء، وعن عدّاد ICV التسلسلي، وعن تجزئة PIH الرابطة. تولّده الأنظمة تلقائيًا مرة واحدة وتخزّنه ثابتًا. للمزيد عن بقية الحقول التقنية راجع توثيق ملف XML للفاتورة الإلكترونية وبنية الفاتورة الإلكترونية، وللصورة الكاملة عن المتطلبات النظامية راجع دليل الفاتورة الإلكترونية وضريبة القيمة المضافة.