>You are making your current problem worse if you do that. How will you deal with a change to an invoice somewhere in the middle of the list? Are you going to recalculate all of the past balance fields in all later invoices to fix them?

I hadn't thought of that. That would be a mess, wouldn't it?

>You can calcualte the data when you need it. If you can't, then it is time to drop way back to the design of the tables and find out WHY you can't calculate the balance for a customer. Goping any further with producing invioces when the tables don't have the necessary details will not only be fruitless, but it will drive you crazy.

I don't know if there was any design involved in the making of these tables. :)

>Why not post the structures of the tables you are using with some description of them and we can see if we might have ideas to make them more suitable to your goals?

The two main tables involved in billing are the pc table (like invoice details) and the clbal table (holds the current client balances).

pc: date, time, note1, note2, check_num, rtype
clbal: client_num, fname, lname, current, bal_1_30, bal_30_60, bal_60_90, bal_90_ovr, cust_total

When a trip is processed, the amount is added to the current client balance. When a payment is processed, it can be added to _any_ of the past balances, the current balance, or a combination of them.

When all trips and payments are processed for the month, the user saves the clbal table. When they print bills, it scans through the names to find who to bill and scans through the pc table to get the details.

How I'm thinking of doing it is creating the invoices as soon as they get their first trip for the month. Then I could save the balances with that invoice. At billing time, I'd just need to print the invoices. So far I haven't found what's wrong with the idea. :)

Thanks,

-Michelle