Human Capital Management Blogs by SAP
Get insider info on SAP SuccessFactors HCM suite for core HR and payroll, time and attendance, talent management, employee experience management, and more in this SAP blog.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
Hello time management folks,

no long preliminaries, lets jump directly to the facts. You will learn in this blog details on the new EC Time features that we provide with Q1 release 2018.

In Employee Central we put during the last releases lots of effort in enhancing data security and privacy. And this was necessary: For those customers and consultants based in Europe you should already be aware on the new European Regulations on General Data Privacy Regulations (GDPR) that will be enforced in May 2018. If you aren´t familiar with this regulation please inform yourself on it. Not only cause I am personally the opinion that personell data protection is a very important thing, but also cause the fines that can be imposed when a customer fails to adhere to this regulation can be substantial and massive: "Organizations can be fined up to 4% of annual global turnover for breaching GDPR or €20 Million. This is the maximum fine that can be imposed for the most serious infringements e.g.not having sufficient customer consent to process data or violating the core of Privacy by Design concepts." Hence would be a severe fault to underestimate the urgency and priority of this topic. 

But not only customers based in Europe are subject to this new regulation, the regulation states: "It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location". Hence it affects also customers with a headquarter in US, but locations and employees hired in Europe.

So, if you are not yet familiar with the new regulation you better check . This is the source where the above quotes are taken from and where you can find lots of information on this topic.


Data protection and privacy features in Time Management

As mentioned, in Employee Central we did the last 3 releases lots to enhance data protection and privacy and as you might imagine EC Time had some special effort to provide. Not only cause time management is always the complicated area, but also cause in time management lots of data volume exist and especially sensitive data like illness days, overtime and so on are documented.

So lets see which tools can be used to help out here and let me focus only on the EC Time specific aspects cause I can´t write on all that has been done for other Successfactors modules in this respect. Please refer for general information on Data Privacy and Protection features to the below mentioned Jam Discussion group. You will find there useful information around data protection and privacy. This is especially true for some technical limitations in Q1 on change log and read access log. Not all of the features described in my section on change / read access log might be fully working with Q1, again, please check for details this group:

Data Protection and Privacy Discussion Group


Change Logging
Change logging enables a customer to track who has done what data changes at what date/time. And here all changes are tracked, regardless of the channel used to make the changes - could be via the user interface, via proxy-function, via API or via import functionality. The good thing: customer MDF extensions (custom fields for example) are supported as well.
Tracked are all data changes for time objects, be it a new record, edit of an existing record or the deletion of a record.

The Change logging feature gives you a report that shows the changes either made on a specific data subject or changes made by a specific user. The change log report shows the "before value" and the "after value". Additional context is provided as well - for example when an absence is recorded that deducts from a time account not only the absence record is shown in the report result, but also the time account deduction triggered by this absence.

What you need to do is:
1) Switch on via configure object definition the "MDF Version History" to "complete history" (by default it is not set
2) Check for a permission role the "Generate Change Audit Reports" option

Afterwards you can create new change log reports via the Admin Center, Change Audit Report tool.

Create a new report and select the time component and for example a user:


You can download the result and get a long list of information that contains all you need to track the changes:

Information Report
An employee must be able to get information on all personell data that is stored in a system and that is conected to this person. For this a new report is provided that extracts all time relevant data in form of a list. This might be recorded data like absences, attendances, allowances, on call times or any other recorded time data; this are evaluated and calculated data like premiums and pay types, time collectors, time account accruals and of course work schedule data. In short: everything that is time related and stored on the database is the output of this report. Due to the fact that we query each time object and its content on the database the report result does admitedly not win a beauty contest, but I don´t think that this is the question here. The question is rather: give an employee on request an overview on all of his personell / time data that is stored in the system. And due to the fact that time application is within an HR system by far the application with the highest data volume you can imagine that this report list can easily have multiple of 100 pages.


Read access log
A read access log is necessary according to GDPR for sensitive personal data like racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, health or sexual orientation, bank account and credit card data, genetic data and bio metric data for the purpose of uniquely identifying a person. It must be logged whenever a user that is not the employee himself reads this data. And here it is not only user interface interaction, but all kind of read access targets are relevant. This could be also API data extraction, data export and reporting.

So, what does this have to do with time mangement data? On the first glance not much. However, on the second glance each customer can decide themselves what to declare as sensitive data and what read access he wants to log for what data. This could be for example illness absence records. Or performed overtime, working time account balances, time account balances in general. So, I don´t expect much customer activity in time management regarding read access log but we must be prepared if a customer wants to log read access.

