Saturday, September 28, 2013

What's new with the Dynamics NAV 2013R2 Web client

The web client was a big success with the initial release of Dynamics NAV 2013. With Dynamics NAV 2013 R2 Microsoft has continued the development of the web client to include most, if not all, of the functionality available with the standard Windows client or RTC.
In order for users to have the same experience across all clients the Client Extensibility features from NAV 2009 have been dramatically improved upon. Previously we could only use client extensibility code on the Windows client and it had to be installed on every machine. Data display was limited to .NET / Windows Forms, or Windows Presentation Foundation forms with certain work arounds. Now with Dynamics NAV 2013 R2 we have the ability to use Javascript and HTML5 and we don't have to install it anywhere except the server. We can even use our add-ins on List pages. This continues the trend of introducing NAV to those outside of the NAV world and opens up a world of possibilities. This is the area in which I think the next big innovations will come and I truly hope to see more companies begin to take advantage of it.
These changes drive home what I love about Microsoft's current direction: interface standardization. I come from an educational technology / interface design background and the number one complaint I always hear about software is "It's too hard to figure out!!" The first step to making software easier is to allow users to instinctively learn from other software, to easily move from application to application. Microsoft is nudging developers in the right direction which will do nothing but make better software and happier customers in the long run.

Beware the Third Parameter of MODIFYALL

The C/AL keyword MODIFYALL is tempting to use when a certain value must be changed for every record matching the current filtered recordset.   One may or may not be aware of the third optional parameter for this keyword:  TRUE/FALSE. FALSE is the default. If set to TRUE, the OnModify() trigger is executed when the record is modified.
Consider the following snippet of code:
SalesLine.SETRANGE("Document Type",SalesHeader."Document Type");
SalesLine.SETRANGE("Document No.",SalesHeader."No.");
SalesLine.SETRANGE(Type,SalesLine.Type::Item);
SalesLine.SETFILTER(Quantity,'<>0');
SalesLine.MODIFYALL("Qty. to Ship",0,TRUE);
Using the above snippet of code, the "Qty. to Ship" value will be changed for every sales line matching the filtered recordset. The third parameter, TRUE, indicates the system should execute the OnModify() trigger for every record when changing the value. What the command does NOT do is execute the OnValidate() trigger of the Qty. to Ship field.
The OnValidate() trigger of the Qty. to Ship field of the Sales Line table contains, at minimum, critical code affecting the "Qty. to Ship (Base)" field, without which data errors will be introduced into the database. If code is introduced after the above snippet to release the document and post, Codeunit 80 skips past this particular issue and posts the document. Strange data errors then result when any further action is taken on this document.
The code below is a far safer block of code to execute:
SalesLine.SETRANGE("Document Type",SalesHeader."Document Type");
SalesLine.SETRANGE("Document No.",SalesHeader."No.");
SalesLine.SETRANGE(Type,SalesLine.Type::Item);
SalesLine.SETFILTER(Quantity,'<>0');
IF SalesLine.FINDSET(TRUE) THEN
  REPEAT
    SalesLine.VALIDATE("Qty. to Ship",0);  
      // safe!  code executed to set Qty. to Ship (Base) also
    SalesLine.MODIFY(TRUE);                
      // execute the OnModify() trigger
  UNTIL SalesLine.NEXT = 0;
The key is knowing whether there is any code in the OnValidate() trigger of the field. If there is, it's better to be safe than sorry.

Thursday, September 12, 2013

Dynamics NAV 2013 R2 release at EMEA

Info found at another blog

There are a lot new features coming to us in october. Can't wait to show it to our customers

Info can be found ar the Microsoft launch page