I've read this three times and I'm still not sure what you're saying. I put the stuff into a billing file that only has stuff for that month in it? Then use it as input for what? Maybe an example would help.

Two things go into billing, trips and payments. The point the trips enter the billing system is when they are verified. When verified, they go into billing and trip history.

So with your system, I'd start the month with a specific file to put the trips and payments into? I don't see how that's different than putting it all in one file and extracting the ones in the datespan at the end of the month...

Or am I completely misunderstanding what you're saying?

Thanks,

-Michelle


>Hi Michelle,
>
>Long ago I worked on a long-distance telephone billing system which had the characteristic you describe (one monthly statement for lots and various usage).
>
>I certainly agree that you impose far too many restrictions on the user (and yourself) with the present method.
>
>I'm sure many people have successfully solved this problem, and their memories will be better than mine. However, probably the key for the way we used to do it, which imposed no restrictions on users (but which, of course, meant that they should always be as up-to-date as possible on their entry, was to have the "billing" system *FIRST* extract all billable entry to a specific monthly billing file and, thereafter, use that file as the primary input.
>
>This meant that users could continue to input, or do whatever else their hearts desired, while billing was processing. At sometime during billing processing (we did it at the end but there are arguments to do it at the beginning too) we set a 'flag' in the *original* record corresponding to our copied record to indicate that that record had been billed.
>Of course,, next month's record selections would disregard any records where the 'has-been-billed' flag was ON.
>This is a brief sketch of the basics. I hope it helps