الربط مع زاتكا (المرحلة الثانية - فاتورة)
مرحلة الربط في برنامج فاتورة — توصيل أنظمتك الحقيقية بزاتكا للإجازة والإبلاغ، وإعادة الختم التشفيري والمعرّف الفريد على كلِّ فاتورة، مبنيٌّ وتمتلكه أنت.
ما الذي تتطلّبه مرحلة الربط فعلاً
لم تطلب المرحلة الأولى من فاتورة (مرحلة التوليد) سوى فواتير إلكترونية منظَّمة مع رمز QR، تُولَّد وتُخزَّن محلياً. أمّا المرحلة الثانية — مرحلة الربط، التي تُطرح على المكلَّفين بموجاتٍ بحسب الإيراد — فتُغيِّر النموذج كلِّياً. يجب على نظام الفوترة لديك، وهو وحدة EGS بمصطلح زاتكا، أن يُسجَّل (Onboarding) في المنصّة، ويحصل على معرّف الختم التشفيري (CSID)، ثم يُنادي زاتكا على كلِّ فاتورة.
بالنسبة لفواتير الشركات القياسية يعني هذا الإجازة الفورية: تتحقّق زاتكا من صيغة UBL 2.1، وتُطبّق ختمها التشفيري، وتُعيد معرّفاً فريداً وحالة «مُجازة»، وعندها فقط تُصبح الفاتورة صالحةً نظاماً. أمّا الفواتير المبسَّطة للأفراد فتعني الإبلاغ خلال أربعٍ وعشرين ساعة، مع توليد الختم محلياً وإرسال المستند بعدها. كما تحمل كلُّ فاتورةٍ عدّاداً متزايداً (ICV) وبصمة الفاتورة السابقة (PIH)، مكوِّنةً سلسلةً تكشف أيَّ عبث.
- التسجيل — توليد طلب توقيع شهادة (CSR)، ومبادلته بشهادة امتثال (CSID)، واجتياز فحوص زاتكا، ثم الترقية إلى شهادة إنتاج.
- الإجازة (بين الشركات) — إرسال كلِّ فاتورةٍ ضريبية قياسية بصورةٍ متزامنة؛ ولا تصحُّ الفاتورة حتى تُعيدها زاتكا مُجازة.
- الإبلاغ (للأفراد) — ختم الفواتير المبسَّطة محلياً وإبلاغها لزاتكا ضمن المهلة المطلوبة.
- السلسلة التشفيرية — عدّاد ICV وبصمة الفاتورة السابقة على كلِّ مستند، إضافةً إلى رمز QR الحامل لختم زاتكا.
ربطٌ موصَّلٌ بالنظام الذي تُصدر منه فواتيرك
لا نسلّمك بوّابةً أخرى تُعيد الإدخال إليها. نبني مصافحة المرحلة الثانية داخل النظام الذي يُنتج فواتيرك أصلاً — ERP، أو متجرك، أو نظامك المحاسبي، أو مُشغِّل AIMOCS — فتجري الإجازة ضمن المسار تلقائياً من بياناتٍ حقيقية.
- تسجيل EGS ودورة حياة CSID — التسجيل الأولي إضافةً إلى التجديد الآلي قبل انتهاء الشهادة، كي لا تتوقّف الإجازة بصمت.
- تدفّقات الإجازة والإبلاغ — المسار الصحيح لكلِّ نوع فاتورة، مع كتابة الختم والمعرّف الفريد والحالة المُعادَة عكسياً إلى سجلّاتك.
- طابور صامد — إعادات المحاولة، ومعالجة الرسائل الميتة، وإظهار الرفض بوضوح كي تكون الفاتورة الفاشلة ظاهرةً لا ضائعة.
- استضافة داخل المنطقة — المستندات والمفاتيح وسجلّات التدقيق في الرياض أو جدة، متوافقةً مع توقّعات إقامة البيانات.
- أثر تدقيق — كلُّ إرسالٍ وإجازةٍ ورفضٍ وتجديدٍ مُسجَّلٌ بثبات لمراجعةٍ ضريبية مستقبلية.
لماذا التكامل بدل شراء وسيطٍ للإجازة
سيقبل سوقٌ من الوسطاء بسرورٍ أن يجلس بينك وبين زاتكا، يأخذ فاتورتك ويُجيزها ويتقاضى عن كلِّ مستندٍ إلى الأبد. ينجح ذلك حتى تحتاج تسوية رفضٍ، أو إثبات رقمٍ في تدقيق، أو تغيير طريقة فوترتك — وعندها يكون الوسيط صندوقاً أسود لا تستطيع فحصه. بناء الربط داخل منظومتك يُبقي السلسلة التشفيرية وأثر التدقيق ومنطق الـ API تحت سيطرتك.
ويهمُّ ذلك أيضاً لأنَّ مواصفة زاتكا تتطوّر — قواعد تحقّقٍ جديدة، حقولٌ جديدة، موجاتٌ جديدة. نُبقي منطق الإجازة والتسجيل في أداةٍ مُختبَرةٍ مُؤرَّخة تُراجَع مقابل بيئة زاتكا التجريبية (Sandbox) عند كلِّ تغيير مواصفة، فيكون التحديث إصداراً مضبوطاً لا إنذار حريقٍ في الإنتاج.
ما الفرق بين الإجازة والإبلاغ؟
تنطبق الإجازة على الفواتير الضريبية القياسية بين الشركات: تتحقّق زاتكا وتختم الفاتورة فورياً ولا تصحُّ حتى تُعاد مُجازة. أمّا الإبلاغ فينطبق على الفواتير المبسَّطة للأفراد: تُختم الفاتورة محلياً وتُرسل لزاتكا ضمن المهلة المطلوبة. ونحن نبني المسار الصحيح لكلِّ نوع.
هل تتولّون تسجيل CSID وتجديدها؟
نعم. نُدير الدورة الكاملة — توليد الـ CSR، والحصول على شهادة الامتثال، واجتياز فحوص زاتكا، والترقية إلى شهادة إنتاج، وأتمتة التجديد قبل الانتهاء كي لا تتوقّف الإجازة بصمت.
هل يتّصل هذا بـ ERP أو متجرنا الحالي؟
نعم — هذا هو الهدف. تُبنى مصافحة المرحلة الثانية داخل النظام الذي يُنتج فواتيرك أصلاً، فتجري الإجازة ضمن المسار من بياناتٍ حقيقية دون بوّابةٍ منفصلةٍ تُعيد الإدخال إليها.
ماذا يحدث حين ترفض زاتكا فاتورة؟
يُظهَر الرفض بوضوحٍ ولا يُبتلَع. طابورٌ صامدٌ بإعادات المحاولة ومعالجة الرسائل الميتة يعني أنَّ الفاتورة الفاشلة ظاهرةٌ وقابلةٌ للمعالجة، مع تسجيل السبب في أثر التدقيق.
هل نمتلك الربط؟
نعم — تستلم الشيفرة والمفاتيح والمخطّط وخطّ النشر. لا رسم إجازةٍ لكلِّ مستند، ولا صندوق وسيطٍ أسود.
لا نقدّم استشارات في الذكاء الاصطناعي. نحن نُديره نيابةً عنك.
مُثبَت على بياناتك قبل أن تلتزم.