Gateway Time out

For the past 30 minutes we’re getting Gateway Time Out with the import trade function. Please help

Hi Brad,

We’ll look into this.

How many transactions are you trying to import at once? From an existing or new portfolio? How old is the oldest transaction you’re trying to import?

As a work around - you might try cutting the tran list in half and doing it in two steps.

thanks
ted

We were able to input 25 Trades or more last week. Today nothing…our attempt was approx 10’trades

Existing accounts that allowed trade inputs last week

Oldest trade was yesterday

This morning I tried it with just 5 trades. Nothing has changed it doesn’t work at all.

Gateway timed out

Its an existing account
An account that we uploaded 10 trades or more previously
The trades were made Monday.

Please fix this

I have the same problem and I think I know what triggers it:

It triggers when I import a transaction with a date different from the date that was set in the portfolio by pressing “commit” (i.e. the Monday if you rebalance on a Sunday).
If in real life you got a fill on a Tuesday and you want to update the date accordingly in by importing the trade → Gateway time-out

Without changing the date, I tried a different fill price and a different # of shares (for a buy order) → it does not trigger the bug.
Only a different date seems to trigger it.

Jerome

Jerome, are you saying that we need to change the date of the trade to the date we do the trade input?
Regardless I don’t think this function was ever really tested before being released as it very buggy and needs to be fixed.

Brad,

Let me be more detailed:

Before I started coding a text output file to copy paste into the ‘import’ tool, I decide to check how effective was the ‘update existing transactions’ feature. So I created today a fake live portfolio with all initial transactions today 01 July. That gave me a bunch of buy orders listed in /transactions/all and dated today 01 July

Then I played with the import tool (checking each time the box ‘update existing transactions’):

  • For a given stock, I tried importing a different number of shares traded than the system had listed in /transactions / all (e.g. 500 instead of 300)
  • For a given stock, I tried importing a different fill price than the system had listed in /transactions / all (e.g. $4.00 instead of $3.00)
    The 2 above worked and P123 correctly amended its transactions to reflect my imports of a different fill price and a different number of shares.

Then I tried changing the fill date to 30 June (yesterday) → I got the ‘Gateway Time out’ error

It would be worth checking if you can replicate the same problem and see if we can give the P123 guys a starting point to fix this bug.
(NB: of course, it could also come from the fact that the fake portfolio was created today 01 July and I am trying to put a buy transaction yesterday 30 June i.e. prior to portfolio creation. But I do not feel like messing around with a real port that has been live for some time)

The above typically replicates how I need to use the import tool i.e. rebalance and commit on a Sunday, execute the trades during the week and update the “committed” transactions to match my fill reality at the next week-end before rebalancing again.

I hope this helps

Jerome

Jerome, support contacted me earlier this morning and I think they said they had it fixed for one account but when I went to the next account it didn’t work.

But based on your last post

I changed the date of the transactions to today and checked “update existing transactions” and it failed with the Gateway timed out error.

Next I added the trades (31 to be exact) with todays date but I left “update existing transactions” unchecked and it worked.

Then, I cross referenced the P123 trade update with the broker holding page and they matched.

My next test was to keep the date unchanged 6/29/15 and not check off “update existing transactions” and it worked.

So it looks like the Update Existing Transactions is the issue but it appears it has no effect on the rebalanced portfolio as the P123 positions match the broker holdings.

This could be a detour till a solution is found.

Thanks
Brad

OP - you are correct the ‘Update Existing Transactions’ had a bug when some entered transactions didn’t previously exist. The fix should be live now.

Thanks for your input reporting the error.

ted

Voila! Thank you

Ted / Brad

Yes, but unless I am mistaken, there is one issue remaining → which is the one of updating the date of an existing transaction via import.

Case-study:

  • I rebalance once per week on Sunday. I click commit at the end of the rebalance. P123 records the transactions as occurring on Monday at open (I can’t remember now for sure but I think it uses the Friday close price for the fill price).
  • I place the corresponding orders via my brokers typically also on Sunday. I use limit orders not market orders or MOO.
  • On Monday, the majority of the orders are executed (situation A), but not all.
  • 1 or 2 per week get filled on Tuesday or Wednesday (situation B)

For situation A → using IMPORT and checking “Update existing transactions” will allow to amend the transactions on P123 with the correct fill price and commission. This works fine and is great.

However, for situation B → Using Import and checking “Update existing transactions” will not update the date of the existing transaction in P123 but will create a new P123 transaction with a different date forcing us to delete the old one (prior to or after using IMPORT). I just tried it several times.

In other words, what I would like is: be able to update an existing transaction in P123 from, say, the last 4 weeks (07/01/2015 IBM BUY 100 123.5 10.0) by the reality of my fill (07/02/2015 IBM BUY 99 125 5.0) [prices and commission numbers are totally made up!]

This example would be a “vicious” case i.e. the fill occurred on a different day (02 July instead of 01 July), at $125 instead of $123.5, with a different commission ($5.0 instead of $10) AND with a different number of shares (if small cap stock, I might not get all the shares I wanted at my limit price).

I thought about how to implement the logic using the check-box “Update existing transactions”. I think there will always be cases where it will not work correctly if there is a mixed bag of transactions to import (i.e. some which are just an update of a existing transactions already in P123 records and some that are really new transactions)

So, what about ditching the check-box and creating one more column allowing the user to inform the logic -transaction per transaction- as for whether it must do all it can to try to find a transaction to update or simply create a new one. I assume most of us generate the required import text file via code so adding 3 letters at the end of each line is not an issue (and will actually save manually putting a check in the box)
e.g.
07/02/2015 IBM BUY 99 125 5.0 UPD " Try to update the most recent transaction of IBM BUY
07/02/2015 IBM BUY 99 125 5.0 NEW " Create a new transaction

Logic then would be:
IF (last column value = “UPD”) then: in the existing list of P123 transactions, look for {a matching ticker} AND {matching direction buy or sell} AND {no more recent transaction in the opposite transaction for the same ticker}. Do the search by most recent first (very important!!).
If a match is found: amend date, # of shares, price and commission
Else: create a new transaction 07/02/2015 IBM BUY 99 125 5.0
IF (last column value = “NEW”) then: create a new transaction 07/02/2015 IBM BUY 99 125 5.0

This way, the user has the responsibility to indicate for each transaction whether they are trying to amend a transaction they ‘committed to’ at the last rebalance or simply import a completely new transaction

Comments and thoughts welcomed

Jerome

bump…

No promises, but I believe we’ll be making enhancements to the import transactions utility as part of an upcoming tool set being worked on.
It would make sense for the the utility to automatically resolve common issues such as this.
Worst case scenario, the utility would spit out an error telling you to add the transaction id to the problematic row.