I think I got you now, but it's not much different than how I do it now. The only difference I can see in your way is that I'd take the stuff out of the P/C file for the month and put it in another table. But since I use a datespan to extract the records to bill, it doesn't much matter which file they're in.

The one thing I can see that would help is using a flag instead of a datespan, because then trips missed one month would be caught the next. But I'm afraid this doesn't solve any of my other problems.

I appreciate your response, but I just don't think this is going to do what I need.

Thanks,

-Michelle



>I'll try. . .
>
>When it comes time to run billing, THEN you extract the applicable TRIPS and PAYMENTS into a newly created, for this month (but probably kept forever for audit/backup/etc) BILLING-TOBE-DONE-THIS-RUN file.
>Then any billing programs use thse new file on which to base the billing.
>
>You also ensure that the original files (from which the BILLING-TOBE-DONE-THIS-MONTH file was created) have the extracted records flagged as "already-billed". You might even have a multiple-state flag so that you could indicate 'in process of billing' (as the record is extracted to the BILLING-TOBO-DONE-THIS-MONTH file) and 'billing completed for this record' (after billing has run successfully), as last thing of billing).
>
>By processing an extracted set of records you allow the users to continue to do whatever they want as far as inputting of more billing (trip or payment). This assumes, of course, that they enter new records for such purposes - if the update existing records, it is more complicated.
>
>NEXT month's billing cycle does it all again - extract records for billing, then do the billing. Any record not flagged as 'already billed' becomes candidate for this run. If you encounter any record with 'billing in process' flag only, then you have a problem which needs looking at.
>
>I hope this is clearer.
>
>Good luck,,