Introduction to Electronic Reporting (ER)

Today we will start a series of entries to explain all the details of Electronic reporting or electronic reports. This tool, a little forgotten, helps us create reports without involving a developer!

Generic Electronic Reporting (GER), better known as Electronic reporting (ER) or Electronic Reports, is a tool designed to configure electronic document formats, whether input or output information, by the legal requirements of any country or region. For example, as we see a lot in Latin America, by adopting legal requirements, we will be able to generate XML for the exchange of electronic invoicing or also generate the printing of an Invoice or Purchase Order document, complying with government requirements.

This tool is aimed at functional users rather than developers. This is because document formats are configured rather than code, and creating and adjusting formats is faster and easier than developing them.

Anyone who has implemented a system will agree that there are many different formats to generate the printing of a Customer Invoice or a Sales Order, for example. Usually, can this implies investing hours in development. But with this tool, it is no longer necessary.

Advantages of the tool

We can mention three main concepts:

Configuration instead of coding.

It allows us to carry out a configuration designed to be carried out by a functional user since the data models are defined in business terms and not in programming languages.

In addition, all configuration components are done through visual editors and not programming IDEs, providing a language for data transformation that is very similar to Microsoft Excel formulas.

One configuration is valid for multiple instances of Dynamics 365

It is possible to control a specific data model per domain. We can also maintain a single format for various instances and update specific modifications without creating a data model and format per instance.

Easy or automatic update

Each configuration has a data version, which can be updated to the Lifecycle Services (LCS) asset library and used as a data repository.

In the same way, any version that we have in the LCS asset library can be installed in the environments.

In addition to these advantages, we can mention that once an end user is recognized to make changes to these electronic reports, and since the entire solution is part of the standard, they only need to enable user roles for this tool to be used.

Repository

The repository hosts the configurations of the electronic reports. Here we can differentiate two types of enabled repositories:

Operations resource is a repository that allows access to the confirmation lists that Microsoft, as a provider of Electronic Reports, releases as part of a Dynamics 365 implementation. These configurations can be imported into the instance and used for the Reports.

This repository allows access to these configuration lists for a specific LCS (LCS Asset Library) project. Here you can import shared project settings to other LCS asset libraries. Like the Operations Resource, it allows you to import configurations to the Dynamics 365 instance.

Structure of the Electronic Outgoing Reports

Each electronic reporting configuration has two distinct components:

Data model.

The data model is the representation of the information structure that we are going to use for the reports. For example, if we need to display company data, the data model could be something like the following:

- Company
     - Name
     - IdCompany
     - Address
         - Street
         - Number
         - City
         - Commune
         - Country
     - TaxGroup

We represent the necessary data for the report, corresponding to the company.

The data model does not only consist of this set of entities and their hierarchical definition, as we saw in the company example. But there is also a model mapping sub-component.

This model mapping links the application's data source (Dynamics 365) to each data model element. It also specifies this business data's data flow and population rules to data model elements.

Following the previous example, we complete the information by saying that:

- Company
     - Name          - > CompanyInfo.Name
     - IdCompany      - > CompanyInfo.DataAreaID
     - Address
         - Street       - > LogisticsPostalAddress.Street
                            Related to CompanyInfo.DataAreaID
         - Number     ... etc . - City
         - Commune
         - Country
     - Tax Group

Format

The Format component is the report output that will be generated when it is run. The format consists of the elements:

• The format contains the structure and contents of the report to be generated.

• A format mapping, which functions as a link between the Data Model and the Format

• The validations are carried out at execution time, which will control the generation of the report. For example, rules that govern the generation of a purchase order report do not have the complete delivery form.

So the data flow for the output reports is shown like this:

Structure of Electronic Entry Reports

We can also work with input reports, which input data to the Dynamics tables. In this case, the components of the electronic report take another definition not far removed from the output reports.

The format defines the structure and content of the electronic input document. It parses the incoming document in different formats, such as text and XML.

The format mapping links the format elements to elements of the data model. At runtime, the data model elements specify the rules for importing this data from the document and storing it in the model.

Finally, the format validation is the configurator rules that control this import. For example, if we import a bank statement and we do not have the supplier's code, we can manage to exclude that record.

Setting

An ER configuration is a particular component of reports. This can be a data model or format and include multiple versions. Each configuration is marked as associated with a configuration provider.

These configuration providers are the authors of each electronic reporting configuration.

Each Report configuration contains a data model component. A format component can be derived from a specific data model.

The original data model is inserted into the child component's format configuration as the default data source.

As seen in the image, we have a data model configuration, "EEPP Model", and the " EEPP " report of type format that inherits and works with the data model component.

So far, we will get with this introductory post. In the next one, we'll work with our first report from step one, where I set up the model, to the report's output. See you!