I thank you for this advice, and am going over each item in it!

>Users prefer to "see" DB and CR columns; on forms and reports.
>
>"Internally", you could use a single field ... However, you have to weigh the effort it will take, from a programming POV, to constantly be "converting" from a single field to dual fields for display purposes.
>
>I built a GL with DB and CR fields; as with you, I felt uncomfortable with the design but it seemed to be the way to go, all things considered (like user reporting) ... This only applies to "transactions"; the account records use a single field for any period amounts.
>
>And BTW, the GL yearly "posting account" records also have 13 "buckets", vs "period records" (ie. YYYY MM $) ... Another violation of "conventional" DB normalization ...
>
>At the same time, this (yearly posting records) is still an improvement over most GL packages which typically have one account record with "last year", "this year" and "budget" amounts ... which limits one to only a few years (online) of financial info.
>
>Another tip: consider currency conversion; it may be easier in the long run to have "two" sets of DB and CR fields (internally) ... one for "home", and another for "source".
>
>>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!