Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling extra fields #45

Open
euresti opened this issue Jun 27, 2018 · 3 comments
Open

Handling extra fields #45

euresti opened this issue Jun 27, 2018 · 3 comments

Comments

@euresti
Copy link
Contributor

euresti commented Jun 27, 2018

American Express returns some extra fields for certain calls. (e.g. <AMEX.CMNAME>JOHN SMITH</AMEX.CMNAME> inside of CCCLOSING. Is there any way to
a) Not have this error the entire parser
b) Include the extra values (assuming they are simple strings) somewhere?

@csingley
Copy link
Owner

models.base.Aggregate.groom() is intended as a hook to address (a). It's so far been done in an ad-hoc manner; for some examples see grep -A 5 INTU ~/Code/ofxtools/ofxtools/models/*.py .

Christ now AMEX is doing it too, and well down the tree too. It might be worthwhile moving this behavior up to the base class instead of subclasses.

(b) seems difficult to accomplish within the framework of models.base.Aggregate. I find it difficult to imagine that the information therein contained is very valuable - is it?

@euresti
Copy link
Contributor Author

euresti commented Jun 30, 2018

Section 2.7.1 Private Tag Extension does say that these tags are "valid"
Furthermore,

All tag names that do not contain a period (.) are reserved for use in future versions of the Open Financial Exchange specification.

So one could filter all tags containing . at the base level.

b does seem difficult. I was picturing some attribute private_tags on the Aggregate that would hold all of these. But if we don't know how to parse them it's a little complex to have them show up. I guess I could Monkeypatch the CCCLOSING with the attribute I want.

In particular I care about the AMEX.CMNAME because this is the only place that AMEX puts this.

@csingley
Copy link
Owner

csingley commented Jul 1, 2018

My guess is that AMEX has paid INTU a good chunk of coin to have Quicken do something useful with these undocumented tags. Or maybe vice versa.

What information is it that's contained in this field? Is that cardmember name? What is the intended use of this information?

I'm obviously not actively opposed to making ofxtools useful, but you can see how this kind of thing goes against the grain of some pretty fundamental architecture. Cost/benefit is the first thing I think about when considering inserting myself in the middle of some vendor circle jerk.

Keep in mind that, while it's an ugly solution, you can always get access to the OFX data in ElementTree format prior to running it through the type-conversion/validation system.

@csingley csingley closed this as completed Jul 1, 2018
@csingley csingley reopened this Jul 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants