ORDER_POSITION_ID - page 21

New comment
 
Mikalas:

...

But I wanted to implement it throughorders (it happens that a partially executed order "stands" for a couple or three days),

...

Michael, you were right! Why didn't you do it? You have to understand that when dealing with net positions, sooner or later you will be faced with the fact that you cannot do without analyzing the orders included in it. This is what I'm telling you as a person who has spent months studying this question, and has made this mistake many times:) And moreover, if you have more than one trading robot, you have to consider the contribution of each robot in the joint position, and you can't do without orders here as well. All the necessary information is available in orders and in deals based on them, and matting deals into a single net position on the contrary irreversibly deletes the information.

But if you base your system on the analysis of orders and deals, you should consider the partial execution of orders. To do this, you should create a virtual version of the order and control the arrival of new trades. My algorithm is as follows:

1. A new deal has been received (the counter HistoryDealsTotal() has changed).

2. If this deal is initiated by a certain order, we create a new order including a single deal (COrder* order = new Order(deal)).

3. Next, we search in our list of already existing virtual orders, for an order with the same identifier. If such order is found, then we merge the deals of the created order with the deals of the found one and update its properties, and delete the created order. If the same order is not yet in the list, we simply add it to the list.

In this way, the system becomes fully deterministic. With each new trade our virtual order will change its state, and it does not matter if the actual order is pending execution or has already been moved into the history, we will always see it in our system in the actually executed volume.

 
Contender:
And if we close the position, and the unexecuted part of the order is not removed, it will open (or change) another position?

Good question!

If the order is active, it is not in the history (this has been checked for sure),

And of course, an active order may open another position, but if

it will be partially executed again, we will not assign ORDER_POSITION_ID to it.

In otherwords,ORDER_POSITION_ID can only be seen in the history.

 
C-4:

Yes, it happens in the stock market and these situations have to be taken into account. This is one of the fundamental disadvantages of limit orders.

In your example I think we can replace it:

To:

As all buy and sell type trades are initiated by some kind of order.

No, you can't, because trades occur in clearing, but they don't have a ticket ( or rather ticket = 0 ),

but they have a price and a type (BUY and SELL) and of course IN and OUT :(

 
C-4:

Mikhail, and rightly so! Why haven't you implemented it? You have to understand that when dealing with net positions, sooner or later you will be faced with the fact that you cannot do without the analysis of the orders included in it. This is what I'm telling you as a person who has spent months studying this question, and has made this mistake many times:) And moreover, if you have more than one trading robot, you have to consider the contribution of each robot in the joint position, and you can't do without orders here as well. All the necessary information is present in orders and in deals based on them, and matting deals into a single net position on the contrary irreversibly deletes the information.

But if you base your system on the analysis of orders and deals, you should consider the partial execution of orders. To do this, you should create a virtual version of the order and control the arrival of new trades. My algorithm is as follows:

1. A new deal has been received (the counter HistoryDealsTotal() has changed).

2. If this deal is initiated by a certain order, we create a new order including a single deal (COrder* order = new Order(deal)).

3. Next, we search in our list of already existing virtual orders, for an order with the same identifier. If such order is found, then we merge the deals of the created order with the deals of the found one and update its properties, and delete the created order. If the same order is not yet in the list, we simply add it to the list.

In this way, the system becomes fully deterministic. The state of our virtual order will change with each new deal and it doesn't matter whether the actual order is pending execution or has already been moved into the history, we will always see it in our system in the actually executed volume.

Vasiliy, I implemented everything ( not as you did, but not bad either ), I just wanted to reduce the search time...
 
Serj_Che:

Problem solved, relations sorted out )

I have a related question:

It's very inconvenient to select an order by ticket to see its properties, because it doesn't matter where the order is in the history or in the market, and the ticket won't change.

So we have to search for the order both here and there.

Wouldn't it be easier to make as in MT4: if we select an order, it does not matter where it is located.

I have read it in MT4 Help:

What do you think about it?

P.S. I hope Mihail doesn't mind to continue this thread, so as not to produce more new ones?


Mikalas:

C-4, it's very nice that the discussion was constructive!

So, I need the "net" price of the position to know (in a month, for example) what my profit is.

...

In the function(I'm using it now):

...

Relevant question, in general the MetaTrader5 API is really quite low level. But ... Trading on the exchange has a lot of nuances: execution of order by multiple trades, matched trades into a net position and transferring it through clearing, an abundance of brokerage transactions and so on and so forth. So MetaTrader5 API (and MT5 itself) is such, as any exchange terminal should be.

Another matter is that its API can be wrapped in a high-level wrapper written in MQL5 and use through it the more low-level functions of MT5. If I had the wrapper, Mihail's task of profit calculation would look like this

for(int i = 0; i < TransactionsTotal(); i++)
{
    if(TransactionSelect(i, SELECT_BY_POS, MODE_TRADES))
    {
         ENUM_TRANS_TYPE trans_type = TransactionType();
         if(trans_type == TRANS_HEDGE_POSITION)
         {
              if(HedgePositionGetInteger(HEDGE_POSITION_MAGIC) != myMagic)continue;  // Работаем только со своими позициями.
              if(HedgePositionGetString(HEDGE_POSITION_SYMBOL) != Symbol())continue; // Работаем только с позициями на своем инструменте.
              double profit = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_POINTS); //Профит в пунктах
              double currency = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_CURRENCY); //Профит в валюте депозита.
              double price_open = HedgePositionGetDouble(HEDGE_POSITION_PRICE_OPEN); //Фактическая цена открытия позиции без клирингов и пр. изменений.
              double sl = HedgePositionGetDouble(HEDGE_POSITION_SL); //Узнаем уровень стоп-лосса позиции, если он есть, если нет - вернет нормализованный 0.0.
              if(HedgeOrderSelect(ORDER_SELECTED_INIT)) //Выбираем ордер, открывающий текущую позицию.
              {
                 int deals = HedgeOrderGetInteger(HEDGE_ORDER_DEALS_TOTAL); //Получаем количество сделок, открывающего ордера.
              }
              // Ну и так далее...
         }   
    }
}
 
Mikalas:

No, you can't, because trades happen in clearing, but they have no ticket ( or rather ticket = 0 ),

but have a price and a type (BUY and SELL) and of course IN and OUT :(

Shit, right:

Then sadness for you.

 
Mikalas:
Vasiliy, I implemented everything ( not as you did, but not bad either ), I just wanted to reduce the search time...
By the way, how do you deal with multidirectional entries of your robots? After all, the market entry of one Expert Advisor may be the exit of another robot.
 
Mikalas:

Good question!

If the order is active, it is not in the history (this has been checked for sure),

And of course, an active order may open another position, but if

it will be partially executed again, we will not assign ORDER_POSITION_ID to it.

In otherwords,ORDER_POSITION_ID can only be seen in the history.

There is another problem here. A part of the trades executed by this order will belong to one position, and the other part will already belong to the other, new position. Then the question is, what position identifier will be assigned to it, when it eventually gets to the history?
 
C-4:
By the way, how do you deal with multidirectional entries of your robots? After all, one Expert Advisor's entry into the market may be an exit from another robot's position.
I do not have any overlaps.
 
C-4:
The problem is different here. Part of the executed trades of this order will belong to one position, and the other part will already belong to another, new position. Then the question is, what position ID will be assigned to it when it sooner or later gets to the history?

A fully filled order, will receive the ID of the position it opened or changed.

But this will only be available ( ID ) in the history.

1...1415161718192021
New comment
Reason: