I'm experiencing the following problems:

After staging an order via a chart, I place the order within the Order window. During the first few minutes in the morning no filled quantity information is returned at all. This occurs immediately following the market open. After I think about 5 min, filled quality information starts being returned, sometimes.

Since WLP appears not to have a real-time order status method, I find that the only way to known if an order ifs filled is to hit the refresh button. Unfortunate, filled quality information is only returned sometimes, this results in WLP becoming hopelessly out of sync. As such when you go to sell the shares you might of bought the wrong quantity information will appear in the order.

Let me give you example. I buy 2000 shares of XYZ, and when I hit the refresh no filled quantity information is returned. The then sell those 2000 shares. I then buy another 2000 shares sometime later. When I go to sell those shares 4000 shares will appear in the sell order. If a failed to edit the order down to 2000 shares and fire that sell order it will bounce and error out. I can not tell you how many times I've loss considerable amounts of money, since by the time I've edited the order to the correct number of shares, the price may have moved some distance. A 10 cent move down in the price is $200 of loss for example

Eugene: Moved from a different thread

boreland asked:


I've had enough with this poorly designed and supported product. Let me count the ways:

1. The current version times out so real time orders do not go through if you leave your PC for any period of time.

2. The previous version did not time out, but real time orders did not go through, or at least they sometimes went through, but mostly they did not.

3. The current version is a tad better, the buy orders mostly go through but the sell orders mostly do not. Pretty great hey!! A nice way to loose lots of money.

4. Both versions loose sync with your account, so if the shares being sold are not exactly whats in your account the sell orders, the few that go through, error out. It's a myth that they dynamically adjust to what you hold in your account. I posted a complaint about this several days ago, no response. I guess you know that this program is pretty hopeless as well.

This whole product is a mess. The new version runs slower that the previous version. Does anyone do any actual realtime live testing? How can it be this bad? Eugene and Cone do you have live trading account to test this thing? Do you have test scripts to test the live trading functionality to know it actually works reliably, or is it all just theory on your parts reading what supposed to happen from the user guide?

5. Oh one other thing. There seems be no way to get bid and ask data, some if you create stop orders, there is a good chance that these will error out as the stop price may be inside the bid/ask.

Hi Peter,

Sorry that you're having trouble with the product.

QUOTE:
2. The previous version did not time out, but real time orders did not go through, or at least they sometimes went through, but mostly they did not

Due to a recognized issue in your code? Order Alerts not going through to Staging Area

QUOTE:
This whole product is a mess. The new version runs slower that the previous version.

This is a generalization that doesn't even make sense to comment at this stage. This is simply not true unless something has gone wrong (like upgrade to .NET 4.6 made by Windows Update etc.)

I see you chose not to answer the many questions I raised above. I've created this simple test script below. The idea is you manually buy either the day before or in the pre-open and let the system exit the trade. Since WLP does not know what positions you hold you have to trick it into opening a position, so I do this at the open at the close of the first bar. Auto-trading is in the off position so the opening trades do not go through since you already hold these positions in your account. At the end of bar 2 you switch Auto-trading to live so the sell orders go through. How much do you want to bet that this simple setup will not work?

CODE:
Please log in to see this code.

Of the three securities I tested the above script two of the three fired off OK. The one that did not was RIG. The firstimage shows the results in the strategy monitor. Notice no trades appear in the trade column for RIG. Then sometime later trades started to show up in the trade column for RIG 500 samples, but on the next cycle they went back to zero again. Whats going on here?

Here are some more screen shots of the strategy monitor. Like I said in my rant above, the program is totally unpredictable.

What does it means when a strategy turns blue in the monitor? The scripts that fail turn blue while those to run stay black.

QUOTE:
I see you chose not to answer the many questions I raised above.

Sorry, I don't work with WLP. Cone may be able to assist you.

QUOTE:
Whats going on here?

Like zero trades, it's also unexpected to see two trades firing off (considering there's 390 bars in a session, there's a 80-bar seed period and you only load 500 bars) in the script that trades only once a day. It would help if you select your strategies, right-click on each, and choose "Enable logging for selected items".

QUOTE:
What does it means when a strategy turns blue in the monitor?

AFAIR, blue means "Time's up!" - data weren't returned in a minute interval.

P.S. Re: "++numBarsInTrade;". That's cumbersome. Simply use this in the exit logic:

CODE:
Please log in to see this code.

Additionally, the way you reset the variable unconditionally after BuyAtMarket would initialize it even if the trade wasn't taken due to insufficient capital. Here you have an out of sync condition due to an incorrect programming. So, just use the one-liner above.

I've noticed something else. The strategy monitor scripts enter into this red state, those that are red turn blue, where the number of trades resets to zero. I assume that if the script stays in the red state it has not run correctly as the number of trades stays at zero.

Some that are red turn black and some trades others stay red, others that were black stay red. In varies from minute to minute, please look at examples images and time stamps.

Hence my statement above about the platform being totally unreliable and a great way to loose money.

Please attach the logs as suggested. Although we aren't aware how many bugs are left there in your production (strategy) code, and this is our natural primary suspect, at least we'd be able to see what goes wrong in the SM. Thanks.

As requested

One quick question. In your unknown production code, are you continuing to use ChartRenderer or other objects unsupported in the SM context?

QUOTE:
2016-01-25 11:48:12,698 [1] ERROR WealthLabPro.ChartForm [(null)] - Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index

I'm just running the code above. There are scripts with this code in them but I'm not running any of them for this test. That,s an old log entry.

In the time that we have been talking and since I sent the log file, no new errors have been generated, but the SM problem highlighted in the above image still persist. Do you have contact with the developers? I just spoke with Fidelity to try to get something done about these issues and the fact that the platform order processing times out.

I read somewhere that the SM does not use streaming data. I assume it accesses the stored historical minute data. Could it be as simple as this data not being updated in time when the script runs?

QUOTE:
That,s an old log entry

Thanks but that's not what I'm asking you to do. That's the WLP log file, what I was asking for is the Strategy Monitor log.

Please select your strategies, right-click on each, and choose "Enable logging for selected items". Then run them until they malfunction, copy/paste the logs into text files, and attach. tia.

I've sent you two log files for sysmbol SDLP running in the SM.

The first file was generated after it worked for a bit then failed. The second one was captured after it started working again.

Thanks for the logs. Unlike the other 4 or so symbols, SDLP is an illiquid stock that may not have a single trade for many minutes during the doldrums period. This may have some connection.

We'll forward the logs to the developers. There's a number of records in the wlp.txt log they may find interesting, like:

QUOTE:
2016-03-23 20:04:37,432 [Runner0] ERROR Fidelity.Components.RequestManager.FidelityWebService [(null)] - Exception parsing XML Response
System.Xml.XPath.XPathException: Namespace prefix 'q1' is not defined.
...
2016-03-24 09:31:59,883 [40] ERROR Fidelity.Components.RequestManager.FidelityWebService [(null)] - Exception thrown while Making request
System.ArgumentException: Unknown value for Acct Type:
at Fidelity.Components.RequestManager.Cancel.MakeRequest()

QUOTE:
That,s an old log entry.

Yes but the error message repeats all the way to yesterday:
2016-03-24 07:36:04,337 [1] ERROR WealthLabPro.ChartForm [(null)]

QUOTE:
I read somewhere that the SM does not use streaming data.

Effective v6.x, Fidelity's streaming data is used by the SM.

The color coding for the SM is shown in the first image in the User Guide topic: Strategy Monitor > Strategy Pane. My eyes can't differentiate the Orange from Red, but Red is 'updating and executing' and Blue means that one or more symbols didn't receive updates in the allotted amount of time.

Anyway, let's try bullet-proofing the code do what you want it to do for "today" instead of relying on unknowable initial conditions. This script will initialize a long position on the last bar of the previous day and exit according to your exit rules.

Set the Test/Trade StrategyParameter as appropriate.
0 = Test for testing pre/post market.
1 = Trade when you want to run the script live for the current day.

CODE:
Please log in to see this code.

Cone many thanks for this. Unfortunately the markets here are closed today so will run it Monday. For those would might find this structure useful for their own trading I have also made a few changes. It's possible depending upon the exit rules for more than one sell order to fire causing the sell order to "error out", as I discovered yesterday:

CODE:
Please log in to see this code.

But why add the boolean b?

If any of the exit conditions are true, the hypothetical Position will be sold on the next bar and then IsLastPositionActive will be false. The boolean b is completely extraneous (it will never be tested as false).

Cone:

Great question. In real time testing I found that two conditions could be true and two sell orders would be generated, resulting in the sell order erroring out. Not necessarily the sell conditions as they are defined above, but what we use in our actual trading system. The bool ensures that only one of the sell orders can be triggered.

The "if / [then] / else" statement in my snippet took care of generating multiple alerts too (and it's more concise).

by boreland from https://www.wealth-lab.com/Forum/Posts/Fidelity-WLP-Orders-don-39-t-get-placed-properly-Stuck-Submitted-30938

QUOTE:
You can, however, synchronize to exit the entire position held in an account in Preferences (F12) > Trading.

Cone:
Perhaps we do not have this set up right. Lets say we buy 1000 shares, which we sell. If no sell info is returned, which happen very often, the next time we buy another 1000 shares, WLP will hypothetically try to sell 2000 shares. This order will error out?

QUOTE:
If no sell info is returned, which happen very often

I'm not aware of that problem, but it's hard to say what will happen if something in the system is malfunctioning. Nonetheless, it's a contrived example and I think the possibility of that particular scenario happening is low, and I'll tell you why...

First, the hypothetical shares from the script side will never be wrong. (Pause to let that sink in...)

Why? Because the script does not deal with shares. It exits a "Position". The Position has properties. One of those properties is the number of [hypothetical] Shares, which is based on the Position sizing you selected in WL Pro.

So, the Position.Shares in the Alert (in your example, this would be 1000) are sent to the Orders tool. The Orders tool checks to see if you checked the "Exit All" preference.

o If you didn't, the Order will be for the hypothetical number of shares (1000).

o If you did, the WLP Trade Manager checks the order's account destination. If that account owns shares for the Alert symbol, then the Orders tool updates the number of Alert shares to match the shares in your account.

Your example assumes that WLP missed the message from Fidelity's back end for the 1000 shares that were exited, but then assumes that the back end told WLP that the account owned 2000 shares, which it could not because it didn't own them.

That said, with the updates in 6.9.15 to the new trade server, we're aware that there are bugs that Fidelity needs to address. In the meantime, I suggest monitoring your Positions in AT Pro (or at fidelity.com) when trading with WL Pro. For example, "Stuck Submitted" orders can be treated as if they did not reach Fidelity, which you can verify and correct quickly in AT Pro. Aside from that, if you're using a Market order script, the possibility of getting out of sync with a live account is low as long as internet communication is stable.

I appreciated the detailed response but I'm not satisfied that WLP works the way you have outline above. Perhaps the answer is to uncheck the "Exit All" preference. You say my example is contrived but it's really not.

Lets say I have a strategy running in the background to execute a sell order based on a hypothetical share holding of 1000 shares (note I've previously gone long 1000 share prior to enabling autotrade). Previous to this, I 've been buying an selling the same instrument manually using the right click chart menu. Because there is a good chance fill information will not be returned on one of those manual trades, WLP will become out of sync with the account, and will think you hypothetically hold more shares than you do. Additionally the out of sync share count might arise because you get back partial fill information and not get confirmation that the remainder has been filled. In which case when the algorithm submits the sell order, it will submitted an order with more shares specified than you actually own. Such an order will error out. There is no dynamic adjustment as I think you imply from the above description.

QUOTE:
If you did, the WLP Trade Manager checks the order's account destination. If that account owns shares for the Alert symbol, then the Orders tool updates the number of Alert shares to match the shares in your account.

No it does not.

QUOTE:
WLP will become out of sync with the account, and will think you hypothetically hold more shares than you do.

This cannot happen. We need to talk in the same language or we're not going to understand each other.

As I explained, hypothetical means a scripted strategy. There is no synchronization whatsoever between the hypothetical (script) and the live account.

What we call "Portfolio Synch" comes later, after the hypothetical trade Alert reaches the Orders tool. Here, you're right. If you're using the "Exit All" option and Wealth-Lab does not have the account information for the shares you own, the adjustment to the order size for the account hold could be wrong.

However, in the case of your example, if WLP does not have the updated account information, it would not send an order for more shares than you own. (... unless possibly that you set the hypothetical Position Sizing for too many shares and WLP passed that size due to lack of account information... just supposing here.)

QUOTE:
No it does not.

We're aware that problems have been reported with logins and account data when using 6.9.15. If you don't need the 6.9.15 features (see New & Noteworthy in the User Guide), I suggest that you downgrade to 6.9.12.

Also as you suggested, you can try "Disable Portfolio Synch" and make sure that you set the correct number of shares in the Position Sizing tool that you hold in the account. For this it's best to use the Raw Profit mode and specify the number of shares.

QUOTE:
This cannot happen. We need to talk in the same language or we're not going to understand each other.

I'm sorry but it does perhaps I should make a video. As for 6.9.12 I've never managed to get a single autotrade script to run on this version.

QUOTE:
However, in the case of your example, if WLP does not have the updated account information, it would not send an order for more shares than you own. (... unless possibly that you set the hypothetical Position Sizing for too many shares and WLP passed that size due to lack of account information... just supposing here.)

Oh yes it does. Test it and see for yourself.

QUOTE:
make sure that you set the correct number of shares in the Position Sizing tool that you hold in the account

This is not practical. If I'm trading say 2000 shares lots as set in Position Sizing Tool for that symbol, I can not possible keep track of what WLP thinks I might be holding. That's the whole problem in a nutshell. Because WLP does not always get back the number of shares that might be sold it can become hopelessly out of sync for that symbol. How do you not know or understand about this problem and what I'm saying. I can not tell you how many times a day I miss the exit on a trade, because the sell order craps out, its costing be hundreds of dollars a day. I'm constantly having to reboot WLP. I do not have time to keep manually staging orders and manually adjusting the number of shares that I might be selling. Moreover, this problem negates using a algorithm to manage ones trades.

I've unchecked the exit all option. I'll see if this improves things. I'm hoping that will as it should only try to sell what is specified in the Position Sizing tool.