Integration of New Tables in the Material Master

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 Customi ing settings in Logistics - General Material Master Configuring the Material Master to configure the layout of the screens. You can define the screen se!uences that contain a se!uence of main and secondary screens. "ach screen se!uence represents a display format for the material master.

You should not ma#e any changes to the standard screen se!uence for some new tables$ instead you should ma#e change a copy of a suitable standard screen se!uence, and create a separate screen se!uence.

Integration
The following re!uirements differ for the integration of new tables in the material master% Partial integration

You must be able to maintain the data from the material master. The user must be able to recogni e by the type of integration that they are dealing in this case with a separate ob&ect$ 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(. )ntegration should lead to only one maintenance simplification for the user. Complete integration

The user should not be able to recogni e 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. +ccordingly, all the maintenance functions that are available for the material master data are also available for the integrated data. +bove 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 loo# the same as other material master data, such as for re!uirement groups for a material 'only available in the retail environment(.

Implementation
,ecause of the different re!uirements of integration, there are also different paths to implementation% )mplementation for partial integration

-or 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 ./) status, and therefore differs from the screens in the material master in both the functions in the menu bar, and the pushbuttons available. )n particular, you cannot &ump 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. )n 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. )mplementation for complete integration

-or complete integration, you can implement the maintenance of the new tables in the same way as for material master tables% o o o 0ubscreen 'screen module( on an existing main screen, or additional screen own main screen +dditional screen that can only be selected via the menu Extras +dditional screen that is opened by choosing a pushbutton 'and can be selected via the Extras menu( The same ./) status is used for the material master screens.

1artial integration is simpler than complete integration. )n addition, there are a few restrictions for complete integration%

The enhancement of the material master should be substantive. )t is not about the recording of one or two fields in an existing subscreen. This documentation describes only the integration of new material tables from the aspect of material data maintenance. The use and processing of the data entered in this way into operative processes re!uires a separate concept. The field selection control in the material master cannot be enhanced for additional tables. + separate field selection must be implemented accordingly. The user can decide for the reference handling whether the field is to be suggested from the reference material. You can maintain this via a Customi ing transaction, and is stored in table T120-. 3eference handling also needs to be implemented here.

4ey fields in new tables The new tables usually have a #ey that does not agree with the #ey for an already existing material table 'otherwise integration would wor# by recording new fields in an existing material master table(. )f you have to maintain the #eys for the data5s data records on separate screens, meaning that you need to go to the different data records by changing the organi ational level, then you can generally only implement partial integration. Complete integration of new #ey fields is not supported in material master maintenance. The recording of a new maintenance status is not possible due the integration of new ob&ects in the material master. 6ew ob&ects must be added to an existing material status.

