Today’s pattern changes the paradigm of how we’ve done error processing in Microsoft Dynamics NAV earlier by providing less-intrusive, more user-productive error processing.
Meet the Pattern
This pattern describes an optimized way to handle invalid, incomplete, or inconsistent data that users enter in journals.
Know the Pattern
Scenario: A user has entered data on a journal line and proceeds to invoke a processing action on it, such as posting or exporting to electronic payments. Microsoft Dynamics NAV validates the data before it is committed. If any validation errors are found, the user must be informed of validation errors in the most optimal way.
One design is that when an error is found, stop execution and prompt the user to correct the error. After correcting the error, the user restarts processing and is stopped again at the next error, and so on. Stopping and showing each error is time-consuming and frustrating for the user.
Another design is that processing does not stop when an error is found. Instead, all errors are gathered in a table and displayed all at once at the end of processing. This way, the processing is ideally invoked only once, reducing the time and effort spent by the user to expose and correct all data validation errors.
In both designs, the processing is not finalized if any errors are found (for example, exporting to electronic payments is not done, until the data error is resolved).
This document describes how to implement the second error-handling design: Showing all errors at the end.
Use the Pattern
The example below comes from the implementation of SEPA Credit Transfer.
After setting up SEPA-specific configurations, the user can start entering vendor payments that will later be exported to the payment file. (The setup depends on the country, but generally involves choosing number series for SEPA export files, choosing the export format, and enabling SEPA Credit Transfer.)
In the W1 solution (and most of the country-/region-specific versions), payment lines are created in the Payment Journal page, from where the user can invoke the Export Payments to File action, which will attempt to create a SEPA-compliant XML file containing the description of the journal payments that are to be made by the bank.
When the Export Payments to File function is invoked, Microsoft Dynamics NAV validates the journal line data. If the data must be completed or updated, then no file will be created and the user sees the following message:
To give a visual overview, the lines that need corrections are highlighted in red. The factbox is context-sensitive, meaning that it shows only the errors that relate to the currently selected line.
When the first payment journal line is selected, the FactBox show errors for the first line.
When the second payment journal line is selected, the FactBox shows errors for the second line.
In the following table, the Generic Object column contains the objects that you can use as a base for your implementation.
Sample W1 implementation of SEPA Credit Transfer*
This is the journal list page where the user invokes the processing action.
Action on Page
The processing action invoked by the user on the journal list page.
Export Payments to File
Errors Page List Part
A FactBox that displays any journal line validation errors.
To improve user experience, the developer can highlight the lines with errors in red and conveniently sort the lines with errors at the top.
Payment Journal Errors Part
Contains code that checks that the journal line contains correct, complete, and coherent data and that the line is ready for whatever process must be done next.
SEPA CT-Check Line
Executes the processing of the journal lines.
SEPA CT-Export File
Journal Error Text Table
An extra improvement would be to add a drilldown or a link to the page where the user can fix the error. This would significantly simplify the scenario by excluding manual navigation and investigation by the user to find the page where the error can be fixed.
Payment Jnl. Export Error Text
* The W1 implementation of file export for SEPA Credit Transfer contains the generic SEPA functionality. However, due to differences in data models and user scenarios in various country implementations, the selected local versions contain adaptations of the generic functionality.
Find below a diagram describing the flow between the objects involved in the journal error processing.
Following the flow above, the code (in the SEPA Credit Transfer example) is as follows.
Read more on NAV Wiki...
The NAV Application Patterns team
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|Опции темы||Поиск в этой теме|