When you want to switch on the read access for time objects you need to set via "configure object definitions" a new flag, called "Log Read Access". By default this flag is set to "no". We don´t want to store unnecessary amounts of data in the datacenter.


In time management we got some special things that makes it a bit more difficult than in other areas. For example when you set the time sheet object to read access (and here only the full time sheet object can be set to read access, not single attendance time types), we need to log the access even when no data is recorded in the time sheet - cause we show the planned working time in the time sheet and time evaluation results that might have been generated automatically like working time account balances which could be already a sensitive information. And we also need to log when for example an absence is displayed in the time sheet. Or take the absence tile / time sheet tile on the homepage where information on upcoming absences is shown or the sum of recorded working time - when a user opens this homepage we need to log this information as well.

So, to make it short: use the read access log wisely cause it creates lots of data when you switch it on for each and any object in time. I don´t expect much activity here from customers, but when necessary the read access log can be done. And when you switch it on, you will get in the end a report that shows what kind of data has been displayed to the user.

Purge of employee data
We provide the possibility in EC Time to erase employees time data completly from the data base. No chance to get them back, no chance to have any hint in the system what was there before. The data purge is irreversible and should be performed with lots of care therefore. Purging of data is possible for:

- Time Sheet data (recorded data and all evaluated data like pay types)
-  Absence time types
- Time account types and time account details
- Time alerts
- Temporary workschedule information
- Time account payouts

All of this objects can have different "keep" rules and policies. And even worse, within some of the objects different business related types can have another "keep" period than others. For example you want to keep all illness relevant absences for 10 years and all other only for 3 years. Or you want to keep vacation accounts for 5 years, overtime accounts only for 3 years. This can be configured with the so called "retention group". You create this kind of groups for all business entities that shall have the same retention period and assign this to the absence time types or time account types for example. Then you define a duration for this retention groups. When you perform a purge the system erases then all data that are older than the defined retention period assigned to the retention group which in turn is assigned to the above mentioned objects. 😉 Not that complicated isn´t it?

There are of course some specific aspects worth mentioning. The time sheet for example is purged as a full entity. You are not able to assign a retention period for example to different attendance time types - this is only possible for absence time types. Reason is that we don´t want to overcomplicate things. Time Sheet purge is a full purge of the time sheet object. There is no reason to assign to on call times or allowances a different retention period than for the time sheet as such. Hence, a time sheet purge cannot be futher differentiated. Everything that is recorded and evaluated in a time sheet gets purged after the defined retention period. And due to the fact that you can have time sheets that are partially inside a retention period and partially outside (due to the fact that the time sheet period is 1 week) all time sheets are purged that got 1 day outside of the retention period. There is no split of the time sheet.

When an employee navigates to a period outside the retention period the time sheet will display a corresponding message that time data have been purged and nobody will be able to record any data in this period. This holds true for all object purges: as soon as time data have been erased a date is set which defines that prior to this period no other time data can be recorded or edited. The period prior that has been purged (and of course earlier periods) are completly blocked for time data recording. This is necessary cause otherwise this data change would trigger a recalculation but now based on "wrong" data basis - cause some data has been erased. So, keep this in mind when you define the purge periods.

A further specific are illnesses that are linked together (applies only for Germany, Spain and few other countries). Here an absence that is outside of the retention period but linked to an absence inside the retention period won´t get erased. This record is seen as 1 record. Same is true for example for absence records that are partially outside and partially inside the retention period. Here only those data is purged that are with its end date outside of the retention period. Cause otherwise you erase data that you want to keep - especially for longterm absence records.

Another speciality in time: when absences are purged that deduct from a time account (or attendances that contribute to a working time account) but the time account kept we can´t simply erase the record - cause otherwise the balance calculation of the time account gets affected and altered -which shall not happen. Hence for those cases where a time type led to a time account contribution we perform summarized counter postings to the time account in order to keep the time account balance as it was before the purge.

And one more thing to be mentioned: when time data is purged in EC Time the deletion of the records is NOT replicated to EC Payroll or SAP onprem Payroll (Infotypes 2001 and 2010). Reason is: on Payroll side there are own tools to purge Infotype data. And it might be that customers want to keep payroll relevant time data longer in their payroll system than in the time system. This is why the so called replication proxies are not created when time data is purged.

