Planning Options in Organizational Management

Plan versions allow you to depict and manage several organizational plans in the system at the same time. You can use plan versions to simulate and compare various scenarios. However, only one plan version can be integrated. This plan version represents the valid organizational plan, and is flagged as the active or integrated plan version.

You must define the active plan version when you integrate the SAP system.

As a rule, you cannot change the active plan version at a later date. If integration is active, the plan version you select here as active is the integrated plan version, regardless of the system. In the parameter group PLOGI PLOGI, enter the plan version that is to be the active plan version in the Semantic Abbreviation Value field. Once you designate a plan version such as 01 as the active plan version, as a rule it should always be 01. You can update it directly in production or make copies of it to complete various plan scenarios. For example you might copy 01 to 10, 11 and 12. The best case scenario is represented by 10, 11 represents the worst case, and 12 represents an average case scenario. Once the new version is selected, it is copied back into plan version 01 with an effective date. Plan version 01 should always be the active plan version once it is set up that way.

Plan versions exist independently of each other. They can be created as copies of the original plan in statements by using report RHCOPL00 Copy Plan Version. You can change this copy independently of the valid plan. While this option is advantageous,  it means that handling plan versions is more complicated.

After the copy is created, both plan versions develop independently of one another. Consequently, the best copy is out-of-date after a matter of hours or days.

Report RHCOPLPT Reconcile Plan Version supports you when transferring data from an inactive plan version to the active and integrated plan version. However, this report is not able to update personal data in infotype 0001. This can lead to inconsistencies in the integration between Personnel Administration (PA) and Personnel Planning (see SAP Note 354019).

The current plan version is the plan version that you are currently working on in the system. You can use the OM_FRAM_PLVAR_DISP switch in the user profile to display the active plan version on the Change Organization and Staffing interface.

Infotype records can go through a planning cycle during which they must be accepted or rejected. A plan status is assigned to each infotype record.

Objects can be created in either planned or active status.

You must assign a status for every infotype record you create. You do not, however, have to use all the statuses. Many companies only use the active  status.

You cannot use plan statuses with all interfaces. Plan statuses are primarily intended for use with the approval procedure in workflow.

The majority of maintenance interfaces can create and maintain only infotype records with the active status.

The report RHAKTI00 allows you to change the status of several objects at the same time.

You can specify whether number assignment is specific to the plan version or whether it applies to all plan versions. If you decide to use plan version-specific number assignment, you can define number intervals for each plan version and object type.

For example, subgroup 10S represents the number assignment for object type S in plan version 10.

If you decide to use number assignment for all plan versions, you can define number intervals per object type that are valid for all plan versions in the Maintain Number Ranges step.

For example, subgroup $$O represents the number assignment for object type O in all plan versions.

Number assignment for all plan versions has the advantage that objects will not be overwritten when they are copied from one plan version to another.

The subgroup names are set up so that the first two characters specify the plan version and the last two specify the object type. The standard entry $$$$ in the Subgroup field stands for all number ranges that are not listed explicitly. This entry must not be deleted. You can differentiate between external and internal number assignment in each subgroup.

When an object is created, an object ID must be assigned to it. The object is identified by a combination of plan version, object type, and object ID. Object IDs are numeric. They cannot contain any letters.

You maintain number ranges for object IDs in Customizing.

You can easily search for objects by using search terms, parts of a term, and certain characteristics. It is recommended that you use  internal number assignment, because you do not need the object ID to search for objects.

Each infotype record uses a start date and an end date to specify the validity period for the infotype data. You must assign a validity period to every infotype record you create. When you assign the validity period, you can depict all the changes that take place in your company, and get a dynamic view of your enterprise.

The validity period enables you to evaluate key data or periods in the past, present, or future. The validity of an object’s relationships and attributes can exist only within the life span of the object defined in the Object infotype.

If an object is delimited, all the object’s relationships and characteristics are also automatically delimited. Related objects are not changed. However, a relationship is valid only if both objects are valid.

Time constraints are used internally by the system to guarantee the integrity of data. You use time constraints to control system reactions according to company-specific requirements. For example, if you want to let positions report to a number of supervisors, you can set up a time constraint to allow several relationships to exist.

In addition to this type of inheritance, other infotypes can be inherited.

Change documents can be generated for Personal Development infotypes. They enable you to track changes made to individual infotypes.

Change documents for Personnel Planning infotypes are based on the SAP Change Document solution (transaction SCDO) and change document objects. Application development can create change documents. The change documents  represent the application objects in HR Change Documents. You can assign database tables to each change document object and changes made to the data are logged by using the change document object. You must enter the infotypes for which you want to activate the creation of change documents in table T77CDOC (Management of Change Doc. Object Class for Infotypes).

The SAP system includes standard implementations for creating change documents for Personnel Planning infotypes. In the case of standard implementations, infotypes are already connected to HR Change Documents. No additional infotype-specific source code is required.

In the Customizing table T77CDOC_CUST (Activate HR Change Documents), you can activate the creation of change documents for specific infotypes, plan versions, object types, and subtypes.

In the SAP standard system, HR Change Documents is deactivated for all infotypes. You can only activate infotypes that have been prepared for HR Change Documents, that is, those infotypes for which an entry exists in table T77CDOC. In the case of customer-specific infotypes, you must maintain the entries individually.

Report RHCDOC_DISPLAY enables you to display the change documents created when changes were made to Personnel Planning infotypes using HR Change Documents. The selection options enable you to select the precise documents that you want to display.

The planned status relates to the status of the infotypes and subtypes for which change documents are to be displayed.