ORDER_POSITION_ID - page 20

 
Mikalas:
You have the internet, don't you? The internet does :)
Nein. Only official statistics. Only legitimate tax reports, so the internet is no help in our area. No, it's not.
 
barabashkakvn:
Nein. Only official statistics. Only legitimate tax reports, so the internet is no help in our area. Nein.

It is written in the sleeper, however, thatPOSITION_IDENTIFIER does not change throughout her life.

Isn't that enough?

 
Mikalas:

It is written in the sleeper, however, thatPOSITION_IDENTIFIER does not change throughout her life.

Isn't that enough?

Help - that I know:2

I asked for examples from life, from stock trading:

Forum on trading, automated trading systems and testing trading strategies

ORDER_POSITION_ID

barabashkakvn, 2014.09.01 19:39

It's a pity I closed my account with the broker. Does anyone have a trading history that will clearly show how the clearing is going?

 
barabashkakvn:

Help - I know that:

I asked for examples from life, from stock trading:


Got it....
 

I deliberately looked into the matter and apologised for the incorrect statements. As it turned out, the truth was in the middle. It is true that a position exists from the start to the end of its close, with its identifier and basic properties remaining unchanged, whether it has been moved through clearing or not. However, the opening price of the position does change. The position calculation itself is exactly as shown in my previous post, i.e. from one clearing to another the accumulated profit/loss from an open position is calculated and this result is credited to the account using special brokerage operations (trades). These trades are marked with comments "[variation margin open]" and "[variation margin close]".

Here is the comment of an Otkritie's employee, which describes this process very accurately:

Forum on trading, automated trading systems and testing trading strategies

MT5 Trading: Errors, Bugs, Questions.

OpenBroker, 2013.02.26 09:59

I want to add here, in my opinion, an important observation, so that it can be taken into account when planning your Expert Advisors.

On FORTS, there are two clearing sessions a day: Intermediate (from 14:00 to 14:03 Moscow time) and Main (from 18:45 to 19:00 Moscow time (or 19:10 on days when contracts expire)).

For reference, clearing - is an accounting of mutual settlements, in Russian, it is the moment of fixation of profits/losses on open/closed positions between clearing sessions.

What is actually important. What is important is that at the time of clearing, the Settlement Price is fixed. That is, the price of the last trade of the past trading period. In terms of mathematics, an open position is "sort of" closed and opened at the Settlement Price (of course, no additional commission is charged by either the broker or the exchange for that).

Thus, if you have opened a position before the next clearing and stayed with it at the time of clearing, then you have a change in MT5 to the opening price of that position. And if, say, you have a "trailing stop" in pips, then it will be counted from the clearing price, and not from the price of your trade.

For example, Si-03.13 contract was bought at 11:00 Moscow time with price 30500. A trailing stop equal to 50 pips is set. By 2:00 PM Moscow time, the position is not closed. The settlement price of the Intermediate Clearing was 30525. (i.e., your account was actually cleared with (+25) rubles from each purchased contract). Starting at 14:03 Moscow time, MT5 will calculate a trailing stop on the price of 30525 (and not on the actual price of the trade you made - 30500).

By the way, such a rollover position is practiced not only on FORTS, but also in some forex companies. As I see it, whether only the entry price of a position will be changed or a new position will be created depends on the rules of the company.

Скажите, пожалуйста как именно происходит перенос позиций через ночь?
Почему именно происходит переоткрытие позиции с новой ценой ордера, а не с той же ценой?
Насколько я понимаю, переоткрытие с новой ценой ордера это ролловер (rollover).
Перенос позиции через ночь с той же ценой это своп и как бы долго позиция не удерживалась, цена ордера останется той же. Верно ??
Если так, то в ВТБ своп не применяется?
Или я в чём то ошибаюсь, расскажите..

A currency swap is an operation consisting of two opposite conversion transactions for the same amount of traded currency with different value dates and exchange rates. A tom/next swap means two conversion transactions, the first of which is settled on the value date "tom", i.e. the first business day after the transaction date, excluding weekends and public holidays, and the opposite one - on the spot date.
If, by 01:00 Moscow time on the day following the date of the transaction, the position opened by the Customer is not closed, the Bank shall independently transfer the position to the next business day by performing a "tom/next" currency swap. In doing so, it shall close the existing position on the value date and simultaneously re-open it on the next value date.
The provisions of this paragraph shall be regarded by the Parties as an irrevocable Customer's request to enter into a currency swap transaction with the Bank in the case described in the preceding paragraph, under the following conditions
-the base currency and countercurrency of the swap correspond to the base currency and the countercurrency of the open position,
-the rate of the first swap transaction is equal to the current market rate at the moment of swap execution
-the rate of the second swap transaction is equal to the rate of the first swap transaction adjusted by the value of the current market swap points (positive or negative difference between the market "tom" and "spot" rates)
-the value date of the first swap transaction is the "tom" date,
-the value date of the second swap transaction is the "spot" date.


