Out of around 1.000 SSRS reports in D365FO, Electronic Reporting Business Documents (aka Configurable Business Documents) can be applied only to around 50 Print Management reports. What about the non-Print Management reports? It is true that you can develop ER models, model mappings and formats for them, but you can execute them only from the ER module, which means that you will have a poor user experience. In this article we will show you on example of the Check report how to transform any non-Print Management report into a D365FO ER Business Document, while preserving the user experience of a standard SSRS report.

D365FO Check as ER Business Document

One of the most commonly used non-Print Management reports is US (and Canadian) Cheque. Because it is so important, Microsoft created an ER format for it, but it cannot be started as a regular SSRS cheque report, i.e. from the form where you are handling the payments, or from the paid cheques form. The ER cheque report you can run only from the ER configurations forms, which means that you will each time need to specify the cheques you want to print:

Another bad news about the ER cheque report is its layout:

The Excel cells have been resized to form a grid and the cheque areas where the data should be printed are created as a lot of merged "grid" cells. Each area has to be a named range. I cannot imagine how difficult and unpleasant experience it would be to make any modification in this layout.

D365FO Check as ER Business Document and Docentric Design

Wouldn’t it be great if we could:

• Use "the good" from ER: customizing its models and model mappings without the development,
• But still run the reports in a same way, from the same forms and menu items, as SSRS,
• And as a bonus, not go through the horror of customizing the above Excel?

Yes, we can do this with the Docentric Improved ER Business Documents, because they give us a framework that is capable of:

1. Starting any SSRS report in the standard way (from standard forms, using standard menu items),
2. Fetching the SSRS report datasource,
3. Executing the ER model based on the SSRS datasource structure,
4. Producing the final report datasource (DDSP) that will be an input for the report format,
5. Designing the report format with user-friendly Docentric Designer in MS Word.

In this article, we will explain the steps needed to convert any RDP (Report Data Provider) based non-Print Management SSRS report to an ER Business Document with Docentric report format, on the example of the Cheque_US report.

Analyze the SSRS datasource

First, we need to design a new ER model (and later the model mapping) for the US Cheque report. The simplest possible approach, that guarantees the fastest result, is to replicate the structure of the current SSRS datasource. Therefore, we will find the Cheque_US SSRS report in AOT and open it in designer:

We see that it uses only one data source, Cheque_USDS, and the data source is implemented in the ChequeDP data provider class:

Open the ChequeDP class and find its getChequeTmp() method, notice that it returns the ChequeTmp records:

Open the ChequeTmp table and analyze its fields (only the first dozen of fields are presented in the below image):

Create the ER data model configuration

I have created a new ER data model named Cheque. For the purpose of this article, in my cheque ER model I replicated all the fields available in the ChequeTmp table, including their names, types and labels.

As you can see from the version history, I first created just a couple of fields (ver. 2). I gave them a dummy mapping, just to make sure that the model is successfully executed. Once I verified that I am on a good path, I added all other fields that exist in the ChequeTmp table (ver. 3). Finally, I decided to extend the standard SSRS data source with the payment transactions (ver. 4).

Below you can see how the model looks in the designer. Notice the added BankChequePaymTrans sub-node. You can compare the (yellow-marked field names) with the ones from the ChequeTmp table.

Create the ER model mapping configuration

I have created a new ER model mapping configuration and named it Cheque model mapping:

The three important classes for every SSRS report are:

• Report data provider: responsible for fetching the report data. We will use it to map the data to our ER model.
• Report data contract: responsible for getting the report parameters from the contract.
• Report RDL data contract: responsible for getting the general information about the report (such as: language).

Analyze your report and identify these classes. In the case of cheque, it will be:

• Report data provider: the ChequeDP class (as already explained above)
• Report data contract: SrsTmpTblMarchallercontract (attribute at the beginning of the ChequeDP class)

I have added the objects of these classes to the ER model mapping configuration:

Other data sources you can see in the above image are:

• Calculated field $BankChequePaymTrans: list of BankChequePaymTrans records related to a given cheque.
  This is the formula I used:
  Formula to filter the BankChequePaymTrans records related to a given cheque

  C#

  FILTER(BankChequePaymTransRecords, AND(BankChequePaymTransRecords.AccountId = ReportDataProvider.getChequeTmp.AccountId, BankChequePaymTransRecords.ChequeNum = ReportDataProvider.getChequeTmp.ChequeNum))

  1 2 3

  FILTER(BankChequePaymTransRecords,    AND(BankChequePaymTransRecords.AccountId = ReportDataProvider.getChequeTmp.AccountId,        BankChequePaymTransRecords.ChequeNum = ReportDataProvider.getChequeTmp.ChequeNum))

• Table record BankChequePaymTransRecord
• D365FO enums: AxBankChequeRecipeintType (references the D365FO BankchequeRecipientType enum) and AxNoYes (references the D365FO NoYes enum)
• Data model enum: RecipientType

Mapping is quite straightforward: we have bound our top-level record list CheckSSRS to the data provider class method which returns the ChequeTmp records. Then I continued bounding all the corresponding fields from the both records:

Then I also mapped the BankChequePaymTrans sub-node in my data model to the $BankChequePaymTrans calculated field and repeated the same with all their fields:

Execute the ER-based data source

In the Docentric report setup, for the Cheque_US report we specify the ER Data model and ER Model mapping we want to execute when this report runs:

In the Generation options for this report we specify that the DDSP file should be generated when report runs and then we go and execute the report once, with the main purpose to get the DDSP file:

You can open the DDSP file and make sure that the generated report data source has correct structure and values:

Create the ER-based template

From this moment on it is really simple with the Docentric Designer. We open the existing (SSRS-based) US cheque template and import the previously created DDSP to get the new (ER-based) datasource:

Notice the difference in the top-level structures’ names. We could never have exactly the same names, due to the structure of ER model, but as long as we use the same field names, transition should be simple. We go through the Element Tree, search for all red-colored elements and modify the data bindings to match the new structures.

I have slightly modified the design of this template, by using the blue color instead of the original green background. Next I added the new template to a list of available cheque templates and marked it as default:

Next time when I print the cheque, this will be the result:

Conclusion: D365FO Check as ER Business Document with Docentric Design

By using Docentric, you can transform any non-Print Management report into an ER Business Document. You benefit from non-development approach to customizing your datasource and design, while invoking the reports in a same way as you would do with the SSRS reports.

Resources

Download resources >>

Watch the step-by-step instructions in this video