I agree with your statements and had decided on a similar layout of header and detail records for GL transactions as the most appropriate method of doing the work.

I really like your idea of the "Journal Entry Class" with subclasses. I had not thought of it, but I am going to work on that! Have you created such a class? Any suggestions?


>I used your "first design"; ie. "Header and details".
>
>Eliminating the Header, you loose the concept of a "tra
nsaction"; a number of "details" are generally grouped together to represent some financial event (purchase / acquisition, sale / disposition, etc).
>
>Also, the transaction itself is "balanced". It can also be in a state of "suspense" if some info is missing, and not be "postable". Once a transaction is in balance and ready for posting, it can be flagged as "closed" (in the Header) and subsequently posted (and flagged as such).
>
>A "2 account" detail line fails to "account" for the fact that very often a transaction involves posting to "one account" on the "one side" and "many" offsetting accounts (on the other side); eg.
>
>

>AAA   NNN
>BBB        NNN
>CCC        NNN
>DDD        NNN
>

>
>A running total of the debits and credits would be maintained in the header; or even the "primary" amount would be stored in the header with the offsets in the details.
>
>There are generally 5 "classes" of journal entries, and one may wish to handle these a little differently for the sake of the user (a single OO program with 5 subclasses could handle them all); eg.
>
>Accounts Payable (AP Invoices)
>Accounts Receivable (AR Invoices)
>Cash Receipts (AR Checks)
>Cash Payment (AP Checks)
>General Journals (Adjustments, etc)
>
>In the first four cases, the "Header" generally contains "Client" info (like Client code, Invoice / Check #) that applies to the transaction as a whole.
>
>... But, all this may only be a matter of personal preference and what a given set of Users finds most comfortable to work with.
>
>>Hi Don,
>>
>>I have written a GL system from scratch and have modified it over the last ten years. The nagging concern you will run into is keeping things "in balance". Basically that means that the total of the debits always equals the total of the credits.
>>
>>I don't mean to be simplistic, but my first design used a JV header record which contained the date and a description of the journal entry. The detail records contained the header ID plus an account_ID and two numeric fields, one for debit amount and one for credit amount. In each of the detail records, only one of the numeric fields was used. So every journal entry must have at least two detail records. In this design you must be very careful and be sure to use transaction processing because it is easy to get "out of balance".
>>
>>I could go into a lot more detail if you want, but suffice it to say that my latest design is simpler. There is no header record. Instead, the financial transaction records have one numeric field and two account fields (debit account and credit account). In this design it is virtually impossible to be out of balance providing both account codes are valid and present. This is not the classic design an accountant would develop but, as others have said, under the hood does not matter if the results are there.
>>
>>Let me know if you want more details.
>>
>>Hope this helps,
>>
>>Ken
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>I have a need to design a general ledger system from scratch. I've been searching for examples on the internet.
>>>
>>>I see that some systems use two separate columns: one for DEBIT and one for CREDIT amounts, and others use one "Amount" column with a plus or minus amount.
>>>
>>>I know all the manual systems use debit-credit columns, but is this the way I should actually go with a computerized system?
>>>
>>>Can any of you with experience in this area make a recommendation on the better way to go? Any advice?
>>>
>>>TIA!