Handling extra fields

[euresti]

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]

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]

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]

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.