Complete Integration
6ext the procedure for complete integration is described, with partial integration only being referred to if relevant. ,+d) method ,+7)89+T"3)+:8;7 is available for the integration of new ob&ects, from which the application<specific function modules for the integrated ob&ects can be called. The ,+d) methods prepare the re!uired data that the application module re!uires in each situation. This means that integration can happen in such a way that the integrated data does not need to be recogni ed in the material master. The overall logic, as well as the associated data, can be found in the application<specific function modules. -or partial integration only a part of the existing ,+d) methods is re!uired. 0ome ,+d) methods are only relevant for integration into the retail environment 'with the ending 8 RT(, others for the material master in the industry and retail environment. +s an example for integration, the ones that belong to re!uirements groups integrated in retail are carried out 'function group =311(. This data is maintained on the material level 'all re!uirements groups for one material are maintained on one screen(. +s an example for the integration of data on the material>plant level, the replenishment control parameters implemented in retail are used 'function group =31:(, 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 '=311 and =31:( can be found in function group =317.

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. -or re!uirements groups the development class is WRPL, the function group is WRPD. The function group must also contain a special function module for initiali ation. =ith 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. 0ee INIT_WRPL. The module does not have parameters, and exists only of the one line. perform init8baustein. The form routine is defined in a standard include in the material master. The creation of the function group can, from release 2.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
=ithin the function group you can * as normal < develop screens with 1,; and 1+) 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
"ach screen must be defined as a subscreen. 0ee screen attribute from 1000> WRPD. You can create multiple subscreens within the function group 'for example, for header fields and data fields(. The modules contained in the flow logic for the standard screen, or also in the template screens, should be used, as far as features are concerned, as templates. )f you need to create new header screens 'screen with #ey fields(, then you should do this my changing a copy on an existing header screen. The modules give hints on the features that should be available on the screen, or can be available. +t least some of the modules contained must be available on the subscreen 'see below(. You develop corresponding modules for others for individual application. The flow logic for your modules is described in more detail further below. )f you display fields with corresponding text in the new screens 'such as material groups and the corresponding descriptions(, this is to ensure that, when you hide the data field 'for example, in the field selection(, the corresponding text is also hidden. )f you describe modification group 1 for both the fields which belong together, with -n and Tn, n ? 01, 0@, 02, et cetera, then this tas# is automatically done by the standard module FAUSW_BEZEICHNUNGEN. -or example, see screen @000>=317. + material is formatted for a particular activity in material master maintenance% the material is either created anew 'also enhanced in the industrial material master(, or changed, or its data is displayed without the possibility for change. The activity type results from the combination of the two fields T130M-AKTYP and NEUFLAG 'compare INCLUDE MMGXV01 for the definition of the different activity types(. )t is defined globally within the function group.

)n the industrial material master there is a difference between the activity types A ? add, and B ? change 'a material can be either changed * 990@ * or new screens added or created * 9901(. )n the retail material master, there is a difference between the activity types 6 ? create new material, and C ? maintain material 'a material can either be created from new * 9941 * or it can be maintained, that is to say changed or enhanced * 994@(. 0o that the same program logic may also be used for the retail material master 'the activity type is !ueried at different points(, the

activity type is set in the retail material master after the process of the initial screen in cases 6 and C to activity type A 'you cannot see whether it has been changed or added in the retail material master$ LMGMWFO0 OKCODE_BILD_RETAIL(. )f you need to decide for a particular organi ational level whether it is a !uestion of changing or adding, then it needs to be decided via the internal table PTAB_FULL, and the corresponding RCODE.

ea! "ccess# $ata %uffering# an! $ata Transport

The data should only be read for a particular #ey 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 ,+d) method READ_OTHER_MATERIAL_DATA. You can go to the function modules for the re!uirements 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 Customi able 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% ,efore reading from the database, the authori ation is chec#ed. The data is read in once by the database 'setting the necessary loc#s at this time(, and buffered for each table in an individual function group. -or the 1,; of a screen container, the relevant data for the screen is read from the buffer for each function group, and set in an intermediate buffer 'wor# area( '/ structures(. e.g. MARA_GET_BILD MARM_GET_BILD -or the 1,; of a subscreen, the data relevant for the subscreen is read from the intermediate buffer, so that the data can be displayed on the screen. e.g. MARA_GET_SUB MARM_GET_SUB The data is changed by the entries made by the user, and then chec#ed by the program. The chec#ed data is returned to the intermediate buffer for each subscreen. e.g. MARA_SET_SUB MARM_SET_SUB )f all subscreens for a screen have run, and the data has been chec#ed consistently, then the data from the wor# area is returned to the buffer. e.g. MARA_SET_BILD MARM_SET_BILD The database status is basically retained in the buffer ') status(. The last consistent status before the next consistent change is also retained in the buffer ': status(. +t the start of the transaction the : status corresponds to the ) status. These statuses are often used for chec#s, the database status is also need to establish whether changes have arisen.

-or reasons of consistent features, the same concept for the tables to be integrated must be chosen with regards data buffering and data transport. )n the GET_OTHER_MATERIAL_DATA_BILD ,+d) method, the corresponding get<screen function module is called for the new data, which prepares the data for the screen in the wor# area. The chec#ed data is returned to the buffer from the wor# area in the ,+d) 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 re!uires the availability and declaration of the corresponding tables.

Chec&ing of $ata
7ata should be chec#ed at 1+). )f the chec# routines return a missing consistency of data, do not leave the screen. The user must correct his or her entries. )f you use " messages for outputting error messages, the system ensures that you cannot leave the screen until the error has been corrected. Aowever, when using subscreens, it is not always good to output " messages for errors. ;utput error messages as 0 messages, rather than actual error messages '" 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 pic#ed up by an " message. To stop you from leaving the screen anyway, global variable BILDFLAG must be set to C in case of errors. This ensures that it is not possible to go to another screen. +s soon as the data is accepted by the system, BILDFLAG must be set to blan#. This case can also occur with warning messages 'not all affected fields are on one subscreen(. )n this case, too you must output the message as an 0 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. '/se a flag to ensure that the warning only occurs once if the entry is not changed. 6ote that the warning must be output again if the data is changed in the meantime.(

Compare the procedure in function group 9.71, 1+) module MARC-DISMM-FXHOR.

Chec#s should always be implemented as function modules, because the are called again after saving in the posting logic. =hen creating chec# modules for chec#ing entries, remember% + chec# module must generate messages for errors and warnings. )f there is an error, the module must be left with message raising.

