-
Notifications
You must be signed in to change notification settings - Fork 68
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
Comments
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 |
Section 2.7.1 Private Tag Extension does say that these tags are "valid"
So one could filter all tags containing b does seem difficult. I was picturing some attribute In particular I care about the AMEX.CMNAME because this is the only place that AMEX puts this. |
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. |
American Express returns some extra fields for certain calls. (e.g.
<AMEX.CMNAME>JOHN SMITH</AMEX.CMNAME>
inside ofCCCLOSING
. Is there any way toa) Not have this error the entire parser
b) Include the extra values (assuming they are simple strings) somewhere?
The text was updated successfully, but these errors were encountered: