I have worked with several D365FinOps customers to design and develop reporting and analytical solutions as part of their D365FinOps implementations. I found it quite interesting that many customers know what solutions are available but are not sure how they work, what they are best for, and how to implement them.
This blog series will explain a few standard reporting and analytics solutions or components, what they are best for, and what is involved in implementing them.
- Operational View (Part 1)
- Document Reporting (SSRS) (Part 1)
- Financial Reporting (Part 2)
- Electronic Reporting (Part 3)
Operational View
| Purpose | As part of the D365FinOps process flow, business users interact with to perform day-to-day tasks. |
| Development Effort | Medium. |
| Development Skill Set | Visual Studio D365 development skills. |
The operational views and forms are native D365FinOps application interface components that allow end-users to gather information for their day-to-day operations quickly.
There are a lot of operational views out of the box under each Workspace. These operational views would typically provide a list of filtered datasets, e.g. unpaid invoices, unposted statements etc., for end-users to operate on, e.g., paid the invoice or post statements.
These operational views are an integral part of the D365FinOps application life cycle and are critical to operating the D365FinOps application.
The screenshot below is an example workspace for “Production floor management”.
Design and Development
As the operational views are part of the D365FinOps application, we need to follow the standard D365FinOps development and customisation process to design and develop new operational views. We will need to use the D365FinOps development server (either self-hosted or cloud-hosted) and create a new Visual Studio solution/project.
Apart from developing new operational views shared for all the users, business users can also introduce their personalised workspaces and combine operational views that get data from different parts of the D365FinOps application. The personalised Workspace could serve as the landing page for the business users operating in D365FinOps.
Document Reporting (SSRS)
| Purpose | Operational reporting, provide paginated reports and business document reports. They are also used to print or send formatted business documents such as sales Invoices to the customers or purchase orders to the vendors. |
| Development Effort | High |
| Development Skill Set | Visual Studio D365 Development skills. |
SSRS reports are another fundamental component of the D365FO application. Each functional module in D365FO has a dedicated section for them. For example, the screenshot below shows the “Inquiries and reports” section under the “Accounts payable” module. If you have not used these reports below, please spend some time browsing them, and you will find a lot of valuable reports.
Below is the screenshot of the “Vendor aging report”.
Also, when we open any business document, such as a customer invoice, there will be “View” and “Send” commands on the menu bar to open the invoice in a pdf format or send the invoice as an email attachment.
Design and Development
SSRS reporting is part of core D365FinOps development, and we need to follow the standard D365FinOps development and customisation process. We will need to use the D365FO development server (either self-hosted or cloud-hosted) and create a new Visual Studio solution/project.
The development of new reports will involve X++ coding or AOT query creation to create the data providers, and then design the SSRS report in Visual Studio, which uses the data providers to retrieve data instead of writing SQL statements as with the standalone SSRS development.
To customise an existing report, we would need to extend the current data providers and create a new copy of the SSRS report to add new data to the report. And customise the existing calling place of the report to call the newly created reports.