Ansicht
Dokumentation

BAPI_ALM_ORDER_MAINTAIN - Process Maintenance/Service Order

rdisp/max_wprun_time - Maximum work process run time   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.

Functionality

This Business Application Programming Interface (BAPI) is used to change maintenance or service orders and their subobjects. The following objects of an order can be processed (restrictions are listed at the end of the documentation):

• Order header

• Partner

• User status

• Order operations

• Relationships

• Components

• Long texts for order header, operations, and components

• Settlement rules

• Object list

• Object list link

• Production resources/tools

• Outlines of a service package

• Services lines of a service package

• Limits of a service package

• Contract limits of a service package

• Estimated costs per value category

Function

Calling this BAPI once allows you to perform all operations. For this, the system supplies the function module with a method table containing the methods to be executed. The entries in the method table refer to data records in the (optionally filled) data tables. All the methods from the method table are executed. Alternatively, only subobjects of existing orders can be changed, without changing the header.

You can process the transferred data with the Business Add-In (BAdI) IBAPI_ALM_ORD_MODIFY to, for example, merge data from the external system with data from the SAP system. The BAdI is called as soon as the transferred data is converted to the internal formats. The checks then take place after this.

Structure of Method Table

• REFNUMBER,,Reference number for linking object method to attributes

The reference number is the line of the database that contains the corresponding data. The data table is determined by the object type.

• OBJECTTYPE,,Object type

The object type specifies which object from the order should be processed. The key words listed here are not language-dependent and must be transferred exactly as they are. The following objects exist:

• HEADER,,,,Order header

• PARTNER,,,,Partner data

• USERSTATUS,,User status

• OPERATION,,,,Operation data

• RELATION,,,,Relationships

• FOLLOWUPHDR,,Follow-on order (reference to header), (only method CREATE)

• FOLLOWUPOPR,,Follow-on order (reference to operation), (only method CREATE)

• COMPONENT,,Component

• TEXT,,,,Long texts

• SRULE,,,,Settlement rule

• OBJECTLIST,,,,Object list

• OLISTRELATION,,,,Object list link

• TASKLIST,,,,General maintenance task list

• PRT,,,,,,Production resources/tools

• SERVICEOUTLINE,,,,Service Package Outline

• SERVICELINE,,Service package service line

• SERVICELIMIT,,Service package limit

• SERVICECONTRACTLIMIT,,Service package contract limit

• ESTIMATEDCOST ,,Estimated costs per value category

• (empty),,,,,,General BAPI functions (Save)

• METHOD,,,,Method

The methods with which the data is to be processed. The following functions exist:

• CREATE,,,,,,Create objects

• CREATETONOTIF,,,,,,Create for notification

• CHANGE,,,,,,Change objects

• DELETE,,,,,,Delete objects

• RELEASE,,,,,,Release

• ATPCHECK,,,,,,Availability check

• CALCULATE,,,,,,Calculate

• SCHEDULE,,,,,,Schedule

• DELETEDSEX,,,,Delete the status for external scheduling at operation level

• ADD,,,,,,Add (only possible for object TASKLIST)

• REASSIGN,,,,,,Reassign components

• SAVE,,,,,,Save all data

• DIALOG,,,,,,Dialog call. See explanation below.

• TRACE,,,,,,Write trace file to the specified file on the front end

• DO_NOT_EXECUTE,,,,,,Do not execute

• DO_NOT_EXEC_NOTIF_CLOSE,,,,,,Do not execute and complete notifications
  Note: This also automatically completes any outstanding tasks in the notifications.

• DO_NOT_EXEC_NOTIF_DEALLOC,,,,,,Do not execute and remove assigned notifications from order
  Note: Notifications assigned to the order header are not removed, but rather automatically completed.

• CANCEL_DO_NOT_EXECUTE ,,Cancel the "Do Not Execute" status

• LOCK,,,,,,Lock

• UNLOCK,,,,,,Unlock

• TECHNICALCOMPLETE,,,,,,Technically complete

• CANCEL_TECHNICAL_COMPLETION,,,,,,Cancel technical completion

• TECO_WITH_NOTIF,,,,,,Technically complete with notifications
  Note: If a reference date is transferred, the notification with the reference date is also completed. The tasks of the notification are not automatically completed.

• CANCEL_TECO_WITH_NOTIF,,,,,,Reset technical completion and put assigned notifications in process again

