Electronic Reporting: The Hidden Gem

By CA Neeraj Kumar and Ramita Chaurasiya

 Explore the Electronic Reporting (ER) module in Microsoft Dynamics 365 (MS D365) ERP with this guide. Authored by experienced consultants, it covers ER basics, key components, and practical report preparation tips. The book includes hands-on examples like date

• Language: English
• Publisher: Blue Rose Publishers
• Release date: May 2, 2024
• ISBN: 9789362617187

Book preview

Basic Concepts of Electronic Reporting

CONCEPT-001 What is Electronic Reporting, please give the introduction.

Answer:

You are reading this book, so we hope you have already heard the name of ER, i.e., electronic reporting. It’s one of the reporting tools to configure both outgoing and incoming formats. Outgoing formats like print documents, reports, request payload of third-party integrations, etc. can be generated using the ER. Similarly, import utilities, update the database, parse response payloads, and update the required fields in the application (D365 F&O).

It is based on the concept of "configuration instead of coding". Users can define the configuration as per the business requirements.

ER contains mainly the data model, model mapping, format (both export and import), and format mapping. [see the details later].

It becomes easier to maintain the changes made in the configuration through version control. Updating the configuration in the production environment does not require any deployment. Configuration files can be exported in XML files and imported in the other environment. There is another way also, like maintaining the configuration files through RCS (Regulatory Configuration Services).

Navigation for Electronic reporting:

1) Electronic reporting Workspace

2) Organization Administration >> Electronic reporting.

There are three types of configurations available:

1) Reporting configuration: Contains all the ER configurations for import and export. [It will be used much ]

2) Tax configuration: Contains the ER configuration for the calculation of tax.

3) Metadata Configuration: [Not the part of the book ]

We are very much aware of the SSRS report (SQL server reporting services) for designing any print document and reports. Parallelly, Microsoft (MS) has developed business documents like Sales invoices, purchase orders, Sales orders, etc. through electronic reporting. These configuration files can be extended further as per the requirement. It uses the print management framework.

CONCEPT-002 As we mentioned above SSRS is already available for designing print documents and reports, then what is the need for electronic reporting, and why is SSRS not being used?

Answer:

Using electronic reporting does not mean replacing the SSRS completely. The main point to consider here is that whenever we make any changes in SSRS reports, the same needs to be deployed into the Sandbox environment and then to the production environment. It requires downtime to move the objects from one environment to another.

Suppose there is a field of Invoice date on the sales invoice print document, and it is showing today’s date instead of the invoice date, the same has been missed during the testing phase as all were testing the invoice date on the same date as of posting. In the production environment, it was noticed that yesterday’s generated invoice is showing today’s date. Now this has become a major concern for the dispatch team. The consignment is already loaded on the truck and invoice print is mandatorily required for dispatch and transport of the goods. Panic situation for the business team!! The logic is verified in the development environment, and it is found that the invoice date has not been picked from the CustInvoicejour table and is instead given as getcurrentdate().

Doing the changes in the print is not a big or challenging task, it could be done within a few minutes, the main challenge here is to deploy that change to the sandbox environment and then to the production environment, all these would require crucial time.

Now imagine the above Sales invoice print document is prepared using the electronic reporting tool. Once the issue is identified, the user can update the configuration file and correct the binding. Complete the model mapping, export the XML file, and then import the same into the production environment. Take a new print and the issue gets resolved. All this can happen in the next 10 minutes. Now the situation is under control.

Many of us can argue that such changes can be handled using the PDF editor. The main concern here is the frequency of the changes and its maintenance. Doing the deployment is not a challenge every time. It’s about the frequency of the changes. Even while using electronic reporting, we will be using technical changes like preparation of methods in X++, adding new buttons, new tables, new forms, etc. But these changes won’t be having frequent changes. There is always a high possibility of making changes whenever some logic has been written.

Let’s come again to our main question, why is ER, not SSRS? We can try to move as much as possible for a report preparation over the electronic reporting from SSRS but not all. Configuring the report in electronic reporting requires technical skills as well. In the SSRS, we are already developing all the reports and have overcome the performance issues over time. There are other data warehouse technologies to handle large numbers of data as well.

In Electronic Reporting, print documents can be prepared in the Excel spreadsheet designer. Business users are very familiar with the Excel spreadsheet instead of Visual Studio – SSRS report designer. So, a business user can provide the requirements in the Excel spreadsheet easily. After adding the placeholders for different fields, the Excel template can be prepared and uploaded in the electronic reporting configuration.

CONCEPT-003 Does it not exist earlier? Why was it not explored that much earlier?

Answer:

An electronic reporting tool was not available in the AX2012. We had document templates available in AX2012 where data from multiple tables can be configured to update the placeholders and generate some reports or print documents.

In the D365 F&O, we noticed it is mostly due to Tax configuration. Whenever we need to extend the tax configuration, we make some changes in the Model, mapping, and tax document. Also, to extend the standard GSTR 1 and GSTR 2 configuration files.

There was less documentation for electronic reporting available earlier, we could see many blogs across the internet but those are focusing on the initial detailing of electronic reporting, Microsoft documents were also available and enough to start working on the electronic reporting, but practicing as per those documents was a little tedious. There is always confusion among technical and functional about who should focus on electronic reporting. While working as a functional consultant, we face challenges in knowing the table structure, relations, joins, etc. While working as a technical consultant, it seems that preparation of the model and binding to data sources can be handled by functional easily, so why shouldn't they work on it?

Electronic reporting is something that connects functional and technical aspects of report design very beautifully. A functional understands the requirements of the business users, the formats, the tables, and their fields. And can prepare Excel templates. But when there is a relation between multiple tables and to pick data from data sources using business logic, we require a technical person to write the code for us. We will also share our experience of how as functional consultants we overcame this