Create maintenance plan from a template or a copy model

[former_member222320]

Dear all

When I create a example, an inspection plan; I can use a copy model and bring some of these features to my new plan. The same for a project. I can use an old project to build a new one in the project builder. However, when I want to create a manitenance plan, I do not have this feature.

It is very cumbersome to create a brand new maintenance plan from scratch, when I can reuse another plan and just change something from it. How can I do to create a maintenance plan using another one as template?

Thank you for any input.

M.

[paul_meehan · Accepted solution]

Hi,

You could use MPLAN_CREATE_WITH_TEMPLATE to create your own solution. See note 1680169 about maintenance plan API's.

-Paul

[sebastian_lenartowicz · Accepted solution]

Greetings Paul - interesting - but it seems one needs to ask for the document to be released to take advantage of this possibility...?

[paul_meehan · Accepted solution]

Yes, just noticed it is released internally. Following is a text copy:

1680169 - FAQ/explanations: Maintenance plan APIs

--------------------------------------------------------------------------------

Symptom
This SAP Note provides important information about frequently asked questions and answers about the application programming interfaces (APIs) in the maintenance plan environment.

Information about maintenance plan APIs:
           The methods and function modules of the same name function identically. You can use the respective function module instead of the method to enable an RFC access.
           All the functions that change data have to be completed with the explicit call of COMMIT_WORK to make sure that the data is written to the database. To do this, you can, for example, carry out the function module BAPI_TRANSACTION_COMMIT. You can also update several successive changes to the API using a COMMIT_WORK.
           Errors are returned in the return table RETURN. Processing terminates with the first error. The system does not report follow-on errors.
           The data is buffered internally during reading to avoid multiple database accesses.

Exceptions:
           When processing the maintenance plans using the API, not all the functions of the transaction are supported. This applies in particular to the following functions when creating and changing maintenance plans:

Maintenance plans for service procurement
Maintenance plans for service order with outline agreement
Edit settlement rule
Edit individual location and account assignment data at item level
Edit object list at item level
The customer enhancements using customer exits are not considered. However, you can call the exits using an example implementation of the BAdIs that are created in the API. Details are documented in the respective functions.

Important:
Transaction IP10 updates the calls when starting. For example, the system checks for existing calls if the time horizon has been reached, and the calls are set from waiting to ready for call. The scheduling functions do not carry this out implicitly. To work with the updated maintenance plan data, you can call the function MPLAN_UPDATE_SCHEDULING before you call the function you actually want.

Solution

MPLAN_ACTIVATE, MPLAN_DEACTIVATE
           By specifying the maintenance plan number, the status of the maintenance plan is set to active or inactive.
          

MPLAN_BUFFER_CLEAR
           All the buffers that are read by APIs are deleted here. Changed or created data that have not yet been saved to the database are not taken into account here, and are therefore not deleted. When a maintenance plan is deleted, the dependent items are not by default deleted with it. However, this can also be achieved using the parameter WITH_ITEMS.
          

MPLAN_CHANGE
           This API changes the data for the maintenance plan in storage, and the changed data is then written to the database after a COMMIT WORK.
           Only for the fields that have an X in the update structures, the corresponding data field is changed. If no UPDATE structure is transferred, the X is set in the update structure for all the fields that do not have the initial value.
           The following exceptions apply:

The object list cannot be changed.
Individual location and account assignment data cannot be changed. This is copied from the corresponding reference object.
When changing the fields HORIZ, HORIZ_DAYS, and HORIZ_QUALIFIER, it is possible to update all three fields, even if the fields have only two update flags.
                    Example:
                    You want to change a maintenance plan with a 70% call horizon to a seven DAY call horizon. To do this, you specify the following values in the API interface:

HEADER-HORIZ_DAYS  = 7
HEADER-HORIZ_QUALIFIER  = DAY
HEADER_UPDATE-HORIZ_DAYS  = X
HEADER_UPDATE-HORIZ_QUALIFIER  = X

                    However, in the database (table MPLA), three fields are adjusted as follows:

Old New
HORIZ 70 
HORIZ_DAYS  7
HORIZ_QUALIFIER % DAY

                    You can find information with regard to the function of the call horizon in days in the long text of error message MPLAN550.

MPLAN_SET_DELETION_INDICATOR, MPLAN_CLEAR_DELETION_INDICATOR
           By specifying a maintenance plan number, the deletion flag of the maintenance plan is set or removed.
          

