I’m not sure about you, but I’ve missed last week’s update to this free download from Microsoft Download Center: Microsoft Dynamics NAV 2009 Developer and IT Pro Help.
Published in December 2008, this set of help files and guidelines contains valuable information for developers and IT professionals about development, debugging, installation, security and similar best practices.
This is bazillionth time that I’ve encountered this issue, so I’ve decided to post a solution to it. If you live in a country which doesn’t have Microsoft Dynamics NAV 2009 localized version yet, you might have tried installing the W1 (worldwide, English, non-localized) version. Did it work out?
If you install the NAV 2009 W1 version on a system with regional settings not matching the demo database code page (in W1 it’s Latin_1_General_CS_AS) the installation goes smoothly, but the attempt at running the RoleTailored client fails.
Usually I do not write about local Croatian affairs, but this particular occasion and this particular topic deserve an exception.
As a part of Microsoft Dynamics promotion campaign in Croatia, Zoran Šegić, Microsoft Business Solution Lead in Microsoft’s Croatian subsidiary, has given an interview for eBizMags, a Croatian e-business blog/portal.
It’s hardly any news for the lucky 21 countries which have had them by default for about two years, but for other 18 which haven’t, there is an alarmingly low awareness about three interesting NAV functionalities: Liquidity, Cost Accounting and Kitting.
These three have been named Local Functionality, which means they are a part of a localized version in some of the countries. For other countries, this functionality is not available by default, but it doesn’t mean it can’t be licensed or implemented for customers in other countries as well.
It’s the survival of the fittest game, that stuff that happened to the dataports. You know dataports? That class of NAV objects that’s used to move data back and forth in text format?
It’s really funny what has been going on with them lately. They evolved, then degenerated. Today, they are an endangered species. A release or two, and they might be gone for good. Just like dinosaurs.
Yesterday, my and my friend Dave’s book Implementing Microsoft Dynamics NAV 2009 has been made available on Safari Books Online.
Safari Books Online is the world’s premier on-demand digital library for technology and business professionals, and it delivers the books in digital form on subscription basis from most renowned publishers, including O’Reilly, Prentice Hall, Addison-Wesley, Microsoft Press, Sams, Que, PACKT and many more.
So, even though it really makes sense to grab your own personal hardcopy, if you are already Safari Books Online subscriber you can go and read it right away—it’s the most cost-effective way for you to read it. Enjoy!
This was a part of Chapter 1 in the first draft of my book Implementing Microsoft Dynamics NAV 2009. It was cut to keep page count down and preserve the environment, but I figure that a few electrons pushed through the optical labyrinths of The Internet won’t hurt anyone, so here you get it, in its original form: The History of Microsoft Dynamics NAV.
One of the biggest absurdities about ERP systems springs from the very word we use so often when describing ERP: integrated.
ERP is an integrated system: it integrates all data and processes into a single application. Different modules look over different aspects of data and processes, but a change in one module automatically reflects in all others.
A fantastic concept. When it was invented, it streamlined processes, boosted productivity and eliminated overhead and error.
So, whenever a new functionality is needed by a company, it should be integrated into the ERP, to benefit from the integrated system. Right?
Wrong.
You can’t avoid customizations. Vanilla ERP is a great first step, and a valuable tool for establishing common language between the customer and the consultant. But in the long run? Probably not. Pristine uncustomized ERP won’t be sufficient, because of the gaps between your way and ERP’s way. Sooner or later, gaps will have to go.
Two most common ways of closing functionality gaps are customizing the software, and changing the processes. You can almost always touch general processes, optimize them, twist them, bend them, make them more efficient or even eliminate them. But when it is about industry specifics that add true value or contribute to company’s competitive edge, customization is the answer.
– “We need a report which groups our sales by product components.”
– “And we need it broken down by cost centers.”
– “And it must show comparison with last month, quarter and year, and with budget and forecast, with indexes and trends. In linear regression.”
– “And it must let you choose if it is by posting date or by document date. Or by shipment date. Maybe some other date as well.”
– “And it must exclude returns, and include only those re-shipments that were linked to original returns in the shown period.”
And it must be a disaster if you agree to half of these.