Skip to Content

Continued in querying on an Infoset return multiple of the actual key figure value Part2

Case II

Let’s consider a more generic scenario.

 

Infoprovider A – Sales Order DSO/Cube / Purchase Order DSO/Cube

 

Infoprovider A

Sales Org

Sales order num

Item

Material

Ordered Qty

S01

10000001

10

Mat1

3

S02

10000001

20

Mat1

4

 

Infoprovider B – Delivery DSO/Cube / Goods receipt DSO/Cube

 

Infoprovider B

Delivery num

Delivery item

Ref Order Ref Item

Delivered Qty

5000001

10

10000001

10

1

5000002

10

10000001

10

1

5000003

10

10000001

10

1

5000004

10

10000001

20

1

5000005

10

10000001

20

2

5000006

10

10000001

20

1

 

Infoset for determining backlog, service level or vendor delivery performance.

 

Infoset

Sales org

Sales order num

Item

Reference char

Delivery num

Delivery item

Ordered Qty

Delivered Qty

S01

10000001

10

1000000110

5000001

10

3

1

S01

10000001

10

1000000110

5000002

10

3

1

S01

10000001

10

1000000110

5000003

10

3

1

 

Total

9

3

S01

10000001

20

1000000120

5000004

10

4

1

S01

10000001

20

1000000120

5000005

10

4

2

S01

10000001

20

1000000120

5000006

10

4

1

 

Total

12

4

 

 

The conventional approach of exception aggregation with a single reference characteristic does not work here, since the reference order and reference item values in infoprovider B together define the reference by which the key figures in infoprovider A must be averaged.

 

In the above example if only reference order/sales order is considered as a reference characteristic, then the key figure ordered quantity would have the incorrect values of 1.5 and 2 (i.e. 9/6 and 12/6 respectively).

 

To solution this, we can create a reference characteristic which is the concatenation of the order and item and use it to exception aggregate our key figures from infoprovider A.

Adjoin the reference characteristic as well, in the infoset and use it in the query for exception aggregation.  

Modelling the reference characteristic.

 

The requirement from this infoobject (Refobj say) is:-

1.      It should be a perfect fit with other components of the infoset.

2.      It should provide the reference characteristic for aggregation.

 

1. It should be a perfect fit with other components of the infoset –

 

For joining the infoobject (Refobj) with an existing infoprovider in the infoset, we will try to have the key of the infoobject = key of the infoprovider containing the reference characteristic [i.e. try to create 1:1 cardinality for this join]

 

For DSO as an infoprovider in the infoset:-

The key of the master data table of the infoobject (Refobj) should be exactly equal to the key of the DSO in the infoset which contains our reference characteristics.

 

For Cube as an infoprovider in the infoset:-

The key of the master data table of the infoobject should be exactly equal to the characteristics of the cube that have been switched on in the infoset.

 

 (Limitation – The key of the infoobject cannot be more than 60 char. If the key required is more than 60 characters, then one may have to remodel the original cube or DSO to have the reference characteristic embedded in the model of the infoprovider)

 

Example:-

 

In Case I above, demand planning area and material (highlighted in blue) are the key of the infoprovider A, furnishing the reference characteristic and hence they would form the key of the infoobject. [Reference char – Demand planning area and Material]

 

In Case II above, key of infoprovider A / infoprovider B could be used to form the key of the infoobject, since our reference characteristic is included in both the infoproviders.

[Reference char – Reference/Sales order and reference item]

 To form such a key in the master data table of the infoobject, compounding would be used.  

2. It should provide the reference characteristic for exception aggregation.

 

The reference characteristic (Refchar) for aggregation, would be an attribute of this infoobject (Refobj).

Refchar would be filled by the concatenation of the fields that would form the reference fields in the infoprovider. (Limitation 60 char)

 

Example:-

 

In Case I above, demand planning area and material would be concatenated to form the reference characteristic.

 

In Case II above, reference order and reference item would be concatenated and loaded as attributes characteristic value.

 

The master data of this infoobject would be created from transaction data.

The transaction data of the infoprovider which contains the reference characteristic would be used to create the master data of our infoobject.

An export data source is created over the infoprovider containing the reference characteristics which will mart the data to the infoobject.

A delta would be setup to load the master data of the infoobject after the transaction data load.

The attribute would be created as a display attribute, which would mean there would be auto activation after data load and no attribute/change run would be required.  

 

Continued in querying on an Infoset return multiple of the actual key figure value Part3

Infoset Keyfigure multiplicity Part 3

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply