Thanks. I think this will work for me. The only situation I can think of where it is not correct at the commodity level is defining asset classes that incorporate a tax hedge strategy (i.e. tax deferred Lg Cap vs. tax immediate Lg Cap).
Tax policy balancing is rare but not unheard of in terms of a balanced portfolio. I think the KVP at the commodity level is good enough. As I mentioned earlier, I think I'll abandon my tree and try again from scratch with a recent SVN copy. -Jon. ---- Derek Atkins <[EMAIL PROTECTED]> wrote: > Derek Atkins <[EMAIL PROTECTED]> writes: > > >> Given that not many people are using it yet, I would like to work out > >> a way to implement this functionality in the upstream if possible. > >> It need not be compatible with what I have. Would it be a reasonable > >> comprimise to add some kind of "misc" field(s) in the XML format for > >> purposes similar to this? In that way, we could achieve > >> compatibility and flexibility in one fell swoop. > > > > Well, I would store it in the KVP, sort of how transaction notes > > are stored in the KVP. But as I said earlier I think this particular > > data should live with the commodity, and unfortunately I dont think the > > current data file actually stores the Commodity KVP Frame, so it would > > be problematic to put it there right now without making changes to the > > XML code. > > For the record, I just committed code to Trunk that saves the > commodity kvp-frame.. > > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
