Position id switch because of partially filled order

 

Hi everyone,


I have a quite specific question about the POSITION_IDENTIFIER (PI) of a position in a certain case. But first a bit of information about what I found out so far. When an order opens a new position, the POSITION_TICKET (PT) and the PI are set to the ORDER_TICKET (OT) of this order. When a position is fully closed, the next position that is opened just again gets the PT and PI set to the OT of the order that opens it. In case of a directional change of the position (DEAL_ENTRY_INOUT type of deal), so from buy to sell or the other way around, the PI stays constant and only the PT changes to the OT of the order that caused the directional change. So far, so good.

My question now is, what will happen if an order is set to change the direction but it is not filled entirely but only partially and one of the partial deals that are connected to that order just happens to close the position entirely (instead of doing an INOUT), so that another following partial deal of the same order then opens a new position? Is it the same as stated above, so PI constant and PT = OT of the order? Or will the PI also change to the new OT? If it is case one, then that's all. But if it is case two, then I would also want to know, what will happen to the ORDER_POSITION_ID (OPI) of the order that causes it. Will it stay on the PI of the position that was closed or is it updated to the PI of the newly opened position?


Cheers, tandoori

 
tandoori_mql:

I have a quite specific question about the POSITION_IDENTIFIER (PI) of a position in a certain case. But first a bit of information about what I found out so far. When an order opens a new position, the POSITION_TICKET (PT) and the PI are set to the ORDER_TICKET (OT) of this order. When a position is fully closed, the next position that is opened just again gets the PT and PI set to the OT of the order that opens it. In case of a directional change of the position (DEAL_ENTRY_INOUT type of deal), so from buy to sell or the other way around, the PI stays constant and only the PT changes to the OT of the order that caused the directional change. So far, so good.

My question now is, what will happen if an order is set to change the direction but it is not filled entirely but only partially and one of the partial deals that are connected to that order just happens to close the position entirely (instead of doing an INOUT), so that another following partial deal of the same order then opens a new position? Is it the same as stated above, so PI constant and PT = OT of the order? Or will the PI also change to the new OT? If it is case one, then that's all. But if it is case two, then I would also want to know, what will happen to the ORDER_POSITION_ID (OPI) of the order that causes it. Will it stay on the PI of the position that was closed or is it updated to the PI of the newly opened position?

I did not test, but I think that every state when the open volume becomes 0 "closes" previous position ID and will use new PID next time. So this is not the case N1, but N2 in your enumeration. N1 would generate two positions with the same ID which is impossible.

The new PID will be acquired from the originating order (secondary filled part) which is generated by the trade server automatically behind the scenes. Please find more details here (original post in Russian is here - with logs, pictures, and other details - use automatic/built-in translation button for reading).

How do I identify a chart replacement?
How do I identify a chart replacement?
  • 2018.02.08
  • www.mql5.com
Forum on trading, automated trading systems and trading strategies testing. Zero chartid input parameter in some functions does not cause recalculation of values. True, i have not managed to find such a demo account, because there was a rule with asynchrony everywhere
 
Stanislav Korotky #:

I did not test, but I think that every state when the open volume becomes 0 "closes" previous position ID and will use new PID next time. So this is not the case N1, but N2 in your enumeration. N1 would generate two positions with the same ID which is impossible.

The new PID will be acquired from the originating order (secondary filled part) which is generated by the trade server automatically behind the scenes. Please find more details here (original post in Russian is here - with logs, pictures, and other details - use automatic/built-in translation button for reading).

The issue is further complicated by the fact that some broker-dealers' trade servers generate completely new transaction ID's for all Deals. Therefore, testing with the OP's specific broker-dealer will provide the answer.

Forum on trading, automated trading systems and testing trading strategies

Unable to identify which position is closed/mt5.history_deals_get

1057102143, 2023.12.20 04:41

I cannot see any matching identifiers for those deals ...all four were opened  positions before started closing any  one of them. But how can I retrieve those info via python or other alternative...when there is no common identifier..If I am missing some thig ..please notify..Thanks for your time,.

 
Ryan L Johnson #:

The issue is further complicated by the fact that some broker-dealers' trade servers generate completely new transaction ID's for all Deals. Therefore, testing with the OP's specific broker-dealer will provide the answer.

Nethertheless, I think all entities (orders, deals, positions) provide cross-references to bind them together for analysis. The "issue" you quoted can't be investigated because the OP (of the quoted topic) did not provide complete set of IDs.
 
Stanislav Korotky #:

I did not test, but I think that every state when the open volume becomes 0 "closes" previous position ID and will use new PID next time. So this is not the case N1, but N2 in your enumeration. N1 would generate two positions with the same ID which is impossible.

The new PID will be acquired from the originating order (secondary filled part) which is generated by the trade server automatically behind the scenes. Please find more details here (original post in Russian is here - with logs, pictures, and other details - use automatic/built-in translation button for reading).

Okay, so going from the forum post that you linked, it seems like for partial orders the terminal generates new market orders automatically and therefore when a position was earlier closed by the initial order that was partially filled and the remaining volume was then filled by the automatic order, then a new position is opened with the PI of the automatic orders OT. What a complicated way to solve this instead of just allowing multiple deals on one order (which is even described in the documentation).

So I could end up with a cascade of one initial order and some unrestrained amount of automatic orders that partially fill the remaining volume instead of just one order and a certain amount of deals that partially fill all volume and sum up to the order's volume. So basically one order that is partially filled in ten chunks will also spawn nine other automatic market orders?

Or does this "automatic market order" case only happen when a position is closed by a partial filling and all the other time we just have many (partial) deals that sum up to the volume of the initial order but without the automatic market orders?
Ryan L Johnson #:

The issue is further complicated by the fact that some broker-dealers' trade servers generate completely new transaction ID's for all Deals. Therefore, testing with the OP's specific broker-dealer will provide the answer.


But as far as I know every deal gets a new transaction ID anyways (titled DEAL_TICKET (DT) in the deal properties). So I don't get what you say here. Are you talking about the DEAL_EXTERNAL_ID (DEI)?

So we apparently agree that of the two described possible cases in my initial post, number two is happening. That's more complicated but also what I expected. And connecting that to my question about the OPI I would now think that the OPI of the initial order stays constant at the PI of the "old" position that was closed by the partial deal and the PI of the new position which is opened by the remaining partial deal is being put into the automatic market order's OPI. Do you agree?

Stanislav Korotky #:
Nethertheless, I think all entities (orders, deals, positions) provide cross-references to bind them together for analysis. The "issue" you quoted can't be investigated because the OP (of the quoted topic) did not provide complete set of IDs.

I don't understand which IDs you are talking about here, sorry.

Cheers, tandoori

 
tandoori_mql #:

Okay, so going from the forum post that you linked, it seems like for partial orders the terminal generates new market orders automatically and therefore when a position was earlier closed by the initial order that was partially filled and the remaining volume was then filled by the automatic order, then a new position is opened with the PI of the automatic orders OT. What a complicated way to solve this instead of just allowing multiple deals on one order (which is even described in the documentation).

So I could end up with a cascade of one initial order and some unrestrained amount of automatic orders that partially fill the remaining volume instead of just one order and a certain amount of deals that partially fill all volume and sum up to the order's volume. So basically one order that is partially filled in ten chunks will also spawn nine other automatic market orders?

Or does this "automatic market order" case only happen when a position is closed by a partial filling and all the other time we just have many (partial) deals that sum up to the volume of the initial order but without the automatic market orders?

So we apparently agree that of the two described possible cases in my initial post, number two is happening. That's more complicated but also what I expected. And connecting that to my question about the OPI I would now think that the OPI of the initial order stays constant at the PI of the "old" position that was closed by the partial deal and the PI of the new position which is opened by the remaining partial deal is being put into the automatic market order's OPI. Do you agree?

I think I can agree with your statements in general, but did not test it. The filling mechanism is the same for closing and opening positions - this is just about how orders are processed and generate or alter other stuff like deals and positions.

Please bear in mind that there is also ENUM_ORDER_TYPE_FILLING, which can be selected (if allowed by broker to choose from many options) and affect the filling.

 
tandoori_mql #:
But as far as I know every deal gets a new transaction ID anyways (titled DEAL_TICKET (DT) in the deal properties). So I don't get what you say here. Are you talking about the DEAL_EXTERNAL_ID (DEI)?

Truth be told, I live trade in a Netting account (I have to in the U.S.) but I've coded indicators that identify and track deals individually in a demo Hedge account. I also do some trading on a centralized exchange in MT5 which isn't as uniform as trading OTC forex/CDF's in MT5 in terms of handling of transaction ID's, exchange commissions, broker commissions, etc. This involves a custom gateway between the exchange and MT5. 

If you're trading OTC forex/CFD's, then dual ID's for Deals is the norm. You can use Position ID and Deal ID.

 
Stanislav Korotky #:

I think I can agree with your statements in general, but did not test it. The filling mechanism is the same for closing and opening positions - this is just about how orders are processed and generate or alter other stuff like deals and positions.

Please bear in mind that there is also ENUM_ORDER_TYPE_FILLING, which can be selected (if allowed by broker to choose from many options) and affect the filling.

Alright, then I take this as a given for now and code on. When something deviates at one point and I notice it, I will post it here to let you know. Does this thread auto-close at some point?
Ryan L Johnson #:

Truth be told, I live trade in a Netting account (I have to in the U.S.) but I've coded indicators that identify and track deals individually in a demo Hedge account. I also do some trading on a centralized exchange in MT5 which isn't as uniform as trading OTC forex/CDF's in MT5 in terms of handling of transaction ID's, exchange commissions, broker commissions, etc. This involves a custom gateway between the exchange and MT5. 

If you're trading OTC forex/CFD's, then dual ID's for Deals is the norm. You can use Position ID and Deal ID.

Okay, also thanks for the advice.


And one final thanks to both of you guys for the insights!

Cheers, tandoori

 
tandoori_mql #:
Does this thread auto-close at some point?
There is no auto-close for forum threads. You can write a new comment here at any time if you like.