And due to the fact that we really delete the data from the data base which would lead to inconsistent time valuation results and time account balance calculation when a time record is created for a period that has been purged, we need to restrict time data recording into or before a period that has been purged. This is extremly important. There is no possibility to record any time data in a period or before a period that has already been purged.

So even when only time sheets are purged that are older than 5 years, you can´t create an absence into this period. So, use the purge functionality wisely.

How is this all set up? I can just share some screenshots and explanations that focus on the time side. There is a dedicated documenation on all this data security and privacy tools that I suggest to consult to get more information.



Blocking of time data access
Another part of data protection and privacy is to restrict data access for users. Users should have data access to personal data only on a need-to-know basis. So, access to data that is not needed or not needed any more for business processess shall be limited. But different user groups need to manage different business processes, hence the data access restriction needs to be role-specific. Managers, HR Admins, shift supervisors need to have access for time data only for a specific and mostly different period.  This is why we opened our data models for MDF security checks and role based permissions. You can for example define that a Manager can access an employees time sheet only up to 1 year in the past. However, a time admin shall have unlimited access to the time sheets. You even can define a finer granularity: you can differ for example amongst absence time types which data access to which time type shall be blocked for which person. This is necessary when you want to block access for illness related absences sooner than for other absence types. So quite sophisticated possibilities. But this needs of course configuration.

Due to the fact that we got lots of objects in time management you can will be able to define different "access periods" for following objects:

- Absences (Employee time types of category absence)
- Time Sheet
- Time Account Type
- Time Account Payout
- Time Account Snapshot
- Temporary Time Information
- Time Alert
- Time Collector

For Time Accounts, Absence time types and time account snapshot you can define on type level the access period. You can for example define that the vacation accounts 1 year into the past, but time off in lieu accounts 6 months.

Due to reduce complexity you should try not to set up too many different access periods and roles. I personally don´t see a reason why there should be a different access period for temporary time information than for time collectors for example. So, whereever possible try to standardize and harmonize. But we need to provide a possibility for customers to set this up in a more complex way if needed due to legal reasons.

How does the configuration look like in detail?
First you have to switch on a generic flag that role based permissions shall be enabled for the time objects (up to know, this was not the case).  You do this with a new flag set in the time configuration object via manage data:

Then you need to switch on for the above mentioned time objects the security checks:

Now you can use the time objects in the miscellanous permissions section and create a role with the appropriate permissions:

And then you navigate into the "grantings" part of the role:

And here you can set for the objects mentioned above the access period in months - and even for some objects you can assign an access period per type - like for absence time types for example:

Everywhere where the option "More restrictions" exist you can define the blocking period on type level. This are the objects for Time Account, Employee Time (absence time types) and Time Account Payout.

Assign the role to a user and you are done. Due to the different nature of the objects the blocking period refer to different dates depending on the business context:

- Absences: end date
- Time Sheet: start date
- Time Account Type: booking end date
- Time Account Payout: posting date
- Time Account Snapshot: balance effective date
- Temporary Time Information: end date
- Time Alert: date
- Time Collector: booking date

What does this mean concrete? It means an absence is completly blocked when the end date of the absence is outside the access period defined counting from todays date and for time sheet access we use the start date of the time sheet to verify against the access period. Why the differences? Well, it is only a detail, but for time sheet we say that when parts of the time sheet week is inside and parts of it outside the access period we better use the start date of the time sheet to block the full time sheet. And for absences - the duration of an absence can be for longterm illness 6month long and longer. Here we can´t use the start date cause the absence could still be ongoing (and would be blocked), hence the end date is choosen. Don´t worry too much on this details, this is just when you get questions on why it is different.

And of course the blocking period does not only block the data access, but it is also impossible in time management for a user who does not have access for time sheet data in a period to record data in this period.

When a user tries to navigate into the periods that are outside the access period he gets a little information that explains him why there is no data visible.

And one last thing needs to be mentioned on this topic when you set up the permission roles: make sure you don´t have assigned the MDF OData API access permission in the Metadata Framework Section  - cause this is gonna overwrite all other permissions ;-).

Make sure it looks like this:

So, lots of stuff around data protection and privacy. But apart from this topics we also have developed some new features that are purely time management related. Lets have a look on the time feature and function enhancements:


New time sheet / time evaluation features

