قائمة تحقق المرحلة الثانية لزاتكا للشركات السعودية (2026)

المرحلة الثانية لزاتكا (مرحلة التكامل) هي حيث تعلق كثير من الشركات السعودية. المرحلة الأولى كانت تتطلب فقط فواتير مبسّطة بـ QR — طابعتك تستطيع فعل معظم الأمر. أما المرحلة الثانية فتفرض تكاملًا مشفّرًا حقيقيًا مع منصة فاتورة: تسجيل أجهزة وXML موقّع وتخليص فوري لفواتير B2B وتقارير B2C.

هذه قائمة التحقق التي ننفّذها لكل عميل في المرحلة الثانية.

1. تحقّق من موجتك والموعد النهائي

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

2. حصر مصادر الفواتير لديك

اكتب كل نظام يُصدر فاتورة أو إيصالًا:

• ERP (Oracle, SAP, Odoo, NetSuite, Dynamics, مخصص)
• طرفيات نقاط البيع (واحدة لكل فرع، أحيانًا أكثر)
• مدفوعات التجارة الإلكترونية
• تطبيقات البيع الميداني على الموبايل
• أدوات فوترة مستقلة (حتى إكسل يطبع PDF يُحتسب)

كل مصدر فاتورة يحتاج CSID (معرّف الختم المشفّر). نسيان مصدر فاتورة هو السبب رقم 1 لتأخّر الإطلاق.

3. اختر بين التكامل المباشر والوسيط

أمامك مساران:

مباشر. كل مصدر فاتورة يتصل بـ APIs زاتكا بنفسه. زمن أقل. سطح تكامل أكبر. CSIDs أكثر للإدارة. مناسب لـ ERP واحد، مؤلم لتجزئة متعددة الفروع.

وسيط (موصى به للأغلب). خدمة فوترة إلكترونية من سمارت أيديال تجلس بين مصادر فواتيرك وزاتكا. مسار XML موقّع واحد. قائمة إعادة محاولة واحدة. لوحة رفض واحدة. يُصدر ERP ونقاط البيع فاتورة فقط؛ الوسيط يتولى التوقيع والتخليص والتقارير.

للتجزئة متعدّدة الفروع وأي تشغيل بثلاثة مصادر فواتير أو أكثر، الوسيط هو الخيار الأفضل تقريبًا دائمًا.

4. تسجيل CSIDs

لكل جهاز يُصدر فاتورة:

1. سجّل الجهاز على بوّابة فاتورة (الإنتاج، لا الـ sandbox).
2. أنشئ OTP وبادله بـ Production Cryptographic Stamp Identifier (PCSID).
3. خزّن المفتاح الخاص في keystore مدعوم بالأجهزة (HSM على الخادم أو TPM على طرفية POS). تخزين المفاتيح في ملف .pem على القرص ثاني أكثر أسباب ملاحظات التدقيق.

نُؤتمت هذه الخطوة طرفًا إلى طرف للعملاء بأكثر من 3 أجهزة.

5. تحقّق من الـ sandbox أولًا

قبل لمس الإنتاج، يجب أن يجتاز كل قالب فاتورة sandbox زاتكا. حالات الرفض الشائعة:

• رقم التسجيل الضريبي مفقود أو غير صحيح
• حسابات خصومات بنود الفاتورة منحرفة 0.01 ريال (تقريب)
• بيانات المشتري مطلوبة لـ B2B لكنها مفقودة على فاتورة بنمط B2C
• عدم تطابق المجموع الفرعي مع مجموع البنود

ابنِ سير عمل معالجة الرفض قبل الإنتاج. ستحدث حالات رفض — يحتاج فريق التشغيل واجهة لإصلاحها لا تنبيهًا في Slack.

6. خطّط للتحويل بتشغيل متوازٍ

التحويل بأفضل الممارسات:

1. أسبوع -2. كل الفواتير تمرّ عبر الوسيط بوضع تقرير فقط. لا شيء يُرسل لزاتكا. تبني الثقة بأن الوسيط لا يُشوّه الحجم.
2. أسبوع -1. تحويل فواتير B2B إلى تخليص زاتكا. B2C تبقى تقرير فقط.
3. أسبوع 0. تحويل B2C إلى تقارير كاملة. زاتكا الآن هي المصدر الرسمي.
4. أسبوع +2. إيقاف أي مسار قديم "طباعة وتوقيع يدوي".

تجاوز التشغيل المتوازي هو السبب رقم 1 لانفجار تحويل المرحلة الثانية.

7. ابنِ لوحة عمليات، لا مجرّد تكامل

بعد الإطلاق، يحتاج فريق الماليّة أن يرى:

• نسبة نجاح التخليص لكل مصدر (طرفية POS واحدة معطوبة تُسقط 5% من الفواتير بصمت).
• قائمة الرفض بإعادة إرسال بنقرة واحدة.
• إجماليّات يوميّة مُسوّاة بين ERP والوسيط وبوّابة زاتكا.

بدون هذه اللوحة، يتحوّل إقرار الضريبة إلى رحلة إكسل ثلاثة أيام شهريًا.

8. دعم الإنتاج — أوّل 90 يومًا تهم

أكثر إخفاقات المرحلة الثانية تحدث بعد 6 إلى 8 أسابيع من الإطلاق، عندما يكسر تحديث برنامج عند بائع ERP أو POS مخطط XML بصمت. شغّل تسوية يومية آليّة بين زاتكا وإجماليّات ERP لأول 90 يومًا. أصدر تنبيهًا على أي انحراف يزيد عن 0.5%.

تريد المعمارية المرجعية لدينا؟

نفّذت سمارت أيديال المرحلة الثانية لزاتكا داخل Oracle ERP وSAP وOdoo وNetSuite ونصف دزينة من الأنظمة المخصصة. تواصل معنا ونشاركك مخطط المعمارية المرجعية الذي اجتاز كل تدقيق sandbox أجريناه.