Skip to Content


again a short how-to blog on setting up EC Time Valuation in order to illustrate how a real life customer requirement can be covered in EC Time. This shall demonstrate how to best use the different time valuation types – and also to show that it is less complicated as it looks ;-).

Business requirement is to have a validation that a dedicated overtime time type can only be recorded outside the employees scheduled working time and not during the employees scheduled working time.

You know that there are always several ways how customer want to have their overtime processes covered. Customers can choose to have only 1 attendance time type to be recorded by employees and the time valuation sorts out in its daily, weekly or monthly calculations what is overtime and what normal working time, thus generating overtime pay types or regular paid types.

But some customers want that employees explicitly record a dedicated “overtime” time type. Be it for better reporting purpose (but here you could report on time valuation results, too) or to trigger a time sheet workflow only when this time type is recorded (but here again in the workflow rule the time valuation results can be queried) or due to the explicit action that an employee simply need to record something different than his normal working time.

So, when customers want employees to record an explicit overtime time type they often want that this time type is validated to be recorded only outside their scheduled working time. This requirement is best covered within the time valuation rules. But wait, why not using the time sheet validation rules based on business rules for it? Cause it is much more complicated to set this up with the business rules and it is slow in performance.

With the time sheet valuation rules it is much more easier, you need only 1 small rule:

As a precondition you need to have already time type groups created that collect the scheduled working time and the recorded overtime – but this you need to do anyway when you want to use the time sheet. Looks like this:

Scheduled working time:


And overtime:


Lets look onto the time valuation rule then. You need one that contains the time valuation type “Deduct Group from Input Group” and you need to use the above mentioned “Scheduled working time” and the “Recorded overtime”. Lets just look how this rule looks like:

So, what´s going on in there?

The input time type group “scheduled working time” per day is checked against the deduction group “Recorded overtime”.  When there is a time slice containing an overlap of this two time type groups an entry is written to the time type group stated in the time type group below field. This is simply a kind of dummy-time type group that we need to raise an error on it. It is not important how many hours are put into this time type group nor on which day, the sheer fact that there is a value in it states that there is an overlap and this is enough for our purpose. Cause this means in the end that an recorded time type “overtime” overlaps with the scheduled working time per day. And this should not happen. Hence, I raise an error message by seting the error flag to “raise error message on time type group below” and as a message text I choose for example: “Overtime can only be recorded outside planned time”.

Done. Nice, clean and easy. Result in the time sheet looks when an overtime time type is recorded outside the planned time looks like this:

All good, no error. You can see that the scheduled time is 08:00 – 17:00 and I recorded overtiem from 17:00 – 21:00. But when I record overtime outside the planned time….


… the defined error message pops-up. And this works not only when the record is completly inside the scheduled time, but also partially inside and partially outside:


Let me add some finetuning suggestion:

You don´t have to create dozend of valuation rules when you have got dozend of time types that you want to veto when recorded inside the planned working time.

When the time types are of the same category (like attendance, absence, on call…) you just add them as Input time type when you define the time type group that you want to use as “deduction group” or “input time type group” in the time valuation rule.

However, when you have got multiple time types of different category (overtime and on-call for example) then you can´t mix them into 1 time type group. You better adapt the above mentioned rule in a way that you exchange the value in the “input time type group” with the time type group you have entered in the “deduction group”. Cause a deduction group can only be 1, whereas as input time type group you can enter multiple time type groups. Hence you can assign here time type groups that collect on call time types and time type groups that collect overtime time types. Means the “deduct” time valuation type works vice versa the same way.

Looks like this:

I just exchanged the “deduction group” with the “input time type group” entries and added there a new time type group that collects the on-call times.

And of course the error message needs to be more generic when you enter more Input time type groups. It can´t be something like: “Overtime allowed only outside planned time” when the user tries to record an on call time type 😉

End of story. Hope this little example of how the “Deduct Group from Input Group” can be used was helpful to you.



