On Thu, 5 Mar 2009 09:35:46 -0600, Alan Cohen
wrote:
>What you have laid out as a schema might me a bare minimum for most
>purposes. I've spent most of the last 30 years configuring and implementing
>financial systems, mostly General Ledger for a variety of clients and
>developers. Here are the
What you have laid out as a schema might me a bare minimum for most
purposes. I've spent most of the last 30 years configuring and implementing
financial systems, mostly General Ledger for a variety of clients and
developers. Here are the top group of items I think you have missed:
- multiple ent
Hi all,
Below the basic SQL schema I have so far for double entry bookkeeping.
Does this look like a viable schema? I think I'm interpreting the
general structure of double entry bookkeeping and earlier discussion
here correctly. I welcome any comments specifically on the schema.
Basically e
BareFeet wrote:
> Hi John,
>
>> You still miss the point of the cross reference ID. It is NOT the
>> reference ID od the document, such as an invoice or check number,
>> but it
>> more like the row ID used by Sqlire as a unique key for a DB row.
>
> I thought, from your explanation, that was w
On 20/02/2009 12:35 PM, BareFeet wrote:
> Hi John (Machin),
>
> Thanks for the discussion.
>
>>> I understand that double entry bookkeeping traditionally uses the
>>> redundancy as an error check, but that seems more appropriate for
>>> manual paper systems, since computer systems can validat
We are talking about different things. The referennce ID is an ID
assigned by the originator or the transaction, say an invoice number
from a vendor or a check number from a bank whereas the cross reference
is assigned by the application software and represents a key in an index
on the table.
Hi John (Machin),
Thanks for the discussion.
>> I understand that double entry bookkeeping traditionally uses the
>> redundancy as an error check, but that seems more appropriate for
>> manual paper systems, since computer systems can validate entries
>> automatically.
>
> That's just fine
Hi John,
> You still miss the point of the cross reference ID. It is NOT the
> reference ID od the document, such as an invoice or check number,
> but it
> more like the row ID used by Sqlire as a unique key for a DB row.
I thought, from your explanation, that was what you were using the
"Re
You still miss the point of the cross reference ID. It is NOT the
reference ID od the document, such as an invoice or check number, but it
more like the row ID used by Sqlire as a unique key for a DB row.
You could normalize out the date and have stored as associated with the
cross reference.
On 20/02/2009 9:23 AM, BareFeet wrote:
> Hi John,
>
> Thanks again for your discussion.
>
>> "Double Entry" book keeping is actually a misnomer. A transaction
>> is very likely to have more than two entries.
>
> Yes, I realize that, though most Transactions generally have just two.
> In any
Hi John,
Thanks again for your discussion.
> "Double Entry" book keeping is actually a misnomer. A transaction
> is very likely to have more than two entries.
Yes, I realize that, though most Transactions generally have just two.
In any case, if there are n entries in a Transaction, we only
"Double Entry" book keeping is actually a misnomer. A transaction is
very likely to have more than two entries. The "transaction ID" I
mentioned is a locally generated reference ID to tag the particular
complete transaction, which might include postings to a bank account,
sales, cost of sales
Hi John,
Thanks for the input.
> In general you need for one transaction -
> General Ledger account
> Date
> Reference ID
> Cross Reference
> Amount
> Optional narrative
>
> The Chart of Accounts defines full set of accounts and the details of
> each account.
OK, that seems very similar to the s
In general you need for one transaction -
General Ledger account
Date
Reference ID
Cross Reference
Amount
Optional narrative
The Chart of Accounts defines full set of accounts and the details of
each account.
The G/L A/C indicates whether it is an asset or liability account (plus
or minus) and
Hi Rich,
>> I'm trying to design a schema for double entry book-keeping. Is there
>> already a schema available that provides this functionality?
>
> Well, if you're going to re-invent the wheel, take a look at the
> source
> code for gnucash or, better yet, SQL-Ledger.
Thanks for your reply.
On Tue, 17 Feb 2009, BareFeet wrote:
> I'm trying to design a schema for double entry book-keeping. Is there
> already a schema available that provides this functionality?
Well, if you're going to re-invent the wheel, take a look at the source
code for gnucash or, better yet, SQL-Ledger.
Rich
Hi all,
I'm trying to design a schema for double entry book-keeping. Is there
already a schema available that provides this functionality?
As I see it, I need to start with something like the schema below. Any
other approaches?
create table Accounts
(
Code text unique collate nocas
17 matches
Mail list logo
