If you are building or using an e-commerce system and want to look all professional, you need invoice numbers. Invoice numbers are required, at the very least, for auditing purposes by most businesses. However, nothing says "not professional" quite like "dressing in a shirt that is flashier than a light pinstripe" or invoice numbers based solely on a MySQL 'auto_increment' field starting at '1' or, worse, a false arbitrary starting value.
Searching Google for an industry-standard practice of creating an invoice number turns up pathetic results. So this blog entry aims to correct this severe oversight of the Internet and bring it down to the level of the average programmer.
Businesses that are large enough have dedicated finance departments. These people like things to be EXTREMELY organized. If you are developing an application that is going to bring in money (e.g. an e-commerce solution), it needs to generate sequential orders that can be verified later should the organization be required to perform an audit. Audits are annoying. If you start numbering invoices/orders at 500, the auditor is going to want to know where invoices 1 through 499 are. So, you really should start numbering orders at '1'. However, from a customer's perspective, being the first person to order anything is viewed as rather "tacky" for the invoice. So, what should be done about this?
Invoice numbers should represent the order in some fashion that makes sense and makes looking up the order later on easy to do. It should also include some letters with the numbers. What follows is my own blend of parameters that creates a rather good-looking invoice number in most cases, makes it easy for programmers to extract the order number, AND meets the auditing restrictions imposed by most businesses:
So, a sample invoice number could be:
The example is the company "CubicleSoft" abbreviated to an acronym, the two-digit year, two-digit month, and two-digit day of when the invoice was created (November 19, 2010), a hyphen (-), and then the order number (Order 1). It could be the very first order ever in the system but the customer won't notice - they will likely just think it was the first order of that particular day. For programming purposes, it is easy to locate the hyphen, convert whatever comes after that to an integer, and then use the value to look up the order in the system. In fact, the only thing that really matters with the invoice is the number after the hyphen. The stuff before the hyphen can just be used for verification purposes.
The next issue is that finance departments require the ability to map an invoice number to the money. That is, they need to be able to exactly match the order to each and every penny. An e-commerce solution depends on a third-party to process the payment. This creates a disconnect between the order and the payment that must be resolved. The invoice number on the payment end of things must match the order entry system or auditors get unhappy. Therefore, be sure to send the payment processor the fancy invoice number so when someone later on goes to do a report, they can easily get that information, which makes that person's life easier and simpler.
In conclusion, I really like that video. :)