> On Oct 4, 2017, at 10:51 PM, Lincoln A Baxter <[email protected]> wrote: > > I am a BAC customer. > > This has been working for me for at least the last several years, ever > since I first set it up. > The last time I down loaded transactions was Sep 8. (successfully) > This email triggered me to try it this evening. > > I got exactly the same errors as those below. > > In the aqbanking setup, I changed the quicken emulation from no > selection to Quicken 2013 (which is the latest offered).
Please read Bill Starrs’ followup message where he describes the solution. As for the Quicken version, you can set the AppVer in aqbanking setup yourself to something recent enough to ensure that the existence of ClientUIDs is supported. Bill used 2600 for the QWIN version. > > Note that Quicken tends to desupport software 3 years after it is > released… That’s why you need to update AppVer, but it doesn’t take an aqbanking update to do it. > > It still did not work with exactly the same error. > I think everyone who was using BAC with the current GC is probably > screwed. When I called the bank, I got now help because this is not > quicken. I checked my version of aqbanking: > > # apt-get install -s aqbanking-tools > Reading package lists... Done > Building dependency tree > Reading state information... Done > aqbanking-tools is already the newest version (5.6.12-1+b1). > 0 upgraded, 0 newly installed, 0 to remove and 126 not upgraded. > > So it appears we not going to be downloading BAC transactions directly > into GC via aqbqnking for a while. I suspect quicken has changed the > software it is providing to the bank... and broken this interface. > > Sadly, I think it is going to take a update to aqbanking to fix this. Nope. This is between you and BAC software, and you can fix it. Chase made the same change two years ago on Thanksgiving day. There is an extensive thread about it. The trigger is that the bank has chosen to update their server software to insist on a ClientUID from Quicken connections (all versions of quicken that still support online connections now support ClientUIDs). The banks use a required second contact via logging into the web online account to verify that the attempted data download was legitimate. After confirmation, the bank stores the ‘verified’ ClientUID as an acceptable client for logging in. And you’ll be back to the same performance as before September. Aqbanking has supported ClientUIDs for something like ten years. > > :-( :-( > > I was able to download, and import an OFX file. Interestingly, > however, it did not recognize the account, and I had to select it even > though the routing number and account number it showed me in the import > dialog were correct. I suspect the OFX files have changed somewhat as > well, which might be consistent with Quicken being updated at BAC. Gnucash’s recognition of accounts for ofx data streams is separate between libofx imports and aqbanking connections. IIRC, that has always been the case. I think aqbanking used libofx many years ago, but no longer does. Or else it’s just that the account linking scheme used by Gnucash’s importing infrastructure kept the two data streams distinct. > > Lincoln > > BTW: I've decided since GnuCash has been removed from Debian stretch > --because it depends on desupported packages removed from stretch -- > (THIS IS VERY BAD), that I am not going to do any significant upgrades > until I absolutely have to. > -- Dave Reiser [email protected] _______________________________________________ gnucash-user mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
