Use

You can include new tables in material master maintenance without modifying the programs for the material master.

The procedure for the inclusion of new fields in existing tables is described in note 44410.

This documentation is based mainly on the possibilities, number, and appearance of the main and secondary screens that the user can define.

Prerequisites

You should be familiar with the main features of the material master.

You have used the Customizing settings in  Logistics - General Material Master Configuring the Material Master to configure the layout of the screens. You can define the screen sequences that contain a sequence of main and secondary screens. Each screen sequence represents a display format for the material master.

Integration

The following requirements differ for the integration of new tables in the material master:

You must be able to maintain the data from the material master. The user must be able to recognize by the type of integration that they are dealing in this case with a separate object; the user must not expect the same features for the integrated data as in the case of material master data (such as field selection and reference handling). Integration should lead to only one maintenance simplification for the user.

The user should not be able to recognize that they are dealing with a table of the material master. The integration is therefore invisible to the user, with the only technical difference being to the connection – as a separate material master table. Accordingly, all the maintenance functions that are available for the material master data are also available for the integrated data.

Above all, you choose partial integration for data that does not need to be maintained urgently for each material, for additional data, and for data that does not need to be viewed urgently as part of the material master, such as production versions for a material.

You choose complete integration for data that needs to be maintained for all or many materials, for your data that is displayed in normal material master tables (no additional data), and for data that is to look the same as other material master data, such as for requirement groups for a material (only available in the retail environment).

Implementation

Because of the different requirements of integration, there are also different paths to implementation:

For partial integration, you can only maintain a new table in the same screen (secondary screen). The screen on which the new data is maintained has its own GUI status, and therefore differs from the screens in the material master in both the functions in the menu bar, and the pushbuttons available. In particular, you cannot jump from the screen directly to other material master screens, and you cannot accommodate the screen as your own main screen, or as a subscreen on an existing main screen. In addition to this, not all the maintenance functions for the integrated data are necessarily available.

You can open the secondary screen via the Extras menu, or via a pushbutton.

For complete integration, you can implement the maintenance of the new tables in the same way as for material master tables:

Partial integration is simpler than complete integration. In addition, there are a few restrictions for complete integration:

Complete Integration

Next the procedure for complete integration is described, with partial integration only being referred to if relevant.

BAdI method BADI_MATERIAL_OD is available for the integration of new objects, from which the application-specific function modules for the integrated objects can be called. The BAdI methods prepare the required data that the application module requires in each situation. This means that integration can happen in such a way that the integrated data does not need to be recognized in the material master. The overall logic, as well as the associated data, can be found in the application-specific function modules.

For partial integration only a part of the existing BAdI methods is required. Some BAdI methods are only relevant for integration into the retail environment (with the ending _ RT ), others for the material master in the industry and retail environment.

As an example for integration, the ones that belong to requirements groups integrated in retail are carried out (function group WRPP). This data is maintained on the material level (all requirements groups for one material are maintained on one screen). As an example for the integration of data on the material/plant level, the replenishment control parameters implemented in retail are used (function group WRPL), as plant-specific data in the material master must even during integration account for the problem of reference sites (compared with the point for reference handling). The screen modules for both database tables (WRPP and WRPL) can be found in function group WRPD.

Creating a Frame

The development of the screen is analogous to adding new fields in existing tables in a separate function group. The relevant includes for the material master are included in this function group (inclusion in main program, not a copy), so that the necessary routines for data retrieval can run from the screen. For requirements groups the development class is WRPL , the function group is WRPD .

The function group must also contain a special function module for initialization. With this function module, central control parameters are read on each entry into the function group. The module has the fixed prefix INIT_ , followed by the name of the function group. See INIT_WRPL . The module does not have parameters, and exists only of the one line.

perform init_baustein.

The form routine is defined in a standard include in the material master.

The creation of the function group can, from release 3.1, be made with the help of program COPYMGD1 (a parameter controls whether a function group is to be created for a material master for industry or for retail). The main program, the function module, and even a template screen are created automatically in this way.

Screen Logic

Within the function group you can – as normal - develop screens with PBO and PAI logic. You do not need to pay any particular attention to a specific numbering. You need to be aware of the following points for development:

General

In the industrial material master there is a difference between the activity types H = add, and V = change (a material can be either changed – MM02 – or new screens added or created – MM01). In the retail material master, there is a difference between the activity types N = create new material, and C = maintain material (a material can either be created from new – MM41 – or it can be maintained, that is to say changed or enhanced – MM42). So that the same program logic may also be used for the retail material master (the activity type is queried at different points), the activity type is set in the retail material master after the process of the initial screen in cases N and C to activity type H (you cannot see whether it has been changed or added in the retail material master; LMGMWFO0, OKCODE_BILD_RETAIL ). If you need to decide for a particular organizational level whether it is a question of changing or adding, then it needs to be decided via the internal table PTAB_FULL , and the corresponding RCODE .

