Re: Thoughts on payment handling in 1.4.x

["Gerald Chudyk" <..hidden..>]

On 4/26/07, Chris Travers <..hidden..> wrote:
> Hi all;
>
> I have been thinking a great deal about the data organization of
> financial transactions for 1.4 even though we are not there yet.  I
> think we can all agree we need to have a central table which tracks
> every financial transaction and which other tables may join to.  I
> would propose that this table should be equivalent to the General
> Journal of paper-based accounting systems and it would replace the
> current gl table.
>
> In most cases, the journal table would be very similar in structure to
> the current GL table, but I have one question:  should we give
> payments their own journal entries?  I would think the answer would be
> yes, and then have a table which handles the many-many relationship
> between payment entries and other entries.
>
> What do other people think?
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.

A query to a specific customer in ar becomes a lookup in the gl
balance sheet ar account that contains all of the transactions for all
ar accounts.

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 changing a transaction in this environment will become
impossible, making auditors very happy and end-users looking for ways
around the system.

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.

If you are thinking more about journaling all transactions for audit
and recovery, then a group of tables, connected by time stamp, each
specific to a transaction type will probably be more efficient. A
single file with many transaction types becomes a nightmare for
everyone except cobol/rpg programmers who use isam files.

Gerald.