| Home
Products & Services Technical
support Articles
Archives Partial list
of users
Satisfied customers Contact us Dealer inquiries FAQs Links About
us Jobs 01 02 03 04 05 06 07 08 09 10 11 12 |
| d Three different animals: learn how to tell them apart (and save wear and tear on your career) Data capture devices vs. timekeeper applications vs. payroll applications
Are you being courted by a vendor of computerized timekeeping devices (aka computerized bundy clocks)? Avoid later disappointment and feelings of betrayal by keeping a few considerations firmly in mind. Just as with any investment in business equipment or production machinery, the bottom line is, you’re seeking productivity increases.
Ensure that you actually get the productivity improvements that you seek by knowing your basic parameters. A useful first step is to get your definitions down cold.
A TIMEKEEPING device is a piece of hardware (with software). Its basic function is to capture accurately your employees’ time of arrival and time of departure from your workplace. It is aptly described as a “computerized bundy clock,” because it performs the same function as that charming appliance from an earlier generation. To record the time-ins and time-outs of employees, the timekeeping device is necessarily equipped with rudimentary software that can capture and store these time-in/time-out data.
A timekeeping application
- that's a very different beast. First of all, it's purely a piece of software,
not hardware. It may reside in the data capture device; but it more usually
resides in a computer. A timekeeping application is a much more
sophisticated piece of software than what you find in a time data capture device, going way beyond merely recording your
times of arrival and departure. The timekeeping app does a lot more data crunching than the time capture device. The timekeeping application's job is to take the raw time-in/time-out data captured by the time data capture device (or a traditional bundy clock), and to produce usable time information from these, based on rules that are specific to your organization. A time data capture device may or may not be equipped with a timekeeper application (usually not). And it is precisely that important determination that this article aims to help you make.
In brief, a timekeeper application computes each employee’s regular hours worked, undertime and overtime hours, night differentials, absences, etc., based on (1) their time-ins and time-outs from the time data capture device, and (2) relevant company “rules” and policies regarding work times and periods. This software, if properly designed, frees the payroll officer from having to manually compute these figures. Done manually, this is one of the most tedious, time-consuming aspects the payroll officer’s job.
Numerous rules, policies and algorithms (your rules, your policies, your algorithms) play a role in the proper processing of time parameters for your payroll inputs. These rules are set by your company management, in a direct manifestation of your company’s policies about time, indeed, its cultural attitudes about time. As dramatized in the sidebar ("Elvis has entered the building!"), different companies will have different ways of treating the same workday, each one of them perfectly justifiable. That’s management’s prerogative (or the labor union’s hard-won conditions). When implemented by a human clerk, these rules seem simple, straightforward, even self-evident. But
when translated into a computer program, their full complexity
emerges. That’s because computers require everything to be
expressed explicitly and precisely. Computers, unlike most
humans, are famously intolerant of ambiguity. And computer
programs have a tendency to expose inconsistent rules and procedures...
by crashing. Part of the challenge of computerizing timekeeping is
frequently the need to first “repair” rules conflicts that had
been coexisting undetected in the previous (non-computerized) regime. And that is why it’s one thing to create a time-in-time-out data capture software module (very easy); it’s quite another to create a true timekeeping application (much more difficult). A programmer, working alone for just a few hours, can easily write a time data capture module; but he would need multiple detailed consultations with the end-user, plus a few hundred hours of coding time, to create an acceptable timekeeping application. THE POINT was made earlier that different companies could easily assume different attitudes, and therefore formulate different policies, to various time questions in a workplace (typical issues are illustrated in the sidebar on page 2). Face it, this will happen all the time; because there’s no standard way to handle time issues. What this means is that a timekeeping application always has to be specially tailored to each company’s attitudes, rules, and culture about time issues. This is why a timekeeping application is a very complicated thing, and a very different animal from either a time data capture module or a payroll application. Don’t confuse one with the others, or think they are all one and the same thing. A time data capture module, because it merely records raw time-ins and time-outs, can’t tell regular hours from overtime hours, or absences from disciplinary suspensions. That’s the job of the timekeeping application. . And everyone knows that a payroll application is a piece of software that computes your employees’ pay in peso terms. But it’s useful to remind ourselves that in computing our pay, a payroll application grapples with many, many more parameters and variables than just time. Aside from time-impacted pay issues like overtime, night differential, and time-based pay, a payroll application needs to simultaneously handle: contributions to various government funds (SSS, HDMF, PHIC); contributions to in-company provident funds; a whole slew of income taxation issues and mandatory BIR reporting; and issues having to do with employee benefits in monetary form, such as company loans. And that’s how a payroll application differs from a timekeeper application. And that's why a payroll system is a different and separate animal from a timekeeping application.
THEREFORE, if you are about to invest in a time data capture device, clarify first if it comes with a timekeeping application or not. If it doesn’t, then all you get is a machine that produces the same raw time data as a bundy clock, only perhaps with biometric identity validation capabilities or optical scanning features to prevent employee fraud.
If you do decide to commission a timekeeping application, make sure that you explain all of your company’s rules, policies, and algorithms regarding time questions to the software developer you hire. And yes, now that you know the unsubtle difference, make sure your programmer really delivers a true timekeeping application, not just a time data capture module.
This leads us to the logical question: Can a payroll application automatically take the time information produced by a timekeeping application so that the payroll clerk is spared the tedium of encoding time data manually into his payroll application? For example, can Balmori Software’s SURE! PayMaster payroll application automatically take up the output of a timekeeper software package so that you avoid manual inputting?
Answer:
If what you have is a true timekeeping application as
meticulously defined in this article, then the answer is yes, it is
possible to express its output in text format so that it can be
automatically sent to the payroll application, thus eliminating manual
encoding of time data. If, however, what you have is only a
time-in-time-out data capture device, know that it only records
time-ins and time-outs. If you already have a timekeeping application, SURE! PayMaster has an available add-on module for processing the output (in text format) of a timekeeper application. SURE! PayMaster reads this file, and automatically transmits the corresponding hours and minutes data from this file into the respective employee records, whence they will be incorporated into this pay period’s payroll computation. To get more clarity on this potentially confusing topic, read the related article Biometric data capture devices: where they're helpful, where they're not. RSR/RCD. (To request a printer-friendly version of this article, e-mail us your request at balmori@balmorisoftware.com. Please cite your name and company name.) Questions? Reactions? Write to balmori@balmorisoftware.com. |