I've always wondered how its done, is there a standard or just everyone does it randomly?
I thought this would be good:
.. but it gets too long, any way to reduce the length? should I convert it to hexadecimal? So
I've never been a fan of trying to build smart numbering systems for things like invoices or part numbers. It forces you to try to anticipate all your future requirements now and hope for the best.
For related idea in the world of part numbers, read the section titled "Significant numbering schemes are quite fragile
http://www.buyplm.com/plm-good-practice/part-numbering-system-software.aspx In your example, you are limited to 99999 clients and they will probably not have more than one invoice in a single day. This makes your proposal very inefficient and sparsely populated.
Also, in a few years, you may wish that you had included something like "sub-client ID" in there.
I'm a proponent of "dumb" numbering schemes... Just pick a sequential integer series and pull from that pool.
You may wish to prepend a prefix such as "MCX-" for "my company x" to assist your clients in recognizing invoice numbers that belong to you.
You could also include a check digit at the end, to decrease the probability of Mis-typing a real invoice number... Or you could simply increment your integer series by a number greater than 1 (such as 19). These methods will 'waste' numbers and be less efficient, but have other benefits.
In formal invoicing system design, they generally argue for sequential invoice numbers. It facilitates an additional audit checkpoint, where you can easily identify missing invoices. Generally you need to have an integrated mechanism to ensure that someone in receivables dept isn't deleting invoices and pocketing money.
I'd suggest simple sequential number, which is the standard mechanism of most invoicing systems.
Having said that, as a small business, it's a little annoying to provide your customer a way of determining how many invoices you're cutting per month. So I've seen people employ a "customer id"-"invoice number" scheme. I really disagree with the notion of putting the date in there, though.
I think the most straightforward way of doing this is to just use number sequence starting at N.
I go with a "client id"-"sequential number" where the number of digits isn't fixed anywhere. This is as much for my internal organization (all contracts, invoices, etc have the client id and there's nothing restricting me from making the client id a project id instead, so the same client could potentially have a different number for each project).
This works for me, but I'm only sending out one invoice a month to one client at a time, and a larger scale operation would want to automate this with a single sequential number.
I agree with the other answers. Computer applications and databases do a good job of assigning unique sequential numbers out of the box. Your system is going to require more coding, testing and user training than its worth not to mention changing the scheme in the future.
You do have to be careful with distributed systems that may have some disconnect, but that is not a reason to put any "intelligence" in the PO number. At most you would just have different starting points for each location and enough room to prevent their numbers from realistically overlapping. Office A starts with 1000000 and Office B starts with 2000000 or something like that.
Your scheme for numbering invoices is doomed to failure, so you might want to change it now.
1) Basing the invoice number on a client ID limits you to that system forever. What if you start selling retail software, or services to anonymous clients in the future? Or you exceed 5 digits worth of clients??
2) Encoding the date in your invoice number makes no sense. Invoices are legally required to have a date on them. Why would you repeat this information in the invoice number itself?
3) Now you are aiming for 99999 invoices in a single day???
The vast majority of all firms pick a starting number, and increment it after each invoice. This system allows you to track any invoice, and puts no limits on how or when invoices may be generated.