مخطط الفاتورة (Invoice Schema) والتحقق منه

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

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

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

ما هو مخطط الفاتورة (Invoice Schema)؟

مخطط الفاتورة هو ملف XSD (اختصار XML Schema Definition). إنه مستند رسمي يصف البنية المسموح بها لملف XML. فكّر فيه على أنه «نموذج فارغ» صارم: يحدد العناصر (elements)، والسمات (attributes)، وتسلسلها، وعدد مرات تكرارها، وأنواع البيانات داخلها.

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

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

مكوّنات المخطط الأساسية

يصف مخطط XSD ثلاثة أشياء عن كل جزء من الفاتورة:

• العناصر (Elements): العقد المسموح بها مثل cbc:ID وcbc:IssueDate وcac:AccountingSupplierParty.
• أنواع البيانات (Data types): هل القيمة نص، أم تاريخ، أم رقم عشري، أم قيمة من قائمة محددة مسبقًا.
• قواعد التكرار (Cardinality): كم مرة يجوز أو يجب أن يظهر العنصر. مثلًا: رقم الفاتورة إلزامي ويظهر مرة واحدة، وبنود الفاتورة تتكرر مرة واحدة على الأقل.

هذه المكوّنات الثلاثة معًا تُشكّل «العقد الهيكلي» الذي يجب أن تلتزم به كل فاتورة قبل أن تنظر إليها الهيئة على الإطلاق.

قاعدة التسلسل (Sequence) ولماذا الترتيب مهم

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

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

القيود الفرعية (Restrictions) داخل النوع

لا يكتفي مخطط XSD بتحديد «نص» أو «رقم». يمكنه فرض قيود أدق على القيمة عبر عناصر مثل xsd:pattern وxsd:enumeration وxsd:maxLength. مثلًا، رمز نوع الفاتورة قد يُقيّد بقائمة مغلقة من القيم المسموح بها عبر enumeration، فلا تقبل أداة التحقق أي رمز خارجها. وقد يُقيّد طول حقل نصّي بحد أقصى عبر maxLength. هذه القيود ما تزال «هيكلية» بمعنى أنها تُفحص ميكانيكيًا، لكنها تقترب من حدود قواعد العمل دون أن تتجاوزها. الفرق أن المخطط لا يقارن قيمتين ببعضهما ولا يجري حسابًا، بل يفحص كل قيمة منفردة مقابل قيد ثابت.

كيف يبدو مخطط XSD فعليًا؟

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

<xsd:element name="ID" type="cbc:IDType" minOccurs="1" maxOccurs="1"/>

<xsd:complexType name="IDType">
  <xsd:simpleContent>
    <xsd:extension base="xsd:normalizedString">
      <xsd:attribute name="schemeID" type="xsd:normalizedString"/>
    </xsd:extension>
  </xsd:simpleContent>
</xsd:complexType>

ما الذي يفرضه هذا التعريف؟ ثلاثة شروط واضحة:

• minOccurs="1" يعني أن العنصر إلزامي. فاتورة بلا ID ترفضها أداة التحقق فورًا.
• maxOccurs="1" يعني أنه يظهر مرة واحدة فقط. عنصران بنفس الاسم يكسران المخطط.
• النوع normalizedString يعني أن القيمة نص. لا يفرض المخطط أن يكون «رقم فاتورة حقيقي»، فقط أن يكون نصًا صالحًا.

ولنرَ كيف تبدو هذه العناصر داخل فاتورة XML فعلية ملتزمة بالمخطط:

<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:ID>INV-001234</cbc:ID>
  <cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>
  <cbc:IssueDate>2026-06-23</cbc:IssueDate>
  <cbc:IssueTime>14:30:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0211010">388</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>

  <cac:AccountingSupplierParty>
    ...
  </cac:AccountingSupplierParty>

</Invoice>

لاحظ فضاءات الأسماء (namespaces) في أعلى المستند. هذه ليست تفصيلًا تجميليًا. أداة التحقق تستخدمها لتعرف أي مخطط تطبّق على كل عنصر. عنصر cbc:ID يُتحقق منه مقابل تعريف CommonBasicComponents، بينما cac:AccountingSupplierParty يُتحقق منه مقابل CommonAggregateComponents. الترتيب الكامل لهذه العناصر وبنية المستند ككل لهما مقال مخصص (بنية الفاتورة الإلكترونية) في هذا المسار.

لماذا تتعدد ملفات XSD؟

قد تتوقع ملف XSD واحدًا يصف الفاتورة كاملة. الواقع أن مخطط UBL مُقسّم إلى عدة ملفات مترابطة عبر تعليمات xsd:import. الملف الرئيسي UBL-Invoice-2.1.xsd يستورد ملف المكوّنات الأساسية CommonBasicComponents، وملف المكوّنات المركّبة CommonAggregateComponents، وملفات أنواع البيانات غير المؤهلة. عند التحقق، تحمّل الأداة الملف الرئيسي فتتبع الاستيرادات تلقائيًا.

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

كيف يجري التحقق من المخطط (Schema Validation)؟

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

ماذا تفحص أداة التحقق من المخطط؟

تتحقق الأداة من أربعة جوانب فقط، وكلها هيكلية:

• وجود العناصر الإلزامية: هل كل عنصر عليه minOccurs="1" موجود فعلًا؟
• الترتيب الصحيح: هل تظهر العناصر بالتسلسل الذي يفرضه المخطط؟ XML حسّاس للترتيب داخل العقد المتسلسلة.
• أنواع البيانات: هل قيمة التاريخ تاريخ فعلًا؟ هل القيمة العشرية رقم؟
• القيم المغلقة (Code lists): هل قيمة مثل رمز العملة من القائمة المسموح بها؟

أي إخفاق في واحد من هذه الأربعة ينتج عنه خطأ تحقق من المخطط (schema validation error). والمهم: هذا الفحص لا يجري أي عملية حسابية، ولا يتصل بأي قاعدة بيانات، ولا يتأكد من «صحة» المعلومة في الواقع. هو فحص شكلي صرف.

مثال عملي على التحقق برمجيًا

إذا أردت تنفيذ التحقق من المخطط بنفسك في بيئة تطوير، فالعملية مباشرة في أغلب اللغات. باستخدام Java ومكتبة التحقق القياسية، تبدو هكذا:

SchemaFactory factory =
    SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);

Schema schema = factory.newSchema(new File("UBL-Invoice-2.1.xsd"));
Validator validator = schema.newValidator();

try {
    validator.validate(new StreamSource(new File("invoice.xml")));
    System.out.println("الفاتورة مطابقة للمخطط");
} catch (SAXException e) {
    System.out.println("خطأ تحقق من المخطط: " + e.getMessage());
}

المنطق نفسه متاح في Python عبر مكتبة lxml:

from lxml import etree

schema_doc = etree.parse("UBL-Invoice-2.1.xsd")
schema = etree.XMLSchema(schema_doc)

invoice = etree.parse("invoice.xml")

if schema.validate(invoice):
    print("الفاتورة مطابقة للمخطط")
else:
    for error in schema.error_log:
        print(f"السطر {error.line}: {error.message}")

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

أخطاء التحقق من المخطط الشائعة

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

1. عنصر إلزامي مفقود

أكثر الأخطاء شيوعًا. ينسى المطوّر إدراج عنصر عليه minOccurs="1". مثلًا فاتورة بلا cbc:IssueDate. رسالة الخطأ تكون من نوع:

cvc-complex-type.2.4.b: The content of element 'Invoice' is not complete.
One of '{IssueDate}' is expected.

2. عناصر بترتيب خاطئ

مخطط UBL يفرض تسلسلًا محددًا. وضع cbc:IssueDate بعد cbc:InvoiceTypeCode بدلًا من قبله يكسر المخطط، حتى لو كان العنصران موجودين. الرسالة المعتادة:

cvc-complex-type.2.4.a: Invalid content was found starting with
element 'IssueDate'. One of '{InvoiceTypeCode}' is expected.

3. نوع بيانات غير صالح

وضع نص داخل عنصر يتوقع رقمًا، أو تاريخ بصيغة خاطئة. مثلًا 2026/06/23 بدلًا من 2026-06-23. المخطط يفرض صيغة ISO 8601 للتواريخ، وأي انحراف عنها خطأ.

4. قيمة خارج القائمة المغلقة

بعض الحقول تقبل قيمًا من قائمة محددة فقط. وضع رمز عملة غير موجود في قائمة العملات المعتمدة، أو رمز نوع فاتورة غير صالح، ينتج خطأ تحقق. هذه الأخطاء أصعب اكتشافًا لأن العنصر «يبدو» صحيحًا شكلًا.

5. مشكلة في فضاء الأسماء (Namespace)

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

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

كيف تقرأ رسالة خطأ المخطط؟

رسائل أخطاء المخطط تتبع نمطًا ثابتًا يساعد على التشخيص السريع. غالبًا تبدأ برمز مثل cvc-complex-type أو cvc-datatype-valid، وهذا الرمز يخبرك بنوع الانتهاك مباشرة. بعده يأتي اسم العنصر المخالف، ثم وصف لما كان متوقعًا. اقرأ الرسالة من ثلاثة أجزاء: ما الرمز، وأي عنصر، وما المتوقع. هذا الثلاثي يكفي عادة لتحديد السطر وإصلاحه دون تخمين.

الفرق بين التحقق من المخطط والتحقق من قواعد العمل

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

التحقق من المخطط: هل البنية صحيحة؟

