Workforce objects, one row at a time
A workforce plan is employee-job rows with components attached: salary from a grade, plus earnings, benefits, and taxes from a wizard. The ceilings and defaults around those components are documented, and most Workforce surprises come from not knowing them.
Note: Workforce is the part of Planning, Oracle's module where budgets and forecasts are built, that plans people: headcount and everything paid for it. This page is the objects that carry a workforce plan, an employee-job row and the components attached to it.
The whole module is mapped on the Planning index.
◆ The row itself, one employee-job row from the sample world.
One employee-job row from the sample world, the shape everything else on this page attaches to:
| Field | Value | Where it comes from |
|---|---|---|
| Employee | E04412 | Loaded from the HR system, one member per person. |
| Job | Financial Analyst II | The job catalog, when granularity includes Job. |
| Entity | 1010-CL, the Chilean subsidiary | The shared entity tree from the Entity page. |
| Salary | Grade CL-M2, annual basis | Salary grades, defined with a basis of Annual or Hourly, per the configuration checklist. |
| Components | 2 additional earnings, 3 benefits, 2 taxes | The Benefits and Taxes wizard, explained below. |
| FTE / Headcount | 1.0 / 1 | Defaults the load rule sets unless you load values. The trap is on the rules page. |
◆ The four decisions, doc-cited, granularity, the 30-component ceiling, reduction, assumptions.
| Decision | What the doc says |
|---|---|
| Granularity | Employee, Job, or Employee and Job. The choice gates features: Employee Type members (Regular, Contractor, Temporary) exist for Employee-only granularity, and Split-Funded FTE requires Employee or Employee and Job, per the enablement doc. |
| Component count | A maximum of 30 members combined across Additional Earnings, Benefits, and Taxes, per the wizard doc. Size by the maximum any one person receives: Oracle's own example is two employees at 3/3/2 and 5/2/4, so the configuration is 5 earnings, 3 benefits, 4 taxes, per the expense doc. Set for current needs; the numbers can change later. |
| Reducing components | Removing a component removes members from the Account dimension. The doc says snapshot first, and warns that members referenced in customized forms, formulas, or rules will not be removed, which leaves half-deleted wiring behind. Also per doc: give these members no aliases, they are placeholders. |
| Assumptions | Hours per day, week, and year, and the partial payment factor that sets the pay percentage for Maternity status, all settable by scenario, version, entity, and currency, per the configuration checklist. |
The spine numbers these objects carry: budgeted headcount 4,880, which is 4,806 active people plus 74 open requisitions. Total compensation forecast 486.3M, which is salary 371.0 plus benefits 63.9 plus employer taxes 30.2 plus additional earnings 21.2. Both sums foot, and the roster and cost report is where they become answerable questions.
The problem: The planned headcount and the HR system drift apart, and nobody can say where.
What we build: The employee-job rows export nightly and land beside the HR extract, keyed the same way, footed automatically.
What you get: The 4,880 in the plan reconciles to the people who exist, and the gaps come listed by name.
- granularity
- Employee, Job, or both. Gates features, decide early.
- component
- A benefit, tax, or additional earning. Thirty combined, maximum.
- the sizing rule
- Configure for the most any one person receives.
- partial payment factor
- The pay percentage applied to Maternity status.