المرحلة الثانية من الفاتورة الإلكترونية ليست مجرد موعد تلتزم به منشأتك، بل مجموعة متطلبات تقنية دقيقة يجب أن يلبّيها نظامك المحاسبي قبل أن تصدر أول فاتورة متوافقة. في المرحلة الأولى كان يكفي أن تصدر فاتورة رقمية منظّمة وتحفظها. أما المرحلة الثانية فتفرض ربطاً مباشراً مع منصة فاتورة التابعة لهيئة الزكاة والضريبة والجمارك، وتوقيعاً تشفيرياً، وبنية بيانات محددة لكل فاتورة.
هذا الدليل لا يكرر مواعيد الموجات ولا جدول التطبيق الزمني. إذا أردت معرفة موعد موجة منشأتك بالتحديد فستجده في دليل مراحل ومواعيد تطبيق الفاتورة الإلكترونية. هنا نركّز على شيء واحد فقط: قائمة المتطلبات التقنية الفعلية لمرحلة الربط والتكامل، وما الذي يجب أن ينتجه نظامك في كل فاتورة لكي يقبلها النظام.
ما الذي تعنيه المرحلة الثانية على المستوى التقني
المرحلة الثانية تُعرف رسمياً باسم مرحلة الربط والتكامل. الفكرة الجوهرية أن الفاتورة لم تعد ملفاً محلياً على جهازك، بل رسالة منظّمة تُرسل إلى منصة فاتورة لحظة إصدارها أو خلال مهلة محددة بعدها. الهيئة تتحقق من كل فاتورة، توقّعها أو تعتمدها، ثم تعيدها إليك.
هذا التحول يفرض على نظامك المحاسبي قدرات لم تكن مطلوبة من قبل. عليه أن يولّد ملف الفاتورة بصيغة قياسية، ويوقّعه بختم تشفيري، ويربطه بسلسلة الفواتير السابقة، ويتصل بواجهة برمجية مؤمّنة مع الهيئة. أي حلقة ناقصة في هذه السلسلة تعني فاتورة مرفوضة.
الفرق بين المرحلتين يتضح في النقاط التالية:
- المرحلة الأولى: إصدار وحفظ فاتورة رقمية منظّمة، بلا ربط مباشر مع الهيئة.
- المرحلة الثانية: ربط فوري مع منصة فاتورة، توقيع تشفيري، معرّف فريد، وسلسلة تجزئة بين الفواتير.
لفهم تفاصيل ما كانت تتطلبه المرحلة الأولى، راجع دليل المرحلة الأولى من الفاتورة الإلكترونية. وللاطلاع على الإطار الكامل للنظام السعودي، تصفّح صفحة الفاتورة الإلكترونية الرسمية.
متطلبات المرحلة الثانية في صورة واحدة
التسجيل وشهادة الختم التشفيري CSID
بنية XML وفق معيار UBL 2.1
الختم التشفيري والتوقيع بالمفتاح الخاص
المعرّف الفريد UUID وتجزئة Hash المتسلسلة
رمز الاستجابة السريع QR المنظّم
نموذج الربط: الاعتماد أو الإبلاغ
تتلخص المتطلبات التقنية للمرحلة الثانية في ست ركائز مترابطة. لا يكفي أن يلبّي نظامك بعضها، بل يجب أن يلبّيها جميعاً في كل فاتورة. نستعرض كل ركيزة بالتفصيل في الأقسام التالية.
الركيزة الأولى: التسجيل والشهادة الرقمية CSID
قبل أن تصدر أي فاتورة متوافقة، يجب أن يحصل نظامك على شهادة هوية رقمية من الهيئة. تسمى هذه الشهادة معرّف شهادة الامتثال، أو CSID اختصاراً. هي بمثابة هوية موثّقة تربط جهاز الإصدار لديك بالهيئة، ولا يمكن توقيع الفواتير بدونها.
تمر عملية الحصول على الشهادة بمرحلتين. الأولى شهادة الامتثال المبدئية، وتُصدَر بعد اجتياز نظامك لاختبارات الامتثال في بيئة المحاكاة. الثانية شهادة الإنتاج، وتُعرف باسم PCSID، وتُصدَر عند الانتقال إلى البيئة الفعلية. الشهادة الأولى للاختبار، والثانية للتشغيل الحقيقي.
خطوات الحصول على الشهادة على المستوى التقني:
- توليد طلب توقيع شهادة (CSR) من داخل نظامك المحاسبي.
- إدخال رمز التحقق (OTP) الذي تحصل عليه من بوابة فاتورة في الهيئة.
- استلام شهادة الامتثال المبدئية CSID وتخزينها بأمان.
- تنفيذ فواتير اختبارية في بيئة المحاكاة للتأكد من القبول.
- طلب شهادة الإنتاج PCSID والانتقال إلى الإصدار الفعلي.
الشهادة مرتبطة بوحدة الإصدار، أي بنقطة بيع أو فرع أو نظام محدد. المنشأة التي تملك عدة فروع أو عدة أنظمة إصدار تحتاج إلى شهادة لكل وحدة. إدارة هذه الشهادات وتجديدها جزء من المتطلب التقني، لا خطوة تُنجز مرة واحدة وتُنسى.
كثير من المنشآت تتعثر في هذه الخطوة تحديداً، لأنها تتطلب تعاملاً مع مفاتيح التشفير وطلبات التوقيع. النظام المحاسبي الجيد يخفي هذا التعقيد، فيكفي أن تدخل رمز التحقق من بوابة فاتورة، ويتولى النظام بقية الخطوات. هذا يحوّل عملية تقنية شائكة إلى بضع نقرات داخل واجهة بسيطة.
من المهم أيضاً أن تنتبه إلى صلاحية الشهادة. الشهادة لها مدة محددة، وعند اقترابها من الانتهاء يجب تجديدها قبل أن تنقطع قدرتك على الإصدار. النظام المتوافق ينبّهك إلى موعد التجديد ويتولاه بأقل تدخل ممكن، فلا تتوقف فوترتك فجأة.
الركيزة الثانية: بنية الفاتورة بصيغة UBL 2.1 XML
الفاتورة في المرحلة الثانية ليست ملف PDF ولا صورة. هي ملف XML منظّم يتبع معيار UBL 2.1 المعتمد عالمياً للمستندات التجارية. هذا المعيار يحدد بدقة كيف تُكتب كل خانة في الفاتورة، من اسم البائع إلى قيمة الضريبة على كل بند.
تأخذ الفاتورة شكلين مقبولين. الأول ملف XML خالص للفواتير بين المنشآت. الثاني صيغة PDF/A-3 تحتوي ملف XML مدمجاً بداخلها، وتُستخدم غالباً مع الفواتير المبسّطة الموجّهة للأفراد. في الحالتين، البيانات المنظّمة هي ما يقرؤه النظام، لا الشكل المرئي.
أبرز الحقول الإلزامية التي يجب أن يولّدها نظامك ضمن ملف UBL:
- الرقم الضريبي للبائع واسمه القانوني وعنوانه الوطني.
- بيانات المشتري عند الفواتير بين المنشآت، بما فيها رقمه الضريبي.
- تاريخ الإصدار ووقته بدقة الطابع الزمني.
- تفاصيل كل بند: الوصف، الكمية، سعر الوحدة، نسبة الضريبة وقيمتها.
- إجمالي الفاتورة قبل الضريبة وقيمة الضريبة والإجمالي النهائي.
- معرّف البائع الإضافي عند التعامل مع الجهات الحكومية.
أي حقل ناقص أو غير مطابق لقواعد المعيار يؤدي إلى رفض الفاتورة. لهذا يجب أن يبني النظام الملف وفق القواعد تلقائياً، لا أن يترك صياغته للمستخدم. الفرق بين الفاتورة المنظّمة والفاتورة الورقية القديمة يتضح في دليل أنواع الفواتير الإلكترونية.
تكمن أهمية المعيار في أنه لغة موحّدة تفهمها أنظمة الهيئة دون لبس. حين تلتزم كل المنشآت بالبنية نفسها، يستطيع النظام التحقق من ملايين الفواتير آلياً. لهذا لا مجال للاجتهاد في ترتيب الحقول أو صياغتها، فالقواعد محددة وصارمة.
المعيار يفرض أيضاً قواعد حسابية على القيم داخل الفاتورة. مجموع البنود يجب أن يساوي الإجمالي قبل الضريبة، وقيمة الضريبة يجب أن تطابق نسبتها المطبّقة، والإجمالي النهائي يجب أن يجمع الاثنين بدقة. أي تعارض بين هذه القيم يكشفه النظام ويرفض الفاتورة. النظام المحاسبي الذي يحسب هذه القيم تلقائياً يحميك من هذا النوع من الأخطاء.
الركيزة الثالثة: الختم التشفيري والتوقيع الرقمي
إنشاء ملف UBL 2.1 في النظام
تطبيق الختم التشفيري بالمفتاح الخاص
حساب التجزئة Hash والمعرّف UUID
توليد رمز QR
الاعتماد أو الإبلاغ عبر منصة فاتورة
كل فاتورة في المرحلة الثانية يجب أن تحمل ختماً تشفيرياً. الختم التشفيري توقيع رقمي يُنشأ باستخدام المفتاح الخاص المرتبط بشهادة CSID. وظيفته إثبات أن الفاتورة صدرت من جهة موثّقة، وأنها لم تتعرض لأي تعديل بعد إصدارها.
يعتمد الختم على بنية المفاتيح العامة، حيث يملك نظامك مفتاحاً خاصاً يوقّع به، ومفتاحاً عاماً يتيح للهيئة التحقق من صحة التوقيع. التوقيع يُحسب على محتوى الفاتورة نفسه، فأي تغيير في رقم أو حرف يفسد التوقيع ويكشف العبث فوراً.
على المستوى العملي، يجب أن يكون نظامك قادراً على إنشاء التوقيع وحفظه داخل الفاتورة بصيغة قياسية، وإدارة المفاتيح بأمان دون كشف المفتاح الخاص. هذه عملية تقنية معقدة، ولهذا يتولاها النظام المحاسبي تلقائياً بدلاً من أن يطلبها من المستخدم.
الفكرة الجوهرية وراء الختم أنه يحوّل الفاتورة إلى مستند موثّق لا يقبل الإنكار. البائع لا يستطيع التنصّل من فاتورة وقّعها، والمشتري يستطيع التأكد من مصدرها، والهيئة تتحقق من سلامتها. هذه الثقة الرقمية هي ما يجعل الفاتورة الإلكترونية بديلاً قانونياً كاملاً عن الورق.
لاحظ أن الختم يختلف عن مجرد تشفير الفاتورة. التشفير يخفي المحتوى، أما الختم فيثبت صحته دون إخفائه. الفاتورة تبقى مقروءة، لكنها تحمل توقيعاً يكشف أي عبث. هذا التمييز مهم لفهم ما يفعله نظامك فعلاً في كل عملية إصدار.
الركيزة الرابعة: المعرّف الفريد UUID وسلسلة التجزئة Hash
تتطلب المرحلة الثانية أن تحمل كل فاتورة معرّفاً فريداً عالمياً يسمى UUID. هذا المعرّف يميّز الفاتورة عن أي فاتورة أخرى في النظام كله، ويمنع التكرار أو التزوير في الترقيم.
إلى جانب المعرّف الفريد، يجب أن يحسب النظام قيمة تجزئة لكل فاتورة. التجزئة بصمة رقمية تُشتق من محتوى الفاتورة. والأهم أن كل فاتورة تحمل أيضاً تجزئة الفاتورة السابقة لها، فتتكون سلسلة مترابطة تُعرف بسلسلة التجزئة.
فائدة هذه السلسلة أنها تضمن سلامة التسلسل. لو حاول أحد حذف فاتورة أو إدراج فاتورة في المنتصف، لانكسرت السلسلة وظهر الخلل. هذه الآلية تجعل دفتر الفواتير سجلاً لا يقبل التلاعب الرجعي. مسؤولية نظامك أن يحسب التجزئة ويربطها بالفاتورة السابقة في كل عملية إصدار، دون تدخل يدوي.
المعرّف الفريد UUID يختلف عن رقم الفاتورة المتسلسل المعتاد. رقم الفاتورة قد يتكرر بين منشأتين، أما المعرّف الفريد فمصمّم ليكون فريداً على مستوى العالم. هذا يضمن أن كل فاتورة في نظام الهيئة تحمل بصمة لا تتطابق مع أي فاتورة أخرى.
الجمع بين المعرّف الفريد وسلسلة التجزئة يبني سجلاً محكماً. المعرّف يضمن عدم التكرار، والسلسلة تضمن عدم الحذف أو الإدراج. معاً يشكّلان طبقة حماية تجعل التلاعب في الفواتير شبه مستحيل، وهو هدف أساسي للمرحلة الثانية.
الركيزة الخامسة: رمز الاستجابة السريعة QR
كل فاتورة، وخاصة الفاتورة المبسّطة الموجّهة للأفراد، يجب أن تحمل رمز استجابة سريعة. لكن رمز QR في المرحلة الثانية ليس مجرد صورة، بل يحتوي بيانات منظّمة يمكن للهيئة وللمشتري قراءتها والتحقق منها.
تتضمن البيانات داخل الرمز عناصر محددة:
- اسم البائع ورقمه الضريبي.
- الطابع الزمني لإصدار الفاتورة.
- إجمالي الفاتورة وقيمة الضريبة.
- قيمة الختم التشفيري للفاتورة.
- المفتاح العام وبيانات الشهادة في الفواتير المبسّطة.
هذه البنية تجعل الرمز أداة تحقق فعلية، لا زينة على الورق. يستطيع تطبيق الهيئة قراءة الرمز والتأكد من أن الفاتورة صادرة فعلاً من جهة موثّقة. على نظامك أن يولّد الرمز بهذه البنية تلقائياً مع كل فاتورة.
في الفاتورة المبسّطة تحديداً، يكتسب الرمز أهمية مضاعفة. لأن هذه الفاتورة تصدر للأفراد وتبلّغ بها الهيئة لاحقاً، يصبح الرمز هو وسيلة التحقق الفورية المتاحة للمشتري عند الشراء. أي عميل يستطيع مسح الرمز والتأكد من سلامة فاتورته على الفور.
الترميز الصحيح للبيانات داخل الرمز يتبع صيغة محددة تفرضها الهيئة. لا يكفي وضع البيانات كنص عادي، بل يجب ترميزها بالطريقة التي تتوقعها أنظمة التحقق. هذه تفصيلة تقنية أخرى تبرّر اعتمادك على نظام محاسبي يتولاها بدقة بدلاً من بنائها يدوياً.
الركيزة السادسة: نموذج الربط، الاعتماد مقابل الإبلاغ
هنا يظهر فرق جوهري كثيراً ما يُساء فهمه. المرحلة الثانية تفرّق بين نوعين من الربط حسب نوع الفاتورة. الفهم الدقيق لهذا الفرق ضروري لأن آلية التعامل مع الهيئة تختلف بينهما.
نموذج الاعتماد: يخص الفاتورة الضريبية بين المنشآت. هنا ترسل الفاتورة إلى منصة فاتورة وتنتظر اعتمادها قبل تسليمها إلى المشتري. أي أن الفاتورة لا تكتمل قانونياً حتى تعتمدها الهيئة لحظياً.
نموذج الإبلاغ: يخص الفاتورة الضريبية المبسّطة الموجّهة للأفراد. هنا تصدر الفاتورة وتسلّمها للمشتري فوراً، ثم تبلّغ بها الهيئة خلال مهلة أقصاها أربع وعشرون ساعة من الإصدار. الإبلاغ لاحق، والإصدار فوري.
الفرق بين النموذجين يلخّصه الجدول التالي:
| المعيار | الاعتماد (Clearance) | الإبلاغ (Reporting) |
|---|---|---|
| نوع الفاتورة | فاتورة ضريبية بين المنشآت | فاتورة مبسّطة للأفراد |
| توقيت التعامل مع الهيئة | قبل تسليم الفاتورة | خلال 24 ساعة من الإصدار |
| التحقق | اعتماد مسبق من منصة فاتورة | إبلاغ بعد الإصدار |
الفهم العميق لهذا التقسيم يساعدك على معرفة ما ينتظره العميل وما يصل للهيئة في كل حالة. لمزيد من التفصيل حول تصنيفات الفواتير، راجع دليل أنواع الفواتير الإلكترونية.
الواجهة البرمجية: كيف يتصل نظامك بمنصة فاتورة
الركائز الست السابقة تصف ما تحمله الفاتورة. لكن يبقى سؤال عملي: كيف تصل الفاتورة فعلاً إلى الهيئة؟ الجواب عبر واجهة برمجية تطبيقية، أو API، توفّرها منصة فاتورة. هذه الواجهة هي القناة التي يرسل من خلالها نظامك كل فاتورة ويستقبل ردّ الهيئة.
تتعامل الواجهة مع ثلاث عمليات رئيسية يجب أن يدعمها نظامك:
- طلب الامتثال: يرسل نظامك فواتير اختبارية إلى نقطة نهاية الامتثال للتأكد من مطابقتها قبل الإنتاج.
- الاعتماد: يرسل الفاتورة الضريبية بين المنشآت إلى نقطة نهاية الاعتماد، وينتظر ردّاً يحمل حالة القبول أو الرفض.
- الإبلاغ: يرسل الفاتورة المبسّطة إلى نقطة نهاية الإبلاغ خلال المهلة المحددة بعد الإصدار.
كل اتصال يتم عبر بروتوكول آمن، ويحمل بيانات الفاتورة بصيغة منظّمة مع التوقيع. الهيئة ترد على كل طلب برسالة تحدد ما إذا قُبلت الفاتورة أو رُفضت أو قُبلت مع ملاحظات. مسؤولية نظامك أن يقرأ هذا الرد ويتعامل معه: يسلّم الفاتورة المقبولة، ويعيد محاولة المرفوضة بعد التصحيح، ويسجّل الملاحظات.
الفهم المهم هنا أن الربط ليس عملية تُنفّذ مرة واحدة. هو حوار مستمر بين نظامك والهيئة في كل فاتورة على مدار اليوم. لهذا يحتاج النظام إلى آلية موثوقة لإدارة هذا الحوار، بما فيها التعامل مع انقطاع الاتصال وإعادة الإرسال.
استقرار هذا الاتصال شرط أساسي لاستمرار فوترتك. لو فشل الاتصال أثناء إصدار فاتورة بين المنشآت، فلن تكتمل الفاتورة حتى يعود الاتصال ويصل الاعتماد. أما الفاتورة المبسّطة فتصدر فوراً ويبقى الإبلاغ ضمن المهلة المتاحة. النظام الجيد يدير هذه الحالات بهدوء، فيخزّن الفواتير المعلّقة ويعيد إرسالها تلقائياً حين يعود الاتصال، دون أن توقف ذلك حركة بيعك.
أكثر أسباب رفض الفاتورة شيوعاً
معرفة أسباب الرفض الشائعة تساعدك على تقييم جاهزية نظامك. أغلب حالات الرفض ترجع إلى أخطاء تقنية يمكن تفاديها إذا بنى النظام الفاتورة بشكل صحيح من البداية.
أبرز هذه الأسباب:
- حقل إلزامي مفقود أو غير صحيح: مثل رقم ضريبي ناقص أو تنسيق تاريخ خاطئ في ملف UBL.
- ختم تشفيري غير صالح: يحدث عند تعديل الفاتورة بعد توقيعها أو عند خطأ في إدارة المفاتيح.
- انقطاع سلسلة التجزئة: عندما لا تُربط الفاتورة بتجزئة الفاتورة السابقة بشكل صحيح.
- رمز QR ناقص أو غير مطابق: عند غياب أحد العناصر المطلوبة داخل الرمز.
- شهادة منتهية أو غير مفعّلة: عند انتهاء صلاحية الشهادة دون تجديد، أو محاولة الإصدار قبل الحصول على شهادة الإنتاج.
القاسم المشترك بين هذه الأسباب أنها كلها أخطاء تقنية في بناء الفاتورة أو إدارتها. حين يتولى النظام المحاسبي هذه التفاصيل تلقائياً، تختفي معظم أسباب الرفض. لتقييم استعداد منشأتك بشكل منهجي قبل موعد موجتك، تساعدك صفحة برنامج المحاسبة على فهم القدرات المطلوبة.
قائمة التحقق: ما الذي يجب أن ينتجه نظامك
بعد استعراض الركائز الست، نلخّص المتطلب في صورة قائمة تحقق عملية. نظامك المحاسبي جاهز للمرحلة الثانية فقط إذا كان قادراً على القيام بكل بند مما يلي تلقائياً:
- توليد طلب توقيع شهادة والحصول على CSID ثم PCSID من الهيئة.
- بناء كل فاتورة بصيغة UBL 2.1 XML بكل حقولها الإلزامية.
- تطبيق الختم التشفيري على كل فاتورة باستخدام المفتاح الخاص.
- توليد معرّف فريد UUID لكل فاتورة.
- حساب قيمة التجزئة وربطها بالفاتورة السابقة في سلسلة متصلة.
- إنشاء رمز QR يحمل البيانات المنظّمة المطلوبة.
- الاتصال بمنصة فاتورة عبر واجهة برمجية مؤمّنة للاعتماد أو الإبلاغ.
- التعامل مع نموذج الاعتماد للفواتير بين المنشآت ونموذج الإبلاغ للفواتير المبسّطة.
- اختبار كل ذلك في بيئة محاكاة قبل الانتقال للإنتاج.
أي بند ناقص في هذه القائمة يعني أن منشأتك غير جاهزة للمرحلة الثانية. لتقييم سريع لجاهزية منشأتك، استخدم قائمة جاهزية الفاتورة الإلكترونية.
كيف يساعدك قيود على تلبية متطلبات المرحلة الثانية
الجانب التقني في المرحلة الثانية معقّد، لكنه يصبح بسيطاً عندما يتولاه نظام محاسبي متوافق. قيود مصمّم ليلبّي كل ركيزة من الركائز الست دون أن تكتب سطراً واحداً من XML أو تدير مفتاحاً تشفيرياً بنفسك.
- توافق كامل مع المرحلتين: يصدر قيود الفواتير متوافقة مع المرحلة الأولى والثانية وفق متطلبات هيئة الزكاة والضريبة والجمارك.
- تبادل تلقائي مع الهيئة: يربط قيود فواتيرك مع منصة فاتورة ويتولى الاعتماد والإبلاغ تلقائياً حسب نوع الفاتورة.
- بيئة محاكاة للاختبار: يتيح لك قيود اختبار فواتيرك في بيئة محاكاة آمنة قبل الإصدار الفعلي، فتتأكد من القبول دون مخاطرة.
- دعم الجهات الحكومية: يدعم قيود فواتير الجهات الحكومية بإضافة معرّف البائع الإضافي المطلوب عند الحفظ.
- تقليل الأخطاء البشرية: يبني قيود ملف الفاتورة ويوقّعه ويولّد رمزه تلقائياً، فينخفض احتمال الرفض بسبب خطأ يدوي.
بهذا الشكل، تتحول المتطلبات التقنية التي استعرضناها إلى عمليات تلقائية تجري في الخلفية، بينما تركّز أنت على إدارة منشأتك. تعرّف أكثر على توافق قيود مع المرحلة الثانية وعلى تفاصيل الربط مع الهيئة داخل النظام المحاسبي.
جهّز منشأتك للمرحلة الثانية بنظام متوافق
دع قيود يتولى الختم التشفيري والمعرّف الفريد ورمز QR والربط مع الهيئة تلقائياً، وركّز أنت على نمو منشأتك بدل التفاصيل التقنية.
الأسئلة الشائعة
ما الفرق بين شهادة CSID وشهادة PCSID؟
شهادة CSID هي شهادة الامتثال المبدئية التي يحصل عليها نظامك بعد اجتياز اختبارات بيئة المحاكاة. أما PCSID فهي شهادة الإنتاج التي تُصدَر عند الانتقال إلى البيئة الفعلية. الأولى للاختبار والثانية للتشغيل الحقيقي.
هل أحتاج إلى كتابة ملف XML بنفسي؟
لا. النظام المحاسبي المتوافق يبني ملف UBL 2.1 XML تلقائياً وفق قواعد المعيار. مهمتك إدخال بيانات الفاتورة العادية، والنظام يتولى توليد الملف وتوقيعه وإرساله.
ما الفرق بين الاعتماد والإبلاغ في المرحلة الثانية؟
الاعتماد يخص الفواتير بين المنشآت، حيث تُعتمد الفاتورة من الهيئة قبل تسليمها للمشتري. الإبلاغ يخص الفواتير المبسّطة للأفراد، حيث تصدر الفاتورة فوراً وتبلّغ بها الهيئة خلال أربع وعشرين ساعة.
ما فائدة سلسلة التجزئة بين الفواتير؟
سلسلة التجزئة تربط كل فاتورة بالفاتورة السابقة لها عبر بصمة رقمية. هذا يضمن سلامة التسلسل ويكشف أي محاولة لحذف فاتورة أو إدراجها في المنتصف، فيصبح سجل الفواتير غير قابل للتلاعب الرجعي.
هل يمكنني اختبار المتطلبات قبل الإصدار الفعلي؟
نعم. توفّر الهيئة بيئة محاكاة تتيح لك تنفيذ فواتير اختبارية والتأكد من قبولها قبل الانتقال إلى الإنتاج. النظام المحاسبي المتوافق مثل قيود يتيح لك هذه البيئة لتختبر دون مخاطرة على بياناتك الفعلية.
ماذا يحدث إذا كانت فاتورتي غير مطابقة للمتطلبات التقنية؟
الفاتورة غير المطابقة تُرفض من منصة فاتورة، ما يعني أنها غير صالحة قانونياً. أي حقل ناقص في ملف UBL أو ختم تشفيري خاطئ أو معرّف مفقود يؤدي إلى الرفض. لهذا يجب أن يتولى النظام بناء الفاتورة بالكامل تلقائياً لضمان مطابقتها.