Looks like ofxget is a no-go too. One peculiarity that I have with this Amex account is that it is a company credit card - one that I am responsible to pay prior to being reimbursed by my employer. For this reason, and for help in creating my expense report, I like to track it with my personal accounts. Being a corporate card, it doesn't go through the normal American Express site. I log on to something called netservice - which has moved to "centresuite". I think this has something to do with integration into SAP for corporate accounting. Anyway, my credentials for the netservice site don't work with the amex ofxhome definition, and I think the whole API process might be different with the netservice site.
This might be too far "in the weeds" for this group and the main mission of Beancount. However, I'll try to pursue it a little further to see if there's an OFX server available for this account and try to continue on the ofx path. It is much cleaner than csv which in turn is easier than pdf extraction. Someone noted in another thread that ofx is being retired in many places. I hope that's not true! On Friday, November 12, 2021 at 11:12:43 AM UTC-5 [email protected] wrote: > Thank you for your help, RedS > > As a first step. I tried to modify copy your Disvcover --as well as the > exisiting Amex -- importer, switing the ofxreader with csvreader. I also > kept all of my mapping declarations going from csv "fields" to beancount > narrative fields. > I wasn't able to get that to work quite right. I did finally bring over > def file_account(self, _): > return self.config['main_account'] > ...and it finally worked. However, I then get an error from bean-file: > unexpected error: 'AmexCCImporter' object has no attribute 'file_read_done' > > *This error is captured and the csv file is moved to the right place.* The > error might have been a bigger problem if I hadn't already "ingested" the > file into my beancount ledger. > > But just to dig in a little further... > file_read_done is defined in ...reds_importers.libreader.csvreader. So, I > don't know why the stack is trying to retrieve this value from > 'AmexCCImporter'. > > > I am working on the ofxget implementation next - will post results when I > have them. If successful, it will sort of nullify this other effort, but I > did learn something! > > P.S. I don't know what's going on with the Times/Serif font in the middle > of this post. I couldn't change that back to the normal Sans Serif text. > On Thursday, November 11, 2021 at 2:03:42 AM UTC-5 [email protected] > wrote: > >> Hello Tim, >> That method is in beancount_reds_importers/libreader/reader.py, see here >> <https://github.com/redstreet/beancount_reds_importers/blob/51597c8ca0bc7dba913267a52ea241e538bc1097/beancount_reds_importers/libreader/reader.py#L23>. >> >> If you imported the class correctly, that error should not occur: >> >> class AmexCCImporter(banking.Importer, csvreader.Importer): >> def custom_init(self): >> # blah blah: Look at discover/__init__.py and replace ofxreader with >> csvreader. >> >> Let me know if that worked. >> But the more interesting answer to your question is: have you setup direct >> downloads >> <https://reds-rants.netlify.app/personal-finance/direct-downloads/> (vs >> logging in via a browser)? If so, you'll get ofx from Amex, all from the >> command line that you can stick into a script. I checked my Amex two >> minutes ago, works fine and dandy: >> >> ofxget stmt --nokeyring -u yourusername --password $(pass >> beancount/amex_card) amex -c 'CODECODE|last5' > ~/Downloads/amex_card.ofx >> >> There's a one-time step to get your unique CODECODE, and I forget how >> it's done, but it's a pretty simple, single step IIRC, using ofxget. Post >> here if you're unable to get your code, and I'll try to dig up what I did. >> >> RedS. >> >> On Wednesday, November 10, 2021 at 11:57:23 AM UTC-8 [email protected] >> wrote: >> >>> Additional information: Here is my __init__ >>> >>> class AmexCCImporter(importer.ImporterProtocol): >>> def __init__(self, account, lastfour): >>> self.account = account >>> self.lastfour = lastfour >>> The account does come through in the transaction narrative that is >>> generated. However, it's not picked up by the file.py routine. >>> On Wednesday, November 10, 2021 at 2:44:46 PM UTC-5 [email protected] >>> wrote: >>> >>>> Hi, >>>> I've previously relied very heavily on *red's importers* for my import >>>> and filing needs. They worked great up to the point when my Amex switched >>>> over from ofx to csv's -- the only options for statement/transaction >>>> downloads are excel, csv, and pdf. >>>> >>>> I think I have a working importer for the new Amex csv's, but when I >>>> attempt to archive via bean-file, I receive the error: >>>> ERROR:root:No account provided by importers: <<object.class of my >>>> importer>> >>>> >>>> I think I'm missing a "return account" statement or similar but can't >>>> quite figure it out from the docs or red's other importers. I'm sure >>>> it's there but can't identify it. >>>> >>>> Thanks for reading (and I hope answering), >>>> Tim >>>> >>> -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/cd051404-2321-4e28-b415-048cacb48aa4n%40googlegroups.com.