Read Access, Data Buffering, and Data Transport

The data should only be read for a particular key from the database once per transaction, for a repeated call it should be read from the buffer. The read access must be retained in individual access modules. You incorporate the call for the read routine in the BAdI method READ_OTHER_MATERIAL_DATA .

You can go to the function modules for the requirements groups or the replenishment parameters for the creation of access modules (function group WRPPB for accessing table WRPP , function group WRPLB for accessing table WRPL ). The modules for both function groups are created according to the templates for access modules of the material master (there is a function group for each table, which contains all the access modules).

The property of the material master, to be Customizable for customers, is based in principle on the concept of data buffering, and the transport of data between subscreens, which can belong to different programs. The concept can be briefly described as follows:

For reasons of consistent features, the same concept for the tables to be integrated must be chosen with regards data buffering and data transport. In the GET_OTHER_MATERIAL_DATA_BILD BAdI method, the corresponding get-screen function module is called for the new data, which prepares the data for the screen in the work area. The checked data is returned to the buffer from the work area in the BAdI method SET_OTHER_MATERIAL_DATA_BILD .

The function modules XXXX_GET_SUB and XXXX_SET_SUB are called only for subscreens that are to be included from new. Your call requires the availability and declaration of the corresponding tables.

Checking of Data

Data should be checked at PAI. If the check routines return a missing consistency of data, do not leave the screen. The user must correct his or her entries. If you use E messages for outputting error messages, the system ensures that you cannot leave the screen until the error has been corrected.

However, when using subscreens, it is not always good to output E messages for errors. Output error messages as S messages, rather than actual error messages (E messages), if fields on different subscreens can be affected by a correction, or if it is a steploop screen. The user can still change all fields, and is not restricted to the field picked up by an E message. To stop you from leaving the screen anyway, global variable BILDFLAG must be set to X in case of errors. This ensures that it is not possible to go to another screen. As soon as the data is accepted by the system, BILDFLAG must be set to blank.

This case can also occur with warning messages (not all affected fields are on one subscreen). In this case, too you must output the message as an S message, but in addition the warning logic usually provided by the system (a warning can be confirmed, allowing you to leave the screen) must be programmed accordingly. (Use a flag to ensure that the warning only occurs once if the entry is not changed. Note that the warning must be output again if the data is changed in the meantime.)

( )

Compare the procedure in function group MGD1, PAI module MARC-DISMM-FXHOR .

Checks should always be implemented as function modules, because the are called again after saving in the posting logic. When creating check modules for checking entries, remember:

Function Codes

At PAI, actions of the user are checked by a function code. These function codes are addressed in the actual program, using globally defined constants. The naming convention for constant names is FCODE_ <name of function code>. The definition of these constants occurs in a separate include file (see WRPP_FCODES ).

To ensure the uniqueness of the function code, this should comprise the name of its own function group and a user-defined function code name.

The function code is an element of structure RMMZU and can be called as RMMZU-OKCODE .

If the new subscreen contains a steploop screen with its own function codes for scrolling (note: the function codes for scrolling must be unique, the same as any other function codes), the application must reset variable BILDFLAG after processing the function code, otherwise there is a jump to the next screen.

PBO Modules

The following modules are standard in the PBO logic of a subscreen.

Initialization: must always be present

Data procurement of material master data from buffers (work area): must always be present

Field selection for material master fields (T130F)

Special field selection for material master fields

Special field selection for fields with a special field group

Field selection for descriptions (if a data field is hidden, the description must be hidden)

Sets the screen status

Change management (deactivated)

Default handling for material master fields in industry solution

Default handling for material master fields in industry solution

Default handling for material master fields in industry solution

Reads descriptions of data fields

Default handling for material master fields for retail solution

Return of material master data to buffer (work area)

The modules for data procurement and the return of data to the buffer ( GET_DATEN_SUB, SET_DATEN_SUB) must always be present. They also provide transport of material data between different function groups.

The call of module GET_DATEN_SUB means that all currently entered material master data is available. For example, all basic data can be accessed using MARA-<Feldname> . If the current status of the existing key combination of a material is to be used, this data is always to be used (perhaps the data in the "final" buffers does not have the current status). However, if material data for another organizational level than the current one is required ( RMMG1 ) this data cannot be determined with the existing function modules for the material master (see function groups in package MAG, or MGW, such as MG21 for accessing table MARA). If material master data for other keys than the current one is required to be displayed, note that the corresponding authorizations must be checked (only relevant to industry material master, not retail material master). For example, if you want to display material master data for a different plant from the current one, you need to check the authorization for this plant first.