• COMPLETE_BUSINESS,,,,,,Complete (business)

• CANCEL_BUSINESS_COMPLETION,,Cancel business completion

• BUS_COMPL_WITH_NOTIF,,,,,,Complete (business) with notifications

• SET_DEL_FLAG,,,,,,Set deletion flag

• RESET_DEL_FLAG,,,,,,Reset deletion flag

• SET_DLFL_WITH_NOTIF,,,,,,Also set deletion flag for assigned notifications

• RESET_DLFL_WITH_NOTIF,,,,,,Reset deletion flag and put assigned notifications in process again

Note:
Executing the following methods requires saving (method SAVE) and updating the data. It is not possible to make further changes to the order data until the update is successful:

• TECHNICALCOMPLETE

• TECO_WITH_NOTIF

• COMPLETE_BUSINESS

• BUS_COMPL_WITH_NOTIF

• SET_DEL_FLAG

• SET_DLFL_WITH_NOTIF

• OBJECTKEY,,,,SAP-external object key

This key is for assigning the lower-level objects correctly to the corresponding objects, as there is always just one key in the data table. The key must have the following structure:

• 1-12,,,,Order number

When creating orders with internal number assignment, a reference number beginning with % must be entered here. The BAPI then returns this number and the number actually assigned.

• 13-16,,Operation number

• 17-20,,Suboperation number

For relationships, the key is structured as follows:

• 1-12,,,,Order number from

• 13-16,,Operation number from

• 17-28,,Order number to

• 29-32,,Operation number to

When you create a follow-on order, the key is structured as follows:

Reference to the header of the preceding order

• 1-12 order number of the preceding order

Reference to the operation of the preceding order

• 1-12 order number of the preceding order

• 13-16 operation number of the preceding order

Data Tables and Update Tables

The objects have one or more data tables. For some objects you can specify which of the fields specified in the structure should be changed. For this, you must set the field in the corresponding table to X as in the data table. If no update table is transferred, then only those fields are set that have a value that is not initial. This simplifies the transfer data. However, this means it is not possible to delete fields. If an update structure should only be specified for some data records, the table with the update fields must nonetheless have the same number of lines as the data table. The empty lines are then treated as if no update structure was transferred. The objects "Partner", "User Status", "Text", "Estimated Costs per Value Category", and "Task List" have no update tables. The whole data record is always copied here.

References

The objects use the field REFNUMBER from the method table to refer to the lines in the data table. Counting always begins with 1. In doing this, REFNUMBER also refers to the update table. However, in the method table there is a second reference to the higher-level object for subobjects. The field OBJECTKEY must be filled with order number, operation number, and suboperation number, as specified above. If subobjects of a newly created order should be changed, then you must enter a temporary order number that must begin with %. For example, several orders may be numbered with %00000000001, %00000000002, and so on. For external number assignment, the external number must be specified.

The following objects have special handling for REFNUMBER:

• Partner

Partners have an order number in the data table. During processing of the method table, all those entries in the data table are processed that have an order number that is the same as that in the line to which the method refers. Thus, through just one entry in the method table, several partners can be changed.

• Texts

Texts are composed of two tables. The first table (IT_TEXT) is made up of the header data of the text. Here you must specify the object and the first and last line of the text table (both inclusive, counting from 1). This specifies a line segment in the text line table (IT_TEXT_LINES).

• Estimated Costs per Value Category and Settlement Rules

Depending on the order type, you can enter estimated costs per value category and settlement rules at header or operation level. Whether at header level or operation level, the data table requires the same fields to be maintained. The OBJECTKEY field in the method table needs be filled with the order number for orders without operation account assignment, and with both the order number and the operation number for orders with operation account assignment (OAA orders).

Special Features in Processing

The BAPI processes the transferred methods in a particular sequence, which need not correspond to the sequence in the methods table.

• Write trace file

• Change user status time 1

• Delete objects (dependent first)

• Create new objects

• Change existing or newly created objects

• Change user status time 2

• Status change of order

• Save data

The methods are executed such that subobjects can also be assigned to newly created objects. For example, first the operations are created, and then the components. Long texts can also be created for the objects.

You can use the REASSIGN method to reassign components and all their material data from one order operation to another. The requirement date of the material is recalculated when the components are reassigned.

For settlement rules the following account assignment types are supported:

• Cost center

• Order

• WBS Element

• Asset

• G/L account

• Sales document

User status changes can take place at two different times. Time 1 is before the object changes, time 2 is after the object changes and before the status change of the system. These times should be defined in the transfer table in the CHANGE_EVENT field. The field documentation contains the possible values.

The external scheduling is offered by the BAPI as a special function. The BAPI can set the date field directly at operation level and select the operation with the status DSEX (Date set by external system). This status prevents any further scheduling of the operation. The transferred dates are retained. For this, set the category X in the restriction categories. When reading the operation, this category is also returned, independent of the category of restriction set in the dialog. To delete the status, you can call up the method DELETEDSEX for the object operation. The external scheduling cannot be influenced in dialog. All changes to the scheduling restrictions in the dialog are saved, but they are not relevant for scheduling as long as the status DSEX is active.

A SAVE or DIALOG method must be transferred in every call of the BAPI. Usually, the BAPI call is thought of as a transaction. All data that is changed in the BAPI should also be saved immediately to the database. The BAPI checks whether a SAVE method exists. Otherwise, it terminates processing. A test run of the BAPI consists of a standard call with SAVE method, followed by a BAPI_TRANSACTION_ROLLBACK. To call the BAPI without the SAVE method, for example, to realize dialog transactions, the BAPI can be called with the DIALOG method. This switches off the check for the SAVE method. The caller must then ensure that later either a SAVE method or a BAPI_TRANSACTION_ROLLBACK is called.

A BAPI_TRANSACTION_COMMIT without SAVE method terminates processing in the update to ensure that no inconsistent data is written to the database. The caller that called the BAPI does not receive any confirmation of the termination of the update in the target system. This logic is necessary as the order data was flagged for updating with BAPI_TRANSACTION_COMMIT through the SAVE method. However, the status information was already flagged for updating when the BAPI was called. A BAPI_TRANSACTION_COMMIT without SAVE method then just saves the status information and would generate inconsistent orders, if the updating was not terminated.

The TRACE method is used to save an XML trace file on the front end under the file name specified in the OBJECTKEY field. This file can only be written if the BAPI is called from the dialog, that is, from the SAP GUI. The file is not written if background processing is used, nor is it written if the call originates in a different system. This file can be used by SAP for analysis purposes. SAP does not intend to use this data productively.

Follow-On Order

You can use BAPI_ALM_ORDER_MAINTAIN to create a maintenance order as a follow-on order of an existing order or order operation. When you create a follow-on order, you create a relationship to the reference order or operation. This relationship can be seen in the method table as follows:

• Preceding order header (object type FOLLOWUPHDR)

• Preceding order operation (object type FOLLOWUPOPR)

Only method CREATE is supported.

Creating, Changing and Deleting Additional Long Texts

You can use BAPI_ALM_ORDER_MAINTAIN to enter up to three different long texts for order operations and non-stock materials that you enter as components. You can change or delete these long texts at a later point in time. The example below shows you which entries are required.

Customer Enhancement

The BAdI IBAPI_ALM_ORD_MODIFY can be used to change the transferred data. The BAdI is called up after the conversion of the transfer structure into the structures used internally. Additional data can be transferred via table EXTENSION_IN. The data is only check after this.

Refurbishment Order

BAPI BAPI_ALM_ORDER_MAINTAIN also supports the creation and change of refurbishment orders.

Refurbishment-order-specific header data, item (component) data, and serial number data is always created and updated together with the order header data even though it is passed to the BAPI separately.

In order to support refurbishment-order-specific data, the interface of the BAPI has been enhanced by the following table parameters:

• IT_REFORDER_ITEM (BAPI_REFORDER_ITEM_I)

• IT_REFORDER_ITEM_UP (BAPI_REFORDER_ITEM_UP)

• IT_REFORDER_SERNO_OLIST_INS (BAPI_REFORDER_SERNO_OLIST_I)

• IT_REFORDER_SERNO_OLIST_DEL (BAPI_REFORDER_SERNO_OLIST_I)

Refurbishment order item data (IT_REFORDER_ITEM) is mandatory for the creation of refurbishment orders. A refurbishment order cannot be created without this data. If serial numbers are to be assigned to the refurbishment order (object HEADER, method CREATE/CHANGE), they must also be passed using the parameter IT_REFORDER_SERNO_OLIST_INS. If a serial number is to be unassigned from the order during an update of the order (object HEADER, method CHANGE), the parameter IT_REFORDER_SERNO_OLIST_DEL must be passed to the BAPI. Only existing serial numbers can be assigned to the refurbishment order.

