I would have a look if it worked with any package other than sage.

To be honest with my clients there is not a huge need for traditional management accounts. Most get a monthly report, but this ranges from one page of graphs to 5 pages. Most don't get a sheet of numbers because they don't understand it so it becomes a waste of my time and theirs.

I try to give them the information they want/need quickly

Kris

I'm not interested in the product per se, but a quick glance through it and some thoughts spring to mind on how I think it could be improved.

On the dashboard report on page 3, in the profit margins section, where it says "For every £1,000 of sales, the company is making..." - if someone presented that to me I'd feel they were being somewhat patronising, and I'd be inclined to say the vast majority of people I've worked with/for would as well. I've always found that my clients have a very good understanding of their own accounts, and are quite happy with profit margins expressed as percentages. Of course, this may not be true across the board, and I've mostly had a good bunch of clients. :)

Related, to that, as well as the gross profit margin being expressed that way, you're doing the same for the net profit. Why? The whole point of calculating the GPM is because, typically, the direct costs should increase/decrease proportionally with the sales; the GPM staying reasonably consistent reflects that, and if it strays there's something to investigate. The same is not true of the net profit, though, because overheads aren't affected by the sales in the same way, and are more likely to remain broadly at the same level barring any significant changes. Calculating a percentage (or expressing it as proportions of £1,000s) strikes me as just throwing in extra information for the sake of it, to make it look more impressive (subject to my comment above about the way it's expressed) - but in reality, I don't think it's information that's genuinely useful.

On many of the reports, you've include the nominal codes on each line. I think that sort of detail is likely to be offputting/distracting (delete as appropriate); I reckon most SME's wouldn't give two hoots about the nominal codes, and are more interested in what the line represents; "Sales" rather than "4000 - 4009 Sales" for example. The nominal coding is for the people that do the nitty gritty work, not for those who want to see the results of that work.

And finally, drop the pence!

Having said all that, it's all just my opinion after a very quick glance. Feel free to ignore me. :)

VinceH wrote:

---

(And saying "when that's out boy is that fun to find and even harder to fix" makes it sound like it was a manual process!)

---

Basically it is a manual process.

Every report between start of run and the error needs to be checked to find where the error occured and then when the point of error has been found you have to step through several thousand lines of code to find out why it went wrong.

Doesn't help of course that these old programs will have multiple routes through them that nowdays would be seperate modules but using the tools of the time processing was faster by keeping the code together.

Nowdays you say to someone "if it doesn't peform it doesn't work" and you just get a blank stare as tweaking code for performance doesn't seem high on peoples priority lists anymore when machines are now so fast anyway.

Anyway, the issue would no doubt only be down one branch of the processing and the program showing the error may not be the one with the fault but at least you know that it was one of the programs before that one.

All in all an awful lot of scribbling down flow and structure charts and working through the flows manually to work out where the issue actually lies.

Think that I did that for too long as now, even when doing accounting projects I still think in the same way as proven by the flow charts on my office white board at the moment.

I think that perhaps people like us actually think in a slightly different, more logical way Vince.

On the "here's some money, write me something" line I remember in my first weeks of working for a management consultancy being given a manual, put on a train and expected to be an expert on CSP (IBM Cross System Product) by the time that I got to the meeting!

Thinking of some of the experts that I've encountered in my time I don't think that my experience there was an isolated incident!

 

p.s. edited because how the heck did I just write IBM as ICB!!!

-- Edited by Shamus on Thursday 6th of September 2012 12:44:43 PM

If that's information people have actually asked for then I can't argue with that.

As for the roundings, that's not an uncommon problem and - speaking with my programming hat on - it's a fairly trivial thing to get around.

The starting point is to actually keep a tally in your program so that it spots when there's a rounding error, and how much it is.

The simplest solution when there is such an error is to adjust one figure by the relevant amount. I do this if I'm doing it manually - but his method sucks due to it being a lazy get-out if you're a programmer! :)

Programmatically, the clever solution is to identify those closest to being edge cases and use them if need be. (For example, .50 would normally be rounded up, but you could get away with rounding it down if the rounded tally was £1 out in the right direction.)

The starting point is to have a second (two/three dimensional*) array alongside the original and rounded values. As you round them, you put the original pence value in this second array, and a pointer to which item in the original array(s) that item relates to. (Although at this stage there's a direct correlation, in that the fifth element in this array is the fifth element in the original arrays - and Bruce Willis isn't involved, by the way - by the end, this array will be sorted; hence the need for pointers.)

Come the end of the roundings, if the tally reveals there's a rounding error, you can then use this second array to determine what to adjust.

Sort the new array based on the pence values**, then scan through it to find the nearest to 50p.

What you then do is work upwards or downwards, depending on which way around the rounding error is, and change the way one or more figures are rounded depending on how close they are to being an edge case. If the error is £1, just change the rounding on one edge case figure, if it's £2, change two, and so on.

Sometimes, there might not be anything that could truly be called an edge case - if you need to round up by a squid, and the closest is .36p, then that's what you round up, but it's probably unlikely to get that bad unless you feed it a really contrived set of numbers.

* If it's just a single column of positive numbers being totalled, a two dimensional array will suffice. If it's a mixture of positive and negative numbers - or a situation where different sets of numbers are grouped together, such as a set of accounts (where one set is likely to be credits, and the rest debits), then a three dimensional array is probably better; store all the pence values as positive, and the dr/cr status in the third dimension - and use that to determine which way (or whether) the rounding should be altered.

** Or you could be really clever and apply a clever algorithm to them first (or as you're putting them in the array in the first place), that will result in the edge cases being at the top and bottom of the sorted array, rather than the middle.

"Basically it is a manual process."

Sounds like a complete nightmare - but given the nature of the systems/values involved, that doesn't entirely surprise me.

"I think that perhaps people like us actually think in a slightly different, more logical way Vince."

The programming background is probably the key thing, here: programming, by its very nature, means you have to think in a logical way in order to work.

It also helps to think outside of the box when solving some problems. I've occasionally said that I can think so far outside the box that the box isn't even visible on the horizon anymore, and I'm not even sure it ever really existed in the first place. :)

"Thinking of some of the experts that I've encountered in my time I don't think that my experience there was an isolated incident!"

Amen to that.