Category Archives: Historic NAV

The Navision DNA

The Dynamics NAV world is going through a lot of changes these days.  And it got me thinking: What’s it about NAV that is so unique, what is the DNA of NAV’s big success?

To answer this, we have to take a stroll down memory lane and go back to the birth of Navision.

https://upload.wikimedia.org/wikipedia/commons/6/6f/Personal_System_2_Series_of_Computers.png

We are in the mid-late 80’ties, IBM is about to introduce their new PS/2 computers, running OS/2 with Token Ring networking. In Denmark, they wanted to have a multi-user accounting software to go with their new shiny machines. The options that were available for them, from the US, was not up to par with currency support and other things needed to work in Denmark. So they turned to look at the Danish market. They found a very successful accounting system called PCPLUS.

PCLUS was created by three young guys right out of university and it worked very well, but PCPLUS was a single user system. So IBM approached PC&C and asked if they could make a multi-user version for them. The result was IBM-Navigator 1.0

IBM-Navigator was a huge success, it ran as a true client-server application, with its own database engine. As a result of the success, users started to ask IBM about different changes, from report layouts, new fields in the database to import and exports. IBM went back to PC&C and asked for the ability to make changes. Over the course of version 1.0 to 2.12, IBM-Navigator gained a moderate customization interface, a classic customization interface. Great, but customers and IBM wanted more.

The result was IBM-Navigator 3.00 – PC&C had added a compiler and a runtime environment, rewritten the entire “ERP” application in its own language. In August 1990, this was a revolution, an ERP system where partners and customer have access to customize the entire application, add whole new modules and functions. All contained inside a smooth running platform. And all this delivered on a couple of 1,44MB diskettes.

To become a IBM-Navigator reseller at this point, you needed to be a IBM Business Center, and for that, you needed employees certified for Navigator, both sales and technical. The certification was done through a 7 week curse at IBM, no exceptions. The participants at these curses are still the backbone of the Danish NAV reseller network. The result was partners that focused almost exclusively on IBM-Navigator.

Now fast forward to 2017. Today we have an ERP system where partners and customers have access to customize the entire application, add whole new modules and functions. All contained inside a smooth running platform.

The platform has been updated numerous times. The application has expanded with several new modules and new functionality all over the application.

An eco-system of thousands of companies creating add-ons, modules, ISV verticals, and integrations has grown over the last 27 years. Many with direct connection and history back to August 1990.  Most of these partners are 100% dedicated to NAV, that is their primary product, they may sell others services, software, and hardware, but all are related and tied into NAV.

This concept from 1990 has even gone to the cloud with Dynamics 365, without partners needing to start over or invest massively.

All thanks to the ability to customize everything, and thanks to the cleverness, stability, and smoothness of the application and platform, all delivered though a dedicated partner network:
That’s the DNA of Dynamics NAV.

Thinking about the NAV Future from 30.000 feet above Denver

Sitting here in the plane on my way to Orlando for Directions US.

I’m going to present how an ISV add-on, made for Navision in 2001 makes it all the way to Dynamics 365 as an extension v2.

And I’m looking at how many similarities the solutions have. And this got me thinking, how rare is it, that code programmed in 2001 still works in 2017 (and beyond)?

Most other development I did back in 2001 was done in Watcom C/C++ targeting Win32, sure, those programs mostly still run on Windows 10, thanks to Microsoft’s crazy commitment to backward compatibility, but it’s really not code that lives on. The compiler is long dead, and nobody develops directly toward Win32 anymore. Most of these things were re-factored, re-engineered or re-designed in other technologies.

And looking at technologies that have come and left again in the period, like Silverlight or Flash it is amazing that an investment made 16 years ago still pays off.  The most popular phone in 2001 was the Nokia 3310, and the top laptop was the IBM Thinkpad A21p with a whopping 128MB RAM and 32 GB harddrive.

This phone will not even connect to most cellular networks today, and the laptop is way slower than any phone you can buy in 2017.

But your Dynamics NAV code from 2001 still works 🙂

 

Anti Pattern – TODAY function

One of the oldest features in C/AL and the AL code before that is the TODAY function. It will return the current date from the local computer.

A close friend of TODAY is WORKINGDATE. Working Date is the concept of setting “today” to be something else.

When working with entering data, the ease of type t in a date field for today, and w for working date are good for entering data.

But what about when you’re using TODAY (or WORKINGDATE) in your code?

Yesterday I came across an example in one of our old products:

IF CALCDATE('CM+1D',DueDate) > TODAY THEN
    PostSomething()
ELSE
    PostSomethingElse();

Depending on the current date when the user pressed Post, different things would be posted.

It got me thinking, when is the use of TODAY appropriate in code?

The first valid use case would be to add a timestamp to records, field like “Modified Date, “Created Date”, “Approved Date”. Fields where you are recording the date of a user action.

In most other cases, you should use WORKINGDATE to give your users a chance to control the flow. And if actions in your code depend on Dates – let the user know about this.

Do you have other examples of the bad or good use of TODAY?