Creating Reporting Identifiers (IDT)

Tips for creating a Reporting Identifier!

Welcome back to the next instalment of tips on Reporting Identifiers.

In this instalment, I'm going to share some experience earned while trying to create reporting identifiers - that is to actually create a detailed list of items, which together represent a view and which individually are a specific subset of that view.

But first, a clarification!  Don't confuse a reporting identifier with the name of the field it is stored in, and remember that you could have more than one identifier in a single system field.

For example, in simple systems, it is common to combine department and nature views into the GL (because these systems don't have a costing module for example).

Tip 1 : Reporting Identifiers should be in separate fields.

When referring to a reporting identifier note that multiple identifiers can be represented in a single system field.

Now ideally, you will have enough system identifier fields to be able to have all your required reporting identifiers in separate fields.  If they don't, you'll have no choice but to combine them.  

Combining them is not ideal, because it increases the chance of misposting (as people select the wrong account) as well as significantly increasing the length of your item list!

Let's look at an example - we have one identifier representing nature ("what we bought") and using the GL Code field (this is really common) plus another responsibility view using a field called department code.

separate fields are the way to go!

Now, the same identifiers, but combined into 1 field, the GL Code field.

Longer, harder to understand, and easier to make entry errors.

As you can see, combining identifiers in a single field leads to a much longer list...imagine what happens when you have several hundred GL accounts?  

The other issue is that adding to  or changing your nature identifier (ie adding a new nature account, say Wages - monthly) means you have to add it to every department, instead of just doing it once.

So, always separate.  Always.  

Tip 2 : Explain the identifier

When you have a view/perspective, it is a REALLY good idea to document what the view/perspective represents.  That really helps when putting the item descriptions together, and also makes it easier for report users to understand what the view represents.

Not the best approach for reporting identifiers

I've found that the easiest way to keep identifiers on point and understandable is to come up with a phrase which is short, but catchy.

Example:

"Nature" views are common and most GL's are based on this view.  In this case, you can use a description like "What we buy or sell" which tends to work well.  It applies really well to P&L items - the balance sheet is a bit shakier, but generally the finance team knows what to include there anyway.

Some examples:

• Nature = "What We Buy" (eg salaries, consultants, cleaning, rental)
• Activity = "What We Do" (mining, processing, administration)
• Responsibility = "Who does it"
• Location = "Where we do it"

Having a short description which is easily understood can really simplify the process of creating good identifiers.

Tip 3 : Keep it Pure

A pure identifier is true to its description, so doesn't have any item descriptions which are outside the view.

Common fails in this area include:

Activity descriptions in a Nature hierarchy

In this case, "Admin" is not a "nature description".  Generally you can't buy "Admin".  The main issue with not having pure identifiers is it leads to confusion (or laziness!) when people actually code transactions.  

In the above example, where do office rentals go?  To 6140 Rentals?  Or to 6130 Admin?

Keep it pure and you are less likely to have miscodings and weird variances.

Location descriptions in Activity Hierarchy 

Here again, you can see that the example isn't pure, because we have location and activity combinations.  This often happens when the system is set up when the company only has one mine, but then it grows and adds another one.

Tip 4 : All numbers or all letters for your codes

What about the numbering system for your items?  From the examples above, you can see I prefer simple numbers.  Alternatively, I can live with all letters.

Why?

From a data processing perspective.  Having to switch between numbers and letters really slows down processing time.  

The other reason to stick with one or the other is that the codes sort more reliably if they are all one or all the other.

Oh, whether you use numbers or letter, NEVER start a code with a 0 or an O.  That creates huge issues importing into excel.  

In fact, don't use O because it is easily confused with 0 - and minimising confusion is a good thing!

Tip 5 : Simple logic in the code

In the system implementations we have done there has been a lot of debate about whether the numbers should have logic built into them, where the position of a number or letter means something.

The argument is usually that if people can work out the code, they are more likely to get the postings correct.

What happens when the logic breaks down?

In practice, that doesn't work.  People tend to memorise the codes they use often, so it is much better to have a shorter code.  

Generally, I find that really simple logic (eg for a Nature hierarchy, 1 is Assets, 2 is Liabilities etc) can work, eliminates a lot of really silly mis-postings but still allows freedom to add new codes as necessary.

The key thing is that too much logic reduces your ability to deal with new codes when the business grows (or, you end up with really long codes with lots of 0 or xx in them).  It also makes setting up the codes a nightmare - as you are bound to get a couple wrong.

* * * * *

I hope that you find these tips useful!  I can't stress enough how much easier reporting is when your codes are separated into separate fields, reflect views used in the business are are pure!

What do you do with your identifiers?  Please share your tips in the comments!