To report this post you need to login first.


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

  1. Naga Swathi T J

    This article is so informative and useful

    especially while implementing EC Time and EC Timesheet for manufacturing organisations

    thabks Volker for sharing this knowledge


  2. Phil Deane

    Thanks Volker.These kind of blogs really help. A lot!

    How about a slight variation on this requirement.

    Not using clock based time recorders, but simple work schedules, with a number of planned hours each day. The validation required is that time type ‘normal working time’ cannot exceed the planned hours for that day.

    The idea being they would have to use a different time type to capture ‘additional hours’. Is there a function to get planned hours for that day, for that employee that can be used within the rules?

    1. Volker Ruof Post author

      Hi Phil,

      yes this is possible as well. But why this complexity? Why not using simply 1 Timetype that represents simply “attendance time” and the overtime premiums are calculated based on this 1 timetype? What is the benefit of having employees to choose an extra “additional hours” time type”?
      Time Valuation reasons? As said, you can get the same results for overtime payments with 1 single time type.
      Reporting? You can report on time valuation results that gives you the calculated overtime.
      Approval? Manager sees on the approval screen the calculated overtime portion even when only 1 timetype for attendance is recorded.

      So, why this complexity?

      But if you nevertheless want to implement it the way you asked you will need to implement two checks

      Check1: Working time is not allowed to be bigger than planned time.
      This valuation rule is quite simple. Check my other blogs, I have already explained on how to create error messages when value x (recorded working time) is bigger than value y(scheduled working time). Rule function here is: Aggregate Input groups and split.

      So, this is quite easy. But you don´t want that employees record “Overtime” or “additional hours” when the bucket of the planned time is not covered with the “normal working time”, right?

      Hence you need to check if the normal working time is equal to the planned time, and then the timetype “additional hours” is allowed.

      You need two rules for this. In first rule you calculate the difference of recorded working time and scheduled time and store this in a time type group. For duration based you need to use the valuation method “Difference between Input and Threshold”. You compare scheduled/planned time per day (as threshold time type group) with Input time type group “Working time” (or however you call it). The result is put into the “below time type group” section and represents the hours worked that are less the planned time.

      In the second rule you pick up this calculated value (less hours than planned). Use the “route” time valuation method (If you don´t know how it works, check out my other blog that I have written on this function). Input time type group is the recorded overtime. The comparison group is the above calculated difference. You compare this against threshold fix value 0. So, you check if less hours exist when a time type “overtime” is recorded. If yes, means if value bigger 0, than this value is routed into the above time type group. And you can create an error based on the above time type group than.

      So, possible. I checked it in my system. Works smooth and fine.


      1. Phil Deane

        Thanks Volker that’s brilliant!

        So, rather than trying to use a validation rule, I have moved to the split and aggregate method as you suggested. I have a time type group for the Scheduled Working Time being used as the ‘Dynamic’ Threshold Group and with a valuation method of weekly which fires an error on the time type group above. This is great.

        However…. Is it possible for flexibility around the Threshold Group that represents ‘Scheduled Working Time’? The Scheduled Working Time needs to consider any absences. If the work scheduled is 8 hours a day for 5 days, and the employee have 3 days off, the weekly threshold value should be  16 hours to reflect the planned working time for the week.

        Maybe I have missed a configuration setting on the absence time type which would deduct it as this Planned Working Time is also miss represented in the approval workflow. In the Approval Overview popup when the approver sees the and overview consisting of

        • Period
        • Planned Working Time
        • Recorded Working Time

        This planned working time doesn’t consider absences so to the approver it looks like there is time missing.

        1. Volker Ruof Post author


          Hi Phil,

          sure, why not? How the “scheduled working time” type group is calculated is up to you. If you want to deduct recorded absences you create a rule that takes the scheduled working time, compares it with a time type group in which you put all possible absences and you do a aggregate input group and split valuation. The remaining value is the scheduled time less absences. When there are no absences, the full planned time is remaining.

          This is for the time valuation purpose. But you always have two options for those kind of queries: either you deduct the absences from the planned time, but then semantically, it is not any more “scheduled” or planned time. Cause that the employee was planned in your example on Thursday / Friday did not change. So usually for overtime calculations absences are not deducted from the threshold, but of course you need to add them to the recorded working time.

          So, in an easy example:

          Weekly overtime calculation. Planned time 5 days with 8 hours. Full day absence on Thursday / Friday. The overtime threshold normally is still 40 hours. You don´t deduct the absences here. But you count against the threshold not only the recorded working time, but also recorded absences (mostly even unpaid absences).

          For the workflow UI and for the homepage tile the above mentioned is not relevant, cause there it is hard coded behaviour and cannot be configured. There we applied a logic that simply collects all recorded attendance times. Not absences. Reason is: the manager does not approve the absences (separate workflow) but only the attendances in the time sheet. The information is indeed not really useful when the employee has a 3-days vacation and worked on the other two days 30 hours (theoretically). Let me think if an adaptation here makes sense. But you get into tricky constellations then: Time Sheet is sent to the approver and includes the absence hours, in the meantime the manager has declined the absence request (or the employee withdrawn) so that the absence hours should not appear anymore in the time sheet workflow summary. Let me check if the data is stored or always read upon user interface call.




Leave a Reply