بيئة المحاكاة (Sandbox) للمطورين

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

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

ما هي بيئة المحاكاة (Sandbox)؟

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

تعمل المنصة على ثلاث بيئات منفصلة، لكل منها رابط (Endpoint) خاص ونوع شهادة خاص:

• بيئة المطوّر (Developer Portal): للتجارب الأولية السريعة وفهم بنية الواجهات. لا تتطلب شهادة كاملة.
• بيئة المحاكاة (Simulation): البيئة المعتمدة لاختبار التكامل الكامل قبل الإنتاج، وهي محور هذا الدليل.
• بيئة الإنتاج (Production): البيئة الفعلية التي تُسجَّل فيها الفواتير قانونياً لدى الهيئة.

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

لماذا تشترط الهيئة المرور ببيئة المحاكاة؟

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

تخدم هذه البيئة ثلاثة أهداف واضحة:

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

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

شهادة الامتثال (Compliance CSID) ومكانها في بيئة المحاكاة

للعمل في بيئة المحاكاة يحتاج نظامك إلى شهادة خاصة تُسمّى شهادة الامتثال (Compliance CSID). هذه الشهادة هي معرّف الختم التشفيري الخاص ببيئة الاختبار، تُستخرج بطلب توقيع شهادة (CSR) ورمز تحقق مؤقت (OTP) من بوّابة المنصة. بها يوقّع نظامك فواتيره الاختبارية، وبها تتعرّف الهيئة على أن هذا الإصدار قيد التحقق وليس في الإنتاج بعد.

من المهم عدم الخلط بين نوعين من المعرّفات: شهادة الامتثال (Compliance CSID) للاختبار في بيئة المحاكاة، وشهادة الإنتاج (Production CSID) للعمل الفعلي. لا تُستخدم إحداهما مكان الأخرى. الترتيب الصحيح: تستخرج شهادة الامتثال أولاً، تجتاز بها فحوص المحاكاة، ثم تطلب على أساسها شهادة الإنتاج.

نفصّل آلية كل شهادة في دليلين مستقلّين: راجع شهادة CSID: معرّف الختم التشفيري لفهم المعرّف بشكل عام ودورة حياته، وراجع شهادة Compliance CSID: شهادة الامتثال التقني لتفاصيل استخراج شهادة الاختبار عبر CSR و OTP خطوة بخطوة.

المتطلبات قبل البدء في بيئة المحاكاة

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

• رقم تسجيل ضريبي ساري: يجب أن تكون المنشأة مسجَّلة في ضريبة القيمة المضافة لدى الهيئة، فالرقم الضريبي عنصر إلزامي في كل فاتورة.
• رمز تحقق مؤقت (OTP): تستخرجه من بوّابة منصة فاتورة، وتستخدمه مرة واحدة عند طلب شهادة الامتثال. صلاحيته قصيرة، لذا استخرجه لحظة الحاجة إليه.
• طلب توقيع شهادة (CSR): يولّده نظامك ليرسله إلى الهيئة مقابل شهادة الامتثال. يحوي بيانات المنشأة والمفتاح العام.
• بيئة تطوير جاهزة: أداة لإرسال طلبات HTTP، ومكتبة لتوليد ملف XML وفق UBL 2.1، ومكتبة تشفير لحساب القيمة الاختزالية والتوقيع.

توليد طلب توقيع الشهادة ورمز التحقق هو ما يفتح لك باب بيئة المحاكاة. لا نكرّر تفاصيله هنا، بل نحيلك إلى دليل شهادة Compliance CSID الذي يشرح كل حقل في طلب التوقيع وكيفية الحصول على رمز التحقق خطوة بخطوة. ما يهمّنا في هذا الدليل هو ما يحدث بعد أن تملك الشهادة: كيف تختبر بها، وكيف تقرأ النتائج.

العناصر الإلزامية في كل فاتورة محاكاة

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

