BAPI_ALM_ORDER_MAINTAIN - Process Maintenance/Service OrderFill RESBD Structure from EBP Component Structure TXBHW - Original Tax Base Amount in Local Currency
This documentation is copyright by SAP AG.
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
- User status
- Order operations
- 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
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
- FOLLOWUPHDR,,Follow-on order (reference to header), (only method CREATE)
- FOLLOWUPOPR,,Follow-on order (reference to operation), (only method CREATE)
- 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)
- 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
- ATPCHECK,,,,,,Availability check
- 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.
- 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
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:
- 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.
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:
- 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 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.
Components have an exceptional position. Components are created through the assignment to an operation, that is, using the key order/operation/(item number). However, as this is not the unique component key, you can only access the components to change them, delete them, or add long texts by using the reservation number/item, which is only given after saving. This means that, for example, you cannot create a long text when you create the component.
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
- WBS Element
- 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.
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.
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.
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.
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.
Creation of an order with operation and long text
|*||Long text for operation 10, line 1|
|*||Line 2 of the long text|
Creation of the refurbishment order header data with one serial number assigned (operation and first component are created automatically):
Creation of the refurbishment order data, changing the first operation data, adding the second operation and second component:
|0009||...||Update of 1st Operation||..|
|0020||...||New 2nd Operation||..|
Update of the data of the refurbishment order’s first component from header data (recommended):
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.
- 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.
- 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).
- User status change not possible.
- 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
- User status change not possible.
- BOM data cannot be processed.
- The delivery address cannot be processed.
See also the documentation for the individual transfer tables.
ROGBILLS - Synchronize billing plans CL_GUI_FRONTEND_SERVICES - Frontend Services
This documentation is copyright by SAP AG.
Length: 50237 Date: 20190119 Time: 235915 sap01-206 ( 170 ms )
Looking for Support? Questions?
Leave us your contact details and we will call you back. Panels marked with * are mandatory.