Refurbishment-order-specific parameters are always processed together with the order header data. This means that if the refurbishment order is created or updated, the order header data structures must be provided by the calling application. Even if the header data itself must not be updated, at least the order number of the refurbishment order being updated must be provided in the order header structures:

• IT_HEADER (BAPI_ALM_ORDER_HEADERS_I)

• IT_HEADER_UP (BAPI_ALM_ORDER_HEADERS_I_UP)

In all cases, the update and creation of the data of the first component in the refurbishment order (the refurbishment order item), as well as the assignment and deassignment of serial numbers, is triggered by providing the HEADER object with the corresponding method CREATE or CHANGE in the method table

The HEADER object for a refurbishment order is also responsible for creating and updating the refurbishment-order-specific data, for example, plant from/to; storage location from/to, batch from/to, valuation type from/to). There may be several serial numbers assigned to a single refurbishment order, so the parameter table must always contain the order number to which the serial number is assigned.

The data of the first component (refurbishment order item) is always created with the order header data. In order to be able to create this data, the HEADER function must be specified in the method table.

The data of the first component can be updated either with the header data (object HEADER, method CHANGE) or separately by specifying the function component update (object COMPONENT, method CHANGE) in the method table. If the data of the first component is updated with the order header data, then the structures for the header data must also be passed to the BAPI interface (the order number at least must be specified). If both methods of updating the component data are used simultaneously in the method table, then the refurbishment order item data is updated with the header data.

When the refurbishment order is created, the first operation is generated automatically. If this generated data needs to be changed, an update must be triggered in the method table. The first operation must be generated for refurbishment orders (unlike standard orders) in order to make it possible to create the data of the first component with the refurbishment order header data.

The BAdI BADI_REFORDER_BAPI_MESG allows the user to suppress some messages that are raised during the creation or update of a refurbishment order. These messages are shown as warning messages when the back-end transaction is executed, so this BAdI provides the user with the flexibility to control the message type of these messages in the BAPI.

• The first operation cannot be created as an external operation.

• The first refurbishment order operation must not be created manually by passing the relevant data through the method table.

• When more than one order is processed at once, the same serial number must not be assigned to several orders.

• The same serial number can be assigned to another order only if the first order has been successfully committed to the database table.

• Only existing serial numbers can be assigned to the refurbishment order.

• The first generated refurbishment order component cannot be updated within the execution of the same BAPI call.

• Executing the methods TECHNICALCOMPLETE, COMPLETE_BUSINESS, and SET_DEL_FLAG requires saving (method SAVE) and updating the data. It is not possible to make further changes to the order data until the update is successful.

• An order can be created from a notification using the CREATETONOTIF method for the object type HEADER.

• A notification can be created for the order.

• The notification type has to passed within the parameter IT_HEADER (BAPI_ALM_ORDER_HEADER_I-NOTIF_TYPE)

• A notification can be separated from the order.

• The notification type (NOTIF_TYPE) must be empty in the IT_HEADER, and the corresponding update flag (NOTIF_TYPE) must be set in the update parameter IT_HEADER_UP.

• An object list can be maintained for the refurbishment order.

• DIMP-specific fields can be maintained at the header level:

• Special stock is determined automatically from the equipment or material/serial number stock data if the refurbishment order is being created for a piece of equipment (BAPI_ALM_ORDER_HEADER_I-EQUIPMENT) or a material/serial number (BAPI_ALM_ORDER_HEADER_I-SERIALNO and BAPI_ALM_ORDER_HEADER_I-MATERIAL have to be specified in table IT_HEADER)

• Sales order, sales item (BAPI_ALM_ORDER_HEADER_I-SALES_ORD and BAPI_ALM_ORDER_HEADER_I-S_ORD_ITEM must be specified in the table IT_HEADER)

• DIMP-specific fields can be changed at the component level. In particular, the special stock indicator can be set for the component.

Example

The following examples illustrate usage:

Creation of an order

OBJECTKEY should be filled with a temporary key. The BAPI returns this key together with the assigned order number in the return table ET_NUMBERS. The order number in the HEADER table should also be filled with the number. For external number assignment, the external number should be specified. The update structure can be transferred if necessary.

Methods table

REFNUMBER	OBJECTTYPE	METHOD	OBJECTKEY
1	HEADER	CREATE	%00000000001

