With Waldo skiing I'll briefly take over his job of announcing VAT objects.
The first reports are available.
Go here and see if your country is there.
The Netherlands are availble. Belgium not yet. (As always. ).
Microsoft Dynamics NAV 4.0 SP3
Microsoft Dynamics NAV 5.0 SP1
Microsoft Dynamics NAV 2009 SP1
Complete (data + reporting):VAT2010_DAT_W1_NAV4.0SP3.exe
Complete (data + reporting):VAT2010_DAT_W1_NAV5.0SP1.exe
Complete (data + reporting):VAT2010_DAT_W1_NAV2009SP1.exe
Complete (data + reporting):VAT2010_FULL_AT_NAV4.0SP3.exe
Complete (data + reporting):VAT2010_FULL_AT_NAV5.0SP1.exe
Version not available as of 12.2.09
Report part:Version not available as of 12.29.09
Report part:Version not available as of 12.22.09
In Part 1 of this three-part evaluation of Microsoft Dynamics NAV 2009, I provided a generally positive assessment of the Role Tailored Interface. In this Part 2, an examination of The Service Tier and the Transformation Tool, I am somewhat less enthusiastic.
The Service Tier
Whereas the new Service Tier interface is a very visible new feature of Dynamics NAV 2009, the Service Tier's functionality is definitely not new. From an end user's or consultant's perspective, it is difficult to judge the Service Tier. From a developer's perspective, it is difficult to judge as well. The Service Tier does not make his/her life any easier, though the question should be this: Does it make his life harder?
For what we have seen, this is not the case. The Service Tier is very stable in normal conditions and seems to have good performance. The first caching seems to be a bit slow, but once the objects are in, it is fast enough for an end user to work with. Too bad sessions do not share cached objects, though. For batch processing the service tier seems to be significantly slower than the classic two-tier client. It takes up to three times longer to post a batch of invoices.
One of the downsides is that the service tier only accepts Windows authentications. This makes it mandatory to be in the domain when connecting. This makes it impossible to bring your own laptop to the end user. A good workaround is to have a remote desktop connection for the Role Tailored Client.
When working with files and automation control objects, it is slightly more confusing when working with the service tier. Extra code needs to be added to handle this at the correct place.
And what about web services? Though this has been introduced with NAV 2009, I have not yet used it in my implementations. The job queue has not been changed. We are planning to use it through allowing customers to request their order status from the internet.
From all perspectives, then, the service tier has not made our lives better. It seems to be a necessity to use the new interface, that's all.
The Transformation Tool
With the release of Dynamics NAV 2009, Microsoft has converted the entire application to being capable of running in the new Role Tailored Interface. It has developed a tool for this and made it available for partners to upgrade applications as well.
This is not just a techies' tool. The Transformation Tool needs to be ‘implemented' in order to do a good job.
The new Role Tailored Client has a lot of new features the classic interface did not have. When you just technically convert your old application to the new interface it will lack most of these features.
So how did Microsoft implement this? Here you can clearly see that it is a lot of work to do properly. The most commonly used parts of the application have a lot of new features like fact boxes and promoted fields and actions, but a good number of deeper application parts are still ‘unimplemented'.
A lot of Dynamics partners are struggling with this tool. Implementing it comes down to a single question. Do I want to support both clients with my solution?
Based on my previous year's experience, I recommend the following: Upgrade your solution first to the classic environment, and then make sure it all works exactly as it should. Get a few customers running the package. Then, just like Microsoft, create a TAP program; but with just one or two customers.
The add-on we use in the implementation we just ‘technically' converted to the new client. This means that it works the same in the new client as in the old client. Then, together with the end users, start adding the new features.
After this project, it is your decision. Import all information into the Transformation Tool or just stick with the pages.
Ask yourself this question: How long do you think Microsoft will continue forms and the classic client? Apply common sense and decide.
Of course, it is different if you develop small components that you sell to other Dynamics NAV partners. Here the number of sales are often much higher and the components are generally smaller, making it easier to fully implement the Transformation Tool.
The version name says all; 2009. It has been a year since the release of Microsoft Dynamics NAV, making it time for a thorough evaluation.
At this moment I have two customers ready to go live on January 1. One with Dynamics NAV CRM and one with NAV Financials and an add-on. For this add-on, we used the Transformation Tool to upgrade the forms to pages.
So what have we learned? I have broken this evaluation into five sections or components, and evaluate each one separately. Each component comes at the evaluation from the End User perspective, the Consultant perspective and the Developer perspective.
Because of its length, this evaluation is being presented in three parts. In this Part 1, I assess the new Role Tailored Interface.
My company uses the new Role Tailored Interface in the role of an end user, for invoicing and banking.
The new interface is definitely the most eye-catching change in this version of Dynamics NAV, but is it an improvement? And what about implementing and developing with this compared to the classic interface?
From the end-user perspective, I must say I am very impressed. End users find the interface very easy to use and it seems very intuitive.
One group of end users is migrating from a Unix environment with a 25x40 line screen, unbelievably easy to use but graphically from the stone age. They can find their way in the RTC client within minutes. The action buttons are easier to use than the old menu buttons and filtering is much more intuitive.
The fact boxes are a big improvement to end users, making detailed information easier to locate as well as the fast tabs. The success of the fast tabs is not in the vertical vs. horizontal character, but in the promoted information. Users can see information on a tab without expanding it.
From an integration perspective the client add-ins are a big improvement. We have used it to interface with Bing Maps. We used the examples from the NAV Team and expanded it with complete route visualization.
Once users are more used to the interface, they start personalizing it. The two most popular personalizations are changing the columns and changing the menus on the role center. The first was also possible in the classic client, the latter is new.
A complaint from the end user is the lack of color and/or indication possibilities. People who work with a generated workflow that they have to manage by exception have an especially big need for this.
From the consultant's perspective the new interface means less and more work. In the classic environment, end users had many more difficulties finding their way. Menu items where hard to find and often in odd places between menu items that were not used but easily clicked on by mistake. So explaining it is a lot easier--a consultant no longer has to ‘defend' the way the interface works.
More work is generated from the possibility to create the profile personalization layer. This is also part of the success of the end users' acceptance. The consultant needs to interview the end user and place actions, menu items and fact boxes in the right place.
This gray area brings us to the developers' perspective. This job has become more comprehensive than before. This is not because developing in 2009 is more complex, but because of the lack of integration between the Role Tailored Interface and the development environment. The development environment is still in the classic client.
To ‘develop' in the new interface, the developer needs to be able to translate in his mind how it's going to look when it's executed on the new client. Fortunately, this job is made much easier with the new client adopting the changes almost immediately. A change in the interface or business logic no longer requires a restart.
My experience is that the ‘run' function in the development environment is hardly used. It is enough to have the Role Tailored client open and simply restart the page. The run function also often executed the object in the wrong mode--for example, where edit is required it shows view mode.
Also developing in a Role Tailored environment means a better need to understand the end user and the business process. As a developer, you can no longer just group functions by functionality. There needs to be more interaction if a function is important enough to be on the Action pane, in which category, big or small. Should a field be promoted or additional? What fact boxes can I use with a page? Does it makes sense?
Developing in an ERP system always was a challenge for techies without knowledge of businesses, and that has not changed. On the contrary, it has become even more important.
A special consideration must be made for developing the role center. Designing a role center requires special skills in understanding a business workflow. From a technical perspective, we have found out that it is best practice to have only one cue table for all role centers in the company. This makes it easier to copy and paste cues from one center to another. The ‘my' pages are very popular. Microsoft delivers my customers, vendors and items with the package, but so far we have created my contacts, my to-do's and my routes.
What makes it extremely difficult for a developer is the debugging process. The new interface does not know a debugging tool, so whenever a bug is reported in the new client, it first has to be recreated in the classic environment. Only then, is the developer able to debug.
This article is also reviewed and posted on MS Dynamics World. Thank you for this.
Please also read part 2 and part 3.
So I have to merge the DAT changes into a 2.60 database of one of my earliest clients. How difficult can that be...
Step 1. The fields.
I choose to add the fields in the 50000 range for simplicity.
2. the forms.
Just add them somewhere...
3. The Code
The VAT Code in Dynamics NAV (Navision) has not changed for ages and ages so you have to believe me that this really is old and new code...
That's it. A 15 minutes job if you have access to the database and the right tools.
Next step... the functional application changes...
Oh, BTW, this is a 100GB database, so the tablechanges might take a while...
Ok, so let's have a look first at the work Microsoft has done and what all the noize is about.
I have not looked at all countries, so I might be wrong, but I looked at NL and BE.
This is a 4.0 SP3 BE compare. Microsoft changed 5 objects and this is what beyond compare finds...
It fits on one screen!
I'll translate it for you.
2 tables have one new field. 2 forms have one new column and one new line of code in codeunit 12.
This I am not yet sure of, since I am still convinced there is NO NEED for change in the application!
In NL and BE we only need to change the VAT Statement Setup as I will explain in my one of my next posts.
My guess is that the new column, EU Service is only created to make the ICP report easier to create with two columns. But you may still require two VAT Product Groups, one for products, one for Services.
But it is still a guess since Microsoft has not yet released the reports.
Next step for me is to merge all this $#%@&! into a 2.60 BE database...