Hi, I am Burjis from India. I have just joined this forum and I find it very interesting. I would like to have an opinion on using Dimensions for filtering on inventory. First I will add global dimensions into the system (thinking of adding another 6 to make a total of 8 Global Dimensions). As of now Inventory is filtered on basis of:
Item Code
Variant Code
Serial No.
Lot No.
Location Code
Bin Code
I would like to add Global Dimension Codes to this filtration. This could make inventory really powerful. Ofcourse a lot of changes will have to be made throughout the system which I am ready. Any suggestions, criticism towards this idea would be helpful
Fields 65 Global Dimension 1 Filter and 66 Global Dimension 2 Filter are already there.
You can add additional filters but they need to have a function that is pre-determined.
How are they to be used? Who is asking for this further breakdown?
You must always ask these questions of the users, if there is no good reason for them, do not add. You will need to add Keys or amend existing keys as well as going through each report and form that uses the dimensions in this way.
Your system can slow down dramatically if you just add new Keys “just in case” someone needs them. I always make the user justify the need first.
As Colin has already said the Global Dimension 1 and Global Dimension 2 filters are already in the system. And I am not sure what version of Navision you are running but they should be FlowFilters on Inventory as standard.
Adding Dimension from 3 onwards will be a little harder as they are not stored directly on the Ledger Entry but are intsead stored in the “Ledger Entry Dimension Table”. If you really needed to be able to filter the Inventory FlowField by Dimensions 3-8 then you would either have to store the Dimension Values on the Ledger Entry (Create 6 new flowfilters on the Item card, modify the flowfield, and as Colin says add a new key in ILE), or find another way around it.
Thank You for your answers but I am afraid I was unable to communicate my question clearly, so I will illustrate it with an example.
Imagin the inventory of a Bicycle - 1000 as zero in the system. No ledger entries are available for Item No. 1000. I buy 10 bicycles at currency 100 and put it in the Area Dimension with value 30 (ILE Entry No. 1). Then I buy another 10 similar bicycles at currency 150 and put it in Area dimension with value 50(ILE Entry No. 2). Now if I sell 7 bicycles from Area 50, the resulting ledger entry will show the “Remaining Quantity” of ILE 1 as 3 and ILE 2 as 10. This is how it works in standard W1 Ver 4.0 SP2. Same for costing purpose. Based on FIFO my COGS would tell me that the cost per unit is 100.
I would like the Remaining Quantity of ILE2 to made as 3 instead, the cost to be 150 instead, which means I want Navsion to understand a physical segregation of items on the basis of Global Dimensions. The addition of extra global dimensions is needed only to facilitate this exercise and their addition itself is not my pain area. My pain area is the example just illustrated and I would like your views on this count. Till now Dimensions have been used to segregate Financial data. How do you think it would work if we extend it to segregate inventory. Do you think it would impair the present functionality of Dimensions. It is a big task and it is not for one client. It is a kind of horizontal layer that we wish to build under our other generic components that we sell in the market.
Imagine a multi location based Project Engineering Services Scenario.
Imagine an Item with multiple specifications as in the wood industry.
There can be many such examples and using Locations and Bins would not be correct. It would not sound correct. Besides the indenting levels that Dimension Values provide gives an added advantage of having 1 single field describing an nth level subtype of an item.
I think I see where you are heading.
Whent the Purchase Order is created, create a new Area dim value the same as the Purchase Order document no.
You will then have an automatic segregation.
You could aggregate a particular order by changing the Area dim value to a previous purchase Order.
You could then show the remaining value by Area.
I used something similar but for drop shipments where the Project dim value is created from the Sales Order so that the profit by Project can be reported. The most important part of my need was to make it automatic and transparent to the user.
Item application in Navision is handled in codeunit 22, function ApplyItemLedgEntry. This function figures out which positive entry a negative entry gets applied to. The default behavior is to require that item number, variant code, and location code match on both the positive and negative entries (lot and serial number must also match if you are using them). As your example points there is nothing that requires the dimensions to match (which, by the way, makes it silly to use dimensions in the calculation of physical journal entries - report 790, Calculate Inventory). I don’t think that it would be too difficult to incorporate dimensions into this matching logic; I would stick to global dimensions for performance reasons. If you only match based on global dimensions then you have to be careful about allowing the users to change the global dimensions.
Burjiis - I have a client that did exactly what you are proposing.
A critical factor to remember is that if you do this, accountants will want to reconcile inventory and gross margin by Dimension as well as by Location. It’s just our nature.
You will also need to change the code to make sure that the Dimension value on the outflow of goods matches that on the inflow. If you don’t, your margins will get right messed up, and you client will not be happy.
THANK YOU EVERYBODY for all your answers. Have got quite a lot of information from you all regarding this.
Quote JPoapst
A critical factor to remember is that if you do this, accountants will want to reconcile inventory and gross margin by Dimension as well as by Location. It’s just our nature.
You will also need to change the code to make sure that the Dimension value on the outflow of goods matches that on the inflow. If you don’t, your margins will get right messed up, and you client will not be happy.
UnQuote
Burjiis - If you are posting sales by dimension, is there a chance you will want to know what your inventory level is by dimension, and your margins?
Let’s say you buy 100LCY into dimension X, and the person entering the sale posts to dimension Y, either by accident or intentionally. If you were to run inventory valuations, filtered by dimension, the dimension X will show 100LCY on hand, while dimension Y will show negative 100. They offset each other, and unfiltered the value is 0, which is correct. There is no functionality built into NAV that tests or checks that dimensions match on the inflow and outflow of goods. So your inventory valuation, FILTERED BY DIMENSION, is out. Depending on how they do their margin analysis, that may show as out as well. The direct entry should be to the correct dimension, but margin won’t line up with inventory levels.
You may ‘never’ want to run statements or reports this way (filtered by dimension value), but never is a long time.
I spent a lot of time with and for my client reconciling ‘differences’ in their inventory. It always balanced overall, but they were looking at a dimension value level. We finally put some tight controls in, and made sure that they would always sell from the same dimension the purchase went to. This is not an entirely satisfactory situation, because if a ‘mistake’ is made on the inflow, it has to be perpetuated in the outflow. Either that, or they have to do an item journal to correct all the entries, and their volume is such that this is highly inconvenient.
