Sooner than expected, the next step in NAV reporting is available and I have called it Wordlayout+, because it extends the standard Wordlayout capabilities of NAV 2016. Especially the following features have been implemented:

  • Nested Groups (Customer -> SalesHeader -> SalesLines, e. g.)
  • Improved image handling (empty image is displayed as empyt, image size is retained)
  • Manual line breaks within plain text controls (“Allow multiple paragraphs” works now)
  • Repeating Sections around arbitrary paragraphs, table rows or even whole tables (standard NAV works only for one table row)
  • Formatted output for Rich Text Controls works now
  • Optionally blank zero values

How is it implemented?

The implementation is as close to standard NAV as possible. The investigations in the previous post https://massivedynamicsblog.wordpress.com/2016/09/08/wordlayout-revisited/ already suggest the most elegant implementation. In fact, only one Codeunit (9651) has to be modified slightly and a new server-based AddIn has to be copied to the server AddIn folder. Technically speaking, the standard WordReportManager AddIn with its method MergeCustomXML has been replaced by a new AddIn with the above features.

How does it work?

In a first step, the output of the REPORT.SAVEASXML function is converted to CustomXMLPart-format via an XSL-Transformation. This transformation also converts empty text elements to a space character and empty image elements (whose names start with “img”) to a small white one-pixel-image. This is done in order to avoid the standard word placeholder text/image for empty content controls (“Click here to enter text.”, etc.). Furthermore, for elements whose names start with “b0”, a “0” (zero) is automatically blanked to a space and the formatting of decimal values is done with respect to the decimalformatter attribute, given in the NAV XML data (it would be nice, if there were also a blankzero attribute). After this transformation, the custom xml part is replaced in the wordlayout template. That’s all.

When you open the resulting document in word, the content controls are filled with the xml data automatically by the word application. All content controls are retained. In standard NAV functionality, the content controls are removed and only their content is retained. With the new feature of retaining content controls, it is now possible to edit the word document and import the custom xml part back into NAV, because any change of a content control is immediately saved in the custom xml part of the word document.

What is now possible?

In order to demonstrate the new capabilites, I created a Wordlayout for the standard report 108 “Customer – Order Detail” as close as possible to the standard RDLC layout. You can download the slightly modified report object together with a fully functional demo version of Wordlayout+ here:


In the print result, there is hardly any difference between RDLC and Wordlayout+. I have relinquished to implement the conditional visibility of the filter expressions on page 1, but this could be done with manual line breaks, prepared within NAV report code. Here is a screenshot of the new Wordlayout+ for report 108:

Report 108: New Wordlayout+

Within a Rich Text Control, you can use formatting expressions to display some parts of the content in bold or italic, for example. This is not possible within standard Wordlayout. Further information is provided in the following posts.

What are the drawbacks and how may they be improved?

The concept of Wordlayout+ differs in some respect from the standard NAV approach. Within the standard approach, the population of the content controls is done manually in the Word document part, using rather low level functions of the Open XML SDK library. Since this seems to be a difficult task, there are now severe limitations and missing functionalities, like for example nested repeaters or support of rich text controls. On the other hand, Wordlayout+ takes advantage of the built in functionality of the Word application to populate the content controls automatically, when opening or printing a document. The drawback is of course, that an instance of Word, preferably on the client side, has to be installed in order to use this built-in functionality. This has been strictly avoided with the standard approach. For example, no Word instance is necessary to use standard Wordlayout and print the result as a pdf. In order to accomplish this, a third party library, aspose.words, is used on the NAV server. If this server-side print-to-pdf functionality should be implemented in Wordlayout+, the content controls had to be populated, first. This would require a Word instance on the NAV server, which is not recommended. On the other hand, if Word is used on the client side, anyway, the pdf output could be directly created by Word automation methods like Microsoft.Office.Interop.Word. In this way, other tasks like removing empty content controls, could be handled, too. So the obvious extension of Wordlayout+ is to use client-side Word automation in order to process the document further or print it to some other format like pdf, e. g. – I will call the next step Wordlayout++…


One thought on “Wordlayout+

  1. Known issues:
    1. When a report produces no data, the Wordlayout template is shown as output with the default custom xml part. Instead, all content controls should have been emptied. (minor bug)
    2. When print to pdf is requested from within standard NAV, the Microsoft.Dynamics.Nav.PdfWriter.WordToPdf function is used, which is based upon the standard Wordlayout functionality and cannot handle advanced WordLayout+ goodies like nested repeaters, etc. To fix this, the function ConvertToPdf in Codeunit 9651 has to be extended. For WordLayout+ reports, the WordHelper.CallSaveAsPdf function should be used, which requires Word on the client side to be installed. Sample Code is available on request and works properly.
    3. For decimal data, the format attribute “decimalformatter” is currently ignored by Wordlayout+. This should be corrected. Workaround: Format the data within the NAV report with the FORMAT function. – Solved in the meantime (see update below)
    4. If a repeater is not fed with data from the NAV report, an empty section (table row, etc.) is shown with the content control names, defined in the Wordlayout. Instead, the section should not be rendered or should be empty in this case (similar to issue 1). This is especially problematic in the case of a nested repeater, which has no data in parts. Workaround: Instead of no data, at least one empty record should be output for each dataitem, which is mapped to a repeating section content control. (will be fixed with Wordlayout++)

    21-09-2016: Version 1.1 released, download link has been updated; please download again and replace the DLLs
    Improvements: decimal formats from NAV are working now and a new blanking zero feature has been introduced (see the updated documentation within the download package).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s