دورة حياة الفاتورة الإلكترونية تقنياً

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

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

لماذا «دورة حياة» وليست «خطوة إصدار»

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

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

نظرة على الرحلة الكاملة

دورة حياة الفاتورة الإلكترونية في المرحلة الثانية تتألف من ثماني مراحل متسلسلة. كل مرحلة تأخذ مخرجات المرحلة السابقة مدخلاً لها، ولا يمكن قفز أي حلقة. التسلسل العام كالآتي:

1. التوليد: بناء ملف الفاتورة بصيغة UBL XML.
2. المعرّفات: إسناد UUID و ICV و PIH للفاتورة.
3. التجزئة (Hashing): حساب البصمة الرقمية للفاتورة.
4. التوقيع: الختم التشفيري عبر شهادة CSID.
5. التحقق: فحص المخطط (Schema) والقواعد (Business Rules).
6. المقاصة أو الإبلاغ: المقاصة الفورية للفواتير B2B، والإبلاغ خلال 24 ساعة للفواتير B2C.
7. التسليم: تسليم الفاتورة بصيغة PDF/A-3 مع XML مضمّن.
8. الأرشفة: حفظ نسخة قابلة للتدقيق لمدة الاحتفاظ النظامية.

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

الإنفوجرافيك الأول: خريطة المراحل الثماني

المرحلة الأولى: التوليد (Generate)، بناء ملف UBL XML

تبدأ الرحلة عند الضغط على «حفظ الفاتورة» في النظام. لا تُخزَّن الفاتورة كنص حر، بل تُبنى ملفاً منظّماً يتبع معيار UBL 2.1 (Universal Business Language) بصيغة XML. هذا المعيار هو الأساس الذي فرضته الهيئة لكل الفواتير في المرحلة الثانية، وهو معيار عالمي مفتوح يصف الفاتورة بعناصر معرّفة مسبقاً.

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

مثال مبسّط على بنية رأس الفاتورة بصيغة UBL XML:

<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>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cbc:IssueTime>14:30:05</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
</Invoice>

القيمة InvoiceTypeCode تحدّد نوع الفاتورة. الرمز 388 يعني فاتورة ضريبية، والقناع name يفرّق بين الفاتورة القياسية (B2B) والفاتورة الضريبية المبسّطة (B2C). هذا التمييز يحكم لاحقاً مسار المرحلة السادسة: مقاصة أم إبلاغ. لذلك يُحسم نوع الفاتورة من لحظة التوليد، لا في مرحلة متأخرة.

عنصر ProfileID يحدّد ملف التوافق المستخدم، وعملة الفاتورة تكون دائماً الريال السعودي (SAR) للمعاملات المحلية. كل قيمة رقمية تُكتب بدقة عشرية محدّدة لتفادي أخطاء التقريب التي قد ترفضها قواعد التحقق. التفاصيل الكاملة لبنية الملف ومساراته موضّحة في صفحة بنية فاتورة UBL XML.

المرحلة الثانية: المعرّفات (UUID و ICV و PIH)

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

• UUID: معرّف فريد عالمياً (Universally Unique Identifier) بطول 128 بت. يميّز الفاتورة عن أي فاتورة أخرى في العالم، ويُولَّد آلياً عند الإنشاء. لا يتكرر UUID نفسه مرتين عملياً.
• ICV: عدّاد الفاتورة (Invoice Counter Value). رقم تسلسلي متصاعد لا يتكرر ولا ينقص داخل النظام، يثبت تتابع الفواتير وعدم حذف أي منها. تبدأ قيمته من واحد وتزيد بمقدار واحد مع كل فاتورة.
• PIH: بصمة الفاتورة السابقة (Previous Invoice Hash). قيمة التجزئة الخاصة بالفاتورة التي سبقتها مباشرة، وهي ما يربط الفواتير في سلسلة متماسكة.

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

الفرق الجوهري بين UUID و ICV يستحق التوضيح: UUID معرّف عشوائي فريد لا علاقة له بالترتيب، بينما ICV عدّاد مرتّب يثبت التسلسل الزمني. الأول يجيب عن سؤال «أي فاتورة هذه؟» والثاني يجيب عن «أين موقعها في السلسلة؟». الشرح التفصيلي لكل معرّف وكيفية توليده في صفحة معرّفات الفاتورة UUID و ICV و PIH.

المرحلة الثالثة: التجزئة (Hashing)، بصمة الفاتورة

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

