Looking For Suggestions Regarding Account Numbers

I have been asked by a client for suggestions in coming up with a good numbering system for accounts in CRM.  My thoughts are that a good system would meet the following criteria:

• It should be a unique identifier--numbers can't be duplicated
• It should be fairly automatic
• It would be nice if it were more meaningful than just a random number.

Do you have any suggestions or experiences in account numbering systems?  Is there a better system that just sequential numbers (00001, 00002, etc)?  I have seen "intelligent" numbering systems that use something like the first few letters from a company name + a random or sequential number, somthing like WAL12345 for Walmart; however, what happens if another company started with the same letters (like Walgreens)?

If you have any suggestions, please share them in the comment section.

Comments

[MDodd]

I have debated this several times with fellow CRM'ers. The solution I think works best is to use a combo of the parsing the Account Name and appending it with the Julian Date. But since JScript 5.6 doesn't have a getJulianDate() method, I concoted my own, with an added touch of a random number generator using the Math.random() method. Put the following code in the OnChange event of the AccountName field. Then, disable the AccountNumber field. Oh, yeah, take out the alerts too.

// Generate AccountNumber
if (crmForm.FormType == 1)
{
var aName = crmForm.all.name.DataValue;
aName = aName.substr(0,3);
aName = aName.toUpperCase();
var iNum = Math.random();
iNum = iNum.toString();
iNum = iNum.substr(8,4);
alert(iNum);
var myDate = new Date();
julDate1 = myDate.getDate();
julDate1 = julDate1.toString();
julDate2 = myDate.getMonth();
julDate2 = julDate2.toString();
julDate = julDate1.concat(julDate2);
alert(julDate);
actNum = aName.concat(julDate, iNum);
crmForm.all.accountnumber.DataValue = actNum;
crmForm.all.accountnumber.ForceSubmit = true;
}

Not very economical, but it works fine.
What's at work here are 3 things:

1.) My psuedo "Julian Date". It may not be as unique as the full julian date, but every day of the current year will produce a unique set of numbers (today is 2902)
2.) This is appended with 4 digits in the random number. So no 2 users in a given day will produce the same random number (in theory)
3.) The first 3 letters of the Account Name. Even Wallgreens and WallMart will get a different Random number.

With these 3 "Checks and Balances" in place, you'd be hard pressed to get a duplicate Account Number.

However, if you're really slick, you could write duplicate checking function using a Web Service call that queries the FilteredAccount view, checking for a record that equals the value in the AccountNumber field. If the response that comes back is not null, restrict the save, re run the OnChange for a new Random number.

--Michael