[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: Outline of financial table schema for 1.4



On 11/13/07, Chris Travers <..hidden..> wrote:
> On Nov 13, 2007 4:59 AM, Isak Hansen <..hidden..> wrote:
> > On 11/9/07, Chris Travers <..hidden..> wrote:
> >
> > > journal replaces gl and transactions and also is the base table for
> > > all transactions:
> > > create table journal (
> > > source text not null,  -- invoice number or source document number
> > > id serial not null,
> > > description text not null,
> > > locked_by int references session(id) on delete set null, -- used for
> > > batch locking of transactions for long payment workloads
> > > entry_type int references journal_entry_type(id),
> > > transaction_date date not null default now(),
> >
> > Transaction date enough, or add a field for accounting date as well?
>

Just to qualify my previous statement before you act on it. ;) -- My
accounting-fu is *weak*, the accountants around here don't use English
terms, and I suspect them of thinking in terms of how our current
software works rather than what they really want/need.

Anyways, here is my current understanding/interpretation, feel free to
clear things up:
"transaction date" === "document date" === "effective date"? -- I read
this as the day a transaction actually occurs; just a piece of fact
which isn't that relevant to the books, but could be of use when
'real' numbers are desired.

"accounting date" === "posting date"? -- The date a transaction is
recognized by ('takes effect' in) the books.

"entry date" -- Date an entry is registered?


> Maybe "entered_on date, posted_on date"?
>

As noted above, I'm somewhat confused when it comes to accounting
terminology and requirements.


> > We need to collect several orders in a single invoice. I imagine
> > multiple invoices per order could be useful as well, even if that's
> > not a requirement for me.
>
> *snip*
> It might be better to
> have a separate mapping of line items to orders and invoices (and this
> might make COGS handling easier too).
>

Sounds good.

But I could always tack something like this on top as a customization
if it adds more complexity than value.


Regards,
Isak

> Best Wishes,
> Chris Travers
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>