IT_HEADER

ORDERID	ORDER_TYPE	PLANPLANT	...
%00000000001	PM01	1000	...

Creation of an order with operation and long text

Methods table

REFNUMBER	OBJECTTYPE	METHOD	OBJECTKEY
1	HEADER	CREATE	%00000000001
1	OPERATION	CREATE	%00000000001
1	TEXT	CREATE	%000000000010010

IT_HEADER

ORDERID	ORDER_TYPE	PLANPLANT	...
%00000000001	PM01	1000	...

IT_OPERATION

ACTIVITY	SUB_ACTIVITY	CONTROL_KEY	WRK_CNTR	...
10		PM01	MECHANIK	...

IT_TEXT

ACTIVITY	...	TEXTSTART	TEXTEND
10	...	1	2

IT_TEXT_LINES

TDFORMAT	TDLINE
*	Long text for operation 10, line 1
*	Line 2 of the long text

Creating, Changing and Deleting Additional Long Texts

Methods table

REFNUMBER	OBJECTTYPE	METHOD	OBJECTKEY
1	TEXT	CREATE/CHANGE/DELETE	%000004094011
2	TEXT	CREATE/CHANGE/DELETE	%000004094011

IT_TEXT_LINES

TDFORMAT	TDLINE
*	Additional long text AVON
*	Assigned order operation 20
*	Additional long text AVOD
*	Assigned order operation 20
*	Additional long text AVOC
*	Assigned order operation 20
*	Additional long text MATN
*	Assigned order operation 20
*	Additional long text MATD
*	Assigned order operation 20
*	Additional long text MATC
*	Assigned order operation 20

NOTE: In the case of DELETE, the TDFORMAT and TDLINE fields have to be empty.

IT_ADDITIONAL_TEXT

ORDERID	RESERV_NO	RES_ITEM	TEXT_START	TEXT_END	TEXT_ID	LOOP_INDEX
000004094011		000000001	000000002	AVON	1
000004094011		000000003	000000004	AVOD	1
000004094011		000000005	000000006	AVOC	1
000004094011	0004426141	0015	000000007	000000008	MATN	2
000004094011	0004426141	0015	000000009	0000000010	MATD	2
000004094011	0004426141	0015	0000000011	0000000012	MATC	2

Enter the value "0020" in the ACTIVITY field.

Creation of the refurbishment order header data with one serial number assigned (operation and first component are created automatically):

Methods table

REFNUMBER	OBJECTTYPE	METHOD	OBJECTKEY
1	HEADER	CREATE	%00000000001
1		SAVE

IT_HEADER

ORDERID	ORDER_TYPE	PLANPLANT	...
%00000000001	PM04	0001	...

IT_REFORDER_ITEM

ORDERID	REQUIREMENT_QUANTITY	PLANT_TO	PLANT_FROM	...
%00000000001	3	0001	0002	...

IT_ REFORDER_SERNO_OLIST_INS

ORDERID	SERIALNO	UII
%00000000001	SN01

Creation of the refurbishment order data, changing the first operation data, adding the second operation and second component:

Methods table

REFNUMBER	OBJECTTYPE	METHOD	OBJECTKEY
1	HEADER	CREATE	%00000000001
1	OPERATION	CHANGE	%000000000010010
2	OPERATION	CREATE	%00000000001
1	COMPONENT	CREATE	%00000000001
1		SAVE

IT_HEADER

ORDERID	ORDER_TYPE	PLANPLANT	...
%00000000001	PM04	0001	...

IT_REFORDER_ITEM

ORDERID	REQUIREMENT_QUANTITY	PLANT_TO	PLANT_FROM	...
%00000000001	3	0001	0002	...

IT_OPERATION

ACTIVITY	SUB_ACTIVITY	...	DESCRIPTION	..
0009		...	Update of 1st Operation	..
0020		...	New 2nd Operation	..

IT_OPERATION_UP

ACTIVITY	SUB_ACTIVITY	...	DESCRIPTION	..
X		...	X	..

IT_COMPONENT

RESERV_NO	RES_ITEM	PLANT	MATERIAL	...
	0001	MN_01	...

Update of the data of the refurbishment order’s first component from header data (recommended):

Methods table

REFNUMBER	OBJECTTYPE	METHOD	OBJECTKEY
1	HEADER	CHANGE	000004000001
1		SAVE

