NAV dimension priorities (part 9 of 15)

Here’s the deal with dimension priorities. Depending on what you’ve chosen for your dimension strategy, an entry could have more than one dimension proposed at the time you post it. When this happens, NAV needs a way to break the tie, and that way is dimension priorities.

This handy-dandy table allows you to be in control by choosing which table will take priority over the other if NAV is forced to choose. What happens if you don’t define the priority? This is where NAV’s built-in tie-breaker comes in. If you don’t define the priority, NAV will choose the table with the lowest Table ID number.

One sure way to avoid needing to do this at all is to think through your dimension strategy really carefully before you commit to it. If you define team as a dimension on both your customer master data and your item master data, and you give a customer and item different default dimensions, what’s going to happen when you post a sales order? You’re going to get a conflict where the system has to choose. Think through your strategy and I bet you can find a way to make sure that team only corresponds to customer and you could give a different dimension designation to item. By doing so, you’ve automatically designed your system not to have a conflict in the first place.

Keep reading this month as we continue our series, 15 Days of NAV Dimensions.