Top reasons to use NAV 2009

-Wider configuration by user itself (hiding fields and fasttabs, adding new tasks etc.)
-You are not loosing settings by compiling objects (zup file problems)
-Sending notifications to other users about different things like problems with orders etc. (more support for "workflow")

Well, how many reasons do you need?

If you read the official highligts, you see that these are the things they want to emphasize as well ...
https://mbs.microsoft.com/downloads/cus ... lights.pdf

The two links are marketing BS.

The whole working faster and be more productive is not true.
Try to do a person task on classic and RTL client and see who finishes it faster.

I would wait till they release a product that will scale on SQL.
A programming language that allows us to utilize SQL the way it should be.

I think this is a very interesting topic. We had a very similar topic just over 10 years ago with all the exact same topics.

"What advantages are there of Navision Financials over Navision for OS/2-DOS?"

And PC&C back then the same (in my opinion) mistake that Microsoft are doing now.

Back then the market drive was the Windows client. It was a true Win 95 application, not a Screen scraper. And the client base perceived Financials as a new Client.

In fact moving to the Windows environment opened up a slew of new possibilities. The code base was now compiled and cached instead of interpreted p-code. But most importantly it opened up access to new opportunities that did not exist before. Things that today we take as common place.

Now we see Role Tailored Client in a fancy graphical environment, and that offerers a lot, but really NAV 2009 is so much more than the surface we see, and I get disappointed by marketing that concentrates on the superficiality of it.

Of course the first thing that the technical savvy see, is Web Services, and the options that this opens up. The three tier it self opens up system management possibilities that we didn't have before.

We now have a solid step towards SQL Server Reporting Services, yes its a compromise solution, but its a good compromise, and of course just the first step to being bale to truly manage reporting in Navision. Instead of just having people "print reports".

We now have managed code. Navision has always been extremely friendly to developers, and without that friendliness we would never have been able to have the applications that we see today. We never really think about how gracefully Navision handles silly errors that in say C++ could simply result in a BSD. Now moving those to a managed environment is a huge task, that I always think similar to the move of Release of Lotus 123 from assembler to C and still managed to keep similar performance, but get things manageable. We see no real benefit of this right now, but it means that they ow have abase to work from for the next version. With errors cache and stuff like that all sorted out.

I do understand the need for the WOW factor, but I really do believe that the RTC distracts form what NAV 2009 is really all about.

I'd say the number 1 reason to use NAV2009 is reporting! The ability to print to Excel and PDF directly. The use of reporting services to sort reports anyway you like.

We all know the pre NAV2009 out of the box reporting blows chunks. This is a much needed improvement.

Alex Chow wrote:

I'd say the number 1 reason to use NAV2009 is reporting! The ability to print to Excel and PDF directly. The use of reporting services to sort reports anyway you like.

We all know the pre NAV2009 out of the box reporting blows chunks. This is a much needed improvement.

I would suggest paying for crystal reports, and a good pdf writer, and paying a solution center to integrate those, seems the cost would a lot less then upgrading to Nav2009

kine wrote:

It is why customization are not good from upgrade point of view. But you are writing the amounts, but you did not get us info about DB size, count of modified objects, if you have some own development (e.g. because you have report designer, application builder or SD). This is big part of the cost. And you have other solutions - upgrade centers, cheaper partners etc. (but take into account some additional risk...)

only minor customizations, all done by the solution center, so they know exactly what they are. database size 27 gig, I would not have them do any report upgrades, or forms customization, after the upgrade is complete, I would change the forms appearance, so they would just upgrade to standard forms and reports

Sample of a typical customization we have had,

1. Make a PO cost be the standard cost, not the last cost paid
2. Add custom fields in customer table, such as data account opened, all in the 50000 range, none of which are used by anything but our own reports they we create and customize ourselfs.

we don't have application builder or SD, but are considering getting them, getting a copy of latest license for 2009, and dropping microsoft maintance completly, it would save money and allow us to add things we want.

and saying you shouldn't modify your database if you want to upgrade, takes away probably the most appealing aspect of Navision, the ability to make it fit your business. If I wanted a program with no flexibility so I could easily upgrade later, I would not have ever picked Navision. But in my view, there is no benefit to paying microsoft support, If our corporate headquarters didn't say company policy is to be current on support for ERP. we wouldn't be.

Of course I do not like the fees too (just to make it clear ;-)) - mainly if in some periods there was no new version for few years.

For me the biggest part is the Data upgrade, and it is understandable - upgrading process itself will take hours, you need to repeat it few times (correcting mistakes between etc.) + result cross-checks. Upgrading objects in with small customization can take 1-3 days, depends on developer/problems/customization (do not forget that some customization must be re-designed to be able to transform them into pages). I do not know if you want to use RTC or not, if you want to have Reports redesigned into RTC or you will be using still the classic reports etc., customization of RoleCenters etc. - it is additional cost which was not there in previous upgrades...

generic wrote:

I heard from people from convergence that they should wait for SP1 for 2009 to upgrade.
Otherwise you will be pulling your hair out. Be warned. ](*,) ](*,) ](*,) ](*,) ](*,) ](*,) ](*,)

Plus you will also have to pay your solution center to apply the upgrade which won't be cheap at all.

Hello,

one of our customers wants to upgrade his navision version, which is currently 3.7. He asks me to create a short
overview of new functions in upper navision versions ( 4,5, 2009 ). Especially he's interested in new functions of
financials and inventory. I could find documents of changes in navision 4 and 5, but unfortunatly i couldn't find
a correspondig document for navision 2009.
Do you know if such a document ( like "Microsoft Dynamics NAV 50 Change Doc" ) exists ?


Yours sincerely

Dennis

And there is documentation about changes in the upgrade toolkit...

DBCS stands for Double Byte Character Set?
Any info on how to enable it?

Does the globalfilter work on temp variables as well?

I am happy that you remember GLOBALFILTER in the textbased version of NAV

It is back in 2009 SP1 as Rec.FILTERGROUP(1);

This means that if you set filters in CU1 using this group, all tablehandles from that point will have the filter (Record variables, UI, Reports, etc.)and it cannot be seen or changed from the UI

I hope that this will not make errors during posting - e.g. when I set filter in FILTERGROUP 1 on G/L Entry, that the posting CU 12 will find correct Entry No. of last entry... ;-)

That's what I am afraid of... if there is no explicit cleaning of this global filter in some points, it can kill whole application and usage of this possibility... I hope that it will be solved somehow (i do not know how the DOS version solved that)..