• معرّف الفاتورة الفريد (UUID): معرّف عالمي فريد لكل فاتورة. تكراره أو غيابه يفسد الفحص فوراً.
• القيمة الاختزالية (Invoice Hash): بصمة رقمية للفاتورة محسوبة بخوارزمية SHA-256. أي تغيير في محتوى الفاتورة يغيّرها بالكامل.
• القيمة الاختزالية للفاتورة السابقة (Previous Invoice Hash): ما يربط الفواتير في سلسلة متّصلة، ويمنع الحذف أو الإقحام دون اكتشاف.
• رمز الاستجابة السريعة (QR Code): إلزامي خصوصاً في الفاتورة المبسّطة (B2C)، ويحوي بيانات الفاتورة وتوقيعها مشفّرة بصيغة TLV.
• الختم التشفيري (Cryptographic Stamp): التوقيع الرقمي الذي تنتجه شهادة الامتثال على محتوى الفاتورة.

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

كيف تُرسل فاتورة اختبارية إلى بيئة المحاكاة؟

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

1. بناء الفاتورة: يولّد نظامك ملف XML وفق مواصفة UBL 2.1، يحوي بيانات البائع والمشتري والبنود وضريبة القيمة المضافة ومعرّف الفاتورة الفريد (UUID).
2. التوقيع والختم: يحسب نظامك القيمة الاختزالية للفاتورة (Hash)، ويربطها بالقيمة الاختزالية للفاتورة السابقة لبناء السلسلة، ثم يوقّعها بشهادة الامتثال ويضيف رمز الاستجابة السريعة (QR).
3. الإرسال إلى الواجهة المناسبة: ترسل الفاتورة الضريبية (B2B) إلى واجهة الاعتماد (Clearance)، والفاتورة المبسّطة (B2C) إلى واجهة الإبلاغ (Reporting).
4. قراءة الرد: تستقبل رد الهيئة الذي يبيّن إن كانت الفاتورة قد اجتازت الفحوص أم لا، مع تفاصيل أي خطأ.

مثال مبسّط على هيكل طلب اعتماد فاتورة ضريبية إلى بيئة المحاكاة عبر الواجهة البرمجية:

POST /einvoicing/simulation/invoices/clearance/single
Host: gw-fatoora.zatca.gov.sa
Accept-Version: V2
Authorization: Basic {Compliance-CSID-credentials}
Content-Type: application/json

{
  "invoiceHash": "{base64-encoded-SHA256-hash}",
  "uuid": "{invoice-UUID}",
  "invoice": "{base64-encoded-signed-XML}"
}

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

ما الفحوص التي تُجريها الهيئة على كل فاتورة؟

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

• فحص البنية (Schema validation): يتحقق من مطابقة ملف XML لمواصفة UBL 2.1، ووجود كل العناصر الإلزامية بترتيبها وأنواعها الصحيحة.
• فحص قواعد العمل (Business rules): يتحقق من صحة الحسابات. مجموع البنود يساوي الإجمالي، ونسبة ضريبة القيمة المضافة 15% محسوبة بدقة، وفئة الإعفاء أو الصفرية موثّقة عند استخدامها.
• فحص التوقيع (Signature validation): يتحقق من أن الفاتورة موقّعة بشهادة امتثال سارية، وأن التوقيع الرقمي سليم ولم يُعبَث بالمحتوى بعده.
• فحص سلسلة الفواتير (Hash chain): يتحقق من أن القيمة الاختزالية للفاتورة السابقة مذكورة بشكل صحيح، لضمان تسلسل الفواتير دون انقطاع أو تكرار.

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

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

يأتي رد المنصة على هيئة كائن منظَّم يحوي حالة الفاتورة وقائمة بالملاحظات. تنقسم الملاحظات إلى نوعين يجب التفريق بينهما بوضوح:

