I see what you're saying. This is a whole different way of looking at things. The way we do it now, invoices and statements are the same thing. Each month, the trips and payments for that month are gathered, stuck on an invoice/statement along with the past balances that are stored somewhere and manually updated each month. This is what gets sent to the customer.

So your way, the customer would have a new invoice each month, but get sent a statement that compiles the data from all invoices that aren't paid yet? That makes a lot of sense. I think that would make my life a _lot_ easier.

This is giving me a lot to think about. Thanks!

-Michelle


>You are confusing Invoices with Statements. An Invoice is a record of a transaction, the only balance associated with an invoice is the balance due for THAT invoice. You print Statements to list unpaid invoices, and on statements you can total the invoices for date ranges to fill in the over 90, 90, 60 etc. fields on the statement.
>
>Statements represent a customer account at a certain point in time (the statement date). They are not usually saved anywhere as they change each time they are produced. What is the data that produces a statement? The invoices which are unpaid. So for an invoice record you would create it and then apply payments to it until its balance due is 0. For statements you look for the invoices for the customer that have a balance due other than 0.
>
>Again, why not post your table structures and let us try and help in getting them to work for you.