أنت شركة تنفيذ ERPNext، وعميلك وصله إشعار الإلزام — أو سيصله مع المجموعة 25 في فبراير 2027. هو لا يريد نظامًا جديدًا؛ هو دفع لك لتبني له نظامه. والسؤال الذي يقع عليك أنت: من أين يأتي امتثال زاتكا؟
أمامك ثلاثة طرق، ولكل منها ثمن يظهر متأخرًا.
الطرق الثلاثة كما هي
- تبنيه بنفسك. واجهة الهيئة موثقة ومتاحة — وبناء التكامل يعني لكل عميل: طلب شهادة CSR وشهادتي CCSID/PCSID، وتوقيع XAdES بترتيب عناصر لا يغتفر، وسلسلة عدّاد وبصمة لكل جهاز، وتمييز الإجازة عن التبليغ، ثم التعامل مع 135 كود رفض. كتبنا الطريق كاملًا في دليل الربط من CSR إلى CSID — اقرأه قبل أن تقرر أن تسلكه، فهو أسابيع هندسة لأول عميل، وتشغيل دائم بعده.
- تشغّل ksa_compliance. التطبيق المفتوح المعروف في بيئة Frappe — حقيقي ويعمل، ومجانيته مجانية ترخيص لا مجانية تشغيل: أنتم من يدير شهادات كل عميل وتجديدها، وترقيات التطبيق مع كل تغيير من الهيئة، وتشخيص الرفض حين يتصل العميل غاضبًا. مع خمسة عملاء هذا عبء؛ مع عشرين هذا قسم.
- تضيف طبقة امتثال. نظام عميلك يبقى كما بنيتَه، والفاتورة تخرج منه إلى واجهة REST تتولى كل ما في البند الأول — وهذا هو الطريق الذي بنينا له واجهة الشركاء.
كيف تعمل واجهة الشركاء
المبدأ: أضف دعم ZATCA إلى نظامك خلال دقائق، وليس أسابيع. والميكانيكا:
- مفتاح واحد لشركتك (Partner API Key) يدير حسابك ويُصدر فواتير كل تجّارك — التاجر المقصود يُسمَّى في كل نداء، فلا مفاتيح متناثرة تحرسها لكل عميل.
- إنشاء التاجر نداء واحد، ثم يكمل عميلك ربطه مع منصة فاتورة بنفسه عبر Onboarding Link ترسله له — أو من داخل شاشتك إن أردت التحكم الكامل. الشهادات وفحوص التوافق تجري خلف الستار.
- عميل بعدة فروع؟ لكل تاجر فروع، ولكل فرع جهاز EGS بشهادته وسلسلته المستقلة يُفعَّل برمز تحقق من بوابة فاتورة — وفاتورة الفرع تسمّي
branch_idوdevice_idفي النداء نفسه. متطلب الإصدار المتوازي من نقاط بيع منفصلة، جاهز من الواجهة نفسها. - التاجر النشط فوترته بلا حد — يستهلك اشتراكًا من رصيد اتفاقك، وإن غادر حرّرت اشتراكه فعاد لرصيدك.
- حين تُرفض فاتورة تفهم السبب: الرد يحمل الكود ورابط شرحه العربي في مرجع الأكواد — نفس المرجع الذي يستخدمه السوق كله حين لا يفهم رفض الهيئة.
الوثائق: دليل الشركاء بالعربية للفهم، ومرجع API الإنجليزي الكامل للبناء.
أين يلتقي هذا مع ERPNext عمليًا
لا نقدّم تطبيق Frappe جاهزًا اليوم — ولن ندّعيه. التكامل الصادق أبسط من ذلك: فاتورة المبيعات في ERPNext لحظة اعتمادها (on_submit على Sales Invoice، أو Webhook من إعدادات Frappe) ترسل بياناتها — العميل وسطور الأصناف والضريبة ونوع الفاتورة — نداءَ REST واحدًا إلى واجهة الإصدار باسم التاجر صاحب الشأن، ويعود الرد بالفاتورة المقبولة ورمز QR وروابط ملفاتها. حقول الطلب والرد كلها في المرجع؛ ومهندس اعتاد Server Scripts يرى النهاية من هنا.
متى تكون الاستضافة الذاتية هي الصواب؟
لنقلها بوضوح: إذا كانت سياسة عميلك تمنع مرور بيانات فواتيره بطرف ثالث، أو كان عندك فريق تشغيل يريد ملكية كل مكوّن ويحتمل كلفته، فـksa_compliance المستضاف ذاتيًا خيار محترم وقد كتبنا أعلاه أنه حقيقي ويعمل. المقايضة ليست جودة الفاتورة — المقبول مقبول — بل من يحمل التشغيل: الشهادات وتجديدها، والسلاسل، والترقيات، ورموز الرفض، لكل عميل، كل سنة.
المقارنة على طاولة القرار
| تبنيه بنفسك | ksa_compliance ذاتي | واجهة الشركاء | |
|---|---|---|---|
| زمن أول عميل | أسابيع هندسة | أيام تهيئة | دقائق: تاجر + Onboarding Link |
| كل عميل جديد | إعداد شهادات كامل | إعداد شهادات كامل | نداء إنشاء تاجر |
| تجديد الشهادات ومواكبة الهيئة | عليك | عليك | علينا |
| تشخيص الرفض | عليك | عليك | الكود بشرحه العربي في الرد |
| ملكية المكوّنات كاملة | لك | لك | الطبقة طرف ثالث |
الصف الأخير هو تنازلنا الصريح — وهو ثمن كل طبقة وسيطة. ما نقدمه مقابله مكتوب في الصفوف الأربعة فوقه.
الخطوة العملية: اقرأ دليل الشركاء — عشر دقائق تكفي مهندسك ليعرف إن كان هذا يناسبكم — ثم راسلنا باسم شركتك وعدد عملائك المتوقع لترتيب الاتفاق واستلام مفتاحك.
المرجع الرسمي
متطلبات الفوترة الإلكترونية ومواعيد الإلزام تصدر عن هيئة الزكاة والضريبة والجمارك وتُحدَّث — المرجع النافذ دائمًا zatca.gov.sa. وأما التزاماتنا في واجهة الشركاء فمرجعها الدليل والاتفاق الموقَّع، لا هذا المقال.