خطأ MT5 "Not enough money" (134/10019): 7 أسباب وحلول

الحل الشامل لخطأ ERR_NO_MONEY (في MT5/MQL5)

عندما يظهر ERR_NO_MONEY أو not enough money في تبويب Expert أو سجل الأحداث (Journal) أثناء تشغيل إكسبيرت (EA)، يشعر الكثيرون بالقلق ويعتقدون أن الرصيد قد نفد. لكن الحقيقة أن هذا الخطأ قد يظهر حتى مع وجود رصيد كافٍ في الحساب. فالسبب لا يقتصر على "نفاد الأموال" فقط، بل يشمل عدة عوامل أخرى مثل طريقة حساب حجم اللوت، الرافعة المالية، وحجز الهامش بسبب الصفقات المفتوحة.

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

ما هو ERR_NO_MONEY (الفرق بين 134 و10019)

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

① ERR_NO_MONEY = 134 (خطأ وقت التشغيل من GetLastError())

هذا كود خطأ وقت التشغيل (runtime) الذي تُرجعه دالة GetLastError(). يظهر الكود 134 عندما تحدد دوال الحساب مثل OrderCalcMargin() أو OrderCalcProfit()، أو الأكواد بالأسلوب القديم، أن "الهامش المطلوب يتجاوز الهامش الحر المتاح".

المعنى: الأموال المطلوبة لتنفيذ عملية التداول غير كافية (not enough money)
الثابت: ERR_NO_MONEY
القيمة: 134

② TRADE_RETCODE_NO_MONEY = 10019 (كود إرجاع OrderSend())

عند تنفيذ أمر فعلي عبر OrderSend() في MQL5، تُخزَّن نتيجة العملية في MqlTradeResult.retcode. عندما يُرفض الأمر من قبل الخادم بسبب نقص الأموال، لا يظهر الكود 134 بل 10019 (TRADE_RETCODE_NO_MONEY). هذا ليس خطأً من MT5 نفسها، بل إشعار رفض من خادم البروكر.

المعنى: لا توجد أموال كافية لتنفيذ الأمر (There is not enough money to complete the request)
الثابت: TRADE_RETCODE_NO_MONEY
القيمة: 10019

// مثال نموذجي يمكن رؤيته في السجل
2026.06.12 09:15:32.441 EA_NAME XAUUSD,H1: OrderSend error 10019

الاستخدام العملي للتمييز بينهما:

إذا ظهر "134" في السجل، فالمشكلة في مرحلة الحساب/الفحص الداخلي، أما إذا ظهر "10019" أو رسالة not enough money في تبويب Expert، فالمشكلة في مرحلة رفض الخادم. السبب الجذري في الحالتين واحد (الهامش المطلوب > الهامش المتاح)، وبالتالي فإن طريقة العلاج مشتركة.

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

افتح تبويب "الأدوات → التداول" (Toolbox → Trade) في MT5 وراجع الثلاثة عناصر التالية:

الرصيد (Balance)              : النقد في الحساب
الهامش المتاح (Equity)        : الرصيد ± الأرباح/الخسائر العائمة
الهامش الحر (Free Margin)     : الهامش المتاح حاليًا للصفقات الجديدة ← هذا هو الأهم
مستوى الهامش (Margin Level %) : Equity / Margin × 100

• إذا كان الهامش الحر (Free Margin) أقل من الهامش المطلوب للصفقة الجديدة ← ستظهر ERR_NO_MONEY بنسبة 100%.
• إذا ظهر الخطأ رغم كفاية الرصيد، فالسبب غالبًا أحد الحالات التالية: "② حجم لوت مبالغ فيه"، "④ حجز الهامش بسبب صفقات قائمة"، أو "⑥ اختلاف نوع الحساب".

يمكن معرفة الهامش المطلوب لصفقة واحدة من خلال "الأسعار → النقر بزر الفأرة الأيمن على الرمز → المواصفات" (Specification) في MT5، حيث يظهر "هامش لوت واحد". المعادلة التقريبية هي:

الهامش المطلوب ≈ (حجم اللوت × حجم العقد × السعر) / الرافعة المالية

الأسباب والحلول (6 حالات)

① نقص فعلي في الهامش

الأعراض: تضخمت الخسائر العائمة، وأصبح الهامش الحر (Free Margin) أقل من المطلوب للصفقة الجديدة. شائع بعد سلسلة خسائر أو عند تعمق مستويات التعزيز (Martingale/Nampin).

الحل:

1. إيداع أموال إضافية، أو
2. إغلاق جزء من الصفقات المفتوحة يدويًا لاسترجاع الهامش
3. تقليل قيمة RiskPercent في الإكسبيرت لتصغير حجم اللوت لاحقًا

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

② حجم اللوت كبير جدًا (بالنسبة للرصيد)

الأعراض: يظهر ERR_NO_MONEY من أول صفقة رغم وجود رصيد كافٍ. شائع عند استخدام لوت ثابت.

السبب: قيمة FixedLot لا تتناسب مع رصيد الحساب والرافعة المالية. على سبيل المثال، في حساب برأس مال 100,000 ين ياباني (≈$670)، محاولة فتح صفقة بحجم 0.1 لوت على XAUUSD قد تجعل الهامش المطلوب يتجاوز الرصيد حسب الرافعة المالية.

الحل:

1. خفض اللوت الثابت إلى الحد الأدنى (0.01) والتحقق من إمكانية التشغيل
2. التحول إلى الحساب التلقائي لنسبة المخاطرة (UseFixedLot=false / RiskPercent)
3. إذا تعذر فتح صفقة بحجم 0.01 أيضًا، فالمشكلة في الرافعة المالية أو رأس المال ← انتقل إلى ③ أو ⑥

③ الرافعة المالية منخفضة / تم تقييدها بسبب نهاية الأسبوع أو حدث اقتصادي

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

السبب: عندما تكون الرافعة المالية للحساب منخفضة (مثل 1:30 في حساب خاضع للتنظيم الأوروبي مقابل 1:1000 في حساب خارجي)، يتغير الهامش المطلوب بعشرات الأضعاف. كذلك، قد يخفّض بعض البروكرات الرافعة المالية في عطلات نهاية الأسبوع أو حول الأحداث الاقتصادية الهامة (على سبيل المثال، يحدد XM الرافعة المالية بحد أقصى 200:1 في عطلة نهاية الأسبوع)، مما قد يؤدي فجأة إلى زيادة الهامش المطلوب أثناء الاحتفاظ بصفقة مفتوحة. كذلك قد تكون هناك حدود قصوى للرافعة المالية مخصصة لرمز معين، كالذهب أو العملات الرقمية.

الحل:

1. تحقق من الرافعة المالية للحساب (عبر لوحة تحكم البروكر أو معلومات الحساب في MT5)
2. تحقق من "نسبة الهامش" في مواصفات الرمز (قد تكون منخفضة لرموز معينة)
3. استخدم إعدادًا لإغلاق الصفقات قبل نهاية الأسبوع (مثل CloseAllBeforeWeekend=true)، أو انتقل إلى بروكر لا يقيّد الرافعة المالية في عطلة نهاية الأسبوع
4. التحول إلى حساب رافعة مالية أعلى، أو تقليل حجم اللوت

④ حجز الهامش بسبب صفقات قائمة

الأعراض: تُفتح الصفقة الأولى بنجاح، لكن يظهر ERR_NO_MONEY عند الصفقة الثانية أو عند زيادة الحجم (تعزيز/نامبين).

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

الحل:

1. تحقق من الهامش المستخدم (Margin) والهامش الحر (Free Margin) في تبويب "التداول"
2. تحقق مما إذا كانت الإكسبيرتات المختلفة تتنافس على نفس الهامش في نفس الحساب (عند تشغيل عدة إكسبيرتات)
3. حدد الحد الأقصى لعدد الصفقات المتزامنة عبر إعدادات الإكسبيرت
4. إكسبيرتات النامبين/الشبكة (Grid) تستهلك الهامش بسرعة كلما تعمقت المستويات ← راجع الحد الأقصى للمستويات، ومضاعف اللوت، وإعدادات الإغلاق الطارئ

⑤ احتساب البونص/الرصيد الائتماني ضمن الهامش

الأعراض: يظهر ERR_NO_MONEY رغم أن "الرصيد + البونص" من المفترض أن يكون كافيًا.

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

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

⑥ اختلاف حجم العقد حسب نوع الحساب (قياسي مقابل سنت/مايكرو)

