Up to R/3 Plug-In 2000.2, the procedure for transferring changed master data is that ALE change pointers with special message types are written for changes to fields in the relevant tables. You can use transaction CFP1 to evaluate these change pointers and compare them with active integration models. If required, this activates the transfer of the changed data to APO.

From R/3 Plug-In 2000.2 four new Business Transaction Events (BTEs) and the necessary CIF functionality will be available. This is so that changes to master data are transferred immediately to APO, as with the procedure for transactional data. The active integration models of the corresponding filter object type are the basis for the filter (T_MAT, T_CUS, T_VEN). If there are one or more active integration models for the corresponding filter object, the changed data is transferred to the APO system(s). This procedure removes the need for change transfer using ALE change pointers.

Also, it is possible that when a master data object is changed, this object is then regarded as APO-relevant and is transferred to APO. This functionality corresponds to the functionality described for the initial creation of master data.

Up to R/3 Plug-In 2000.1, the recommended procedure for transferring newly created master data was as follows:
A test was carried out to see whether master data had been created in the meantime which fulfils the selection criteria of the background processing variant, or whether certain master data no longer fulfils these criteria. The test was based on periodic background processing. If this is the case, background processing can do the following in a number of steps:

1. Create a new version of an integration model
2. Background processing can be activated
3. If required, the old inactive version can be deleted

From R/3 Plug-In 2000.2, you can immediately adapt the integration landscape between APO and R/3 to suit the new situation when updating master data. Again, to do this, you create new versions of integration models and activate them.

1. Activate the relevant BTEs. These BTEs have the application indicator ND-APO, which means that this application indicator must be marked as active in the table TBE11. The BTE numbers are 1250 for material master, 1321 for customer master, and 1421 for vendor master. Correspondingly, the numbers of the BTE consumer modules are: NDPLG_APO_001_00001250_MAT, NDPLG_APO_001_00001321_CUS and NDPLG_APO_001_00001421_VEN. When the BTEs are activated, two things occur. Firstly, the changes to the master data are transferred in near-real time. Secondly, if the appropriate CIF customizing has been carried out, the integration model is adapted accordingly. Activate the BTEs using transaction FIBF or SM30 after entering the table TBE11.
2. Maintain the control entries for adapting the integration model. You determine the procedure for adapting the integration model by means of entries in the database table CIFIMODGEN. This is defined as follows:

Maintain the entries using transaction SM30.

• The field HOOK contains one of six possible entry points:

• Creation of new materials (MAT_INS)
• Change to material master data (MAT_UPD)
• Creation of new material (CUS_INS) (corresponding point for customers)
• Change to material master data (CUS_UPD) (corresponding point for customers)
• Creation of new material (VEN_INS) (corresponding point for vendors)
• Change to material master data (VEN_UPD) (corresponding point for vendors)

• The field PROGNAME contains the name of an ABAP/4 program. This program should be executed when one of these events occurs.
• The field VARIANT contains the name of a variant. This variant contains the input parameters of the given program.

You can specify several program or variant combinations for the same entry point and determine their order using the field COUNTER. Usually, you should specify the standard program RIMODGEN for generating integration models. This program’s functionality was extended:

• An existing integration model can be selected
• Filter objects can be inserted or deleted
• The result can be saved as a new version of the integration model

Also, the program evaluates the integration model key, the checkboxes for the filter objects, and the selection options for material, customer, and vendor. If the number of filter objects does not change, no new version is created. If a new version is created, it is activated, in other words, new objects are transferred, and the data flow is stopped for obsolete objects.

In the RIMODGEN selection screen, the fields Name of Integration Model, Destination System and Application Name are obligatory, that is, they must be filled in.

In the case of material, the selection options under Relevant Materials are evaluated and compared with the newly created or changed material. Besides the checkbox for material master, the following checkboxes are evaluated:

• Availability check
• Sales orders
• Purchase orders and purchase requisitions
• Production orders and process orders
• Planned orders
• Manual reservations
• Planned independent requirements
• Stocks, all types
• Consumption data

If the checkbox for PPMs has been selected, a selection is carried out on the database using the selection options entered. The results are transferred to the model. In the case of newly created material, this selection provides no results, since no bills of material, task list or production version exist yet. In the case of material changes, the selection can deliver valid PPMs. In the case of PPMs, however, the current date enters the system in the form of the key date. Therefore, it is possible that a ‘new’ PPM is selected and transferred, even if nothing has changed in the bills of material, production version, or task list.

All other selection options (including special restrictions for material/plant for the individual documents) are not taken into account here.

In the case of customers, only selection options for customers and the checkbox ‘customer’ are taken into account. The same is the case for vendors.

The purpose of the extension CIFIMO01 (CIF-IMO-zero-one!) with the module EXIT_RIMODGEN_001 is to influence the number of filter objects. This extension modifies the list of filter objects provided by the standard functionality.

The process of automatic generation of integration models runs in the background as qRFC. For this reason, you can test in the qRFC monitor (transaction SMQ1) whether errors occurred. The queue name consists of the prefix CF_IMOD_ and the master data type, that is, T_MAT, T_CUS or T_VEN. Transaction SMQ1 provides the following functions:

• Restart
• Debugging
• Call deletion

If the CIF application log is activated, entries are written there. These entries are documented under the object CIF and the sub-object IMOD. Detailed information about the automatic generation process and the activation of the model is located here.