أخطاء Off quotes / Requote في MT5 — الرمز 10021

الحل الشامل لأخطاء Off quotes / Requote في MT5/MQL5

عند تشغيل روبوت تداول آلي (EA)، قد يظهر في سجل الأحداث أو تبويب Expert خطأ off quotes (10021) أو requote (10004)، مما يوحي بأن الوسيط رفض تنفيذ الصفقة، لكن هذين الخطأين في الحقيقة ليسا متعلقين بالرصيد أو حجم اللوت، بل بمشكلة في السعر فقط. السعر الذي أرسلته لا يتطابق مع السعر الذي يحمله الخادم في تلك اللحظة، وهذا كل ما في الأمر. معظم الأسباب تعود إلى واحد من أربعة عوامل: تقلب مفاجئ في السوق، إعداد الانزلاق المسموح به (slippage)، طريقة التنفيذ، أو تأخر الاتصال.

هذا المقال موجّه لكل من يستخدم روبوتات EA على منصة MT5 ومن يبرمجها بلغة MQL5، ويقدّم شرحاً شاملاً لـ الرمز 10021 (TRADE_RETCODE_PRICE_OFF) والرمز 10004 (TRADE_RETCODE_REQUOTE)، بالإضافة إلى الخطأين 136/138 من زمن MT4 — من حيث الماهية والأسباب والحلول الفورية والحلول البرمجية الدائمة. لمراجعة قائمة شاملة بجميع رموز الأخطاء، يمكن الاطلاع على الدليل الشامل لحل رموز أخطاء MQL5 / MT5.

ما الفرق بين هذين الخطأين (+ الخطأين 136/138 من MT4)

أخطاء "عدم تطابق السعر" تنقسم إلى نوعين حسب طريقة رد الخادم.

① TRADE_RETCODE_PRICE_OFF = 10021 (لا توجد تسعيرة يمكن معالجتها)

هذه القيمة تظهر في MqlTradeResult.retcode كنتيجة لتنفيذ OrderSend()، وتعني "لا توجد تسعيرة لمعالجة الطلب" (There are no quotes to process the request). يشير هذا إلى عدم توفر سعر صالح لدى الخادم، أو أن السعر المُرسل بعيد جداً عن التسعيرة الحالية بحيث لا يمكن معالجته.

المعنى: لا توجد تسعيرة لمعالجة الطلب
الثابت: TRADE_RETCODE_PRICE_OFF
القيمة: 10021

② TRADE_RETCODE_REQUOTE = 10004 (Requote — إعادة عرض سعر جديد)

هذه القيمة أيضاً تظهر في retcode ضمن OrderSend()، لكنها ليست رفضاً بسيطاً بل إعادة عرض سعر جديد ("هذا السعر غير صالح، فما رأيك بهذا السعر الجديد؟"). تُعاد قيمتا bid / ask ضمن MqlTradeResult وهما السعر الجديد الذي أعاد الخادم عرضه.

المعنى: Requote — إعادة عرض سعر جديد
الثابت: TRADE_RETCODE_REQUOTE
القيمة: 10004

// مثال نموذجي يظهر في السجل
2026.07.07 21:30:02.118 EA_NAME EURUSD,M5: OrderSend error 10004 (requote)
2026.07.07 21:30:02.310 EA_NAME EURUSD,M5: OrderSend error 10021

③ الخطأين 136 / 138 من زمن MT4

في MQL4 (MT4) كانت نفس هذه الظاهرة تُعاد كرمز خطأ عبر GetLastError().

إذا صادفت "error 136" أو "error 138" في مقالات قديمة تشرح روبوتات EA أو في سجلات روبوت مبني على MT4، فإن محتوى هذا المقال ينطبق عليه تماماً (في MT4 كانت القاعدة المتبعة هي استدعاء RefreshRates() لتحديث السعر قبل إعادة الإرسال؛ طريقة الكتابة في MT5 موضحة لاحقاً).

التمييز العملي:

كلا الخطأين مؤقتان (قابلان لإعادة المحاولة)، ولا يمكن "إلغاؤهما نهائياً" عبر تعديل الكود أو الإعدادات، لكن يمكن تقليل تكرارهما بشكل كبير.

تشخيص سريع خلال 30 ثانية

1. تحقق من التوقيت الذي ظهر فيه الخطأ من خلال سجل الأحداث
   • لحظة صدور مؤشر اقتصادي مثل تقرير الوظائف الأمريكي أو اجتماع FOMC ← تقلب طبيعي في السوق. إذا كان الروبوت يحتوي على فلتر للمؤشرات الاقتصادية، فعّله
   • حول منتصف الليل بتوقيت الخادم (rollover) أو فجوة بداية الأسبوع ← فترة تسعيرة ضعيفة، وهذا ضمن النطاق المتوقع
   • يتكرر بشكل عشوائي بغضّ النظر عن التوقيت ← اشتبه في الاتصال أو الـ VPS أو إعداد deviation
2. تحقق من الرمز المالي الذي ظهر فيه الخطأ
   • إذا كان التكرار مرتبطاً بأزواج عملات ثانوية أو رموز نادرة (exotic) أو عقود CFD ذات سيولة منخفضة، فالسبب هو ضعف التسعيرة في هذا الرمز تحديداً
3. جرّب التنفيذ اليدوي
   • إذا كان أمر السوق اليدوي السريع يُنفَّذ بشكل طبيعي بينما يُرفض فقط عند استخدام الروبوت، فالاحتمال الأكبر أن deviation (الانزلاق المسموح به) في الروبوت مضبوط بقيمة ضيقة جداً

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

الأسباب والحلول (5 أنماط)

① تقلب مفاجئ في السوق / ارتفاع حاد عند صدور المؤشرات (تقادم السعر المُرسل قبل وصوله)

الأعراض: يتكرر ظهور 10004/10021 بشكل مركّز عند توقيت صدور المؤشرات الاقتصادية، أو تصريحات مسؤولين، أو صباح الاثنين الباكر.

السبب: يستقبل الروبوت التسعيرة (tick) ويحسب السعر، وخلال عشرات إلى مئات الميلي ثانية اللازمة لوصول الأمر إلى الخادم، يتحرك السعر عدة نقاط (pips). بما أن السعر المُرسل لم يعد موجوداً، يُعيد الخادم إما Requote (10004) أو "لا تسعيرة" (10021). هذا ليس خطأً بحد ذاته، بل ظاهرة طبيعية تحدث في الأسواق سريعة الحركة.

الحل:

1. أوقف فتح صفقات جديدة قبل وبعد صدور المؤشرات (فلتر الأخبار). الروبوتات الموزّعة على هذا الموقع تتضمن EconomicFilter كإعداد أساسي
2. وسّع قيمة deviation (الانزلاق المسموح به) لتصبح واقعية (راجع البند ②)
3. أضف منطق إعادة المحاولة (retry) الموضح لاحقاً في الكود

② قيمة deviation (الانزلاق المسموح به) ضيقة جداً

الأعراض: يظهر الخطأ أحياناً حتى في أوقات هدوء السوق. الأوامر اليدوية تُنفَّذ بينما يُرفض الروبوت فقط.

السبب: الحقل MqlTradeRequest.deviation يحدد "إلى أي مدى بالنقاط (points) يمكن قبول انحراف السعر عن السعر المُرسل". إذا كانت القيمة صفراً أو بضع نقاط فقط، فحتى الانحراف الطبيعي الناتج عن تحديث التسعيرة سيُرفض. من الأخطاء الشائعة أيضاً الخلط بين points وpips (في وسطاء بخمس خانات عشرية، 1 pip = 10 points).

الحل:

1. ابدأ بقيمة deviation تتراوح بين 10 و30 نقطة (= 1 إلى 3 pips). إذا لم تكن الاستراتيجية سكالبينغ، فإن 20 نقطة نقطة انطلاق مناسبة
2. تأكد من عدم وجود خلط في الوحدات مثل ظن أن deviation=5 يعني 0.5 pips
3. إذا كانت الاستراتيجية لا تسمح بأي انزلاق إطلاقاً، فاعتبر الرفض جزءاً من التصميم واكتفِ بضبط عدد مرات إعادة المحاولة

③ اختلاف طريقة التنفيذ (Requote ظاهرة خاصة بتنفيذ instant)

الأعراض: يتكرر الخطأ كثيراً لدى الوسيط A، بينما لا يظهر إطلاقاً لدى الوسيط B.

السبب: خطأ Requote (10004) ظاهرة خاصة بـ instant execution (التنفيذ الفوري). في هذا النوع من التنفيذ، الأمر يعني "نفّذ الصفقة عند هذا السعر تحديداً"، لذا إذا تحرك السعر يُعيد الخادم عرض سعر جديد (Requote). أما market execution (تنفيذ السوق) فيعني "نفّذ الصفقة عند سعر السوق الحالي"، وبالتالي لا يمكن مبدئياً حدوث Requote، بل تُنفَّذ الصفقة مباشرة بالسعر المنحرف (انزلاق/slippage).

بمعنى آخر، "عدم ظهور Requote" لا يعني "وسيط أفضل"، بل هو مقايضة بين الرفض والتنفيذ بانزلاق. يمكن التحقق من طريقة التنفيذ للرمز المالي من حقل Execution في "مواصفات الرمز" (Specification) في MT5، أو برمجياً عبر SYMBOL_TRADE_EXEMODE.

الحل:

1. تحقق من طريقة التنفيذ في حسابك (الحسابات القياسية لدى معظم الوسطاء الدوليين تستخدم market execution، وبالتالي لا يظهر Requote أصلاً)
2. إذا كان تكرار Requote يعيق الاستراتيجية، ففكّر في نوع حساب أو وسيط يعتمد market execution
3. حتى مع market execution، بعض الوسطاء يحترمون قيمة deviation وبعضهم لا يحترمها، لذا إذا كان الانزلاق الكبير غير مقبول، تحقق من الانزلاق الفعلي عبر سجل الصفقات المنفذة

④ فترات أو رموز ذات تسعيرة ضعيفة أو متوقفة

الأعراض: يظهر 10021 حول منتصف الليل بتوقيت الخادم (rollover)، أو مباشرة بعد افتتاح بداية الأسبوع، أو في فترات الركود مثل عيد الميلاد، أو في رموز ثانوية.

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

الحل:

1. تجنّب فتح صفقات جديدة بين الساعة 23:55 و00:05 تقريباً بتوقيت الخادم (فلتر زمني)
2. تجنّب الدقائق الأولى بعد افتتاح بداية الأسبوع (إعداد من نوع AvoidMondayOpen)
3. أضف فلتر سبريد (MaxSpread). بما أن السبريد يتسع في فترات ضعف التسعيرة، فهذا يتيح تجنّب هذه الفترات تلقائياً

⑤ تأخر الاتصال (VPS بعيد عن خادم الوسيط)

الأعراض: يتكرر الخطأ بشكل ملحوظ أكثر من بيئات أخرى، بغض النظر عن التوقيت أو الرمز المالي. قيمة ping مرتفعة.

السبب: كلما طال وقت الذهاب والإياب (latency) اللازم لوصول الأمر إلى الخادم، زادت احتمالية تحرك السعر خلال تلك الفترة. تشغيل الروبوت من جهاز منزلي، أو من VPS في منطقة بعيدة عن موقع خادم الوسيط (غالباً لندن أو نيويورك)، يرفع بشكل بنيوي من تكرار 10004/10021. قيمة ping الظاهرة أسفل يمين شاشة MT5 مؤشر جيد على ذلك (مئات الميلي ثانية غير مناسبة بوضوح، بينما عشرات الميلي ثانية أو أقل هي المطلوبة).

الحل:

1. تحقق من قيمة ping أسفل يمين MT5، وإذا كانت مرتفعة باستمرار، أعد النظر في بيئة تشغيل الروبوت
2. انقل الروبوت إلى VPS في منطقة قريبة من خادم الوسيط. بصراحة، أخطاء 10004/10021 الناتجة عن تأخر الاتصال لا يمكن تقليلها عبر الكود، والحل الوحيد هو التقارب الفيزيائي. طريقة الاختيار مشروحة في كيفية اختيار VPS مناسب لروبوتات EA
3. تأثير التأخر يكون أكبر في الروبوتات السكالبينغ. أما الروبوتات التي تعمل على فريم يومي أو H4 فأولوية هذا السبب منخفضة بالنسبة لها

كود بلغة MQL5 لتقليل هذا الخطأ (لمطوري الروبوتات)

الاستراتيجية تتكون من ثلاثة محاور: (1) ضبط deviation بقيمة واقعية، (2) عند الرفض، إعادة جلب أحدث تسعيرة وإعادة الإرسال، (3) قصر إعادة المحاولة على رموز retcode المتعلقة بالسعر فقط.

ضبط deviation بوحدة النقاط (points) بشكل مناسب

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
req.action    = TRADE_ACTION_DEAL;
req.symbol    = _Symbol;
req.type      = ORDER_TYPE_BUY;
req.volume    = lots;
req.deviation = 20;   // انزلاق مسموح به 20 نقطة (2.0 pips في وسيط بخمس خانات)
// يجب أيضاً ضبط req.price / req.sl / req.tp / req.magic وغيرها

وحدة deviation هي points. في الوسطاء ذوي التسعير بخمس (أو ثلاث) خانات عشرية، 10 points = 1 pip. القيمة صفر أو أي قيمة صغيرة جداً ترفع معدل الرفض دون داعٍ.

إعادة المحاولة فقط لرموز retcode المتعلقة بالسعر (بإعادة الإرسال بأحدث تسعيرة)

النقطة الأساسية هي إعادة جلب السعر عبر SymbolInfoTick() في كل محاولة (إعادة إرسال السعر القديم سيؤدي فقط لنفس الرفض)، وقصر إعادة المحاولة على 10004/10021 فقط. إعادة إرسال أمر تلقائياً بسبب رصيد غير كافٍ (10019) أو طلب غير صالح (10013) لا فائدة منها، بل تُثقل السجل فقط.

bool IsRetryableRetcode(uint rc)
{
   return (rc == TRADE_RETCODE_REQUOTE       // 10004
        || rc == TRADE_RETCODE_PRICE_OFF);   // 10021
}

// إعادة الإرسال حتى 3 مرات كحد أقصى مع تحديث السعر في كل مرة بأحدث تسعيرة
bool SendWithRetry(MqlTradeRequest &req, MqlTradeResult &res, int maxTries = 3)
{
   for(int attempt = 0; attempt < maxTries; attempt++)
   {
      MqlTick tick;
      if(!SymbolInfoTick(req.symbol, tick))
      {
         Print("SymbolInfoTick failed: ", GetLastError());
         return false;
      }
      req.price = (req.type == ORDER_TYPE_BUY) ? tick.ask : tick.bid;

      if(OrderSend(req, res) && res.retcode == TRADE_RETCODE_DONE)
         return true;                          // تم التنفيذ بنجاح

      if(!IsRetryableRetcode(res.retcode))
      {
         PrintFormat("OrderSend failed (no retry): retcode=%d", res.retcode);
         return false;                         // لا تُعِد المحاولة لغير أخطاء السعر
      }
      PrintFormat("Retry %d/%d after retcode=%d", attempt + 1, maxTries, res.retcode);
      Sleep(200 + 150 * attempt);              // انتظار تدريجي: 200ms ← 350ms ← 500ms
   }
   Print("Order abandoned after retries (price kept moving).");
   return false;
}

سبب زيادة وقت Sleep() تدريجياً هو أن إعادة الإرسال الفورية دون انتظار خلال لحظة التقلب الحاد ستؤدي فقط لنفس الرفض المتكرر. في المقابل، الانتظار الطويل جداً يُبعد سعر الدخول عن افتراضات الاستراتيجية، لذا من الأفضل التوقف عن المحاولة بعد مرتين أو ثلاث محاولات فقط. لاحظ أيضاً أنه في حال أوامر معلّقة (TRADE_ACTION_PENDING)، فإن retcode النجاح يكون TRADE_RETCODE_PLACED (10008).

استخدام السعر المُعاد عرضه في Requote (10004)

عند حدوث 10004، تحمل bid / ask ضمن MqlTradeResult السعر الجديد الذي أعاد الخادم عرضه. إعادة الإرسال بأحدث تسعيرة كما في المثال أعلاه كافٍ عملياً في معظم الحالات، لكن إذا أردت بناء منطق "اقبل السعر الجديد إذا كان ضمن نطاق مقبول" في حالة instant execution، فيمكن مقارنة الفرق بين res.ask / res.bid والسعر الأصلي المتوقع بالنقاط قبل إعادة الإرسال.

تجنّب فتح صفقات في فترات محددة أصلاً

إعادة المحاولة عبر الكود هي حل علاجي مؤقت. الأكثر فاعلية من الناحية الجذرية هو فلتر يمنع فتح صفقات جديدة قبل وبعد rollover، وحول توقيت المؤشرات الاقتصادية، وعند اتساع السبريد.