تُحسب البصمة على النسخة المعيارية (Canonical) من XML بعد تطبيق تحويل C14N، لضمان أن النظامين المختلفين يصلان للبصمة ذاتها من المحتوى ذاته. سبب هذا التحويل أن XML قد يُكتب بطرق متعددة متكافئة (مسافات، ترتيب السمات، ترميز) لكنها تعطي بصمات مختلفة. التحويل المعياري يوحّد الصياغة قبل الحساب. الناتج يُرمَّز بصيغة Base64 ويُدرَج لاحقاً في حقل PIH للفاتورة التالية، فتتولّد السلسلة.

# حساب بصمة الفاتورة (تمثيل توضيحي)
canonical_xml = c14n_transform(invoice_xml)
invoice_hash  = base64(sha256(canonical_xml))
# تُمرَّر invoice_hash كقيمة PIH للفاتورة التالية

خاصية مهمة في SHA-256 أنها أحادية الاتجاه: يمكن حساب البصمة من المحتوى، لكن لا يمكن استرجاع المحتوى من البصمة. هذا يكفي للتحقق من السلامة دون كشف بيانات الفاتورة. منطق الخوارزمية وخطوات التحويل المعياري مشروحة بالكامل في صفحة تجزئة الفاتورة الإلكترونية (Hashing).

المرحلة الرابعة: التوقيع (Sign)، الختم التشفيري

هنا يدخل عنصر الأمان الأهم. تُوقَّع الفاتورة توقيعاً رقمياً (Cryptographic Stamp) باستخدام مفتاح خاص مرتبط بشهادة CSID. الاسم الكامل للشهادة هو Compliance Cryptographic Stamp Identifier، وهي الشهادة التي تصدرها الهيئة للمنشأة عند الربط مع منصة فاتورة.

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

آلية التحقق تعمل عكسياً: أي طرف يملك المفتاح العام (المُضمَّن في الشهادة) يستطيع التأكد أن التوقيع يطابق البصمة، فيثبت أن الفاتورة لم تُمَس. هذا هو جوهر البنية التحتية للمفاتيح العامة (PKI) التي تقوم عليها المرحلة الثانية.

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

الإنفوجرافيك الثاني: تسلسل التوليد والتوقيع

المرحلة الخامسة: التحقق (Validation)، المخطط والقواعد

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

• تحقق المخطط (Schema Validation): فحص بنيوي يتأكد أن XML يطابق مخطط XSD المعتمد. يكشف العناصر المفقودة، والترتيب الخاطئ، وأنواع البيانات غير الصحيحة. هذا الفحص شكلي بحت: هل الملف مبني بالشكل الصحيح؟
• تحقق القواعد (Business Rules): فحص منطقي يطبّق قواعد الهيئة. مثلاً: أن مجموع البنود يساوي الإجمالي، وأن نسبة ضريبة القيمة المضافة صحيحة، وأن الرقم الضريبي بالتنسيق الصحيح. هذا الفحص دلالي: هل القيم منطقية ومتوافقة مع القانون؟

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

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

المرحلة السادسة: المقاصة (Clearance) أو الإبلاغ (Reporting)

هنا تتفرّع الرحلة حسب نوع الفاتورة المحدّد في المرحلة الأولى. القاعدة الحاكمة بسيطة: الفاتورة القياسية (B2B) تخضع للمقاصة الفورية، والفاتورة المبسّطة (B2C) تخضع للإبلاغ خلال 24 ساعة. هذا التفرّع هو أهم نقطة قرار في الرحلة كلها.

المقاصة الفورية للفواتير B2B

الفاتورة القياسية الموجّهة لمنشأة أخرى تُرسَل إلى منصة فاتورة قبل تسليمها للمشتري. تتحقق المنصة من الفاتورة وتضيف ختمها الخاص، ثم تعيدها «مُقاصّة» (Cleared). لا تُعدّ الفاتورة سارية حتى تتم مقاصتها. هذه عملية متزامنة (Real-time) تتم خلال ثوانٍ، ويجب أن ينتظر النظام ردّ المنصة قبل إكمال العملية.

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

الإبلاغ خلال 24 ساعة للفواتير B2C

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

المنصة تجمع الفواتير المبسّطة وترسلها دفعة أو فرادى ضمن مهلة 24 ساعة. لو فشل الإرسال، يعيد النظام المحاولة دون تعطيل البيع. آلية الإبلاغ والمهلة النظامية موضّحة في صفحة الإبلاغ خلال 24 ساعة (Reporting).

المرحلة السابعة: التسليم (Deliver) بصيغة PDF/A-3 مع XML مضمّن

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

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

