الربط مع فاتورة في المرحلة الثانية ليس رفع PDF. على المطوّر توليد XML وفق مواصفات الهيئة، وتهيئة كل وحدة إصدار، وإدارة المعرفات وسلسلة الفواتير والأختام، والاتصال بواجهات منصة فاتورة، ومعالجة الاعتماد أو الإبلاغ، وحفظ الأدلة. التطبيق تدريجي بموجات؛ تحقق من إشعار منشأتك وآخر تعليمات هيئة الزكاة والضريبة والجمارك.
الامتثال مسؤولية المكلف، حتى عند شراء حل أو توظيف مطور. لذلك يجب أن يستطيع فريق المالية شرح نوع كل فاتورة، وأن يستطيع المطور إثبات مسارها من الطلب إلى XML ثم إلى استجابة الهيئة والأرشيف. عبارة «ندعم ZATCA» بلا تقرير اختبار ولا عينة XML ولا سجل استجابة ليست معيار قبول.
هذا شرح تقني عام. حدود الموجات والمواعيد والحقول والسياسات قابلة للتحديث؛ اعتمد الإشعار الرسمي والمواصفات المنشورة واستشارة ضريبية مناسبة لنشاطك.
المرحلة الأولى والثانية جنباً إلى جنب
بدأت الفوترة الإلكترونية بمرحلة الإصدار والحفظ، ثم أضافت مرحلة الربط والتكامل متطلبات تقنية واتصالاً بمنصة فاتورة للفئات التي تبلغها الهيئة ضمن الموجات. لا تلغي المرحلة الثانية الأولى؛ بل تبني فوقها وتفرض صيغة وحقولاً وخصائص أمنية ومسارات مشاركة محددة.
المتطلب | المرحلة الأولى: الإصدار والحفظ | المرحلة الثانية: الربط والتكامل |
نظام إلكتروني | إصدار وحفظ الفواتير بنظام متوافق | استمرار الإصدار مع تهيئة وربط الحل |
الصيغة | متطلبات وحقول المرحلة الأولى | XML منظم، ويمكن PDF/A-3 متضمناً XML للمشاركة البشرية |
الاتصال بالهيئة | لا يوجد ربط API لكل فاتورة | اتصال بمنصة فاتورة وفق المسار المحدد |
خصائص الأمان | ضوابط منع العبث الأساسية | معرفات وعداد وربط تسلسلي وأختام وفق المواصفات |
الفاتورة الضريبية | تُصدر وتحفظ | تُرسل للاعتماد قبل مشاركتها وفق المسار النظامي |
الفاتورة المبسطة | تُصدر مع QR وتحفظ | تُختم وتُبلغ ضمن المدة المحددة رسمياً |
الاختبار | اختبار بيانات وطباعة | محاكاة وامتثال وتهيئة إنتاج ومراقبة استجابات |
الأرشفة | حفظ إلكتروني منظم | حفظ XML والاستجابات والسجلات مع إمكانية الاسترجاع |
يوضح دليل الهيئة التفصيلي أن الربط يتم عبر API، وأن الصيغة المطلوبة هي XML أو PDF/A-3 يتضمن XML، مع اختلاف الاعتماد والإبلاغ حسب نوع الفاتورة.
ابدأ بتصنيف العملية لا بكتابة API
يحتاج المطور إلى خريطة معاملات معتمدة من المالية أو المستشار الضريبي. هل العملية بين منشأتين أم مع مستهلك؟ هل المشتري مسجل؟ هل توجد دفعة مقدمة أو إلغاء أو استرداد؟ هل المنصة بائع أم وسيط؟ الإجابات تحدد نوع الوثيقة وحقولها ومسارها.
اربط كل حدث تجاري بوثيقة صحيحة. إنشاء الطلب ليس دائماً لحظة إصدار الفاتورة. نجاح تفويض الدفع ليس دائماً تسوية. ولا يجوز معالجة الاسترداد بحذف سجل سابق؛ يحتاج النظام إشعاراً دائناً أو مديناً مرتبطاً وفق الحالة والمواصفة.
ابنِ قاموس بيانات يربط حقول المتجر بعناصر الفاتورة: بيانات البائع والمشتري، والرقم الضريبي، والعملة، والبنود، والخصومات، والضريبة، والإجماليات، ومرجع الطلب. حدد مصدر الحقيقة لكل حقل ومن يملك تصحيحه. إذا سمحت الواجهة بعنوان حر، بينما XML يحتاج بنية أو رمزاً، أصلح نموذج البيانات قبل التكامل.
المهام التقنية التي يجب أن تظهر في النطاق
يجب ألا تُخفى أعمال الربط داخل بند «تطوير Backend». اطلب مخرجات يمكن اختبارها، ومسؤولاً لكل حساب وسر، وبيئة مستقلة للاختبار قبل الإنتاج.
- يصنف المطور أنواع الفواتير والإشعارات ومسار كل معاملة.
- يبني مولّد XML وفق قاموس البيانات ومعيار التنفيذ المنشور.
- يطبق المعرف UUID والعداد والتجزئة والختم وQR حيث يلزم.
- يهيئ وحدات إصدار النظام ويحصل على بيانات الاعتماد عبر المسار الرسمي.
- يربط واجهات الاعتماد والإبلاغ ويتحقق من الاستجابات.
- يعالج المهلة وإعادة المحاولة ومنع التكرار وانقطاع الاتصال.
- يحفظ XML والاستجابة والسجل والمرجع التجاري بطريقة قابلة للتدقيق.
- يختبر الحالات الصحيحة والخاطئة والإشعارات والاسترداد والإلغاء.
توفر الهيئة مواصفات XML وقاموس البيانات وأدوات تمكين واختبار للمطورين. اجتياز أداة محلية خطوة مهمة، لكنه لا يعني وحده أن الفاتورة اعتمدت من الهيئة أو أن التشغيل الكامل صحيح.
تحدث مع فريق CloudTopia على واتساب لمراجعة جاهزية متجرك والحصول على نطاق ربط بالريال يحدد XML والاختبارات والتسليم بوضوح.
التهيئة والشهادات والأسرار
كل جهاز أو وحدة حل تُصدر الفواتير تحتاج تهيئة وفق آلية منصة فاتورة. تشمل العملية عادة إنشاء طلب توقيع شهادة، واستخدام بيانات تهيئة من الحساب الرسمي، واجتياز مسار الامتثال، ثم الحصول على بيانات اعتماد الإنتاج المناسبة. يجب تنفيذ التفاصيل حسب دليل الهيئة الحالي، لا من مقال قديم أو كود من مشروع آخر.
ضع المفاتيح والشهادات في مخزن أسرار، لا في مستودع الكود أو قاعدة بيانات مكشوفة. قيد الوصول، وسجل الاستخدام، وخطط للتجديد أو الاستبدال والإلغاء. افصل الاختبار عن الإنتاج حتى لا يرسل مطور فاتورة تدريبية ببيانات حقيقية أو يستخدم اعتماداً إنتاجياً على جهازه.
اضبط الوقت والتسلسل. التوقيع والتجزئة والعداد وسلسلة الفواتير تتأثر بمحاولات الإعادة وتعدد نقاط البيع والعمل دون اتصال. لا تسمح لفرعين بإصدار الرقم أو حالة السلسلة نفسها بسبب مزامنة ضعيفة. اختبر استعادة النسخة الاحتياطية: هل يستعيد النظام آخر حالة بأمان أم يعيد عداداً قديماً؟
وثق ملكية الاعتمادات. حساب الهيئة والمنصة للمنشأة، والوصول الفني مؤقت ومراقب، ويُسحب عند تغيير المورد.
الاعتماد والإبلاغ ليسا طلباً واحداً
الفواتير الضريبية المعتادة والفواتير الضريبية المبسطة لها مساران مختلفان في المرحلة الثانية. في مسار الاعتماد، يرسل الحل الفاتورة إلى الهيئة قبل مشاركتها مع المشتري ويعتمد النتيجة المعادة. وفي مسار الإبلاغ، يولد الحل الفاتورة المبسطة بخصائصها الأمنية ثم يرسلها ضمن المدة الرسمية.
على المطور التعامل مع القبول والتحذير والرفض والعطل الشبكي. لا يحول كل استجابة غير ناجحة إلى «أعد المحاولة»؛ قد يكون الخطأ في قيمة ضريبية أو بنية XML ويحتاج تصحيحاً. وفي المقابل، يجب ألا ينشئ الضغط المتكرر فاتورتين لنفس الطلب.
استخدم مفتاحاً داخلياً ثابتاً للمعاملة، وحالة واضحة: مسودة، جاهزة، مرسلة، معتمدة أو مبلغة، مرفوضة، وتحتاج تدخلاً. خزّن رمز الاستجابة ووقت المحاولة من دون تسجيل أسرار أو بيانات أكثر من الحاجة. أنشئ لوحة استثناءات للمالية بدلاً من ترك الأخطاء في سجل تقني لا يراه أحد.
اختبر خطة الانقطاع وفق القواعد الرسمية: ما الذي يمكن إصداره، وما الذي ينتظر، وكيف تُستأنف المشاركة من دون كسر الترتيب أو ازدواج الفواتير؟
ماذا يعني الربط لمتجرك الإلكتروني؟
يجب فصل تجربة الشراء عن محرك الفواتير مع إبقاء الرابط بينهما قوياً. الطلب يحمل المنتجات والشحن والخصومات. الدفع يحمل التفويض والتحصيل والاسترداد. الفاتورة تحمل الأثر الضريبي. قد تتزامن الأحداث في عملية بسيطة، لكنها ليست سجلاً واحداً قابلاً للحذف.
اختبر على الأقل هذه السيناريوهات:
- اختبر طلباً ناجحاً بمنتج وشحن وخصم.
- اختبر فشل الدفع ثم نجاحه من دون فاتورة مزدوجة.
- اختبر استرداداً كلياً وجزئياً وإصدار الإشعار المناسب.
- اختبر تعدد معدلات أو حالات الضريبة المعتمدة في نشاطك.
- اختبر عميل منشأة وعميل مستهلك وحقولهما المختلفة.
- اختبر إلغاء الطلب قبل الإصدار وبعده وفق الإجراء الصحيح.
- اختبر انقطاع منصة خارجية ثم استعادة الاتصال.
- اختبر مطابقة إجمالي الطلب والدفع والفاتورة والتسوية.
يجب أن يعرض حساب العميل نسخة قابلة للقراءة عند الحاجة، بينما يحفظ النظام XML القانوني كما أُرسل أو أُعيد. لا تعِد توليد ملف قديم من بيانات حالية؛ قد تكون الأسعار أو العناوين أو الإعدادات تغيرت.
الجاهزية من أول يوم أو ترقيع لاحق
المتجر الذي يخزن الإجمالي النهائي فقط يصعب تحويله إلى فاتورة صحيحة. تحتاج السطور إلى سعر وكمية وخصم وضريبة وإجماليات محسوبة بقواعد متسقة. كما تحتاج المرتجعات إلى ارتباط بالأصل، والفروع إلى وحدات إصدار واضحة، والحسابات إلى ملكية مؤسسية.
تبني CloudTopia المتاجر على نموذج بيانات جاهز للربط مع فاتورة من اليوم الأول: عربية RTL أصيلة، وكود يملكه العميل بموجب العقد، وفصل بين الطلب والدفع والفاتورة. يمكن اقتراح تدقيق جاهزية محدد من 990 ر.س قبل تقدير التنفيذ، لتحديد فجوات البيانات والتكامل من دون دفع تكلفة بناء كاملة مبكراً. السعر المقترح يُثبت بالنطاق ولا يشمل رسوم الجهات الخارجية.
هذا لا يعني أن كل متجر يصبح مربوطاً آلياً قبل دخول موجته أو دون تهيئة المنشأة. يعني أن قاعدة البيانات والأحداث والحسابات لا تمنع الربط عند وجوبه. احتفظ بإعدادات مرنة للحقول والنسخ، ولا تثبت افتراضاً مؤقتاً داخل عشرات الملفات البرمجية.
أسئلة تطرحها على مطور ZATCA
اطلب إجابات مع أدلة، لا كلمة «نعم». يمكن إرفاق عينة منزوعة البيانات، وتقرير أداة الامتثال، ومخطط حالات، وقائمة اختبارات، وصورة لوحة الاستثناءات.
- اسأل كيف يفرق النظام بين الاعتماد والإبلاغ ونوع كل وثيقة.
- اسأل أي نسخة من مواصفات XML وقاموس البيانات يعتمدها الفريق.
- اسأل كيف يحمي المفاتيح والشهادات ويفصل الاختبار عن الإنتاج.
- اسأل كيف يمنع التكرار ويحافظ على العداد والتجزئة بعد الانقطاع.
- اسأل كيف يعالج الرفض والتحذير ومن يراجع الاستثناءات.
- اسأل كيف يصدر الإشعارات الدائنة والمدينة ويربطها بالأصل.
- اسأل ماذا يحفظ، ومدة الحفظ، وكيف يستخرج ملف تدقيق.
- اسأل من يملك الكود والحسابات والوثائق بعد التسليم.
الأهم أن ترى حالات الاختبار تعمل في النظام، لا أن تكتفي بمخطط أو عرض تقديمي.
العقوبات والمسؤولية وإثبات الامتثال
تنص الأنظمة واللوائح على مخالفات وعقوبات عند عدم الالتزام بمتطلبات الفوترة الإلكترونية أو إصدار وحفظ الفواتير بصورة غير صحيحة أو العبث بها. لا تعتمد مبلغاً من مقال؛ نوع المخالفة والتحديثات والظروف تؤثر في الإجراء. راجع بوابة الهيئة الرسمية وإشعارات منشأتك، وخذ رأي مختص عند الحاجة.
تقنياً، صمم أدلة قابلة للاسترجاع: XML الأصلي، وحالة الإرسال، والاستجابة، والطابع الزمني، ومرجع الطلب، والإشعارات اللاحقة، وسجل التعديل. امنع تعديل وثيقة صادرة كأنها مسودة؛ استخدم المسار النظامي للتصحيح.
راقب يومياً الفواتير المرفوضة أو العالقة، ونبه قبل انتهاء المهل التشغيلية المعتمدة. راجع العينات دورياً بين المتجر والحسابات، واختبر الاستعادة وتغيير الشهادة وإضافة فرع. الامتثال ليس مشروع ربط ينتهي؛ إنه عملية تشغيل تتغير مع المواصفات والنشاط.
تواصل مع فريق CloudTopia عبر واتساب للحصول على فحص منخفض التكلفة وخطة ربط موثقة، ثم تحقق من موعد موجتك ومتطلباتك النهائية لدى الهيئة.
الأسئلة الشائعة
ما هي المرحلة الثانية من فاتورة؟
المرحلة الثانية هي مرحلة ربط وتكامل حلول الفوترة الإلكترونية مع منصة فاتورة التابعة لهيئة الزكاة والضريبة والجمارك. تُطبق تدريجياً على موجات تبلغها الهيئة، وتضيف صيغة XML وحقولاً وخصائص أمنية ومسارات اعتماد أو إبلاغ. راجع موقع الهيئة وإشعار منشأتك للتفاصيل المتغيرة.
هل متجري الإلكتروني ملزم بالربط؟
يعتمد ذلك على خضوع المنشأة للفوترة الإلكترونية ودخولها ضمن موجات المرحلة الثانية وإشعار الهيئة، لا على كون البيع عبر متجر فقط. تحقق من الرقم الضريبي والإيرادات والفترة المعتمدة في الإعلان الرسمي، واطلب رأياً ضريبياً لنموذج السوق أو الوساطة. لا تعتمد تقويماً عاماً وحده.
ماذا يحتاج المبرمج ليربط نظامي مع ZATCA؟
يحتاج خريطة معاملات وبيانات صحيحة، ومولد XML متوافقاً، وتهيئة وحدات الحل، وإدارة شهادات وأختام ومعرفات وتسلسل، وربط واجهات الاعتماد والإبلاغ. كما يحتاج معالجة الرفض والانقطاع والتكرار، وأرشفة XML والاستجابات، واختبارات موثقة بأدوات الهيئة وبيئاتها المعتمدة قبل نقل الربط إلى الإنتاج.
ما عقوبة عدم الربط؟
قد يعرّض عدم الامتثال المنشأة لإجراءات وغرامات وفق نوع المخالفة والأنظمة السارية، وقد تشمل المخالفات عدم إصدار أو حفظ الفواتير كما يجب أو العبث بالحل. لا تنقل رقماً ثابتاً من مصدر ثانوي؛ راجع جدول المخالفات الحالي لدى الهيئة واستشر مختصاً بشأن حالتك.
اقرأ أيضاً
هل تحتاج إلى نظام إدارة علاقات العملاء (CRM) أو نظام تخطيط موارد المؤسسات (ERP) أو لوحة معلومات مخصصة؟
تحول كلاود توبيا جداول البيانات الفوضوية والعمليات اليدوية إلى أنظمة أعمال واضحة يمكن لفريقك استخدامها بالفعل.
شارك هذا المقال
كُتب بواسطة
Mohamad Shahm | محمد شـهم
أسس محمد شهم شركة كلاود توبيا بعد مدة طويلة من بناء منصات الويب، وأنظمة التجارة الإلكترونية، للأفراد والشركات. محمد شهم يكتب أيضًا مقالات عن القرارات الهندسية والتجارية وراء إطلاق برمجيات يستخدمها الناس فعلاً.
