Purpose is to have a uniform procedure across the organization and avoid future problems as much as possible.
Standard SAP objects including schemas and PCRs may be copied to customer object name range like Yxxx or Zxxx. Then the copy is customized as required.
If a PCR is customized, the sub-schema which uses it and the schemas all the way up till the main executable one are customized. The schema line is changed to call the customized PCR by repeating the original line, commenting it out and the repeated line is changed to call the custom PCR.
Changing the SAP objects and not following this above practice has following disadvantages:
When a SAP schema is changed, it is saved in table T52C1 which is for customer schemas. T52C0 is for SAP schemas. When you next display or maintain this schema, the PE01 txn brings it from table T52C1.
When support packs (SP’s) are implemented using basis txn SPAM, any change from SAP for a schema changes table T52C0. Table T52C1 is not changed. Hence PE01 txn will show the schema with the last customer changes but not the changes from SP’s. Hence you need to see the change in SE16 txn or in the relevant OSS note.
To see the SAP-changed schema in PE01 txn, delete the schema in PE01 txn; this deletes the customer version of the schema; now display the schema in PE01 txn.
Both SAP Standard PCRs and custom PCRs are stored in one table T52C5. When you customize a SAP PCR, then a SPAM txn changes it, the last customer changed version is lost.
To overcome the above problems, you may use one/more of following methods for schemas / PCRs. However in any case it may not be the same as the version that existed before the SP-related change.
Overall MORAL OF THE STORY is: FOLLOW THE STANDARD PRACTICE TO CUSTOMIZE.
When you need to change Payroll or Time Eval schema significantly or unsure how it is to be done /what is required, I suggest following:
For example,
XAL0 (is in main schema) and calls ZXX1, where the pcr is being changed or added in b). Copy ZXX1 to YXX1; change it to use the pcr/s in b) above
Copy XAL0 to YAL0, change it to call YXX1 sub-schema instead of ZXX1
Change main test schema to call YAL0.
Configure a constant as below for example:
ZTOL1 01.01.1900 31.12.9999 xxx Change effv 0.00
ZTOL1 01.01.1900 30.06.2016 xxx Change effv 0.00
ZTOL1 01.07.2016 31.12.9999 xxx Change effv 1.00
D HRS=CZTOL1 HRS?0 xxx CHANGE EFFV?
* -- -- -- NEXTR Y- DO AS PER CHANGED REQMT
* 1 -- -- --
< --- --- NEXTR N – DO AS BEFORE
< 1 --- ---
- PCR ZXXX Check if xxx change is effective
For time eval
D HRS=CZTOL1 HRS?0 xxx CHANGE EFFV?
* SCOND=T IF -Y SET COND AS TRUE
< SCOND=F IF -N SET COND AS FALSE
For payroll assuming period 7.2016 is the effective period
D CMPER 0716 xxx CHANGE EFFV?
* SCOND=T IF -Y SET COND AS TRUE
< SCOND=F IF -N SET COND AS FALSE
In the schema or sub-schema insert lines as below,
IF ZXXX IF XXX CHANGE EFFV
- - - do as per changes
-- - -
ELSE ELSE do as before
- - -
- - -
ENDIF END OF xxx CHANGE
When a number of changes are made, rigorous testing including UAT is advisable. Users may also be involved during screen/report design. Else you may end up with problems in subsequent stages, like UAT, production, requiring correction efforts for customizing, fixing data, etc. If the problem has occurred for example at end of financial year, it may have undesirable serious impacts on employees’ tax, superannuation, G/L, etc.
Purpose is to have a clear understanding of business requirements and solution at any time so that future change task is less stressful.
Following is recommended.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |