I received a PO from a customer this morning and this was the PO number: 00001445
Not one leading zero. Not two. But four leading zeroes. Why? Is 1445 not a good enough for a PO number?
Another common one is checks. I received a customer check numbered 000095220. My personal and business checks are nice and simple, with no leading zeroes, so I don't understand why people feel compelled to add zeroes at the front of document numbers.
It seems like the Fabrikam / TWO sample company encourages this, and takes the leading-zero cake with 19 leading zeroes setup in the default checkbooks. I think that would allow for several quintillion checks. Good luck having BofA cash a check that has a 20 digit number.
But are the leading zeroes really necessary? Do they provide any value whatsoever? Can't we just have a check number without the leading zeroes?
Is there some secret about the leading zeroes that I'm missing? Assuming the system is able to roll over numbers and add a new digit, like incrementing from 9,999 to 10,000 (which I believe GP does
[Update: So Jen and Roger submitted comments below, and not surprisingly, they both point out that there are modules and records where GP is not able to roll numbers over and add a digit. For those situations, yes, you're stuck with the leading zeroes.]
Many of the default document numbers in GP have alpha prefixes, so it's not quite the same, but they do have an excessive number of zeroes in them. One of the first things I do when working with a new Fabrikam / TWO database is to change the default next document numbers to values that are usable and don't require me to count a bunch of zeroes. The default numbers are a nightmare to test with, so I usually pare them down to no more than 6 digits after the alpha prefix.
I'm open to explanations as to why this might be an even remotely valid idea. I can only think of one, which I'll keep to myself so as to not encourage the practice, but even that one seems like a very weak justification.
Steve Endow is a Microsoft MVP
for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.
He is the owner of Precipio Services, which provides Dynamics GP
integrations, customizations, and automation solutions.
5 comments:
I typed a whole comment and lost it, bummer.
Long story short, believe it or not, many places in GP, it doesn't know that after 9999 comes 10000. So leading zeroes are required in some "next number" fields. In some, like cheques, there shouldn't be a lot of leading zeroes, unless the consultant implementing is lazy and leaves the default long cheque number in place.
I never leave the default next numbers for anything if I can avoid it, they are ridiculously long, even for the organizations that have the highest of trx volume. I shorten them to a reasonable length but it's based on a discussion around anticipated trx volumes to ensure it's long enough to last several years of activity!
Remotely valid? There are two reasons: Sorting/ordering transactions since the field is alphanumeric and left justifies.
The other reason is legacy code. Fixed Assets module for example does not have its own index. It auto finds the next number in sequence *at the time the stored procedure runs* and let's just say it assumes a few things...like there are NO customizations done to the FA module.
We found that out the hard way. Basically if you need to customize the FA Doc Number (gee Mr eConnect, why don't you create an FA Doc Number like your user interface cousin? Is that why analytical accounting doesn't work with FA imports using eConnect?) DON'T use a code that letters AFTER FA. You will break the user interface because of this runtime indexing.
Thanks Jen and Roger. I wasn't sure if there still were modules or records where GP doesn't know how to count past 9. I've updated the post to clarify.
One of the first things I do when setting up any new company in GP is take the number of leading zeros down to just a few for all transactions in all modules. That said, I have definitely seen customers run out of numbers after doing this and if it's not caught in time, they start getting errors.
Fields like SOP document number are character fields rather than numbers so in terms of sort order document 1001 comes before 2. Plenty of features allow you to select a range of numbers that are affected by this. Leading zeros deal with this.
That said I always recommend including a digit other than zero every couple of digits in the starting number to make it easy to read over the phone. Try reading INV001001037 rather than INV000000037.
Post a Comment