Wrong entry orders

Hello,
I have a system which gets its singals at the end of the day and make the entry regarding these signals at the opening of the follwoing day. There are three type of exits: a %profit stop, a technical indicator threshold value stop and a time stop.

I traded the signals of this system actively for the last couple of days. Sometimes I was confused because the signal history of the most recent day seemed to have changed sometimes the following day (e.g. another ticker was openend the day before than initially shown). I was confused by that and first thought that maybe something would be wrong with updating of the prices. After taking a closer look now, I have discovered that the system opens an already existing position at the opening if it is closed on the same day with the closing. This is obviously not correct, since this second position cannot be opened at the opening, because the real position of the ticker is closed only afterwards at the closing of this day and therefore no entry signal would be generated in reality for this ticker.

Now, I tried to handle this by deselect “Allow same bar exit / entry signal” in the backtester settings. But this is also not correct, because it happens sometimes that the postion is opened at the opening and closed during the day due to a profit stop (and that is suppossed to happen).

Can somebody help me to solve this issue…

Many thanks

are you able to provide an example showing results with what you had expected?

It is always due to incorrect settings. Please read this thread: Same Bar Exit and Limit Orders allowing too many open positions and follow the links from the guide that I gave there. The relevant part of the manual explains how to set things up properly. In short you need to make sure that settlement occurs on next bar (settlement delay = 1)

Thanks for your answers and sorry for my late response.

@Colydog:
e.g. t-2: At the end of day a buy-signal for BAC appears
t-1: BAC is bought at opening (and at the end of day the condition for a buy signal is again fullfilled)
t+0: At the end of day a sell-signal appears and BAC is closed at the end of day
t+1: When I run a backtest for looking for new buy-signals, another BAC-position is opened at the beginning of t+0 (which not really happened and since a sell-signal appears at the end of day, these false signals actually kind of peek and generate unrealistic performance results)

@Tomasz:
I (hopefully) read carefully the mentioned article. As far as I can see, what I want to program is not feasible in a pure array-style programming. Because my strategy would need more than one of the mentioned scenarios in the guide: There are situations when the strategy buys a ticker at the opening and closes it during or at the closing of the same day. Secondly, situations arise when for an open position, aonther buy signal appears, which would be (but should not) acted on if the position is closed on the same day (so it would be acted on only afterwards which is not correct).
You mentioned a settlement delay (e.g. of 1). I tried that and it did not solve the problem which I think is because I am testing on portfolio-level with a relatively large number of positions allowed, therefore there are often enough funds available in spite of the settlement delay for the closing positions. Would that explanation be correct?

So what probably would work is if I leave the pure-array-style programming path, e.g. using a for loop to go through every bar (like it is known from other backtesting programs). Nevertheless, I am wondering if it is not still possible somehow, to solve the case in the short, clean and fast array-style.
Is it possible to check for open positions on the day before. Then I could enter this into the buy-condition (like buyCriteria= existingOpenPosition==0 AND…)

Thanks again for the great help in this forum

General rule for array based code is one entry signal per bar per symbol, because given single array element x[ i ] can only hold ONE value. Trying to do multiple trades per single bar on single symbol requires low-level custom backtester. I always advocate against complex single-bar timing in portfolio backtesting. Such thing very rarely work in real life.