Overview pages of released platform hotfixes and application hotfixes for Microsoft Dynamics NAV 2013 are now available on PartnerSource and CustomerSource at the following links:
See also hotfix overview pages for Microsoft Dynamics NAV 2009 SP1/R2 and Microsoft Dynamics NAV 5.0 SP1:
Introducing RapidStart Services for Microsoft Dynamics NAV
If the phrase “IT implementation project” makes your palms sweat and your heart beat faster, this blog entry should be good news. It’s about a new service that we developed as a direct result of customer feedback. We listened when customers told us that a simpler and faster deployment would mean a lot to them. And we know how important it is for you to be able to stay focused on your business.
That’s why we built special functionality that improves the implementation process -- right in the Microsoft Dynamics NAV solution. Functionality that makes the entire process smooth. RapidStart Services for Microsoft Dynamics NAV accelerates deployment time, improves the quality of the implementation, gives you better control of the whole process and reduces the cost. Here’s why.
RapidStart Services for Microsoft Dynamics NAV actively involves you in a way that makes the entire implementation process transparent. So not only is the implementation fast, but equally important, it is of the highest quality,
Simplifies Configuration and Data Migration
The new services include four main types of tools that simplify data migration and configuration and ensure that the quality of the data stays intact:
A Good Overview and Better Control
The RapidStart Services Role Center gives you a good overview of the setup status. And in more advanced deployments, it allows you to assign a certain set of questions to a specific person. That way you can follow up if questions are not answered in time.
Now, you’re probably wondering if this streamlined service is only available on-premise. Well we’re happy to offer RapidStart Services for Microsoft Dynamics NAV as a native part of the product. So, it’s supported in both on-premise and in the cloud, for greater flexibility.
Does RapidStart Services for Microsoft Dynamics NAV sound interesting?
Do you want to take advantage of the reduced cost of deployment and accelerated deployment time? Then, contact your partner and ask to learn more about how you can get your solution up and running in no time and with better control over the process. See more in this video. If you are a partner, learn more about resources and materials for RapidStart Services for Microsoft Dynamics NAV here (PartnerSource login and password required).
As many of you may know, Microsoft Dynamics NAV 2013 includes a new application feature called Assembly Management. It is described as a set of features designed for companies that supply products to their customers by combining components in simple processes, such as assembly, light manufacturing, and kitting.
At this point it may be tempting to ask yourself and your sales consultant: with this definition, isn't Assembly Management in essence the same as Manufacturing? That’s a fair question that will be raised in many sales and implementation situations.
The quick answer is yes, it certainly is, insofar as it belongs to the same category of business processes that represent the conversion of a set of products into a different or new product: Manufacturing typically concerns itself with converting (changing the physical nature of) raw materials into finished goods, kitting puts together end-products into a sellable unit, and assembly is often a hybrid of the two.
Now, as the standard application suite for Microsoft Dynamics NAV 2013 includes both Manufacturing and Assembly, how are we to know the subtle difference between the two and to decide which module fits the business and project budget best? Here is some guidance.
Let's start from reminding ourselves that Microsoft Dynamics NAV Manufacturing is a rich functionality that covers a broad selection of discrete production processes and industrial demands. It is meant for manufacturers that operate with multi-stage production processes, with specialized activities at each work operation, long production lead times that result in WIP, versions of BOMs, and have a need for capacity load optimization and control.
Theoretically, of course, with the right setup and user training, Manufacturing feature set could also support lighter production and assembly processes. However, the fact is that due to its scope, complexity, maintainability, price, and sometimes, lack of partners' expertise in the area, customers, especially in the small and mid-size segment, have been walking away from the Manufacturing solution. It is simply not suitable or cost-efficient for them. At those customers, an assembly task often means picking a set of items and packing them into one box that is sold as a kit, making the “production process” a part of regular warehouse operations. For other businesses, the work and labor involved in producing a final assembly is relatively short and consists of very few simple operations that do not warrant the setup and control of work centers, routings, or capacity load calculations.
Those light manufacturers, wholesalers, and retailers are looking for a simple manufacturing solution that allows them to manage the conversion process through one-entry-point interface, with minimal setup effort, using employees without university degrees in production engineering, and for an affordable price. And they are the target audience for the new Assembly Management functionality. The assembly granule is included in the Starter license package, comes with minimum setup requirements, supports companies that run both assemble-to-order and assemble-to-stock processes, and is fully integrated with the entire Microsoft Dynamics NAV supply chain suite.
This is also good news for existing customers with assembly and kitting needs, who in the past had little choice but to get the basic Sales BOM journal (as part of Starter license package) and then buy consulting and customization hours from their partner to bring the solution to the desired functional level. Admittedly, this approach did not represent an ideal situation. Partners would in effect have to first build a basic horizontal foundation for the assembly/kit process (as simple as it may be, it is still a manufacturing process) before taking it further into a vertical (if time and budget permitted). Many partners acknowledged that solutions built this way are poorly integrated and remain at the core level rather than support vertical industry needs.
So, with Assembly Management joining the total supply chain offering, new and existing customers will now have more options to consider when deciding what “manufacturing” functionality they need and how much to pay for it. What we have also understood is that at its heart, the new Assembly Management has the same conversion process as a true manufacturing module – it just has a lesser scope, simpler interface, fewer setup options and maintenance requirements, and is cheaper. With this in mind and especially with regard to the latter, should we now not expect that the same license alternatives will also be considered by the manufacturers, who will be tempted to shy away from the core Manufacturing functionality?
Tempted, yes, but upon closer examination and with partner guidance, customers engaged in full-blown manufacturing activities will come to see that Assembly Management may not be the right solution for them. The least desirable situation to find yourself in would be to choose the assembly module and then start paying your partner to beef up the Assembly Management feature, for example, to allow BOM versioning, or to enable work-in-process management, or to support multi-stage production processes. By design, the Assembly Management feature safeguards its conceptual boundaries and protects it from being turned into a full-scope manufacturing.
This is not to suggest that manufacturers shall not be interested in Assembly Management. It is easy to imagine an operational setting where a company will rely on manufacturing modules to support their production activities and then use the assembly feature, to-stock or to-order, when selling the produced products in sets or kits to its customers. Moreover, an item's production BOM may include a subassembly with assembly BOM, an efficient way to ready several components for a work center as one set.
-Olga T. Mulvad
In Microsoft Dynamics NAV 2013, the Microsoft Dynamics NAV Classic Client has been renamed to the Microsoft Dynamics NAV Development Environment. We did this not only because we like long product names but because we want to call attention to the fact that the development environment is now specifically repurposed to developers only. C/SIDE (Client Server Integrated Development Environment) is no longer an end-user client and we’ve made several changes to the client to support its role. C/SIDE has always been the development environment and it’s been the jumping off point for third-party developer tools, both commercial and community sourced, and we know that the success of Microsoft Dynamics NAV 2013 is going to hinge on those tools continuing to work for you.
But if C/SIDE no longer supports running C/AL code, then how can we make that claim?
Before jumping in, I’d like to share a couple of thoughts about where we’re going with the development environment and a few thoughts about the different types of solutions that we’ve seen.
First, the Application and Client have moved to the Windows Forms Client/NAV Server with the Microsoft Dynamics NAV 2009 release and we’ve had several releases since then. In the meantime, C/SIDE has both stayed as the (almost) single development environment and slowly evolved to its position in Microsoft Dynamics NAV 2013 where it’s no longer an end-user solution. We’ve talked a lot about moving the developer tools to the RoleTailored client, mainly because we think it’s a good fit to have the developer tools as part of the client (or part of the solution environment, however you want to think of it) and we think it’s a good fit because the UX offered by the RoleTailored client is a good match for a development environment. Task pages allow you to work atomically, FactBoxes allow us to share related information, Actions are good for functions, and so on and so forth.
In Microsoft Dynamics NAV 2013, we made an explicit decision to not build the developer tools in the RoleTailored client and to instead focus on the following areas:
In Microsoft Dynamics NAV “8” and beyond, we see new areas that we didn’t think of when we were starting Microsoft Dynamics NAV 2013 and we’re likely to give them equal consideration along with the developer environment. We look at the requirements brought by Azure and the desire to scale. We ask the question -- how does the deployment of a FOB file work when you have 1000 running instances? We also see the value in personalized clients and know that the user personalization settings are orthogonal to the Page in FOB/Text format – how are we going to solve that problem? We are also constantly challenged by questions about source control and other Microsoft product integrations (like Visual Studio based solutions & TFS) and we will factor those thoughts into our planning alongside the main goal of moving all development into the Microsoft Dynamics NAV Server stack.
But back to the Microsoft Dynamics NAV Development Environment and using the developer environment with third-party tools or extensions. To review a couple of basics, the following have been implemented in Microsoft Dynamics NAV 2013.
After reviewing these points, we saw that in Microsoft Dynamics NAV 2013 we needed to port any third -party tools to be Page object based. If the tool uses C/AL, then pages and code have to be validated on the Microsoft Dynamics NAV Server.
We’ve seen several categories of ‘external tools’ and I’ll share those and their migration story here.
For many people, the command line options offer an interesting new entry point for the Microsoft Dynamics NAV Development Environment. Examples are shown here:
finsql.exe command=compileobjects, servername=<server>, database=<database>, [filter=<filter>], [logfile=<path and filename>], [username=<user name>], [password=<password>], [ntauthentication=<yes|no|0|1>]
finsql.exe command=importobjects, file=<importfile>, servername=<server>, database=<database>, [logfile=<path and filename>], [importaction=<default|overwrite|skip|0|1|2>], [username=<username>], [password=<password>], [ntauthentication=<yes|no|1|0>]
Thanks for reading and thank you for your continued interest in Microsoft Dynamics NAV 2013 and developer tools. With your feedback, we can make future versions of Microsoft Dynamics NAV even better. I’m always interested to hear your thoughts and suggestions. My email is email@example.com and I wish you productive business.
In earlier releases, the Online Help in the Classic Client did contain two separate sections:
In a non English country release, that would mean that end users had to deal with two languages in one application. The Microsoft Dynamics NAV Classic Help would show up in the language of the country release they were working with and the C/SIDE Reference guide would always show up in English. The expectations were that end users would not start the C/SIDE Reference guide.
In Dynamics NAV 2013 Developer Environment, there is only one section:
The Online Help in the Dynamics NAV 2013 Developer Environment will always show up in English language regardless in what country release the user / IT Professional is working with. In Dynamics NAV 2009 and later releases earlier then Dynamics NAV 2013, the Online Help in the Role Tailored Client did only contain one section:
The C/SIDE Reference guide can be found for this release in %programfiles%\microsoft dynamics nav\60\documentation\developer guides or %programfiles(x86)%\microsoft dynamics nav\60\documentation\developer guides.
Two big changes were implemented starting with Dynamics NAV 2013. All existing help files can now be viewed via the Online Help via the Role Tailored Client. If you start the Microsoft Dynamics NAV Help from the Online Help, it would look like this:
New is also that two new sections have been added to the Online Help in Dynamics NAV 2013:
Now, this is fine in an English country release of Dynamics NAV 2013. In a non English country release, this does mean that two languages are being shown to the user:
The online help in a Dutch release would show up like this:
NOTE: the yellow marker indicates the non English section within the online help.
Our expectations are that an end user will look for his / her own content and especially for the translated contents that is in Application Help for Microsoft Dynamics NAV 2013. Searching through the Online Help may give him English search results which could possibly confuse the end users. That chances that this will happen are low.
Marco Mels CSS EMEA
This posting is provided "AS IS" with no warranties, and confers no rights
The policy for SOAP Web Services in NAV 2013 states that they always run in EN-US culture.
In NAV 2009 it was reported a buggy scenario that was solved in build 32558 and upcoming ones (remember)
However after collecting some feedback a workaround was built for NAV 2009 (remember 2)
This workaround was temporary as product team did not want to introduce a breaking change in a Hotfix without a way to revert to the original behavior.
Therefore now in NAV 2013 it has been decided to set EN-US as the default fixed culture for SOAP Web Services, the aim behind this decision is that we want to gurantee that Web Services have a fixed culture insensitive interface so any system can achieve a predictable communication with NAV.
I hope you find this Information helpful.
Diego García Álvarez
Dynamics NAV Senior Support Engineer
We recently shipped the Application Test Toolset for Microsoft Dynamics NAV 2013.
The supplement is applicable to the following country releases of Microsoft Dynamics NAV 2013:
W1, AU, CA, DE, DK, ES, FR, GB, IN, IT, MX, NL, NZ, SE and US
The supplement contains the following per country:
You may attempt to apply the W1 version to other country versions, but you should expect parts of the toolset to not work.
To install the supplement, do the following:
How Do I Use This?
The simplest way to make use of this supplement is to run the Test Tool page (130021) directly from the development environment. This launches the following page:
Click Get Test Codeunits and then select All Test Codeunits.
After Microsoft Dynamics NAV finishes loading all test codeunits, they are displayed on the Test Tool page. To run them, click the Run action and then select All.
It will take about 1 – 2 hours depending on your machine and the setup to run all tests. When the run is completed it will show the results in the Test Tool page:
Any changes done to the database through running of tests from the Test Tool are automatically rolled back using the Test Isolation testability feature of Microsoft Dynamics NAV 2013. (See the Additional Resources section in this post.)
During typical development, it is unacceptable to have to wait hours to get results from tests, which is why we have built an advanced test selection feature to help identify the relevant tests. (See the Test Selection section in this post.)
Alternatively, you can run individual tests or codeunits by selecting them and choosing either Active Line or Active Codeunit after you click the Run action.
If any test fails, you can attach a debugger session and re-run the failing test. The debugger will then break at the line where the test failed and you will be able to inspect the call stack and examine variables to determine the underlying cause of the failure.
Extending the Toolset With Your Own Tests
After you have written your first test codeunit, you can easily integrate it into the tools we provide in this supplement.
To include your own tests, in the Test Tool page, simply run the page from the development environment and click the action Get Test Codeunits and choose Select Test Codeunits. This will display a page listing all available test codeunits, including your own:
Select the codeunits you would like to add to the tool and press OK. The new test codeunits appear at the bottom of the Test Tool list, and you can now select them and run them just like any of the tests we included.
Again, Test Isolation prevents your tests from persisting changes to the database. During development it may be beneficial to actually see the output produced by the tests. It is possible to disable Test Isolation just by running the test codeunit directly from the development environment, however, instead we recommend attaching a debugger session, breaking at the test entry point, then stepping through test execution and inspecting variables to determine if your test is behaving as expected.
Speeding Up Development of Your Own Tests
The tests that we have developed are built on top of a layer of libraries that contain helper functionality to automate many aspects of Microsoft Dynamics NAV. For example, the library named Library – Sales contains functionality related to working with customers and sales documents, including creating new customers, sales headers, sales lines and posting sales documents. The library is extensive and has functionality in many areas of the product, such as finance, service, jobs, warehousing, inventory, etc.
Instead of re-inventing the wheel when developing your own tests, we highly suggest that you look into our existing helper functionality for functions you can leverage.
To help you find your way around the libraries, we have shipped a Microsoft Compiled HTML Help file (*.chm), which is bundled together with the .fob file you installed. When you open the .chm file, you are prompted with the following window:
This lists all our libraries and the functions inside them. However, normally you don’t know which library to look for, You can search it from the Search tab. Try searching for "finance charge memo" and you will have a couple of choices to pick from:
Code Coverage Tools
Code coverage is the means of being able to track which part of the application code has been exercised during some activity. In Microsoft Dynamics NAV, code coverage is recorded by AL code line and in addition to knowing if a code line was exercised it also records the number of times it was recorded.
The code coverage activity that we record can be any interaction with Microsoft Dynamics NAV, be it manual user interaction, automated test execution, NAS, Web services, etc. You can, of course, record code coverage of your own tests exercising your own objects.
The toolset includes a page (130002), Code Coverage List, which you can use to track code coverage. Run the page from the development environment:
From this page you can start/refresh/stop the code coverage recorder. If you click the Start action, the code coverage engine is turned on and code coverage is captured. However, you will not be able to see any updated information before you click either Refresh or Stop, at which time you are presented with the code coverage information:
The information contains coverage of objects, triggers/functions and individual lines (code and empty) as determined by the column Line Type. Only lines of type Code can have coverage. Lines of type Trigger/Function show the average coverage of all code lines in the trigger/function. Lines of type Object show the average coverage of all code lines inside the object.
From the above picture, you can read that the activity exercised 33.93% of the Currency table (4). It covered 100% of the OnModify trigger and that comes from 100% of a single Code line.
It is often desirable to filter on Line Type = Object to first get a high-level overview of the coverage result:
Then from here, you can filter to look at individual objects and expand the Line Type filter to include triggers/functions as well:
This way you can drill-down into the results starting from a high-level view going to a low-level view.
Note #1: Code coverage is recorded globally for all sessions when using this tool, so make sure you are running in a controlled environment so you don’t have any activity from unaccounted sessions.
Note #2: Only objects that are touched by the activity are recorded, meaning the coverage of any object not in the list is implied to be zero. If you would like to force the recorder to include specific objects even if they are not covered, you can usethe Load objects action and select the relevant objects from the subsequent page. This forces the code coverage engine to load these objects and provide information on even when no lines are covered.
Now that we have all the building blocks in place, I’d like to talk about an advanced feature we included with the tooling.
As mentioned previously, having to wait hours to run all tests is not feasible from a development point of view. Therefore we shipped the Test Selection, which helps you narrow the set of tests down to the relevant tests.
The feature works by analyzing the code coverage data from individual test codeunits and comparing it to the set of objects that have the Modified field set to Yes in the database.
To use this feature, you run the Test Tool page and go to the Actions tab and click Import/Export Test Map action. On the request page, make sure the direction is Import and click OK. Browse to the bundled "AppTestToolsetNAV2013-<countrycode>-Map.txt" file and import the file. This will take a couple of seconds. After it is done, click the Get Test Codeunits action. The prompt will now include a third option:
Select this third option and the tool will automatically detect the relevant tests to run and add them to your current suite.
Note #1: In typical circumstances you would want to make sure your suite is empty before using this feature.
Note #2: There is a small risk this feature will not identify all relevant tests in unusual circumstances. Thus we strongly recommend running the full regression suite before shipping anything to the customer.
This feature also integrates with you own tests. Once enabled (by loading the Test Map), the information will auto-update when any test is run – including your own tests. This means that you can load the map, run your tests and now export the map to another text file. You can then load the new map into another database and the test selection feature will now be able to suggest your own tests based on modified objects in this other database. If your test codeunit is not present in the database, you will be prompted with a list of missing test codeunits that could not be added. Import the missing test codeunits into the database and re-run the test selection feature.
Today we can announce that the Lync Add-In is available for download in source code. This Add-In is a good sample for a nice integration with other fields on a page, yet still provides a very custom functionality and rendering.
It has been shown at recent conferences and is also contained on the VPC for Microsoft Dynamics NAV 2013.
Please read the related BlogPost here.
Senior Program Manager
Microsoft Dynamics NAV