NAV 2017 – Delivering custom code as extension

Standard

We can still deliver our custom code as a fob in NAV 2017 as most VARs will continue to do so in the foreseeable future, however it seems to me that ISVs will embrace faster the new method. While in my first blog on extensions I was focused on explaining the basics of the technical side of creating an extension, in this blog I will delve into delivering a functional requirement as an extension.

I will go through an exercise of adding a new field: “Created By” Code 20 (a valid user from User table)¬† to Sales documents.

If you’re planning to follow this exercise please review “Setting up your working space” from my previous blog.

I will make this new field available on:

  • Table 36 “Sales Header”
  • Table 112 “Sales Invoice Header”
  • Table 114 “Sales Cr. Memo Header”
  • Page 43 “Sales Invoices”
  • Page 44 “Sales Credit Memo”
  • Page 132 “Posted Sales Invoices”
  • Page 134 “Posted Sales Credit Memo”.

The field will be passed on and made visible on

  • Page 20 “G/L Entries” and
  • Page 25 “Cust. Ledger Entries”

when we drill down on different tables exposed via Navigate action on the posted document.

At this moment, delta files for reports (standard report modifications) cannot be part of an extension. Please visit Extension Packages Capability Support Matrix for updates on this topic.

Therefore my attempt to modify the report 1306 to add the new field in the layout and report failed:

ext21

Delivering modifications to reports must be done in a different way. One alternative is to add a new action on the Posted Sales Invoice and point to a copy of report 1306 (modified to include our field). Therefore our custom code won’t be extension-only based.

This link contains a fob with all the modifications done to a Demo Database 2017 CU9.

The steps to create and publish the extension are very similar to the steps in my previous blog located here.

Let’s test the changes by pointing our Service tier to the target database and publish there the new extension.

First let’s install the extension, by opening page 2500 “Extension Management”:

ext22

Let’s open Sales Invoice page and create a new invoice. The “Created By” field should be in the first FastTab and auto-populated with the logged in user:

ext23

After posting the invoice we notice that the new field is part of the “Posted Sales Invoice” as well:

ext24

Next we want to check the existence of this new field in page “General Ledger Entries” and page “Cust. Ledger Entries”. In the “Posted Sales Invoice” page, in the Actions tab, click on Navigate, and check the 2 pages:

Ext25

ext26

At the core of this simple exercise is the codeunit 50000 in which I subscribed in a few instances to standard events like OnAfterInsertEvent:

 ext28

Thank you for reading, sharing, commenting, liking, following ūüôā

 

Advertisements

NAV 2017: Wizard pages now supported in Web Client

Standard

As of October 2016, NAV 2017 is the latest version of the popular ERP system. To complement the brand new features, NAV team worked on enhancing current features.

A list of the features not supported in NAV 2016 is located here.  Among them, NavigatePage was not supported in NAV 2016 Web Client, but it is now supported in NAV 2017 Web Client.

Let’s delve into creating a simple (yet fit for starting your own)¬†NavigatePage and check it in the Web Client. Additionally, I will suggest a few cases when a NavigatePage is a good candidate to collect data from users and perform some processing in one screen.

The NavigatePage assumes the existence of the following objects (included in the demo):

  • Table 90001 “Generic Entity” with the following fields:
    • field_1 (Code10)
    • field_2(Code10)
    • field_3(Code10)

PK: field_1,field_2,field_3

  • Table 90002 “Generic Entity Comment” with the following fields:
    • field_1 (Code10)
    • field_2(Code10)
    • field_3(Code10)
    • Entry No.(integer)
    • Comment(Text80)

PK: field_1,field_2,field_3,Entry No.

  • Page 90001 “Generic Entity Card”
    • An action to launch the NavigatePage¬†will be located on this page

NavigatePage details:

navigatepage

And the actions:

navigatepageactions

Note: To make the actions appear as buttons on the toolbar and the groups as tabs set each action’s InFooterBar property to Yes.

This simple NavigatePage will collect data(the comment) from the user in Step1 and when the user clicks Next will insert a comment and make visible Step2.

When user clicks Next, the system will:

  • validate the fields in Step1
  • Hide the fields in Step1 group
  • Perform Wizard action (generate the comment)
  • Show Step2 group

When the user clicks on Finish the page closes.

A few snapshots of the NavigatePage as it appears on the Web Client:

genericentitycardpage

Launching Comment – Wizard action:

genericentitycommentwizzard

Click on Next will move the wizard into Step 2:

wizzardsummarystep

Standard NAV has a few NavigatePage pages. Check them out:

  • 5077 -> Create Interact
  • 5097 -> Create To-do
  • 5126 -> Create opportunity

If you have processes in which the users need to go through a few pages to enter data and create different entities, then NavigatePages are a great candidate for improving user efficiency and experience.

I used recently NavigatePages in two instances. Once, when I needed an unified screen to allow users to attach files (word docs, excel files, pdfs) in a Property Management AddOn. The documents were collected and attached to an email sent to the owner at month-end.

Another example was more recent when, with one NavigatePage, I was able to create records similar to a fixed asset, collect mandatory data¬†for a purchase invoice and generate¬†the purchase invoice for that record. Of course you need methods that will take care of generating the purchase invoice, its lines, general ledgers, vendor ledgers, dimensions. Moreover,¬†assertiveness¬†is needed to not end up with half-performed processes¬†… But it’s possible to run your processes through a wizard page with an overall¬†improved user experience and efficiency.

Sample code available here.

NAV Upgrade Notes – Turning Comments into Notes using .NET

Standard

Upgrading a NAV AddOn is not solely merging code and upgrading the database through all NAV versions in between source and target. It involves analysis and prototyping of present AddOn features into features existent in the latest NAV versions. We often ask ourselves how can we replace feature X in our AddOn hosted on a NAV 2009 installation with the new feature Y in NAV 2017?

Sometimes the answer is Yes: we can merge AddOn functionality with existent features in standard. The benefit is major.

Take Comment Line table for example. Almost any AddOn has a storage place for AddOn entities to record comments or notes.

Why keep them recorded in a table in ISV’s range when we could take advantage of an existent standard table perfect for this purpose? Table Record Link was introduced in NAV 2013 and can keep track of notes and links.

The short demo below assumes the existence of:

  • a table “Generic Entity”
  • a table “Generic Entity Comment”
  • a card page “Generic Entity Card”
  • a list page “Generic Entity Comments”
  • ¬†codeunit “Upgrade Notes 1”

To generate notes for each comment in table “Generic Entity Comment” run the codeunit 90003″Upgrade Note 1″.

The text itself resides in a Text field in “Generic Entity Comment”, but “Record Link” table has a BLOB field for recording the text. Therefore I needed to move text from “Generic Entity Comment”Comment field into a BLOB field in¬†“Record Link”.

text2blob

I wanted to use .NET here not only for exercising my rusty .NET muscles, but recording Danish characters in a BLOB proved to be a non-trivial job. So I used MemoryStream class with BinaryWriter which comes equipped with character encoding capabilities.

For a simple demo follow steps 1-4 below:

capture

Code used is available for download here.