// مثال فلتر السبريد: تجنّب فتح صفقات جديدة عندما يتسع السبريد
long spreadPts = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spreadPts > MaxSpreadPoints)
{
   // تجاوز فتح صفقة جديدة (يتجنب تلقائياً الفترات الضعيفة التي يكثر فيها 10021)
   return;
}

الروبوتات التي يوزعها FXEA365 تتضمن بشكل أساسي فلتر السبريد، وفلتر المؤشرات الاقتصادية، وإعادة المحاولة التلقائية لرموز retcode المتعلقة بالسعر.

قائمة تحقق حسب الأولوية

الخلاصة

• 10021 (TRADE_RETCODE_PRICE_OFF) تعني "لا توجد تسعيرة يمكن معالجتها"، بينما 10004 (TRADE_RETCODE_REQUOTE) تعني "إعادة عرض سعر جديد". وهما ينتميان لنفس عائلة أخطاء رفض السعر التي كانت تُعرف بالرمزين 136/138 في زمن MT4، وليستا متعلقتين بالرصيد أو حجم اللوت.
• تتركز الأسباب في خمسة عوامل: التقلب المفاجئ في السوق، وضبط deviation بقيمة ضيقة جداً، وتنفيذ instant، وفترات/رموز ذات تسعيرة ضعيفة، وتأخر الاتصال.
• ظاهرة Requote خاصة بتنفيذ instant، بينما في market execution تظهر بدلاً منها كانزلاق سعري (slippage). "عدم ظهورها" ليس بالضرورة "أفضل"، بل هي مقايضة.
• على مطوري الروبوتات اعتماد حل دائم عبر إعادة المحاولة 2-3 مرات بأحدث تسعيرة (لرموز 10004/10021 فقط) + ضبط deviation بشكل مناسب + فلاتر زمنية وفلاتر سبريد. أما الجزء الناتج عن تأخر الاتصال فلا يمكن تقليله إلا بحل فيزيائي (VPS أقرب لخادم الوسيط).

للاطلاع على قائمة شاملة بجميع رموز الأخطاء، راجع الدليل الشامل لحل رموز أخطاء MQL5 / MT5، وللحصول على روبوتات مجانية تطبق هذه الحلول بشكل أساسي، راجع قائمة الروبوتات.

الأسئلة الشائعة

س: أيهما أخطر، 10004 أم 10021؟

كلاهما خطأ مؤقت متعلق بالسعر، ولا يوجد فرق كبير في الخطورة بينهما. الفرق فقط في طبيعة الرد: 10004 تعني "تمت إعادة عرض سعر جديد"، و10021 تعني "لم تتوفر تسعيرة يمكن معالجتها". إذا حدث الخطأ مرة واحدة فلا داعي للقلق، لكن إذا تكرر بكثرة في توقيت أو رمز مالي معين فيجب معالجة السبب (المؤشرات الاقتصادية، rollover، deviation، الاتصال).

س: هل الوسيط الذي لا يظهر لديه Requote إطلاقاً وسيط أفضل؟

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

س: يظهر لدي الخطأ 136 / 138 في روبوت يعمل على MT4، هل الحل نفسه؟

نعم. الخطأ 136 (ERR_OFF_QUOTES) يقابل 10021، والخطأ 138 (ERR_REQUOTE) يقابل 10004، والأسباب والحلول مشتركة بينهما. في MQL4 كانت القاعدة المتبعة هي استدعاء RefreshRates() قبل إعادة الإرسال لتحديث Bid / Ask، وهي نفس الفكرة المستخدمة في MQL5 عبر SymbolInfoTick().

س: لا يظهر الخطأ في الاختبار التاريخي (Backtest) لكنه يظهر في التداول الفعلي.

هذا أمر طبيعي. في Strategy Tester لا يوجد (أو يتم تبسيطه) عنصر "التأخير حتى وصول الأمر إلى الخادم" و"تحرك السعر خلال تلك الفترة"، لذا لا تظهر 10004/10021 إلا في التداول الفعلي (forward). حتى لو كانت نتائج الاختبار التاريخي جيدة، لا يزال ضبط deviation وإعادة المحاولة وبيئة التشغيل (VPS) أموراً ضرورية بشكل منفصل في التداول الفعلي.