Support The Site

Friday, June 1

Customizing Feature

Do you often time find the business requirements sometime don't fit with what is available in standard features, such as TARIF, SCHKZ, etc.,?

Most standard features uses similar table structure, such as TARIF uses the PME01 structure. The only available values there for you to select against are MOLGA, Company Code, Personnel Area, Personnel Sub Area, Employee Group, Employee Sub Group, Position, Job, and Work Contract field. Most of which dervive off infotype 0001.

What if you have a requirement to have the feature decision against something not part of the structure? For example, the company business process calls for Job Function Code. Depending on the solution design for Job Function Code, their location could be anywhere.

With that, this will go through one of the many methods on how to enhance the feature to meet the business requirement. I will use the example of TARIF with Job Function Code.

In our example, Job Function code is an new OM object (ZJ) with a relationship to object "C" via HRP1001. We will need to now go down the path of enhancing the feature and do some ABAP'ing.

1) We need to create the new sub feature to be called in the ABAP program. In order to create the new sub feature, we must first create the structure for it. Using SE11 as your starting point, make a copy of the standard structure PME01 (since this is what TARIF was based against). Let's call it "ZPM01". In this new structure, add a new field to capture the job function code ID.
2) Using transaction PE03, we will need to create the new feature structure to be used as a sub-feature through the ABAP program. Create a new feature call it "ZTARI". In this "ZTARI" call the "ZPM01" structure you've identified earlier.

3) Now let's modify the TARIF feature through PE03 to call the ABAP program. At the top node, have it call your custom program, let's call it "ZFEATURE_TARIF".

Now you've got the basic frame work the design. What is missing is the ABAP coding. In the ZFEATURE_TARIF program, you will use the the function module called "HR_FEATURE_BACKFIELD" and "RH_READ_INFTY". The function module HR_FEATURE_BACKFIELD is used to read the "ZTARI" feature and retrive the BACK STATUS value to send back to the main feature TARIF.




The function module RH_READ_INFTY is used to basically read HRP1001 for your job function code information so you could populate the "ZPM01" structure.

In the ABAP program, you will need to reference PME01 structure at the very beginning since you will be sending data back to it


In the program, send data from PME01 to the ZPM01 structure. You will need it for the decision tree in ZPM01 later. What you don't have in PME01 is the job function. This is where you use the read infotype function module, look up the job function code and pass it back to the ZPM01 structure.

At the every end after you finishes with looking up data, send the ZPM01 structure to the HR_FEATURE_BACKFIELD function module for it to handle it's own duties of going through the feature ZTARI and send you back the return value.


Play around with this method and you can see the flexibility of it is fairly nice. What other methods have you come across, feel free to share it!


2 comments:

Hindustani.... said...

Hello Kevin,
This is article on how to create a sub-feature and call it within an SAP standard feature is exactly what I have been looking for. Thanks for the article. Quick question though:

How to do step (3)
3) Now let's modify the TARIF feature through PE03 to call the ABAP program. At the top node, have it call your custom program, let's call it "ZFEATURE_TARIF".

Am not sure how to modify SAP standard feature to call custom program, can you please share some pointers?

Anonymous said...

Even this can be done. On configuring the program, you can modify the std features in your custom program and return the value through 'BACK' statement