cancel
Showing results for 
Search instead for 
Did you mean: 

Why start date/end date are designed as defaulted primary key in most ECC HCM tables?

0 Kudos

I see many person related information types (eg. 0185 - document of record) has start date/ end date as its part of primary key by default. Form my viewpoint, there are two kinds of requirements for date

1. date tracking - for some key information, we need effective date to have the data change to be tracked

2. natural information - some business entity has date information in natural, but the date is not related to date tracking, sometime the dates are part of the entity.

so i cannot fully understand why 0185 ( document of record) need to have start/end date as primary key - 0185 has two set of date fields, one set of field belongs to #2 ( above) , but 0185 also have start date / end date that function as #1. For start date/end date in 0185, they are marked as primary key. I have doubts on this. I think 0185 ( documents of record) don't need to be tracked by date, so we don't need start date / end date as PK.

I ever worked on Oracle product, for the same, Oracle's data structure looks reasonable

The unique constraint: PERSON_ID, DOCUMENT_TYPE_ID, DOCUMENT_CODE

The date fields ( Date From and Date To ) are to indicate the valid period of this document.

Anyone can help me on this doubts? Thanks.

Accepted Solutions (1)

Accepted Solutions (1)

ChrisSolomon
Active Contributor
0 Kudos

You are right....there are situations where start/end dates are needed and some where they are not....this is the flexibility of SAP. As you said, you won't see this in other products....even in SuccessFactors, there is no notion of delimited dates or time constraints.

In SAP, one key component you need to look at is the "time constraint" settings for particular infotypes and subtypes. Based on this "time constraint" setting, the start/end dates may overlap and allow multiple records of same type (for instance, I may have many children all with different dates). Others, however do NOT allow overlap (for example, I may have a position from 05/15/2012 till 09/22/2018 but then a new record/position for 09/23/2018 till 12/31/9999....depending on which "reference" date I am looking at, my position information...and everything related....pay, work schedule, etc... may be very different at different points of time.....especially important in reporting). There are several "time constraint" options available. And as you pointed out, this is a very SAP-centric thing to understand.

Past that, the "primary key" structure you reference.....if you look closely, this is built into every infotype...EVERY one of them....as it keeps them consistent.....each infotype will then have their own structure included to further define the table metadata. THIS is a BIG part of understanding SAP HR tables. As you said, it might not make sense for every table (such as IT0185 for you) BUT it keeps them consistent and their access/interaction consistent (think of it like a common interface in OO programming).

Thanks Christopher.

Answers (0)