r20616-20630 (GncOwner)

[J. Alex Aycinena]

Phil,


> ---------- Forwarded message ----------
> From: Phil Longstaff <plongstaff at rogers.com>
> To: devel gnucash <gnucash-devel at gnucash.org>
> 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
>