كل فاتورة إلكترونية متوافقة مع المرحلة الثانية في السعودية ليست مجرد صورة أو ملف PDF، بل مستند XML منظَّم تقرأه الأنظمة قبل أن يقرأه الإنسان. هذا المستند مبنيّ على بنية ثابتة محدَّدة سلفًا: ترتيب معيّن للعناصر، وتداخل دقيق بينها، وأقسام رئيسية لكل منها دور واضح. إذا اختلّ هذا الترتيب أو غاب عنصر إلزامي، ترفض منصة فاتورة المستند أو تصدر تحذيرًا.
هذا الدليل التقني موجَّه للمطوّرين والمحاسبين التقنيين الذين يريدون فهم بنية مستند الفاتورة الإلكترونية من الداخل: ما هي الأقسام الثلاثة الكبرى، وكيف تتداخل في شجرة XML واحدة، وما ترتيب العناصر بينها. نركّز هنا على الهيكل العام فقط. أما التفاصيل العميقة لكل قسم (حقول الترويسة، تركيب البنود، مخطط XSD) فلها أدلة مستقلة نشير إليها في موضعها. يندرج هذا الدليل ضمن سلسلة التوثيق التقني للفوترة الإلكترونية.
يبني برنامج الفاتورة الإلكترونية من قيود هذه البنية تلقائيًا خلف الكواليس، فلا تحتاج لكتابة XML بيدك. لكن فهم الهيكل يساعدك على قراءة الفاتورة المُولَّدة، وتفسير رسائل التحقق، والتأكد من اكتمال البيانات قبل الإرسال.
ما المقصود ببنية الفاتورة الإلكترونية؟
بنية الفاتورة هي الطريقة التي تُرتَّب بها بيانات الفاتورة داخل مستند XML واحد. تتبع هذه البنية معيار UBL 2.1 (Universal Business Language)، وهو المعيار العالمي الذي اعتمدته هيئة الزكاة والضريبة والجمارك (ZATCA) للمرحلة الثانية من الفوترة الإلكترونية.
المستند ليس قائمة حقول مسطحة، بل شجرة. تبدأ بعنصر جذر واحد يضمّ كل شيء، ثم تتفرّع منه الأقسام، وتتفرّع من كل قسم عناصر أصغر. هذا التداخل (nesting) هو جوهر الفكرة: موضع العنصر داخل الشجرة يحدّد معناه. الرقم نفسه يعني شيئًا مختلفًا إذا وُضع في الترويسة أو داخل بند أو في قسم الإجماليات.
للتوضيح، إليك أبسط هيكل ممكن لفاتورة ضريبية قبل ملء التفاصيل:
لاحظ بادئتين تتكرران: cbc: وcac:. الأولى اختصار لـ Common Basic Components وتعني الحقول البسيطة ذات القيمة الواحدة (رقم، تاريخ، نص). الثانية اختصار لـ Common Aggregate Components وتعني العناصر المركّبة التي تضمّ عناصر أخرى بداخلها. هذا التمييز يفسّر لماذا بعض الوسوم تحوي قيمة مباشرة وبعضها يحوي وسومًا أخرى.
هذه البادئات ليست تزيينًا، بل أسماء نطاقات (Namespaces) معرَّفة في رأس المستند. يفتح كل مستند فاتورة بإعلان هذه النطاقات على العنصر الجذر، فتعرف الأنظمة من أي معيار جاء كل وسم. غياب أحد إعلانات النطاق أو الخطأ في عنوانه يجعل المستند غير قابل للقراءة من أساسه، قبل أي تحقق على مستوى المحتوى.
إعلان النطاق ext: هو ما يسمح لاحقًا بإضافة امتدادات الختم المشفّر. أما النطاق الافتراضي (بلا بادئة) فيشير إلى أن المستند من نوع Invoice في معيار UBL. هذه السطور الأربعة هي «غلاف» المستند الذي يحتضن الأقسام الثلاثة كلها.
شرح بنية مستند الفاتورة الإلكترونية
فاتورة مقروءة بشرياً
وسم كل حقل بعنصر XML
ملف XML منظّم مقروء آلياً
الأقسام الثلاثة الرئيسية لمستند الفاتورة
أيًا كان نوع الفاتورة (ضريبية للأعمال B2B أو مبسّطة للمستهلك B2C)، ينقسم المستند منطقيًا إلى ثلاثة أجزاء كبرى. فهم هذه الأجزاء الثلاثة هو مفتاح قراءة أي فاتورة إلكترونية.
1. الترويسة (Header): هوية الفاتورة وأطرافها
الترويسة هي الجزء الأعلى من المستند. تحمل البيانات التي تعرّف الفاتورة ككل: رقمها، ونوعها، وتاريخها، ومعرّفها الفريد، إضافة إلى بيانات البائع والمشتري. هذه البيانات تنطبق على الفاتورة بأكملها لا على بند بعينه.
أبرز عناصر الترويسة في ترتيبها الطبيعي:
هنا نرى مثالًا حيًا على التداخل. AccountingSupplierParty عنصر مركّب يضمّ بداخله اسم البائع، ورقمه الضريبي، وعنوانه. الترويسة إذن ليست حقولًا مسطحة، بل تحوي عناصر مركّبة تتفرّع بدورها. كل حقل من هذه الحقول له قواعد إلزام وصيغة محدَّدة لا نتوسّع فيها هنا.
لفهم التداخل أكثر، انظر كيف يُبنى عنصر البائع داخليًا. هو لا يحمل اسم البائع وحده، بل يضمّ عنصر طرف Party يتفرّع بدوره إلى الاسم القانوني، والرقم الضريبي، والعنوان، ومخطط التعريف:
هذا التعشيش متعدد الطبقات هو ما يجعل الترويسة أعمق مما تبدو. عنصر واحد ظاهريًا (البائع) ينطوي على أربع طبقات من العناصر المتداخلة. عنصر المشتري AccountingCustomerParty يتبع البنية نفسها. الفرق الجوهري بينهما أن الفاتورة الضريبية (B2B) تتطلب رقمًا ضريبيًا للمشتري، بينما الفاتورة المبسّطة (B2C) لا تشترط ذلك لأن المشتري مستهلك نهائي.
للتعمّق في كل حقل من حقول الترويسة (المعرّف الفريد UUID، ورمز نوع الفاتورة، وبيانات الطرفين، وعدّاد الفاتورة ICV)، راجع الدليل المخصص «ترويسة الفاتورة (Invoice Header)»، إذ يتناول كل عنصر على حدة بأمثلته وقواعده.
2. البنود (Line Items): تفاصيل المنتجات والخدمات
القسم الثاني هو جسم الفاتورة: قائمة البنود. كل سطر في الفاتورة (منتج أو خدمة) يُمثَّل بعنصر InvoiceLine مستقل. إذا باعت المنشأة ثلاثة أصناف في فاتورة واحدة، تكرّر العنصر ثلاث مرات داخل المستند نفسه.
كل بند يحمل رقمه التسلسلي، والكمية، ووحدة القياس، والسعر، وإجمالي السطر، واسم الصنف، إضافة إلى تفاصيل الضريبة الخاصة به. لاحظ التداخل مجددًا: Item وPrice عنصران مركّبان داخل البند، وليسا حقلين مسطحين. هذا يسمح لكل بند أن يحمل نسبة ضريبة مختلفة عن غيره (صنف خاضع 15% وصنف معفى مثلًا) داخل الفاتورة الواحدة.
ترتيب البنود مهم: تُرقَّم تصاعديًا من 1، ويجب أن تتطابق مجاميع الأسطر مع الإجماليات في القسم الثالث، وإلا فشل التحقق الحسابي. أما القواعد التفصيلية لتركيب البند (الخصومات على مستوى السطر، ورموز الضريبة، ووحدات القياس) فموضوعها الدليل المخصص «بنود الفاتورة (Invoice Lines)».
شرح تكرار عنصر البند داخل المستند
الترويسة (Header): بيانات الفاتورة العامة
أطراف الفاتورة (البائع والمشتري)
البنود والإجماليات (Lines & Totals)
الامتدادات والختم التشفيري (Extensions)
3. الإجماليات والضريبة والامتدادات (Totals, Tax & Extensions): الختم القانوني
القسم الثالث يجمع أرقام الفاتورة في صورتها النهائية، ويحمل البيانات الأمنية التي تثبت سلامتها. ينقسم عمليًا إلى مجموعتين متجاورتين: إجماليات الضريبة، والإجماليات المالية القانونية.
هنا تظهر ضريبة القيمة المضافة بنسبتها (15%)، والمبلغ الخاضع للضريبة، والإجمالي قبل الضريبة وبعدها، والمبلغ المستحق الدفع. هذه الأرقام يجب أن تنسجم حسابيًا مع مجاميع البنود في القسم الثاني. أي فرق بسبب التقريب يُعالَج وفق قواعد محدَّدة في المعيار.
إلى جانب الإجماليات، يحمل هذا الجزء العناصر الأمنية الإلزامية في المرحلة الثانية، وتوضَع غالبًا في امتداد التوقيع أعلى المستند ضمن UBLExtensions:
الختم المشفّر هو توقيع رقمي بخوارزمية ECDSA يُنشأ بمعرّف الختم المشفر (CSID) الصادر من الهيئة لكل جهاز أو فرع. تُضاف إليه بصمة المستند (Hash بخوارزمية SHA-256)، وبصمة الفاتورة السابقة لتشكيل سلسلة مترابطة، ورمز QR. هذه العناصر مجتمعة تجعل الفاتورة موثَّقة ومقاومة للتلاعب. توليد هذه الامتدادات وإدارة شهادة CSID يتمّان تلقائيًا في قيود.
كيف تتداخل الأقسام في شجرة المستند
الآن بعد أن عرفنا الأقسام الثلاثة، لننظر إلى الصورة الكاملة. كل شيء يعيش داخل عنصر جذر واحد اسمه Invoice. تحته مباشرة تأتي امتدادات الختم أولًا، ثم حقول الترويسة البسيطة، ثم عناصر الترويسة المركّبة (البائع والمشتري)، ثم إجماليات الضريبة، ثم الإجماليات المالية، وأخيرًا أسطر البنود.
قد يبدو مفاجئًا أن البنود تأتي في نهاية المستند رغم أنها «جسم» الفاتورة بصريًا. هذا أحد أهم الفروق بين الشكل المرئي للفاتورة وبنيتها الفعلية في XML: الترتيب البصري للقارئ يختلف عن ترتيب العناصر في الشجرة. ما يهمّ الأنظمة هو موضع العنصر داخل التسلسل الهرمي، لا مكانه على الورقة.
إليك الهيكل الكامل مبسّطًا بترتيب عناصره الفعلي:
هذا الترتيب ليس اختياريًا. يفرض معيار UBL 2.1 تسلسلًا محدَّدًا للعناصر داخل العنصر الأب. وضع InvoiceLine قبل TaxTotal مثلًا يخالف المخطط ويؤدي إلى رفض المستند عند التحقق. لهذا يبني قيود الشجرة وفق التسلسل الصحيح دائمًا دون تدخّل منك.
شرح ترتيب العناصر داخل شجرة الفاتورة
| المعيار | ملف XML | ملف PDF/A-3 |
|---|---|---|
| الوجهة | منصة فاتورة والأنظمة | العميل |
| المقروئية | آلية (للأنظمة) | بشرية (للعرض) |
| الغرض | المعالجة والتحقق | عرض الفاتورة وقراءتها |
الفرق بين البنية والمخطط (Schema)
يخلط كثيرون بين بنية الفاتورة ومخطط الفاتورة (Schema). الفرق جوهري. البنية هي الترتيب الفعلي للعناصر في مستند فاتورة بعينه. أما المخطط فهو القواعد التي تحكم تلك البنية: أي العناصر إلزامية، وأي العناصر اختيارية، وما نوع القيمة المسموح في كل حقل، وما ترتيبها الصحيح.
بعبارة أخرى: المخطط هو القالب، والبنية هي المستند الذي يتبع القالب. حين ترسل فاتورتك إلى منصة فاتورة، تتحقق المنصة من أن بنية مستندك تطابق المخطط المعتمد. أي مخالفة (عنصر إلزامي ناقص، أو ترتيب خاطئ، أو قيمة بصيغة غير صحيحة) تُكتَشف في هذه المرحلة. تفاصيل ملفات المخطط وقواعد التحقق XSD موضوعها الدليل المخصص «مخطط الفاتورة (Invoice Schema)».
رحلة البنية من الإنشاء إلى الاعتماد
تمرّ بنية الفاتورة بسلسلة خطوات منذ لحظة إنشائها حتى اعتمادها لدى الهيئة. فهم هذه الرحلة يكمل الصورة، لأن البنية ليست ساكنة، بل تُبنى وتُختم وتُرسل بترتيب محدَّد.
- بناء الشجرة: يُولَّد المستند بأقسامه الثلاثة، مرتَّبًا وفق تسلسل UBL الإلزامي، مع إعلانات النطاقات على العنصر الجذر.
- حساب البصمة (Hash): تُحسب بصمة SHA-256 للمستند بعد تطبيعه (Canonicalization)، وتُربط ببصمة الفاتورة السابقة لتكوين السلسلة.
- الختم المشفّر: يُوقَّع المستند بمعرّف الختم المشفّر (CSID) فيُضاف التوقيع والمفتاح العام داخل
UBLExtensions. - توليد رمز QR: يُبنى رمز QR بصيغة TLV ويُضمَّن في البنية، حاملًا بيانات البائع والرقم الضريبي والإجمالي والبصمة والتوقيع.
- التحقق والإرسال: يُرسَل المستند إلى منصة فاتورة. الفاتورة الضريبية تخضع للمصادقة فتعود مختومة من الهيئة، والمبسّطة تُبلَّغ خلال 24 ساعة.
أي خطأ في ترتيب الأقسام يُكتشف عند التحقق قبل اكتمال الرحلة. لهذا يُبنى المستند بالتسلسل الصحيح من البداية، لا أن يُعاد ترتيبه لاحقًا. عدّاد الفاتورة (ICV) وبصمة الفاتورة السابقة يضمنان أن كل فاتورة تأتي في موضعها الصحيح ضمن سلسلة فواتير المنشأة، فلا يمكن حذف فاتورة أو إقحام أخرى دون كسر السلسلة.
هذا الترابط بين البصمة والعدّاد والتوقيع هو ما يحوّل المستند من ملف نصّي قابل للتعديل إلى وثيقة موثَّقة. لو غيّر أحدهم رقمًا واحدًا في أي قسم بعد الختم، لاختلفت البصمة المحسوبة عن البصمة المخزَّنة، وانكشف التلاعب فورًا.
مثال متكامل: قراءة فاتورة من أعلاها لأسفلها
لنجمع ما سبق في قراءة واحدة متسلسلة لمستند فاتورة كامل. ابدأ من العنصر الجذر Invoice بإعلانات نطاقاته. أول ما تقابله امتداد UBLExtensions الذي يحمل الختم والتوقيع. هذا هو الجزء الأمني الذي يثبت أصالة الوثيقة.
بعده تبدأ حقول الترويسة البسيطة: معرّف الملف ProfileID الذي يحدّد ما إذا كانت الفاتورة للمصادقة أو الإبلاغ، ثم رقم الفاتورة، ومعرّفها الفريد UUID، وتاريخها، ورمز نوعها، وعملتها. تلي ذلك عناصر الترويسة المركّبة: البائع بطبقاته الأربع، ثم المشتري ببنيته المماثلة.
ننتقل بعدها إلى الإجماليات: TaxTotal يحمل إجمالي الضريبة وتفصيلها بالنسبة والمبلغ الخاضع، ثم LegalMonetaryTotal بمبالغه الأربعة (إجمالي الأسطر، والمبلغ قبل الضريبة، والمبلغ شاملها، والمستحق). أخيرًا تأتي أسطر البنود InvoiceLine واحدًا تلو الآخر، كل بند بكميته وسعره وصنفه وضريبته.
إذا قرأت أي فاتورة بهذا الترتيب، عرفت موضع كل بيان فورًا. التاريخ في الترويسة، وسعر الصنف في البند، وإجمالي الضريبة في قسم الإجماليات، والتوقيع في الامتداد. هذا الانضباط في المواضع هو ما يجعل ملايين الفواتير قابلة للمعالجة آليًا دون لبس.
فواتير متوافقة مع المرحلة الثانية دون كتابة سطر XML واحد
يبني قيود بنية الفاتورة الإلكترونية كاملة تلقائيًا: الترويسة والبنود والإجماليات والختم المشفّر، بالترتيب الذي تطلبه الهيئة. أنت تكتب الفاتورة، وقيود يتولّى الباقي.
أنواع الفواتير وأثرها على البنية
تشترك أنواع الفواتير في البنية العامة نفسها، لكنها تختلف في بعض الحقول وفي طريقة معالجتها لدى الهيئة. أبرز نوعين:
- الفاتورة الضريبية (B2B): تُستخدم بين المنشآت. تخضع لـ«المصادقة (Clearance)»، أي تُرسَل إلى الهيئة أولًا فتعيدها مختومة، ولا تُسلَّم للمشتري إلا بعد ذلك.
- الفاتورة الضريبية المبسّطة (B2C): تُستخدم مع المستهلك. تُسلَّم للمشتري فورًا، ثم تُبلَّغ للهيئة خلال 24 ساعة («الإبلاغ Reporting»).
إلى جانبهما، يتبع الإشعار الدائن والإشعار المدين البنية نفسها مع حقول إضافية تربطهما بالفاتورة الأصلية. الفارق في البنية بين هذه الأنواع محدود غالبًا في رمز نوع الفاتورة InvoiceTypeCode وبعض الحقول المرتبطة بالطرف الآخر، بينما تبقى الأقسام الثلاثة الكبرى ثابتة في جميعها.
موضع رمز QR في البنية
رمز QR جزء أصيل من بنية الفاتورة، لا إضافة بصرية على الورقة فقط. في المرحلة الثانية، يُضمَّن الرمز داخل المستند بصيغة TLV (Tag-Length-Value)، أي سلسلة من الوسوم لكل منها رقم وطول وقيمة، مرمَّزة بترميز Base64.
يحمل رمز QR للفاتورة الضريبية تسعة وسوم: اسم البائع، ورقمه الضريبي، والطابع الزمني، وإجمالي الفاتورة شاملًا الضريبة، وإجمالي الضريبة، وبصمة المستند، والختم المشفّر، والمفتاح العام، والتوقيع. هذه الوسوم التسعة مستلّة من الأقسام الثلاثة: اسم البائع ورقمه من الترويسة، والإجماليات من قسم الإجماليات، والبصمة والختم من الامتداد الأمني.
أي أن رمز QR ليس قسمًا رابعًا مستقلًا، بل ملخّص مرمَّز للبيانات الموزَّعة على الأقسام الثلاثة. هذا يفسّر سبب توليده في نهاية الرحلة بعد اكتمال البنية والختم: لا يمكن بناؤه قبل أن تُحسب البصمة ويُوقَّع المستند، لأنه يحملهما.
أخطاء بنيوية شائعة وكيف تقرأها
تنشأ أغلب رسائل التحقق من خلل في البنية لا في الأرقام نفسها. معرفة القسم الذي ينتمي إليه الخطأ يختصر زمن الحل. أبرز الأنماط:
- عنصر إلزامي ناقص في الترويسة: غياب الرقم الضريبي للبائع أو رمز نوع الفاتورة يوقف التحقق فورًا، لأن هذه الحقول تعرّف الفاتورة ككل.
- ترتيب خاطئ للأقسام: وضع
InvoiceLineقبلTaxTotalيخالف تسلسل UBL ويُرفَض، حتى لو كانت القيم صحيحة. - عدم اتساق حسابي: إذا لم يساوِ مجموع أسطر البنود قيمة
LineExtensionAmountفي الإجماليات، يُكتشف التعارض بين القسمين الثاني والثالث. - صيغة معرّف غير صحيحة: رقم سجل تجاري أو رقم ضريبي بعدد خانات خاطئ يُلتقط على مستوى الحقل في الترويسة قبل الإرسال.
القاعدة العملية: اقرأ رسالة التحقق، حدّد العنصر المذكور، ثم اسأل إلى أي قسم ينتمي. هذا التموضع يقودك مباشرة إلى مصدر البيانات الذي يحتاج تصحيحًا، سواء كان إعداد المنشأة، أو بيانات العميل، أو سطر بند بعينه.
لماذا يهمّك فهم هذه البنية؟
حتى لو لم تكتب XML بيدك أبدًا، فهم البنية يفيدك عمليًا في مواقف عدة:
- تفسير رسائل التحقق: حين تصدر الهيئة تحذيرًا، يشير غالبًا إلى عنصر بعينه في الشجرة. معرفة القسم الذي ينتمي إليه العنصر تسرّع تشخيص السبب.
- مراجعة اكتمال البيانات: تدرك أي البيانات تنتمي للترويسة (مرة واحدة لكل فاتورة) وأيها يتكرر مع كل بند، فتراجع المصدر الصحيح عند وجود نقص.
- التكامل البرمجي: إذا كنت تربط نظامًا خارجيًا عبر واجهة برمجية، تحتاج لفهم مواضع العناصر لتقرأ الفاتورة المولَّدة أو تبني تقاريرك عليها.
- التحقق من سلامة الإجماليات: تعرف أن مجاميع البنود يجب أن تساوي الإجماليات، فتكتشف أخطاء الإدخال قبل الإرسال.
في النهاية، البنية ليست تفصيلًا تقنيًا منعزلًا، بل اللغة التي تتفاهم بها أنظمتك مع منصة فاتورة. كلما فهمتها أعمق، قلّت أخطاء فواترك وأسرع حلّك لأي تحذير.
كيف يتولّى قيود بنية الفاتورة نيابةً عنك
قيود حلّ متوافق مع المرحلة الثانية من الفوترة الإلكترونية. عند إصدار أي فاتورة، يبني قيود مستند XML كاملًا وفق معيار UBL 2.1: يرتّب الترويسة والبنود والإجماليات بالتسلسل الذي يطلبه المخطط، ويولّد الختم المشفّر ورمز QR وبصمة السلسلة، ويدير شهادة CSID لكل فرع.
كما يتحقق قيود من صيغة أرقام التعريف (السجل التجاري، والرقم الضريبي، ومعرّفات الطرف الآخر) قبل الإرسال، فيلتقط أحد أكثر أسباب التحذيرات شيوعًا مبكرًا. ثم يتولّى مسار المصادقة للفواتير بين الأعمال، ومسار الإبلاغ خلال 24 ساعة للفواتير المبسّطة. كل ذلك دون أن تكتب سطر XML واحدًا.
جرّب قيود مجانًا لمدة 14 يومًا، دون بطاقة ائتمان.
خلاصة بنيوية للأقسام الثلاثة
لتثبيت الصورة، إليك ما يحمله كل قسم وموضعه في الشجرة. الترويسة في أعلى المستند بعد الامتداد الأمني، وتحمل ما ينطبق على الفاتورة كلها: أرقام التعريف، والتواريخ، والعملة، وبيانات البائع والمشتري بطبقاتها المتداخلة. تتكرر بياناتها مرة واحدة لكل فاتورة.
قسم الإجماليات يلي الترويسة، ويحمل أرقام الضريبة والمبالغ النهائية التي يجب أن تنسجم حسابيًا مع البنود. أما البنود فتأتي في نهاية المستند، يتكرر عنصرها لكل صنف، ويحمل كل بند كميته وسعره وضريبته الخاصة. والامتداد الأمني في القمة يربط الجميع بختم وبصمة وتوقيع يحوّل المستند إلى وثيقة موثَّقة.
هذه الأقسام الثلاثة، بغلافها من النطاقات وامتداداتها الأمنية، تشكّل كل فاتورة إلكترونية في السعودية. اختلاف نوع الفاتورة يغيّر بعض الحقول لا الهيكل. ومتى أتقنت قراءة هذا الهيكل، صار تشخيص أي تحذير وفهم أي فاتورة مولَّدة أمرًا مباشرًا.
الأسئلة الشائعة
ما الأقسام الرئيسية في بنية الفاتورة الإلكترونية؟
ثلاثة أقسام: الترويسة (هوية الفاتورة وأطرافها)، والبنود (سطر لكل منتج أو خدمة)، والإجماليات والضريبة مع امتدادات الختم المشفّر. كلها تعيش داخل عنصر جذر واحد اسمه Invoice.
ما معيار البنية المعتمد في السعودية؟
معيار UBL 2.1 (Universal Business Language)، وهو المعيار العالمي الذي اعتمدته هيئة الزكاة والضريبة والجمارك للمرحلة الثانية من الفوترة الإلكترونية. صيغة المستند XML.
لماذا تأتي البنود في نهاية المستند رغم أنها جسم الفاتورة؟
لأن الترتيب البصري للقارئ يختلف عن ترتيب العناصر في شجرة XML. يفرض معيار UBL تسلسلًا محدَّدًا تأتي فيه الترويسة والإجماليات قبل أسطر البنود. ما يهمّ الأنظمة هو موضع العنصر في الشجرة لا مكانه على الورقة.
هل أحتاج لكتابة XML بنفسي لإصدار فاتورة متوافقة؟
لا. يبني قيود بنية XML كاملة تلقائيًا، فأنت تدخل بيانات الفاتورة عبر واجهة بسيطة وقيود يولّد المستند المتوافق بالترتيب الصحيح ومع الختم المشفّر.
ما الفرق بين بنية الفاتورة ومخطّطها؟
البنية هي الترتيب الفعلي للعناصر في فاتورة بعينها. المخطط (Schema) هو القواعد التي تحكم تلك البنية: العناصر الإلزامية والاختيارية وصيغها وترتيبها. المخطط قالب، والبنية مستند يتبع القالب.
هل تتغيّر البنية باختلاف نوع الفاتورة؟
الأقسام الثلاثة الكبرى ثابتة في كل الأنواع. تختلف بعض الحقول ورمز نوع الفاتورة InvoiceTypeCode بين الفاتورة الضريبية (B2B) والمبسّطة (B2C) والإشعارات، لكن الهيكل العام واحد.
