12.1 Electronic Reporting (ER) Framework

12.1 Electronic Reporting (ER) Framework

Quick Answer: The Electronic Reporting (ER) engine is Dynamics 365 Finance and Operations' no-code/low-code framework for generating and importing configurable business and statutory documents. It decouples document structure from application code through three core configuration assets: the Data Model (hierarchical business domain schema), the Model Mapping (binds AOT tables, queries, and entities to the model, running To model for outbound or To destination for inbound), and the Format Configuration (defines physical file layouts in XML, JSON, Microsoft Excel, Microsoft Word, CSV, or PDF). Standard Microsoft configurations are read-only; developers must establish an active Configuration Provider and create derived configurations, which can later be rebased when upstream updates occur. Delivery channels are managed independently via ER Destinations (File, Email, Archive, SharePoint, Electronic Message).

---

1. Electronic Reporting Architecture & Philosophy

In legacy Dynamics AX 2012 and early AX releases, generating regulatory electronic payment files (such as SEPA, ISO 20022, or NACHA), statutory tax declarations, and localized business invoices required extensive custom X++ code and hardcoded SQL Server Reporting Services (SSRS) reports. Whenever banking standards changed or tax authorities updated XML schemas, developers were forced to modify source code, recompile models, and coordinate full application deployments.

The Electronic Reporting (ER) framework eliminates developer code deployments for document formatting by introducing a modern, declarative, metadata-driven engine. ER provides:

• No-Code / Low-Code Configuration: Business analysts and developers configure models, mappings, and formats within the web client UI using visual designers and a built-in formula expression language.
• Decoupled Architecture: Business logic, data extraction, and physical file serialization are separated into independent configuration layers.
• Statutory Agility: Regulatory updates are published by Microsoft as versioned metadata packages that can be imported and merged without code changes or downtime.
• Bi-Directional Capability: ER supports both outbound document generation (exporting data to external systems or tax authorities) and inbound document processing (importing electronic bank statements, vendor invoices, or catalog data into ERP tables).

---

2. The Three Core ER Configuration Components

A complete Electronic Reporting solution separates data definition from data extraction and serialization. Understanding the distinct responsibilities of each configuration asset is fundamental for the MB-500 exam.

Electronic Reporting Configuration Component Architecture

┌─────────────────────────────────────────────────────────────┐
│                     Format Configuration                    │
│  • Defines physical serialization (XML, JSON, Excel, CSV)  │
│  • Transforms Data Model items into target file structures  │
│  • References a specific Data Model definition             │
└──────────────────────────────┬──────────────────────────────┘
                               │ Maps From
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                          Data Model                         │
│  • Abstract domain structure (Hierarchical tree of nodes)   │
│  • Format-agnostic and database-agnostic                    │
│  • Record, Record List, String, Real, Date, Enum nodes      │
└──────────────────────────────▲──────────────────────────────┘
                               │ Populates
                               │
┌──────────────────────────────┴──────────────────────────────┐
│                        Model Mapping                        │
│  • Binds F&O runtime data sources to Data Model nodes       │
│  • Data Sources: Tables, Views, Queries, Entities, Methods  │
│  • Direction: 'To model' (Outbound) or 'To destination'    │
└─────────────────────────────────────────────────────────────┘

1. Data Model

The Data Model is a domain-specific, hierarchical definition of business data. It describes what data concepts exist (such as an Invoice, Payment Line, Customer, or Tax Registration) without regard to how the data is stored in SQL tables or what format the final document takes.

• Hierarchical Node Types: Nodes are organized in a tree containing Record (single complex entity), Record list (repeating collection), String, Integer, Real, Date, DateTime, Boolean, GUID, and Enumeration.
• Format Agnostic: A single Payment Data Model can serve as the data contract for an ISO 20022 XML format, a BACS text format, and an Excel payment summary report.
• Root Definitions: A data model can contain multiple root definitions, allowing different functional areas of the same business domain to be modeled within one asset.

2. Model Mapping

The Model Mapping acts as the execution bridge between the Dynamics 365 Finance and Operations application schema and the abstract Data Model.

