Unit Conversion: Notes on Modeling
When you choose a planning function of type unit conversion you are, to a large extent, free regarding the type and number of characteristics and key figures that you want to include in unit conversion. Some special features can occur here in relation to the SAP BW data model that we will explain in this section.
The SAP BW data model manages unit fields such as characteristics. As a result these fields are part of the logical key of a data record. The keys of units for one or several key figures are in the unit fields. As a result, you determine a part of the semantics and the formatting attributes (decimal places) for these key figures. Therefore there may be transaction data records that only differ in the unit fields.
The key figures can then, for example, be interpreted as the value in the local unit of measurement of a subsidiary in one case, and in the other case, as values in the valid unit standardized for the group.
You can derive which unit is used in particular cases from characteristics such as company, company code or material. A unit key is assigned to these characteristics as an attribute.
Scenario
In group-wide planning scenarios, plan data is mostly entered in different currencies for subsidiaries. However, decentralized it is planned in the local unit. This regional data is transferred to the group headquarters, converted into the group unit and revised there.
It is often not sufficient when the central partner only works with plan data in the group unit. On the contrary, as a rule access to the output value in the local unit must be possible, so that the decentralized planner can respond to queries quickly and simply. For the following observations it is also assumed that the central planner must also still plan an amount in addition to the key figures for quantities.
Solution Approaches
We present two different approaches below in order to model the planning scenario described with BW-BPS: As an example the quantities of a liquid are used which are entered at company level in canisters and at group level in pallets. It is based on the assumption that 100 canisters fit into 1 pallet. The approaches differ as follows:
§ ...
a. Only one key figure is used for quantities (quantitiy). If required it is converted into group unit.
b. Two key figures (company amount, group amount) and two different characteristics (company currency, group currency) are used for the currency key.
The following tables show the transaction data records: There are two data records in each case. The second result data record results from a unit conversion from the first record.
Case a)
Company |
Group currency |
Company |
Amount |
Quantity |
913 |
USD |
Canister |
50 |
6000 |
913 |
USD |
Pallet |
|
60 |
Case b)
Company |
Company |
Group |
Group |
Group currency |
Amount |
Quantity |
Quantity |
913 |
Canister |
|
|
USD |
50 |
|
6000 |
913 |
Canister |
|
Pallet |
USD |
|
60 |
|
The following stands out in the results records:
· In both cases the unit of measurement field is filled, although the quantity is 0 in the results record.
· In case b) the group field is not filled. Here two data records are also formed by the unit conversion although there would actually be space in the first data record to include the new calculated (group) quantity.
Working with two different data records is unfavorable on one hand because it affects performance and on the other because a new unit conversion can change the result.
The following tables show this with the data records in case a) after a second execution of the unit conversion:
Case a) Data records before a new unit conversion
Company |
Company currency |
Unit of measurement |
Amount |
Quantity |
913 |
USD |
Canister |
50 |
6000 |
913 |
USD |
Pallet |
|
60 |
Case a) Data records after a new unit conversion
Company |
Company currency |
Unit of measurement |
Amount |
Quantity |
913 |
USD |
Canister |
50 |
6000 |
913 |
USD |
Pallet |
|
120 |
Both initial data records are converted into pallets and the result is added up: 6000 canisters = 60 pallets + 60 pallets = 120 pallets. It follows from this that in the case a) the target data must be consistently deleted before unit conversion.
You can avoid the occurrence of two data records in case b) by defining characteristic relationships. If the first data record is entered, the system automatically adds the values for the group and group unit fields to the characteristic relationship defined.
The following table shows the data record before and after unit conversion:
Case b) Data record before unit conversion with characteristic relationship
Company |
Company |
Group |
Group |
Group currency |
Amount |
Quantity |
Quantity |
913 |
Canister |
9 |
Pallet |
USD |
50 |
|
6000 |
Case b) Data record after currency translation with characteristic relationship
Company |
Company |
Group |
Group |
Group currency |
Amount |
Quantity |
Quantity |
913 |
Canister |
9 |
Pallet |
USD |
50 |
60 |
6000 |
This result is already closer to the expectations since here only one transaction data record is formed. As the fields are already correctly derived you do not need to execute a delete function before a new unit conversion.
In our example, we have also planned an amount with a currency. If, in the group in a planning session, you only plan the quantity in group unit, a transaction data record is formed in which the unit field is initial. For that reason, with planning functions with fields to be changed (for example, formulas) or those which work with reference data (for example, distribute with reference data), you must make sure that objects exist in the system which have logically different keys and if necessary behave differently during the selection.
See also: