I work as part of an organisation where the general ledger coding system used seems incredibly complex. In part due to the nature of the sector and the number of bodies we have to report to. Following on from my previous sentence in particular the various ledger codes have resulted in strings which are sometimes in excess of 12 sections long. There are thousands of codes that could result in millions of different combinations and quite often the end user is expected to provide the correct code as part of an expenses claim for example. Not very user friendly.
Also what I find with the system is that in order to get a headline figure for a Travel budget, for example, we have to run reports at a transaction level and pivot them in Excel in order to get the headline figure. It would seem more logical to me to have the total figure for travel presented with an option to then drill down to the detail if this is required.
We are in the process of transferring to a new system which I am not actively involved in but would like to understand how the coding may be improved upon in generic terms. I am so used to working with the coding that I struggle to see how it can be improved on, simplified and rationalised and still provide the granularity required to satisfy multiple external bodies from a reporting perspective.
The coding as it stands tells us everything we need to know so I need to understand how to get the same information out of a simplified/shorter code without a human having to think through each section of it. Humans thinking through each section of the code is very time consuming, can result in lots of questioning, take up lots of time and result in the need to journal errors and close incorrect codes etc etc...
So....if a code is made up of ten parts and:
Section 1 = Defines what the activity is
Section 2 = Defines the expense type e.g. Travel and Accomodation
Section 3 = Defines what type of Travel e.g. UK / International (i.e. a further analysis of section 2)
Section 3 = Which Busines Unit
Section 4 = Which area within the Business Unit (i.e. a further analysis of section 3)
Section 5 = Various Activities (Optional)
Section 6 = Various Projects (Optional)
HOW would you create a simplified coding system to give you everything you need to see? Could you have attributes which are invisible to certain user groups which are not part of the code itself resulting in a much shorter simplified code / string? Whilst still being able to satisfy multiple reporting requirements for various bodies?
I realise this may seem a bit vague but I just want to see if anyone has any advice?
I cannot advise you on a system that I have no knowledge of (#2) except to say that your front end should not be inflicting upon end users the requirement to memorise a multitude of codes. The key fields should exist in the background (thats one of the issues that I have with Sage. Any system where end users have to memorise codes is a poor one).
That to me indicates that you may be looking in the wrong place. Rather than changing the key fields should you not be looking at improving the front end.
Also, any system with that sort of complexity I would move from heirarchic to relational. Maybe something like an SQL Server back end?
The above said of course surely the new system that you have purchased will dictate your coding and also will not without a major data cleanup excercise your historical data dictate that you maintain your existing background coding structure?
A couple of observations from your question :
Section 3 is defined twice. You list seven sections but state that there are in excess of 12 sections... How can you have "in excess of" for a key field? Do not define variable fields as key or you will hit serious performance issues as your database grows (assuming that your software allows variable key fields).
Why is Activity defined as sections 1 and 5? Is that an indication that normalisation (#1) of the data is required?
You indicate that you are reporting to external bodies so is not your data structure dictated by their expectations?
kindest regards,
Shaun.
#1 Normalisation
- Remove repeating groups
- Remove non key dependancies
- Remove part key dependancies
There is also a 4th normal form where you reintroduce duplication for performance but I won't complicate matters.
#2 and to gain knowledge of it I would be charging you £55 per hour (plus VAT), 8 hours a day, 5 days a week for at least three months. Systems / Data analysis is not a two minute job and if your employers are treating it as one or trying to do this on the cheap then the implementation is doomed to failure.
__________________
Shaun
Responses are not meant as a substitute for professional advice. Answers are intended as outline only the advice of a qualified professional with access to all relevant information should be sought before acting on any response given.
Can you not make this cloud based? Provide various people with various logins for their sections needed? Link into the SQL database? Are your supervisors open to using a developer? Dare I say this is too large for a single person to tackle on his own without any real IT experience. One hell of a mess could be created. How I'd do it - call a professional, this you can't bodge. If you're looking for brownie points at work, read up on databases, how they are work. Join an IT forum.
__________________
Johnny - Owner of an overly-active keyboard.
A man who can read, yet doesn't, is in no way wiser than a man who can't.
Mostly, I agree with what Shaun said - apart from his criticism of Sage's coding system. Which, in fact, is the closest I can think of in terms of what I've used to what you describe, breaking down components of the structure you describe into departments (which business unit), projects (err... which project) and cost codes within projects (activities?) and the rest in the nominal code (expense type, further analysis thereof).
But beyond likening it to that... I'm completely unable to comment because, as Shaun said, I can't comment on something I know nothing about. But I'll undercut him slightly and suggest £50 per hour plus VAT. (I know such a comment sounds facetious - but it belies a serious point: based on what you've said, in order to gain an understanding of the system and to therefore advise on how best to approach it, we would indeed have to devote a fair old chunk of time to gaining that understanding - and our time is our bread and butter.
The bottom line is that it sounds like you are using something very specialised - and unfortunately that requires specialist knowledge; general principals - which is what can mostly be offered here probably won't cut it. (However, sometimes surprises can happen. Is it off the shelf software, or something written specifically for the organisation concerned - or somewhere between the two? Identifying the software, if possible, might suddenly result in someone popping up and saying they know and have used it.)
Having said all of that, something that jumps out at me is this: You said "We are in the process of transferring to a new system which I am not actively involved in but would like to understand how the coding may be improved upon in generic terms."
If you aren't actively involved in moving to the new system, then understanding how the coding may be improved upon isn't going to be all that useful - if you aren't actively involved, you can't implement any improvements.
It sounds to me that what you really need to understand is how to better extract information from it.
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
Thanks Vince...I can feed back thoughts and I would like to have an understanding around these kinds of topics so that I can involve myself in discussions.
I studied database and SQL ages ago but it was fairly abstract back then as I was a student without real world experience / application, I think I just need to do some brushing up although I appreciate this is a very complex task. It's the complexity of the task which prompted me to get some input from other people despite not being "actively involved" so to speak.
Whilst the system we have now is a challenging system to use it 'does-the-job' and years have thought have gone in to it over a period of time. The thought of rationalising all the codes to fit a new system over a relatively short time frame does concern me.
Thanks for taking the time to reply, it's very much appreciated!
Jay3