Template Handling

The modules for template handling are only on every subscreen for industry. For Retail, the module only occurs in header subscreens (subscreens with key fields), because the template logic runs once per screen, not per subscreen. For customer-specific tables, a default logic must also be programmed, which is based on the logic of the industry material master or the different logic of the retail material master. The default logic for the table to be integrated should be encapsulated as a function module, because then a default is generated even if the subscreen is not processed, and this logic must run in the posting logic in this case.

In default handling for new tables, note that the default for a table (or table and maintenance status) only runs once when you first create data. It must not overwrite changes made by the user.

For each field you can control whether the field is copied from the template ( T130F-KZREF ). If this control is required for new fields of integrated that are to be inserted, you need to provide corresponding control (see negative list).

For the retail material master, call the function module for default logic for integrated objects in BAdI method MATERIAL_REFERENCE_OTHER_DATA_RT .

Example: See the default module for requirements groups WRPP_GET_REFERENCE and for replenishment control parameters WRPL_GET_REFERENCE.

In BAdI method MATERIAL_PREPARE_POSTING_OD relevant checks can be made before posting, and any default data can be added to (for example, if the screen was not processed explicitly and therefore no default data was generated).

Example: WRPP_PREPARE_POSTING and WRPL_PREPARE_POSTING .

PAI Modules

The following modules are standard in the PAI logic of a subscreen.

Data procurement of material master data from buffers (work area)

Return of material master data to buffer (work area)

