How to handle 2 semanticaly different characters with same master-data?

[marco_simon2]

Hi specialists,

I've got a little moddeling problem - here's the szenario:

I've got a cube with a dimension "Customer".

This dimension shall have the following characteristics

- CustomerNumber (0Customer),

- Region_Cust (0Region (or reference of 0Region))

- Country_Cust (0Country (or reference of 0Country))

- Region_ShippedTo (ZRegion (=Reference of 0Region))

- Country_ShippedTo (ZRegion (=Reference of 0Region))

(The mentioned Info-Objects are just a proposal)

The regions need to be in the cube (for historical correctness) - (Display-)Attributes won't help.

The hatch: 0Region has a compound with 0Country. There seems to be no way to tell Region_ShippedTo to use ZRegion for the compound.

Let's say a customer has it's headquarter in Germany(Region: Berlin) - while the product is shipped to the brance in France(Region: Ile-de-France). Imho this is currently not modellable.

So how can one implement that (not that artificial) szenario without beeing forced to dublicate and keep synchronized the 0Country-InfoObject and all of its master-data? Master-Data should imho follow the idea of beeing centralized - it should be useable for the customer country/region as well as for the shipped-to country/region.

Could you please gimme a hint how to solute that problem?

[Former Member]

Hi,

The requirement is not so clear to me .But i would think this way :

Is it possible to define 0COUNTRY as Master data object with 0REGION as well ZREGION as its attributes?

If so,this must give a way to solving your problem

Sriman

[marco_simon2]

The regions need to be in the cube (for historical correctness) - (Display-)Attributes won't help.

The hatch is (for keeping the szenario):

I need to know where I shipped-to 2 years ago.

Let's say the branch in Germany moved on 1.1.2007 from Hamburg to Berlin.

If I pick the region-information from the master-data (as you suggested) then every report - even for shippments in 12.2006 - would show me "Berlin" (because on 1.1.2007 somebody updated the master-data - which was of couse correct!). But it's important (for my case) that the shippment was to Hamburg - therefor I need to store the Region as addional characeristic in the cube.

This is what I meant by "historical correctness".

[Former Member]

Ok!! in that case you can define this as Time dependant navigational attribute to 0COUNTRY itself

Here you can mention HAMBURG prior to 1.1.2007 & and later as BERLIN.

as its navigational,you can very well use it in reports also.

Sriman

[Former Member]

I see - you're absolutely right! - Thanks!

Unfortunately the time-dependance is just the half job.

I fear I've to modify my szenario for making my problem clear:

Customer (with region_customer and country_customer) orders a product which might need to be shipped to a different region/county for every new order. (Simple example: Customer often orders flowers at flowershop.net - which need to be shipped to an always different ship-to region/country ).

In that case I certainly can't store the ship-to region/country in the customer's master-data, can I?

But I need them for futher analyze. In this case I need to add them to the cube - and it needs to be navigation-enabled. (region_shippedTo, country_shipedTo)

Now I want to report all customers from France together with all regions where the product was shipped-to.

Is that possible? Can I set a filter for country_customer (=0Country) without filtering the shipped-to regions (which are references of 0Region, which has a compound-key with 0Country) at the same moment? Will the report still show me the flowers shipped to Berlin?

Hope I could clearify my question a bit!?

[Former Member]

Set these up as attributes of 0customer, time dependent if necessary, nav attirbutes of your infocube.

0country - customer country

0region - customer region

Set these up for shipped to region. These will be characteristics of your infocube.

zcountry - reference to 0country

zregion - reference to 0region, use zcountry for compounding

[Former Member]

Hi,

In this case,If you define them as compounding attributes,you no need to worry about master data.

ex: CAR ID & Colour: Same CAR can be in different colors and we can differentiate this in Transaction data by defining Color as compounding Attribute of CAR ID

Similar is your requirement.

you can define the ZCOUNTRY & ZREGION as compunding attributes to 0CUSTOMER.

Hope it hepls

Sriman

[marco_simon2]

Thanks to both of you!

In the meanwhile I managed to test-out the recommended moddeling an it works as predicted.

This moddeling seems to work fine as long as I only need a maximum of one characteristics (in my case) referencing 0Region. (~having a compound-key with the same characteristic).

In how far does it change the situation, when I need more than one?

Let's say I've got "Test-Customers" (CPD) very often, which make a first sample-order to test the product. In that case I don't want to add them as "full" customers at once (the overhead for data-housekeeping would often be bigger than it's worth).

Instead I want to use a "dummy" customer for those "order-once-and-never-seen-again" customers.

But I need to keep their address (e.g. country and region) anyway! So I only can keep them as transactional data in the cube.

But now - I've got 2 InfoObjects which reference to 0Region. The CPD's region/country and the ship-to region/country.

Can they still be filtered and navigated independently?!

If no - what's the workaround?

[Former Member]

Hi Marco,

As I mentioned previously,Define Compounding attributes(ZREGION & ZCOUNTRY) on 0CUSTOMER.

as 0CUSTOMER is the point of concern here,this solution works well in both ways

Sriman