I use a transaction view that includes a transaction table and a transaction detail table. In the detail table, all chargable items have an item number (that links them to other, item tables), a quantity, a regular price/fee/amount per unit, a computed column that is the product of the quantity and the price, and a final price (discounted/agreed amt, etc). All payments and other credits receive negative signs and go in the final price column, so the "balance" of a transaction is simply the sum of the price column, which will be positive if a balance remains, negative if a credit balance is created, and zero if the payment/credit totals equal the charged amounts. This way I can create statements, bills, insurance claims etc from this one view.

bill

Ben Petersen wrote:

Hi all,

I'm down to the nitty gritty of an accounting package and wanted to make sure my take on accounts receivable for cash based customers was accurate.

For straight up transactions where there is an invoice and a payment for that invoice nothing hits the GL until payment is made. But in the instance where someone _partially_ pays an invoice, or, over-pays an invoice, this is what I've been doing in past systems:

Debit cash for the payment amount.
Credit A/R for the payment amount.
Debit A/R for the invoice total.
Credit income accounts for the items on the invoice.

In the case of under-payment this leaves an A/R balance. In the case of over-
payment there is a negative A/R balance.


In my re-write everything is driven by views, so it is possible to have a circumstance where new invoices work directly against the customer account to reduce the credit and not be posted through A/R. My concern is that while it makes the A/R portion of the GL cleaner, it is possible, for example, to have an invoice detailed in A/R at one moment, and not the next, if a new invoice brought the customer account to zero. While the transactions would explain "what happened" I don't know that this is acceptable.

I'm looking for some outside confirmation and/or alternatives.

Thanks

Ben Petersen

.






Reply via email to