Definition of Characteristic Data Elements for Locations

Process Flow

You confirm that additional characteristics are really necessary. The business location is essentially a modeling mechanism. Its purpose is to bring together various objects in the SAP Oil & Gas System in order to provide a complete picture of business activity at a physical location.

As characteristics of the business location generally align to business processes, the characteristic may be better defined as a characteristic of the process-oriented object which already exists and which can be linked to the business location as a secondary depiction of the location. Characteristics of process-oriented objects may already be defined in the standard system, or it may be necessary to add them. The two examples given below are already defined in the standard system:

The cost allocation method for the location is a characteristic of cost center processing.

The capitalization date of the business location is a characteristic of asset depreciation processing.

As it is possible to link business partners to locations, it is important to distinguish between characteristics of a site and characteristics of a business partner.

A fuel operator license may be a renewable qualification of the station operator, while a fire safety certificate may be awarded by the local fire service to the site or owner of the site. Only the latter should qualify for inclusion in the business location structure.

If there is a need to create extra characteristic fields for the business location, you list the fields that are to be defined as part of the append structure.

One way of compiling the list is to consider in turn the requirements for each type of business location that you plan to define in your system. By identifying the required characteristics by location type you can save time later if you control the display of these characteristic fields via field selection, using the business location type as an influencing field (see step 4).

You create an append structure. See Creating an Append Structure for a Business Location .

You design and program the subscreens to be called by the business location transaction.

The MRN AMC (append maintenance concept) requires, through its interface with the SAP enhancement concept, that certain standards are followed with respect to the names of both include structures which are predefined in customer functions and those which are added by your user installation. The following graphic shows the basic separation.

The left-hand side of the diagram shows the elements that are provided in SAPLXOIF when it is delivered to your system. In connection with the SAP enhancement concept, various include statements are provided. These reference programs that do not exist in the initial delivery of the system. These must be created by your installation. A sample of these objects is shown on the right-hand side of the diagram. Only the objects shown on the left-hand side are delivered by SAP.

Having defined new data elements in your append structure, you should design the layout of your sub-screens to include all data elements that you wish to maintain. These screens are your dialog with the business location database table.

It may be useful to use a separate screen table structure as a screen work area.

You can create a screen structure ZXOIF or ZOIFSPBL and include in this the structure of OIFSPBL. In this case your screen painter field definitions would belong to table ZXOIF or ZXOIFSPBL and not OIFSPBL.

Your screen painter developer should follow the ergonomic screen design principles described in the SAP Style Guide. For more information, see About the SAP Style Guide .

The subscreen numbers are freely definable, but they must begin with the prefix 9 as customer objects and belong to module pool SAPLXOIF. You may define up to three subscreens for use with the MRN AMC.

When you have created your subscreens you need to program certain PBO and PAI modules. Typically, these are required to retrieve cross-reference data, for example language dependent texts for codes and validate user entry. You also need to consider basic screen management requirements, such as screen field control.

The modules should be coded in include programs that begin with Z prefixes. We recommend that you accept the proposals that are made by the ABAP Workbench, namely, ZXOIFO01 for PBO modules and ZXOIFI01 for PAI modules. Local data tables, variables and constants can either be defined in the modules, or centrally in the user data definition INCLUDE program, ZXOIFTOP.

You should code a call to the central field selection module as the first step in your subscreen PBO. In this way you can suppress input to your fields in display mode, and also control the field availability by location type. In the SAPLXOIF module pool a predefined module called AMC_SET_FIELDS is provided. This works in combination with the Screen Configuration for Business Location Master Data Screen Configuration Tool (SCT). AMC_SET_FIELDS sets all fields to display only in display mode, and influences field settings in accordance with SCT field customization in create and change modes. The MRN AMC demo screen SAPMOIFA 0195 includes a call to the module AMC_SET_FIELDS. You can copy this code to your own program, if you wish.

On the PAI side, you need to set the dataloss flag, which can be passed back to the SAPMOIFA calling program. This causes SAPMOIFA to prompt the user to save when exiting the transaction. Without it, the SAPMOIFA program does not recognize that data has changed and therefore bypasses an explicit save instruction for the user.

       5.      See Setting the Screen Call Control

       6.      See Modification and Activation of the Data Transfer Customer Functions .