Function Co!es
+t 1+), actions of the user are chec#ed 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_Dname of function codeE. The definition of these constants occurs in a separate include file 'see WRPP_FCODES(. To ensure the uni!ueness 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.

)f the new subscreen contains a steploop screen with its own function codes for scrolling 'note% the function codes for scrolling must be uni!ue, the same as any other function codes(, the application must reset variable ,):7-:+. after processing the function code, otherwise there is a &ump to the next screen.

P%' Mo!ules
The following modules are standard in the 1,; logic of a subscreen. 9;7/:" )6)T80/,

)nitiali ation% must always be present 9;7/:" ."T87+T"680/,

7ata procurement of material master data from buffers 'wor# area(% must always be present 9;7/:" -":7+/0=+A:

-ield selection for material master fields 'T120-( 9;7/:" 0;67"3-+/0

0pecial field selection for material master fields 9;7/:" 0;67"3-+/0=8)68-.3/11"6

0pecial field selection for fields with a special field group 9;7/:" -+/0=8,"F")CA6/6."6

-ield selection for descriptions 'if a data field is hidden, the description must be hidden( 9;7/:" ,):70T+T/0

0ets the screen status 9;7/:" -":7A)0T;3)"

Change management 'deactivated( 9;7/:" F/3"-8B;30CA:+."68, 'industry(

7efault handling for material master fields in industry solution

9;7/:" 3"-7+T"68B;30CA:+."6

7efault handling for material master fields in industry solution 9;7/:" F/3"-8B;30CA:+."68+ 'industry(

7efault handling for material master fields in industry solution 9;7/:" ,"F")CA6/6."68:"0"6

3eads descriptions of data fields 9;7/:" ,"F")CA6/6."68:"0"683T '3etail only(

7efault handling for material master fields for retail solution 9;7/:" 0"T87+T"680/,

3eturn of material master data to buffer 'wor# 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. -or example, all basic data can be accessed using MARA-"F#$%&'(#). )f the current status of the existing #ey combination of a material is to be used, this data is always to be used 'perhaps the data in the GfinalG buffers does not have the current status(. Aowever, if material data for another organi ational level than the current one is re!uired ' RMMG1( this data cannot be determined with the existing function modules for the material master 'see function groups in pac#age 9+., or 9.=, such as 9.@1 for accessing table 9+3+(. )f material master data for other #eys than the current one is re!uired to be displayed, note that the corresponding authori ations must be chec#ed 'only relevant to industry material master, not retail material master(. -or example, if you want to display material master data for a different plant from the current one, you need to chec# the authori ation for this plant first.

Template (an!ling
The modules for template handling are only on every subscreen for industry. -or 3etail, the module only occurs in header subscreens 'subscreens with #ey fields(, because the template logic runs once per screen, not per subscreen. -or 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.

)n 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. )t must not overwrite changes made by the user. -or each field you can control whether the field is copied from the template ' T130F-KZREF(. )f this control is re!uired for new fields of integrated that are to be inserted, you need to provide corresponding control 'see negative list(. -or the retail material master, call the function module for default logic for integrated ob&ects in ,+d) method MATERIAL_REFERENCE_OTHER_DATA_RT. "xample% 0ee the default module for re!uirements groups WRPP_GET_REFERENCE and for replenishment control parameters WRPL_GET_REFERENCE* )n ,+d) method MATERIAL_PREPARE_POSTING_OD relevant chec#s 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(. "xample% WRPP_PREPARE_POSTING and WRPL_PREPARE_POSTING.

P"I Mo!ules
The following modules are standard in the 1+) logic of a subscreen. 9;7/:" ."T87+T"680/,

7ata procurement of material master data from buffers 'wor# area( 9;7/:" 0"T87+T"680/,

3eturn of material master data to buffer 'wor# area( -or each screen field there must be a field statement, because otherwise no data transport ta#es place 'note% the field statements must be after calling GET_DATEN_SUB* You may need to insert chec# routines for chec#ing entries at 1+).

Passing 'n of $ata )Mass Maintenance* an! +ariance (an!ling

)n 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 organi ational levels 'such as plants(. +lso, there are generic materials with subordinate variants, whereby data maintained at the level of the generic material automatically gets passed on to all variants. 7ata from a superior level is only passed on to related subordinate levels if the subordinate level is not maintained differently. To record variances, Gvariance pointersG are updated 'table 9+,=(. These show whether a variance exists for a template and are written for all types of organi ational level 'see table 9+,=(. "xample% sales data for a variant 'distribution chain level( has been maintained differently from that of the generic material. + 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. Bariances can be displayed using a button 'for a specific screen and therefore organi ational level(. The functionality of mass maintenance must also be supported for new ob&ects in the retail master record. To do this, a suitable function module must be created, to which the current #ey fields are transferred, and which then chec#s 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 ta#en from the buffer(. The function module must be called in ,+d) method MATERIAL_REFCHANGE_OTHER_DATA.

WRPP_REFCHANGE and WRPL_REFCHANGE* 7ata 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. "xample% data from dependent plants are adapted to the data of the template plant. ;nly the plants that have data in the buffer are adapted, all others are not adapted until posting. )f 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

)f 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 ,+d) method MATERIAL_GET_DIFFERENCES_OD_RT and specifies whether there is a variance for the data &ust maintained 'buffer(, and if there is, at what level.

=3118."T87)--"3"6C"0, =31:8."T87)--"3"6C"0

-or displaying variance reasons, you also re!uire a function module that is called in ,+d) method MATERIAL_DIFFMAINT_ORGLEVS_OD and returns the fields where there is a variance.

WRPP_GET_DIFFMAINT_ORGLEVS and WRPL_GET_DIFFMAINT_ORGLEVS* )f 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 re!uired for posting data% + function module for chec#ing whether data has changed in the transaction. This is not only executed when posting, but also to decide whether a confirmation prompt is shown 'once all the screens have been processed(. The function module is called in ,+d) method CHANGE_CHECK_OTHER_MAT_DATA. "xample% WRPP_CHANGE_CHECK_1. + function module for determining in detail which changes to the database must be updated 'inserts, updates, deletes(. The function module is called in ,+d) method CHANGE_CHECK_OTHER_MAT_DATA 'in this case, flag P_CHANGE_CHECK_+ , X is set(. "xample% WRPP_CHANGE_CHECK_+* -irst, function module SET_IWRPP_TWRPP is called, which sets the logical database status ') status( and the actual database status '; status(. '1rere!uisite, so that CHANGE_CHECK wor#s correctly.( + function module for physically updating the data. This function is only called if ,+d) method CHANGE_CHECK_OTHER_MAT_DATA has registered a change. The function module posts the changed data IN UPDATE TASK. The function module is called in ,+d) method MATERIAL_POST_OTHER_DATA. "xample% WRPP_START_POSTING calls function module WRPP_POST IN UPDATE TASK.

The function modules can read the data re!uired from the buffers of the function group.

;nce the functions for updating the database status have run in the retail material master 'for example, SET_IMARA_TMARA(, no more new data can be imported to the material master buffer, because the change chec# would incorrectly interpret it as to be created. The buffer of the material master must not be changed in the chec# module and update module 'when importing new data, the logical database status is not provided and the records are interpreted as to be created(.

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

0ubscreen 'screen module( on an existing main screen, or additional screen ;wn main screen +dditional screen that can only be selected via the menu Extras +dditional screen that can be opened by a pushbutton

The necessary Customi ing settings for integration of new subscreens in the material master are defined in transaction OMT3. )f you want to include new subscreens in an existing main or additional screen, chec# 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. )f there is no free subscreen on the screen, you must chec# whether the subscreen container can be changed 'the subscreen container contains a certain number of placeholders for subscreens to be inserted(. 0ubscreen 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. )f it is a main screen, the se!uence of main screens can be defined. )f 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. +ll others should be implemented as pushbutton. )f the call is from the Extras menu, function code ZUXX is automatically assigned to the additional screen. +s for the main screen, the se!uence in which additional screens appear in the menu can be defined. )f 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, li#e a new field. 1ushbutton function codes must start with 1, and be uni!ue. 1,HI is reserved for customer pushbuttons. The name of the pushbutton should include the string 1/0A. -or each additional screen, you should create an ;4C;7" routing, regardless of whether the screen is called as an additional screen in the se!uence or by pushbutton. The ;4C;7" routine must be implemented in the same function group. To call the ;4C;7" routine, use ,+d) method 0"T813;.3+98-;38;4C;7"83;/T6 to ma#e the name of its own program #nown to flow control for the material master. The ;4C;7" routine is assigned to the additional screen in ;9T2. -or full integration, the ;4C;7" routine includes only the chec# whether the integrated data can be maintained 'see below(.

