By: Ray Killam, CFSP, CFC
President

It happened again last week. While working with a client, we got into a debate about what constitutes a "good" form number. My customer had created a complex numbering scheme and was faced with a crisis caused by an organizational change. It seemed like a good time to start with a completely new system.
What’s so important about a form number? What purpose does a form number serve? What purpose does a form title serve? What constitutes a “good” form number and title? These seemingly simple questions create a lot of debate within the forms community and can result in significantly increased cost for a business or government agency.
Let’s start with the form number. It seems to me that this number serves several distinct purposes:
- Helps "search" and "find" efforts
- Used as a reference within a procedure
- Legitimizes the form
- Provides a kind of “shorthand” for referring to the form
In this context, the form identifier can consist of several elements, including:
- Base form number
- Record number
- Edition date
- Language version
- Type identifier
- State or Province version
- Responsible department
- Line of business identifier
- Business system identifier
- Status
- AKA (Also Known As)
- Cost center code
- Packaging Configuration
- Related To (other forms)
Obviously, incorporating all these identifiers into a form number would be quite confusing and maybe even incomprehensible! Fortunately, there is a process that simplifies.
Let’s start with the basic form number. It should be simple, unique to the form, and easily remembered and understood by all users, even the general public. Therefore, we advocate the form number start with a five digit number, 10000, and simply increment by one for each new number. That works fine, but it doesn’t provide for all the variations the form can take. When adding these variations, the form number no longer is unique, therefore losing its value as a primary key in a database.
To get around this problem, we can add a Record Number that servers as the primary key in the database. This would be an automatically incrementing number, beginning with one (1). Our data table looks like this:
RecordNumber |
FormNumber |
1 |
10000 |
The next identifier is the Edition Date. We use edition to describe the date the form became active and express the format as mm/yyyy. All forms, even the first edition of the form, have an edition date. There can be more than one edition for a given form, either concurrently active, or one active and one obsolete, and so forth. Our data table now looks something like this:
RecordNumber |
FormNumber |
EditionDate |
1 |
10000 |
11/1999 |
1 |
10000 |
02/2006 |
Each edition of each form can exist in a variety of formats, including language versions, state or provincial versions, electronic formats (Types), and more. Since we need a unique way to identify each variation, we can simply add more records, giving each one a unique identifier (primary key in the data table). Using this methodology, we never run out of primary keys; we simply add more fields to our table. The result looks something like the following:
RecordNo |
FormNumber |
EditionDate |
Language |
Type |
State/Prov |
RespDept |
LOB |
BusSys |
CostCtr |
1 |
10000 |
11/1999 |
EN |
Paper |
All |
1002 |
Annuities |
Sales |
56 |
2 |
10000 |
02/2006 |
EN |
Paper |
All |
1002 |
Annuities |
Sales |
56 |
3 |
10000 |
02/2006 |
FR |
Paper |
PQ |
1002 |
Annuities |
Sales |
56 |
4 |
10001 |
05/2004 |
EN |
PDF |
All |
5006 |
Life |
UW |
861 |
5 |
10002 |
11/2005 |
EN |
Paper |
All |
3200 |
ADD |
Legal |
500 |
6 |
10002 |
11/2005 |
EN |
PDF |
All |
3200 |
ADD |
Legal |
500 |
7 |
10002 |
11/2005 |
EN |
Word |
All |
3200 |
ADD |
Legal |
500 |
8 |
10003 |
10/2004 |
FR |
PDF |
PQ |
5006 |
Life |
UW |
861 |
9 |
10003 |
05/2005 |
FR |
PDF |
PQ |
5006 |
Life |
UW |
861 |
In this scheme, any number of variations can be provided because the Record Number is unique. A search for a form returns all the variations for a base form number, or the user can bookmark the Record Number. The Form Number cannot be the primary key because it is repeated with each variation. The Record Number cannot be the form number because it doesn’t uniquely describe the form.
As for printing identifiers on the container, there are really no restrictions except practically. For example, the container could include identifiers such as:
Form ADD-10002 (11/2005) EN PDF
which clearly identifies the form as Form 10002, Nov. 2005 edition, English version, PDF variation, assigned to the Accidental Death & Dismemberment line-of-business. There is no conflict with the database for the person looking at the form.
Some schemes attempt to encode all the data into a form number. This is generally not a good idea because as business systems and procedures change, changes to the form number become necessary. The numbering scheme described above is indifferent to any such changes. Of course, the more information printed on the container, the more changes are required when re-printing or updating the container.
Recent Comments