MPLAN_COMPLETE_CALL
           This function sets a call of the maintenance plan to completed. The fields MHIS-LRMDT, MHIO-ADDAT, and MHIO-ADTIME are set to the completion date.
           If you have not specified any values for the parameters LRMDT (date of the last completion - for time-dependent maintenance plans), RZAEH (completion counter reading - for performance-related maintenance plans), and ZEIEH (unit for the performance of maintenance tasks - for performance-related maintenance plans), the system determines default values in accordance with transaction IP10. If you specified values, these are valid.
          

MPLAN_CREATE
           This API creates a maintenance plan in storage, and the data is then written to the database after a COMMIT WORK. During the creation of maintenance plans the system also creates maintenance items that are also transferred.
           The following exceptions apply:

The object list cannot be added.
Individual location and account assignment data cannot be added. These are copied from the corresponding reference object.
When changing the fields HORIZ, HORIZ_DAYS, and HORIZ_QUALIFIER, it is possible to fill all three fields even if only two fields are filled in the interface.
                    Example:
                    You want to create a maintenance plan with a seven day call horizon. To do this you specify the following values in the API interface:

HEADER-HORIZ_DAYS  = 7
HEADER-HORIZ_QUALIFIER  = DAY

                    However, in the database (table MPLA), three fields are adjusted as follows:

HEADER-HORIZ  = 100
HEADER-HORIZ_DAYS  = 7
HEADER-HORIZ_QUALIFIER  = DAY

                    You can find information with regard to the function of the call horizon in days in the long text of error message MPLAN550.

In the case of a strategy plan, it is always the scheduling parameters that are copied from the strategy. If you do not want this, you have to call the API MPLAN_CHANGE again with the respective update structure.

           Unique features in processing:

The subobjects (maintenance item and maintenance cycle) have a field called ACTION. You have to fill this field with 'A' to add the objects.
If you maintain long texts, it is important that you specify a temporary number in the form %000000000000001 for the maintenance items to enable long text assignment to the correct item.
If you specify an existing item number, the system assigns the existing maintenance item and it does not create a new  maintenance item. The item data is ignored and the item is assigned as it is.
           Customer enhancement:

You can use the Business Add-In (BAdI) MPLAN_BADI_HEADER_SAVE to check the transferred data, and to prevent the update. Using an example implementation, the BAdI can also call the customer exit EXIT_SAPLIWP3_004.
Additional data can be transferred at item level using the customer include CI_MPOS. It is automatically written to the database.
          

MPLAN_CREATE_WITH_TEMPLATE
           This API creates a maintenance plan with template in storage, and the data is then written to the database after a COMMIT WORK. To create a maintenance plan, only the data has to be transferred that should be different from the maintenance plan that is specified as template.
           The following exceptions apply:

The object list cannot be added.
Individual location and account assignment data cannot be added. These are copied from the corresponding reference object.
When changing the fields HORIZ, HORIZ_DAYS, and HORIZ_QUALIFIER, it is possible to fill all three fields even if only two fields are filled in the interface.
                    Example:
                    You want to create a maintenance plan with a seven day call horizon. To do this you specify the following values in the API interface:

HEADER-HORIZ_DAYS  = 7
HEADER-HORIZ_QUALIFIER  = DAY

                    However, in the database (table MPLA), three fields are adjusted as follows:

HEADER-HORIZ  = 100
HEADER-HORIZ_DAYS  = 7
HEADER-HORIZ_QUALIFIER  = DAY

                    You can find information with regard to the function of the call horizon in days in the long text of error message MPLAN550.

           Unique features in processing:

The same unique features as for changing a maintenance plan apply. However, as the changes are made to the data before creation, there are no restrictions that have to be taken into account for a change. This means that you can, for example, change the maintenance plan category.
Identification of the maintenance cycles and maintenance items for change and deletion is carried out using the object numbers in the template. For adding maintenance cycles and maintenance items, no numbers have to be specified.
          

MPLAN_FIX_CALL
           This function fixes the call. The field MHIS-NPLDA is set to the next planned date. The fields MHIO-TSTAT and MHIS-TSTAT are set to F.
           If you did not specify a value for the parameter NPLDA (next planned date), the system determines a default value in accordance with transaction IP10. If you specified a value, this is valid.
          

