Evaluating Condition Changes 
Use
This function enables the system to recognize condition changes and to provide the applications concerned with the relevant information.
Integration
There are two procedures for evaluating condition changes:
- The procedure delivered in the standard system.
- An alternative procedure (as of R/3 4.6A).
The advantages of the alternative procedure for POS outbound processing are:
- Instead of reading the condition change pointers, the system only reads a worklist that requires fewer system resources.
- The system only analyzes POS-relevant condition changes.
- The analysis program reads the condition change pointers for all the applications that are related once. This does not need to be done for every application separately. As of Release 4.7 condition change pointers are no longer read – the system only updates the worklist as soon as condition changes are created.
Features
The procedure delivered in the standard system works in the following way:
In the ALE layer, the function for generating condition change pointers for POS outbound is activated (transaction BD52 for message type WP_PLU, entries for change document object COND_A). You cannot restrict processing to particular POS-relevant condition types. The system generates a change pointer for every condition change. The analysis of condition change pointers in POS outbound filters out the POS-relevant change pointer. This procedure slows down system performance.
The alternative procedure used the new R/3 condition document index function:
In this procedure the system also generates a change pointer for every condition change. Your changes are analyzed once by the analysis program for all applications that use this procedure. The analysis program creates a worklist for each application - the worklist is to contain relevant condition changes. In Customizing, you can make very accurate settings for every application (right down to the name of the condition table, for example, A071) for which condition changes are relevant. As of Release 4.7 the analysis program is replaced by an automatic update of the worklist when changes are made to a condition.
Activities
If you want to evaluate condition changes using the alternative procedure instead, use the following procedure:
Procedure for R/3 4.6A to R/3 4.6C
If you have defined your own POS-relevant condition types and condition tables, you have to alter the Customizing settings for your condition document index accordingly. Use transaction OWS2 for this. The entries for the POS-relevant condition types and tables delivered in the standard system have already been entered. In addition, you need to enter the POS-relevant condition type and the numbers of the condition tables concerned from the access sequence that relates to the condition types. Do this for all the condition types you have defined yourself and all those condition types used in the POS condition type groups. There is no fixed sequence for these entries.
- Reorganize POS outbound. Start the program RWDPOSRS for POS outbound.
- Ensure that the message type CONDBI in the ALE layer is activated.
- Ensure that the program RMEBEIN4 is complete before starting the change message. It creates the worklist for POS outbound. This program must be finished before one of the linked applications starts. Therefore, plan the program to be executed at regular intervals in the background like a change message.
In the selection screen, select all the document types and the indicator Mark processed change pointers for reorganization. Plan the background job that starts the change message so that it does not start until after the first time program RMEBEIN4 has started (status-independent). Then you will not encounter any difficulties with planning periodic intervals for running this job.
- To avoid losing any condition changes when you change the analysis procedure, wait until the next change message for all the stores that require it has been completed and has been given the status OK.
- Finally, ensure that none of the normal condition change pointers are read while the change message is being run. They are no longer required, as they are replaced by the worklist. Use transaction BD52 for message type WP_PLU for this, and delete the following entries:
- Object COND_A, table name KONDAT, field DATAB
- Object COND_A, table name KONDAT, field DATBI
- Object COND_A, table name KONDAT, field KEY
Procedure as of R/3 4.7
The following procedure is also described in SAP Note 519685.
- Same as point 1 from the section above.
- Same as point 2 from the section above.
- Same as point 3 from the section above.
- Migrate the old change pointers (see
Migration of Change Pointers)
- Check your Customizing settings for the condition document index. Start up the maintenance view (transaction SM30) for table V_T6I2A. The following entries should already be made:
- Document category 55, condition table KONDAT, field name DATAB
- Document category 55, condition table KONDAT, field name DATBI.
- Document category 55, condition table KONDAT, field name KEY
- Document category 55, condition table KONP, field name KEY
- Document category 55, condition table KONP, field name KBETR
- Document category 55, condition table KONM, field name KEY
- Document category 55, condition table KONM, field name KBETR
- Document category 55, condition table KONW, field name KEY
- Document category 55, condition table KONW, field name KBETR
If these entries are no longer in the Customizing settings, enter them again.
- Start the program RMEBEIN4 once only. The parameterization is the same as in point 4 from the previous section. This program should be run at a time when no more changes are being made in the system (preferably in the evenings).
- As soon as the program has finished and before the changes have been made in the system, navigate again to the condition document index in Customizing. Start up the maintenance view again (transaction SM30) for table V_T6I2 and set the direct entry indicator for document category 55 so that the following entry is made:
- Document category 55, DirectEntryID <selected>, Migration ID <selected>
- Finally, complete the instructions in point 6 from the previous section.
Result
The system only analyzes the worklist from the next change message instead of the condition change pointers. Instead of doing a conversion, you can execute an initialization straight away. In this case, you only have to carry out the instructions in points 1, 3, 4, and 6 (R/3 4.6A to R/3 4.6C) or points 1, 5 and 7 (as of R/3 4.7).