Tuesday, August 1, 2017

Patch / Update Available


Last Updated: 8/27/2017

Recent changes at Vanguard prompted another round of minor patches to the scripts, which can be downloaded @ https://sites.google.com/site/pocketsense/home/msmoneyfixp1/p2


Detail: Vanguard is now using session tokens (cookies).  There were a number of ways to handle it, but I chose to allow the first connection attempt to fail, and return the server-response cookie on the next attempt, thus using the same tokens as the server.  We could instead send a client token on the first pass, and skip the double-connect, but that requires an assumption re: expected server tokens.  The hope is that the chosen method will support changes at other banks, should they choose to use session keys, regardless of token names.

I must say, however, that I don't see the benefit of using session management, when it's a one-pass post/response transaction.  My guess is that they implemented (or upgraded) a general purpose service api, which happens to manage persistent sessions, by default.

21 comments:

  1. Thank you again, update works!

    Kale

    ReplyDelete
  2. Setting a timeOffset in sites.dat, such as
    timeOffset : -30

    gives an error "type object 'datetime.datetime' has no attribute 'timedelta'"

    A cure is to change "from datetime import datetime" to "from datetime import datetime, timedelta" and to change "datetime.timedelta(hours=h)" to "timedelta(hours=h)".

    I don't know why that is needed.

    CL





    ReplyDelete
    Replies
    1. What version of Python are you using?

      Delete
    2. Never mind... it's a bug introduced somewhere along the way. I replaced datetime.datetime calls w/ a datetime import. Missed the timedelta part, since I don't use it. Will fix.

      Delete
  3. Thanks for all the work you have done.
    There is an issue i am facing. I am using Google finance and not yahoo finance. If i check for quotes for symbol "BOM:500012", the result given is wrong i.e. i think it is multiplying the code itself i.e. 500012 * the day's price and giving wrong result. e.g. today's rate is 32.05 but getdata is returning like G: BOM:500012 16025384.6 8/24/2017 4:00pm

    ReplyDelete
    Replies
    1. I see the problem, and you're correct re: the multiplier. The scripts allow a multiplier option for each quote line, and is specified using a M:# parameter. The BOM: is being interpreted incorrectly, so I'll modify the script to handle it better.

      Delete
    2. Thanks. The update works fine now.

      Delete
  4. The scripts have been updated to address the two issues mentioned above.

    ReplyDelete
  5. I finally got my acct defined properly with USAA, at least it said it downloaded successfully. But I get this error message:OFXAdapter: Failed to parse request: Unable to parse a composite field "OFXRequest.OFXRequest": postTag "/OFX" not found. I can see no OFX data when I open the XFER file other than that msg. Any idea where I go from here?

    ReplyDelete
    Replies
    1. Just a guess here, but try explicitly setting ofxVer:102 in sites.dat for USAA. If that doesn't work, see if they support ofx 2.x (e.g., ofxVer:211).

      Delete
  6. No, that did not work. Msg: OFXAdapter: Failed to parse request: Unable to parse a composite field "OFXRequest.OFXRequest": postTag "/OFX" not found.
    I will ask them if they support 2.X

    ReplyDelete
    Replies
    1. I did a quick search and found another comment from long ago: "Apparently, with USAA, leading 0's in an account number are really necessary". Just a fyi, since many banks/sites require leading zeros be included w/ the account number (e.g., 00001987567).

      Delete
  7. Yes, I already knew that from my past experience with Quicken. I use two leading zero's. I also found that if I did not get the acct number correct, the error msg tells me that. But in this case, it says the data downloaded, even though I get the error msg above.

    ReplyDelete
  8. I have multiple accounts at USAA that are working, here's the USAA section from my sites.dat:

    SiteName : USAA
    AcctType : BASTMT #bank
    fiorg : USAA
    fid : 24591
    url : https://service2.usaa.com/ofx/OFXServlet
    bankid : 314074269
    brokerid :
    appid : QWIN
    appver : 1700
    mininterval:
    timeOffset :

    I also noted that usernames must be zero-padded to exactly 9 digits and account numbers must be zero-padded to exactly 10 digits.

    Hope that helps!

    ReplyDelete
  9. Thank you. That is for USAA Federal Savings Bank, I am trying to get it to work for USAA Investment Management Co. which uses different stuff. I did know that the user ID needed to be 9 digits with leading zeros. I wonder if I can dummy in the appid and appver?

    ReplyDelete


  10. LarryB, what is your sites.dat entry for USAA Investment Management Co?

    CL

    ReplyDelete
    Replies
    1. Name: USAA Investment Mgmt Co
      AcctType: INVSTMT
      fi: USAA
      Fid: 24592
      url: https://service2.usaa.com/ofx/OFXServlet
      brokerid USAA.com

      Delete
    2. Is that a copy/paste from the actual sites.dat file? Some field names aren't what's expected. Specifically: Name should be SiteName and fi should be FiOrg. Also, the colon is missing after brokerid.

      Delete
  11. It is not a cut/paste since it is on a different computer. It is all entered properly in the form on the sites.dat file

    ReplyDelete
  12. Hi Robert! Got a question. For accounts that use the same bank, how hard would it be to set it up to get all files on the same login session? I have just changed the password on BoA where I have multiple accounts. I forgot to change the password on PocketSense, so it issued an incorrect login multiple times... boom. BoA locked me out. My fault entirely, but it would be less likely to happen if only one login was used for all accounts in the bank.

    ReplyDelete
    Replies
    1. I'm pretty sure the OFX standard supports it, but ... the scripts are written w/ an explicit "one connection per statement" logic. I like the idea, but I'd need to think it through. I'm certain that it can't be done "as is", and that some core logic would need to be revamped. The nice thing about "one connection per request" is that each account is processed independently, and therefore no assumptions re "grouping by sign-on credentials".

      Delete