Feeder calculation for unmatched dimension between cube

[ram123]

HI TM1 Team,

I am facing an issue to saving a feeder in Cognos tm1. My requirement is feeding data from one cube to another by using Rule. Source cube is having 3 dimension like month, currency and measure dimension and target cube is having 5 dimensions like Region, month, customer, product and measure.
Region dimension contain around 150 elements with 4 level of hierarchy.
Product dimension contain around 120 elements with no hierarchy.
Customer dimension contain around 600 elements with no hierarchy.
Month dimension contain around 13 elements with 1 level of hierarchy.
Currency is data in my Target cube.
Find the below Rule and Feeders I wrote for this Requirement
Rule: is in target
[Measure]=N:DB(‘Source Cube’,! Month,DB(‘Target Cube’,………,’Currency’),’Measure’);

Feeders: is in source
[Measure]=>DB(‘Target Cube’,’All Region’,! Month, ‘Total Product’,’Total Customer’,’Measure’);
Here Total element is consolidating element.
While saving Feeder it’s taking too much time. And Feeder file size is also increasing.
Please let me know is there any other way to write Rule or Feeders for such kind of requirement. Because in same application I have 4 more cube to load data into target with unmatched dimension. Due to this reason my application is getting stuck.
Thanks in advance………….

[declanr]

It would help if you could provide more detail on what measures you have etc

If you have a "volume sold" measure in your destination cube that is populated then its probably safe to assume that other measures such as "Net Sales Value" would only be relevant when there is a volume and as such you could do all the feeding within the "destination cube."

[ram123]

It would help if you could provide more detail on what measures you have etc

If you have a "volume sold" measure in your destination cube that is populated then its probably safe to assume that other measures such as "Net Sales Value" would only be relevant when there is a volume and as such you could do all the feeding within the "destination cube."

Measure Dimneion of target cube is containing around 20 element. here i am loading data for exchange rate to excahge rate in source.
source cube measure dimension Containg only exchage rate as a element.

thanks for reply.

[tomok]

here i am loading data for exchange rate to excahge rate in source.

Why in the world would you copy the exchange rate from one cube to another, when the end result is to load the same exchange rate for every region, product, and customer? That is extremely redundant. For foreign exchange calcs you should never do this in your scenario. Just reference the appropriate exchange rate from the source cube when writing the rule to calc the difference currencies. As declanr suggested, you must have a currency amount in the target cube already. Just use that to feed the exchange rate if you must. I also should add that you don't have to feed the exchange rate, regardless of which option you choose. Not feeding will only effect whether or nor the rate shows when you zero suppress a view off the target cube. The exchange calc will still happen regardless of whether or not the exchange rate cell is fed.

[mvaspal]

I agree with tomok: even if you really want to pull rates to your target cube, you do not really need to feed them. Rates should not be aggregated at all and it is very unlikely to use zero suppression in a view where there are only the rates displayed. So just simply write the rule if you really need it, and leave the feeder away. If you need rates to be displayed on C: elements too, just leave away the N: classifier.

If you feed totals for product, customer, region, it's not a wonder that saving the rule takes a long time.

[ram123]

Thanks ,

My exchange rate cube ( which has 3 dimensions( Currency,Month,Measure) and which is loaded from ODBC) is feeding a Cost cube which has 6 different dimensions.

So when i am writing a feeder from exchange rate to cost cube i have to write feeder at consolidated level on the dimensions which are not present in my Exchange rate cube. when i am saving the feeder it is taking ages to save and memory for the application is also increasing.

Please suggest. ( changing the design is not an option)

[Duncan P]

Could you explain why it is not possible to feed only from the cost amounts that are multiplied by the exchange rate? If the cost amount in local currency is zero then the converted amount is going to be zero as well.

If in spite of all this you still find it necessary to feed from the exchange rate then a way round save time problem is here. However I really think you should discuss this further before using this technique.

[ram123]

Thanks for reply...

There is requierment that we need data at consolidate levle. Is there any way to write Feeders in source Cube.

[lotsaram]

Thanks for reply...

There is requierment that we need data at consolidate levle. Is there any way to write Feeders in source Cube.

I think you could be confusing here the requirement to consolidate the result of the calculation using the exchange rates. You certainly wouldn't ever need to consolidate the exchange rates themselves because as others have already said the result is meaningless.

Consolidating the translated values is a normal requirement but you would never do this from the exchange rate cube.

[David Usherwood]

Could I state this all rather more simply?
Rates.Don't.Need.Feeding

[rmackenzie]

The situation overlooked by the answers so far is where the UI of the cube only allows a single cube-view and requires the forex rates in the drilldown for reporting purposes. E.g. I have accounts on rows and 3 measures on columns - local currency, reporting currency, forex rate; as I drill-down the accounts I still need to see the forex rate. In Excel, perhaps we'd solve this by having data from two cube views in an active form, but in clients limited to a single cube-view then perhaps the OPs design comes into play. If the rate is being pulled into the reporting cube then just feeding that calc from local currency would seem to be an option worth exploring.