Skip to Content

Standard practice for customizing

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:

  1. Schemas & Sub-schemas

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.

  1. PCRs

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.

  • If the SP changes have not been made in say the production client, you can copy the production version.
  • If you have saved or documented the previous version, you can use it to recover.

Overall MORAL OF THE STORY is: FOLLOW THE STANDARD PRACTICE TO CUSTOMIZE. 

Significant changes in schemas or PCR’s

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:

  • It may be even better to do such trials in the sandpit client.  However for this purpose, the sandpit client needs to be kept always in sync with the production client, which is not an issue if the transport path includes the sandpit client.
  • Copy the main schema to a test schema; for example, copy ZX00 or YX00;
  • Copy the pcr to be changed to a test PCR, similarly. If you need to create a new PCR create it as usual.
  • Copy the sub-schema where the pcr/s in b) to a test sub-schema
  • Change this test sub-schema to use the test PCR.
  • Customize the schemas all the way up to the main schema.

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.

  • When you change a schema, I suggest following for doc’ purpose.
    • duplicate the line being changed;
    • comment out the old line;
    • change the new line as required.
  • Often a change is required from a particular date usually known as   xxx change effective date where xxx is the title of change – may be abbreviated as required.  For such purpose, following methods may be used1
    • Constant in view V_T511K:

Configure a constant as below for example:

ZTOL1  01.01.1900 31.12.9999 xxx Change effv         0.00

  • Ø Delimit the constant for the change effective date say 01.07.2016

ZTOL1  01.01.1900 30.06.2016  xxx Change effv        0.00

ZTOL1  01.07.2016 31.12.9999  xxx Change effv        1.00

  • Operation HRS in time eval or CMPER in payroll. This method may be used where you need to check in one or two PCRs only. See example below (for payroll see point c.)

            D HRS=CZTOL1  HRS?0        xxx CHANGE EFFV?

  *             — — —               NEXTR                    Y- DO AS PER CHANGED REQMT

  *      1     — — —

  <            — —                NEXTR                    N – DO AS BEFORE

  <     1     — —

  • PCR to check whether the change is effective. This method is advantageous when the change is in several parts of a schema.

– 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

Testing

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.

Documentation

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.

  • Provide adequate comments in the schema/PCR
  • Expand the top level schemas fully using program RPDASC00, using selection input as below. Save the output as a text file with a suitable name e.g.    PY schema Z000 exp 2016-06-15.
    • Schema:   Main schema name
    • Schema type:  C for payroll, T for time evaluation
    • For all other selection fields:  * (asterisk)
  • Document in a spreadsheet with columns for standard object name/title, customized object name, any related or linked object, last change date/by, task number, task title. This includes all customized objects (including schemas, PCRs, SAP HR functions/operations, ABAP objects, etc.), any object key if required (e.g., wage type), comments,  etc.    
    Purpose:
    • Overall – When one such SAP object is changed in future by a SP, you can easily identify any need of correcting/changing the corresponding custom version.
    • Linked object:  To identify the sequence of transports.  For example, when a SAP HR function (used in schemas) is created, the transport for the ABAP object needs to be released & moved prior to the customizing transport.
    • Object key:  If another task needs to change the same key, the team leader can determine the sequence of tasks and when to change for this task.
  • Create a task document with purpose and solution, imbedding the documents for any Config changes, schemas, ABAP design/code, and for any related object, Test reports, user sign off, etc.
  • Create a Solution document imbedding or linking above task document.  Keep this up-to-date with Change history at the top.
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply