خطأ Unsupported filling mode في MT5 (10030)

الحل الشامل لخطأ Unsupported filling mode (خطأ MT5 رقم 10030)

كان الـ EA يعمل بشكل طبيعي مع وسيط آخر حتى الأمس، لكن بمجرد نقله إلى حساب جديد تظهر رسائل Unsupported filling mode أو OrderSend error 10030 في تبويب Expert ولا يُنفَّذ ولو أمر واحد — هذه واحدة من أكثر مشاكل الانتقال بين الوسطاء شيوعًا عند تشغيل EA على MT5. الأمر لا علاقة له بعطل في الـ EA أو مشكلة في الحساب. السبب ببساطة أن طريقة تنفيذ الأمر (filling mode) المحددة غير مسموح بها لهذا الرمز لدى الوسيط الجديد.

هذا المقال موجّه لكل من يستخدم EA على MT5 ومن يكتب EA بلغة MQL5، ويجمع في مكان واحد حقيقة TRADE_RETCODE_INVALID_FILL (10030)، معنى FOK/IOC/RETURN، طريقة تحقق تستغرق 30 ثانية، والحل الدائم على مستوى الكود. للاطلاع على قائمة شاملة بجميع أكواد الأخطاء، راجع الدليل الشامل لحل أكواد أخطاء MQL5 / MT5.

ما هو 10030 (TRADE_RETCODE_INVALID_FILL)

تُخزَّن نتيجة OrderSend() في MqlTradeResult.retcode. القيمة 10030 = TRADE_RETCODE_INVALID_FILL التي تظهر هنا هي رفض من جانب السيرفر بمعنى أن "طريقة التنفيذ (type_filling) المحددة في الطلب غير مسموح بها لهذا الرمز".

المعنى: طريقة التنفيذ (filling type) المحددة غير مدعومة
الثابت: TRADE_RETCODE_INVALID_FILL
القيمة: 10030
الرسالة: Unsupported filling mode / Invalid order filling type

// مثال نموذجي لما يظهر في السجل (log)
2026.07.07 09:15:32.441 EA_NAME EURUSD,M15: OrderSend error 10030
2026.07.07 09:15:32.441 EA_NAME EURUSD,M15: failed market buy 0.10 EURUSD [Unsupported filling mode]

النقطة المهمة هي أن رأس المال وحجم اللوت والسعر لا علاقة لهم بالأمر إطلاقًا. خطأ 10030 مشكلته منحصرة في حقل واحد فقط داخل الطلب وهو MqlTradeRequest.type_filling، وبمجرد تصحيحه ينفَّذ نفس الأمر دون أي تغيير آخر.

الأنواع الأربعة لطريقة التنفيذ (type_filling)

يحتوي ENUM_ORDER_TYPE_FILLING في MQL5 على أربع قيم.

في EA الفوركس العادية، غالبًا لا يُستخدم فعليًا سوى FOK أو IOC. أما RETURN فمعناها مرتبط بالتنفيذ من نوع البورصة (Exchange execution) كالأسهم والعقود الآجلة، وBOC يُستخدم لغرض خاص عندما يُراد فرض أن يكون الأمر من نوع الصانع (Maker) فقط.

لماذا يُعتبر الطلب "غير صالح" — SYMBOL_FILLING_MODE

طرق التنفيذ التي يقبلها الوسيط تُحدَّد عبر علم (flag) يضبطه الوسيط لكل رمز على حدة (SYMBOL_FILLING_MODE). يمكن قراءته من MQL5 كالتالي:

long flags = SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE);
// إذا كان علم SYMBOL_FILLING_FOK مفعّلاً فـ FOK مسموح
// إذا كان علم SYMBOL_FILLING_IOC مفعّلاً فـ IOC مسموح

SYMBOL_FILLING_MODE عبارة عن أعلام ثنائية (bit flags) تحمل حالة السماح بـ FOK وIOC (إذا كان كلاهما مسموحًا، يُفعَّل كلا العلمين). أما RETURN فلا يظهر ضمن هذا العلم، وتحديد إمكانية استخدامه يعتمد على وضع التنفيذ الخاص بالرمز (الموضح لاحقًا).

بمعنى آخر، سبب ظهور 10030 بسيط جدًا:

type_filling الذي أرسله الـ EA ∉ طرق التنفيذ المسموح بها لهذا الرمز → 10030

هذا كل ما في الأمر.

لماذا يظهر هذا الخطأ "في يوم تغيير الوسيط" تحديدًا

السبب في تسمية 10030 بـ"الخطأ الكلاسيكي عند الانتقال بين الوسطاء" هو التالي:

1. طرق التنفيذ المسموح بها تختلف حسب الوسيط وحسب الرمز. بعض الوسطاء يسمحون بـ FOK فقط لرموز الفوركس، وآخرون بـ IOC فقط، وبعضهم يسمح بكليهما. حتى داخل الوسيط الواحد، من الطبيعي أن يختلف الإعداد بين الفوركس والعقود مقابل الفروقات (CFD) والأسهم.
2. كثير من الـ EA يضع type_filling كقيمة ثابتة في الكود. فمثلًا EA مكتوب بصيغة request.type_filling = ORDER_FILLING_FOK; سيعمل لسنوات دون مشاكل مع وسيط A الذي يسمح بـ FOK. وبما أنه يعمل في بيئة المطور، لا يُكتشف كخطأ ويُوزَّع على هذا الأساس.
3. إذا لم يسمح الوسيط الجديد B بـ FOK، تفشل كل الأوامر من أول محاولة تنفيذ. وغالبًا لا يظهر هذا في الاختبار الخلفي (Backtest) لأن سلوك أداة الاختبار أكثر تساهلًا من السيرفر الفعلي، فيظهر الخطأ فقط "في يوم نقل الحساب الحقيقي".

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

العلاقة مع وضع التنفيذ (SYMBOL_TRADE_EXEMODE)

يمتلك كل رمز، بالإضافة إلى طريقة التنفيذ، وضع تنفيذ (execution mode) يؤثر على أي طرق تنفيذ تكون ذات معنى.

تحديد التوليفة المسموح بها بدقة يعتمد على إعداد سيرفر الوسيط، لكن من الناحية العملية يكفي أن تتذكر: "في تنفيذ Market لرموز الفوركس/CFD يُستخدم FOK أو IOC، وفي النمط الشبيه بالبورصة يُستخدم RETURN". يمكن أيضًا التحقق من وضع التنفيذ عبر SymbolInfoInteger(_Symbol, SYMBOL_TRADE_EXEMODE).

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

① التحقق من طرق التنفيذ المسموحة للرمز (شاشة MT5)

افتح نافذة الأسعار (Market Watch) ← انقر بزر الفأرة الأيمن على الرمز ← المواصفات (Specification) وانظر إلى سطر "التنفيذ" (Filling). ستظهر قيمة مثل Fill or Kill أو Immediate or Cancel أو كلاهما معًا. إذا كان الـ EA يرسل طريقة غير مذكورة هنا، فالسبب مؤكد هو 10030.

② التحقق من معاملات إدخال الـ EA

الـ EA المصمَّم بجودة جيدة عادةً ما يحتوي على معامل إدخال باسم FillingType أو Filling Mode. إذا وُجد، يكفي تغييره ليتوافق مع الطريقة المسموحة التي تحققت منها في الخطوة ① (دون الحاجة لتعديل الكود).

③ التحقق عبر الكود (للمطورين)

long flags = SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE);
PrintFormat("%s filling: FOK=%s IOC=%s exemode=%d",
            _Symbol,
            ((flags & SYMBOL_FILLING_FOK) != 0) ? "yes" : "no",
            ((flags & SYMBOL_FILLING_IOC) != 0) ? "yes" : "no",
            (int)SymbolInfoInteger(_Symbol, SYMBOL_TRADE_EXEMODE));

بتشغيل هذا الكود عبر سكربت، تظهر الحالة الفعلية للسماح لدى ذلك الوسيط ولهذا الرمز في سطر واحد.

الحل الدائم — كود MQL5 يقرأ أعلام السماح ويختار تلقائيًا

الطريقة الصحيحة لحل 10030 ليست "الضبط اليدوي في كل مرة يتغير فيها الوسيط"، بل جعل الـ EA نفسه يقرأ أعلام السماح الخاصة بالرمز ويختار تلقائيًا. فيما يلي التطبيق القياسي الجاهز للاستخدام مباشرة.

دالة الاختيار التلقائي

// تُعيد طريقة التنفيذ المسموح بها فعليًا لهذا الرمز
// الأولوية: FOK ← IOC ← RETURN (كحل احتياطي للنمط الشبيه بالبورصة)
ENUM_ORDER_TYPE_FILLING GetFillingMode(const string symbol)
{
   long flags = SymbolInfoInteger(symbol, SYMBOL_FILLING_MODE);

   if((flags & SYMBOL_FILLING_FOK) != 0)
      return ORDER_FILLING_FOK;    // ينفَّذ فقط إذا أمكن تنفيذ الكمية بالكامل (بدون تنفيذ جزئي)

   if((flags & SYMBOL_FILLING_IOC) != 0)
      return ORDER_FILLING_IOC;    // يُنفَّذ القدر الممكن فقط، وتُلغى البقية

   return ORDER_FILLING_RETURN;    // لا توجد أعلام = نمط شبيه بالبورصة وغيره. يُرسل بـ RETURN
}

طريقة الاستخدام مع OrderSend

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);

req.action       = TRADE_ACTION_DEAL;
req.symbol       = _Symbol;
req.volume       = lots;
req.type         = ORDER_TYPE_BUY;
req.price        = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
req.deviation    = 20;
req.magic        = MagicNumber;
req.type_filling = GetFillingMode(_Symbol);   // ← دون تثبيت القيمة في الكود

if(!OrderSend(req, res) || res.retcode != TRADE_RETCODE_DONE)
{
   if(res.retcode == TRADE_RETCODE_INVALID_FILL)   // 10030
      PrintFormat("Unsupported filling mode: sent=%d, allowed flags=%d",
                  (int)req.type_filling,
                  (int)SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE));
   else
      PrintFormat("OrderSend failed: retcode=%d", res.retcode);
}

بهذا يعمل نفس الملف التنفيذي سواء مع وسيط يدعم FOK فقط أو وسيط يدعم IOC فقط، دون الحاجة لأي تعديل يدوي عند كل عملية انتقال.

في حال استخدام CTrade

توفر المكتبة القياسية CTrade دالة SetTypeFillingBySymbol() التي تضبط طريقة التنفيذ تلقائيًا بناءً على أعلام السماح الخاصة بالرمز.

#include <Trade/Trade.mqh>
CTrade trade;

int OnInit()
{
   trade.SetExpertMagicNumber(MagicNumber);
   trade.SetTypeFillingBySymbol(_Symbol);   // يقرأ أعلام السماح ويضبط تلقائيًا
   return INIT_SUCCEEDED;
}

إذا كان سبب ظهور 10030 هو الكتابة القديمة trade.SetTypeFilling(ORDER_FILLING_FOK); (قيمة ثابتة مسبقًا)، فيكفي استبدالها بهذا السطر الواحد لحل المشكلة. وفي حال الرغبة بالتحديد اليدوي، يمكن تمرير نتيجة GetFillingMode() المذكورة أعلاه إلى SetTypeFilling() للحصول على نفس التأثير.

ملاحظة عند استخدام أوامر Limit (خيار BOC)

ORDER_FILLING_BOC (Book or Cancel) مخصص فقط لأوامر limit وstop limit، ويُرفض إذا حُدِّد سعر سيُنفَّذ فورًا. استخدامه في أوامر السوق (market) خطأ، لذا لا داعي لإدراج BOC كخيار في EA من نوع أوامر السوق.

ملاحظات متعلقة بالوسيط (إعادة التحقق عند الانتقال)

• إعداد السماح بطرق التنفيذ لا يختلف فقط من وسيط لآخر، بل يختلف أيضًا من رمز (أو مجموعة رموز) لآخر داخل الوسيط نفسه. من الطبيعي أن يكون الفوركس مسموحًا فيه بـ IOC بينما لا تسمح عقود الأسهم مقابل الفروقات إلا بـ RETURN.
• قد يتغير الإعداد أيضًا عند تغيير نوع الحساب أو السيرفر. ليس فقط عند الانتقال بين الوسطاء، بل قد يبدأ ظهور 10030 فجأة بعد نقل السيرفر داخل نفس الوسيط، أو تغيير نوع الحساب، أو تحديث مواصفات الرمز.
• لذلك من الأفضل اعتماد قاعدة عمل ثابتة: "عند تغيير الحساب أو السيرفر أو الرمز، أعد التحقق من طريقة التنفيذ عبر شاشة المواصفات (أو عبر سكربت)". أما إذا كان الـ EA يحتوي على كود الاختيار التلقائي، فهذا التحقق يصبح غير ضروري من الأساس.

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

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

الخلاصة

• خطأ Unsupported filling mode (10030 / TRADE_RETCODE_INVALID_FILL) هو رفض من السيرفر عندما تكون طريقة type_filling المحددة في الأمر (FOK / IOC / RETURN / BOC) غير مسموح بها لهذا الرمز. لا علاقة لرأس المال أو حجم اللوت بالأمر.
• بما أن طرق التنفيذ المسموحة تختلف حسب الوسيط وحسب الرمز، فإن أي EA يثبّت type_filling كقيمة ثابتة في الكود سيُصدر 10030 دفعة واحدة يوم الانتقال إلى وسيط جديد. هذا هو النمط النموذجي لهذا الخطأ.
• بالنسبة للمستخدم، يكفي "التحقق من خانة التنفيذ في مواصفات الرمز ← تعديل معامل إدخال الـ EA" للحل الفوري. أما بالنسبة للمطور، فيمكن تحقيق حل دائم عبر قراءة أعلام SymbolInfoInteger(SYMBOL_FILLING_MODE) والاختيار التلقائي بناءً عليها (أو استخدام CTrade::SetTypeFillingBySymbol()).

للاطلاع على أكواد الأخطاء الأخرى بشكل عام، راجع الدليل الشامل لحل أكواد أخطاء MQL5 / MT5. جميع الـ EA التي توزعها FXEA365 تطبّق آلية اختيار تلقائي لطريقة التنفيذ، وتعمل بغض النظر عن الوسيط المستخدم (قائمة الـ EA).

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

س: كان الـ EA يعمل بشكل طبيعي حتى الأمس، لكن بعد تغيير الوسيط توقف تمامًا عن تنفيذ الأوامر مع ظهور 10030. هل هذا عطل في الـ EA؟

ليس عطلاً. السبب أن طريقة التنفيذ التي يحددها الـ EA (مثل FOK) غير مسموح بها لهذا الرمز لدى الوسيط الجديد. تحقق من خانة "التنفيذ" في مواصفات الرمز، ثم عدّل معامل إدخال الـ EA (مثل FillingType) ليتوافق معها، أو صحّح الكود ليختار تلقائيًا، وسيعمل الـ EA كالمعتاد.

س: أيهما يجب استخدامه، FOK أم IOC؟

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

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

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

س: نفس الوسيط، لكن 10030 يظهر مع بعض الرموز دون غيرها.

هذا سلوك طبيعي (وارد الحدوث). السماح بطريقة التنفيذ يُحدَّد على مستوى كل رمز على حدة، لذلك من الطبيعي أن تسمح أزواج الفوركس بـ IOC بينما لا تسمح عقود الأسهم مقابل الفروقات إلا بـ RETURN، وهكذا تختلف المجموعات. يجب على أي EA يتعامل مع رموز متعددة أن يقرأ SYMBOL_FILLING_MODE لكل رمز على حدة.

س: لا يمكنني تعديل كود الـ EA (أملك فقط ملف .ex5). ماذا أفعل؟

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