Accumulate e Lookup d-link in TM1

[taziob]

I have a big bidimensional cube, see it as a purchase orders relational table, with dimensions  "order_id" and "measures" (which contains also product_code and plant_id).

In a Plannig project I was able to accumulate d-link product and plant to another cube with dimensions product, plant and others (no order_id).

Now, with TM1, how can i do this match? As I can understand there is no way to map a measure in the source cube  to a dimension to the target cube.
Am I wrong?

Thanx in advance

[dusherwo]

It would be worth posting something more specific - but I'll stick my neck out regardless and say, yes, it can be done.
TM1 has no concept of a 'measure' dimension as relationally derived tools do for the column data. I'm guessing that you have created a dimension with string elements and put your product code and plant id in there. I don't think it's the right way - you are making a MOLAP tool behave relationally.
Post some details of your cubes and we'll suggest the way to do it.

[taziob]

Thank you, I'll try to be more specific:

Target cube dimensions are Product, Plant, Measures (where measures contain a long series of calculation to get the simulation ). In this cube you can input some values to simulate new purchase price & quantity and see the new average price with delta on budget and new stock cover index.

To make this model running I have othe cubes feeding this, like "blanket purchase orders", "stock availability", "history demand", "receipts", "budget prices".

The "blanket purchase orders"  cube, "the big bi-dimensional one" is in effect treated like a relational table and yes, you're are right, product id and plant id are strings. Now I'll try to explain why.

In this cube, blanket orders have start-date and end-date, let's say for example from jan-09 to dec-09.
Let's say also that I have a history demand period covering jan-08 -  dec-08 for the product. (history demand cube) . For certain order types (order types that have no quantity predefined, only period), the quantity is calculated taking history demand. The user can decide that not the full history period is to be taken under consideration, but only a portion, let's say jun-08 - oct-08, to be more aligned to the demand trend for future. The system recalculates new averages,  feeding the final target cube.
As you can see I have to do this for every single order line , that's why I have order_id treated as dimension.

I can achieve what I want, but with an exteremely sparse cube, in which I put also Product_ID and Plant_ID as dimension not as strings, but I don't know if this is the best way. Another consideration is the ability to drill to this cube from the target...

Hope this clears up a little bit

Tiziano

[dusherwo]

'I can achieve what I want, but with an extremely sparse cube, in which I put also Product_ID and Plant_ID as dimension not as strings, but I don't know if this is the best way. Another consideration is the ability to drill to this cube from the target...'

That's what I was going to suggest. TM1 handles sparsity well, if you get the feeders right, so don't worry about the size (just about the feeders  :) ). Ideally your 2D cube would be in relational land, but this may not be feasible.