Business Planning and Consolidation version for Netweaver has some features that work differently than those in Microsoft version. BPC Validations is one of them. In this blog we will discuss how these validations can be of tremendous help to us in maintaining data integrity.
The purpose of having validations, as you might have guessed, is to prevent invalid or wrong records to be saved to the cube. Now this statement can raise many questions. Invalid according to whom? What is invalid for one BPC Application may be valid for some other Application. Something may be invalid if it is entered manually but the same thing may be valid if loaded from a Data Manager package. How is this different than having a script logic function to check and clear the ‘invalid’ records? The list can go on. Let us try to understand this functionality and answer some these questions here.
First of all, validations in BPC7NW stops invalid records from being written to the database. This is different than having any script logic function to correct or clear the invalid records because in order to clear or correct the invalid records, those invalid records should first be available in the cube. A BPC validation nips such invalid records in the bud rather than correct them later on – it simply prevents such records from being saved.
Who determines whether a record is valid or invalid? The user controls what is valid and what is invalid. The ‘user’ is used here in a broader sense – the ‘user’ as against any predefined functions – or you can say the customer in general.
So the next logical question is how do you create such validations? Well, for doing that, for now, we have to go to SAP GUI as against BPC front end. In SAP GUI, the transaction to maintain validations is UJ_VALIDATION.
To begin with setting up of validations, we need to define a driver dimension. One application can have only one driver dimension but several applications in the same application set can have the same driver dimension, if we so desire. It is not mandatory to define the driver dimension to each and every application if we want to set up validations for only a few applications. As shown below, we can choose what should be our driver dimension for applications in our application set.
The next step is to set up validation rules. The validation rules are by dimension. So we have to first choose the dimension for which we are going to set up the rule as shown below.
We can set up several rules for each dimension and we can assign the dimension members for each rule. Each rule can include more dimensions and dimension members. The following screenshot shows an example of a rule for dimension P_ACCT. This rule is valid for members within the range CE0004000 to CE0005000 and it states that the category dimension can not have value ‘FORECAST’.
We should note a few points here. Firstly the assigned members are from CE0004000 to CE0005000 – so do we have to have members CE0004000 and CE0005000 as valid members for the dimension P_ACCT? The answer is NO. We need not have these members as defined in the dimension members of this dimension and still can use them here. This works as wildcards. If we define the rule as above, then it will be valid for all the valid members within this range. So the members like CE0004510, CE0004520 etc will obey this rule but members such as CE0005010, CE0003990 etc will not be bound by this rule. So this opens up a possibility for us to define a wide range as 000000000 to ZZZZZZZ etc so that all possible members will be considered in that range. For those who have worked with traditional SAP R/3 or SAP BW, may be familiar with defining wide ranges like that. An example is shown below.
Now if you do that, you will get a warning similar to one shown below to caution you but you can continue through this.
Secondly, though we can have ranges in the assigned members for the dimension for which we are setting up the validations, we can’t have ranges in the additional dimensions that we choose in the rule. So going back to the example of the rule we created above for P_ACCT, we can’t define ranges for Category and the members we choose for category should be the valid members for that dimension. The operators available there are = and <>. If we choose <>, then we can define multiple values in the same line.
Thirdly, we can use multiple dimensions in one rule as shown below.
Fourthly, when we choose the assigned members while creating the rule, please note that one member can be assigned to multiple rules and one rule can apply to multiple members. In other words, there is N: N relationship between dimension members and validation rules. If a dimension member is governed by rule 1, rule 3 and rule6, then in order for a record with that member to be valid, all the three rules must be satisfied.
Finally, please note that when we are defining the rules, we are defining them for the dimensions and dimension members but nowhere we are talking about the application while maintaining the rule. So what does that mean? This means that the rules that we define here are applicable to all the applications where the dimension for which we are creating the rules is their driver dimension. So in the example above, the rules that we created for P_ACCT will be applicable for all applications in that appset where P_ACCT is the driver dimension. This also can be a consideration while assigning the same driver dimension to multiple applications since all the rules for that dimension will then be applicable to all those multiple applications.
If the rules that we want to define are complex and can’t be configured simply with = and <>, then we can implement those rules as BADI and in the rule maintenance, we can select the badi implementation as shown below.
Thus far we have seen the way to create validation rules. The next question is that once we define these rules, do we have to use them everywhere or do we have any choices there? At present, we have the following three choices.
So we can turn the validations on or off by application for journals, manual planning or data manager and thus control the applicability of the validation rules only for the intended functionality. The ‘data manager’ switch includes script logic and consolidation rules.
Thesevalidations will prevent invalid records from being saved. For example, if we define the validation rule and switch it on for manual planning, and if an invalid record is entered, we will get an error message as shown below.
We can copy or delete these validation rules as part of rule maintenance. We can also copy the validations from one appset to another if necessary. The authorizations for maintaining the validation rules are governed by the standard SAP authorization for the transaction to maintain these validations. What will happen if the dimension, which we choose as the driver dimension for validation rules, gets deleted from appset? In that case all the validation rules for that dimension will also get deleted. If we delete appset itself, obviously all the validations for that appset will also be deleted.
Thus, we have this new gatekeeper for helping us to maintain data integrity in the Netweaver version of BPC. Let us make maximum use of this to safeguard us against the attack of invalid data.