SAP Business Objects Planning and Consolidation version for Netweaver effectively leverages the Netweaver infrastructure and we can use the Business Add-In functionality (http://help.sap.com/saphelp_nw04/helpdata/en/e6/d54d3c596f0b26e10000000a11402f/content.htm). In this blog we will try to explore the features of write-back badi and discuss when we can use it to our advantage in the implementation projects.
You are in the best position to use the write back badi if you are on SAP Business Objects Planning and Consolidation 7.5 version for Netweaver. At present, the latest support pack for 7.5NW is SP4 but even if you are on an earlier SP level, you can still use the write-back badi. If you are on BPC7.0NW though, you should be at least on SP4 or higher to take advantage of the write-back badi.
One may ask, is it mandatory for us to use a write-back badi to write any records using BPC? The answer is ‘no'. It is not mandatory for us to use write-back badi if we don't want to. Even without a write back badi, several BPC customers have been entering data through input schedules, data manager packages, comments etc. Write-back badi is generally of use when we want to write-back records in a fashion not supported by the regular write back operations.
For example, let us consider a simple case of budgeting by cost centers. Let us consider that our Entity type dimension is Cost_Center and it has a hierarchical structure with Worldwide as the top node, followed by Europe, Asia and North America as lower level nodes. Under each of these nodes, let us assume that we have individual countries. So North America may have USA, Canada and Mexico; whereas Europe may have UK, Germany, France and Asia may have Singapore, India, China etc. Hence, in this dimension, the individual countries are the lowest level nodes and typically we can do planning ONLY at the lowest level nodes. So in a normal situation, we can plan at the level of India, USA, Canada, Germany etc but we may not be able to plan at the level of Europe, North America, and Asia. This is good if we want to do bottom-up planning. If we have to do top-down planning where it may become important to enter the data at the higher level nodes, then the normal write back operation may not allow us to do so. In such cases, write-back badi can be effectively used. With the write-back badi we can enter the plan data at a higher level node and the data will get stored at the base level dimension members by means of the disaggregation mechanism defined in the write-back badi. The disaggregation mechanism can be defined in the badi implementation. This may include different types of distributions, including even distribution, based on a percentage value which is maintained in a property, or distribution based on previous year's data, etc. Some type of ABAP program could also be developed to allow maintenance of such distribution rules for parent level entries per Appset/Application/Parent Member.
Another example where write back badi may become necessary is where we have matrix security and the data entry has to be secured based on the matrix security. Let us take an example to clarify this scenario.
Let us consider that a member access profile (say MAP1) is set up as follows:
Category = Plan - Read/Write
Time = 2009.OCT - Read/write
Time = [ALL] - Read only
The idea here is that the user should be able to read the plan values for all time periods but write to only 2009. OCT month plan values.
Now consider that there is another member access profile (say MAP2) that is set up as follows:
Category = Forecast - Read/Write
Time = [ALL] - Read/Write
The idea here is that the user should be able to write forecast values to all periods.
Now, if these profiles are assigned to two different users there is no issue. However if they are assigned to the same user, then there is a conflict. Clearly, the administrator of the security intends to RESTRICT writing of values to Plan category for time other than 2009.OCT. However what happens is that if the user who has both these member access profiles assigned, enters a Plan value for say 2009.SEP, it gets saved according to the rule of least restrictions by dimension - in this case the time dimension. This is not what the administrator might have intended.
In this case also the write-back badi can come to our rescue. With the write-back badi we can very effectively handle the situations like this.
The write back badi is a ‘pre-process' badi. This means that it is called before any other checks are processed. Since the write-back badi is called before the standard security checks, validation checks, work status checks etc, it can accomplish the tasks that are generally not possible with the standard write-back operations. The Enhancement Spot for the write-back badi is ‘UJR_WRITE_BACK' and it includes filters for AppSet ID, Application ID, and Module ID.
Appset and Application IDs are self explanatory. The module can be either Manual planning, journals, data manager, comments or document modifications. This enables us to use a PRE-PROCESS method where the logic for pre-processing for the write back can be written. BAdI Implementation UJR_BADI_SAMPLE_DISAGGREGATE is shipped as an sample implementation for disaggregation.
There is also a how-to guide available for the step-by-step instruction for the write-back badi implementation for disaggregation. (http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0309226-814f-2d10-61a6-ef8da29e3727?QuickLink=index&overridelayout=true)
Thus write-back badi can b
e a very useful utility for us to leverage on out BPC NW implementation projectsSAP BPC Tutorials | SAP BPC Training | SAP BPC Interview Questions |SAP BPC Books
No comments:
Post a Comment