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
