Tax Table Tracking

Derek Atkins warlord at MIT.EDU
Wed Dec 15 18:47:46 EST 2004


Hi,

Rich Johnson <rjohnson at dogstar-interactive.com> 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
       warlord at MIT.EDU                        PGP key available


More information about the gnucash-devel mailing list