Procedure
Diagnose missing time in a consumer
Establish which of the five Time and Labor processing stages a reported-time problem belongs to, and what evidence proves it.
When to use
Use this procedure when time that was reported and submitted is absent from Global Payroll or Project Costing, or present in Time and Labor but not downstream. Do not use it when the time card was never submitted — that is a different problem, and this procedure will show the submission gap at step one.
Access assumptions
A procedure followed by the wrong person is a security incident, so these are stated explicitly rather than assumed.
- Ability to view time cards for workers outside your own reporting line
- Read access to time processing profiles and consumer sets
- Read access to the consumer for the affected period
Prerequisites
- Access to the time card for the affected worker and period
- Access to the worker time processing profile covering that worker
- Access to the time consumer set on that profile
- Access to the consumer, so consumer-side messages can be read
Pre-checks
Do these before starting. Each one prevents a failure that is expensive to undo once configuration exists.
- 1.Confirm the dates and the consumer. "Missing time" in payroll and "missing time" in project costing are different failures with different owners.
- 2.Confirm the worker has a payroll relationship covering the period. A retroactive change to the payroll relationship can require recalculation and transfer.
Steps
Confirm the time card reached Submitted
Open the time card for the affected dates and record its status. If it is not Submitted, the problem is in submission or approval and nothing downstream has run.
Expected outcome: A recorded time card status for the period.
Check for unresolved entry exceptions
Record any entry exceptions on the card and who owns resolving them. If any exist, the chain stopped at stage two and stages three to five never ran.
Expected outcome: Either a clear exception list or confirmation that none exists.
Confirm calculation produced the entries
If entry validation passed, check whether calculation produced the entries this consumer needs. Incorrect totals with no exception is the quietest failure in the chain.
Expected outcome: Either calculated entries present, or a diagnosis in the rule sets.
Read consumer validation for the specific consumer
Record the consumer-specific validation messages on the entries. These rules are delivered by the consumer, so read its message rather than Time and Labor configuration.
Expected outcome: Either a consumer rejection message, or confirmation the consumer accepted the data.
Confirm the transfer completed
Check whether the transfer completed for the approval period covering the affected dates, using the approval period on the time consumer set.
Expected outcome: Either a completed transfer or a pending one.
Close the loop in the consumer
Re-query the consumer after the transfer. If the data is still absent there, the investigation has moved out of Time and Labor and into the consumer integration.
Expected outcome: Either the data appears, or a consumer-side defect is confirmed.
Run this procedure
Sign in to record a run. The steps above read the same either way; only the record needs an account.
Verify
A configuration that is not verified is not complete.
- The consumer now shows the expected data, or the failing stage is documented with its evidence.
- No later stage was re-run in the hope of fixing an earlier one.
If it fails
| Symptom | Cause | Resolution |
|---|---|---|
| A payroll analyst concludes payroll is misconfigured when nothing was ever transferred. | Starting at the symptom rather than at the first failed stage. | Work stages one to five in order and record the status at each. The first failure is where the fix belongs. |
| Recalculation produces no change. | Calculation runs on data entry validation accepted, so a pending exception blocks it. | Resolve the entry exception, then recalculate. |
| An entry against a closed project saves cleanly and fails only at transfer. | Project and payroll validations do not run on save by default. | Configure validation on the relevant time card actions, and confirm the consumer's precondition before saving. |
Rollback
Configuration in a live tenant is reversible only if somebody wrote down how.
- If a diagnostic change was made while investigating — for example adjusting a rule set — record it and revert it before closing, unless the change is the intended fix.
- Do not correct a downstream figure directly. Correct the time card and let the chain re-run, so payroll and project costing remain reconcilable.
Security notes
- Time data is worker-confidential. Restrict diagnostic access to the affected worker's records and log the access.
- Diagnostic changes to rules affect a whole population. Record every change made during investigation, with a rollback note, before proceeding.
Time and Labor processing chain
Each stage feeds the next, in order. A downstream symptom means the failure was upstream.
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.
Time consumers and the transfer
Three consumers receive the same validated time, and which of them receive it for a given population is decided by the time consumer set.
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.