9 Replies Latest reply on Sep 27, 2011 7:34 PM by Robb Salzmann

    using mapping during import

    886365
      Hi all,

      I have two questions !

      1. How can we implement a mapping rule during the import process?
      2. How to use mapped value as a source for another column ?

      Please do help !

      Thanks in advance,
      -James.
        • 1. Re: using mapping during import
          JeffJon
          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.
          • 2. Re: using mapping during import
            SH_INT
            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.
            • 3. Re: using mapping during import
              Robb Salzmann
              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
              1 person found this helpful
              • 4. Re: using mapping during import
                TonyScalese
                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.
                • 5. Re: using mapping during import
                  Robb Salzmann
                  Tony,

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

                  Robb
                  • 6. Re: using mapping during import
                    TonyScalese
                    It's conditional mapping. You need to create a script in the maps themselves. Search for varvalues in the admin guide
                    • 7. Re: using mapping during import
                      Robb Salzmann
                      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
                      • 8. Re: using mapping during import
                        TonyScalese
                        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
                        1 person found this helpful
                        • 9. Re: using mapping during import
                          Robb Salzmann
                          It does Tony, thanks! :)