How to … Variables Line Items of type Exitin SEM-BPS and BW-BPS
How to…
Line Items Documents in SEM-BBPS and BW-BPS
Logging the history of plan data
SEM-BPS/BW-BPS
Applicable Releases: SEM 3.1B - SEM-BPS 3.5, BW-BPS 3.5
1998 SAP America, Inc. and SAP AGTable of Contents
How to … Variables Line Items of type Exitin SEM-BPS and BW-BPS
1 Problem
2 Concept of the Solution
3 Practical Implementation
4 Result
5 Possible Problems and Solutions
6 Sample Coding
1Sample Scenarios - Description______2
1.1Simple interaction between two variables.______2
1.2Use Variables of type attribute in the WEB or in the planning folders______2
1.3Selection of an interval______2
1.4One variable restricts the selection of another variable.______2
1.5BW Query uses SEM-BPS variable for default value______2
1.6Select ‘all values’ for a variable in the WEB (to do).______2
1.7Avoid single value conversion for authorization variable (to do).______3
1.8Fill variable with possible combinations (to do).______3
2General Hints______3
3Sample Scenarios: The Step By Step Solution______4
3.1Introduction______4
3.2Basics______4
3.3Simple interaction between variables – implementation______5
3.3.1Determine Next year______5
3.3.2Reference version______10
3.3.3Global variables______10
3.4Using variables of type attribute______10
3.5Selection of an interval______11
3.6One variable restricts the selection of another variable______11
3.6.1Source code: Next year – to be deleted______11
3.6.2Source code: Attribute values______11
3.7BW Query uses SEM-BPS variable for default value______12
4Appendix (Sample ABAP Source code)______16
4.1Function module Z_VARIABLE_GET_DETAIL______16
4.2Function module Z_SIMPLE_RELATION______18
4.3Selection of an interval______20
1 Problem
In the context of the delivered standard functions, it is not possible to reconstruct the history of a plan data record after the event in SEM-BPS/BW-BPS. For example, if a sales target is planned for a business area for a certain time frame, you can no longer see when and from whom this sales target was actually entered. It is also not possible to see whether this value was planned directly, or whether the value was formed from targets, changes and corrections in the context of a long process.
However, if such proof is desired/requested in particular cases, then it can be realized by proceeding as follows.
2 Concept of the Solution
The solution described here uses the technology of characteristic derivation, which has been a part of the standard functions of SEM-BPS since the SEM release 3.1A (and BW-BPS 3.5).
The “normal” application case of characteristic derivation consists of deriving the characteristic customer group from the characteristic group, or the company code currency from the company code.
In the present case, this interface is used to make a unique identification of the current data record. Since in SEM-BPS/BW-BPS a delta posting is carried out internally, this unique identification means that the complete history of a plan figure is logged to the current characteristic combination.
You can find more details on the topic of characteristic derivation in the SEM-BPS/BW-BPS documentation under the keyword Characteristic Derivation.
3 Practical Implementation
To provide every data record with a unique identification, the InfoCube in BW used for planning must contain a suitable InfoObject or if necessary be extended by one. A characteristic of the type Char with length 32 without a check table or text table (for example, 0BBP_OBGUID) is suitable for this, which can be filled with a GUID (globally unique identifier) during characteristic derivation. Alternatively, this unique identification can also be achieved by pulling a number from a number range or similar techniques. In each case, a suitable InfoObject must be available in the InfoCube. In addition to that, other fields can also be included in the InfoCube to save additional organizational data, for example, 0UNAME (created by), 0DATE (date) and 0TIME (time).
On the side of SEM-BPS/BW-BPS, the characteristic relationships must be maintained in the planning area used as shown below.
Here the source characteristic of the derivation can be any characteristic which is contained each of the planning levels used. All characteristics which are to be filled with control data are to be entered as target characteristics. In the example above, these are 0BBP_OBGUID, 0UNAME, 0DATE and 0TIME. These target characteristics are not to be included in any of the planning levels used, since they are automatically filled by the function module for characteristic derivation (here: Z_YOUR_FUNCTION_MODULE_HERE).
As a rule, you must implement the function module for characteristic derivation (here: Z_YOUR_FUNCTION_MODULE_HERE) in accordance with the data model used. In SEM-BPS the delivered module UPY_CDI_DERIVE_EXIT can be used as a copy template (for BW-BPS please copy the coding attached to this How to). If the fields used in the example (0BBP_OBGUID, 0UNAME, 0DATE and 0TIME) are used exactly, then this module can also be used directly.
Note: Modifying this module for the purposes of adjustment can reduce the stability of the entire system! Even if no static usage is displayed, a dynamic usage cannot be ruled out!
Both of the function modules (Z_YOUR_EMPTY_PROP_MODULE_HERE and Z_YOUR_EMPTY_CHECK_MODULE_HERE) can be any function modules without functionality which implement the required interfaces for exit modules for combination check or generate valid characteristic combinations. Implementing functionality is not necessary here, since these modules are normally never called up (the target characteristics of the characteristic relationships are not contained in any planning level).
After these preparations, you can plan as normal with the existing data model.
4 Result
With the technique described above, for example the history of data
can be presented in all single steps as below:
5 Possible Problems and Solutions
Using this technique avoids different postings being aggregated to one characteristic combination and thus being grouped together in one data record. This is also absolutely necessary for a complete log.
On the other hand, this of course results in a much larger data volume than normal. Therefore, possible performance problems must be taken into account with this approach.
If necessary, this effect can be reduced or even completely avoided with a suitable organizational task.
For example, it is imaginable that not the whole planning process is logged, but only certain steps. Recurring steps such as transferring old actual data as the basis for planning and changing it with automatic planning functions (revaluate: +10%) could be documented sufficiently, for example, in the process description of the planning cycle. During such “uncritical“ steps, the characteristic derivation can be removed from the characteristic relationships of the planning area. Only when, for example, a decentralized manual change of data is executed by the person responsible, can the described functionality be activated. Instead of changing the Customizing of the characteristic relationships, you can program a mechanism to activate and deactivate the functionality described and integrate it in the function module for characteristic derivation. Unfortunately, an automatic control is not possible here, since the module only receives the current data record, but not the call up context (manual planning or name of a planning function).
Alternatively to that a second InfoCube can be used without line item display in which the plan data is transferred aggregated before “uncritical“ steps of the planning cycle.
Another way to limit the number of records is to get the time stamp only once and buffer it. Thus all records changed within the same planning session will have the same time stamp and there will only be one delta record for a given characteristic combination for each planning session.
6 Sample Coding
FUNCTION UPY_CDI_DERIVE_EXIT.
*"------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(I_AREA) TYPE UPC_Y_AREA
*" REFERENCE(ITO_CHA) TYPE UPC_YTO_CHA
*" CHANGING
*" REFERENCE(XS_CHAS) TYPE ANY
*" EXCEPTIONS
*" FAILED
*"------
FIELD-SYMBOLS: <l_chavl> TYPE ANY.
* fill ID
ASSIGN COMPONENT '0BBP_OBGUID' OF STRUCTURE xs_chas
TO <l_chavl>.
CALL FUNCTION 'GUID_CREATE'
IMPORTING
ev_guid_32 = <l_chavl>.
* fill user
ASSIGN COMPONENT '0UNAME' OF STRUCTURE xs_chas
TO <l_chavl>.
<l_chavl> = sy-uname.
* fill date
ASSIGN COMPONENT '0DATE' OF STRUCTURE xs_chas
TO <l_chavl>.
<l_chavl> = sy-datlo.
* fill time
ASSIGN COMPONENT '0TIME' OF STRUCTURE xs_chas
TO <l_chavl>.
get time field <l_chavl>.
ENDFUNCTION.Sample Scenarios - Description
Copy Documents using a Planning Function
In the SEM-BPS the user can attach documents (type MS Word, MS Powerpoint, MS Excel or Plain Text) to certain combinations of characteristic values and keyfigure values. One way to use documents is to enable the document functionality in the manual planning and to create documents that are attached to the characteristic combination (including a keyfigure) that is defined by a cell in a layout. The documents are stored in the Knowledge Warehouse and thus are accessible in the BW as well. Tas the Knowledge Warehouse offers functionality for document management (such as copying, deleting, etc.) the SEM-BPS only provides the following functionality: to create, view, or delete single documents.
As the documents hold comments about specific plan data and thus are closely related to the data customers also want to treat documents together with the data, e.g. copy documents to a new versions whenever the plan data is copied to that version. This should be done with a planning function as thus the functionality is accessible in all front ends alike and also can be combined with a copy function (for plan data) in a planning sequence.
Delete Documents using a Planning Function
In the SEM-BPS documents can only be deleted one by one. If data records are deleted the documents related to that data is not deleted. There is a number of reasons why the system behaves this way. On the other hand sonetimes the documents should be deleted together with the plan data. Again this functionality should be realized in a planning function.
General Hints
The SEM-BPS offers two different ways to display documents:
The document functionality in the Planning Framework. The functionality is accessible via a node in the lower tree and displays all documents that belong to a certain selection given by the selected package. This function displays a list of all documents that contain relevant selections for all (commentable) characteristics that are in the planning level. If a document has selections for additional characteristics (and thus being defined in a level that is implicitely contained in the planning level) it will be shown as well. Documents created or displayed with this functionality need not contain a keyfigure in the selection.
The document functionality in the Manual Planning/Web. The functionality is available for a layout if it is switsched to “document enabled” in the layout builder. Documents can be attached to plan data in cells (or columns in the Web). Only those documents will be shown that have relevant selections for exactly the commentable characteristics of the planning level and that also have a selection for a keyfigure. Documents that have additional characteristics in the selection or do not have a keyfigure in the selection will not be shown.
Example:
Characteristics in the planning level (all commentable):
0VERSION
0CUSTOMER
0COUNTRY
Keyfigure in the planning level:
0REVENUE
Selection (planning package/level)
0VERSION: 1-2
0CUSTOMER: 0001-1000
0COUNTRY: GB, DE, FR, US
Selection for Document 1:
0VERSION: 1
0CUSTOMER: 0002
0COUNTRY: GB
Keyfigure: 0REVENUE
The document can be seen in both cases
Selection for Document 2:
0VERSION: 1
0CUSTOMER: 0002
0COUNTRY: GB
0REGION: 001
Keyfigure: 0REVENUE
If the characteristic 0REGION is commentable then the document will not appear in a layout but can be seen using the document functionality in the framework. If on the oterh hand the characteristic 0REGION is NOT commentable (set the flag “document enabled” ??????? in the admin workbench) then the characteristic will be ignored and the document can be seen in both cases.
Selection for Document 2:
0VERSION: 1
0CUSTOMER: 0002
0COUNTRY: GB
The selection does not contain a keyfigure and therefore the document will not be visible in a layout but in the other document functionality.
Sample Scenarios: The Step By Step Solution
Introduction
In this paper we want to show how a copy function and a delete function for documents can be used in the SEM-BPS. From release??? on there is are shipped realizations for such functions done as a planning functions type exit. The logic how this function works and how it is to be used will be explained.
Basics
The shipped versions of the planning functions for copying and deleting documents can be found in the function group UPFX. Note that both function save the changes in the documents after excecution automatically!
The Delete Function
We start with the planning function that is deleting documents as this one is easier to understand and to handle.
In order to create this planning function go to the framework (transaction BPS0) and in an appropriate level create a planning function type Exit. Enter “UPF_DOC_DEL_INIT” as name of the init function and “UPF_DOC_DEL_EXIT” for the Exit function itself (note that the exit funtion module is empty – all the work will be done in the init function module).
As the
Determine Next year
The following steps have to be done in the delivered planning area 4PERF001 – ‘Basic technical performance’.Create the variable SOURCE of variable type characteristic.
/Chose the characteristic ‘Fiscal year’ and enter a value, e.g. 2002. Do not check the box ‘Restriction of Values Required by User’.
/Create the variable DEST of variable type characteristic.
/Chose as details as shown in the screenshot. It is important to select the replacement type User Exit.
/Navigate to transaction SE37 and create the function module Z_SIMPLE_RELATION by pressing the tools button at the right side of the function module name.
/Enter the import and export parameter as shown. This interface definition is given by SEM-BPS.
/FUNCTION Z_SIMPLE_RELATION.
*"------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(I_AREA) TYPE UPC_Y_AREA
*" VALUE(I_VARIABLE) TYPE UPC_Y_VARIABLE
*" VALUE(I_CHANM) TYPE UPC_Y_CHANM OPTIONAL
*" VALUE(ITO_CHANM) TYPE UPC_YTO_CHA
*" EXPORTING
*" REFERENCE(ETO_CHARSEL) TYPE UPC_YTO_CHARSEL
*"------
Add the Source code mentioned in the attachment 4.2 Function module Z_SIMPLE_RELATION. It contains two parts: the first one reads the value of the source variable, and the second one introduced by the comment ‘Example 1’ show how to derive the new values.
/ Attachment: Function module Z_SIMPLE_RELATION
Save and activate the function module
/Go back to SEM-BPS using the green back arrow of the SAP-Gui and save the newly created customizing.
/Test the results in the transaction BPS0: call up the set variable screen …
/Pop-up shows:
… and use F4-Help to set the source value to e.g. year 2002.
/Now set the variable DEST using the F4-Help and you will see, that it shows the value of 2003. This is the source value of 2002 incremented by one year.
/.Now we have our first working example.To learn more about the features of the exits follow the next steps, which are grouped into several parts.
/Hints Part 1When changing the SOURCE variable you will see that the result will not change.
/The reason for this is, that the values are buffered in the function module Z_VARIABLE_GET_DETAIL by default. By changing the value from ‘X’ to ‘ ‘ you can avoid this.The reason for this default is performance related: It is faster to return the buffered value directly. Please remember that the content of the drop down boxes in the WEB will be defined during the start and not reread during the planning session. This has the effect that the values of the DEST variable will not change in a drop-down box but only in the planning levels etc. .
/FUNCTION z_simple_relation.
[… other lines of Source code…]
l_buffer_call TYPE boole-boole VALUE 'X'.
[… other lines of Source code…]
Hints Part 2When entering two or three values in the SOURCE variable and checking the flag for user restriction, the function module z_simple_relation will stop with an information message saying, that only one value is allowed. The reason is that the function module reads by default all values of a variable and it doesn’t care about the restriction.
/To change this, replace the blank with an ‘X’.
/[… other lines of Source code…]
l_use_restricted_values TYPE boole-boole VALUE 'X',
[… other lines of Source code…]
Now we have seen how the first example can be implemented. But how can we use the example to solve the other scenarios mentioned?
Reference version
For the scenario where you would like to determine the value of a variable (reference version) dependent on the value of another variable (current plan version), you have to implement your own logic between the comment lines containing ‘logic start’ and ‘logic end’. As the rules are dependent on your specific set of requirements we can’t make any suggestions here.
Global variables
From a logical point of view you have the same variables in several planning areas e.g. the actual year. Now you would like to define one ‘leading’ area containing the variable that should automatically set/adjust the corresponding variables in the other planning areas.
If you would like to refer to the values of a reference variable (example 3) you simply have to change the constants containing the name of the variable and the area: in all areas where you implement the DEST variable the constants should point to your SOURCE variable.
In addition, you delete all coding between the ‘logic start’ and ‘logic end’ lines as there is no additional logic to be implemented.
* ------logic start
* nothing to do
* ------logic end
Using variables of type attribute
The basic idea of the solution is to use a variable SOURCE of type characteristic on the front-end side and to transfer the selected value to a variable DEST of type attribute on the back-end side. This attribute variable could then be used to restrict the selection.
As we are again merely transferring values from one variable to another we can make use of the implementation shown above. To do so follow these steps:
Choose the example of the global variables
Change the variable type of the variable DEST from characteristic to attribute.
The implementation now works as follows: Add the variable DEST into the attribute selection of the planning level and refer to the SOURCE variable. As this variable has the normal type characteristic it can be used in the planning folders and in the WEB.
A change of the source now influences via our implemented logic directly the values of the attribute variable.
Selection of an interval
This problem is solved by creating two source variables SFROM and STO containing the ‘from’ and the ‘to’ values as single values and a variable DEST, that will read the values of the two sources and compile them in an interval. As there are several code changes necessary, the complete Source code has been added to the appendix (4.3 Selection of an interval).