أخطاء الإبلاغ (Reporting Errors)

«أخطاء الإبلاغ (Reporting Errors)» هي المشكلات التي تظهر على مسار الفاتورة الضريبية المبسّطة (B2C) بعد إصدارها، حين يرسل نظامك نسختها إلى منصة فاتورة خلال نافذة 24 ساعة الملزمة. هذا الدليل العملي يفكّك كل خطأ شائع على هذا المسار: العَرَض الذي تراه، وسببه الجذري، والحل خطوة بخطوة. يقع هذا الدليل ضمن مركز أخطاء الفوترة الإلكترونية، وهو الدليل الأخ لدليل أخطاء المقاصة (Clearance) الخاص بفواتير المنشآت (B2B) ضمن مركز الأخطاء نفسه.

إن كنت تحتاج أولًا فهم آلية الإبلاغ نفسها قبل الغوص في أخطائها، فابدأ بـدليل الإبلاغ (Reporting) الذي يشرح التدفق من جذوره، أو راجع واجهة الإبلاغ Reporting API إن كنت تبحث في الجانب التقني للتكامل المباشر مع منصة فاتورة.

لماذا تختلف أخطاء الإبلاغ عن أخطاء المقاصة؟

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

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

الجدول التالي يضع المسارين جنبًا إلى جنب حتى تتأكد أنك تقرأ الدليل الصحيح:

كيف يعمل الإبلاغ تقنيًا حتى تفهم أين يكسر؟

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

1. تصدر الفاتورة من نظامك وتسلّمها للعميل في لحظة البيع.
2. يولّد النظام العناصر التقنية: الختم التشفيري، والمعرّف الفريد (UUID)، وقيمة التجزئة (hash) المرتبطة بالفاتورة السابقة، ورمز الاستجابة السريعة (QR).
3. يبني النظام ملف XML وفق مواصفة UBL 2.1، ويضبط حقل Clearance Status على القيمة 0 لأنها فاتورة مبلَّغ عنها لا مُقاصّة.
4. يرسل النظام الفاتورة إلى منصة فاتورة عبر واجهة الإبلاغ خلال نافذة 24 ساعة.
5. تردّ الهيئة بإحدى ثلاث حالات: قبول (Accepted)، أو قبول مع ملاحظات (Warning)، أو رفض (Error).

أي خطأ تراه يقع في الخطوة الثانية أو الثالثة أو الرابعة أو الخامسة. الأقسام التالية تعالج كل عَرَض على حدة، بترتيب شيوعه في الواقع.

جدول الأعراض: من العَرَض إلى القسم المناسب

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

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

الخطأ الأول: الإبلاغ بعد نافذة 24 ساعة (إبلاغ متأخر)

هذا أكثر أخطاء الإبلاغ شيوعًا وأقلّها وضوحًا، لأنه لا يمنع البيع لحظة حدوثه.

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

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

الحل:

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

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

الخطأ الثاني: رفض الإبلاغ (حالة ERROR)

هنا تردّ الهيئة برفض صريح، فتبقى الفاتورة غير مبلَّغ عنها رغم أنها سُلّمت للعميل.

العَرَض: يرسل النظام الفاتورة فتعود برمز الحالة ERROR مصحوبًا برسالة تشرح سبب الرفض. الفاتورة في هذه الحالة ليست في دفاتر الهيئة، وتحتاج تصحيحًا وإعادة إرسال. الرفض يختلف عن «القبول مع ملاحظات» (Warning) الذي تقبل فيه الهيئة الفاتورة لكنها تنبّهك إلى نقص ثانوي.

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

الحل:

1. اقرأ رسالة الخطأ الواردة من الهيئة بدقة. هي تحدّد الحقل أو القاعدة التي كُسرت، وهي نقطة البداية الصحيحة دائمًا.
2. تحقق من الحقول الإلزامية: رقم التسجيل الضريبي، اسم البائع، التاريخ والوقت، بنود الفاتورة، مبلغ الضريبة، والإجمالي.
3. راجع اتساق احتساب الضريبة. تأكد أن مجموع ضريبة البنود يساوي مبلغ الضريبة في الإجمالي تمامًا.
4. تأكد أن الختم التشفيري ساري المفعول، وأن معرّف الختم التشفيري (CSID) مسجّل وغير منتهٍ.
5. صحّح السبب ثم أعد الإرسال. لا تصدر فاتورة جديدة بديلة إلا إذا تطلّب الأمر إشعارًا دائنًا لإلغاء الأصلية.

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

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

الفرق بين قيمة الحالة في ردّ الهيئة يحسم نوع تدخّلك. الجدول يوضح الحالات الثلاث:

الخطأ الثالث: الإبلاغ المكرّر عن الفاتورة نفسها

قد تظهر الفاتورة الواحدة مرتين في سجلّ الإبلاغ، وهو خطأ يربك التسوية لاحقًا.

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

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

الحل:

1. لا تعيد الإرسال يدويًا قبل التأكد من حالة الإرسال الأول. ابحث عن المعرّف الفريد (UUID) في سجلّ الإبلاغ أولًا.
2. اعتمد على المعرّف الفريد لكل فاتورة كمفتاح وحيد يمنع التكرار. الفاتورة الواحدة تحمل UUID واحدًا لا يتغيّر مهما أعدت المحاولة.
3. راجع تكامل الاستيراد من نقطة البيع حتى لا يُحمَّل ملف الفواتير مرتين.
4. اضبط سياسة إعادة المحاولة الآلية بحيث تتحقق من نجاح الإرسال السابق قبل إطلاق محاولة جديدة.

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

الخطأ الرابع: قيمة Clearance Status خاطئة (1 بدل 0)

هذا خطأ تصنيف يضع الفاتورة في المسار الخاطئ من أساسه.

العَرَض: يرفض الإرسال أو يعود برسالة عدم اتساق، لأن الفاتورة المبسّطة (B2C) حُدِّد حقل Clearance Status فيها على القيمة 1 (مُقاصّة) بدل القيمة الصحيحة 0 (مبلَّغ عنها). الفاتورة المبسّطة لا تمرّ بالمقاصة، فلا يصحّ وسمها بأنها مُقاصّة.

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

الحل:

1. تأكد أن نوع الفاتورة في النظام مضبوط على «فاتورة ضريبية مبسّطة» للمعاملات الموجّهة للمستهلك النهائي.
2. تحقق أن حقل Clearance Status يحمل القيمة 0 لكل فاتورة مبسّطة، والقيمة 1 للفواتير الكاملة فقط.
3. راجع قوالب الفواتير المنسوخة بين الفروع، وتأكد أن كل قالب يحمل نوع الفاتورة الصحيح لنشاط الفرع.
4. بعد التصحيح، أعد إصدار الفاتورة بالنوع الصحيح إن لزم، ثم أبلغ عنها على مسار الإبلاغ.

الخطأ الخامس: الإبلاغ عن فاتورة B2B بالخطأ

هذا انعكاس للخطأ السابق: فاتورة كاملة سلكت مسار الإبلاغ بدل المقاصة.

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

السبب الجذري: تصنيف خاطئ للعميل في النظام، فعومل العميل المنشأة كأنه مستهلك فرد. سبب آخر هو غياب رقم التسجيل الضريبي للمشتري في بيانات الفاتورة، فلم يتعرّف النظام عليها كفاتورة B2B تستوجب المقاصة.

الحل:

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

كيف تُحسب نافذة الـ24 ساعة بدقة؟

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

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

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

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

تصحيح فاتورة مبسّطة بعد الإبلاغ: الإشعار الدائن

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

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

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

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

أفضل الممارسات لمنع أخطاء الإبلاغ من جذورها

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

