See poll :-
Out of intrest, please feel free to post a reply and explain how many Dimensions you use and if you have an performance realted issues to the Dimensions.
From a controllers point of view, I would like to use as many dimensions as possible. But getting users to care at all about entering dimensions is another thing. So, unless we can make them default then they don’t get entered. or don’t get entered correctly.
I would also like an easy way of adding dimension information to existing transactions. We just moved from Navision 2 to 4.0 and thus have 7 years of data that only has dimensions for departments and projects entered. As we find new dimensions we would like to track, we can only do it from this point forward.
It is possible to set default dimensions in all areas, it is also possible to set requirements for dimensions such as “Same Code”, “Code Mandatory” or “No Code”.
It is also possible to set dimension combinations - that is if a dimension can be used with another dimension.
You can also set dimension priorities so if two dimension values of a dimension are trying to be posted, which one “wins”.
We use just Global 1 & 2 - but since I run so many of our reports on Crystal - I wish we never set it up. It’s just eating up space.
I have doen a few conversions from BD to AD (before dimensions and after dimensions), ans yes this is a common request, and yes its not all that difficult.
do you want to elaborate, Here is what I tried, mind you I don’t have application designer, so limited acess to system
I figured the dimension entries are stored when posted in the Ledger Entry Dimension table. So, I used MSAccess to export the Item ledger entry table, I already had a table with the item no, and dimension code I wanted, for example Item XYZ dimension code Inventory = Heavy ( which for us means part xyz is a Heavy duty item, it could be light duty or medium duty.)
so, I used the item ledger entry table linked to my item dimension table and created a file which contained a ledger entry dimension for every item ledger entry. so my file looked like this
Table ID = 32 (Item Ledger Entry)
Entry No = entry no (from the item ledger entry table)
Dimension code - Inventory
Dimension Code Value = (what ever the default dimension for that part number is)
I then created a dataport and imported these entries into the Ledger entry dimension table. They all came in fine and all looked well.
I then create an Inventory analysis view, using the dimension Inventory and had it update the analysis view. But nothing showed in the analysis view when I was done. What did I miss? this is all in a test company, so no actual data was harmed in the making of this test.
Our company is in the process of installing Nav right now. I would like to know from the poster above (Harry Ruiz), why even using global 1 and 2 dimensions is considered as eating up space. To be honest, our implementor does not do a good job of explaining thoroughly the impact of dimensions and its best-practices so we’ve had to grope in the dark ourselves.
At the moment we are probably going for 7 Dimensions:
Department / Sub Department.
Branch City / Area.
Type of Medical Expense. We intend to attach this one to COA account “Medical Expense” to capture what kind of medical expense occured . Content is: Hospitalization, Doctor’s Visit, Glasses Replacement (Frame), Glasses Replacement ( Lens)
Type of Target Bonus. Target Bonus is a sales promotion tool we use to push shops to buy more of our products. This Dimension will be attached to COA “Target Bonus Expense” to capture what kind of Target Bonus Expense was recorded.
Telephone Charges Reimbursement. Our acct department wanted this as a dimension because we want to capture the different types of telephone reimbursement.
Vehicle. Here we will input each of our company’s cars licence plates so we can track each car, and ultimately each department’s fuel usage, toll fees, etc… This dimension will be attached to the COA related to fuel usage, toll fees, etc…
Employee. Here we will input all of our company employees so we can track each employees medical benefits, expenses, reimbursements, etc… This dimension will be attached to the COA related to the items above.
Since we have had to basically figure out dimensions ourselves, in your opinion, are we using them correctly? Do you have any suggestions?
Thank you all.
there is one notice that you have to know. dimensions are not connected to any data in navision whatsoever. Which means, if you want to have employees as dimension, you’ll have to enter every employee as dimension value separate and there is no synchronization between these values and values in Employee table. For any kind of sync, you’ll have to do it your self (or your NSC). So keep it in mind.
For 3,4 &5 I would not have a separate dimension, but you more g/l accounts (in sub-section / same indent), as they are essentially variants on the same type of expense. Vehicles and employee are better examples of dimensions as they are attributable to a number of different types of expense. Having said that what you are doing is not wrong, but this way reduces the dimensions and therefore overhead on the system and simplifies (in my opinion) input.
I am not sure exactly what you did, but in general it shoudl work. Though for some things you do need also to import Global dimensiosn 1 and 2 to the journal tables. You can do this by removing them form the setup, and then adding them back again, this will resync them after your dataport.
In general thought the dimensional detail needs to be exact for it to work. You may have just missed something simple.
As was mentioned above, dimensions are very often over sold with Navision. Basically all dimensions are in Navision is a flag added to an entry that says “this entry relates to xyz department or cost centre”. Based on that you can generate reports and create analysis views of your data. But just setting up dimensions is just the begining. Firstly many of the reports you may expect are not there as you would expect, and since the dimensiosn are flags in secondary tables, you can’t sort and filter ont hem as you could with fields in navsion tables.
Unfortunately though its all too easy during the slaes process to simply say “oh yes we can do that with dimensions”.
So addressing your issues one by one:
This can be done as one or two dimensions in Navision, depending on how you need your reporting. If you can do it with indented dimensions, then one will work fine. Basiscally this is a proper use of dimensions in Navision, and would probably be your global dimension 1.
In addition, how is this to be used. If it is related to Customers addresses etc, Then you may want to look at some method of enforcing this to ensre the data is correct. Basiscally this is a proper use of dimensions in Navision, and would probably be your global dimension 2.
I would need to know your business model, and why you need these broken down as Dimensions. Some how it just does not seem right, but more information wouldbe needed to make a proper assumption.
In my experience, Dimensions are not suitiable for handling any forms of bonuses, and I think this needs review.
I would be processing the Telephone expenses though Purchase Invoices, and depending on the reporting, there are many ways to do this. My prefered method would be to modify Resources for purchasing, bt somehow I don’t think you will get the flexibility by using dimensions.
Dimensions can probably do what you want here, but I would also take a look at work with Fixed assets, or as per 5 above use purchase resources to handle this.
Is this similar to 3?
Another thing to keep in mind, is that its not a huge job to add Global dimensions 3 and 4 if needed, and this often can make reporting a lot simpler.
A. Can you explain what you mean by “Another thing to keep in mind, is that its not a huge job to add Global dimensions 3 and 4 if needed, and this often can make reporting a lot simpler.”
I thought that, as long as you use a dimension, it doesnt really matter if its global or not, because you can always create a report and analyse by dimension (aren’t all dimensions global in a sense? because you can tag them to any COA, journal, etc…).
My question is, why and how does it make reporting easier, when you add a 3rd or 4th global dimension (as opposed to having the same values in a non-global dimension)? … Does that make sense? [:^)]
B. To explain a little more about our medical plan…we don’t use insurance. We cover our employees (and their family’s) medical costs. And they can be categorised as (1) hospitalization cost and (2) outpatient cost.
So, with the COA “Employee Medical Expense”, we attach 4 dimensions to it:
- Branch (City)
- Type of Medical Coverage (Hospitalization, Outpatient) … (I’ll ignore other entries in here for this discussion’s purpose)
- Employee (Name)
This way, for every journal involving medical expenses recorded into the system, we can later analyze:
- What the medical cost for any department in any branch was, for a certain period.
- For each employee (and their family), what their medical expenses was, during a certain period, broken down into (1) hospitalization cost and (2) outpatient cost
We need to do this because we operate in a third world country and unfortunately this system has been abused in the past. Many hospitals and doctors dont have a good system, invoices tend to be hand written and hard to trace so its easy for people working in remote branches to “work together” with a doctor or hospital to overstate hospitalization or medical costs. So we need to be able to run detailed reports that can highlight any irregularities in the use of this facility.
C. The same principle applies to analyzing the cost of Service, Maintenance, Fuel, etc… for all of our operational cars. For COA accounts related to operational vehicle expenses, we will attach dimensions: (1) Branch (City), (2) Department and (3) Vehicle (Plate number)
D. My last question is, is it possible to make a modification so that the Employee and Operational Vehicle Dimension can take and self-update their values from the Employee and Fixed Asset tables? Our implementor has told us that this can’t be done (or if it can, it is very very difficult to do and a major modification).
Thanks very much.
At first glance the biggest differnce between global dimensions and "normal " dimensions, is that the Glogbals are stored in the GL entries. But it goes a lot further. These two dimensions are there mainly for compatibility with older verisons of Navision, but you cna do a lot more with them than with Analysis views.
Basically when the field is in the Entry Table, you can do alot more with it. IN reports basically you do it either way, but for on screen work, there is so much more you can do with Globals. For example, you may use a dimension to seperate Vendor Invoices, then GL reporting on those dimensions is not a problem, but if you would like to go back to the vendor card, and take a quick look at the amounts spent to that vendor for that Department, its a lot of programming work, compared to a few minutes.
So for that reason, some cleints will add another 2 dimensions as globals.
Of course there are more to businesses use of dimensions than just the Dimensions tables. Posting Groups Responsibility centers, Locations etc can all be used to dimensionalise the company information. Every company is different, and each Business pricess needs to be analysed and resolved the best way, not jsut by saying “Oh yeah dimensions can do that”.
At first glance I would say best would be create the Employee as a Vendor, create the medical costs as Resources, then you can create Resource/Vendor reports to get this data. The cost to convert resources to be purchasable is not a lot, but it will give you better control, and you will be able to easily print out balances using the standard Navision Vendor statement reports etc.
PS Why isn’t purchasing resources standard in Navision [:(]
C I don’t have enough information to comment.
D. Yes its tricky, but not a big job, and not verly complex, but everything is relative. You just need a new table that stores certain defaults for the dimensions, and then extend Default Dimensions (like on Vendor anc Customerr card) to the areas needed. I have only done this few times, but it seemed worth it becuase it makes life easier for the users, and thus they are more likely to take care and get the data correct.