Re: Thoughts on payment handling in 1.4.x

["Chris Travers" <..hidden..>]

On 4/26/07, Gerald Chudyk <..hidden..> wrote:

> Are you planning total integration between accounting modules? I
> designed a gl like this once. The issues with ar and ap are fairly
> clear; each transaction is a db/cr to a few well defined gl accounts
> with a reference to customer/vendor id.

One of the goals is to normalize the accounting data so reporting is
easier and you don't have any potential data imbiguity issues.

The idea (as I currently understand it) would be to have at least the
following tables:
invoices
invoice_items
journal
journal_lines

Maybe more.  I am thinking that it would be best to have the secondary
transaction in the journal_lines table because one journal line should
have either 1 or 2 (but no more) transactions associated with it.  And
only one is a primary transaction.

> The problem is found in the number of ar transactions this creates and
> the inability to optimize modules for speed or size. Some modules,
> like oe will probably not do well; many oe activities are not needed
> in the gl until a sale is finalized.

Of course.  Not quite sure how OE will be handled yet.  But orders are
not financial transactions so would not appear in the general journal.

> This approach forces the gl to become more than a general ledger and
> instead becomes an itemized repository of every activity in the
> system. I think there is a better way to do this.

No, only financial transactions.  Non-financial-transaction items
(order entry, quotations, warehouses, pricematrix, contact management,
etc) fall outside this.  In essence the general journal does exactly
what it does in the paper accounting world-- acts as the first point
of entry for any financial transation.

Best Wishes,
Chris Travers