SAP HCM

HCM manages employee data and HR processes: personnel administration (master data, hiring, changes), organizational management (the org structure of positions and units), time management (working time, absences), and payroll (calculating and paying salaries, with country-specific legal rules).

• Personnel Administration: employee master data and actions.
• Organizational Management: positions, jobs, org units.
• Time Management: working time and absences.
• Payroll: pay calculation (country-specific).
• Employee/manager self-service.

HCM does not store an employee as one wide record. It stores a set of infotypes, each a small record with its own validity dates, and the employee is the sum of them over time. Once that clicks, the rest of the module follows.

The ones you meet immediately are 0000 Actions, the history of what happened to this person, 0001 Organizational Assignment, which links them to a position, cost centre and personnel area, 0002 Personal Data, 0006 Addresses, 0007 Planned Working Time and 0008 Basic Pay.

Each infotype is dated, so a pay rise is not an overwrite: it is a new 0008 record starting on the effective date, with the old one delimited the day before. That is why HCM can answer what somebody earned two years ago without an audit table, and why deleting a record is almost never the right fix.

Time constraints govern how many records may exist at once. Some infotypes must have exactly one valid record at all times, some may have none, some may overlap. Fighting a time constraint error usually means the correction being attempted is not the one the data needs.

PA30 maintains employee master data and PA20 displays it. PA40 runs personnel actions, which is how a hire, a transfer or a leaving is done, because an action walks you through the infotypes that must be updated together.

Organizational management has its own world. PPOME is the org and staffing editor, where org units, positions and jobs are maintained as objects with relationships between them. Those objects live in HRP1000 and their relationships in HRP1001, which is a different shape from the PA tables and catches people out.

Time evaluation runs through PT60 and payroll through the PC00 transactions. Employee master tables follow the infotype numbering directly, so infotype 0001 is table PA0001.

Half an hour on a training system, and it teaches the infotype model better than any diagram.

1. Run PA40 and choose the hiring action. Give a start date and work through the screens the action presents.
2. Notice you are not choosing infotypes. The action decides which ones are mandatory and in what order, which is exactly why actions exist.
3. When it finishes, open PA20 and step through 0000, 0001, 0002 and 0008. Each has a validity period starting on your hire date.
4. Now run a pay change through PA30 on infotype 0008 with a later start date. Look at the overview: two records, adjacent, not one overwritten.
5. Open PPOME and find the position the employee was assigned to. The link between person and position is what drives reporting lines and much of the authorisation model.

HCM integrates with FI/CO (payroll posts costs to finance), and organizational data underpins workflows and authorizations across SAP. For new deployments, SuccessFactors (cloud) handles most HR, often with core/payroll scenarios integrated back to S/4HANA.

Two integrations do the heavy lifting. Payroll results post to FI as journal entries and to controlling as costs against the cost centre on infotype 0001, so a wrong org assignment is a finance problem as much as an HR one. And organizational management underpins workflow and authorisation across the whole system, which is why an unfilled position quietly breaks approval routing somewhere else entirely. See SAP master data for how employee records sit alongside the other master objects.

• How tightly PA and OM are integrated. Full integration means every employee holds a position and the org chart is real. Partial integration is quicker to start and leaves you maintaining two versions of the truth.
• Positive or negative time recording. Positive records every hour worked. Negative records only the exceptions, absences and overtime. Negative is far less effort and is wrong for anywhere that pays by the hour.
• Payroll in house or outsourced. Running it in SAP keeps the detail and the compliance burden. Outsourcing moves both and creates an interface to maintain.
• What happens to history at go-live. Loading only current records is cheap and means the system cannot answer questions about last year.

Learn HCM by following its end-to-end process, its master data, its configuration (in SPRO), and its integration points with finance and neighbouring modules. Hands-on practice in a training system is essential.

In most modules an authorisation question is about which transactions somebody may run. In HCM it is also about which people they may see, and that second dimension is what makes it difficult.

Access is typically restricted by organisational assignment, so a manager sees their own org unit and below, and a payroll administrator sees a personnel area. Structural authorisations enforce that through the organisational structure itself, which means the org chart is not just documentation: it is a security object.

It goes further down than the record. Somebody may legitimately need to see an employee and not their salary, so access is granted per infotype, and sometimes per field within one. That is why infotype 0008 is treated differently from 0006 in almost every design.

The practical consequence is that an org change quietly changes who can see what. Moving a position between org units can widen or narrow a manager's visibility without anybody touching a role, and that is worth testing after any structural change rather than assuming.

Payroll has a reputation for being impenetrable, and the core loop is simpler than it looks.

It reads the employee's infotypes for the period, applies the rules for their country and grouping, and produces a result: gross pay, deductions, statutory contributions, net pay. The rules live in schemas and personnel calculation rules, which are the configuration people find intimidating, and most projects change far less of them than expected because the country versions ship with the legal logic already in place.

Two behaviours cause most of the questions. Results are stored per period and per employee, so a change dated into a closed period triggers retroactive accounting, which recalculates the affected periods and posts the difference in the current one. And the payroll control record locks the period while a run is in progress, which is why master data changes are refused mid-run rather than being silently queued.

The output posts to finance as a journal, summarised by cost centre and wage type, which is where HCM meets the general ledger.

• Learning screens, not the end-to-end process.
• Ignoring the finance integration that every logistics module has.
• Skipping master-data setup that the process depends on.

• Correcting data by deleting a record. Delimiting and creating a new one keeps the history that payroll and audit rely on.
• Forgetting retroactive accounting. A change dated in a closed payroll period triggers a recalculation, and that is the intended behaviour rather than a fault.
• Treating authorisations as somebody else's problem. In a module holding salaries and personal data, they are part of the design.

SuccessFactors is SAP's strategic direction for human resources, and most new customers start there. On-premise HCM did not disappear: it runs on S/4HANA as a compatibility scope with a published maintenance horizon, and a great many organisations keep payroll on-premise while moving core HR to the cloud. That hybrid is the normal shape, which makes the boundary between the two the useful thing to understand. See SAP SuccessFactors for the cloud side.

Reading infotypes is the start, and configuring an action and its payroll posting so the numbers reach finance correctly is the part you do in the course.