The post New ways to Update Transaction Data in NAV 2015 appeared first on Dynamics 101.
In this demo, we are going to have a look at new patterns that Dynamics NAV 2015 provides for updating data during a transaction.
First, we will discuss the design patterns which were previously used to update the data in Dynamics NAV, and have since become outmoded solutions. Then, we will look at the setup update implemented in Dynamics NAV 2015 version. Finally, we will run a report, check how the new update pattern works, and review the functions it performs. We will also point out the limitations of using the pattern.
Dynamics NAV is traditionally designed to pop-up errors for the user if the data is missing or incorrect before posting routine is started. If we look at the posting routine codeunit, we will see that a TESTFIELD function is called for in order to check the data:
If the data is missing, it gives an error to the user:
Thus, the posting process is rolled back and the user should correct the error in order to continue.
The new design pattern is created to allow users to correct the error without stopping the transaction. This pattern is recommended for small companies where the owner of the issue can actually solve it as well.
The Pattern
Instead of using a TESTFIELD function, Dynamics NAV2015 introduced a set of functions that will check that the data is available and if not, open the necessary page for the user to complete the setup. In general, the new pattern performs the following actions:
- Verify the data
- Pop-up a message to the user with the data that is missing. Usually this is a confirmation dialog where the user can click OK to open the required setup page and complete the setup data entry, otherwise if the user clicks Cancel, the process either runs without the setup (if it’s not mandatory) or throws an error again
- Verify the data again (if the user made some setup data update)
Let’s have a look at the example of how this pattern works in Dynamics NAV 2015. In the Role Tailored Client, navigate to a posted sales invoice and click Print button. A message appears informing the user that Company Information setup is not complete and there is missing Payment data:
If the user chooses to click No, another message appears and a report request page is open:
If the user runs a report at this time, he will notice that the company payment information is blank on the header:
However, if the user clicks Yes on the suggestion to update the payment information, the Company Information page opens on the relevant tab.
This allows for quick data entry of the missing information. Let’s enter, for example, the Bank Name and click OK:
Now, if the user runs the report again, he will get no notification, because the minimum required data was entered in the setup:
Let’s have a look inside of this process and the functions involved. In the Object Designer, select Report 206 and click Design. In the OnInitReport() trigger, we can see a new function VerifyAndSetPaymentInfo():
This function is called for before the actual report request page is available to the user. Right-click on the function name and click Go To Definition. The table 79 Company Information function VerifyAndSetPaymentInfo() is open :
This function calls for another function called IsPaymentInfoAvailable() which checks that either of the payment fields contains data and returns a boolean (true/false) :
Next, the system checks that the user has confirmed to edit the missing data and opens the relevant page in RUNMODAL view. Finally, a check for the payment data is performed again, and if it’s still not available, the user will get the message again.
Pattern Limitations
This pattern is not suitable for substituting TESTFIELD function during the posting process. That assumes data modification, because it implies running a page modally, which causes a block in the system. Dynamics NAV prevents developers from doing that.
Summary
In this demo, we had a look at the new design pattern that allow the users to update data without having to re-run the process once again in case of any errors received. This approach can be effective if used properly and will save time on data entry and setup for the users.