المرحلة الثانية للفوترة الإلكترونية (زاتكا): ما الذي يتطلبه الربط فعلياً

المرحلة الأولى من الفوترة الإلكترونية في السعودية كانت تغييراً في الصيغة. توقفت عن كتابة الفواتير يدوياً أو في معالج نصوص، وبدأت بإصدارها من نظام. مؤلم للبعض، لكنه بسيط من حيث المفهوم.

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

الفارق الذي يحدد بنيتك التقنية

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

الفواتير الضريبية — عادةً بين المنشآت وبين المنشآت والجهات الحكومية — تمر عبر الإقرار (Clearance). ترفع الفاتورة إلى زاتكا، فتتحقق منها وتضع ختمها، ولا تكون الفاتورة صالحة نظاماً لإصدارها للمشتري إلا بعد إقرارها. هذه عملية متزامنة وحاجبة. إذا فشل نداء الإقرار فأنت لا تملك فاتورة.

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

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

ما الذي يجب أن تحمله الفاتورة

الفاتورة المتوافقة في المرحلة الثانية مستند XML مهيكل — مبني على معيار UBL — يحمل عناصر لا يستطيع ملف PDF التعبير عنها إطلاقاً:

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

البند الأخير هو القاتل الصامت. زاتكا تتحقق من الحساب. أسلوب تقريب ظل يعمل في نظام ERP لديك عشر سنوات — التقريب على مستوى البند مقابل المجموع، أو معالجة فاتورة متعددة النسب بطريقة غير متسقة — سينتج رفضاً على نطاق واسع حين يصير كل مستند مفحوصاً آلياً. ومطابقة منطق التقريب لديك مع المواصفة هي غالباً أكبر تغيير برمجي في المشروع.

تسجيل حل الفوترة

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

ثلاثة أمور خطّط لها وهي غير واضحة من الوثائق:

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

أين تضع طبقة الربط

أمامك ثلاثة خيارات واقعية، والصحيح منها يعتمد على عدد الأنظمة في منشأتك القادرة على إنشاء فاتورة.

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

طبقة وسيطة. خدمة مخصصة تناديها كل أنظمة الفوترة، وتتولى بيانات الاعتماد والتنسيق والإرسال وإعادة المحاولة والأرشفة. بناؤها أكثر عملاً، لكنها الإجابة الصحيحة لأغلب المنشآت من أي حجم — لأن عدد الأنظمة القادرة على إصدار فاتورة يزداد دائماً، ولأنها تمنحك مكاناً واحداً لمعالجة أي تغيير في المواصفة.

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

أنماط الفشل التي تسبب ضرراً حقيقياً

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

تجاهل تراكم التقارير. الفواتير المبسطة تُبلَّغ لاحقاً، ما يعني أن الإخفاقات غير مرئية إلا إذا نظرت. وبدون لوحة تعرض الفواتير غير المبلَّغة حسب عمرها، ستعرف عند التدقيق. ابنِ المراقبة من اليوم الأول؛ تكلف يوماً وتوفر ربع سنة.

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

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

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

كيف ترتّب العمل

1. تأكد من التزاماتك وتوقيتها. تُطبَّق المرحلة الثانية على مجموعات تُحدَّد بحسب الإيرادات، ويُبلَّغ المكلفون مسبقاً بمجموعتهم. حدّد موقعك من إشعار زاتكا لا مما أخبرك به نظير في السوق.
2. اجرد كل نظام يستطيع إنشاء فاتورة. شاملاً ذاك الذي بنته المالية في جدول بيانات، والنظام المستقل في الفرع، والذي يستخدمه فريق المبيعات للعرابين. كل واحد منها داخل النطاق.
3. أصلح بياناتك قبل أن تصلح ربطك. أرقام التسجيل الضريبي الناقصة، والعناوين المشوّهة، ورموز الضريبة غير المتسقة ستفشل في التحقق مهما كان ربطك ممتازاً. هذه عادةً أطول مهمة، ويمكن أن تبدأ فوراً.
4. ابنِ على البيئة التجريبية. توفّر زاتكا بيئة للمطورين. استخدمها بقوة، وللحالات الفاشلة أيضاً.
5. شغّل بالتوازي قبل التحوّل. أصدر عبر المسارين وطابق بينهما، لمدة تكفي لتشمل إقفال نهاية شهر.
6. قِس كل شيء. نسبة نجاح الإرسال، وزمن استجابة الإقرار، وعمر تراكم التقارير، والعد التنازلي لانتهاء الشهادات. هذه مؤشرات تشغيلية دائمة لا مؤشرات مشروع.

الطريقة الصحيحة للتفكير فيه

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