IT_HEADER

ORDERID	ORDER_TYPE	PLANPLANT	...
000004000001		...

IT_HEADER_UP

ORDERID	ORDER_TYPE	PLANPLANT	...
000004000001		...

IT_REFORDER_ITEM

ORDERID	REQUIREMENT_QUANTITY	PLANT_TO	PLANT_FROM	...
000004000001	6	9999		...

IT_REFORDER_ITEM_UP

ORDERID	REQUIREMENT_QUANTITY	PLANT_TO	PLANT_FROM	...
000004000001	X	X		...

IT_REFORDER_SERNO_OLIST_DEL

ORDERID	SERIALNO	UII
000004000001	SN01

Notes

Using the BAPI to process the order data cannot support all the functions of the transaction. This applies in particular to the following functions:

Order header data

• Notification data cannot be processed with the order BAPI, even if the settings in Customizing are such that the orders and notifications can be maintained on one screen. However, the system will create a notification with the order if this is specified in the Customizing settings.

• Permits cannot be processed.

• The order addresses cannot be processed.

• Individual partner addresses cannot be maintained.

Order functions

• Printing the papers is not possible.

• Locking and unlocking the order is not possible.

• Accepting and rejecting quotations is not possible.

• The log cannot be displayed.

• User default values are not used.

• The field selection is not checked.

• The customer exits/BAdIs are not executed completely.

• Funds management is not supported.

• Investment orders are not supported.

• No integration of service products with task lists is possible if configuration data has to be maintained.

• No integration of configurable service products is possible if configuration data has to be manually maintained.

• Assignment of sales document items with service products in accordance with the aforementioned conditions.

Operation data

• A change of the control key in the operation is not possible, if this leads to a change of the processing type (internal/external processing).

• Production resources and tools cannot be processed.

• Integration of task lists with configurations is not supported, since manual maintenance of the characteristic valuations would be performed in the dialog.

• Automatic linking of operations with object list is not supported. If a new operation is to be generated for a new object list entry, you must do this by creating a new operation in the corresponding BAPI method and linking to the object list entry using the object OLISTRELATION.

• Note that services with the following object types cannot be used with the DIALOG method, but only with the SAVE method:

• SERVICEOUTLINE - Service package outline

• SERVICELINE - Service package service line

• SERVICELIMIT - Service package limit

• SERVICECONTRACTLIMIT - Service package contract limit
  

Component data

• User status change not possible.

• BOM data cannot be processed.

• The delivery address cannot be processed.

Further information

See also the documentation for the individual transfer tables.

Parameters

ET_NOTIFICATION_NUMBERS
ET_NUMBERS
EXTENSION_IN
IT_ADDITIONAL_TEXT
IT_COMPONENT
IT_COMPONENT_UP
IT_ESTIMATED_COSTS
IT_HEADER
IT_HEADER_JVA
IT_HEADER_JVA_UP
IT_HEADER_SRV
IT_HEADER_SRV_UP
IT_HEADER_UP
IT_METHODS
IT_OBJECTLIST
IT_OBJECTLIST_UP
IT_OLIST_RELATION
IT_OPERATION
IT_OPERATION_UP
IT_PARTNER
IT_PARTNER_UP
IT_PERMIT
IT_PERMIT_ISSUE
IT_PERMIT_UP
IT_PRT
IT_PRT_UP
IT_REFORDER_ITEM
IT_REFORDER_ITEM_UP
IT_REFORDER_OPERATION
IT_REFORDER_SERNO_OLIST_DEL
IT_REFORDER_SERNO_OLIST_INS
IT_RELATION
IT_RELATION_UP
IT_SERVICECONTRACTLIMITS
IT_SERVICECONTRACTLIMITS_UP
IT_SERVICELIMIT
IT_SERVICELIMIT_UP
IT_SERVICELINES
IT_SERVICELINES_UP
IT_SERVICEOUTLINE
IT_SERVICEOUTLINE_UP
IT_SRULE
IT_SRULE_UP
IT_TASKLISTS
IT_TEXT
IT_TEXT_LINES
IT_USERSTATUS
IV_MMSRV_EXTERNAL_MAINTENACE
RETURN

Exceptions

Function Group

IBAPI_ALM_ORDER

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   General Data in Customer Master  
This documentation is copyright by SAP AG.

Length: 54143 Date: 20240426 Time: 033723     sap01-206 ( 504 ms )