الأعراض: نفس "حجم 0.01 لوت"، لكن عند تغيير الحساب يظهر فجأة ERR_NO_MONEY، أو على العكس يصبح الحجم مبالغًا فيه.

السبب: يختلف حجم العقد بين حساب السنت (المايكرو) والحساب القياسي بنحو 100 ضعف. فحجم 0.01 في حساب السنت يعادل تعرضًا فعليًا أقل بنحو 1/100. إذا كان الإكسبيرت لا يميز بين أنواع الحسابات ويستخدم لوتًا ثابتًا، فقد يؤدي ذلك إلى نقص الهامش في أحد الحسابين.

الحل:

1. إذا كنت تفضل التشغيل الآمن برأس مال صغير، استخدم حساب السنت/المايكرو لتجنب المخاطرة الزائدة حتى عند استخدام أدنى حجم لوت
2. صمم الإكسبيرت بحيث لا يُدرج نوع الحساب في الكود بشكل ثابت، بل يعتمد على OrderCalcMargin() لتحديد الهامش المطلوب الفعلي واحتساب حجم اللوت بناءً عليه (راجع القسم التالي)

ملاحظات خاصة بكل بروكر

حساب الرافعة المالية غير المحدودة لدى Exness (حسابات Pro/Raw Spread) يسمح غالبًا بتنفيذ صفقات جديدة حتى عندما يكون الهامش الحر شبه صفر، مما يقلل من احتمالية ظهور هذا الخطأ. هذا يتناسب جيدًا مع إكسبيرتات النامبين، لكن في المقابل، يصعب تفعيل وقف الخسارة (Stop Out)، مما يعني خطرًا معاكسًا يتمثل في تضخم الخسائر. راجع أيضًا صفحة مقارنة البروكرات لمزيد من التفاصيل.

كود بلغة MQL5 لمنع هذا الخطأ (لمطوّري الإكسبيرت)

التصميم الصحيح للإكسبيرت لا يقتصر على "الإصلاح" فقط، بل يمنع ظهور ERR_NO_MONEY أصلًا قبل إرسال الأمر. الفكرة الأساسية هي: "احسب الهامش المطلوب قبل إرسال الأمر، وإذا كان غير كافٍ، لا تفتح الصفقة أو قلّص حجم اللوت".

التحقق من الهامش المطلوب قبل إرسال الأمر

// بوابة قبل الإرسال: التحقق من أن الهامش المطلوب <= الهامش الحر قبل استدعاء OrderSend
bool HasEnoughMargin(ENUM_ORDER_TYPE type, double lots)
{
   double price = (type == ORDER_TYPE_BUY)
                  ? SymbolInfoDouble(_Symbol, SYMBOL_ASK)
                  : SymbolInfoDouble(_Symbol, SYMBOL_BID);

   double margin = 0.0;
   if(!OrderCalcMargin(type, _Symbol, lots, price, margin))
   {
      Print("OrderCalcMargin failed: ", GetLastError()); // مثل الكود 134
      return false;
   }
   double freeMargin = AccountInfoDouble(ACCOUNT_MARGIN_FREE);
   if(margin > freeMargin)
   {
      PrintFormat("Skip: need %.2f > free %.2f (ERR_NO_MONEY guard)", margin, freeMargin);
      return false;   // عدم فتح الصفقة = منع ERR_NO_MONEY مسبقًا
   }
   return true;
}

تسوية حجم اللوت وفق الحد الأدنى وخطوة اللوت

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

double NormalizeLot(double lots)
{
   double minLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
   double maxLot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MAX);
   double step    = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);
   lots = MathFloor(lots / step) * step;          // التقريب وفق خطوة اللوت
   lots = MathMax(minLot, MathMin(maxLot, lots)); // التحديد بين الحد الأدنى والأقصى
   return NormalizeDouble(lots, 2);
}

تحقق دائمًا من retcode الخاص بـ OrderSend

لا تكتفِ بالقيمة المُرجعة من OrderSend() (bool)، بل تحقق من result.retcode وعالج الكود 10019 (TRADE_RETCODE_NO_MONEY) بشكل منفصل.

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
// ... بناء req ...
if(!OrderSend(req, res) || res.retcode != TRADE_RETCODE_DONE)
{
   if(res.retcode == TRADE_RETCODE_NO_MONEY)   // 10019
      Print("Not enough money. يلزم تصغير حجم اللوت أو الإيداع.");
   else
      PrintFormat("OrderSend failed: retcode=%d, lastError=%d", res.retcode, GetLastError());
}

