Things that MS should revisit for future NAV

kine

Moving to .NET doesn't mean that it is end of C/AL. This is wrong assumption. There is still plan to use C/AL, not replacing it fully by C# or anything else. That it is compiled to C# in background doesn't matter. We can await moving the development IDE from C/Side to RTC, but still MS knows that developing ERP in C/AL is much faster than developing ERP in C#. It means that the evolution of NAV will lead to new ways of developing etc. but still with emphasizis to speed of the development (customization) and ease of this. But it will be step by step process, and it means that there now known only e.g. next two steps ahead... rest are only dreams or thoughts somewhere in brain of some people. And everything can be changed... ;-)

Who was on Convergence and saw the demo of Warehouse management using Surface technology can have some vision of the future, but this is not near future (next few years)... (I made some video from the presentation but it seems that it is corrupted and I cannot play it...)

DenSter

You are talking out of your neck, you are fabricating this information, there is absolutely nothing to support that claim. [-X

Even if they do find a way to put NAV development, and GP development, and AX development, and SL development on a CLR based language, it would be a different language from eachother. Even if they miraculously find a way to create a language that would be able to support business logic into one language, there is no way that they would then translate all existing apps into one. It's just not practical.

davmac1

Surface technology looks like something a science fiction writer described about 20 years ago - he called it cyber technology - the people had the ability to use and manipulate information with their hands.
Author is William Gibson. Book "Neuromancer".

generic

DenSter wrote:

You are talking out of your neck, you are fabricating this information, there is absolutely nothing to support that claim. [-X

Even if they do find a way to put NAV development, and GP development, and AX development, and SL development on a CLR based language, it would be a different language from eachother. Even if they miraculously find a way to create a language that would be able to support business logic into one language, there is no way that they would then translate all existing apps into one. It's just not practical.

In AX you can already program in .NET, GP you can customize in VB, and there is nothing special about dexterity to be translated to .NET langauge. NAV is already translated to C#. and MS CRM is already written in C#.
There is nothing stopping it for them to be all on same language. It will be a lot of work to move the code, but it will be done.

They will look at each area of the different ERP business structure (tables) and make decision which one is designed well starting probably with GL tables. This will be a very research intensive part. You will have to have all the people who are expert in each Solomon, NAV, AX, GP (SNAG) in a room and SQL guys, to come up with a design that all the 4 ERP's will implement for the next version. Once SNAG implements in their product and releases it as new verion. everybody will upgrade to it upgrades to this new version with having just GL the same. You would have specific to each area but those will be implemented in each product differently. You could for example consolidate GP companies into AX or NAV.
In terms of code, in business logic, you will have again classes derived from Parent Dynamics class.
And anything that is Specific to NAV, AX, GP, etc will be done in those classes. For example for NAV when GL transaction is posted, it will run function such has update analysis view.

They would look something like this;

This is an example for RTC but you would have it for all the classes.

using System;
using Microsoft.Dynamics.Nav.Runtime;
using Microsoft.Dynamics.RoleTailoredClient;

namespace Microsoft.Dynamics.RoleTailoredClient.Nav
{
   public sealed class
...
}

So anything that is NAV specific will be implemented in above classes.

The same will happen to GP, AX, and Solomon.

Alex_Chow

That's a good theory and it may be that you're right.

But why start these kinds of rumors when the future of all products are still being improved? Before NAV2009 was released, rumor was floating around that the classic dev environment and client will go away. As you can see, the classic client and dev environment is still alive and kicking.

I think the original purpose of this thread is to suggest to MSFT the FEATURES that should be improved in NAV. I would vote Dimensions as their first order of business.

AdamRoue

generic wrote:

Most prospects can't tell the difference between the products.

Most prospects I am involved with have a very clear understanding of the differences, the UI is the same to breed familiarity, but one click away and everything changes. Have you ever seen AX next to NAV?

DenSter

generic wrote:

but it will be done.

No.... it will not

Microsoft wanted to, and announced project Green when they first purchased the ERP products, and made a lot of noise about the "common sense" of the convergence of ERP products into one powerful product. Now, years later, they realized that each produt is indeed its own product, with their own unique features, and their own unique market place, and saw that it is better to serve these specific unique marketplaces with their own products than to force an artificial product that is a-not wanted because each marketspace has their own specific requirements, and b-impossible to implement.

Again, there will be no product that individual Dynamics products will morphe into, it will simply never happen that you will upgrade from NAV 13 into this imaginary product. What MIGHT happen is that they will create a NEW product, based on best practices and experience from each current product, and they MIGHT develop a set of migration tools, but that will NEVER be "the next version of NAV/AX/GP/SL" (I like NAGS better ).

DenSter

generic wrote:

They would look something like this;

This is an example for RTC but you would have it for all the classes.

using System;
using Microsoft.Dynamics.Nav.Runtime;
using Microsoft.Dynamics.RoleTailoredClient;

namespace Microsoft.Dynamics.RoleTailoredClient.Nav
{
   public sealed class
...
}

So anything that is NAV specific will be implemented in above classes.

The same will happen to GP, AX, and Solomon.

Right, uhuh, and with that example you illustrate yourself that a "common product" would have separate classes for NAV logic, AX, logic, etcetera. Hey wasn't that the problem why they eventually decided it couldn't be done after all? :-k Where's the commonality there? If it's a true morphed product, there would be one set of common classes.

Each product has their own set of business rules. Existing customers will not accept it when all of a sudden in a new version all business logic would be changed. It's hard enough to migrate data, let alone the entire set of business logic rules.

One product for all markets with Std/Enterprise editions might happen some day down the road, but it will be a NEW product. They already came out with Office Accounting, and who knows how that will evolve. You'll see the resemblence in bits and pieces from the current products, but it is clear that it will not be morphed from existing products.

generic

The example is the first step in the process. There will be many versions and code will change.

As far as changing business logic, well look at history of NAV.

Dimension was a big change.
value entry was a big change.
Average costing in 5.0 was big change.
Serial, lot tracking was a big change.
Removing Bin code to warehouse entry was a big change.
warehouse management was a big change.
NAV 2009 was a bigger change.