What is the exact version of Hyperion(including patch level) are you on?
Did you refresh the members from the target applications screen?
In your load rule did you specify the exact plan type you looking to load to?
I am on 126.96.36.199 with .001 FDMEE patch.
Yes. I did refresh metadata from target application screen.
Yes. I selected PL as the plan type I want to load data.
For 188.8.131.52 the latest patch is 184.108.40.206.100 so you may want ensure you get that applied at some point.
In your screenshot above it appears you are ignoring the account dimension hence nothing will load.
Also you should narrow down your test to a file that just has one single record that only has members that are explicitly mapped and actually existing in the target Plan type.
You may also want to delete your data load rule and create a fresh one and ensure that you point directly to the PL Plan type.
Tested on 220.127.116.11.100 and Hyperion Planning 18.104.22.168.004 and loaded to an application with multiple plan types fine.
The below document may also be of help
FDMEE Loading Data To Different Planning Plan Types Does Not Work (Doc ID 1934447.1)
Sorry. I am on the latest FDMEE patch .100.
I am ignoring all accounts except those that start with 0.
I have tested this before. I am able to load data if I delete the "UDx" data table column name in Target application screen. But my point is, if I want to load data to both PL and Capex, I need to have multiple dimensions selected including Asset Class.
Not sure what "UDx"(belief is you reference to Asset Class) is and why you would need to delete.
You should have all the dimension identified in the target application screen(ensure you refresh metadata as per the Oracle document).
If at some point in the future you wish to load to the other Plan types yes you would need to have the mapping adequately updated for such dimensions. Since you are not loading them they do not need to be mapped.
When you create your data load rule you are able to specify the plan type and that drives the dimension FDMEE validates.
You may want to delete the data load rule(you may even want to create a new location) and also you should narrow down your test to a file that just has one single record that only has members that are explicitly mapped and actually existing in the target Plan type.
As mentioned tested on 22.214.171.124.100 and Hyperion 126.96.36.199.004 on an application which has multiple plan types and have been able to load fine so the issues is specific to your setup.
Ok. I will try to delete the data load rule and location and see if that works.
By UDx, I was referring to Asset Class mapped to UD2, Asset Detail mapped to UD3 in the TDATASEG table.
In my earlier testing, I have removed these UD2, UD3, etc for the dimensions that are not associated with PL. That way I was able to load data.
In your testing on multiple plan types, did you have all the dimensions for all the plan types associated with a UD1, UD2, etc fields? And did you have mappings defined for the dimensions that are not associated with the plan type you are loading data to?
This is the screenshot of a working Target application screen. I have deleted UD2 and UD3 against Asset Class and Asset Detail dimensions.
Not sure why you have SmartList as the [Target dimension class]. You would generally use [Generic] for dimension data that is truly defined in the source file.
In the test case yes all dimension were identified in Target application section and had an applicable UD. Also the dimension not associated with the Plan types which was being loaded did not have any mappings defined.
As mentioned it is much faster to troubleshoot with a single record file with dimension members that are explicitly mapped and exist in the target plan type.
1 person found this helpful
This sort of error can be pretty frustrating as often it is not related to a mapping in the dimension shown in the Validation Errors screen. FDMEE will just default to showing a mapping error for the first dimension not related to the plan type you are loading. The mapping error could be in any other dimension even ones that are valid for the plan type but it will always be down to the fact that there is no mapping defined for the criteria. I would double check you have valid mappings for all dimensions i.e. none are set to be data load rule specific and would use a wildcard map * to * for all dimensions not related to the plan type you are loading and associate those with the specific data load rule if required.
I would also follow USER1211 advice and debug by loadiing a file with only one complete line of data.
1 person found this helpful
I am loading data to an EPMA application. And those with the dimension class "Smartlist" are smartlists in the application.
I tested with only 1 record and was able to find the problem. I have spaces in my source file. I have defined <BLANK> mapping to map the space to a member in the target application. For some reason this mapping doesn't seem to work for any field. If I replace the spaces with some member in the source file, I am able to load data.
Account, State, Department,Operating Unit, Scenario, Product, Project, Period, Year, Amount
"052000"," ","2126","533","ACTUALS"," "," ","2","2016","4"
Yes. That error was frustrating. It took me a while to debug. I have identified the problem as explained above. For some reason <BLANK> mapping doesn't seem to work as stated above.
Glad you were able to get to the bottom of the issue. That is the beauty of narrowing down to one record with explicit mappings as it allows you to get more quickly to the root issue in the process.
Secondly <Blank> does not refer to NULL value. Francisco A did a great explanation in the discussion [ FDMEE Mapping <Blank> Not Working / Jython Script ]
Hopefully the information from the community has been helpful to you in addressing your item.
Remember to mark the thread as answered so members of community can focus on unanswered questions.