Here we need to talk about codes and why/how they are used. When we talk in general about “codes” we are referring to such things as:
- Chart of Account codes
- Customer codes
- Supplier codes
- Product Codes
- Trading Terms codes
- Hold Payment codes
- Branch Codes
These are but a few examples. OA, like most systems, is made up of many such codes. These codes are sometimes referred to as “numbers” as in “the Chart of Account Number” or “the Customer Number”. However we do not use the word “number” as it suggests a numeric nature to the code and this is far from the real situation. We often see users creating codes that contain both numeric and alphabetic characters.
Codes are the building blocks of good databases. They are integral to the way “data” becomes “information” within a database. There are two basic reasons for this:
- they provide uniqueness
- they allow relationships
Uniqueness
The most important attribute of a “code” is that it is unique within the context of its use. This uniqueness is crucial to the system so that we can accurately identify the use of each individual code. This is perhaps quite obvious when we think about Products and Sales Reps, but the same characteristics are required for all codes in a system. If you want to analyse your historical sales by the type of material it is made up of, there is no point trying when you have products marked with ad-hoc words like “Steel”, “Metal”, “Stainless Steel, “Stl”, “Stel” and other such spelling and typing related issues as you won’t be able to accurately use those for report filters and reporting totals. However, if you simply assign a code to represent the material e.g. “SS” for “Stainless Steel” then you will always be able to select this unique material and get an accurate result.
Relationships
Once you have a solid set of unique codes to record your data against, the system is able to use these to form relationships between the data, mostly for reporting and display purposes. It is because of these relationships that most of the information can be extracted from a system. For instance, without recording a sales rep against a transaction (Invoice, Credit Note, Quote, Order) how else would we be able to relate that to the individual rep so that monthly or annual sales can be compared to budget.
A more complex version of the relationships that we are able to construct in OA through the use of unique codes is shown with a Stock Valuation by Division Report. Each stock item sits in a Stock Location and is recorded against a Product code. Each Product code sits in a Product Group, and each Product Group is allocated to a Division, so this enables us to follow those unique relationships to produce a summary report of the value of all stock in the Inventory system by Division.
Best Practices
It should be said that there are no specific best practices other than the ones that work for your company/situation. Ultimately if it is not broken, then the coding structure you are using is usually going to still work in OA without major re-engineering. Having said that, we often find people coming over to use OA that feel their code structures have limitations/problems and they take the opportunity to re-visit the coding. When taking the opportunity in these cases, or when inventing new code lists, here are some “best practices” to keep in mind:
1. Make it easy to type! This is the 1st item for a reason. It should be at the top of your list when the code you are inventing is input a significant amount of times by your users. This is particularly true of the main elements in the OA system such as Product, Customer, Supplier, Chart of Account.
Making it easy to type can mean keeping it mostly numeric. The numeric keypad is significantly faster to use for users who are well practiced at keyboard input. Keep the use of alphabetic characters to a minimum where possible. Avoid entirely the use of “special” characters i.e. those that require the use of the “shift” key for input.
However making it easy to type on the keyboard is not always the solution. You must consider the users of the codes in question. All users. That means not only your Order Entry staff, but Customer Service, Warehouse & Factory staff, Sales & Marketing and even your Customers who have to work with, quote and often even type your codes in if using your E-Commerce portal. Often companies opt for a non-numeric code because they find that having a more intuitive alphanumeric code works better for the majority of their users.
2. Implied logic/structure – where possible attempt to build in some implied logic or structure where it exists. This is most useful and easier to do on the smaller code sets that you might build. For instance Product Group or Bins. If you think you may add to the structure later – leave gaps! e.g. use 10, 20, 30, 40 so you can slip in 15, 25, 35, 45 later if you need to. Remember if you structure your code as a single digit, you have numbers 0-9 so you have 10 codes available under this structure. If you use a single alpha, then you have 26 (A-Z).
3. Avoid leading “fill” characters like zero. There is rarely a need to have every code the same length so avoid the temptation (or impulse for some people) to make all codes “look” the same by putting leading zeros in front. If you’re considering using the code “111”, then create it like that. No need to make it “00111” just because you have another code that is 5 characters long. All you do there is give users two more characters to type every time they use it.
4. Consider using meaningful codes. For example, SHRT, PANT, HATS and GLVES is more meaningful than 1, 2, 3 and 4. This can be useful if you have (for example) a report where space is tight – you may be able to fit the ‘code’ in and use that as a ‘short description’ where the code’s full length description might not fit the available space.
5. Consider how the code will sort. Numbers sort before letters in ascending sequence. Codes that are expected to be alpha usually sort in a ‘left justified’ manor – for left justified sorting, numbers sort in sequence 1, 10, 11, 2, 21, 22, 3, 4, 5, 6, 7. This is not so important if you expect sorting to occur on the code’s corresponding ‘name’ field.
Restrictions
Within Online Advantages there are a few restrictions on what can be used for codes.
- Code length – the length of a code is not unlimited. Code lengths of 3, 5 or 8 characters are the most common. In some cases the length of the code is determined by your own requirements at system set up time. For example, product code length and chart of account code length are two of the codes where the length is configurable.
- Reserved characters – generally the use of characters like [ & , \ . * / ‘ ] in codes is not allowed. There are sometimes other ‘special’ cases of reserved characters. For example, you may not use a product code of ‘T’ as this is used to denote text lines on sales or purchase orders.
- Codes are always upper case