Blog

Check out the step-by-step solution how to develop Page Number Functionality in a new NAV database to ensure that caption “Page” is always printed in correct language.

Upgrading NAV Classic Reports to RDLC is tedious, requiring you to sacrifice valuable development resources to a low margin project.  These upgrade projects typically take the most development time but make the least return on development resources.  It is no wonder many Dynamics Partners try to avoid upgrade services all together. 

Minimize the time invested by your development resources and maximize the upgrade benefit to your customers with 1ClickFactory’s Transformation Services for NAV Classic Report upgrades. 1ClickFactory took on the challenge of simplifying NAV Classic Report upgrades for partners through Transformation Services enabling you to transform an object in “just a few clicks”.

We are pleased to announce the release of our latest service to the Microsoft Dynamics Partner Community, Self-Provisioning for Microsoft Dynamics NAV on Windows Azure and in Office 365.

We saw a unique opportunity with Microsoft Dynamics NAV to ‘change the game’ for Microsoft Dynamics partners by providing them a service that would deliver the high performance and reliability of an on-premise solution, with Windows Azure at the foundation, but translate the simplicity and ease-of-use to the end user in the Cloud.

To create a complex filter, a developer usually uses command "FILTERGROUP" to place different filters for the same field. In the first Microsoft Dynamics NAV Windows-based versions, developers were able to use filtergroups starting from 0 to 255. Some of them were reserved and used within the application like filtergroup 2 used by properties SubFormView, DataItemTableView or when you use command SETTABLEVIEW. There was also a reserved filtergroup 1, which was supposed to be a "Global filter" as it was in the DOS version.

Beginning with version Microsoft Dynamics NAV 5.0 SP1 build 28913, Microsoft introduced filtergroup 1 functionality.

In this article, we are going to talk about the "Promoted" actions feature. It allows users to easily access the main functions related to the active page. When we use pages without subpages, we can promote any function we want. The challenge arises when using subpage functions - where from the main page you can't get to the active subpage record.  (When you call the subform function in the Classic client, the Microsoft Dynamics NAV knows on which record the user stays, but in the RTC it doesn't work this way).

At 1ClickFactory we found a way to solve this issue - to promote actions that need subpage functions -- by using Parts (fact boxes). When you use parts, you can link them with lines subpages. The example we are going to present in this article is based on the standard Microsoft Dynamics NAV 2009 SP1 W1 version.

In this article I want to share with my peers how to hold the same two columns in a page as we have in a form.

There are a few standard solutions for accessing different role functions:

• Other role functions are accessible via Departments menu. But having a dedicated Role Center makes it even easier.
• It is possible to have several shortcuts to NAV where the Role Center name is entered in parameters string. While it is a solution that works, it is done not via NAV and is often not so easy for users who are not advanced.
• It is possible to develop special Role Centers according to specific users' requirements. This is good solution when users mostly do the same actions from several Role Centers.

I would like to tell you about one more intelligent option. With a small modification, it is possible to prompt the NAV application to ask which Role Center (profile) the user wants to use. How does it work?

As many developers know, Pages and Codeunits can be exposed as Web Services. When using a Codeunit as a Web Service we ordinarily use simple data types as function parameters. It is also possible to pass XMLPorts. Let's view an example and test it.

When trying to match date formatting on the classic and RDLC versions of a report, you might run into an issue of mismatched date formatting. This can be corrected by forcing the same date format on Classic and RDLC reports. But what do you do if you want to maintain the user's setup?