MPLAN_GETLIST
           List selection of maintenance plan numbers. You can select maintenance plans using selection criteria.
           The transferred parameter values and selection options are used to call the list report RIMPLA00 from transaction IP16. The selection screen defines which parameters and selection options are possible. If the optional parameter TEMPLATE is transferred, the API returns a list of the selection options there.
           As a result, only the maintenance plan numbers are returned.
          

MPLAN_ITEM_CHANGE
           With this API you can change maintenance items.
           Unique features in processing:

The optional ITEM_UPDATE structure contains the key and fields of the type BAPIUPDATE. You have to fill the fields with X to change the respective data field. If no UPDATE structure is transferred, all the fields that do not have the initial value are set. A unique feature is the customer include CI_MPOS_UPDATE that you have to create in accordance with the customer include CI_MPOS to change the fields of the customer include.
Existing long texts are always overwritten completely with the transferred long texts. To delete a long text, you have to transfer a line that is completely empty to the respective key.
By deleting or filling the maintenance plan number you can remove the assignment of a maintenance item to a maintenance plan, or you can assign a maintenance item to a maintenance plan.
           Customer enhancement:

Additional data can be transferred at item level using the customer include CI_MPOS. It is written to the database in accordance with the customer include CI_MPOS_UPDATE.
          

MPLAN_ITEM_CREATE
           With this API you can create maintenance items.
           Unique features in processing:

You cannot assign the maintenance item to a maintenance plan. You can use the method MPLAN_ITEM_CHANGE or MPLAN_CHANGE to do this.
           Customer enhancement:

Additional data can be transferred at maintenance item level using the customer include CI_MPOS. It is automatically written to the database.
          

MPLAN_ITEM_GETLIST
           List selection of maintenance item numbers. You can select maintenance items using selection criteria.
           The transferred parameter values and selection options are used to call the list report RIMPOS00 from transaction IP18. The selection screen defines which parameters and selection options are possible. If the optional parameter TEMPLATE is transferred, the API returns a list of the selection options there.
           As a result, only the maintenance item numbers and the corresponding maintenance plan numbers are returned.
          

MPLAN_ITEM_READ
           The specified maintenance item is read (regardless if it is still in the buffer or already in the database). You have the option to lock the maintenance item, for example, if you want to make subsequent changes.
           Unique features in processing:

The data of the maintenance items that are read is buffered internally. If you changed data between two calls of the API in the database, you have to delete the buffer for this entry before reading, using the function module MPLAN_BUFFER_CLEAR, to read the current data. If you make changes using the API, this is not required.
          

MPLAN_MANUAL_CALL
           This function generates a manual call. The manual call occurs in a different number range that starts at 90.000.000.
           A manual call with a date that lies in the past is not possible. The field MHIS-MANDA is set accordingly. MHIS_TERMA is set to M, MHIS-TSABR to X.
           If you did not specify a value for the parameter MANDA (Manual call date), the system determines a default value in accordance with transaction IP10. If you specified a value, this is valid.
           The parameter ZAEHL stands for the selection of the maintenance package, for example, package 1 = > ZAEHL= 01, package 2 => ZAEHL=02, and so on.
          

MPLAN_READ
           The specified maintenance plan is read (regardless if it is still in the buffer or already in the database). You have the option to lock the maintenance plan, for example, if you want to make subsequent changes.
           Unique features in processing:

If you set the optional parameter WITH_HISTORY to <space>, the system does not read history or call data. This can reduce runtime and memory consumption.
The data of the maintenance plans that are read is buffered internally. If you changed data between two calls of the API in the database, you have to delete the buffer for this entry before reading, using the function module MPLAN_BUFFER_CLEAR, to read the current data. If you make changes using the API, this is not required.
          

MPLAN_READ_MULTIPLE
           Reading several maintenance plans to the buffer. The maintenance plans that are specified in the table are read. Only the header data is returned directly, and the other data is read to the buffer. A subsequent call of MPLAN_READ delivers the read detail data from the buffer without having to access the database again.
           Unique features in processing:

If the maximum buffer size is smaller than the number of maintenance items that are transferred plus their items, the data is not buffered and has to be read again. It is important that you avoid this because otherwise, performance will be worse than for individual reading. Take into account that the maintenance items also require an entry in the buffer.
          

MPLAN_RELEASE_CALL
           This function releases the call. The fields MHIS-TSTAT, MHIO-TSTAT, MHIS-TSVBT, MHIS-TSENQ, and MHIO-TSENQ are initialized.
           Using the  import parameter NO_COMMIT, you can control if the COMMIT WORK should be made directly in the API or externally. For example, this is required if you want to update several instructions with the API.
          

