What is the standard way to write a program to generate invoices?

I am building a billing s开发者_如何学编程ystem. The system needs to generate monthly invoices to Clients.

What I am doing now is using a For loop to check all the clients their previous invoices and decide if it is the time to generate a invoice for the client.

If there are huge number of clients in the database, I think it could be very heavy to do so.

What is the standard way of generating invoices? Is it possible to make cron jobs that records a client's next invoice date and only check a particular client when it is the time to generate an invoice.

Thanks a million

You mention a database. Why don't you use it?

Put an index on the "date of previous invoide" column, add a WHERE clause to return only clients whose last invoice was sent more than a month ago.

What is the standard way of generating invoices? Is it possible to make cron jobs that records a client's next invoice date and only check a particular client when it is the time to generate an invoice.

There is no standard way. But this task is indeed a typical candidate for a batch job. Either run it at the end of the month if you bill all clients at the same time or daily and select only the clients that are billable based on some date criteria. For each client, do what you have to. Depending on the size of your data, JPA might not be appropriate (or maybe consider Hibernate's StatelessSession or even forget it).

For the scheduler part, I've seen most often enterprise scheduler like Quartz or even bigger dedicated solutions like Control-M, Dollar-U, TNG Workload, etc.

I strongly advice to NOT create one job per client. This is really not a good solution (hell to administrate, won't scale, etc).

leon, i'm not sure if there actually is a standard way as such. each company culture will define to a certain extent, how the process is best run to fit their requirement. you'll find some apps that do both the extremes of on demand processing and others that run invoicing as a batch process. in general, it's nice to build your interfaces to accomodate both. you may also have to consider the possibility of a 3rd party at some point requiring your API via a webservice etc. (for cost savings, the company in question may actually use a bureau service to 'publish' the invoices - i know this from 1st hand experience). Your database structure will also have to be fairly robust and have plenty of fallback points, should any of the processes fail etc, etc..

Anyway - Debate... :)

jim