In sage, you can create sub codes to every other code.
So using 3000 as an example
3000 - Partner 1 - balance brought forward 30000 - Partner 1 - capital introduced 30001 - Partner 1 - cash and transfers 30002 - Partner 1 - self assessment and NIC paid by business 30003 - Partner 1 - miscellaneous drawings
3001 can then be Partner 2
Then on your accounts, you can just group the drawings codes together - and its handy if the client queries drawings.
HTH :)
Hi Michelle,
I noticed your handy tip the other day and filed it for future reference. However, I've just noticed this advice given in the Excel comment on the Refn field (Nominal Code) in the [Nominal Record FULL template.xls] Sage import template:
Note: You can make your new nominal code up to eight numbers long. However you cannot mix your numbers, for example, you cannot have a four number nominal code with a six number code in the same nominal structure, as this will make your Balance Sheet and Profit and Loss reports incorrect. You must therefore be consistent.
As a certified anorak, I wondered what the problem would be. In the Practice company I set up a new nominal code 40011 in Sales | Product Sales and got this warning:
The nominal account code does not fall within the range for an account of the required category. Are you sure you wish to use this code?
It happily created the code and presented it between accounts 4001 and 4002. The COA definition still defines Sales | Product Sales as Low - 4000, High - 4099. When I checked the COA it reported no errors. When I posted to the account and performed a year end it rolled into retained earnings fine. It seems like the COA definition behaves in a way that could be expressed as:
Sales | Product Sales comprises all nominal codes that begin with anything between 4000 and 4099 inclusive.
Admittedly my testing hasn't been exhaustive, but I can see nothing wrong with variable length nominal codes.
Have you, or anyone else, ever encountered incorrect Balance Sheet or Profit and Loss reports as a result of having variable nominal code lengths?
Hi Ive just received the same message ( The nominal account code does not fall within the range for an account of the required category. Are you sure you wish to use this code?)
Ive never used one with an extra 0 on the end, usually start them with a 1 and have had no problems in my ancient sage but do have in my newer version. Havent tested it out yet though.
__________________
Joanne
Winner of Bookkeeper of the Year 2015, 2016 & 2017
Thoughts are my own/not to be regarded as official advice,which should be sought from a suitably qualified Accountant.
You should check out answers with reference to the legal position
You can Mix different numbers of digits it is not a problem but they are not "sub groups" there is no hierarchy, things are not rolled up. They are all just separate nominal codes.
I can think of things that might happen if you exported to another system and the nominal codes were treated as numbers not alpha numerics where the range 4000 - 40009 would include all the numbers in between
-- Edited by BruceDenney on Friday 17th of October 2014 04:14:35 PM
__________________
For just about anything Sage :- switch to renting, pay-as-you-go sage support, sagecover, upgrades, application integration, reports, layouts, analysis or any other help making life with sage easier/less time consuming Contact me.
Yes, I agree. But don't you think it is confusing that 5000 wouldn't be in the range defined as Low - 4000, High - 40999?
Not really - I've always understood the nominal coding to work the way it does. (Well, for as long as I can remember, anyway - but I can't say for certain if I'm remembering correctly all the way back to when I first used Sage in the mid to late 1800s 1980s!)
Clearly Sage treats the codes as strings of text, not numbers.
Indeed it does; They are alphanumeric strings (even though they consist only of numeric digits).
Consider it the other way around, though. The suggestion earlier in the thread was to add a fifth digit to mark the added codes as "subgroups"* - but if Sage did treat the nominal codes as numerical, those subgroups would come after nominal code 9999, and therefore wouldn't be in the right place numerically.
To expect that to work, you can't expect the codes to be treated numerically - or, conversly, if you think the codes should be numerical, you can't expect that to work.
Do you think it is this confusion that Sage is trying to avoid with their guidance?
What guidance? I don't think I've read a Sage manual in donkey's years. :)
* As Bruce says, they aren't "subgroups" per se, since the nominal codes simple are what they are. There is no enforcement of a hierarchy - but it is efficient to organise things in a hierarchical manner. (The default nominal codes form a basic hierarchy, but it is entirely arbitrary, and they can all be changed as you see fit.)
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
The Excel comment on the Refn field (Nominal Code) in the [Nominal Record FULL template.xls] Sage import template:
Note: You can make your new nominal code up to eight numbers long. However you cannot mix your numbers, for example, you cannot have a four number nominal code with a six number code in the same nominal structure, as this will make your Balance Sheet and Profit and Loss reports incorrect. You must therefore be consistent.
Ah - I didn't realise that guidance came from Sage; I assumed you were quoting the help from some third party Excel thing that works with Sage.
Excel will see the nominal code field as numeric, so if you have conditional formulae that, for example, tot up anything whose nominal code is between 4000 and 4099, it's going to miss something with a code of 40990, since that's 36891 higher than the highest number in the range - and, here, extending the range as I suggested within Sage won't work, because 4000-40999 is obviously going to include 4100-9999 as well. (This is basically what Bruce mentioned in his final paragraph.)
And if that guidance does come from Sage, it's because they're aware of this pitfall. So the answer to that question is therefore "yes".
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
I haven't had any issues with reports. I have just made sure the chart of accounts was amended to include the sub codes, as Vince says. I don't like departments, so I create bespoke PL's instead, they allow me much more freedom with the companies whose coding structures I have implemented. These all seem to be going ok.
That said, you lost me after the first sentence Ian! LOL
For a moment there, I had a momentary lapse of reason - I was going to come to Sage's defense and point out that it *isn't* misleading advice for the reason I've already given.
However, I've now come to my senses.
Well, what I've done is looked further to find out exactly where Sage have said that. You did say where - the Excel tooltip in the 'template' for importing nominal records. Until a few minutes ago, I still hadn't clocked that as a template to demonstrate the file format for things to be imported into Sage itself.
I didn't even know those Excel templates existed!
But now I've seen it for myself, I agree that it is indeed misleading advice. Sage don't seem to be aware of what their own software can do and cope with.
(Or maybe they're just trying to idiot-proof their instructions, on the basis that an idiot might not realise they can update the range in the COA to include any longer codes!)
Aside: I have just noticed that in my Sage's import dialogues, the option to select an Excel file for importing is greyed out; I can only import CSV files.
My best guess as to why it is greyed out is that the software has cunningly detected that Excel is not installed on my system - and if that's the reason, Sage are unmitigated idiots. I wonder if they realise that on modern computers, it's possible to pass files around - even from one computer to another? If not, they'll be truly amazed to discover that it's even possible to create files for one program in a completely different program altogether!
There. Insulting Sage really makes up for almost defending them. I feel better now.
Edit: "dialogies" ? They're "dialogues" !
-- Edited by VinceH on Monday 20th of October 2014 07:49:29 PM
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
<aside>I think that Sage uses bits of Excel to read the excel formatted sheets and so if it is not installed it can not use them.</aside>
__________________
For just about anything Sage :- switch to renting, pay-as-you-go sage support, sagecover, upgrades, application integration, reports, layouts, analysis or any other help making life with sage easier/less time consuming Contact me.
Ah, okay - if they're making calls to DLLs that are part of the Excel installation, that's forgivable.
If they really are doing that: Other software is able to read Excel files without doing that - it's one of the reasons I don't need to have Excel installed!
(Edit: I said "the Sage Installation" - D'oh!)
-- Edited by VinceH on Tuesday 21st of October 2014 01:59:50 PM
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
