Study guide
12.1 Electronic Reporting (ER) Framework
Microsoft Dynamics 365: Finance and Operations Apps Developer Associate MB-500
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud & Ecosystem Architecture
1.1 Cloud vs On-Premises Architecture & Deployment Typologies 1.2 Microsoft Ecosystem Integration & Extensibility Boundaries 1.3 Lifecycle Services (LCS) & Implementation Portal
2 Chapter 2: ALM, Environments & Unified Developer Experience
2.1 Package Deployment & Servicing 2.2 Unified Developer Experience (UDE) & Power Platform Admin Center 2.3 Environment Management & Governance
3 Chapter 3: Visual Studio Development & Metadata
3.1 Visual Studio Extension Models & Packages 3.2 Application Explorer & Element Designers 3.3 Database Synchronization & Visual Studio Debugging
4 Chapter 4: Azure DevOps Version Control & CI/CD
4.1 Version Control Architecture: TFVC vs Git in F&O 4.2 Branching, Merging & Conflict Resolution 4.3 CI/CD Build Pipelines & Artifact Generation
5 Chapter 5: UI Elements: Forms, Menus & Labels
5.1 Form Design & Form Patterns 5.2 Menus, Menu Items & Navigation 5.3 Label Files & Localization
6 Chapter 6: Data Model: Tables & Relational Design
6.1 Table Design & Extension 6.2 Views, Queries & Maps 6.3 Data Entity Design & Modeling
7 Chapter 7: Classes, Attributes & AOT Modifiers
7.1 Class Architecture & Access Modifiers 7.2 Attributes & Reflection 7.3 Event Handlers & Pre/Post Method Events
8 Chapter 8: X++ Core Programming & CRUD Operations
8.1 X++ Syntax, Control Flow & Global Functions 8.2 Data Manipulation & CRUD Logic 8.3 Best Practice Rules & Compiler Diagnostics
9 Chapter 9: Advanced OOP, Chain of Command & Extensibility
9.1 OOP Principles & QueryBuilder Class 9.2 Chain of Command (CoC) Implementation 9.3 Extensibility Patterns & Non-Breaking Changes 9.4 Event Handler Classes & Delegate Architecture 9.5 Variable Scoping, Declaration Placement & Object Lifetime
10 Chapter 10: F&O Frameworks & SysTest Unit Testing
10.1 SysOperation Framework Architecture 10.2 Workflow Framework & SysExtensionSerializer 10.3 SysTest Framework & Test Explorer
11 Chapter 11: Reporting Architecture & SSRS Reports
11.1 Reporting Architecture & Datastores 11.2 Report Data Providers & Contracts 11.3 SSRS Report Design, Deployment & Security 11.4 Determining When to Use a Specific Reporting Tool or Platform
12 Chapter 12: Business Intelligence, Workspaces & Electronic Reporting
12.1 Electronic Reporting (ER) Framework 12.2 Power BI Integration & Analytical Workspaces 12.3 Workspaces, Tiles, Lists & KPIs 12.4 Excel Integration & Office App
13 Chapter 13: Integration Patterns & Service Endpoints
13.1 Integration Pattern Evaluation & API Selection 13.2 Custom Services & SOAP/REST Endpoints 13.3 Consuming External Services & REST/SOAP APIs
14 Chapter 14: Data Management Framework (DMF) & Batch Processing
14.1 DMF Concepts, Projects & Sequencing 14.2 Entity Change Tracking & Recurring Integrations 14.3 Composite Entities & Batch OData API 14.4 Monitoring Entity Status, Availability & Job Execution
15 Chapter 15: Power Platform, Business Events & Azure Integrations
15.1 Dual-Write & Virtual Entities 15.2 Business Events Framework 15.3 Azure Key Vault Integration & Secure Storage
16 Chapter 16: Role-Based Security & Extensible Data Security
16.1 Role-Based Security Architecture 16.2 Extensible Data Security (XDS) Policies 16.3 Security Enforcement & Best Practices
17 Chapter 17: Performance Optimization & Data Access Patterns
17.1 Table & Form Caching Mechanisms 17.2 Temporary Tables & Set-Based Operations 17.3 Query Tuning, Indexes & Concurrency 17.4 Diagnostics: Trace Parser, Async & Sandbox Frameworks 17.5 Tuning Variable Scope, Buffer Lifetime & Memory Pressure
12.1 Electronic Reporting (ER) Framework
Key Takeaways Explain This Topic AI
The Electronic Reporting (ER) engine is a configurable, no-code/low-code reporting and document exchange framework designed to replace hardcoded SSRS reports and custom X++ export routines for statutory, regulatory, and business document generation.
An ER configuration hierarchy consists of three core decoupled artifacts: the Data Model (abstract business domain structure), Model Mapping (binding AOT tables, views, and data entities to the model), and Format Configurations (defining output structure such as XML, JSON, Excel, Word, or CSV).
ER destinations decouple output generation from delivery, allowing administrators to route generated documents to File, Email, Archive, SharePoint, Electronic Message, or Power BI without modifying the underlying format configuration.
Microsoft-delivered standard ER configurations cannot be modified directly; developers must create an active Configuration Provider and derive custom configurations, which can subsequently be rebased when Microsoft releases upstream updates.
Inbound ER configurations use Model Mapping with the direction set to 'To destination' to parse incoming files (XML, CSV, Excel) and insert or update records directly in Finance and Operations tables or staging entities.
Last updated: September 2026
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.
Destination Type Delivery Behavior Common Enterprise Use Case
File Downloads the generated file directly to the user's web browser session. Ad-hoc user downloads, interactive testing, on-demand statement exports.
Email Sends the generated artifact as an email attachment via SMTP or Exchange. Recipients, subject, and body can be evaluated dynamically using ER formulas. Sending customer payment receipts, automated vendor remittance advices.
Archive Stores the generated file in Dynamics 365 Document Management ( DocuRef ), persisting it in Azure Blob storage. Regulatory compliance, audit retention of generated tax reports.
SharePoint Automatically uploads the generated file to a designated SharePoint document library or folder. Corporate document repositories, shared audit archives, external workflow triggers.
Electronic Message Passes the generated output directly into the Electronic Messages framework for transmission to government tax portals. Peppol e-invoicing, Spanish SII, UK Making Tax Digital (MTD), Italian SDI.
Power BI Outputs structured analytical files into Power BI workspaces. Feeding operational metrics into analytical dashboards.
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
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.
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.
Lifecycle Services (LCS) Asset Library: The legacy repository mechanism for storing and distributing ER configurations across customer projects.
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
Set your custom organization provider as the Active Provider in the Electronic Reporting workspace.
Select the target Microsoft configuration (Data Model, Model Mapping, or Format) and click Create configuration > Derive from Name: BaseName, Microsoft .
Implement custom nodes, fields, or formatting rules in the derived version.
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
Set Active Provider: Open Workspaces > Electronic reporting , verify the custom provider Contoso is active.
Import Base Configuration: Open the Global Repository , locate the ISO 20022 Credit transfer (DE) format configuration, and import it into the local environment.
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 .
Add Custom Format Element: Open the Format Designer. Navigate to Document > CstmrCdtTrfInitn > GrpHdr > InitgPty > Id > OrgId .
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 .
Validate & Complete: Run the built-in format validator. Once clean, click Change status > Complete .
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.
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.