رمز الخطأ 1013: بنية XML لا تطابق UBL 2.1

تبني تكاملك مع منصة فاتورة، وتُرسل فاتورة إلكترونية للاختبار، فيعود إليك رفض برمز محدد: 1013. يخبرك هذا الرمز أن بنية ملف XML للفاتورة لا تطابق معيار UBL 2.1، فترفضها الهيئة قبل أن تتحقق من قيمة أي حقل. الفاتورة قد تكون أرقامها كلها صحيحة، لكن شكل المستند نفسه لا يوافق القالب الذي تتوقعه منصة فاتورة. هذه الصفحة دليل متخصص في رمز الخطأ 1013 وحده، ضمن منظومة الفاتورة الإلكترونية من قيود.

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

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

ما الذي يعنيه رمز الخطأ 1013 بالضبط

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

UBL 2.1 اختصار لـ Universal Business Language الإصدار الثاني والواحد. هو معيار دولي يصف بنية المستندات التجارية بصيغة XML. اعتمدت الهيئة هذا المعيار أساساً لملف الفاتورة الإلكترونية في المرحلة الثانية، وأضافت عليه قواعدها الخاصة عبر قواعد عمل إضافية. لذلك لا يكفي أن يكون ملفك XML صحيحاً نحوياً، بل يجب أن يطابق هذا القالب تحديداً بكل تفاصيله.

من المهم أن تفرّق بين مستويين من التحقق. المستوى الأول هو صحة XML نحوياً: هل الوسوم مغلقة؟ هل المستند متوازن؟ هذا تكفله أي أداة XML. المستوى الثاني هو مطابقة المخطط (XSD): هل العناصر هي ذاتها التي يعرّفها UBL 2.1؟ هل بالترتيب والأنواع التي يفرضها؟ الرمز 1013 يخص المستوى الثاني تحديداً. قد يكون مستندك سليماً نحوياً تماماً، ومع ذلك يرفضه المخطط لأنه لا يطابق القالب.

هذا التمييز يفسّر سبب حيرة كثير من المطوّرين. يفتح المطوّر الملف في محرر XML فيراه سليماً ومنسّقاً، فيظن أن المشكلة في مكان آخر. لكن المحرر يتحقق من الصياغة لا من المخطط. أداة التحقق مقابل XSD هي وحدها التي تكشف مخالفة UBL 2.1.

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

رسالة الهيئة كما تصلك في استجابة الـ API

عند رفض الفاتورة بالرمز 1013، تعيد منصة فاتورة استجابة JSON تحدد فيها نوع الخطأ وموضعه. هذا نموذج فعلي لشكل الرسالة:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1013",
        "category": "XSD_SCHEMA",
        "message": "XML document does not conform to UBL 2.1 schema"
      }
    ],
    "warningMessages": []
  }
}

الحقل category بقيمة XSD_SCHEMA هو مفتاحك. يقول لك بوضوح أن المشكلة في مطابقة المخطط (XSD)، لا في قيمة حقل واحد. بعض أدوات التحقق تضيف في رسالة المخطط موضع المخالفة، مثل اسم العنصر المخالف ورقم السطر. اقرأ تلك التفاصيل أولاً، فهي تختصر عليك مكان الخطأ.

إنفوجرافيك: الصور الأربع لمخالفة UBL 2.1

الحالة الأولى: عنصر مطلوب مفقود من المستند

أكثر سبب شيوعاً للرمز 1013 هو غياب عنصر يفرضه مخطط UBL 2.1. المخطط يحدد عناصر إلزامية لا يقبل المستند بدونها. مثالها cbc:ProfileID الذي يعرّف ملف الفاتورة، أو cbc:ID الذي يحمل رقم الفاتورة، أو كتلة بيانات البائع. إن سقط أي عنصر إلزامي، يرفض المخطط المستند كله.

هذا مقطع معطوب تنقصه العقدة cbc:ProfileID التي يفترض أن تسبق رقم الفاتورة:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>INV-001</cbc:ID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  ...
</Invoice>