• أخطاء (Errors): تمنع اعتماد الفاتورة. ما دام هناك خطأ واحد، تُرفض الفاتورة ولا تُعتمد. يجب إصلاحها كلها.
• تنبيهات (Warnings): لا تمنع الاعتماد، لكنها تشير إلى أمور ينبغي مراجعتها. الفاتورة تُقبل مع وجودها، لكن تجاهلها قد يسبب مشكلات لاحقة في الإنتاج.

مثال مبسّط على شكل رد يحوي حالة الفاتورة وملاحظاتها:

{
  "clearanceStatus": "NOT_CLEARED",
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "BR-KSA-15",
        "message": "Invoice total does not match the sum of line items"
      }
    ],
    "warningMessages": []
  }
}

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

أخطاء شائعة في بيئة المحاكاة وكيفية تجاوزها

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

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

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

دورة حياة فاتورة اختبارية كاملة

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

1. إنشاء البيانات: يجمع نظامك بيانات البائع والمشتري والبنود والكميات والأسعار، ويحسب ضريبة القيمة المضافة على كل بند بنسبة 15%.
2. توليد ملف XML: يصوغ النظام هذه البيانات في ملف XML وفق مواصفة UBL 2.1، مع وضع معرّف الفاتورة الفريد (UUID) في موضعه.
3. حساب القيمة الاختزالية: يحسب النظام بصمة الفاتورة بخوارزمية SHA-256، ويربطها بالقيمة الاختزالية للفاتورة المعتمَدة السابقة.
4. التوقيع التشفيري: يوقّع النظام الفاتورة بشهادة الامتثال، فتصبح مستنداً موقّعاً لا يمكن تعديله دون كشف.
5. توليد رمز الاستجابة السريعة: يبني النظام رمز QR من البيانات الموقّعة بترميز TLV.
6. الإرسال للاعتماد: يرسل النظام الفاتورة الضريبية إلى واجهة الاعتماد في مسار المحاكاة، وينتظر الرد.
7. قراءة النتيجة: إن عادت بحالة اعتماد، فقد اكتملت الرحلة بنجاح. وإن عادت بخطأ، يصلح النظام السبب ويعيد الإرسال.

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

الفرق بين بيئة المحاكاة وبيئة الإنتاج

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

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

أفضل ممارسات الاختبار في بيئة المحاكاة

للوصول إلى الإنتاج بأقل عدد من المحاولات، اتبع هذه الممارسات أثناء عملك في بيئة المحاكاة:

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

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

قائمة الانتقال من المحاكاة إلى الإنتاج

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

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

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

كيف يبسّط قيود التكامل مع منصة فاتورة؟

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

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

أسئلة شائعة عن بيئة المحاكاة

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

هل يمكنني تجاوز بيئة المحاكاة والذهاب مباشرة إلى الإنتاج؟
لا. تشترط الهيئة اجتياز فحوص المحاكاة بشهادة الامتثال قبل أن تمنح نظامك شهادة الإنتاج. المرور بالمحاكاة شرط فني لا اختيار.

ما الفرق بين شهادة الامتثال وشهادة الإنتاج؟
شهادة الامتثال (Compliance CSID) تعمل في بيئة المحاكاة للاختبار، وشهادة الإنتاج (Production CSID) تعمل في بيئة الإنتاج للتشغيل الفعلي. تُستخرج شهادة الإنتاج بعد اجتياز المحاكاة.

هل الفحوص في بيئة المحاكاة مطابقة لفحوص الإنتاج؟
نعم. فحوص البنية وقواعد العمل والتوقيع وسلسلة الفواتير متطابقة في البيئتين. لهذا تُعدّ المحاكاة اختباراً صادقاً لجاهزيتك الفعلية.

كم فاتورة اختبارية ينبغي أن أرسل قبل الانتقال؟
لا يوجد رقم ثابت. المعيار هو التغطية لا العدد: اختبر كل أنواع الفواتير وحالاتها الاستثنائية حتى تعود كلها بحالة قبول نظيفة دون أخطاء.

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