The user can change the standard setting 'additional screen or pushbutton( at any time using ;9T2 'possibly having to define his or her own pushbutton on a customer<specific subscreen and assign the pushbutton function code to the additional screen(. The ;4C;7" routine that is assigned to the additional screen always ensures that the necessary chec# runs when the additional screen is called. )f the user does not want to see certain pushbuttons in maintenance, he

or she deletes the subscreens 'with the pushbutton( from the screen se!uence or creates his or her own subscreens without the pushbuttons. The user5s control options mean that you must not program on the function codes of additional screens or pushbuttons. "xceptionally, an additional screen can be called from both a pushbutton and the menu 'consumption values, for example(.

To chec# whether the integrated data can be maintained, a chec# module must be created. This is used in several places% =ithin the module for field selection, to decide whether to hide the new data =hen choosing the pushbutton, to decide whether to hide the pushbutton. )f the pushbutton is only visible when a specific material master table is relevant to the screen, the name of the pushbutton should begin with the name of the table 'for example, 9+3C8J981/0A(. The pushbutton is then hidden automatically when the table is not relevant. =hen choosing a menu option, to decide whether the menu option is grayed out. The call is in ,+d) method 1-80T+T/080"TF"6. )n the ;4C;7" routine of the additional screen

Partial Integration
=ith 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. /nli#e complete integration, these secondary screens are not assigned to the subscreens using ;9T2. 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 ./) status, which is different to the ./) status of the material master screens. +ccordingly, you cannot go directly to other screens of the material master from this screen. The implementation of these secondary screens is, technically spea#ing, fully encapsulated. The screen is called by the ;4C;7" routine that is assigned to the screen.

Creating a Frame
-or partial integration, as for complete integration, the screens re!uired and the functions belonging to them are developed in a separate function group. Aowever, there are no special re!uirements for this function group, unli#e complete integration.

Screen Logic

=e recommend that you #eep 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% You can use your own routines for retrieving and buffering data. Aowever, do #eep to the points in the concept described above, such as reading data once only from the database, and after that from buffers. )f accesses to material master tables are re!uired, use the function modules of the material master 'see function groups in pac#age 9.+ or 9.=, such as 9.@1 for accessing table 9+3+(. )f data is to be displayed, you will need to ta#e account of the relevant authori ations. )t is also a good idea to use your own function modules to chec# data. There are no re!uirements for function codes of secondary screens. The application determines whether a field selection is re!uired. The application also determines whether reference handling is re!uired. The application must also determine whether passing on of data 'mass maintenance( and therefore variance handling is re!uired.

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 Gperform on commitG. Aowever, we recommend in this case that you find the change by using your own function module 'CHANGE_CHECK(.

Customi,ing
The above applies to ;9T2 settings, too. Aowever, with partial integration, you can only implement an integration as its own secondary screen.

$ata Transfer - $ata $istribution

The transfer and distribution of the new material data uses +:" and the relevant )7ocs 'as of 3>2 4.0+, using ,+1)s(. The )7ocs re!uired, and the functions for creating, posting, and manual sending of )7ocs, must be created by the application. The application also has to deal with the +:" Customi ing settings re!uired 'change pointers and so on(. The seriali ation of message types by +:" ensures posting in the correct se!uence in the target system 'first the material, then dependent ob&ects(. You need to define Customi ing settings for this.

-or 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 )7ocs. This function module must be integrated in ,+d) method MG_IDOC_CREATE_FULL_MAT 'for industry( or MG_IDOC_CREATE_FULL_ART 'for 3etail(, and is called when you want to send a complete material.

eorgani,ation - $iscontinuation an! "rchi.ing# an! $eletion Flags

The reorgani ation or discontinuation of integrated data uses the relevant function modules in the reorgani ation programs of the material master. -or this, you need the following function modules for the tables you want to integrate% + chec# module for chec#ing whether the relevant data still exists for the material, and>or whether this data can be reorgani ed 'you may want to chec# for deletion flags(. This function module is called by material reorgani ation 'industry( or discontinuation 'retail(. The material can only be reorgani ed if no more dependent data exists for the material. This module is optional, and is only re!uired if you need a chec# of this sort for the ob&ect. + module for archiving the integrated data. + module for physically deleting the data.

You can use methods of ,+d) ,+7)89989+T63 for this.-or more information, see the documentation on the ,+d). )f you need your own deletion flags at integrated data level, you need to provide a function for setting deletion flags. 7eletion flags at material level are passed on to dependent ob&ects. )f you need your own deletion flags, you must ensure that either the new ob&ect is integrated in this logic of passing on deletion flags, or the chec# for deletion flags for the integrated ob&ect !ueries the deletion flags that are above it in the hierarchy. /sually, the deletion flags for the material are sufficient.

/riting an! $ispla0ing Change $ocuments

-or documenting changes to data, change documents are updated every time individual fields in a table are changed. To do this, a change document ob&ect must be created for the table. The creation of change documents is performed by the application<specific posting module, by calling the -;39 routine generated by the system. To display change documents, you need to develop a special report.