Maintenance objects can now been deassigned from specific models (planning versions) even if there is transaction data. In earlier releases, if transaction data existed for a model, you were not allowed to deassign the maintenance object from the model; this would result in a warning message.

When you now deassign maintenance objects from a model in MSP, the system searches for transaction data in the relevant model. Deassignment is carried out only if you choose to delete transaction data from the model.

When the technical object structure is updated, whether from IE4N, IE01/IE02, IL01/IL02, or Enterprise Services, the relevant maintenance objects in MSP are now automatically updated as well. This can be carried out through a batch job.

Previously, when components were removed or installed in SAP ERP, for example, MSP did not immediately recognize this and you had to remember to go to the maintenance object transaction and save the object.

The SAP APO system now transfers independent slots within the planning horizon to SAP ERP as revisions. Independent slots within the planning horizon are now flagged to indicate such a transfer. A configuration table in SAP ERP Customizing defines what revision type to create.

One-time demands within the planning horizon are transferred to SAP ERP as notifications. If that notification already exists in SAP ERP, you can link it to the one-time demand in MSP.

MSP can now be used to create revisions with different revision types through the configuration table. A Customizing setting is provided for this purpose. Previously, only one revision type was available.

MSP now allows the modeling of SAP ERP objects with local intervals and local average performances.

You can now specify a profile - /SAPAPO/MSP_CRFP - that links mechanics to service areas within the same location. The automated planning run chooses the mechanics and service area based on the relationship mentioned in the profile. For example, service area Hangar H1 in Location L1 uses check resource Mechanic M1. If the hangar is changed from H1 to H2 in the same location, the check resource is changed to M2, which belongs to Hangar H2.

When higher level checks are performed, the cycle for lower level checks is now reset. Resetting checks involves the resetting of cycles of lower level checks that coincide with a higher level check based on a resetting profile (/SAPAPO/MSP_RESTPROF) you maintain.

Compliance date calculation is based on multiple references. Higher level checks are taken into account in the calculation of due dates for lower level checks.