I've examined IOrder objects using IHistory.getOrdersHistory(instrument, from, to)
and I am uncertain how to calculate the PNL.

Normally, when a position is closed using TP or SL then we have a PNL in PIPs given
by IOrder.getProfitLossInPips(), etc.

I tried an experiment in a LIVE account,
using PLACE_BID to fill using an amount X, and then used PLACE_OFFER to fill
using the same amount X, and then I MERGEd these two orders/positions.
Using IHistory.getOrdersHistory(...) returns 3 order representations related
to these operations.

All of these have status CLOSED.
One is the Long (PLACE_BID) fill, another is the Short (PLACE_OFFER) and the
third one is the Merged order label which I specified in the merge operation.

All three of these IOrder objects have IOrder.getProfitLossInPips() = 0.

How can I calculate the PNL from the orders fetched with IHistory.getOrdersHistory(...) ?

I assumed that at least one of them should show a PNL value, or is there some other
field I need to examine ?

Attached is a pretty image of what was done, and here are selected fields
from the 3 order objects involved fetched from IHistory.

// selected fields are left to right ; separated
CLOSETIME;LABEL;ORDER;INSTRUMENT;LOTSIZE;SIDE;PNLPIPS;PNL$;COMMISH$;STATE;OPENPRC;CLOSEPRC
// next is the Short position
2014-06-10 20:00;SOH_62_EURJPY_S_371;31889833;EURJPY;0.001;S;0.00;0.00;0.02;CLOSED;138.632;138.632
// next is the Long position
2014-06-10 20:00;SOH_62_EURJPY_L_370;31889821;EURJPY;0.001;L;0.00;0.00;0.02;CLOSED;138.614;138.614
// next is the Merged position
2014-06-10 20:00;SOH_62_EURJPY_L_373;31889956;EURJPY;0.0;L;0.00;0.00;0.0;CLOSED;138.623;138.623
// none of these has a PNL, except for zero

Thanks !
HyperScalper

Here's a better picture of the operations.

HyperScalper

According to this post, it is not possible at this time??

viewtopic.php?f=65&t=50983&p=78507&hilit=history+calculate+profit#p78507

HyperScalper

OK, so is this actually a bug? ...

Should the retrieved Merged-to Order show appropriate PNL details in the
case of equal, but opposite positions being merged?

And will this be fixed in next major API revision?

HyperScalper

Yes, as we have already replied in this topic:
viewtopic.php?f=65&t=50983

Concerning the API which does not currently fetch the
Merged-To order, here is what I see in a Live trade sequence.

Long and Short order sizes are 0.050 with PNL in pips and
PNL in $ shown as ZERO.

The Merged-To order contains "FM" as part of the label, which
indicates to me that it is FLAT as a result of a MERGE of two
equal Long/Short positions.

In my understanding, the "fix" for this will provide information
in the PNL fields, of the Merged-To order, which represents
the result of the "merge to flat" operation.

Commission$ Per Side is -0.12 and the Gross profit in Pips would
be 2.0 pips EUR/JPY which would appear in the Merged-To order?
So the Merged-To order would reflect -0.24 (both sides) commission?

For the Merged-To order IOrder.isLong() would have no meaning
because it represents the merged flat position, I suppose.

Is this the correct expectation when this is fixed in v3.x of the API ?

Please put this on your work-list for the next release.

HyperScalper

15:11:25 2014-06-18 15:08;SOH_36_EURJPY_S_423;32403447;EURJPY;0.005;S;0.00;0.00;0.12;-0.12;CLOSED;138.61;138.61
15:11:25 2014-06-18 15:08;SOH_36_EURJPY_L_424;32403448;EURJPY;0.005;L;0.00;0.00;0.12;-0.12;CLOSED;138.59;138.59
15:11:25 2014-06-18 15:08;SOH_36_EURJPY_FM_425;32411680;EURJPY;0.0;S;0.00;0.00;0.0;0.00;CLOSED;138.6;138.6 <-- Merged-To order

15:11:25 CLOSETIME;LABEL;ORDER;INSTRUMENT;LOTSIZE;SIDE;PNLPIPS;PNL$;COMMISH$;NETPFT$;STATE;OPENPRC;CLOSEPRC

Both commissions and P/L values get transferred to the merged-to position, meaning that for both merged-from positions those values will be zeroes.

I was pulling CLOSED orders from IHistory and
not getting the expected results.

My history orders were exclusively PLACE_BID Long
positions and PLACE_OFFER short positions
which were never closed; rather, they were
MERGED against each other...

Then I realized this is the BUG or "limitation"
that Merged Positions do not appear as CLOSED
and that this is being fixed. Mea culpa.

In which API version will this limitation
be fixed relating to MERGE operations?

Thanks,
HyperScalper

Hi Mr. Hyperscalper

I see that the strategies scalp on tick whether the robot is able to achieve such effectiveness like this
https://www.dukascopy.com/swiss/english/forex/jforex/forum/viewtopic.php?f=65&t=51502
in a month because I do not know whether to force myself to write on tick.

Thanks and Regards

First of all, in order to attempt to gain Price Advantage through liquidity
inside the spread, you must use the PLACE_BID and PLACE_OFFER API
order types. As these are "liquidity dependent" BackTesting is valid only if
reasonable liquidity assumptions are made in the backtesting, which is
always going to be difficult. Liquidity assumptions would need to be
"pessimistic" since Dukascopy Wholesale liquidity is limited, and Wholesale
fills require a lot of patience and finesse in the software.

I do not know, but I doubt, whether this level of control
is available through a MetaTrader bridge.

Secondly, your software must handle Partial Fills, and Merge operations and this
requires some specialized software in order to manage and "balance" the
Long and Short positions, plus Merge opportunities as trading progresses.

And, finally, Wide Spread so-called "minor crosses" would be the ones to benefit
most from Buying Best Bid and selling Best Offer. HOWEVER, liquidity can be
so extremely low that we are unable to anticipate fills and must very "patiently"
maintain our Best Bid and Best Offer orders INSIDE the spread in order to
take advantage of any Fills or Partial Fills which can occur.

In Currency Pairs which have narrower spreads, the significance of "making the spread"
is less, since the "spread penalty" is also less.

In summary, unless large Lot Sizes are used, and specialized software is available,
then this approach to gaining "price advantage" is not so significant.

OTHER factors in gaining overall "price advantage" include Cost Basis Averaging, in which
positions are entered Incrementally. When combined with ECN price advantage, along with
Incremental approaches, these two methods can complement and enhance your
profitability at Dukascopy.

As you can see it is a complex subject. But liquidity is the key here, and Wholesale ECN
liquidity at Dukascopy can be quite limited, since only Dukascopy Retail clients are counterparties
to your PLACE_BID and PLACE_OFFER order types, plus of course you must NOT CLOSE your
positions (as this is Retail). Rather, you must use MERGE to combine your Long and Short
positions together to benefit from this approach.

Hope this helps !! Good Trading !

HyperScalper

Hi,
I see that the topic is rather complicated, too much for me.
Thanks for the help.
Regards
zix

OK, now that we have API v2.11 in the platform I'm assuming
that we can calculate Profit and Loss from iterating over merged
and unmerged IHistory entries correctly.

So, API Support, can you say specifically how we should deal
with IHistory items from are "merged from" items so that we
do not consider them in the calculations.

Merged from items will have commission zero, and pnl zero,
but what is the proper test to identify them as "merged from"
order position items?

And, presumably, the "merged to" order will be dealt with
normally, containing the merged states?

Maybe it would be simpler to introduce a new order state
IOrder.State.CLOSED_BY_MERGE ? That way we would know to ignore those
positions in calculations of running pnl from orders IHistory?

I looked at the Merge workflow but couldn't see an answer
there. Here we show some of the properties of 5 orders fetched
from history as a result of Live executions.

The jfm2f5f1g order is a "merge to" of the 4 HBOT... orders. I see that
the size 0.0175 is the sum of the 4 HBOT sizes. But I'm wondering
for the HBOT... labels, what properties do I examine to know that
they are in fact the "merged from" positions, and the jfm2f5f1g is
in fact the "merged to" position ?

All of the items show a non-zero commission, but I thought the
"merged from" items should show a zero commission with
commission in the "merged to" item? (or the other way
around)

Maybe look into the Partial Fill history? Did that.
No, that doesn't contain useful information either.
THANKS for the guidance.

Order: [HBOT_EN_L1401]-Instrument: EUR/NZD, order command: BUY, amount: 0.0025, fill time: 2014-12-22 22:22:27:467, fill price 1.58241, close time: 2014-12-22 22:57:12:824, close price 1.58241
Order: [HBOT_EN_L1399]-Instrument: EUR/NZD, order command: BUY, amount: 0.005, fill time: 2014-12-22 21:32:50:274, fill price 1.58355, close time: 2014-12-22 22:57:12:824, close price 1.584552
Order: [HBOT_EN_L1398]-Instrument: EUR/NZD, order command: BUY, amount: 0.005, fill time: 2014-12-22 21:32:44:729, fill price 1.58356, close time: 2014-12-22 22:57:12:824, close price 1.584562
Order: [jfm2f5f1g]-Instrument: EUR/NZD, order command: BUY, amount: 0.0175, fill time: 2014-12-22 22:57:12:000, fill price 1.58418, close time: 2014-12-22 23:09:52:925, close price 1.58289
Order: [HBOT_EN_L1397]-Instrument: EUR/NZD, order command: BUY, amount: 0.005, fill time: 2014-12-22 21:26:19:877, fill price 1.58331, close time: 2014-12-22 22:57:12:823, close price 1.584312

Thanks!
HyperScalper

Does anybody know the answer to this question?
HyperScalper

Hi!

This is still missing feature. We are aware of the issue, but unfortunately we can't say when this feature will be implemented.