Application Design Pattern: Report Selection
From the PRS workshop at NAVTechDays 2014, this pattern was written by 2 work groups:
- Group 1: Dale Gauci & Kimberly Congleton
- Group 2: Jens Winberg, Tim Grant, Alen Tot
Thanks to Tim Grant for merging the two patterns, correct, send for review, and finalizing them!
Meet the Pattern
It should be possible to change which document report object should be used when printing. This configuration can be stored in one place (Report Selection) and available at configuration time. In this situation, the code for printing records can remain the same.
The purpose of this pattern is to describe the process to implement a reports selection by retrieving the specific Document Header, determining which type of document is related to it in the Report Selection page, and call the report which needs to be printed by passing the specific document header. This specifies the reports that you can print when you work with the various documents for sales and purchases, such as orders, quotes, invoices, and credit memos.
Know the Pattern
In Dynamics NAV, you canpreselect which report will be printed when you print from various types of purchase and sales headers. For example, on an order, the Order Confirmation report is automatically printed.
The Report Selection table contains the specification of which report will be printed in different situations. The Report Selection table also contains the report ID and report name for the report that will be printed when the user works with a given document type.
The user can, of course, choose to have Dynamics NAV print a different report than the preselected one. You can also add reports to the Report Selection table to have the program print more than one report per document type.
This pattern should be used when the user needs to print a new type of document which can have different report layouts, or when the user needs to print several different reports in sequence. This can also be used during a new post and print routine, a test report for journal posting or for re-printing a posted document. Using this pattern will minimize code by allowing a flexible means of specifying different reports to print, instead of hard-coding a report id when printing a document.
Use the Pattern
The Report Selection Pattern involves the Report Selection table as the central configuration element also with the Report Selection page. The table is used in 4 generic functional workflows:
1) Test Print un-posted
If the Report Selection is related to a Test Report relating to a document:
- The document’s page object including printing actions
- Test Report-Print Codeunit 228
2) Print un-posted. If the Report Selection is related to an existing document (un-posted):
- The document’s page object (document / list) including the printing actions
- The Document-Print Codeunit 229 is used atomically to use the document type in the generic Sales Header table before the report selection is found.
3) Print while posting. If the document is printed at the point of posting then:
- The document’s Post + Print Codeunit (82 or 92), with the related GetReport andPrintReport functions.
4) Print after posting. If the Report Selection is related to an existing document (posted):
- The specific document related posted header table is used along with a typical function: PrintRecords within the respective table.
Example
Sales Document (Invoice)
Pre-conditions
- The document header/lines table is present and there is a report which has a parent DataItem linked to this document.
- A document and list page is present and related to the document.
- A post-and-print codeunit exists for the document.
Continue reading on the community.dynamics.com NAV Patterns wiki site…
