SAP HCM TIP: MANAGING SCHEMA CHANGES
March 23, 2017
If you have been using time evaluation very long, you may have seen an error like this. When this happens, it tends to cause some panic because it stops time evaluation, and subsequently payroll for all employees.
This occurs when multiple changes are being made to the schema but not moved to the production system at the same time, or in the same order.
The Cause
When a schema is transported in SAP, it is considered one object, so the entire schema is captured any time it is saved to a transport. It does not pick up only the changes that were made during the current session. For example, consider the following scenario:
You are working on a change to a quota, and attach a new personnel calculation rule (PCR) to the schema
While you are testing the quota change, a higher priority overtime rule (PCR) is attached to the same schema
The overtime rule change is saved in a separate transport, and moved into the production system before the quota change
The schema is now looking for your quota rule (PCR), but it does not exist in production yet because it was saved in a separate transport that has not been moved to production
Resolving the Error
To resolve this error, open the schema in PE01, then click on the ‘Check’ button (F6). An error is displayed. The cursor will highlight the first occurrence* of the missing PCRs. See the screen shot below.
A new transport should be created, with the missing PCR commented out of the schema. When this transport is moved up to production, the schema will then ignore this rule, and the production system error will be resolved.**
As a second step, the rule is still required for the other change, so it will need to be added back to the schema. If the transport for the second change has not been released yet, this change can be added to the existing transport. It is likely, though, that transport has already been released to your QA system or the issue would have appeared during testing.
* Be sure to compare the production and development schemas to identify ALL of the missing PCRs
** Because the second transport is likely already in the QA system, it will be difficult to provide meaningful test results on the correction transport.
TIPS to Reduce the Risks
While there are no practical ways to completely avoid this situation, the following tips can help to mitigate the risks, or quickly identify the issue when it occurs.
Checking the Schema in Production
As soon as a transport (that includes the schema) is moved into production, check the schema by opening it in PE01, and clicking on the ‘Check’ button. You should see a notification at the bottom of the screen ‘ZM04 schema O.K.’. If a PCR is missing from another transport, you will get the error that was described in the previous section.
Another transport, or series of transports will be required to correct this, but by doing this check right away, the issue will be identified early.
Using Sub-Schemas
A sub-schema is really no different than your main schema, except that it is not run independently, but called by the main schema (using the COPY function), and contains a smaller set of logic. The most common examples of sub-schemas are for overtime rules.
The benefit of using sub-schemas is that each sub-schema is considered a separate object. So when you attach a new PCR to the sub-schema, it does not record a change to the main schema. So in the scenario that was described previously where 2 separate changes were made - overtime and quota- if there were 2 separate sub-schemas has been used, these changes would have been more independent.
There still could be issues if there are 2 separate changes to overtime that attach to the same sub-schema, but still provides some separation of different types of processing.
Adding sub-schemas generally occurs over a period of time. It is most natural to add them when specific changes are being made. It is not always possible or practical to use a sub-schema as individual PCRs may need to be processed in a particular place in the schema (ie. before/after the QUOTA function).
Testing with a Schema Copy
When you have a significant change to make, consider making a copy of the schema to test with. For example, if you use schema ZM04, copy it to YM04. Attach your new PCRs to this alternate schema to do the majority of the testing. When you feel comfortable with the changes, then attach the changes to the live schema.
Make sure that you do some additional testing to ensure that nothing was missed in the copy.
Delete the test schema to keep the system clean. Too many versions of the schema can get confusing to new team members. When the next change is needed, make a new YM04 copy, to capture all of the recent ZM04 changes.
Downloading the schema
In case some unintended change does get moved to your production system, it is handy to have a copy of what the schema looked like before the change. SAP delivers a standard program to download the schema into a text file. The program name is RPDASC00. Using the settings below should display all of the sub-schemas and personnel calculation rules.
Rather than relying on the configuration team to remember to download this, it might be worthwhile to set up an automated job to run this daily. If you do need to back out any changes, this text file will make it much easier.
