MT5 Close all: de ce mai rămân poziții deschise?

Close all din MT5 este o secvență de cereri, nu garanția închiderii simultane a contului. După respingere, întrerupere sau închiderea aplicației pot rămâne poziții. Identifică ce s-a executat și ce volum mai există. Discutăm operațiunile de grup integrate în MT5; un script sau EA personalizat poate avea alte reguli.

Ce include comanda selectată?

Notează denumirea completă: toate pozițiile, numai cele profitabile, cele pierzătoare, un simbol sau o direcție. Selectarea unei poziții poate schimba opțiunile afișate. „Am închis tot” fără numele comenzii nu stabilește domeniul. Nici inversarea nu este închidere fără expunere: poate crea o poziție în direcția opusă.

Pe hedging, MT5 încearcă întâi Close By, apoi închiderea obișnuită a pozițiilor rămase. Eroarea din etapa secvențială Close By oprește procesul. În etapa ulterioară asincronă, o cerere respinsă lasă poziția ei deschisă, fără să oprească trimiterea cererilor pentru celelalte. Închiderea FIFO este și ea secvențială și se oprește la eroare. Nu generaliza comportamentul unei etape întregului proces.

Comenzile de grup cer One Click Trading, iar unele nu sunt disponibile pe conturile restricționate FIFO. Verifică modul contului și ACCOUNT_FIFO_CLOSE; aspectul terminalului nu stabilește setările. Sunt proprietăți ale contului concret, nu o regulă juridică mondială sau aplicabilă automat tuturor românilor.

Hedging explică pozițiile opuse separate față de poziția netting comună. Close By privește două poziții opuse ale aceluiași simbol. Numele asemănător al altui instrument nu îl face automat a doua parte a perechii. Pentru un script Close all citește instrucțiunile lui, fără să presupui echivalența cu meniul platformei.

Cum verifici cinci poziții după un clic?

Model diagnostic propriu: cont hedging fictiv, fără FIFO, cinci poziții, EUR/USD permite Close By. Nu există executări parțiale, intrări noi sau alte schimbări. Secvența descrie dependențe, nu viteza serverului. Modelul inițial nu calculează rezultat monetar și nu adună loturi din contracte diferite.

Pe un ecran mic, derulează tabelul orizontal pentru a citi toate coloanele.

După executarea A–B, numărul pozițiilor scade de la cinci la trei. Terminalul trimite apoi închiderile C/D/E fără să aștepte confirmarea fiecărei cereri precedente. C și E se închid, D este respinsă. Starea finală conține o poziție D: Sell USD/JPY de 0,10 lot. Trei cereri trimise nu dovedesc trei închideri executate.

Close By a eliminat două ticketuri printr-o operațiune; închiderile obișnuite au avut rezultate separate. Numără pozițiile curente și cantitatea confirmată, nu ferestrele mesajelor. Diagnosticul erorilor explică respingerea, dar citirea contului stabilește starea finală. Rezultatul necunoscut nu este același lucru cu respingerea confirmată.

Pentru fiecare ticket păstrează simbolul, direcția, cantitatea inițială, identificatorul cererii sau ordinului, răspunsul, executările și volumul rămas. Proprietățile executărilor leagă ordinul de poziție. Un ordin poate produce mai multe executări; un fragment nu dovedește închiderea completă. Ora include convenția și fusul serverului, fără conversie implicită în București.

Model RON: 80% din ticketuri nu înseamnă 80% din risc

Patru din cinci poziții inițiale s-au închis: 80% este procentul numărului lor. Nu cunoaștem din acel procent expunerile comparabile sau riscul monetar eliminat. Lotul de aur și lotul valutar nu sunt aceeași cantitate economică.

Extensie fictivă numai pentru D: contract liniar de 100 000 USD/lot, Sell 0,10 lot executat inițial la 149.80 JPY/USD. Presupunem Ask 150.00 la prima observație și 150.60 mai târziu, conversie constantă 0,030 RON/JPY, fără costuri. Nu sunt prețuri actuale sau o ofertă de cont RON. Pentru short folosim Ask, nu Bid, la evaluarea ieșirii ipotetice.

Pe un ecran mic, derulează tabelul orizontal pentru a citi toate coloanele.

Cantitatea D este 10 000 USD. Rezultatele sunt 10 000 × (149.80 − 150.00) = −2 000 JPY și 10 000 × (149.80 − 150.60) = −8 000 JPY. Schimbarea ulterioară este −6 000 JPY, adică −180 RON, deși numărul pozițiilor rămase este tot unu. Acestea sunt evaluări sau ieșiri presupuse, nu pierderi deja realizate și nici comisioane. Modelul nu prezice mișcarea și nu justifică o nouă cerere automată.

Eroare la început sau întrerupere mai târziu?

Variantă separată a stării inițiale: A–B primește eroare Close By înainte de executare; presupunem că nu a existat nicio executare de închidere. Secvența se oprește înaintea C/D/E și rămân cinci poziții. Este alt caz decât respingerea D după închiderea reușită a perechii. Într-un incident real, răspunsul lipsă cere investigație, nu presupunerea „nimic executat”.

Închiderea aplicației oprește procesul de grup, dar nu anulează executările confirmate. Dacă A–B s-a închis și cererile C/D/E încă nu fuseseră trimise, în acea variantă rămân trei poziții. Pentru cererile deja trimise identifică rezultatul serverului. Repornirea terminalului nu confirmă un cont fără expunere și nu trebuie să relanseze automat întregul lot din memorie.

Verifică dacă un EA, altă aplicație sau persoană a deschis poziții noi între timp. Un ticket nou nu trebuie să fie o închidere eșuată. Compară istoricul, inițiatorul și momentul. În automatizări MQL5, OrderSend=true nu dovedește executarea; citește rezultatul și evenimentele. Diagnosticul nu cere un ordin live de probă.

Lista goală de poziții încheie verificarea?

Inspectează și ordinele în așteptare. MT5 are operațiuni separate pentru ștergerea lor; închiderea pozițiilor nu confirmă anularea tuturor instrucțiunilor. Ordinul Buy fictiv P poate rămâne după închiderea celor cinci și poate crea ulterior o poziție nouă. Tipurile de ordine explică diferența dintre cererea de anulare și rezultatul ei confirmat.

După sincronizare citește contul corect fără filtre care ascund simboluri sau direcții. Reconciliază istoricul închiderilor și verifică separat instrucțiunile active. Descrie starea goală împreună cu ora și domeniul observației. Un screenshot nu dovedește că robotul nu poate recrea expunerea. Protecția pozițiilor rămase trebuie citită și ea: eșecul lotului inițial nu elimină riscul actual.

Ce verifici înainte să declari operațiunea încheiată?

1. Pe demo, înregistrează modul contului, denumirea exactă a comenzii și starea inițială cu ticketuri/volume. Nu testa deliberat respingeri pe bani reali.
2. Leagă fiecare poziție de rezultatul confirmat. Separă Close By de închiderea obișnuită, respingerea de răspunsul neclar și cantitatea trimisă de cea executată.
3. Verifică ambele liste, poziții și ordine în așteptare, fără filtre ascunse. Evaluează ce a rămas, păstrează starea finală și ora ei și abia apoi stabilește ce problemă mai necesită rezolvare.