Greetings, I am running a simple inter day strategy on a equity basket that exits long positions at the highest high of the last 2 bars. I am running into a issue with Tradestation rejecting orders that strategy monitor is attempting to update on each poling run.
Example: position is long 100 shares of NKE with a existing sell order of 100 shares at the highest(high,2) when the strategy is run Tradestation rejects the new / updated order returning "order rejected you are long 100 shares 100 NKE remaining on sell orders".
From my understanding this behavior is inherent with Tradestation equites order entry . The brokerage will reject unmatched equites orders relative to the open position. I have tried checking wait for processing to complete in configuration this did not fix the issue. Also I am observing this error on 10-25% of orders placed / updated. Is there remedy for this issue?
Example: position is long 100 shares of NKE with a existing sell order of 100 shares at the highest(high,2) when the strategy is run Tradestation rejects the new / updated order returning "order rejected you are long 100 shares 100 NKE remaining on sell orders".
From my understanding this behavior is inherent with Tradestation equites order entry . The brokerage will reject unmatched equites orders relative to the open position. I have tried checking wait for processing to complete in configuration this did not fix the issue. Also I am observing this error on 10-25% of orders placed / updated. Is there remedy for this issue?
Rename
WL auto-trading won't update an order without cancelling the previous one, so there must be another order working that wasn't created by the strategy.
Do you enter another sell order for the shares manually, in WL or in TS?
Do you enter another sell order for the shares manually, in WL or in TS?
Nope, no other sell orders are entered for the symbols in question accept for the ones created by strategy monitor. Order rejection only occurs 10-25% of time. If I had to guess it seems as though Tradestation is receiving the new order before the prior order is canceling.
10 - 25% of the time, ok, I missed that. We'll see if we can duplicate that.
Excellent thanks!
You have "Use Live Positions" (ULP) enabled, right? That's the right way to go when trading a limit system, but I think I've identified the problem and why it occurs intermittently.
It takes the "Auto" out of "Auto-Trading", but right now you can only recover from this by canceling the live exit order at TradeStation.
I suspect it's a problem with other brokers too, but it may manifest in a different way. IB, for example will allow you to oversell the position in a margin account, and this would explain why you end up with an unexpected short position.
It takes the "Auto" out of "Auto-Trading", but right now you can only recover from this by canceling the live exit order at TradeStation.
I suspect it's a problem with other brokers too, but it may manifest in a different way. IB, for example will allow you to oversell the position in a margin account, and this would explain why you end up with an unexpected short position.
Thanks for the update. Yes live positions is enabled. Shouldn't be too difficult to write a cancel all script on tradestaion to execute just before SM sends the new order batch. It is interesting that this seems to occur more often in faster conditions and I wonder if it has to do with order server lag on the Tradestation side. ie cancel not complete but new order received. Anyways thanks for your assistance.
We'll get it fixed. There seems to be multiple scenarios, but in at least one of them its a bug keeping track of live orders when the backtester hypothetically thinks the position should have filled. In this case, Use Live Positions keeps WL in sync, but it Places a new order instead of RePlacing the existing one.
Excellent. In that case I can add some additional info.
1: Trade Manger on TS from a visual perspective does appear to clear all open orders for the data set before issuing new orders on each run. (this may be just visual)
2: Orders appear as modified rather than canceled. For example in the attached screen shot (HON) of TS trade manger the entered timestamp and the filled timestamp are longer in difference than what would be expected for a 30min strategy that cancels and then re-sends on each strategy monitor run. Suggesting a order update rather than a cancel.
3: Buy orders with no existing position update / are modified correctly.
4: The rejected sell orders are being issued at the correct price.
5: New positions issue the correct corresponding sell order as expected on the next run after a fill when no previous sell order was in place.
The attached screen shot is a little convoluted to decipher. However the (MCD) sell order issued at 0812 and the rejected orders at 0900 and 0930 is a good example of what is occurring.
1: Trade Manger on TS from a visual perspective does appear to clear all open orders for the data set before issuing new orders on each run. (this may be just visual)
2: Orders appear as modified rather than canceled. For example in the attached screen shot (HON) of TS trade manger the entered timestamp and the filled timestamp are longer in difference than what would be expected for a 30min strategy that cancels and then re-sends on each strategy monitor run. Suggesting a order update rather than a cancel.
3: Buy orders with no existing position update / are modified correctly.
4: The rejected sell orders are being issued at the correct price.
5: New positions issue the correct corresponding sell order as expected on the next run after a fill when no previous sell order was in place.
The attached screen shot is a little convoluted to decipher. However the (MCD) sell order issued at 0812 and the rejected orders at 0900 and 0930 is a good example of what is occurring.
I've been working this one pretty hard this week. Found a small bug, but the main problem was synchronization with the order response for edge cases while replacing orders in the multithreaded environment. After more testing we should have this wrapped up next week.
Your Response
Post
Edit Post
Login is required