Hi @zilliq,

In http://this post  (and earlier in that topic), I essentially claim the same. But in there it is way more complicated to explain because that is about aggregated orders.
In the base the problem is already there as well, but it requires recognizing what the culprit actually is. But anyway, I noticed the same as you tell already years ago – possibly since I work with PRT. This is a bit hard to tell, because from the start I calculated my own spread-loss and then it is fine. Still, the figure entered in the Editor screen also does something, and the nice thing of your topic is that I now definitely know that this should be shut off (set to 0) all together. And this in itself never went into my too thick brain ! In other words, if you always have it at 0.6 (pips) it does something in consistency with your own programming. If you then change it to 0.8, things change, but the checking whether this changes correctly is cumbersome. So it really does something, but what it is … it beats me. It could be a factor of 10 off or so.

I have just been working on it (again) and I think I know how to solve it for myself. This should be something like setting it to 0 in the Editor’s screen, and next do it yourself throughout. But, in a fashion that you can get rid of that again with the flip of a switch/flag when PRT would be so kind to solve this (we would want it to be dynamic).

In the attachment you see the self-calculated spread of 38,64 at the top (orange) and the system-implied spread of 12.29 at the bottom (yellow). The 38.64 is correct (against the position) and the 12.29 makes no sense. This is for 0.8 pips in the Editor’s screen. Set the Editor to 0 and the 38,64 applies and I am in business. The system calculates 0 for spread indeed and you’re in control again. Now you can set your own spread to twice as low (0.4 in my example) and the 2nd attachment shows that truly (don’t look at the Profit in there because it currently is a tweaked job and the Spreads needs to be subtracted).

I am afraid I am not easily done with this yet, because all relates to what the system (PRT) subtracts for eaten spread. This is what my posts in that other topic are about – getting it consistent with a. what PRT reports in the backtests and b. make that in itself consistent with reality. I accomplished #a the other day, but quite explicitly killed reality with that because the calculated spread now was wrong. And to be vague once again (sorry for that) : now I calculate the spread right and my programs know what to accomplish (for say break even), PRT’s backtest fails on me because it won’t subtract spread and my shown results will be higher than reality will show me lateron.

You won’t believe it, but in PRT-IB I always “live” with the very same problem but with different source  : there we can perfectly work with commission (IB works with BrokerFee) but PRT forgets to show that in the results (Detailed Report and such). So there too the results show too high, but at least there I can do something like 500 trades times 60 of BrokerFee and subtract that from the total result I see. With spread this is a bit more complicated, but it could work out the same.
I have told this something like 100 times to local support as well as numerous times to 2nd line (Technical) support as well for the IB side of things. Throughout the years nobody is doing anything about this and regarding such (crucial) matters, PRT support virtually does not exist indeed.

The most essential thing of all is that your program knows where break-even is. So in the last example (2nd attachment) this would be when I have a gain of + 19,32. I am not sure yet what the Detailed Report will show, but most probably 19,32 profit, while in reality it is zero.

zilliq, thank you. You kind of forced me to work this out to something which will really work for me. All (servo) mechanisms will start to work like reality (Live) works too (apart for spread differences but this is a matter of defining spread on the high side and hope your system can still make something of it (profitable trades)).
Subtracting e.g. 8 euros on the 100.000 of position times the number of trades, is easy to do and is a linear thing. So for example, see 3rd attachment. Gain is 1915 there and position is 480.000. Spread is 0.8 or 8 on the 100.000. Thus 4.4 * 8 = 35,20 (attachment 1 shows 38,64). This times 20 because of 20 trades = 704. Thus the real result will be 1915-704 = 1211.
This is fine for me. But  do notice that each time I would show you a result, I always need to tell you “but this is without spread” and nobody will understand. Profit on individual trades I also can’t show without context because they are all too high. See 4th attachment. Each result in there is 35,20 too high now.

What we also could try is finding the spread number for the Editor which resembles reality (I mean, maybe that 2.5 (etc.) implies a reality of 0.8).

image_2022-01-02_071212.png image_2022-01-02_072612.png image_2022-01-02_075255.png image_2022-01-02_075330.png