وقف طارئ عند انخفاض مستوى الهامش

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

double level = AccountInfoDouble(ACCOUNT_MARGIN_LEVEL); // مستوى الهامش %
if(level > 0 && level < EmergencyMarginLevel)          // مثال: 150%
{
   // إيقاف الدخول في صفقات جديدة / إغلاق جزء من الصفقات القائمة إذا لزم الأمر
}

الإكسبيرتات التي يوزّعها FXEA365 مزودة بشكل قياسي بـ "حساب اللوت التلقائي بنسبة المخاطرة"، و"التحقق من الهامش قبل إرسال الأمر"، و"الإغلاق الطارئ عند انخفاض مستوى الهامش (UseMarginEmergencyClose)"، مما يسمح بتشغيلها بسلاسة حتى برأس مال صغير.

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

الخلاصة

• لخطأ ERR_NO_MONEY وجهان: 134 (من GetLastError) و10019 (retcode الخاص بـ OrderSend، أي TRADE_RETCODE_NO_MONEY)، لكن السبب الجذري مشترك وهو "الهامش المطلوب > الهامش المتاح".
• حتى مع وجود رصيد كافٍ، قد يظهر الخطأ بسبب حجم لوت مبالغ فيه، رافعة مالية منخفضة (بما في ذلك تقييد نهاية الأسبوع)، حجز الهامش بسبب صفقات قائمة، أو اختلاف نوع الحساب.
• بالنسبة لمستخدمي الإكسبيرت، الوقاية تكون عبر "حساب اللوت التلقائي بنسبة المخاطرة" و"اختيار نوع حساب مناسب"، أما لمطوري الإكسبيرت، فالحل الدائم يكون عبر "بوابة OrderCalcMargin قبل الإرسال"، و"تسوية حجم اللوت"، و"معالجة retcode رقم 10019".

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

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

س: رصيدي كافٍ، لكن يظهر ERR_NO_MONEY. لماذا؟

لأن الحكم لا يعتمد على الرصيد (Balance) بل على الهامش الحر (Free Margin). إذا انخفض الهامش الحر بسبب خسائر عائمة أو حجز هامش من صفقات قائمة، فلن يمكن فتح صفقة جديدة حتى مع وجود رصيد كافٍ. تحقق من قيمة Free Margin في تبويب "التداول".

س: ما الفرق بين 134 و10019؟

134 (ERR_NO_MONEY) هو خطأ وقت التشغيل الذي تُرجعه GetLastError()، بينما 10019 (TRADE_RETCODE_NO_MONEY) هو نتيجة (retcode) دالة OrderSend(). الفرق فقط في مكان الظهور، أما السبب (نقص الأموال) فواحد.

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

السبب أن الرافعة المالية ونوع الحساب (سنت/قياسي) والصفقات القائمة في الحساب الحقيقي تختلف عن إعدادات الاختبار. الفرق في الرافعة المالية وحجم العقد يؤثر بشكل خاص وكبير.

س: يظهر ERR_NO_MONEY عند تعمق مستويات إكسبيرت النامبين/الشبكة (Grid).

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

س: هل يمكن تجنب هذا تلقائيًا عبر كود الإكسبيرت؟

نعم، يمكن ذلك. احسب الهامش المطلوب قبل إرسال الأمر باستخدام OrderCalcMargin()، وإذا تجاوز القيمة التي تُرجعها AccountInfoDouble(ACCOUNT_MARGIN_FREE)، لا تفتح الصفقة (أو قلّص حجم اللوت). راجع مثال الكود في المقال.

س: ما هو أقل رأس مال يمكن البدء به دون مخاطرة زائدة؟

يُعد البدء بحد أدنى لوت 0.01 في حساب قياسي برأس مال 100,000 ين ياباني (≈$670) معيارًا معقولًا. إذا كنت ترغب في رأس مال أقل أو تشغيل أكثر أمانًا، فاستخدام حساب سنت (مايكرو) يجعل التعرض الفعلي أصغر حتى عند استخدام الحد الأدنى للوت، مما يسهّل تجنب ERR_NO_MONEY.