Time and Labor — Module Case

Alt text: Five-stage Time and Labor chain: entry rules validate, managers resolve exceptions, calculation rules derive, consumer validation checks, and administrators transfer.

Reported time passes through five stages in order. Stage one: time entry rules validate the reported time automatically, and raise an entry exception if something is wrong. Stage two: managers resolve any exception raised. Nothing downstream runs until this happens, which is why an unresolved exception is the most common cause of a missing payslip. Stage three: calculation rules derive further time from the validated data, and they run only on data entry validation has accepted. Stage four: consumer validation checks the calculated data once per downstream consumer. Stage five: time consumer administrators transfer the data to payroll or project costing. Stages two and five need a person; the other three are automatic. A symptom at a later stage means the failure was earlier.

Alt text: Time cards, calendar, Web Clock and third-party devices feeding one validated stream of time entries, with the exception queue beside the device path.

Four channels bring reported time into the application, and they are not equivalent. Time cards, a calendar and Web Clock are used directly by an individual, who can see and correct their own record. Web Clock events and third-party time collection devices — badge and biometric readers — arrive differently: an import process validates the event-related time data and creates or completes time entries from it, and the events it rejects become badge and time entry exceptions that time and labor managers resolve. That queue is the operational difference between the typed and the personless channels: a typed card has an author who can be asked what they meant, while a rejected badge event has only an exception with an owner and no deadline. Three actors have different reach. A worker reports their own time. A line manager can report, review and submit time cards for their people, including delegates. A time and labor manager can do the same for their people and additionally run the processes that generate mass time — the only actor who can create time that nobody individually recorded. Beneath the channels sit the prerequisites that decide whether any of it works: the setup tasks live in Setup and Maintenance under the Workforce Deployment offering, Time, and Labor functional area, in three groups — Time entry, Time processing, and File processing for time collection devices; Oracle Global Human Resources Cloud is required for Time and Labor processing; and if you pay worked time according to time card entries, the Elements and Formulas functional area is needed as well.

Alt text: A Worker Time Processing Profile linking a repeating time period, a time consumer set, an HCM group, and optionally calculation and entry rule sets.

A Worker Time Processing Profile is the object that decides how a population of workers has their reported time processed. It links four things. A repeating time period supplies the time card period and the overtime period. A time consumer set names which downstream consumers receive the time and holds their validation rules, approval period and transfer rules. An HCM group identifies which workers the profile applies to, bounded by from and to dates. Optionally it can also link time calculation rule sets and time entry rule sets. One critical property: once the time consumer set is associated with the profile, the set can no longer be edited, and no consumer can be added or removed. Review the set before attaching it. Separately, several profiles of the same type may match one worker, and priority decides which wins, where Oracle states the highest priority is 1.

Alt text: A Worker Time Entry Profile linking a layout set, an HCM group and optionally an attestation set, and governing who may create, review, edit and submit a time card.

A Worker Time Entry Profile is the object that decides how a population of workers has their time cards entered and submitted. It links three things. A layout set supplies the fields that appear on the time card, so the profile decides what a worker is even able to record. An HCM group identifies which workers the profile applies to, bounded by from and to dates. Optionally an attestation set supplies the attestations a worker must give. The profile governs four actions across three roles: workers create and submit, line managers review, and time and labor managers edit. A group may be assigned to more than one time entry profile, but a single group cannot be assigned to more than one time entry profile for the same period: group assignments must not overlap. The time card statuses named on the page are Entered, Saved and Submitted. Where the days-before and days-after values are left unset, people can always perform the enabled action on cards in the enabled statuses, which means the edit window is open-ended by default rather than deliberately bounded.

Alt text: One repeating time period feeding five uses — time cards, approvals, accrual processing, overtime and balances — with its usage deciding which configuring page may select it.

A repeating time period is one object with one usage, and the usage decides which configuring pages offer it. The five usages are time cards, approvals, accrual processing, overtime and balances. Eligibility is carried by the period rather than by a rule on the page, so a period that exists, is dated correctly and has the right length is still simply absent from a page its usage does not feed. That absence is the diagnostic: nothing on the page reports that a period exists with a different usage. The repeating length is constrained separately. All time card layouts support weekly and two-week repeating periods, and the responsive layout additionally supports a monthly one, so a monthly period is unavailable on any other layout. The overtime period can match or differ from the time card period, which is what allows overtime boundaries to sit on a different day from the card start. Editing is constrained too: a delivered repeating time period cannot be edited at all, and after saving your own period only the name and description remain editable, so the dates are final before you expect them to be.

Alt text: The four time card actions covered by validation and processing rules — Next, Save, Save and Close and Submit — and the delivered defaults that decide which validations start.

Four actions on a time card are covered by validation and processing rules: Next, Save, Save and Close, and Submit. Which validations run is not a property of the rules. It is set by the Validate on Time Card Actions field on the time consumer set, which chooses which actions trigger validation on save. The delivered defaults are asymmetric and this is the part worth remembering: by default the delivered absence validations always start, while the delivered project and payroll validations do not. A tenant that assumes every delivered validation behaves the same has inherited a difference that was there before anyone configured anything, and it shows up as a card that saves cleanly all week and fails at submission. Submitting is different in kind from the other three actions — it sets the time card status to Submitted and starts the approval workflow, so saving records and submitting requests. Oracle recommends selecting Submit and save for Project Costing so that people working on time cards learn immediately if they are saving time entries to closed projects. One question here is deliberately unanswered: whether the absence validation statement applies to Save alone or to both Save and Save and Close is ambiguous in the source and is recorded as needing confirmation rather than asserted.

Alt text: Six formula and template types — advanced time category, time calculation, time device, time entry, time submission and workforce compliance — with the read-and-write behaviour of the three answering types.

Six formula and template types configure time validations, processing and compliance: advanced time category, time calculation, time device, time entry, time submission, and workforce compliance. Three of them answer, and they are separated by two questions rather than one. First, what data can the rule read. A time entry rule validates time card entries — time a person typed. A time calculation rule works from that same data. A time device rule evaluates time events imported from time collection devices, so typed time is not in its input at all. Second, what is the rule permitted to write. A time entry rule generates a message with a defined severity and changes nothing. A time calculation rule creates or updates time card entries and produces calculated results from formula logic, so it writes the data payroll will later consume. A time device rule creates time entry exceptions. The writable effect differs as much as the readable data, which is why substituting one type for another is not a miscategorisation: a rule in the wrong type produces nothing rather than an error, and the silence looks like a broken rule. The remaining three types are named here without described behaviour, because the page that states the taxonomy does not describe what advanced time category, time submission and workforce compliance do. The delivered template names, rule names, formula function names and database item names are published in a separate fast formula reference document, and this lesson names none of them.

Alt text: Three time consumers: Global Payroll, Project Costing, and the Project Execution Management offering of Project Portfolio Management.

Three products consume Time and Labor data: Global Payroll, Project Costing, and the Project Execution Management offering of Project Portfolio Management. Which of them receive time for a given population is decided by the time consumer set attached to the worker time processing profile, so the same submitted time can go to payroll but not to project costing. The set also holds each consumer's validation rules, its approval period, and its transfer rules. The approval period matters most in practice: it determines when transferred time actually reaches the consumer. A consumer whose source is not healthy is demoted in search ranking, and a claim citing a broken source stops being retrievable as support until it is re-verified.