Skip to Content

Objective Setting & Appraisals: Document datamodel

After the first BLOG entry came the stress of moving out of Germany. That made out of a two weekly blog a one time entry. But, it is a new year and I am trying to settle down in beautiful India. So, let’s see if we can get some more articles about Objective Setting and Appraisal going.

While going thru the forums to answer some questions about OSA I stumbled on a question about our data model. The question made sense; where is the document data stored, and why in such a structuring.

Well, before I go in detail on the where I while first answer the why question. The old appraisal module stored the document data in infotypes that created a huge number of entries in a few tables which made for imperformant reads.

With the design of the AES-engine we already envisioned other applications besides OSA using the appraisal engine. This would mean that there would be an even bigger mass of documents created as before. As such that made performance one of the top issues. Currently there are 4 applications using the appraisal engine; that being OSA (Performance Management), LSO (Learning Solution), E-Recruitement and EIC (Employee Interaction Centre).

The data structure of a document consists out of two parts.
– The header which contains all the necessary administrative data of the document. Things like who or what is being appraised, by whom and for which time period are just a few of the possible options.

– The document body. In here the actual appraisal takes place. The elements (objectives, questions etc) are in here, but also the different ratings from each participant. Even automatically generated data is filled out in here.

The main identifier is always the appraisal ID. This is a GUID32 and is stored in the HRHAP table. With this key you can uniquely identify a document, and the ID is used always as a pointer in the rest of our tables. Besides the ID also all the appraisal dates are stored in the HRHAP table. The appraisal document can have a title and this is stored in the HRHAP_T.

An appraisal is always performed on someone/something (the appraisee). Appraisee data is stored in the HRHAP_APPEE table. The main object/person appraising the appraisee (the appraiser) is stored in HRHAP_APPER. Besides a mandatory appraisee and an appraiser you can have part appraisers. They are stored in HRHAP_P_APPER. And finally all other participants are stored in HRHAP_OTHERS.

The above mentioned tables make up the document header. The main body table is the HRHAP_BASIC, this table contains all the elements available in the appraisal document. Each element consists out of one or more columns and the entered values and/or notes (exception can be the criterion group element which can be empty).

We store the column data in groups. All the objective setting data (all the columns with technical name OBJ* or QBJ*) is stored in the HRHAP_OBJECT table. The final appraisal data (column FWGT and FAPP) is stored in HRHAP_FINAL and the part appraisal data (column PAPP and PWGT) in HRHAP_PART. All other columns, be it standard delivered or customer specific, are stored in HRHAP_FURTHER. All the notes belong to the document are stored in the SAPScript tables.

That leaves us with the last 3 tables in which document data is stored. The HRHAP_ACT_LOG contains additional data that belongs to the action log. In the HRHAP_PROCESS all the follow-up process are registered when they are performed. And finally the HRHAP_ANON, this table contains the information whether a user is allowed to perform the appraisal in cause of a non-named template mode. When it is an anonymous document the HRHAP_APPER stays empty and the changed by information in the HRHAP table is left blank.

In the picture below you can see the above in a nice graphical overview. There are several other HRHAP* tables besides the ones mentioned here, however these tables don’t belong to the document directly. They are used in a process supporting role.


This concludes the quick overview of the data model for an appraisal document. One recommendation, do not read directly from the database tables when you can avoid it. Use the function module HRHAP_DOCUMENT_GET_DETAIL instead. Reading directly can give invalid values from a process point of view, especially if the document hasn’t been completed yet.

You must be Logged on to comment or reply to a post.
  • Great Blog and very timely.  We are in the middle of implemention the new OSAs.  We have some requirements to integrate the results with Compensation so this is very helpful.

    Just a suggestion with the old appraisal model it was fairly easy to use the FMs and BAPIs to read and intrepret appraisal data.  Perhaps you could explain in more detail how to interpret the data returned in the new FMs.  This seems a little less straight forward.


    Chris H.

    • Hi Chris,

      I plan to do the data interpreting part in the next article. Also with the new OSA model it is relatively easy. It’s just a handfull of FM’s and the structures are always the same.

      Regards and Groetjes,

  • maurice,

    It’s great and timely.could you tell us the what are the additional features in OSA (ERP2005) when compared to its previous versions.


    • New is in ERP2005:
      – Offline
      – Element Access
      – PDF Printforms
      – Note on status change
      – Personal notes

      As always documents and released templates from lower releases are 100% compatible with this release.

      See also the service marketplace:

      This link will lead you to the Performance Management area and in its media centre you can find a presentation on the changes in detail. Also here is a document compairing each version of OSA.

  • Hi Maurice,
    Welcome to India.
    This is a nice Blog and the Function module “HRHAP_DOCUMENT_GET_DETAIL” is extremely usefull.
    Right now I am having problem reading the Status Change notes from the parameter (T_STATUS_NOTES), of this function module, which I wanted to put in my emails. But I will figure it out.
    Raghu Kolukuluri