Phil,
> ---------- Forwarded message ---------- > From: Phil Longstaff <[email protected]> > To: devel gnucash <[email protected]> > Date: Sat, 14 May 2011 16:33:27 -0400 > Subject: Re: r20616-20630 (GncOwner) > On Thu, 2011-05-12 at 13:49 -0400, John Ralls wrote: > snip > This all sounds great and I'm wondering what the steps are. One > original idea behind KVP is that modules can be added to gnucash and can > associate data with the core objects. An example is a US tax data > module which associates an account with a line on a tax form. Should > this tax line become part of the Account record in the db? Might be OK > for US users, but what if a user from a different country needs more > information or different information. Do we want Account, and > USTaxAccount and OtherCountryTaxAccount derived from it? What about > other relationship types? > A different thought that has floated around deals with 'tagging' accounts (and perhaps, individual transactions, too) with values that correspond to one or more user-defined hierarchies (this has come up with reference to having a capability sort of like 'classes' within Quicken). This would be analogous to, and could share capabilities with, the existing hierarchy used for accounts but would function in parallel to it and would primarily drive reporting and searching capabilities, although it might have an impact on data entry and validation, too. I always thought that this approach could be generalized enough to be part of the core and fit into the restructuring/refactoring that is being talked about. Then, using this capability, in addition to user-defined hierarchies, there could be developer-defined hierarchies distributed with the system in cases where someone stepped up to initially set it up and maintain it. One of these would be a replacement for the existing KVP-based US Income Tax system (and possibly, that for Germany if someone volunteered to do it). Using the existing tax system(s) as guides, other volunteers could set them up and maintain them for other tax jurisdictions. Then we would have a system where users could use none, one, or more tax reporting capabilities at the same time, as there individual situation required. It would fit into a more generalized capability and wouldn't be an exclusive, either-or, location based system like we have now. > I think it would not be difficult to pull the info currently in slots > out of them and into better data structures which have their own tables. > They could be attached to the main core objects so that they load/save > at the same time but would be independent and in their own tables. Does > this idea help with your refactoring? > > Phil > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
