خطأ ميتا 131047، بعنوان Re-engagement message، يعني أن النظام حاول إرسال رسالة حرة بعد مرور أكثر من 24 ساعة على آخر رسالة مستخدم. إعادة المحاولة الحرة لا تحل السبب. أرسل قالبًا معتمدًا إلى مستلم لديه موافقة مناسبة، ثم انتظر رده؛ رد المستخدم وحده يبدأ نافذة جديدة تسمح بالرسائل الحرة.
يورد مرجع أخطاء WhatsApp الرسمي الرمز 131047 لهذه الحالة، بينما تحدد سياسة المراسلة الرسمية قاعدة القالب خارج نافذة الـ24 ساعة. احتفظ بالنص الكامل الذي أعادته ميتا بدل تفسير الرمز من لقطة شاشة مقتطعة.
ما الذي يثبته الخطأ 131047؟
يثبت أن محاولة الإرسال التي قيّمتها ميتا لم تكن قالبًا مؤهلًا خارج النافذة، وأن أكثر من 24 ساعة مضت منذ آخر رد للمستخدم على ذلك الرقم. لا يثبت وحده أن الحساب معلّق، ولا يحدد سبب أي فشل آخر ظهر في وقت مختلف.
رسالة الموظف أو الأتمتة أو القالب السابق لا تصبح مرجعًا جديدًا للنافذة. المرجع يتغير فقط عند وصول رسالة جديدة من المستخدم.
ما مسار التشخيص الأسرع للرمز 131047؟
الفحص | ما تبحث عنه | القرار |
|---|---|---|
حمولة الخطأ | code=131047 وعنوان Re-engagement message | تابع تشخيص النافذة |
آخر رسالة مستخدم | طابعها الزمني على القناة والرقم الصحيحين | احسب الفرق حتى محاولة الإرسال |
نوع الرسالة الفاشلة | نص أو وسائط أو تفاعل أو رد آلي غير قالب | تعامل معها كرسالة حرة |
آخر قالب صادر | هل أرسل من دون رد مستخدم بعده؟ | لا تعتبره إعادة فتح |
الموافقة والقالب | موافقة تغطي الغرض وقالب approved | استخدمهما لمسار الاستعادة |
رسالة المستخدم اللاحقة | هل وصلت بعد القالب؟ | من وقتها تبدأ 24 ساعة جديدة |
ابدأ من البيانات، لا من الافتراض: رقم القناة، رقم المستلم، وقت آخر رسالة واردة، وقت المحاولة، نوع الحمولة، ورمز الخطأ. إذا لم تتطابق هذه العناصر، لا تنسب الفشل إلى 131047 قبل مراجعة السجل الكامل.
لماذا لا تنفع إعادة إرسال الرسالة الحرة؟
إعادة المحاولة تغيّر وقت الطلب فقط؛ لا تنشئ رسالة مستخدم ولا تعيد فتح النافذة. لذلك يظل شرط الأهلية كما هو، وقد تعيد ميتا الرفض نفسه. تحديث الصفحة، إعادة تشغيل التكامل، تبديل الموظف، أو تحويل النص إلى صورة لا يغير القاعدة أيضًا.
لا تستخدم سياسة إعادة المحاولة الآلية المعتادة مع هذا الرمز. التكرار مناسب لعطل مؤقت بعد انتظار مضبوط، أما 131047 فيحتاج تغيير نوع الرسالة أو وصول حدث جديد من المستخدم.
ما الحل الصحيح بعد تأكيد السبب؟
تحقق أن الشخص وافق مسبقًا على نوع المتابعة المقصود ولم يطلب إيقافها.
اختر قالبًا اعتمدته ميتا للغرض واللغة الصحيحين.
أرسل القالب بدل الرسالة الحرة، وراقب حالة تسليمه منفصلة عن حالة النافذة.
انتظر رسالة المستخدم؛ لا ترسل متابعة حرة مباشرة بعد القالب.
عند وصول الرد، حدّث وقت آخر رسالة واردة وابدأ 24 ساعة جديدة.
إذا احتجت ضبط القالب والجمهور والموافقة قبل الإرسال، استخدم دليل حملات واتساب وقوالب ميتا. القالب حل تقني للأهلية، لكنه لا يعوض غياب الموافقة.
ماذا تفعل إذا فشل القالب أيضًا؟
لا تفترض أن 131047 يشرح فشلًا جديدًا مختلفًا. افحص رمز وعنوان وتفاصيل محاولة القالب نفسها، وحالته ولغته ومعاملاته والمستلم والقناة. قد يكون للقالب سبب مستقل يحتاج علاجه وفق رسالة ميتا الرسمية، لذلك لا تستبدل التشخيص بقائمة رموز غير موثقة.
عند إعداد القناة لأول مرة، يساعد دليل ربط واتساب للأعمال مع ميتا على فصل مشكلة الاتصال والأصول عن قاعدة نافذة الخدمة.
كيف يمنع Wats الإرسال المرفوض مسبقًا؟
يطبق Wats الحماية في طبقتين مستقلتين للمحادثات المسجلة. في الواجهة يحسب حالة النافذة من آخر رسالة مستخدم، ويعطّل محرر النص والوسائط والردود الحرة عند الإغلاق، ثم يعرض مسار اختيار القالب. هذا يمنع الموظف من قضاء وقت في كتابة رسالة يعرف النظام أنها غير مؤهلة.
وعلى الخادم يعيد مسار الإرسال الحر فحص LastInboundMessageAt قبل استدعاء ميتا. يمر هذا الفحص عبر مرسل مشترك لمسارات صندوق الوارد والأتمتة والواجهة البرمجية العامة وn8n؛ فإذا كانت المحادثة المعروفة مغلقة يرفض الطلب قبل المزود. وجود الفحص الخادمي مهم لأن تعطيل المتصفح وحده لا يمنع عميل API أو مهمة آلية.
الطبقة | الفحص | النتيجة عند الإغلاق |
|---|---|---|
واجهة Wats | حالة النافذة من آخر رسالة واردة | تعطيل الإرسال الحر وإظهار اختيار القالب |
خادم Wats | آخر رسالة واردة للمحادثة والقناة المسجلتين | رفض الرسالة الحرة قبل استدعاء ميتا |
مسار القالب | approved وIsAvailableInChat وعدم وجود متغيرات حاليًا | إرسال القالب المؤهل أو شرح سبب رفضه |
يمكن للفريق متابعة الملكية والرد بعد الاستعادة داخل صندوق وارد واتساب المشترك، من دون الخلط بين حالة الإسناد وحالة نافذة ميتا.
ما مثال الاستعادة من الخطأ 131047؟
مثال تشغيلي مفترض: أرسل المستخدم آخر رسالة الاثنين 10:00. حاول موظف الثلاثاء 10:03 إرسال نص حر، فأصبح مؤهلًا للرفض 131047؛ وفي محادثة Wats مسجلة تمنعه الواجهة والخادم قبل ميتا. يتحقق الموظف من موافقة تذكير الموعد، ويرسل قالبًا approved متاحًا في المحادثة. تظل النافذة مغلقة حتى يرد المستخدم 10:08، ثم تستمر النافذة الجديدة حتى الأربعاء 10:08.
كيف تعالج 131047 في الأتمتة؟
ضع فحص النافذة قبل عقدة الإرسال، لا بعد الفشل. إذا كانت مفتوحة، استخدم الرسالة الحرة المناسبة. إذا كانت مغلقة، تحقق من الموافقة والقالب المؤهل أو أوقف المسار للتدخل البشري. ولا تبنِ مهمة مجدولة بعد يومين على رسالة حرة لأن موعدها يجعلها غير مؤهلة بطبيعته.
سجّل قرار الفرع مع وقت آخر رسالة مستخدم ونوع الرسالة المختار. عند وصول رد جديد، حدّث الحالة من حدث الوارد بدل الاعتماد على وقت القالب الصادر.
متى يحتاج التشخيص إلى تصعيد تقني؟
صعّد الحالة إذا كانت حمولة ميتا تحمل 131047 مع وجود رسالة مستخدم موثقة خلال أقل من 24 ساعة على الرقم والقناة نفسيهما. أرفق معرف الرسالة الفاشلة، وطابع آخر رسالة واردة، ومعرف الرقم، ووقت الخادم والمنطقة الزمنية، ونوع الحمولة. قد يكشف ذلك تأخر مزامنة أو ربط محادثة بالقناة الخطأ، بدل إعادة المحاولة بلا دليل.
كيف تمنع عودة الخطأ إلى مسار العمل؟
اجعل آخر رسالة مستخدم ووقت الإغلاق حقلي بيانات، لا حسابًا ذهنيًا للموظف.
نبّه عند الاقتراب من الإغلاق وحدد مالكًا للحالات التي تحتاج إجراء.
اختبر كل أتمتة بحالة نافذة مفتوحة وأخرى مغلقة وعدم وجود رسالة واردة أصلًا.
لا تعِد محاولة 131047 تلقائيًا كأنه خطأ شبكة.
راجع سجلات الرفض بحسب المسار والقناة والوردية لتعرف أين يفشل فحص الأهلية.
ما الخلاصة التشخيصية؟
عند ظهور 131047، توقف عن إعادة الرسالة الحرة. أثبت وقت آخر رسالة مستخدم ونوع الإرسال والقناة، ثم انتقل إلى قالب معتمد لمستلم موافق وانتظر رده. إذا كان Wats يملك المحادثة والقناة المسجلتين، يفترض أن تمنع الواجهة والخادم المحاولة قبل ميتا؛ ظهورها رغم ذلك يستحق مراجعة سجل المسار لا تخمين رمز آخر.
