متطلبات المرحلة الثانية زاتكا للشركات السعودية

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

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

ما الذي تغيّره المرحلة الثانية عمليًا؟

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

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

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

متطلبات المرحلة الثانية زاتكا الأساسية

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

تهيئة وحدة الحل والشهادات

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

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

بنية الفاتورة وصحة البيانات

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

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

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

رمز الاستجابة السريعة والتمثيل المرئي

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

التخليص والإبلاغ وإدارة الاستجابة

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

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

التحقق قبل الإرسال يقلل الرفض المكلف

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

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

أين تتعثر المؤسسات الكبيرة؟

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

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

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

خطة تنفيذ تقلل المخاطر

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

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

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

ما الذي يجب أن يظهر في سجل التدقيق؟

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

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

كيف يبدو هذا في alFatora - الفاتورة

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

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

والاستعداد الحقيقي للمرحلة الثانية يظهر عندما تستطيع المؤسسة الإجابة فورًا عن ثلاثة أسئلة: أين كل فاتورة الآن؟ ولماذا رُفضت إن رُفضت؟ ومن يملك الإجراء التالي؟ وعندما تكون الإجابات موثقة وقابلة للتنفيذ، تتحول متطلبات زاتكا من مشروع امتثال مرهق إلى عملية تشغيل يمكن الوثوق بها.