For each screen field there must be a field statement, because otherwise no data transport takes place (note: the field statements must be after calling GET_DATEN_SUB. You may need to insert check routines for checking entries at PAI.

Passing On of Data (Mass Maintenance) and Variance Handling

In the retail material master (not in the industry material master) there is mass maintenance in that data for a material can be maintained simultaneously for several organizational levels (such as plants). Also, there are generic materials with subordinate variants, whereby data maintained at the level of the generic material automatically gets passed on to all variants. Data from a superior level is only passed on to related subordinate levels if the subordinate level is not maintained differently.

To record variances, "variance pointers" are updated (table MABW). These show whether a variance exists for a template and are written for all types of organizational level (see table MABW).

Example: sales data for a variant (distribution chain level) has been maintained differently from that of the generic material. A variance pointer is written for the variant and distribution chain. The data is also passed on if there is a variance, but only for the fields that have not been maintained differently.

Variances can be displayed using a button (for a specific screen and therefore organizational level).

The functionality of mass maintenance must also be supported for new objects in the retail master record. To do this, a suitable function module must be created, to which the current key fields are transferred, and which then checks whether data must be passed on (for example from a generic material to a variant) and any dependent data in the buffer must be adapted (the current data can be taken from the buffer). The function module must be called in BAdI method MATERIAL_REFCHANGE_OTHER_DATA .

( )

WRPP_REFCHANGE and WRPL_REFCHANGE.

Data that is newly imported by a change of validity (that was therefore not in the buffer at the time of passing on data) must also be reimported and adapted to any change. Example: data from dependent plants are adapted to the data of the template plant. Only the plants that have data in the buffer are adapted, all others are not adapted until posting. If data is imported for a plant that was not in the buffer, the data for this plant must be adapted to the template plant. This logic must be run by the corresponding function module for creating the default (difference between generating a default and passing on data).

( )

WRPP_GET_REFERENCE and WRPL_GET_REFERENCE

If the level at which new data is maintained belongs to an existing level at which variances are written, the new data must be integrated in the logic of the variance pointer. To do this a function module must be implemented that is called in BAdI method MATERIAL_GET_DIFFERENCES_OD_RT and specifies whether there is a variance for the data just maintained (buffer), and if there is, at what level.

( )

WRPP_GET_DIFFERENCES, WRPL_GET_DIFFERENCES

For displaying variance reasons, you also require a function module that is called in BAdI method MATERIAL_DIFFMAINT_ORGLEVS_OD and returns the fields where there is a variance.

( )

WRPP_GET_DIFFMAINT_ORGLEVS and WRPL_GET_DIFFMAINT_ORGLEVS.

If the level at which new data is maintained does not belong to an existing level at which variances are written, the application must write and display its own variance pointer.

Posting Logic

Three functions are required for posting data:

The function modules can read the data required from the buffers of the function group.

Customizing

You have the following options for integration in the maintenance user interface of the material master record.

The necessary Customizing settings for integration of new subscreens in the material master are defined in transaction OMT3 .

If you want to include new subscreens in an existing main or additional screen, check whether there is space. You go to the detail display of the screen: if a subscreen with number 0001 (dummy) occurs there, this can be replaced with a new subscreen in the relevant function group. If there is no free subscreen on the screen, you must check whether the subscreen container can be changed (the subscreen container contains a certain number of placeholders for subscreens to be inserted). Subscreen containers for industry material masters are in function group MGMM , those for the retail material master are in function group MGMW .

The decision whether to include a new screen as a main or additional screen is made when you create a new screen, when you set the screen type. If it is a main screen, the sequence of main screens can be defined. If it is an additional screen, you can decide whether the screen is called by choosing a pushbutton or the Extras menu. The Extras menu should usually only contain functions that are relevant to all screens. All others should be implemented as pushbutton.

If the call is from the Extras menu, function code ZUXX is automatically assigned to the additional screen. As for the main screen, the sequence in which additional screens appear in the menu can be defined.

If the call is from a pushbutton, the function code must be assigned to the additional screen. The pushbutton must be accommodated on some new or existing screen in the same function group, like a new field. Pushbutton function codes must start with PB and be unique. PB9* is reserved for customer pushbuttons. The name of the pushbutton should include the string PUSH.

For each additional screen, you should create an OKCODE routing, regardless of whether the screen is called as an additional screen in the sequence or by pushbutton. The OKCODE routine must be implemented in the same function group. To call the OKCODE routine, use BAdI method SET_PROGRAM_FOR_OKCODE_ROUTN to make the name of its own program known to flow control for the material master.

The OKCODE routine is assigned to the additional screen in OMT3. For full integration, the OKCODE routine includes only the check whether the integrated data can be maintained (see below).

To check whether the integrated data can be maintained, a check module must be created. This is used in several places:

Partial Integration

With partial integration, you can only maintain a new table in its own secondary screen. You can open the secondary screen from the Extras menu, or by choosing a pushbutton.

Unlike complete integration, these secondary screens are not assigned to the subscreens using OMT3. The screen that appears when the secondary screen is called is a fixed screen whose display cannot be influenced by the user. The screen has its own GUI status, which is different to the GUI status of the material master screens. Accordingly, you cannot go directly to other screens of the material master from this screen.

The implementation of these secondary screens is, technically speaking, fully encapsulated. The screen is called by the OKCODE routine that is assigned to the screen.

Creating a Frame

For partial integration, as for complete integration, the screens required and the functions belonging to them are developed in a separate function group. However, there are no special requirements for this function group, unlike complete integration.

Screen Logic

We recommend that you keep as close as possible to the procedure and functionality of the material master, in spite of the encapsulation involved in partial integration.

These are the salient points for screen logic, in brief:

Posting Logic

The same principle apply to posting logic as for complete integration. You only need your own function module for posting if posting is not started by "perform on commit". However, we recommend in this case that you find the change by using your own function module ( CHANGE_CHECK ).

Customizing

The above applies to OMT3 settings, too. However, with partial integration, you can only implement an integration as its own secondary screen.

Data Transfer / Data Distribution

The transfer and distribution of the new material data uses ALE and the relevant IDocs (as of R/3 4.0A, using BAPIs). The IDocs required, and the functions for creating, posting, and manual sending of IDocs, must be created by the application. The application also has to deal with the ALE Customizing settings required (change pointers and so on).

The serialization of message types by ALE ensures posting in the correct sequence in the target system (first the material, then dependent objects). You need to define Customizing settings for this.

For manual sending of material data, you need a function module to which a list of materials can be transferred. This function module must then created the relevant IDocs. This function module must be integrated in BAdI method MG_IDOC_CREATE_FULL_MAT (for industry) or MG_IDOC_CREATE_FULL_ART (for Retail), and is called when you want to send a complete material.

Reorganization / Discontinuation and Archiving, and Deletion Flags

The reorganization or discontinuation of integrated data uses the relevant function modules in the reorganization programs of the material master. For this, you need the following function modules for the tables you want to integrate:

You can use methods of BAdI BADI_MM_MATNR for this.For more information, see the documentation on the BAdI.

If you need your own deletion flags at integrated data level, you need to provide a function for setting deletion flags. Deletion flags at material level are passed on to dependent objects. If you need your own deletion flags, you must ensure that either the new object is integrated in this logic of passing on deletion flags, or the check for deletion flags for the integrated object queries the deletion flags that are above it in the hierarchy.

Usually, the deletion flags for the material are sufficient.

Writing and Displaying Change Documents

For documenting changes to data, change documents are updated every time individual fields in a table are changed. To do this, a change document object must be created for the table. The creation of change documents is performed by the application-specific posting module, by calling the FORM routine generated by the system.

To display change documents, you need to develop a special report.