Break recording allowed that do not overlap with attendance time
This is only a smaller enhancement, but we need it as a preparation for the future envisioned clock in / out integration scenarios.
You might know that when time recording is performed with start / end clocktimes you can either manually record breaks and / or breaks can be subtracted automatically based on the breaks defined in the work schedule. Automatically generated breaks are of course only generated when overlapping working time exist. And the logic for manual recorded breaks was similiar: you could only record a break overlapping to exising attendance time, and the break was then slipped into the attendance time. To present an example:
Before Q1 it was not possible to record a break that did not overlap with attendance times. So, when you wanted to record: working time 08:00 - 12:00, break 12:00 - 13:00 and working time 13:00 - 17:00 you had to record: working time 08.00 - 17:00, break 12:00 - 13:00. The break was then cut into the working time so that the end result was: working time 08:00 - 12:00, break 12:00 - 13:00, working time 13:00 - 17:00.

But when we come to the clock in / out scenario this logic can´t be applied anymore. Cause employees clock in, clock out (often with reason event "break") clock in again and clock out to go home. We need then to create separate time slices for working time and break time out of this. And in order to be able to do so, we had to change this kind of logic.

But maybe there are already some customers out there that already now want to use the feature to record breaks that do not overlap with the working time. Or first record a break and afterwards the overlapping working time (which resulted in an error before Q1). You can do so now.


Custom fields for allowances
This request was often heard by our customers: they need to have custom fields in our time sheet for allowances. Up to now it was only possible to have custom fields for the so called "time allocation" section where you record working time, breaks or any other attendance time types. But not for allowances. This has changed now. You can add custom fields for the allowances. See my examples in the attached screenshot. But please note: no, it is not yet possible to have conditional custom fields (custom fields that appear only for a specific allowance type). It is a generic custom field:

And the custom fields can´t be consumed in business rules for validation purposes.


Rule function to trigger workflow based on a time account balance
You know that we provide so called working time accounts. They are calculated by time valuation and represent the daily difference of recorded and planned time. This allows employees (usually only used for salaried employees, for hourly employees this makes no sense cause they are paid for each hour they record) to add more flexibility to their working time. They can work Monday / Tuesday a bit longer than planned without receiving an overtime payment for it, and work on Friday less instead without the need to record an absence for it. Or take a full day off. This longer / shorter working gets balanced out via the working time account. Usually this is something that is only done in Europe - I haven´t heard it from US or from other parts of the world (but correct me if I am wrong).

What many customers have got when they use working time accounts is however: all time recordings of salaried employees having a working time account shall not need an approval as long as certain boundaries of the working time account are not reached. This could be for example -10 hours and / or +40 hours. Means, as long as the working time account balance does not cross this boundaries there is no approval of the time sheet necessary hence the work load for managers / approvers is reduced. But only for those exceptional cases where an employees working time account balance crosses this thresholds a workflow is triggered. With the new rule function this can now be achieved.


Time account payout enhancements
Employees time accounts can be paid out via the time admin workbench. A compensation component is created for this payou and the time account reduced. So far so good, this was already before the new release possible. What has been enhanced?

Two new enhancements:

  1. you can now edit and delete an already performed payout. This was not possible before. The time account gets updated of course and the change / deletion forwarded to the EC Payroll replication.

  2. for EC Payroll the compensation component that is created with a payout creates / updates not only SAP Infotype 0015, but can also be replicated to SAP Infotype 0416. Why has this been done? Well, EC Payroll needs this kind of information for some business processes (and especially for the new replication feature described further below) in the Infotype 0416 rather than in Infotype 0015.

In EC you do not notice this replication change, and the ability to edit / delete an already recorded payout this is from a UI perspective of course nothing revolutionary, you get only a little pencil that symbolizes the edit / delete function:


Time account information replication to EC Payroll Infotype 2006 (for specific countries)
Now it is getting a bit tricky and the following is only relevant for EC Payroll and SAP time guys. Maybe it has first to be mentioned that this new feature is not a full fledged replication of EC Time account balance to Infotype 2006. Cause this infotype and subsequent processes in Payroll do not work simply in a way that the SAP absence quota infotype stores the actual balance. When you have a look on the infotype, you won´t see the actual balance in it. You see amongst other fields the information on the entitlement posting per quota and the cumulated deduction quantity (generated by recorded absences that deduct this absence quota). The actual remaining balance is calculated in function modules. And this modules do consider other infotypes as well, like the infotype 0416 quota compensation or 2013 quota correction. So, the balance calculation is done in hard coding in SAP considering different sources for a different point of time - actual day, future dates, end of year.... Furthermore, infotype 2006 absence quota has many fields and the whole notion of absence entitlement has lots of different flavours in SAP ERP. There are around 100 function modules dealing with quota. I would need to read for most of it the documentation (if exists) to find out what they are exactly doing.
Hence it is important to know that this cannot be simply called a Infotype 2006 replication. 