كما رأينا، هذه الطبقة ميكانيكية وهيكلية. مرجعها ملف XSD. سؤالها الوحيد: «هل الملف مبني بشكل سليم؟». لا تعرف هذه الطبقة شيئًا عن السعودية، ولا عن ضريبة القيمة المضافة، ولا عن المنطق المحاسبي. هي عامة بقدر معيار UBL نفسه.

التحقق من قواعد العمل: هل المحتوى منطقي وصحيح؟

هذه الطبقة تطبّق قواعد العمل (Business Rules) الخاصة بفاتورة السعودية. تُعرّف هذه القواعد عادة برموز مثل BR-KSA-XX للقواعد الوطنية وBR-XX للقواعد المشتقة من المعيار الأوروبي. أمثلة على ما تفحصه:

• هل مجموع مبالغ البنود يساوي إجمالي الفاتورة؟ (قاعدة حسابية)
• هل مبلغ ضريبة القيمة المضافة يساوي الوعاء الخاضع مضروبًا في 15%؟
• هل الرقم الضريبي للبائع يتبع الصيغة الصحيحة (15 خانة تبدأ وتنتهي بالرقم 3)؟
• هل تاريخ الإصدار ليس في المستقبل؟
• هل رمز سبب الإعفاء موجود عندما تكون الضريبة صفرية؟

الفرق العملي: فاتورة قد تكون صالحة من حيث المخطط لكنها تفشل في قواعد العمل. تخيّل ملف XML مبنيًا بشكل مثالي هيكليًا، لكن مجموع البنود فيه 1,000 ر.س بينما الإجمالي المكتوب 1,200 ر.س. المخطط لا يحسب، فيمرّر الفاتورة. أما طبقة قواعد العمل فترفضها لأن المنطق الحسابي مكسور.

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

لماذا فصلت الهيئة الطبقتين؟

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

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

أين يقع التحقق من صيغة المعرّفات داخل قيود؟

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

دور المخطط في رحلة الفاتورة عبر منصة فاتورة

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

1. التوليد: نظامك المحاسبي يبني ملف XML بصيغة UBL 2.1.
2. التوقيع: يُوقّع الملف رقميًا باستخدام معرّف ختم التشفير CSID الصادر من الهيئة.
3. التحقق من المخطط: تتأكد المنصة أولًا أن الملف مطابق هيكليًا لـ XSD.
4. التحقق من قواعد العمل: ثم تطبّق قواعد BR على المحتوى.
5. الاعتماد أو الإبلاغ: اعتماد لحظي للفواتير الضريبية (B2B)، أو إبلاغ خلال 24 ساعة للفواتير المبسّطة (B2C).

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

كيف تتعامل قيود مع طبقة المخطط نيابة عنك

الهدف من فهم المخطط ليس أن تكتبه يدويًا. الهدف أن تفهم ما يجري تحت الغطاء. تتولّى قيود طبقة المخطط بالكامل:

• تُولّد ملف XML مطابقًا لمعيار UBL 2.1 مع كل العناصر الإلزامية في ترتيبها الصحيح.
• تُوقّع الفاتورة رقميًا باستخدام CSID وتدير دورة حياته لكل فرع أو جهاز.
• تُنتج ملف PDF/A-3 مع تضمين XML داخله، وفق متطلب العرض في المرحلة الثانية.
• تتحقق من صيغة المعرّفات (مثل الرقم الضريبي والسجل التجاري) عند الإدخال، قبل الإرسال، لتقليل أحد أكثر أسباب التحذيرات شيوعًا.

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

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

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

أين تذهب بعد هذا الدليل؟

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

• فاتورة XML والتنسيق التقني: لفهم ما هو XML أصلًا وكيف يُمثّل الفاتورة، راجع مقال «فاتورة XML» في هذا المسار.
• معيار UBL 2.1: لفهم المعيار الدولي الذي يُبنى عليه مخطط الهيئة، راجع مقال «معيار UBL 2.1».
• بنية الفاتورة الإلكترونية: لفهم الترتيب الكامل لعناصر المستند والعقد الرئيسية، راجع مقال «بنية الفاتورة».
• قواعد التحقق (Business Rules): للطبقة الثانية وأكوادها الكاملة (BR-KSA)، راجع مقال «قواعد التحقق» في هذا المسار.

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

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

ما الفرق بين مخطط الفاتورة (XSD) وملف XML؟

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

هل اجتياز التحقق من المخطط يعني أن الفاتورة مقبولة لدى الهيئة؟

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

من أين أحصل على ملفات مخطط XSD الرسمية؟

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

ما أكثر أخطاء التحقق من المخطط شيوعًا؟

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

هل تحتاج إلى كتابة مخطط XSD بنفسك لتلتزم بالمرحلة الثانية؟

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

هل يتحقق التحقق من المخطط من صحة المبالغ والحسابات؟

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