Перенос позиции через ночь, как это работает ?? : ВТБ24
  • www.onlinebroker.ru
Валютный своп - операция, состоящая из двух противоположных конверсионных сделок на одинаковую сумму торгуемой валюты с разными датами валютирования и разными обменными курсами. Своп типа “tom/next“ (том/некст) означает проведение двух конверсионных сделок, расчеты по первой из которых осуществляются на дату валютирования “том“ (tom), то есть...
 

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

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

ByPOSITION_IDENTIFIER(as it is implemented in my position), you can see the history of incoming trades of the current position.

But I wanted to implement it throughorders (sometimes a partially executed order "remains" for two or three days),

because the order has ORDER_POSITION_ID, which is the same as

andPOSITION_IDENTIFIER, but the order has the same thing.

In the function (I am using it now):

//+------------------------------------------------------------------+
//| Expert Get history price function                                |
//+------------------------------------------------------------------+
double GetHistoryPrice( const string aSymbol )
{
  double price_in = 0;
  double volume_in = 0;
  
  if ( PositionSelect( aSymbol ) )
  {
    long pos_id = long( PositionGetInteger( POSITION_IDENTIFIER ) );
    
    if ( pos_id > 0 )
    {
      if ( HistorySelectByPosition( ulong( pos_id ) ) )
      {
        int deals = HistoryDealsTotal();
      
        for( int i = 0; i < deals; i++ )
        {
          ulong deal_ticket = HistoryDealGetTicket( i );
          ulong order_ticket = ulong( HistoryDealGetInteger( deal_ticket, DEAL_ORDER ) );
        
          if ( order_ticket > 0 )
          {
            ENUM_DEAL_ENTRY deal_entry = ENUM_DEAL_ENTRY( HistoryDealGetInteger( deal_ticket, DEAL_ENTRY ) );
              
            if ( deal_entry == DEAL_ENTRY_IN )
            {
              double price = HistoryDealGetDouble( deal_ticket, DEAL_PRICE );
              double volume = HistoryDealGetDouble( deal_ticket, DEAL_VOLUME );
                                
              price_in = price_in + price * volume;
              volume_in = volume_in + volume;  
            }
          }  
        }
        if ( volume_in > 0 ) return( NormalizeDouble( price_in / volume_in, _Digits ) );
      }
      else
      {
        Print( "Не возможно получить историю позиции по символу ", aSymbol );
      }
    }
    else
    {
      Print( "Не возможно определить идентификатор позиции по символу ", aSymbol );
    }
  }
  return( 0 );
}

we still refer to the order ticket(order_ticket),

on the basis of which the transaction was made (i.e. we cannot do without an ORDER ticket).

I thought that even if the order was partially executed

But I was wrong.ORDER_POSITION_ID is assigned to it.

is assigned ONLY to the order which has been completely executed.

 

Mikalas:

I thought that even when an order is partially executed

TheORDER_POSITION_ID is assigned to the order, but I was wrong.

is assigned to a fully executed order.

And if the unexecuted part of the order is removed, then the ID appears?
 
Dima_S:
And if the unexecuted part of the order is removed, the ID appears?
Yes, but already in the history...
 
Mikalas:
Yes, but already in history...
What if the position is closed and the unexecuted part of the order is not removed and it opens (or changes) already another position?
 
Mikalas:

But I wanted to implement this through orders (I happen to have a partially executed order "standing" for a couple or three days),

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.

Mikalas:

...

we still refer to the order ticket(order_ticket),

which was used to execute the trade (i.e., we need the ORDER ticket).

...

In your example, I think we can replace it:

ulong order_ticket = ulong( HistoryDealGetInteger( deal_ticket, DEAL_ORDER ) );

To:

int deals = HistoryDealsTotal();
for( int i = 0; i < deals; i++ )
{
   ulong deal_ticket = HistoryDealGetTicket(i);
   ENUM_DEAL_TYPE type = (ENUM_DEAL_TYPE)HistoryDealGetInteger(deal_ticket, DEAL_TYPE);
   ENUM_DEAL_ENTRY entry = (ENUM_DEAL_ENTRY)HistoryDealGetInteger(deal_ticket, DEAL_ENTRY);
   if((type == DEAL_TYPE_BUY || type == DEAL_TYPE_SELL) && entry = DEAL_ENTRY_IN)
   {
      double price = HistoryDealGetDouble( deal_ticket, DEAL_PRICE );
      double volume = HistoryDealGetDouble( deal_ticket, DEAL_VOLUME );                       
      price_in = price_in + price * volume;
      volume_in = volume_in + volume; 
   }
}

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

Reason: