Hi,
Rich Johnson <[EMAIL PROTECTED]> writes:
> I'm trying to get a handle on the TaxTable/BillTerm parent/child
> relationship; with an eye towards documenting it. What follows comes
>>From scanning the code and reading src/doc/business.txt.
>
> Looking at just Invoice and TaxTable for now, it appears that the
> invariants for these objects should include:
> - Posted invoice entries reference immutable child tax tables.
> - Unposted invoices entries reference mutable parent tax tables.
> - No more than one child tax table is created between modifications of
> the parent tax table.
> - Parent/child tree is <=2 levels deep. (no history of modification)
>
> The child tax table invariant includes:
> - referenced by >=1 posted invoice entries
> - immutable
> - child field is always NULL (no further children)
> - refcount field is 0
> - invisible field is TRUE
>
> The parent tax table invariant includes:
> - referenced by >=0 unposted invoice entries
> - mutable
> - parent field is always NULL (no further parents)
> - child field (when !NULL) references a child tax table with content
> identical to its parent.
> - child field NULL -> no referencing invoice entries posted since
> last tax table modification
> - child field !NULL -> at least one referencing invoice entry posted
> since last tax table modification
> - child field references most recently child, created when the
> first referencing invoice entrychild and then only if an invoice has
> been posted since the last modification to the tax table.
> - refcount field contains the sum of the unposted invoice entries
> and the posted invoice entries which reference the child field.
>
> - Modifying the TaxTable clears the child field and adjusts its
> refcount accordingly.
> - Posting an invoice causes its entries to be modified to reference a
> child tax table; that child is created as needed.
>
> FWIW, There are a lot of subtle implications to these invariants. I
> have noticed that _unposting_ invoices does not seem to maintain them.
> I'm not sure whether or not that's a bug--or if the invariants need
> adjusting.
>
> Comments? Corrections?
Sounds about right.
The only comment I have is that I wouldn't call them invariants, or,
at least, not everything you've labeled is an invariant. As you
noticed, unposting an invoice does not maintain them all. This is not
a bug. In HEAD the user has a choice to keep the taxtables or revert
them (this change has not been back-ported to 1.8).
Here's why this is not a bug: Assume you post an invoice on December
30th and the tax rate is 5%. Then on January 2nd you realize you've
made a mistake and need to unpost and repost the invoice. Howver on
January 1st the taxrate changed to 6%. Your invoice still needs to
use the 5% rates when you re-post it, so you want to continue using
the immutable children.
> Thanks,
> --rich
-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
