Hello all,
I am trying to load data from a csv flatfile into an existing cube via a TI process. The problem is, that the source file contains different account names than my dimension in TM1. Because this file is generated and has a lot of data in it, it is also not possible to change that manually.
Source File:
Account1, 2012, JAN, 100
Account2, 2012, JAN, 200
The element name of "Account1" is "Acc1" in my TM1 dimension.
Can anybody tell me, what is the best solution to get the data into the system?
Is there any trick/any function I can use to tell Turbo Integrator to write the data from Account1 to Acc1? (e.g. if variable Account = "Account1" then cellputN (value, 'Acc1', vYear, vMonth,))
Is it necessary to create a mapping cube, and if yes, could you explain the basic principles of a mapping cube?
Thanks in Advance
Kind regards
Mapping Data from Source File to Elements in Dimensions
-
- Posts: 7
- Joined: Mon Mar 07, 2011 10:25 pm
- OLAP Product: TM1
- Version: 9.5
- Excel Version: 2007
- qml
- MVP
- Posts: 1098
- Joined: Mon Feb 01, 2010 1:01 pm
- OLAP Product: TM1 / Planning Analytics
- Version: 2.0.9 and all previous
- Excel Version: 2007 - 2016
- Location: London, UK, Europe
Re: Mapping Data from Source File to Elements in Dimensions
The easiest way would be to create an alias of the Account dimension with the names as they come in the csv. That way your TI would require no changes.
My second preferred approach would be to create a mapping dimension with a text attribute, where the elements are source account codes and attribute values are the account names like you have them in the system. Then in your TI you just need to pick up the mapping for each code using AttrS().
My second preferred approach would be to create a mapping dimension with a text attribute, where the elements are source account codes and attribute values are the account names like you have them in the system. Then in your TI you just need to pick up the mapping for each code using AttrS().
Kamil Arendt
-
- MVP
- Posts: 600
- Joined: Wed Aug 17, 2011 1:19 pm
- OLAP Product: TM1
- Version: 9.5.2 10.1 10.2
- Excel Version: 2003 2007
- Location: York, UK
Re: Mapping Data from Source File to Elements in Dimensions
Hi Stephan,
Is it a guaranteed one to one mapping of source account to target account or is it possible, now or in the future, that more than one source account might map to a single target account? If the latter then you have to use the second method - and you also have to worry about accumulating the values in the import.
Cheers,
Duncan.
Is it a guaranteed one to one mapping of source account to target account or is it possible, now or in the future, that more than one source account might map to a single target account? If the latter then you have to use the second method - and you also have to worry about accumulating the values in the import.
Cheers,
Duncan.
-
- Posts: 7
- Joined: Mon Mar 07, 2011 10:25 pm
- OLAP Product: TM1
- Version: 9.5
- Excel Version: 2007
Re: Mapping Data from Source File to Elements in Dimensions
Thanks all for the replies!
I did not know that it is possible to load data when there are alias names in the csv file instead of the element names. I think that would be the easiest way to do it. I will give it a shot.
According to the customer it is a guaranteed one to one mapping, so the first option would be the best at the moment.
I did not know that it is possible to load data when there are alias names in the csv file instead of the element names. I think that would be the easiest way to do it. I will give it a shot.
According to the customer it is a guaranteed one to one mapping, so the first option would be the best at the moment.
-
- MVP
- Posts: 2836
- Joined: Tue Feb 16, 2010 2:39 pm
- OLAP Product: TM1, Palo
- Version: Beginning of time thru 10.2
- Excel Version: 2003-2007-2010-2013
- Location: Atlanta, GA
- Contact:
Re: Mapping Data from Source File to Elements in Dimensions
This is my preferred approach whenever I have a situation where the metadata from the source, like a datamart, is going to be different than the actual element names the customer wants to see in TM1. Documentation is key here because it can be real confusing for people that come in behind you trying to support this thing and you've got non-matching metadata between a datamart and TM1.