We often talk about the auditability of TimeControl’s data but how is that accomplished behind the scenes.

Imagine this scenario.  We have an employee fill out a timesheet.  We save that timesheet.  It will be no surprise that the timesheet line and header tables have relationships with the employee table, and the charge table.  But then next week, the employee changes departments.  He is no longer in the technical department.  Now he is in the sales department where timesheet rules are different.  Plus he changed salary in the move.  He’s no longer paid the same as he was.  Plus, the charge codes he used have had changes too. They have different start and finish dates.

If I go to look at this person’s timesheet for last week, will it show the updated employee and charge code information?  It won’t.  The TimeControl design was created so that a timesheet can always be recreated as it was originally entered.  That means we have to freeze the employee and charge code data and save anything else relevant to the timesheet at the time.  In TimeControl, we do this at the time of posting.  That allows us to comply with stringent auditing requirements such as the Defense Contract Audit Agency but it also allows us to follow some common sense accounting.

If we did a costing report on the employee I just talked about, we’d reasonably expect that his cost to the company per week would be one value until the department and salary change and then a different value after that.  Also, costs to the tasks that person worked on would be at the original salary value until the department and salary change.  That would just make sense.  That, however, is not how many project-based timesheets work.

So, how do we do it?

Using referential Integrity.

It’s no surprise that TimeControl is based on a relational database.  Products like MySQL, Oracle and Microsoft SQL Server are all relational in nature.  But that’s not enough.  From the earliest versions of TimeControl we’ve embraced the concept of relating different records into specific records in different tables.  Here is how that works.

When a record is changed in a key table in TimeControl like the Employee Table or the Charge table, TimeControl saves the original record as a historical record and makes the newly changed record the current record.  All ties from, say, a timesheet line to a charge code line stays with the original record.

That’s huge.

So, the newly updated record is what you would see in the Charge Table or the Employee Table but you can look also at the historic records that are related to that entry from all the times the record has changed in the past.

The TimeControl Employee Table is called “Employee”.  The TimeControl Employee History Table is called EMP_HIS.  The TimeControl Charge Table is called CHARGE.  The TimeControl Charge History Table is called “CHR_HIS.

When creating reports or exports, it’s important to keep in mind that these tables are distinct and display distinct values.  Choosing the Employee Table will show only the information for that employee record that is from the current entry.  Choosing the Employee History Table will show all the associated entries for that Employee over time.

We never delete historic records.

If you look at a timesheet from a year ago, the employee for that timesheet might not even be in the company anymore.  But the employee record associated to each timesheet will be.

Referential Integrity is part of what keeps TimeControl simple on the outside but robust and flexible on the inside.