Inconsistent business unit (lowest granularity of geographical pointer)

The changes on the business unit will result in data issue both for master data and transactional data. This also impact authorization for user's access who refer to business unit in the centralized authorization DSO. From my understanding,there are a couple of scenario:

1) wrong business unit -> correct business unit (happen when there is alignment required especially for Marketing and Finance business unit hierarchy)
2) old business unit -> new business unit (happen when there is a change in business process. Eg. for endmarket level when China include HK& Macau)
3) obsolete business unit (happen when there is a change in business process)


Scenario (1) Needed for all reports and remapping/reload required. Master data ZG_BUSUNT (infoobject for business unit) should be populated to the correct business unit. ZG_LOC (infoobject for location - used in APO)should point to correct default business unit.Both transactional and master data should be in sycn in global and regional.

Eg:1338_Summerset to 1338_Sommerset

Transactional data (APO Demand Planning)

A mix of entries for both wrong and correct business unit which does not make sense.For planning year period 201401 forecast version 201103 , the data is planned under 1338_Summerset but it was planned under 1338_Sommerset for 201102.

If the report need to reflect the correct business unit, then there may be a need to perform a self-transformation (to map to correct mapping or with some logic included) in the dso level to offset the records that mapped to the wrong business unit and reload the impacted data with correct business unit. The new set of data will be reflected in the cube level as after image. This can potentially be a repeatable action on regional level depending on as and when there is inconsistent issues in business unit esp between APO,Marketing and Finance. A full reload on the impacted generated datasource is required at Global level.


Scenario (2) The end users have to decide whether they require the new business unit view to reflect historical data or not.

This is a challenge to get the same consistent data across region to global as well as an agreed way of viewing the APO report whether to view total volume only by the new business unit or to cater the historical snapshot view (view by both old and new business unit).

Finance reports may need to reflect data that require both old and new business unit mapping and it is important the derivation of business unit in mapping table is correct and in sync with the business unit master data. There is potential issues for some Finance reports that have SPLY (Same Period Last Year). Eg. business unit A01 exist on hierarchy version A but when it became obsolete or replaced by new business unit A02, hierarchy version B is created. When user view SPLY on current hierarchy version (version B), they won't have the comparison figure for A01.


Scenario (3) The business unit will appear on the hierarchy version it ties to (In other solutions, this can also be controlled by time dependent master data and hierarchy). The master data should remain intact and should not be blanked out.