It's very common for any ERP implementation project that standard, out-of-the-box reports do not meet all the reporting requirements, and that implementation will require either modification of the existing reports or the creation of new reports from scratch. Under this topic, we will learn the basic process of report design and development in Dynamics AX.
Report design is one of the most challenging parts of a project. You need business analysts who understand the business and how data is stored in the system. You also need good collaboration with business analysts and developers. To facilitate this process, a report specification document template should be developed and filled out for each report modification or new report identified. This specification should include the following information:
- Business purpose for change/addition of report
- Description of the report along with its data elements
- High-level description or picture of the layout
- Filters required (for example, select data set by date range, customer group, and so on)
- Test plan (the scenarios to test for and the expected results)
- Report placement and security requirements
- Output medium (laser printer/PDF/Excel)
- Scheduling requirements (weekly/daily/ad hoc)
The following diagram shows the process of report development:
Dynamics AX provides an extensive framework to develop custom reports as per customer needs. A developer uses Visual Studio to create report designs. Dynamics AX reporting extension provides easy access to the AX data source, labels (language support), and business logic. The following are some key considerations that a developer has to keep in mind when developing custom reports:
- Picking the right tool: Picking the right tool for report development based on the requirement is an urgent need. Do you need an SSRS report or an EP chart control report? If you decide to use Management Reporter and need to design financial reports, then, definitely, you need to select the management reporter tool to design your new report. Choice of the proper tool is very obvious when report requirements are clearly defined.
- Deciding the source: There can be multiple places in AX from where the data can be retrieved. Does your report need to be based on detailed transactional data or cube data? Do you want real-time data or can it come from an aggregate cube? Based on the requirement, the developer selects the datasets appropriate for the report. The following types of data sets are supported on AX 2012 SSRS reports—Query based, Report data provider, Data methods, and AX Enum provider.
- For more details on how to create an SSRS report for Dynamics AX, follow the TechNet article at https://technet.microsoft.com/EN-US/library/cc557922.aspx.
- Design to perform: It is important for the developer to understand the performance requirement of the report. Design appropriate filters on the reports to filter the data in the report. Consider some of the newest enhancements in AX 2012 to use the TempDB table and preprocessing classes to generate the required data for the report. Consider general best practices and design principles to create reports that need complex calculations and high-volume data.
- Selecting appropriate report templates: There are several predefined report layouts and style templates available for creating a Dynamics AX report. Layout and style templates provide consistent layout and formatting behavior for your new custom report layout.
- Define data security: That's another important consideration while designing reporting solutions. For example, you don't want a Sales Associate to see the commissions of other Sales Associates. Design appropriate security privileges and duties to secure data.
The testing process for a report is similar to any other custom development. As noted earlier, test scripts should be a part of the report specifications so that the developer can confirm that the report is doing what is expected before it is released to the test environment. This will reduce rework and multiple deployments for the developer.
- Test data: Generate sample data in the development environment to verify results. Evaluate the performance of report execution by testing it on larger data sets.
- Verify layout and formatting: In most of the project reports, development takes more time than anticipated most of which is spent on the layout and formatting of data in the reports. Pay special attention to external reports, such as customer invoices, customer statements, and purchase order reports, and verify the layout carefully to avoid multiple iterations or rework.
- Test print medium: It does happen that the report looks great onscreen, but looks different once printed on the printer or a PDF. Test the report by printing it on paper and other mediums to make sure that the layout and formatting is consistent and acceptable to the business user.
Finally, the reports developed need to be deployed in order to be used by the business users. For report deployment, consider the following:
- Security: Determine appropriate roles and duties that need to be assigned to use the custom report. For analytics reports and cubes, you need to define the appropriate role at the cube level to enable users to access the cube data.
- Scheduling and delivery: Certain reports may need to be scheduled. You can set up batch processes in AX or configure the delivery schedule in SSRS to deliver the reports to the users directly.