زاتكا المرحلة الثانية: دليل التطبيق خطوة بخطوة 2026
دليل بصري كامل لمرحلة الربط والتكامل مع هيئة الزكاة والضريبة والجمارك — من إنشاء CSR إلى Clearance والأرشفة. كل ما تحتاج معرفته في سبع خطوات.
المرحلة الثانية من الفوترة الإلكترونية في المملكة العربية السعودية ليست مجرّد ترقية تقنيّة — هي تحوّل كامل في كيفيّة إصدار الفاتورة. بدل توليدها محليّاً وتسليمها للعميل مباشرة، يجب أن تمرّ كل فاتورة عبر بوابة الهيئة لحظيّاً أو خلال 24 ساعة بحسب نوعها. هذا الدليل يأخذك خطوة بخطوة من الصفر إلى أوّل فاتورة معتمدة على الإنتاج.
CSR → CSID → UBL 2.1 XML → XAdES Signature → Clearance / Reporting → Archive
الخطوات السبع
تحقّق من موجة الالتزام الخاصّة بك
هيئة الزكاة والضريبة والجمارك (ZATCA) تُبلّغ المنشآت قبل ستة أشهر على الأقل من تاريخ الربط. التزم بالتاريخ المُعلَن في خطاب الموجة المُرسَل إليك عبر البريد الإلكتروني الرسمي وبوابة فاتورة.
- افتح بوابة Fatoora واطّلع على لوحة الموجات.
- احفظ خطاب الإبلاغ — يُطلب أحياناً عند التدقيق.
- إذا لم يصلك إشعار وتجاوز إيرادك السنوي حدّ الموجة الحاليّة، تواصل مع الهيئة فوراً.
تنبيه: غرامة التأخّر في الالتزام تبدأ من 5,000 ريال وتتصاعد مع التكرار.أعدّ بيئة الإصدار في نظامك المحاسبي
المرحلة الثانية تفرض ربط نظامك مع API الهيئة. تأكّد من أنّ نظامك (ERP أو POS أو مولّد الفواتير) يدعم UBL 2.1 و XAdES B-B للتوقيع، ويستطيع تخزين CSID بأمان.
- حدّث نظامك إلى أحدث إصدار معتمد من المورّد.
- تحقّق من توافق ساعة الخادم مع UTC — انحراف دقيقة واحدة يُسقط التوقيع.
- أنشئ مستخدم خدمة (Service Account) خاص بالإرسال إلى ZATCA.
أنشئ طلب توقيع شهادة (CSR)
كل وحدة إصدار (Solution Unit) تحتاج زوج مفاتيح ECDSA secp256k1 و CSR موقّع. تُولّد المفاتيح داخل نظامك ولا تُرسل أبداً المفتاح الخاص.
- املأ حقول CSR: الاسم القانوني، الرقم الضريبي، نوع الفاتورة (B2B / B2C)، الموقع الجغرافي.
- احفظ المفتاح الخاص في خزنة آمنة (Vault / HSM).
- ابعث CSR إلى الـ Sandbox أوّلاً للاختبار قبل الإنتاج.
تنبيه: خطأ متكرّر: استخدام نفس CSR لأكثر من جهاز — كل وحدة إصدار تحتاج CSR مستقلّاً.احصل على CSID من بوابة فاتورة
بعد رفع CSR ستحصل على Compliance CSID (للاختبار) ثم Production CSID (للإصدار الفعلي). كلاهما يُستخدم في التوقيع وفي المصادقة على طلبات API.
- OTP يُرسل إلى البريد المسجّل في الهيئة — صلاحيّته ساعة واحدة فقط.
- احفظ CSID وكلمة السر (Secret) في متغيّرات بيئة مشفّرة.
- ادخل بيانات Production CSID فقط بعد اجتياز اختبارات الـ Compliance.
ولّد الفاتورة بصيغة UBL 2.1 XML
صيغة الفاتورة موحّدة: ملف XML يتبع معيار UBL 2.1 مع امتدادات ZATCA. يجب أن يحتوي على PIH (Previous Invoice Hash) لربط الفواتير بسلسلة غير قابلة للتلاعب.مولّد فاتورة ZATCA أو محوّل XML.
- كل فاتورة تحمل UUID فريد و ICV (عدّاد تسلسلي) و PIH (هاش الفاتورة السابقة).
- اكتب الحقول العربية بالعربيّة الفصحى — الأرقام الضريبية بالأرقام اللاتينيّة.
- تأكّد من تطابق إجمالي الضريبة في XML مع الإجمالي المعروض على الفاتورة المرئيّة.
تنبيه: تستطيع توليد UBL 2.1 صحيح فوراً عبر أداةوقّع الفاتورة وأرسلها (Clearance / Reporting)
فواتير B2B (ضريبية) تمرّ بـ Clearance: تُرسل لحظيّاً للهيئة وتعود معتمدة قبل تسليمها للعميل. فواتير B2C (مبسّطة) تمرّ بـ Reporting: تُرسل خلال 24 ساعة من الإصدار.
- التوقيع: XAdES B-B باستخدام CSID والمفتاح الخاص.
- أدخل توقيع الهيئة (Cryptographic Stamp) في XML قبل الطباعة.
- QR Code من Base64 من نموذج TLV — إلزامي على كلّ فاتورة مطبوعة أو PDF.
تنبيه: إذا رفضت الهيئة الفاتورة، عالج الخطأ خلال نفس اليوم — لا يُسمح بإعادة الإرسال بنفس الـ ICV.أرشف وراقب الأداء
يجب الاحتفاظ بكل فاتورة XML الموقّعة + رد الهيئة لمدّة 6 سنوات على الأقل. ابنِ لوحة مراقبة لمعدّل القبول من الهيئة — أيّ هبوط مفاجئ يشير إلى عطل في التوقيع أو الاتصال.
- خزّن XML الأصلي + Cleared Invoice من الهيئة.
- سجّل كل محاولة فاشلة مع رمز الخطأ ووقت الإرسال.
- أنشئ تنبيه إذا تجاوز الفشل 1% من الفواتير اليوميّة.
أخطاء شائعة في التطبيق
- إرسال فواتير B2B بعد التسليم للعميل بدل قبله — يُعدّ مخالفة لـ Clearance.
- نسيان حقل PIH في أوّل فاتورة بعد إعادة تهيئة النظام — كسر في السلسلة.
- QR Code يحوي بيانات قبل التوقيع بدل البيانات الموقّعة.
- استخدام Compliance CSID في الإنتاج — كل الفواتير تُرفض.
- عدم تخزين الـ XML الأصلي قبل التوقيع — استرجاع مستحيل عند الخطأ.
لماذا المرحلة الثانية مختلفة جذرياً عن المرحلة الأولى؟
المرحلة الأولى كانت أقرب إلى ضبط شكل الفاتورة داخل النظام: منع الفواتير الورقية، إضافة QR Code، حفظ السجلات، وإصدار الفاتورة من نظام إلكتروني لا يسمح بالتلاعب السهل. المرحلة الثانية أعمق بكثير لأنها تربط كل وحدة إصدار بمنظومة الهيئة، وتحوّل الفاتورة إلى مستند تقني موقّع ومترابط بسلسلة هاش. لذلك لا يكفي أن تبدو الفاتورة صحيحة للعميل؛ يجب أن تكون صحيحة للآلة أيضاً: XML مطابق، توقيع صحيح، عدّاد ICV متسلسل، PIH لا ينكسر، ووقت إصدار مضبوط.
الفارق العملي أن الخطأ في المرحلة الأولى كان غالباً خطأ عرض أو أرشفة. أمّا في المرحلة الثانية فالخطأ قد يوقف البيع نفسه في فواتير B2B، لأن الفاتورة الضريبية يجب أن تحصل على clearance قبل تسليمها. لهذا السبب يجب أن يُدار مشروع المرحلة الثانية كمشروع تشغيل يومي لا كمهمة تقنية تُنجز مرة واحدة. تحتاج اختباراً، مراقبة، خطط رجوع، ومسؤولية واضحة بين المحاسبة وتقنية المعلومات ومورّد النظام.
| المحور | المرحلة الأولى | المرحلة الثانية | الأثر التشغيلي |
|---|---|---|---|
| الربط | لا يوجد ربط إلزامي لحظي | ربط وتكامل مع منصة فاتورة | أي انقطاع اتصال يحتاج آلية معالجة |
| صيغة الفاتورة | فاتورة إلكترونية محلية | XML UBL 2.1 مع امتدادات ZATCA | المحاسبة وحدها لا تكفي؛ يلزم توافق تقني |
| التوقيع | QR Code ومتطلبات عرض | XAdES وتوقيع تشفيري وCSID | حماية المفاتيح أصبحت جزءاً من الامتثال |
| فواتير B2B | تصدر وتسلم مباشرة | Clearance قبل التسليم | الفشل قد يوقف البيع أو التحصيل |
| الأرشفة | حفظ الفواتير | حفظ XML الموقّع ورد الهيئة | الأرشيف يجب أن يكون قابلاً للتدقيق الفني |
خريطة المسؤوليات داخل الشركة
أكثر مشاريع الربط تعثراً ليست التي تجهل XML، بل التي لا يعرف فيها كل فريق ما الذي يملكه. المحاسب يظن أن الموضوع عند المورّد، والمورّد ينتظر بيانات من تقنية المعلومات، وتقنية المعلومات لا تعرف تفاصيل الفواتير الضريبية، والإدارة لا تكتشف الخلل إلا عند رفض أول دفعة فواتير. الحل أن تُقسّم المسؤوليات بوضوح قبل البدء.
- المالية والمحاسبة: تملك صحة البيانات الضريبية: الرقم الضريبي، نوع العميل، النسب، الخصومات، بنود الفاتورة، وتطابق الإجماليات.
- تقنية المعلومات: تملك بيئة التشغيل: المفاتيح، الخوادم، الوقت، الأمان، النسخ الاحتياطي، الاتصال بالـ API، وسجلات الأخطاء.
- مورّد النظام: يملك توافق النظام مع UBL 2.1 وXAdES وواجهات الهيئة، ويجب أن يقدّم دليلاً عملياً لا وعوداً عامة.
- الإدارة: تملك قرار الميزانية والموعد وخطة الطوارئ إذا تأخر المورّد أو رفضت الهيئة فواتير الإنتاج.
- المراجعة الداخلية: تتحقق من أن الأرشفة والتسلسل والردود محفوظة وأن تغيير الإعدادات لا يتم بلا صلاحيات.
قائمة فحص قبل رفع أول CSR
رفع CSR قبل تجهيز البيانات يشبه تشغيل خط إنتاج قبل معايرة الآلات. قد تحصل على شهادة، لكنك ستكتشف لاحقاً أن وحدة الإصدار أو بيانات المنشأة أو إعدادات الفواتير غير مضبوطة. استخدم هذه القائمة كمرحلة ما قبل الربط:
- طابق بيانات المنشأة: الاسم القانوني، العنوان الوطني، الرقم الضريبي، الفروع، وأرقام السجلات التجارية.
- احصر وحدات الإصدار: كل جهاز POS أو نظام ERP أو فرع يصدر فواتير يحتاج تعريفاً واضحاً، وقد يحتاج CSR مستقلّاً.
- ثبّت الساعة والمنطقة الزمنية: استخدم NTP وتحقق من UTC؛ أخطاء الوقت من أكثر أسباب رفض التوقيع إرباكاً.
- راجع أنواع الفواتير: ضريبية، مبسطة، إشعارات دائن، إشعارات مدين، وفواتير تصدير إن وجدت.
- اختبر سيناريوهات الخصم والمرتجع: لا تختبر فاتورة مبيعات عادية فقط؛ اختبر ضريبة صفرية، خصم على مستوى السطر، إلغاء، مرتجع جزئي، وعميل لا يملك رقم ضريبي.
- جهّز خزنة أسرار: المفتاح الخاص وCSID لا يوضعان في ملف نصي على سطح المكتب ولا داخل مستودع الكود.
- اتفق على سجل أخطاء: كل رفض يجب أن يظهر برمز واضح، وقت، رقم فاتورة، وحدة إصدار، وسبب قابل للتصحيح.
سيناريوهات اختبار لا تتجاهلها
كثير من الأنظمة تنجح في فاتورة الاختبار البسيطة ثم تنهار عند أول حالة واقعية. السبب أن الفاتورة السعودية في الحياة اليومية ليست دائماً بيعاً نقدياً بسطر واحد وضريبة 15%. يوجد خصم، مرتجع، عميل أجنبي، ضريبة صفرية، أكثر من فرع، وأكثر من جهاز. لذلك يجب بناء مصفوفة اختبار تغطي الحالات التي ستحدث فعلاً في العمل.
- فاتورة B2B كاملة: عميل برقم ضريبي، أكثر من سطر، خصم، وضريبة صحيحة. يجب أن تمر عبر Clearance قبل التسليم.
- فاتورة B2C مبسطة: عميل فرد، QR Code صحيح، وإرسال Reporting خلال 24 ساعة.
- إشعار دائن: مرتجع جزئي بعد بيع سابق، مع ربط الإشعار بالفاتورة الأصلية.
- فاتورة مرفوضة: اختبر كيف يظهر الخطأ للمحاسب، وهل يستطيع التصحيح دون كسر ICV أو تكرار رقم.
- انقطاع اتصال: ماذا يحدث عند توقف الإنترنت أو API؟ هل تتراكم الفواتير؟ هل يوجد إرسال لاحق؟ من يراقب؟
- تجديد شهادة: اختبر دورة انتهاء الشهادة قبل موعدها، لأن فشل التجديد في الإنتاج يوقف الإصدار فجأة.
كيف تقرأ أخطاء الرفض من زاتكا؟
رسائل الرفض ليست كلها بنفس الخطورة. بعضها يعني أن الفاتورة غير صالحة ويجب إصلاح XML أو التوقيع، وبعضها تحذير يمكن متابعته، وبعضها مشكلة اتصال مؤقتة. التعامل الصحيح يبدأ بتصنيف الخطأ لا بالضغط على زر إعادة الإرسال عشوائياً.
| نوع الخطأ | المعنى المحتمل | التصرف الصحيح |
|---|---|---|
| XML غير مطابق | حقل ناقص أو تنسيق خاطئ أو إجمالي غير متطابق | أصلح التوليد من النظام ولا تعد الإرسال قبل التصحيح |
| فشل التوقيع | مفتاح أو CSID أو وقت خادم غير صحيح | راجع الساعة والمفاتيح والشهادة ولا تغيّر بيانات الفاتورة بلا سبب |
| رفض ضريبي | نسبة أو رقم ضريبي أو نوع فاتورة غير صحيح | أعد مراجعة قواعد الضريبة مع المالية |
| خطأ اتصال | API غير متاح أو مهلة شبكة | استخدم retry منظم وسجل المحاولة ولا تنشئ فاتورة جديدة |
| تحذير | الفاتورة قبلت مع ملاحظة | راقب التكرار وصحح السبب في الإصدار التالي |
الأرشفة التي تنجح وقت التدقيق
الأرشفة في المرحلة الثانية ليست حفظ PDF للعميل فقط. المدقق قد يحتاج XML الأصلي، XML بعد اعتماد الهيئة، ردّ الـ API، وقت الإرسال، رقم ICV، UUID، PIH، وبيانات وحدة الإصدار. إن كان الأرشيف مبعثراً بين النظام والبريد ومجلدات الموظفين فلن يكون قابلاً للدفاع عنه. المطلوب أرشيف منظم حسب المنشأة والفرع ووحدة الإصدار والتاريخ، مع صلاحيات قراءة واضحة وسجل تغييرات.
احتفظ أيضاً بنسخة من إعدادات كل فترة: إصدار النظام، الشهادة المستخدمة، سياسة التوقيع، وقواعد الضرائب. عند حدوث خلاف بعد سنة، ستحتاج أن تثبت ليس فقط أن الفاتورة موجودة، بل أنها صدرت بالإعدادات الصحيحة في وقتها. اربط الأرشفة بنسخ احتياطي مشفّر واختبر الاستعادة دورياً؛ النسخة الاحتياطية التي لم تُستعد من قبل مجرد افتراض.
خطة تشغيل بعد الإطلاق
النجاح الحقيقي يبدأ بعد أول فاتورة إنتاج. خلال أول شهر، راقب المؤشرات يومياً: عدد الفواتير المرسلة، نسبة القبول، متوسط زمن الرد، عدد الفواتير المعلقة، أكثر أخطاء الرفض تكراراً، ووحدات الإصدار التي تفشل أكثر من غيرها. إذا تجاوز الفشل 1% في يوم واحد، فهذا ليس ضجيجاً طبيعياً بل إنذار مبكر. وإذا ظهرت الأخطاء في فرع واحد أو جهاز واحد، فالسبب غالباً إعداد محلي لا مشكلة عامة.
- يومياً: راجع لوحة القبول والرفض، وتأكد من عدم وجود فواتير B2C لم تُرسل خلال المهلة.
- أسبوعياً: طابق عدد الفواتير في النظام المحاسبي مع عدد الفواتير المؤرشفة وردود الهيئة.
- شهرياً: اختبر عينة من الفواتير: XML، PDF، QR، الضريبة، ورد الهيئة.
- ربع سنوي: راجع صلاحية الشهادات والمفاتيح وخطة التجديد، واختبر الاستعادة من النسخ الاحتياطي.
أسئلة يجب أن تسألها لمورّد النظام قبل التوقيع
كثير من عروض الأنظمة تقول إنها "متوافقة مع زاتكا"، لكن هذه العبارة وحدها لا تكفي. التوافق الحقيقي يظهر في التفاصيل: هل النظام يدعم فروعاً متعددة؟ هل يحفظ رد الهيئة؟ هل يوضح سبب الرفض للمحاسب؟ هل يملك بيئة اختبار؟ هل جرّب حالات الإشعار الدائن والخصومات والضريبة الصفرية؟ اسأل أسئلة محددة واطلب إجابات مكتوبة، لأنك وقت التعطل لن تستطيع الاعتماد على وصف تسويقي عام.
- هل يدعم النظام Clearance وReporting معاً؟ بعض الأنظمة تضبط الفواتير المبسطة جيداً لكنها تتعثر في فواتير B2B.
- هل لكل وحدة إصدار CSR مستقل؟ اسأل كيف يُدار أكثر من فرع وأكثر من كاشير وأكثر من بيئة تشغيل.
- أين يُحفظ المفتاح الخاص؟ الإجابة المقبولة: خزنة أسرار أو تخزين مشفّر بصلاحيات محدودة، لا ملف قابل للنسخ.
- كيف تظهر أخطاء الهيئة؟ يجب أن يرى المستخدم سبباً مفهوماً، لا رسالة تقنية مبهمة مثل validation failed فقط.
- هل يوجد تقرير فواتير معلّقة؟ الفواتير التي لم تُرسل أو لم تُقبل أخطر من الفواتير المرفوضة الواضحة.
- هل يحفظ النظام XML ورد الهيئة 6 سنوات؟ PDF وحده لا يكفي في المرحلة الثانية.
- ما خطة تجديد CSID؟ اطلب تنبيهاً قبل انتهاء الشهادة، وإجراءً موثقاً للتجديد دون إيقاف البيع.
كيف تبني لوحة مراقبة للامتثال؟
لوحة المراقبة ليست رفاهية تقنية؛ هي أداة حماية من تراكم أخطاء صغيرة إلى مخالفة كبيرة. ابدأ بلوحة بسيطة تعرض اليوم، آخر 7 أيام، وآخر 30 يوماً. لا تحتاج رسوماً معقدة في البداية؛ تحتاج أرقاماً لا تُخفي الحقيقة: كم فاتورة صدرت، كم أُرسلت، كم قُبلت، كم رُفضت، وكم بقيت معلّقة. إذا كان النظام يصدر 1,000 فاتورة يومياً و20 منها معلقة، فهذا خطر حتى لو كانت نسبة القبول تبدو جيدة.
| المؤشر | لماذا يهم؟ | إنذار مبكر |
|---|---|---|
| نسبة القبول | تثبت أن الفواتير تمر عبر الهيئة دون خلل | أقل من 99% في يوم عمل عادي |
| الفواتير المعلقة | تكشف ما لم يُرسل أو لم يحصل على رد | أي فاتورة B2B معلقة وقت التسليم |
| متوسط زمن الرد | يكشف بطء API أو الشبكة أو النظام | زيادة مفاجئة فوق المعتاد |
| أكثر رموز الرفض | توجه الإصلاح إلى السبب الحقيقي | تكرار نفس الرمز في أكثر من فرع |
| فواتير B2C المتأخرة | لها مهلة إرسال خلال 24 ساعة | أي فاتورة تقترب من نهاية المهلة |
خطة الطوارئ عند تعطل الربط
أسوأ وقت لوضع خطة الطوارئ هو لحظة تعطل البيع. قبل الإطلاق، اكتب سيناريو واضحاً لما يحدث إذا توقف اتصال الإنترنت، أو تعطلت واجهة الهيئة، أو فشل توقيع الفواتير، أو انتهت الشهادة فجأة. الخطة لا تعني الالتفاف على المتطلبات؛ بل تعني معرفة من يقرر، ماذا يسجل، كيف تُحفظ الفواتير، ومتى تُرفع المشكلة للهيئة أو المورّد. في فواتير B2B، لأن clearance مطلوب قبل التسليم، يجب أن تكون نقطة القرار واضحة: هل تؤجل التسليم؟ هل تعالج الخطأ فوراً؟ هل تستخدم وحدة إصدار بديلة معتمدة؟
- حدد مالك الحادث: شخص واحد ينسق بين المالية والمورّد وتقنية المعلومات، حتى لا تضيع الساعات في مراسلات متفرقة.
- احفظ الدليل: رقم الفاتورة، وقت المحاولة، رسالة الخطأ، وحدة الإصدار، ولقطة من سجل النظام.
- افصل بين B2B وB2C: فواتير B2B تحتاج اعتماداً قبل التسليم، أما B2C فلها منطق reporting خلال المهلة.
- لا تكرر الفاتورة عشوائياً: إنشاء فاتورة جديدة لكل محاولة قد يكسر التسلسل ويصعّب التسوية.
- راجع بعد الحادث: كل حادث يجب أن يخرج بسبب جذري وإجراء منع تكرار، لا مجرد "تم الحل".
نموذج جاهزية سريع قبل الإنتاج
قبل الانتقال من sandbox إلى production، قيّم جاهزيتك بصدق. إن أجبت "لا" على أي بند حرج، فأنت لا تؤجل مشروعاً تقنياً فقط، بل تحمي التشغيل من تعطل مكلف. لا تنتقل للإنتاج لأن الموعد اقترب؛ انتقل لأن الدليل يقول إن النظام جاهز.
الاسم، الرقم الضريبي، العنوان، والفروع راجعتها المالية
لا يوجد جهاز أو فرع يصدر فواتير خارج الخطة
خصومات، مرتجعات، إشعارات، ضريبة صفرية، B2B وB2C
المفتاح الخاص وCSID في تخزين مشفّر بصلاحيات محدودة
XML الأصلي، XML المعتمد، PDF، QR، ورد الهيئة محفوظة
نسبة القبول والمعلقات والأخطاء تظهر يومياً
من يتصرف؟ متى نصعّد؟ كيف نوثق؟
المحاسب يعرف معنى الرفض ولا يتجاوزه يدوياً
متى تحتاج مستشاراً ضريبياً أو تكاملاً مخصصاً؟
الشركات الصغيرة التي تستخدم نظاماً سحابياً معتمداً قد تطبّق المرحلة الثانية بإعدادات محدودة. لكن بعض الحالات تحتاج خبرة أعمق: تعدد الفروع، تعدد نقاط البيع، فواتير تصدير، خصومات معقدة، تكامل ERP قديم، أو حجم فواتير كبير. إذا كان لديك أكثر من مصدر للفواتير، فلا تجعل كل مصدر يبني تكامله بمعزل عن الآخر؛ ستنتهي بأرشيفات مختلفة وأخطاء مختلفة ومنطق ضريبي غير موحد.
استعن بمستشار حين لا تستطيع الإجابة بثقة عن سؤالين: ما البيانات التي يجب أن تظهر في XML لكل سيناريو؟ وكيف نثبت بعد سنة أن كل فاتورة صدرت وقُبلت وحُفظت كما ينبغي؟ أمّا التكامل المخصص فيلزم عادة عندما يكون نظامك الداخلي قديماً أو عندما تحتاج ربطاً بين ERP ومستودعات وفروع ومبيعات إلكترونية في وقت واحد. هنا تصبح زاتكا جزءاً من معمارية التشغيل لا إضافة على الهامش.
جدول زمني واقعي للتطبيق
إذا وصل إشعار الموجة قبل ستة أشهر، فلا تنتظر الشهر الأخير. المشروع الجيد يوزّع العمل على مراحل قصيرة قابلة للقياس: أسبوعان للجرد، أسبوعان لاختيار المورّد أو مراجعة النظام الحالي، شهر للاختبارات الفنية، شهر لاختبار المستخدمين والسيناريوهات الواقعية، ثم فترة تشغيل تجريبي قبل الإنتاج. الضغط في آخر أسبوع ينتج قرارات سيئة: قبول نظام غير جاهز، تجاهل حالات اختبار، حفظ مفاتيح في أماكن غير آمنة، أو إطلاق دون مراقبة.
| الفترة | ما يحدث فيها | مخرج واضح |
|---|---|---|
| الأسبوع 1-2 | جرد الفروع ووحدات الإصدار وأنواع الفواتير والأنظمة | قائمة نطاق معتمدة |
| الأسبوع 3-4 | تقييم النظام والمورّد، وتحديد فجوات UBL وAPI والأرشفة | قرار: تحديث جاهز أم تكامل مخصص |
| الشهر 2 | توليد CSR، إعداد sandbox، واختبار الحالات الأساسية والمعقدة | تقرير اختبار بلا أخطاء حرجة |
| الشهر 3 | تدريب المستخدمين، ضبط التقارير، واختبار الانقطاع والرفض | تشغيل تجريبي مراقب |
| قبل الإنتاج | مراجعة المفاتيح والأرشيف والمراقبة وخطة الطوارئ | اعتماد جاهزية موقع من المالية وتقنية المعلومات |
ملف تسليم يجب أن يبقى عندك
عند انتهاء المشروع، لا تكتفِ بأن النظام يعمل. اطلب ملف تسليم واضحاً من المورّد أو الفريق الداخلي. هذا الملف هو ما يحميك عندما يتغير الموظفون أو يتوقف المورّد أو يحدث تدقيق بعد سنة. يجب أن يتضمن وصف البنية، قائمة وحدات الإصدار، مكان حفظ الأسرار، طريقة التجديد، طريقة قراءة الأخطاء، وأسماء المسؤولين. بدون ملف تسليم، تصبح المعرفة محصورة في شخص واحد؛ وإذا غادر، عاد المشروع إلى نقطة الصفر.
- خريطة الأنظمة: أين يصدر كل نوع فاتورة، وكيف تصل إلى زاتكا، وأين يُحفظ الرد.
- قائمة الشهادات: كل CSID، تاريخ الإصدار، تاريخ الانتهاء، وحدة الإصدار المرتبطة به، ومسؤول التجديد.
- سياسة الوصول: من يستطيع تغيير إعدادات الضريبة أو المفاتيح أو وحدات الإصدار.
- دليل الأخطاء: أكثر رموز الرفض شيوعاً، سببها، ومن يعالجها.
- إجراء الاستعادة: كيف تستعيد الأرشيف أو إعدادات النظام إذا تعطل الخادم أو فُقدت بيانات.
أسئلة شائعة
هل يمكن إصدار الفاتورة إذا تعطلت منصة الهيئة؟
يعتمد على نوع الفاتورة وآلية النظام ومتطلبات الهيئة وقت الحادث. المهم أن تسجل المحاولة والوقت والخطأ، وألا تنشئ تسلسلات عشوائية أو تسلم فاتورة B2B قبل clearance دون أساس نظامي واضح.
هل أحتاج CSR لكل فرع؟
ليس الفرع وحده هو المعيار؛ المعيار وحدة الإصدار. إذا كان لكل فرع جهاز أو نظام يصدر فواتير مستقلاً فقد يحتاج تعريفاً وشهادة منفصلة بحسب تصميم النظام.
ما الفرق بين UUID وICV؟
UUID معرّف فريد للفاتورة، أما ICV فهو عدّاد تسلسلي داخل وحدة الإصدار. كلاهما مهم، لكن كسر ICV يكشف خللاً في تسلسل الفواتير.
هل PDF كافٍ للأرشفة؟
لا. PDF مفيد للعميل، لكن الامتثال الفني يحتاج XML الموقّع ورد الهيئة والبيانات المرتبطة بالإرسال، محفوظة لمدة 6 سنوات.
هل يمكن تعديل الفاتورة بعد clearance؟
لا تتعامل معها كملف قابل للتعديل. التصحيح عادة يتم بإشعار دائن أو مدين مرتبط بالفاتورة الأصلية، لا بتغيير الفاتورة المعتمدة.
ما أكثر سبب خفي للفشل؟
اختلافات صغيرة بين الإجماليات المعروضة وXML: التقريب، الخصم، الضريبة على مستوى السطر، أو ترتيب العمليات الحسابية.
ما الفرق بين Clearance وReporting؟
Clearance لفواتير B2B الضريبية: تُرسل للهيئة وتُعتمد قبل تسليمها للعميل. Reporting للفواتير المبسطة B2C: تُسلم للعميل فوراً ثم تُرفع للهيئة خلال 24 ساعة. الخلط بينهما — كتسليم فاتورة B2B قبل اعتمادها — مخالفة مباشرة.
ما الفرق بين Compliance CSID وProduction CSID؟
Compliance CSID شهادة مرحلة الاختبار والتأهيل، وProduction CSID شهادة الإنتاج الفعلي. استخدام شهادة الاختبار في الإنتاج يعني رفض كل الفواتير — وهو من أكثر أخطاء الإطلاق شيوعاً.
متى تصلني موجة الالتزام وكيف أعرفها؟
الهيئة تُبلغ المنشآت قبل ستة أشهر على الأقل من تاريخ الربط الإلزامي، عبر البريد الرسمي وبوابة فاتورة. الموجات تتحدد بحجم الإيرادات الخاضعة — والقاعدة: ابدأ التجهيز قبل وصول الإشعار لا بعده.
كم تستغرق رحلة التطبيق الكاملة واقعياً؟
لمنشأة متوسطة بنظام جاهز: نحو 3 أشهر موزعة على جرد النطاق (أسبوعان)، تقييم النظام (أسبوعان)، اختبارات sandbox (شهر)، تدريب وتشغيل تجريبي (شهر). التكامل المخصص لأنظمة قديمة أو فروع متعددة يحتاج أطول.
ما أهم مؤشر يُراقب يومياً بعد الإطلاق؟
الفواتير المعلقة — التي لم تُرسل أو لم تحصل على رد — فهي أخطر من المرفوضة الواضحة. يليها نسبة القبول (إنذار إذا هبطت دون 99%) وفواتير B2C التي تقترب من نهاية مهلة الـ 24 ساعة.
هل يلزمني مطور أو مستشار للمرحلة الثانية؟
المنشأة الصغيرة بنظام سحابي معتمد تطبق غالباً بإعدادات محدودة دون مطور. استعن بخبرة أعمق عند تعدد الفروع ونقاط البيع، أو تكامل ERP قديم، أو حين لا تستطيع الإجابة بثقة: ما الذي يجب أن يظهر في XML لكل سيناريو؟
ماذا يحدث إذا انتهت صلاحية CSID في الإنتاج؟
يتوقف توقيع الفواتير فجأة ويتوقف معه إصدار فواتير B2B كلياً. الوقاية: سجل لكل شهادة تاريخ انتهاء ومسؤول تجديد وتنبيه مسبق بشهرين، واختبر دورة التجديد في sandbox قبل أن تحتاجها في الإنتاج.
كيف تعرف أن تطبيقك أصبح ناضجاً؟
التطبيق الناضج لا يُقاس بمرور أول فاتورة فقط، بل بقدرتك على تشغيل المنظومة شهوراً دون مفاجآت. العلامات الجيدة واضحة: فريق المالية يفهم أسباب الرفض، تقنية المعلومات ترى مؤشرات الفشل قبل أن يتصل العميل، الأرشيف يُستعاد خلال دقائق، الشهادات تُجدد قبل انتهائها، وكل تغيير في الضريبة أو الفروع يمر بإجراء مضبوط. عندما تصبح زاتكا جزءاً من روتين التشغيل اليومي لا مشروعاً مرعباً عند كل موجة، تكون وصلت إلى مستوى امتثال قابل للاستمرار.
اجعل هذا المعيار هو خط النهاية الحقيقي: لا توجد فاتورة بلا حالة واضحة، ولا خطأ بلا مالك، ولا شهادة بلا موعد تجديد، ولا أرشيف بلا اختبار استعادة موثق.
جرّب الأدوات
أنشئ فاتورة مبسّطة أو ضريبية مع QR Code جاهز للطباعة.
حوّل بيانات الفاتورة إلى UBL 2.1 XML متوافق مع الهيئة.
مراجع رسميّة
هذا الدليل لأغراض إرشاديّة. للحالات الخاصّة راجع الهيئة أو مستشاراً ضريبيّاً مرخّصاً.
أدلّة ذات صلة
مقارنة عمليّة لضريبة القيمة المضافة (VAT) بين السعودية والإمارات والبحرين وعُمان: النِسَب، حدود التسجيل، الإقرارات، الإعفاءات، والاختلافات الجوهريّة.
مقارنة تقنيّة وتنظيميّة بين منظومة الفوترة الإلكترونيّة في السعوديّة (ZATCA Phase 2) ومنظومة مصر (ETA): البنية، التوقيع، الـ Clearance، المواعيد، العقوبات.
مقارنة عمليّة بين نظام حماية البيانات الشخصيّة السعودي (PDPL) ولائحة GDPR الأوروبيّة: نطاق التطبيق، الحقوق، نقل البيانات خارج الحدود، والغرامات.
تطبيق ضريبة القيمة المضافة 15% حسب القطاع: المطاعم والتجزئة والعقار والمقاولات والخدمات المهنية والصحة والتعليم والتجارة الإلكترونية، مع حد التسجيل وخصم المدخلات.