When you create an import, you define the settings and the import format mapping definition. You can create:
One-to-One Mappings—Single Segment and Single Chartfield mappings:
Define a simple one-to-one mapping between source segments and target dimension members.
Pull all members from the source value set as members into the target dimension.
Note:
The topic is not available for file-based data load definitions.
The following figure shows a one-to-one mapping between segments or chartfields in a source system and dimensions in a target EPM application.
Note:
Each member in the source is created as a single member in the target dimension.
Many-to-One Mappings—You can concatenate segments or chartfields to map multiple segments or chartfields from the source into a single EPM dimension member.
When dimensions are mapped as a concatenated segment, the new dimension is created based on the traversal order that you define for the source hierarchies into the concatenated member target dimension. Up to five segments may be concatenated into the target dimension. The following table shows an example of how the segments map to dimensions. In this example, two segments (Company and Department) map to one dimension (Entity).
Segment / Chartfield EPM Dimension Company Entity Department Product Product Account Account
The Import Format allows for the concatenation of source dimensions as the source of target application dimensions. For EBS metadata loads you load the concatenated dimension and the load does not require hierarchies to be associated. However, PeopleSoft sourced applications handle metadata loads differently than EBS.
For PeopleSoft source applications you must have hierarchies associated with the concatenated dimension. This is a requirement for PeopleSoft metadata loads.
If dimension X is sourced from Product + Department, then your metadata rule requires you to have a row in the Hierarchy region which has two hierarchies, one for Product and one for Department. Traversal order must be specified as well and would be Product = First, Department = Second.
This requirement may lead to the inability to handle orphan members (i.e. members not contained within the hierarchies) due to the PeopleSoft dimension structure.