1. اعتمد الإرسال الآلي الفوري. كل فاتورة تغادر فور إصدارها، فلا تتراكم ولا تقترب من حدّ النافذة.
2. راقب طابور الإرسال يوميًا. لوحة تعرض الفواتير المعلّقة تكشف أي انقطاع قبل أن يتحوّل إلى تأخر جماعي.
3. اضبط نوع كل فاتورة عند الإصدار. مبسّطة للأفراد بقيمة Clearance Status صفر، كاملة للمنشآت على مسار المقاصة.
4. اربط تصنيف العميل برقم تسجيله الضريبي. وجوده يوجّه الفاتورة للمقاصة، وغيابه يوجّهها للإبلاغ، فلا يختلط المساران.
5. جدّد معرّف الختم التشفيري (CSID) قبل انتهائه. الختم المنتهي يوقف الإبلاغ كله، لا فاتورة واحدة.
6. راجع اتساق الضريبة آليًا. النظام الذي يطابق مجموع ضريبة البنود مع الإجمالي قبل الإرسال يمنع أكثر أسباب الرفض شيوعًا.

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

كيف تبدو رسالة خطأ إبلاغ فعلية؟

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

{
  "validationResults": {
    "status": "ERROR",
    "reportingStatus": "NOT_REPORTED",
    "clearanceStatus": 0,
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "BR-KSA-EN16931-08",
        "category": "EN_16931",
        "message": "Invoice total VAT amount does not equal the sum of line VAT amounts"
      }
    ],
    "warningMessages": []
  },
  "invoiceHash": "NWZlY2ViNjZmZmM4NmYz...",
  "uuid": "3cf5ee18-ee25-44ea-a444-2c37ba7f28be"
}

اقرأ هذا الرد من ثلاث زوايا. أولًا حقل status وقيمته ERROR تؤكد أن الفاتورة رُفضت ولم تُبلَّغ (reportingStatus: NOT_REPORTED). ثانيًا حقل clearanceStatus وقيمته 0 يؤكد أنها فاتورة مبسّطة على مسار الإبلاغ الصحيح، فالمشكلة ليست في التصنيف. ثالثًا كتلة errorMessages تحدّد السبب بدقة: مجموع ضريبة البنود لا يساوي مبلغ الضريبة في الإجمالي. هذا يوجّهك مباشرة إلى مراجعة احتساب الضريبة قبل إعادة الإرسال.

لاحظ وجود uuid وinvoiceHash في الرد. هذان العنصران يربطان الفاتورة بسلسلتها، ويثبتان أن المعرّف الفريد صحيح، فالخطأ محصور في احتساب الضريبة لا في بنية السلسلة.

قائمة تحقّق سريعة قبل كل إبلاغ

معظم أخطاء الإبلاغ تُمنع بمراجعة دقيقة قبل الإرسال. راجع النقاط التالية على كل فاتورة مبسّطة:

• نوع الفاتورة مضبوط على «ضريبية مبسّطة» وحقل Clearance Status يحمل القيمة 0.
• رقم التسجيل الضريبي للبائع صحيح ومكتمل.
• مجموع ضريبة البنود يساوي مبلغ الضريبة في الإجمالي تمامًا.
• الختم التشفيري ساري المفعول ومعرّف الختم التشفيري (CSID) غير منتهٍ.
• قيمة التجزئة (hash) تطابق الفاتورة السابقة في السلسلة.
• الإرسال يتم خلال نافذة 24 ساعة من لحظة الإصدار، آليًا لا يدويًا.

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

أسئلة متكررة حول أخطاء الإبلاغ

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

ماذا لو قبلت الهيئة الفاتورة بحالة Warning؟ الفاتورة بُلّغ عنها ودخلت سجل الهيئة. الملاحظة تنبيه إلى نقص ثانوي لا يمنع القبول. عالج سبب الملاحظة في الفواتير القادمة حتى لا يتحول إلى رفض لاحقًا.

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

كيف أفرّق بسرعة بين فاتورة إبلاغ وفاتورة مقاصة؟ انظر إلى حقل Clearance Status. القيمة 0 تعني فاتورة مبسّطة على مسار الإبلاغ، والقيمة 1 تعني فاتورة كاملة على مسار المقاصة. وجود رقم تسجيل ضريبي للمشتري مؤشر آخر على أنها معاملة B2B.

متى تلجأ للدعم؟

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

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