MPLAN_RESTART
           This function restarts the scheduling. The start date or the start counter is set, and this generates a call.
           This function is possible only if there was already a call. All existing calls with status waiting are deleted (default). If the calls are required for the history, you can keep them (Keep waiting calls (KEEP=X) or delete waiting calls (KEEP=' ')).
           If you have not specified any values for the parameters STADT (Start date - for time-dependent maintenance plans), or SZAEH (Start counter reading - for performance-related maintenance plans), the system determines default values in accordance with transaction IP10. If you specified values, these are valid.
          

MPLAN_SET_BUFFERSIZE
           Determines the buffer size.
          

MPLAN_SKIP_CALL
           This function skips a call. This is possible only if the call has the status waiting or fixed. This function sets the status to skipped.

The fields MHIS-TSABR, MHIO-TSTAT, and MHIS-TSTAT are set to X to show that the call was skipped.
The fields MHIS-TSVBT, MHIO-TSENQ, and MHIS-TSENQ are initialized to show that the call is no longer set to waiting.
          

MPLAN_START
           This function starts the scheduling. The start date or the start counter is set, and this generates a call. This function is possible only if there was no call yet.
           All existing calls with status waiting are deleted (default). If the calls are required for the history, you can keep them (Keep waiting calls (KEEP=X) or delete waiting calls (KEEP=' ')).
           If you have not specified any values for the parameters STADT (Start date - for time-dependent maintenance plans), or SZAEH (Start counter reading - for performance-related maintenance plans), the system determines default values in accordance with transaction IP10. If you specified values, these are valid.
          

MPLAN_START_CYCLE
           This function starts the scheduling of the maintenance plan in the cycle. This is also possible if the plan was already started, that is, if it has already calls. This function can be carried out only for strategy plans and enhanced multiple counter plans (T399J-MCP_EXT = 'X'). In transaction IP10, the start in cycle pushbutton is deactivated for single counter plans.
           All existing calls with status waiting are deleted (default). If the calls are required for the history, you can keep them (Keep waiting calls (KEEP=X) or delete waiting calls (KEEP=' ')).
           The following parameters are used:

Enhanced multiple counter plans:
LRMDT  Date of the last completion in the maintenance plan
CONF_TIME  Completion time of the call
CYCLESEQIND  Cycle set sequence
SETREPEATIND  Frequency of use for cycle set sequence

Strategy plans with time-related strategy:
LRMDT  Date of the last completion in the maintenance plan
CONF_TIME  Completion time of the call
ZYKLOFFSET  Offset during start in the cycle
ZYKLUNIT Unit for the performance of maintenance tasks

Performance-related strategy plans:
ZYKLOFFSET Offset during start in the cycle
ZYKLUNIT  Unit for the performance of maintenance tasks
RZAEH Completion counter reading

           If you have not specified any values for these parameters, the system determines default values if possible - in accordance with transaction IP10. If you specified values, these are valid.
           Using the  import parameter NO_COMMIT, you can control if the COMMIT WORK should be made directly in the API or externally. For example, this is required if you want to update several instructions with the API.
          

MPLAN_UPDATE_SCHEDULING
           This function carries out a new scheduling, and it may generate a call in accordance with MPLAN_MANUAL_CALL and MPLAN_RELEASE_CALL. It is made sure that there is always an open call with the status waiting or fixed.
           Using the  import parameter NO_COMMIT, you can control if the COMMIT WORK should be made directly in the API or externally. For example, this is required if you want to update several instructions with the API.

[former_member222320 · Accepted solution]

Thank you for your replies. Both very useful. It is rare that a function to create a maintenance plan using another one as template is not available, right?

[Former Member · Accepted solution]

HI,

I want to populate Maintenance Plan item's Object List. Is there any Bapi in which I can pass Object List items and populate it in background.

Thanks in advance.

Cheers,
Nainesh

[sebastian_lenartowicz]

Greetings Maria,

There is a program called MPLAN_TEST_COPY_AND_CHECK, you could try this out - but I don't know just how well tested is this.

When I require multiple copies of a Plan to be created (e.g. for multuiple technical units with different FLs), I tend to use LSMW. Most of the fields come from master data, or Strategy, and Task Lists can be oft reused.

Or, there are third-party solutions to that such as Prometheus' Maintenance Plan Manager

Preventive Maintenance Management | Prometheus Group