The solution to this problem is this:
tblEmployee
EmpID
FirstName
LastName
...
tblTransaction
TransID
EmpId
Debit_Credit - pos or neg currency values
TransDate - mm/dd/yyyy:time
...
Then all your problems are solved since the calculations take place sequentially. If you are using accounting rules and want only absolute values instead of positive or negative, then you can do this:
tblTransaction
TransID
EmpId
Debit_Credit - positive currency values
TransType - yes/no - default no, yes for credit, no for debit
TransDate - mm/dd/yyyy:time
...
You can even display data entry for this solution to look like a credit or debit column with one column. Just put two columsn on the form, have the user select the employee name, then have them enter data in either the credit or debit text box (disable the other when one is being filled out) then pass the data from the text box to the proper field and have the form check the check box as appropriate. With this structure, you can even show the current balance as the form is opened so the user doesn't over-debit.
THEN you might even create a table that stores an opening and closing balance for each month for each employee. THAT table would have:
tblTransMonth
TransMonthID
EmpID
OpeningBalance
ClosingBalance
TransMonth - mm/yyyy
...
You have to design here for n number of transactions, not one per month.
That being said, I am not sure how you will solve this since you are never going to know what your carry over opening balance is from the previous month this way. My inclination is to solve this issue with proper design. I seem to see your particular design coming out of India a lot since this is not the first time this issue has been posted to solve this design problem with ad hoc solutions. I am wondering how this paraigm was adopted for this business process.
Accounting transactions take place sequentially and exclusively, so the values can be stored in one column with a date/time stamp on the record. Then all your sequential calculations can be worked out, and you can determine balances at any point in time. Just because a double entry ledger has two columns for transactions by type doesn't mean your table has to as well.
That's my two cents. I have just seen this problem posted too many times in this forum.
mmcdonal
Look it up at:
http://wrox.books24x7.com