والمقطع السليم بعد إضافة العنصر المطلوب في موضعه الصحيح قبل رقم الفاتورة:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>INV-001</cbc:ID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  ...
</Invoice>

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

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

الحالة الثانية: عناصر صحيحة لكن بترتيب خاطئ

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

السبب أن XSD يستخدم تعريف xsd:sequence الذي يوجب ظهور العناصر بالترتيب المعلن لا بأي ترتيب. هذا يختلف عن صيغ بيانات أخرى تتساهل في الترتيب. مقطع بترتيب خاطئ، وُضع فيه تاريخ الإصدار قبل رقم الفاتورة:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cbc:ID>INV-001</cbc:ID>
  ...
</Invoice>

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

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>INV-001</cbc:ID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  ...
</Invoice>

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

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

الحالة الثالثة: مساحة اسم namespace غير صحيحة أو ناقصة

عناصر UBL 2.1 موزّعة على مساحات أسماء (XML namespaces). كل بادئة مثل cbc وcac ترتبط بمساحة اسم محددة يجب إعلانها في جذر المستند. إن أغفلت إعلان مساحة اسم، أو ربطتها برابط URN خاطئ، أو استخدمت بادئة لم تعلنها، يرى المخطط العناصر مجهولة فيرفضها بالرمز 1013.

هذه أكثر مساحات الأسماء استخداماً في فاتورة UBL 2.1:

• cbc ترتبط بـ urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2 وتغطي الحقول الأساسية مثل رقم الفاتورة وتاريخها.
• cac ترتبط بـ urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2 وتغطي الكتل المركّبة مثل بيانات البائع وسطور الفاتورة.
• مساحة الاسم الافتراضية للجذر Invoice ترتبط بـ urn:oasis:names:specification:ubl:schema:xsd:Invoice-2.

الخطأ الشائع هو نسيان إعلان cac أو كتابة الرابط بخطأ مطبعي. مقطع معطوب يستخدم البادئة cbc دون إعلانها في الجذر:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>INV-001</cbc:ID>
</Invoice>

المقطع السليم بعد إعلان مساحات الأسماء كاملة في عنصر الجذر:

<Invoice
  xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
  xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
  xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  <cbc:ID>INV-001</cbc:ID>
</Invoice>

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

الحالة الرابعة: نوع بيانات مخالف لما يتوقعه المخطط

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

مثال شائع هو حقل المبلغ cbc:PayableAmount الذي يتطلب سمة currencyID إلزامية. مقطع معطوب يكتب المبلغ دون سمة العملة:

<cac:LegalMonetaryTotal>
  <cbc:PayableAmount>115.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

المقطع السليم بعد إضافة سمة العملة بقيمة الريال السعودي:

<cac:LegalMonetaryTotal>
  <cbc:PayableAmount currencyID="SAR">115.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

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

سمات العملة مصدر متكرر لهذه الحالة. مخطط UBL 2.1 يطلب سمة currencyID على حقول المبالغ، وقد يطلب أن تتطابق العملة عبر كل حقول الفاتورة. إن كتبت عملة في حقل وأغفلتها في آخر، أو خلطت رموز عملات مختلفة، يصدر الرمز 1013. اجعل العملة قيمة موحّدة على مستوى المستند، وطبّقها على كل حقل مبلغ تلقائياً بدلاً من كتابتها يدوياً في كل موضع.

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

كيف تقرأ رسالة الرمز 1013 وتشخّصها خطوة بخطوة

عند وصول الرمز 1013، اتبع تسلسلاً ثابتاً يوصلك إلى موضع المخالفة بسرعة بدلاً من التخمين:

1. اقرأ حقل message في استجابة الـ API. كثير من أدوات التحقق تذكر اسم العنصر المخالف ورقم سطره.
2. احفظ ملف XML المرفوض كما هو، ثم تحقق منه محلياً مقابل ملفات XSD الرسمية من الهيئة قبل إعادة الإرسال.
3. ابدأ من الصور الأربع بالترتيب: عنصر مفقود، ثم ترتيب خاطئ، ثم مساحة اسم، ثم نوع بيانات. غالبية الحالات تقع في أول صورتين.
4. قارن مستندك بنموذج فاتورة صحيح معتمد من الهيئة. الفروق البنيوية تظهر سريعاً عند المقارنة المباشرة.
5. بعد الإصلاح، أعد التحقق محلياً أولاً، ثم أرسل إلى بيئة الاختبار قبل الإنتاج.

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

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

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

إنفوجرافيك: مسار تشخيص الرمز 1013

دع قيود يتولّى بناء XML نيابة عنك

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

كيف يساعدك قيود في تفادي الرمز 1013

قيود متوافق مع المرحلة الثانية من الفوترة الإلكترونية، ويولّد ملف XML للفاتورة وفق مخطط UBL 2.1 الذي تبنّته الهيئة تلقائياً. هذا يعني أنك لا تكتب المستند بيدك، ولا تتعقّب العناصر الإلزامية أو ترتيبها أو مساحات أسمائها. يضع قيود هذه القواعد في مكانها افتراضياً مع كل فاتورة تصدرها.

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

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

اختلاف البنية بين فاتورة B2B وفاتورة B2C

قبل أن تبحث عن سبب الرمز 1013، تأكد أنك تبني البنية الصحيحة لنوع الفاتورة. مخطط UBL 2.1 واحد، لكن قواعد الهيئة تفرض حقولاً مختلفة حسب نوع المستند. الفاتورة الضريبية B2B الموجَّهة لمنشأة مسجّلة، والفاتورة المبسّطة B2C الموجَّهة لمستهلك نهائي، تختلفان في بعض العناصر الإلزامية.

الفاتورة الضريبية B2B تتطلب بيانات المشتري كاملة، ومنها رقمه الضريبي، لأنها تمرّ على مسار المقاصة قبل وصولها للمشتري. غياب كتلة بيانات المشتري في فاتورة B2B مخالفة بنيوية تُصدر الرمز 1013. أما الفاتورة المبسّطة B2C فلا تطلب الرقم الضريبي للمشتري، وتمرّ على مسار الإبلاغ خلال أربع وعشرين ساعة من إصدارها.

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

متى يظهر الرمز 1013 في الاختبار ومتى في الإنتاج

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

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

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

قائمة وقاية عملية من الرمز 1013

هذه القائمة تحوّل الرمز 1013 من خطأ متكرر إلى حالة نادرة تكشفها قبل وصولها إلى الهيئة:

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

إنفوجرافيك: قائمة وقاية من الرمز 1013

من إصلاح الفاتورة إلى إصلاح منطق البناء

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

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

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

ما الفرق بين الرمز 1013 وأخطاء XML الأخرى؟

الرمز 1013 يخص تحديداً عدم مطابقة بنية المستند لمخطط UBL 2.1، أي مخالفة في الشكل (XSD). أخطاء XML الأخرى قد تخص الصياغة غير السليمة أو الترميز أو محتوى الحقول. للوحة كاملة بأنماط أخطاء XML راجع صفحة أخطاء XML في الفاتورة الإلكترونية.

كيف أتحقق من ملف XML مقابل UBL 2.1 قبل الإرسال؟

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

هل ترتيب العناصر في XML مهم فعلاً؟

نعم. مخطط UBL 2.1 يستخدم تسلسلاً محدداً (sequence) يوجب ظهور العناصر بترتيبها المعلن. عنصر صحيح القيمة في موضع خاطئ يكفي لإصدار الرمز 1013، فاكتب العناصر بترتيب المخطط لا بترتيب وصول البيانات.

لماذا تُرفض فاتورتي بالرمز 1013 رغم أن كل أرقامها صحيحة؟

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

هل يكفي إصلاح فاتورة واحدة لحل الرمز 1013 نهائياً؟

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

كيف أتفادى الرمز 1013 دون بناء مولّد XML بنفسي؟

استخدم نظاماً محاسبياً متكاملاً يبني XML المتوافق مع UBL 2.1 نيابةً عنك. يولّد قيود العناصر الإلزامية بترتيبها ومساحات أسمائها وأنواع بياناتها تلقائياً، فلا يصلك الرمز 1013 من الأساس.