أخطاء المعرّف الفريد UUID

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

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

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

لماذا يرفض UUID الخاطئ الفاتورة كلياً

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

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

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

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

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

تفصيل أنماط الأخطاء الخمسة

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

الخطأ الأول: UUID مكرر بين فاتورتين

عرض المشكلة. تُرسل فاتورتين أو أكثر، فتُقبل الأولى وتُرفض الثانية برسالة تشير إلى أن المعرّف مستخدم سابقاً. status يعود ERROR، وحقل category يشير إلى تكرار المستند أو تعارض المعرّف.

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

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "DUPLICATE_UUID",
        "category": "DUPLICATE_DOCUMENT",
        "message": "Invoice UUID already exists for this taxpayer"
      }
    ],
    "warningMessages": []
  }
}

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

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

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

الخطأ الثاني: صيغة UUID غير صالحة

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

الصيغة الصحيحة هي نمط 8-4-4-4-12 من المحارف السداسية العشرية، بطول إجمالي 36 محرفاً تتضمن أربع شرطات. أي انحراف عن هذا النمط يرفض القيمة. هذا مثال لرفض بسبب صيغة خاطئة:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "INVALID_UUID_FORMAT",
        "category": "XML_SCHEMA",
        "message": "cbc:UUID value does not match the required UUID pattern"
      }
    ],
    "warningMessages": []
  }
}

السبب الجذري. القيمة المرسلة ليست UUID صحيحاً. أمثلة شائعة: طول خاطئ (أقل أو أكثر من 36 محرفاً)، أو محارف خارج المجموعة المسموحة (حروف غير a إلى f، أو رموز)، أو حذف الشرطات، أو استخدام معرّف ليس من الإصدار الرابع. الإصدار الرابع يميّزه الرقم 4 في بداية المجموعة الثالثة، وقيمة من 8 أو 9 أو a أو b في بداية المجموعة الرابعة.

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

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

الخطأ الثالث: حقل cbc:UUID مفقود كلياً

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

لأن UUID حقل إلزامي في مخطط UBL، فغيابه يوقف التحقق قبل النظر في أي قيمة أخرى. الرسالة تشير إلى العنصر cbc:UUID بالاسم:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "XSD_SCHEMA_INVALID",
        "category": "XML_SCHEMA",
        "message": "Element 'cbc:UUID' is required but was not found"
      }
    ],
    "warningMessages": []
  }
}

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

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

الخطأ الرابع: إعادة استخدام UUID عند إعادة الإرسال

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

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

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "DUPLICATE_UUID",
        "category": "DUPLICATE_DOCUMENT",
        "message": "Submitted UUID was already used in a previous submission"
      }
    ],
    "warningMessages": []
  }
}

السبب الجذري. نظامك يربط UUID بسجل الفاتورة في قاعدة بياناتك، فيستعيد القيمة القديمة عند إعادة الإرسال بدل توليد جديدة. هذا الخلط بين «هوية الفاتورة في نظامك» و«معرّف المستند المرسل للهيئة» هو جذر المشكلة.

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

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

الخطأ الخامس: الخلط بين UUID ورقم الفاتورة أو ICV

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

الفاتورة الإلكترونية تحمل ثلاثة معرّفات مختلفة، لكل منها دور وصيغة:

• المعرّف الفريد UUID (cbc:UUID): بصمة عالمية عشوائية فريدة لكل مستند، صيغتها 8-4-4-4-12، تتغير مع كل فاتورة ولا تتسلسل.
• رقم الفاتورة المقروء (cbc:ID): الرقم التجاري المتسلسل الذي تراه على الفاتورة المطبوعة، مثل INV-1024، يحدده نظامك وفق ترقيمك الداخلي.
• العدّاد التسلسلي ICV: عدّاد متزايد بمقدار واحد عن الفاتورة السابقة، يثبت تسلسل الفواتير دون انقطاع. تفصيله في صفحة عدّاد الفاتورة ICV في الفاتورة الإلكترونية.

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

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

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

منهجية تشخيص خطأ UUID خطوة بخطوة

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

1. اقرأ code وcategory. كود مثل DUPLICATE_UUID يوجّهك لنمط التكرار، وINVALID_UUID_FORMAT لنمط الصيغة، وغياب العنصر لنمط الحقل المفقود.
2. افحص القيمة المرسلة فعلاً. اطبع قيمة cbc:UUID التي خرجت من نظامك، وتحقق من طولها وصيغتها بصرياً قبل أي تحليل أعمق.
3. ميّز التكرار من إعادة الإرسال. إن كان الخطأ تكراراً، اسأل: هل هي فاتورتان مختلفتان بمعرّف واحد، أم إعادة إرسال لمستند صحّحته؟ الحل يختلف بين الحالتين.
4. تأكد من تعيين الحقول. راجع أنك لم تضع رقم الفاتورة أو ICV في حقل UUID. هذا الخطأ يفسّر كثيراً من الأعراض الغامضة.
5. صحّح الجذر لا الفاتورة. أصلح منطق التوليد أو التعيين في نظامك، فيختفي الخطأ من كل الفواتير لا من واحدة.

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

كيف يساعدك قيود في تجنّب أخطاء UUID

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

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

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

أخطاء UUID شائعة تستحق الانتباه المبكر

بعض تفاصيل UUID تربك من يبدأ التكامل. معرفتها مسبقاً تختصر الطريق وتمنع رفض دفعات كاملة.

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

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

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

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

من إصلاح الفاتورة إلى إصلاح منطق التوليد

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

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

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

متى يظهر خطأ UUID في الاختبار ومتى في الإنتاج

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

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

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

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

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

لماذا تُرفض فاتورتي بخطأ تكرار UUID رغم أنها فاتورة جديدة؟

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

ما الصيغة الصحيحة لقيمة UUID وكيف أتحقق منها؟

الصيغة هي نمط 8-4-4-4-12 من المحارف السداسية العشرية بطول 36 محرفاً يتضمن أربع شرطات، مع الرقم 4 في بداية المجموعة الثالثة. تحقق من القيمة قبل الإرسال بتعبير نمطي يطابق صيغة الإصدار الرابع، يكشف أي انحراف قبل أن يصل للهيئة.

هل أستخدم UUID نفسه عند إعادة إرسال فاتورة صحّحتها؟

لا. كل إعادة بناء لمستند فاتورة تستوجب UUID جديداً، حتى لو كانت «الفاتورة نفسها» في نظرك. الاحتفاظ بالمعرّف القديم يُنتج خطأ تكرار. ولّد معرّفاً جديداً واحتفظ برقم الفاتورة المقروء (cbc:ID) إن لزم تتبّعها داخلياً.

ما الفرق بين UUID ورقم الفاتورة والعدّاد ICV؟

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

لماذا تُرفض فاتورتي برسالة أن حقل cbc:UUID مفقود؟

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

هل يعفيني قيود من التعامل مع أخطاء UUID؟

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