James,

1. The mapping is applied during the import process in FDM.
2. Take a look at the conditional mapping in the FDM admin guide.

1) Values are mapped as part of the import process.
2) Don't try to do this. You can reference the mapped values of another import field in the mappings for the field in question.

Hi James,

to accomplish #2, usually you write script in the import format to assign the new value.

E.g. in a CSV file, if column 3 is Cost Center and Columns 5 is account, and Cost centers 100, 101, and 102 put their expenses in specific accounts you might have

Function Logic_CC_Expense(strField, strRecord)
   Dim strResult
   Dim strAccount

   strResult = strField

   If(strRecord.split(",")(3) = "103") Then
      strResult = "103_" & strField
   end if

   Logic_CC_Expense = strResult
End Function

Regards,
Robb Salzmann

I would strongly discourage this approach (import scripts) and echo SH and the other's comments to use conditional mapping.

Using import scripts in this manner makes the mapping an administrator exercise since conditions like this tend to change over time. Most FDM users will not have access to the scripts (nor would you likely want them to) so the result is the admin has to maintain the "mapping" performed by the import sript.

Moreover, this approach means that any time this definition changes, the data would need to be reimported which can impact performance or data integrity if reprocessing historical data.

Tony,

How would you map something in the accounts dimension based on the entity column?

Robb

It's conditional mapping. You need to create a script in the maps themselves. Search for varvalues in the admin guide

I've found in this situation, its 6 of one, half dozen the other, since you have to script the mapping anyway. I find the objects in the import scripts easier to use and more accurately documented. So I prefer to put the logic in the import script.

Regards,
Robb Salzmann

Robb,

Clearly we are going to have a difference of opinion on this point. The reasons I am strongly against the manipulation of data on the way into FDM (i.e., an import script that changes the "source" member or performs a level of premapping) are:

1. You lose visibility to the true source data.
2. You also cannot change that logic without reimporting the data file. This is fine during a development cycle but if you have a situation where a client has a ledger that changes even during historical periods, having to process a new data extract using the revised logic, could result in the reloaded data being different than the reported results.
3. The "mapping" logic is not something that is documented in the map audit reports that you can provide to auditors to explain how ledger data became EPM data
4. Mapping scripts can be controlled by security - meaning a user can have access to one location and change its scripts but not another location. The inverse is not available for import scripts; you have all or none.

To your point about documentation, you can add comments to a map script the same as you can with import scripts. Granted, the expression field in the mapping table has a character limit but basic comments can be applied.

Hope that gives you some insight into my logic.

Tony

It does Tony, thanks! :)