• Data Sources: Inside the Model Mapping designer, developers add application data sources, including AOT Tables, AOT Views, AOT Queries, Data Entities, Calculated Fields, X++ Classes/Methods, and Enums.
• Directionality:
  • To model (Outbound): Queries F&O tables and entities to populate the Data Model nodes during document generation.
  • To destination (Inbound): Parses incoming data stored in the Data Model and maps it into target F&O database tables or staging entities during document import.
• Decoupling Benefit: If Microsoft alters internal table schemas, only the Model Mapping needs updating; all dependent Format Configurations remain intact.

3. Format Configuration

The Format Configuration specifies the physical layout, file structure, and encoding of the generated output.

• Supported File Types: XML, JSON, Microsoft Excel (.xlsx), Microsoft Word (.docx), CSV, Plain Text, and PDF (generated via server-side conversion of Excel or Word templates).
• Structure: Contains a tree of format elements matching the target specification (e.g., XML elements and attributes, CSV record delimiters, or named Excel ranges).
• Binding: Each format element is bound to a corresponding node in the Data Model. Format configurations can also define format-specific calculated fields, filtering conditions, and value transformations.

---

3. ER Destinations Architecture & Output Routing

In standard SSRS reporting, print destinations are bound to print management or user session dialogs. In Electronic Reporting, ER Destinations decouple document creation from document delivery. Output routing is configured administratively per format component without altering the format mapping.

[!IMPORTANT] Exam Rule: Decoupled Destination Configuration Destinations are never hardcoded inside the Format Configuration. They are configured under Organization administration > Electronic reporting > Electronic reporting destination. An administrator can assign different destinations to different legal entities, batch jobs, or user security roles for the exact same format configuration.

---

4. Configuration Repositories & Lifecycle Management

ER configurations are version-controlled assets stored in repositories and shared across environments.

Configuration Providers

Every ER configuration belongs to a Configuration Provider (the authoring organization). Microsoft delivers standard configurations under the Microsoft provider. Customers and partners must create their own provider (e.g., Contoso) and mark it as the Active Provider in the Electronic Reporting workspace before creating or deriving configurations.

Repositories

1. Global Repository: The centralized, Microsoft-managed repository hosted in Azure/Dataverse. It contains all out-of-the-box regulatory, financial, and statutory configurations published by Microsoft.
2. Regulatory Configuration Service (RCS): A standalone, cloud-hosted microservice dedicated to authoring and managing ER configurations, Globalization features, and tax engines. RCS enables multi-environment configuration governance and central publishing to the Global Repository.
3. Lifecycle Services (LCS) Asset Library: The legacy repository mechanism for storing and distributing ER configurations across customer projects.
4. Operations / File System: Local environment storage allowing direct XML file export and import of ER configuration packages.

Version Status Lifecycle

An ER configuration version transitions through three strict status phases:

• Draft: The version is currently under design. By default, runtime business processes cannot execute draft versions unless the user enables Run draft in the Electronic Reporting user parameters.
• Completed: The configuration has been finalized, validated, and locked. Completed configurations are fully operational and executable by end users.
• Shared: The configuration is published to a shared repository (e.g., Global Repository) for consumption across other environments.

---

5. Extending Configurations via Derivation & Rebasing

Modifying standard Microsoft configurations requires following strict extensibility rules. You cannot directly edit a configuration delivered by Microsoft (Provider == Microsoft).

Derivation and Rebasing Workflow

Microsoft Provider                          Contoso Provider (Active)
┌───────────────────────────────┐           ┌───────────────────────────────┐
│ Base Format: ISO 20022 XML    │           │ Derived Format: ISO 20022 XML │
│ Version: 1.1 (Read-Only)      │──────────>│ Version: 1.1.1 (Draft)        │
└───────────────────────────────┘  Derive   │  • Added custom tax tag       │
               │                            │  • Modified payment note      │
               │ Upstream                   └───────────────┬───────────────┘
               │ Microsoft                                  │
               ▼ Release                                    │
┌───────────────────────────────┐                           │
│ Base Format: ISO 20022 XML    │                           ▼
│ Version: 1.2 (Completed)      │...................> Rebase Action
└───────────────────────────────┘  Auto-Merge   ┌───────────────────────────────┐
                                                │ Derived Format: ISO 20022 XML │
                                                │ Version: 1.2.1 (Completed)    │
                                                └───────────────────────────────┘

The Derivation Process

1. Set your custom organization provider as the Active Provider in the Electronic Reporting workspace.
2. Select the target Microsoft configuration (Data Model, Model Mapping, or Format) and click Create configuration > Derive from Name: BaseName, Microsoft.
3. Implement custom nodes, fields, or formatting rules in the derived version.
4. Change the derived configuration version status from Draft to Completed.

The Rebase Action

When Microsoft releases an updated version of a base configuration (e.g., updating Version 1.1 to 1.2 to support new statutory regulations):

• In your derived configuration, click Rebase in the action pane.
• Select the new base version (Version 1.2).
• The ER engine automatically merges upstream Microsoft modifications into your derived configuration while preserving your custom elements.
• Any conflicting schema changes are flagged for manual resolution in the designer.

---

6. Scenario Walk-Through: Customizing an ISO 20022 Payment XML Format

Business Scenario

A multinational enterprise operating in Germany needs to generate ISO 20022 SEPA Credit Transfer payment files. The national banking portal requires an additional <OrgId> node inside the <InitgPty> (Initiating Party) block containing the company's Chamber of Commerce registration number. Standard Microsoft formats do not project this field.

Implementation Steps

1. Set Active Provider: Open Workspaces > Electronic reporting, verify the custom provider Contoso is active.
2. Import Base Configuration: Open the Global Repository, locate the ISO 20022 Credit transfer (DE) format configuration, and import it into the local environment.
3. Derive Format Configuration: Highlight the imported format, select Create configuration, choose Derive from ISO 20022 Credit transfer (DE), and name it ISO 20022 Credit transfer (DE) - Contoso.
4. Add Custom Format Element: Open the Format Designer. Navigate to Document > CstmrCdtTrfInitn > GrpHdr > InitgPty > Id > OrgId.
5. Bind to Formula: Using the ER Formula Designer, bind the node value to a formula that extracts the registration number from the company information table: model.Payments.InitiatingParty.Identification.RegistrationNumber.
6. Validate & Complete: Run the built-in format validator. Once clean, click Change status > Complete.
7. Configure Destination: Open Electronic reporting destination, add ISO 20022 Credit transfer (DE) - Contoso, enable the File destination for client downloads, and enable SharePoint for compliance archiving.
8. Assign to Payment Method: Navigate to Accounts payable > Payment setup > Methods of payment, select the target payment method, set Export format configuration to the derived Contoso format, and test the payment run.

---

7. Real-World Exam Traps: Electronic Reporting Framework

[!WARNING] Exam Trap 1: Attempting to Directly Edit Microsoft Configurations Questions frequently ask how to modify an existing standard format supplied by Microsoft. Any option suggesting to "Edit", "Check out", or "Overlayer" the Microsoft configuration is incorrect. Microsoft configurations are strictly read-only. You must set your organization provider as active, derive a new configuration, modify the derived version, and mark it Completed.

[!WARNING] Exam Trap 2: Hardcoding Output Destinations Inside Format Configurations Do not confuse format layout authoring with output routing. ER destinations (emailing, SharePoint archiving, file downloads) are never defined inside the Format Designer or Data Model. They are configured administratively under Organization administration > Electronic reporting > Electronic reporting destination, allowing routing rules to vary per legal entity without changing the format file.

[!WARNING] Exam Trap 3: Running Draft Configurations in Production Business Processes By default, standard transactional business processes (such as posting payment journals or generating tax declarations) reject configurations whose status is Draft. To execute a configuration in production workflows, its version status must be set to Completed. The Run draft parameter in ER user parameters is intended strictly for development and sandbox validation.

[!WARNING] Exam Trap 4: Model Mapping Direction Inversion When configuring inbound file processing (such as importing MT940 bank statements or vendor invoices), developers must set the Model Mapping direction to To destination. Setting the direction to To model is used exclusively for outbound exports where F&O database tables populate the abstract Data Model.

[!WARNING] Exam Trap 5: Upstream Microsoft Updates: Recreate vs. Rebase When Microsoft publishes a new regulatory version of a base configuration, you should never delete your custom derived configuration and recreate custom fields from scratch. The proper procedure is to execute the built-in Rebase action on the derived configuration, which automatically reconciles upstream schema updates while retaining custom extensions.