Dynamics NAV Dimensions: Part 2—Moving Between Systems
In my last post, I went over NAV dimensions setup, using sales invoices for my examples. I also mentioned how dimensions can be assigned to many, many different kinds of data in NAV.
In this post, I’ll go over how dimension values work with different setups. Again, all my examples use the CRONUS USA sample company.
Dimensions—Assigning Default Values to Master Data
Let’s start with “Items.” Items don’t have default dimensions assigned in CRONUS USA, so we can look at how to set them up.
We’ll choose a dimension that isn’t assigned to any of the customers in the database. This way, we can avoid issues related to order of defaulting (which may be the subject of a future post).
Now let’s get started.
On the item card, let’s choose “1000 Bicycle”:
We then click “Dimensions” at the top.
(Alternatively, you can use the shortcut key Ctrl-Shift-D. This shortcut key displays dimensions in NAV when you’ve highlighted a record on a list or displays the dimensions for the record displayed in a document or card.)
“Dimension Code” and “Dimension Value Code” are fairly straightforward.
The screen is titled “Default Dimensions” because if the item is used in a transaction (like a sales invoice line), this value will default into the transaction.
(You can set up values for other dimensions that aren’t going to be used in financial transactions and haven’t been chosen on the General Ledger Setup page.)
If we enter 1000 Bicycle on a sale transaction, then “Salescampaign Code” will default to “SUMMER”:
The other dimensions were set up on Customer.
By the way, here are the key fields I entered:
General Fast Tab:
Sell-to Customer No.:…………… 20000 – Selangorian Ltd
Customer PO: ………………………. DEFAULT EXAMPLE 1
Document Date: ………………….. 8/26/2016
Posting Date: ………………………. 8/26/2016
Lines Fast Tab:
Type: ……………………………………. Item
Quantity: ……………………………… 20
Unit Price: ……………………………. Defaulted
Tax Group Code:…………………… NONTAXABLE
And as you can see, everything posted fine.
Default Dimension Value Posting
So that’s all well and good. But what about value posting?
You saw the basic defaults above. We didn’t touch anything so the posting went smoothly.
But when value posting, you have additional options to choose from:
Leave this selection blank: The system will perform no special checks when the item is used with this dimension on a financial transaction.
Select “Code Mandatory”: The system will require some value (although not necessarily the default value).
(We’ll deal with “Same Code” and “No Code” in a minute.)
Let’s give Code Mandatory a try. Let’s change the dimension to Code Mandatory:
We’ll use almost the same invoice. The value SUMMER still defaults in:
But now, let’s remove it:
If we try to post the invoice, we receive this error message:
Because it’s code mandatory, we have to put something in that field.
Let’s update the field to “WINTER” (which isn’t the default):
Now, it posts no problem. As long as a value is entered, NAV will accept it.
Default Dimensions—Same Code
You can probably guess how Same Code works. But let’s walk through it anyway.
We go back to the item and switch value posting to Same Code:
Now, we create an invoice, changing Salescampaign to “WINTER”:
When we try to post, we get this error message:
Which is what we would expect.
Default Dimensions—No Code
For our last trick, let’s change Value Posting to “No Code”:
We insert a value in Salescampaign:
And we get this message:
This is also what we would expect.
Default Dimensions—Is Code Mandatory Always Code Mandatory?
So far, so good.
But sometimes, Code Mandatory can get more complex.
When an item is set as Code Mandatory, each posting requires a value. But you’ll see that all the other dimension values on the line came from the customer, not from the item.
Let’s take a closer look.
We start by looking up the customer and checking its dimensions:
As mentioned above, you can also do this by using Ctrl+Shift+D:
We see the dimension values that have been assigned to the customer:
Let’s focus on DEPARTMENT (as it’s one of two global dimensions that shows up on almost every page).
We make the Value Posting for DEPARTMENT Code Mandatory:
Let’s enter another sales invoice to show how this works.
We enter the same data we used before.
And we can see that Department Code has defaulted to SALES—pulling it from Customer:
Let’s clear the Department Code field and post the entry:
Surprise! It posted. Why did that happen? Didn’t we set DEPARTMENT set as Code Mandatory for the customer?
To get to the bottom of this, let’s look at the general ledger entries for this transaction:
Now here’s something interesting. The Department code is missing from the Sales and COGS accounts. But it’s still there on the A/R. What happened?
The G/L entries were driven by two different values on this transaction. A/R is driven by the customer. So, Code Mandatory applies to the customer. And the dimension showed up.
Sales and COGS are driven by the item. And the item didn’t care about department. So it went right through.
This example demonstrates why testing is so important when working with dimensions.
In my next post, I’ll talk about how to deal with multiple sides in a transaction as well as dimension combinations.