Friday, April 26, 2013

Cleaning up Kronos Employee Groups and Labor Level Sets

In Kronos Workforce 6, one the key components of security is the Labor Level Set when used as an Employee Group. These sets restrict the employees that a manager can see.

One issue with these sets are that they are not self-healing or self-maintaining. If you deactivate a labor level entry, it will still be included in a labor level set. While this doesn't directly cause any harm (it won't grant someone access to employees they shouldn't, for example) it can negatively impact system performance. Why include a condition that is no longer valid?

Unfortunately, there are no system-delivered reports that will identify inactive labor level entries assigned to sets. Likewise, there is no magic "cleanup" button that will just go through and remove them for you.

This became a specific pain point for me just recently. We went through a major account change in our financials system that reworked a bunch of our labor levels. This rework included inactivating a lot of old ones that are no longer used. This was coupled with a quarterly audit report of manager accounts that showed exactly what labor levels each manager had access to. Seeing a lot of old inactive departments included on the audit report caused a bit of consternation and raised a few yellow flags.

The question then became, "What is the easiest way to clean up the labor level sets?" In our case, we completely changed our naming schema, so it was pretty easy to tell the old accounts by visual inspection. However, I didn't relish the thought of manually going through hundreds and hundreds of labor level sets looking for old labor level entries to remove. Instead, I poked around in the database schema and was able to come up with a query to identify inactive entries for me.

This query was written against the 6.0 schema on SQL Server 2005. If you are on Oracle, you may have to tweak the syntax slightly. I don't believe these tables have changed in the 6.x product line, so it should work all the way up to 6.3.

select
    laboracctset.shortnm,
    laboracctset.laboracctsetid,
    llelabacctstmm.laborlevelentryid,
    laborlevelentry.laborleveldefid,
    laborlevelentry.name,
    laborlevelentry.description,
    laborlevelentry.inactive
from
    laboracctset
inner join
    llelabacctstmm
on
    laboracctset.laboracctsetid = llelabacctstmm.laboracctsetid
inner join
    laborlevelentry
on
    llelabacctstmm.laborlevelentryid = laborlevelentry.laborlevelentryid
where
    laboracctset.labacctsettypeid = 2 and
    laborlevelentry.inactive = 1
order by
    laboracctset.shortnm,
    laborlevelentry.laborleveldefid,
    laborlevelentry.name
   
A few explanations are in order. The field 'LabAcctSetTypeID' in the LaborAcctSet table specifies what type of Labor Account Set it is. Since I was just worried about Employee Groups, I specified a value of '2'. The other possible values are 1 (All Sets) and 3 (Labor Level Transfer Sets).

I plan on adding this query to my routine maintenance checks, so that we can keep our Employee Groups cleaned up. Also, a partner query that I plan on writing is one that will identify unused Labor Level Sets. I prefer to keep these types of configuration items as lean as possible. There is no reason to hold on to old, unused sets if they're no longer used by anyone.

The LORD bless you and keep you; the LORD make his face to shine upon you and be gracious to you; the LORD lift up his countenance upon you and give you peace.
Numbers 6:24-26 (ESV)

1 comment:

  1. This is great, can you also tell me how to determine what employee group is assigned to a user?

    ReplyDelete