Invalid Fill را خطای جهت معامله حساب نکن
وقتی اکسپرت متاتریدر ۵ با کد 10030 متوقف می‌شود، نتیجه رسمی سرور TRADE_RETCODE_INVALID_FILL است؛ یعنی نوع پرشدن سفارش نامعتبر بوده است [۵]. این کد به‌تنهایی نمی‌گوید سیگنال خرید یا فروش اشتباه بوده، حجم حتماً نامناسب است یا بروکر بد عمل کرده است. اول باید ببینی فیلد type_filling در همان MqlTradeRequest چه مقداری داشته و نماد در همان حساب کدام سیاست‌ها را اجازه داده است [۳].
یک گزارش قابل‌تکرار باید زمان، نام دقیق نماد، نوع حساب، حالت اجرای نماد، نوع سفارش، حجم درخواستی، مقدار type_filling و retcode کامل را نگه دارد. عبارت کوتاه «سفارش ارسال نشد» برای عیب‌یابی کافی نیست. همین اطلاعات جلوی یک اشتباه رایج را می‌گیرد: تغییر تصادفی FOK به IOC یا RETURN تا خطا ناپدید شود، بدون اینکه اثر آن بر پرشدن ناقص سفارش بررسی شده باشد.
قانون را از خود نماد بخوان
ویژگی SYMBOL_FILLING_MODE مجموعه پرچم‌های مجاز پرشدن سفارش را برای نماد نشان می‌دهد. مستند رسمی توضیح می‌دهد که ممکن است چند پرچم با عملگر OR کنار هم باشند؛ مثلاً FOK و IOC هم‌زمان مجاز باشند. برای آزمون یک پرچم باید نتیجه AND بیتی با همان پرچم را بررسی کنی [۲]. عددی که از حساب یا نماد دیگری یادداشت شده، جای پرس‌وجوی تازه SymbolInfoInteger را نمی‌گیرد.
حالت اجرای نماد نیز مهم است. طبق جدول رسمی، در Market Execution استفاده از RETURN ممنوع است، حتی اگر منطق عمومی برنامه آن را انتخاب پیش‌فرض بداند. FOK و IOC در این حالت باید در تنظیمات نماد مجاز باشند. در Instant و Request Execution جدول رفتار دیگری دارد و در Exchange Execution نیز قواعد مجاز باید مطابق همان جدول خوانده شوند [۱، ۲]. پس یک شرط ثابت برای تمام نمادها و تمام حساب‌ها طراحی نکن.
FOK و IOC فقط دو نام متفاوت نیستند
در FOK یا Fill or Kill، حجم خواسته‌شده باید کامل اجرا شود؛ اگر حجم لازم موجود نباشد، سفارش اجرا نمی‌شود. در IOC یا Immediate or Cancel، بخش موجود می‌تواند اجرا شود و باقی‌مانده لغو می‌شود. RETURN باقی‌مانده یک پرشدن جزئی را برای پردازش بعدی نگه می‌دارد، اما در Market Execution مجاز نیست. BOC یا Book or Cancel سیاست سفارش منفعل است و فقط برای سفارش‌های Limit و Stop Limit پشتیبانی می‌شود [۱].
یک مثال کاملاً فرضی بساز: اکسپرت 1.00 لات درخواست می‌کند و در مدل آموزشی فقط 0.60 لات در قیمت موردنظر در دسترس است. با فرض ساده‌شده FOK، درخواست کامل نمی‌شود؛ با فرض IOC ممکن است 0.60 لات اجرا و 0.40 لات لغو شود. این مثال گزارش اجرای واقعی نیست و درباره نقدشوندگی یک بروکر ادعا نمی‌کند. نکته ریسک این است که پرشدن جزئی می‌تواند اندازه موقعیت و محاسبه پوشش یا خروج بعدی را تغییر دهد.
ماتریس سازگاری را بدون ارسال سفارش بساز
AutoTrading را خاموش نگه دار و ابتدا فقط داده جمع کن. برای هر نماد، SYMBOL_TRADE_EXEMODE، مقدار خام SYMBOL_FILLING_MODE، نتیجه آزمون پرچم FOK، IOC و BOC و سیاست پیشنهادی منطق خودت را در جدول بنویس. سپس برای Market، Limit و Stop Limit ردیف جدا بساز. اگر مشخصات نماد خوانده نشد یا مظنه تازه نبود، نتیجه را «پیش‌شرط نامعتبر» ثبت کن، نه اینکه یک سیاست فرضی انتخاب کنی.
انتظار هر ردیف را قبل از اجرای کد بنویس: مجاز، غیرمجاز یا نیازمند بررسی بیشتر. یک حالت منفی برای RETURN در Market Execution و یک حالت دارای هر دو پرچم FOK و IOC اضافه کن. برای BOC نیز فقط سفارش‌های پشتیبانی‌شده را بسنج. هدف این آزمایش تولید لاگ تصمیم است، نه ارسال معامله دمو یا واقعی. اگر خروجی برنامه با جدول رسمی ناسازگار بود، همان ردیف به تست رگرسیون تبدیل می‌شود.
OrderCheck و ابزار CTrade چه کمکی می‌کنند؟
ساختار MqlTradeRequest فیلد type_filling از نوع ENUM_ORDER_TYPE_FILLING دارد [۳]. پیش از ارسال، OrderCheck می‌تواند پارامترهای نادرست یا ناکافی‌بودن وجه را گزارش کند و نتیجه را در MqlTradeCheckResult بگذارد؛ با این حال مرجع رسمی صریح است که موفقیت این بررسی، اجرای موفق عملیات را تضمین نمی‌کند [۴]. بنابراین «بررسی پذیرفته شد»، «درخواست پذیرفته شد» و «معامله انجام شد» سه وضعیت جدا هستند.
اگر از کلاس استاندارد CTrade استفاده می‌کنی، SetTypeFillingBySymbol سیاست را از تنظیمات نماد تعیین می‌کند و در صورت تشخیص موفق true برمی‌گرداند. مستند آن می‌گوید اگر FOK و IOC هم‌زمان مجاز باشند، این تابع FOK را تنظیم می‌کند [۶]. این رفتار را در لاگ ثبت کن و با نیاز استراتژی مقایسه کن؛ استفاده از تابع کمکی جای بررسی اثر پرشدن کامل یا جزئی بر مدیریت ریسک را نمی‌گیرد.
قبل از خرید یا ارزیابی اکسپرت چه بخواهی؟
از فروشنده یا توسعه‌دهنده بخواه لاگ شامل نماد، حالت اجرا، پرچم‌های filling، نوع سفارش، type_filling انتخاب‌شده و کد کامل سرور ارائه کند. یک منحنی سود یا اسکرین‌شات ترمینال نشان نمی‌دهد ربات روی نماد دیگر چگونه با پرشدن جزئی یا سیاست نامعتبر برخورد می‌کند. فایل EX5 امکان مشاهده برخی رفتارها را می‌دهد، اما ممیزی کامل منطق و مسیرهای خطا به کد MQ5 و وابستگی‌ها نیاز دارد.
قدم عملی بعدی، ساخت یک ماتریس حداقل دوازده‌ردیفی برای سه نوع سفارش و چند ترکیب سیاست است. ردیف‌های ردشده و نامشخص را هم نگه دار. اگر اکسپرتی داری که کد 10030 می‌دهد، می‌توانی پس از مشخص‌کردن محدوده و هزینه، بخش بررسی اکسپرت باما‌آپ را ببینی. این مطلب آموزش فنی است؛ نه سیگنال، نه نتیجه آزمون واقعی، نه تضمین اجرای سفارش و نه وعده سود.