If this is not a time account balance replication, what is it then?
We support a process that is relevant in Mexico for leave liability and social insurance calculations.  The whole end-to-end process in EC Payroll needs this information in the IT2006 and internal table PTQUOTED (this table stores the single quota deduction with key date - relevant if you want to calculate balances for a date)- and this is exactly what is supported with this feature. We did not investigate for all other countries if this replication fits for other processes and countries as well, but for Mexico we did.

The concrete replication consist of:

  • for yearly time accounts (!) entitlement postings are transferred to the IT2006 field "Anzhl"

  • negative postings that result from a time account deduction on EC side are transferred to the internal table PTQODED (please note: the IT2006 field KTVERB is not filled!)

  • Time account payouts on EC side using the new time account payout object are replicated to the infotype 0416 quota payout

I have stolen a good slide from EC Payroll product management that shows what exactly is done:


This information is sufficient that for example function module HR_Get_quota_data calculates a remaining balance in EC Payroll. And this module is used to calculate the balances in the SAP transaction PT50 quota overview or to get the balance to display it on a payslip and in multiple other steps like for the Mexican leave liability and social insurance calculations. So, when you as a consultant need to have quota information replicated to EC Payroll check if the above mentioned replication does the things you need to have. Cause there might be processes that are not supported with this kind of replication - remember the large amount of feature modules in SAP ERP / EC Payroll connected to quotas. We cannot guarantee that each one does the things you might expect with the above mentioned replication.

Enough on this technical Infotype-things. The most important thing is that elements of time account entitlement and time account deductions / payout are replicated to EC Payroll that allows to calculate leave liability and social insurance information for Mexico.

Lets get back to EC and its new features 😉


Automatic account creation and accrual for time accounts with flexible start date
When you carefully follow my blogs you learned that 2 releases ago we provided recurring time accounts with a flexible start date. Till that only the hire date or a fix date was possible to set as a time account start date (and hence an accrual date). The flexible start date allows much more flexibilty. It can be detected via a business rule and you can choose any date field that exists in EC or even custom field. You can hence do fency things like for example not use the hire date but a rehire date. Or in case of rehire not the rehire date but the original hire date. Or the employees daughters birthday as a time account start day (okay, I don´t think any customer will have this ;-)). So, much more flexibilty possible with the flexible start date. But up to now there was no possibility to automate the account creation and the accrual. An time admin had to create the corresponding Time Off calendars manually and schedule them to run on a regular basis. This is done now automatically. Time Off calendars are created automatically and the system runs this calendars as part of a daily background job.

So, again some facilitations for time administrators. Which leads to the next point:

Time Management Job summary in the Execution Manager
Cryptical heading, isn´t it? Let me try to explain:
We got in EC Time real-time time valuation. Means: employees enters data and the whole chain of evaluation steps are triggered immediately. However, there are nevertheless background jobs needed for a couple of reasons.
- Generating working time for a negative time recorder who does not open his time sheet
- Calculating working time account balances for negative or positive time recorder even when no data is recorded
- Automated submitting of time sheets at the end of the week for negative time or when times are only imported

To name only few. And there might be occurences where a time management job gets stuck and you need to review it. For this we have now the scheduled background jobs integrated in the Execution Manager dashboard that can be accessed via the Administration Center. You can now exactly monitor and analyze a time management job. You can furthermore define there under which conditions and to which recipients email notifications should be send in order to give them the result summary of the job runs.

The execution manager looks like this (you see as an example the details of the time sheet submit job):


From the Job summary you can download detailed job key figures and results:




And one last minor thing that we did:

Mobile Time Sheet widget

In iOS mobile time sheet you can place a widget on the home screen of the mobile device that allows easily with one tap to record the planned time as hours worked. This is useful for those cases, where an employee worked exactly according to his work schedule on this day. So no overtime, no times outside the planned time.

Makes time recording very easy. Here is how the widget looks like:



That´s it. Hope you like our enhancements and the above elaboration is useful for your time management implementation projects. I am inspired by the picture above and better go off now on vacation ;-).

You will hear from me again soon.

Volker Ruof

EC Time Product Manager