Support for Translations in Write Back from Dynamic Planning to PCR
  • 5 Minutes to read
  • Dark
    Light
  • PDF

Support for Translations in Write Back from Dynamic Planning to PCR

  • Dark
    Light
  • PDF

Article summary

Note:

This feature is available upon request. Please contact Planful to enable.

You can create a Model with Source Segments, map them to the Financial Model and write back to PCR (Structured Planning, Consolidation, Reporting) using a Translations Data Load Rule. The write back map allows you to include Source dimensions as shown in the following example.

image1492zzzzz1232345690123123456901223456789015.png

  • Source Dimension must be a dimension from the source model.

  • Attributes are not supported.

  • You must select AllMembers, MemberAndBelow, LeafMembers or FixedMember as the value Source Filter.

  • The values for Target Dimension, Target Filter, and Target Value must be None.

Additionally, it is not required to map all the PCR dimensions in the Target Dimension column. You can skip them by selecting the No Translation for Unmapped Target Segments check box in the Data Load Rule Write Back ID In this example (image above) the Data Load Rule type is Translations and Account and subAccount are the source dimensions in the MasterModelForWriteback for which the Translations are setup within PCR (shown in the image below). You can map Source dimensions using Translation Setup.

40(2)
For more information on DLR and Translation Setup, refer to the
Data Load Rules and Translations Setup.

Note:

The Source dimension in the Model must be configured with the same name as the Source Segment name setup in PCR.

Let's say, two Source Dimensions are merged and mapped to the target; Account and subAccount Source Dimensions are mapped to the Account. When you load data for the 28 DYN Income account Source dimension and 28 DYNIncomeSubAcc subAccount for the WritebackDLRTranslations model and run write back, the Account DNY_Account1 in PCR gets updated automatically.

The following scenarios provide a few examples where you can use Translations:

  • Mapping two source Segments to one Target Segment - In the above example, the Account and subAccount source segment are mapped to Account.

  • Mapping one Source Segment to one Target Segment - The subAccount Source segment is mapped to Account as shown in the image below. In the second image, the transaction lines for the segments are shown.

    40(2)

  • Mapping two Source Segments to two Target Segments - The Account and subAccount source segments are mapped to Account and Company.

  • Mapping one Source Segment to two Target Segment - The subAccount source segment is mapped to two dimensions.

Translation Requirements:

  • Source Segment names must match dimension names in the source Writeback Model.

  • Source Segment names must be unique across all Translations used by DLR.

  • “Source Column X” must be unique across all Translations used by DLR.

Consistency between DLR and Write Back Map:

  • The Measure in the map must be identical to the DLR Data Type.

Calculation

Once you have created the map for the write back operation that includes the Write Back Id for the Data Load Rule, you will need to add this map to a calculation. Perform the following steps:

  1. In SpotlightXL, select the Model task and the Calculation subtask.

  2. Create a new Calculation for the model you are writing back data from (for example, Finance model).

  3. Add the map to the calculation.

    1. Type = Map

    2. Name = Write back map name (not the write back Id but rather the map created in the step prior)

  4. Save the calculation.

  5. Run the calculation. Note that you CANNOT add this calculation on save for either a View or Report at this time.

Important

You can use one Calculation to writeback data from multiple models to Planning, Consolidation, or Reporting applications, however, one map per model must be provided in the Calculation. Also one data load rule per map must be created in Planning, Consolidation, or Reporting applications.

Set Up the Address Back to the Structured Planning, Consolidation, and Reporting Applications

In Dynamic Planning, login and select the Application that will send data updates to Structured Planning, Consolidation, and Reporting applications.

Manage > Application Settings

In the Soap Uri box, paste the State Free URL that you previously copied in “Maintenance > Configuration Tasks .” Be sure the Username and Password information is up-to-date. (If you have previously entered the username and password, the password field will be blank.) Click Save.

Dynamic Planning: Mapping Data Back to Structured Planning, Consolidation, and Reporting Applications
When you brought data into Dynamic Planning from Structured Planning, Consolidation, and Reporting applications, you specified how the data which had been downloaded into HACPM_Financial should map to the Dynamic Planning target model (called Integration):

  • HACPM_Financial was the Source.

  • Integration was the Target.

Here is the map used in Model > Map before downloading the data.

ModelingImagesDataIntegration-CoreFunctionalSpecDataIntegration-CoreFunctionalSpec121.png

Now you need to map data from Dynamic Planning to Structured Planning, Consolidation, and Reporting applications so Source and Target are reversed.

  • Integration is now the Source.

  • HACPM_Financial is now the Target.

In Practice: Model > Map

  1. The Target Model is HACPM_Financial.

  2. The Name lets you give this mapping a name so you can re-use it.

  3. Type must be set to Data for Write-back.

  4. The Source is the name of the model that contains the changes you want to write back to Structured Planning, Consolidation, and Reporting applications.

  5. Transfer must be set to Leaf.

  6. The Write Back Id is the name of the Data Load Rule that you created in “Maintenance > Data Load Rules .” The Data Load Rule name is case-sensitive.

  7. Leave Access Token blank.

    image1492zzzzz1232345690123123456901223456789012360.png

Source to Target Map Table

Here you must list essentially the opposite of the map of you created prior to data download. The three columns that were on the left will now be on the right, and vice versa. The best practice, however, is to be specific in your map which data items you want to write back using Fixed Member, not to write back all members in all dimensions.

In the example below, instead of writing back all members of Account, Company, Department, Product, and Project, the map specifies only those members which have changed and that you want written back to Structured Planning, Consolidation, and Reporting applications. This way, you can control the flow of data between Structured Planning, Consolidation, and Reporting applications and Dynamic Planning.

Note:

Member names are case-sensitive.

ModelingImagesDataIntegration-CoreFunctionalSpecMCMappingDataBacktothe1.png

Remember that HACPM_Financial has two dimensions, Intercompany and Reporting, that were filtered out prior to data download, and you need to specify the member that data will be written back to. The member specified must be a leaf member. In the example above, Intercompany: Default and Reporting: G/L Data (CC) are leaf members.

For all months in 2014, data for product D006341, account 4010, company 2100, department SLSCA, and Actuals will be written back. Here is a View that shows these member intersections.

ModelingImagesDataIntegration-CoreFunctionalSpecMCMappingDataBacktothe2.png

Note:

If you decide to write back all members of a dimension instead of a fixed member, the dimensionality between the Source and Target dimensions must be the same. If your Source dimension is a subset of the Target dimension, then you can tell Dynamic Planning to write back only the members common to both dimensions by specifying Common under Match Criteria.

ModelingImagesDataIntegration-CoreFunctionalSpecMCMappingDataBacktothe3.png


Was this article helpful?