Show TOC

 Request Financial Reporting Structure Replication

 

To request replication of Financial Reporting Structure master data from FIN-MDM into a connected Financial Accounting or Financial Consolidation backend system.

Technical Data

Entity Type

Service Operation

Software Component Version

FINBASIS 605

Release State

released

Technical Name

FinancialReportingStructureReplicationRequest_Out

Namespace

http://sap.com/xi/FINB/Global2

Application Component

CA-MDG-APP-FIN

Category

SAP A2A

Direction

outbound

Mode

asynchronous

Idempotency

not applicable

Change/Update Behavior

not applicable

P2P Communication Enabled

yes

Business Context and Use

This service operation is used for asynchronous replication of Financial Reporting Structure master data from FIN-MDM into connected Financial Accounting (FI-GL) or Financial Consolidation backend systems (e.g. SEM-BCS, CPM-BPC).

Related Operations

Replicate Financial Reporting Structure  is the corresponding asynchronous inbound service operation in the backend systems that performs the inbound processing of the messages created and sent by this service operation.

Features

  • This service operation reads Chart of Accounts master data for from the relevant editions in FIN-MDM and maps the generic FIN-MDM data fields to the fixed fields of the relevant message data type proxy (i.e. DDIC-structure USMD_CHART_OF_ACCOUNTS_REPLIC1 and its sub-structures).

  • SOA messages are then created and sent via PI to the connected backend systems (e.g. FI-GL, SEM-BCS, CPM-BPC). The service operation creates one replication request message for each chart of accounts or financial statement item catalogue with data included in the relevant FIN-MDM editions. 

  • For the mappings of the data model fields in FIN-MDM to the fixed fields of the message data  type it is recommended to use SMT Mappings. The data model generation in FIN-MDM generates DDIC structures automatically with naming convention "/1MD/<client>_<data model>_<entity type>" for each entity type to be used as a source structure in the SMT mapping definitions, while the substructures of message data type USMD_CHART_OF_ACCOUNTS_REPLIC1 generally represent the target structures.

  • For further processing of the message data the following prerequisites must be fulfilled:

    • The CategoryCode attribute of the message type has to be set accordingly during outbound processing:

      • CategoryCode = “1”: Distribution into Financial Accounting

      • CategoryCode = “2”: Distribution into Financial Consolidation.

    • In case of distribution into SEM-BCS, the FinancialConsolidationArea attribute for the consolidation area has to be set to a valid value that already exists in the relevant SEM-BCS backend system(s).

Message Types

  • FinancialReportingStructureReplicationRequest

Prerequisites

Customizing for data distribution has been maintained and is complete in FIN-MDM:     - PI configuration is done (in particular: content based routing based on the message header target system info)      - SMT mappings are available and/or relevant BAdI methods are implemented     - Distribution service is defined in FIN-MDM     - Master data package is defined in FIN-MDM     - Assignment to target system is done in FIN-MDM     - Edition with FRS data in FIN-MDM has been released for distribution

Constraints

FS items and text nodes of a FS item hierarchy in SEM-BCS must have different namespaces in order to replicate them with the standard service interfaces.Length of FS item hierarchy name is restricted to 4, Length of FS items is restricted to 10.Otherwise customer has to map on outbound and inbound side.Delta distribution for financial statement versions in FI-GL is not supported in EhP4, i.e. this would produce an error during inbound processing later.

In case of delta distribution, the ActionCodes on edge level (-> relationship tables of the message data types) can not be provided (and will be initial).The service includes always all direct successor node assignments of a parent node (where a change occurred) into the message – during inbound processing the concrete ActionCode of a certain assignment (parent node -> child node) must be derived by comparison of the old status (old hierarchy part) with the new hierarchy part.

Example:

 Edition1:                                                 Edition2:       A -> B                                                A -> C                      -> C                                                   -> D         -> D                                                   -> E

This means that delta distribution of Edition2 results in A -> C, A -> D and A -> E as content in the relationship tables of the message, and:

 A -> B is not included anymore     => ActionCode for this edge would be "Delete",  A -> E is a new edge in Edition2   => ActionCode for this edge would be "Insert"  or "Modify",  A -> C and A->D are not changed In general, inbound processing has to compare the direct edges of each parent node of a message with the existing hierarchy edges of this node in the backend (in case of delta distribution only).

Notes on SAP Implementation

Configuration

You have activated the FIN_MDM_ACC business function (transaction SFW5) and maintained all necessary customizing in the backend systems. FIN-MDM services do not replicate any customizing data, so the required customizing has to be completed in the tartet system(s) before this service operation is used.

Enhancements

The Business Add-In (BAdI) USMD_SE_FRS_RPLCTN is available for this operation (BAdI interface method IF_EX_USMD_COA_RPLCTN~OUTBOUND_PROCESSING). In case of delta distribution into SEM-BCS, this BAdI can be used to provide the consolidation area.