Resolving NAV dimensions errors (part 10 of 15)

Posted: March 22, 2013 | Author: kpeters | Filed under: Uncategorized | Tags: code mandatory, dimensions, Dynamics, errors, Microsoft, NAV, tips and tricks | Leave a comment

Error messages related to dimensions can be the bane of a dimension-using NAV user’s existence unless you know how to properly deal with them. The number one thing I tell my end users is, “if the error message has the word dimension in it, the error is generally something you can resolve yourself”. Let’s go through three dimension errors from my system; we’ll resolve each one as we go.

This message says the end-user needs to select a dimension code for team on the first line of this invoice, where they’ve entered general ledger account number 51320. For whatever reason, NAV counts lines by the 10,000, so 10000=line 1, 20000=line 2, etc. The rest of the error message is pretty self-explanatory, but is presented in an “out-of-order” way that doesn’t quite read as well as plain English. This error has occurred because we’ve set a control on the general ledger account 51320 of code mandatory for team. The end-user needs to enter a team code for every transaction that posts against this account number.

The dimension value of 522120 on the list of dimensions for project has been blocked. You can’t use it/you don’t want to use it/you shouldn’t use it. Our company goes through annually and blocks project numbers that have not been given any budget money. If I block a project, I mean it – I really don’t want anybody posting anything against it. For this error, either the person made a typo, or they were given bad coding so the solution is to either fix the typo or get a correct project number.

This is an example of a team and project combination that has been blocked for use. We do this on purpose in order to keep from making errors and to avoid needing to make reclassifying entries. For this error, the person entering the information either needs to correct a typo or get a correct project number (or team number).

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

NAV default dimensions and value postings on the chart of accounts (part 7 of 15)

Posted: March 19, 2013 | Author: kpeters | Filed under: Uncategorized | Tags: Account Schedules, chart of accounts, code mandatory, dimension value code, dimensions, Dynamics, financial reporting, master data, Microsoft, NAV, tips and tricks, value posting | Leave a comment

Value postings on the chart of accounts are your next line of defense to ensure a solid dimension strategy execution. You could probably be content by only applying value postings to your master data, but by adding value postings to your chart of accounts in addition to your master data, you are adding a layer of consistency and control into your transactional posting.

But what could go wrong, you might ask? How would the value postings on your master data fail you? If you are using code mandatory with a default value posting, what could possibly go wrong? Here’s what could go wrong – you could forget to populate the dimensions on a new master data item. Let’s say you set up a brand new item, or maybe a big group of items; how about a whole season’s worth of new items? You set them up and forget to populate the dimensions on them. You could go days, weeks, even months (hopefully not if you’re watching your financials) with these new items merrily populating your system with blank dimensions compared to all of your other items that are populating with default dimensions. Once you catch the error, you’ll need to track down all those blank pieces of data and do journal entry reclassifications to all the effected accounts, with all the effected dimensions, in order to fix your financial reporting.

[Sidebar: Easiest way to do this is to run an account schedule covering the effected accounts with the dimension filter set to ” (that’s two single quotes, the symbol for blank in NAV). You can then see every transaction that’s posted with a blank dimension, and use that to construct your correcting journal entries.]

If you’d like to avoid all of that pain, set up value postings on your chart of accounts. Here’s the trick: your should not use a default dimension value code together with your value postings. What you want to accomplish with this is to have your chart of accounts act as a control point for your postings. If your chart of accounts carry a code mandatory on the accounts, they are requiring that they receive dimension data from the master data card before they will allow any transaction to post to them. So, what happens when that rogue item with no dimensions tries to post through? The code mandatory setting on the general ledger account prevents it from posting, ensuring you never end up with any blank dimension postings in your transactions.

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

NAV default dimensions and value postings applied to master data (part 6 of 15)

Posted: March 18, 2013 | Author: kpeters | Filed under: Uncategorized | Tags: chart of accounts, code mandatory, dimension value code, dimensions, Dynamics, financial reporting, master data, Microsoft, NAV, same code, tips and tricks, value posting | Leave a comment

You’ve decided you want to use dimensions, you’ve picked a strategy, you have people in both finance and IT on board with the plan, and you even have two global dimensions and a few shortcut dimensions all planned out. Now what?

Now you need to go through the process of applying your dimension strategy to all of your master data using value postings.

Master data are all the things in NAV that have a “card”. When you think about the sales process in NAV, what might have a card? How about the customer card, the item card, or even the salesperson/purchaser card? Where else are there cards in NAV? How about the vendor card, the bank account card, or the fixed asset card? All of this is master data you will use when applying dimensions to your system.

Value postings are the requirements you set on your master data when defining dimensions. For the sake of an example, lets say we’re going to focus our dimensions on the item card. You have four choices:

1) Leave the value posting blank. This will impose no requirement for the dimension to be filled out and is the same as not defining a dimension.

2) Choose code mandatory. This option can act in two different ways and is highly useful. If you leave the dimension value code empty, setting the value posting to code mandatory will require the end-user to fill in a dimension value code from the defined dimension code listing before the transaction can be posted to the system. If you fill in the dimension value code with a selection from the list, essentially a default value, any transaction using this item card will populate the dimension value code with the code you have pre-selected as a default. However, if necessary, the end-user can change the value to a different selection.

3) Choose same code. You might think this would be a fantastic option, offering the highest level of control. It is true that choosing same code is the most restrictive. By choosing same code, any transaction must use the code defined in the dimension value code. This can become problematic when your company changes and you need to redefine your default values. Dimensions can be pretty pervasive, getting into places you just didn’t think about when you set them up. For the most part, they’re harmless, just little pieces of data hanging out waiting to be accessed for reporting. But sometimes, when used together with same code, they become vicious nasty little roadblocks. I’ve heard many a horror story of accountants struggling with adjust cost or inventory adjustments or even trying to get sales order postings to finalize because they’re using same code and have needed to make a necessary change.

4) Choose no code. This is the option you choose if you want to tell NAV to never assign a particular code to the item. You could do this if you wanted to reduce the possibility of error from someone trying to apply a dimension that belongs to your customer card to your item card accidentally.

As you can probably tell, my recommendation is to use code mandatory in most situations. It offers the most control over your data while also allowing for necessary flexibility as your business changes. Using code mandatory avoids the problem of “optional” data by requiring some type of data to show up in the dimension value code, whether you put it there as a default to be automatically populated or whether you’ve left it blank so someone down the line can populate it when it is time to make that decision before posting. Using code mandatory can also be a great source of efficiency if you can choose to use default values. If you can decide how to make your dimension postings as automatic as possible, this really can run completely in the background, populating your system with luscious data to be reported on later, with no effort or decision-making required by you. By using default values, you also gain accuracy in your postings since the computer is making the decision the same way every time, whereas you might not be that consistent if you had to define the values manually all year.