اختيار PDF/A-3 تحديداً مقصود: الـ A تعني Archival (أرشيفي)، والرقم 3 يعني الإصدار الذي يدعم تضمين أي نوع ملف. صيغ PDF العادية لا تضمن قابلية القراءة بعد سنوات، أما PDF/A فمصمّمة للحفظ طويل الأمد. مواصفات الصيغة وطريقة تضمين XML في صفحة صيغة PDF/A-3 وتضمين XML.

المرحلة الثامنة: الأرشفة (Archive)

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

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

مثال متكامل: رحلة فاتورة واحدة من البداية للنهاية

لنتتبّع فاتورة قياسية واحدة عبر المراحل الثماني، لنرى كيف تتصل الحلقات عملياً:

1. يصدر المحاسب فاتورة بقيمة 1,150 ر.س لمنشأة عميلة (1,000 ر.س + 150 ر.س ضريبة قيمة مضافة). يبني النظام ملف UBL XML بالعناصر الإلزامية.
2. يُسند للفاتورة UUID فريد، وقيمة ICV (لنفترض 142)، وقيمة PIH المساوية لبصمة الفاتورة رقم 141.
3. يحسب النظام بصمة SHA-256 للفاتورة على نسختها المعيارية، فينتج توقيع البصمة.
4. يوقّع النظام البصمة بالمفتاح الخاص لشهادة CSID، ويُدرج التوقيع داخل XML.
5. يتحقق النظام محلياً: المخطط سليم، ومجموع البنود يطابق الإجمالي، والضريبة 15% صحيحة.
6. بما أن الفاتورة قياسية (B2B)، تُرسَل لمنصة فاتورة للمقاصة. تردّ المنصة بفاتورة مُقاصّة مختومة.
7. يُولَّد ملف PDF/A-3 يحوي العرض المرئي مع XML الموقّع المضمّن، ويُسلَّم للعميل.
8. تُؤرشف النسخة الموقّعة، وتصبح بصمتها قيمة PIH للفاتورة رقم 143.

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

الإنفوجرافيك الثالث: المقاصة مقابل الإبلاغ

كيف تتماسك السلسلة: الربط بين المراحل

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

• خيط البصمة: بصمة كل فاتورة (المرحلة الثالثة) تصبح قيمة PIH للفاتورة التالية (المرحلة الثانية)، فتتولّد سلسلة لا يمكن كسرها.
• خيط العدّاد: قيمة ICV المتصاعدة تثبت أن لا فاتورة حُذفت أو أُدرجت خارج التسلسل.
• خيط التوقيع: الختم التشفيري (المرحلة الرابعة) يربط الفاتورة بهوية المنشأة عبر شهادة CSID، فلا يمكن انتحالها.

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

دور المنصة المحاسبية في تنفيذ الرحلة

المنشأة ليست مطالَبة ببناء XML يدوياً ولا حساب البصمات ولا إدارة المفاتيح. هذه كلها مهام تقنية تتولاها المنصة المحاسبية المتوافقة. وفق متطلبات المرحلة الثانية، ينفّذ قيود المراحل الثماني آلياً: يبني ملف UBL XML بالعناصر الإلزامية، ويسند المعرّفات، ويحسب البصمة، ويوقّع عبر شهادة CSID المُدارة، ويتحقق محلياً، ويتولى المقاصة أو الإبلاغ حسب نوع الفاتورة، ثم يسلّم PDF/A-3 ويؤرشف النسخة.

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

أخطاء شائعة وكيف تُكتشف في كل مرحلة

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

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

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

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

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

هل يمكن قفز أي مرحلة في دورة حياة الفاتورة؟

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

ما الفرق بين المقاصة والإبلاغ؟

المقاصة عملية متزامنة للفواتير القياسية (B2B): تُرسَل الفاتورة للهيئة وتُعتمد قبل تسليمها للمشتري. الإبلاغ عملية غير متزامنة للفواتير المبسّطة (B2C): تُسلَّم للمشتري فوراً ثم تُبلَّغ للهيئة خلال 24 ساعة.

ما علاقة PIH ببصمة الفاتورة؟

قيمة PIH للفاتورة الحالية هي بصمة (Hash) الفاتورة التي سبقتها مباشرة. هذا الربط ينشئ سلسلة مترابطة تكشف أي حذف أو إدراج أو تعديل لاحق.

هل يحتاج المطوّر التعامل المباشر مع شهادة CSID في كل فاتورة؟

لا. تُربط شهادة CSID مرة واحدة عند الإعداد، ثم تديرها المنصة المحاسبية آلياً عند كل توقيع. لا حاجة للتعامل اليدوي مع المفاتيح في كل عملية إصدار.

لماذا تُستخدم صيغة PDF/A-3 تحديداً في التسليم؟

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

كم مدة الاحتفاظ بالفاتورة المؤرشفة؟

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