Explain Fusion HCM Extract and Payroll Interface Basics in Oracle Applications

31 / 60

Fusionadvanced

Fusion HCM Extract and Payroll Interface Basics

Explain how Fusion HCM Extract is used to move HR/payroll data out of Fusion for downstream consumption

HCM Extract pulls structured data out of Fusion HCM — a payroll file for an external provider, a benefits carrier feed, a report OTBI cannot produce.

HCM Extract is like a customizable form-letter mail-merge system for HR data: you define what data fields to pull and any conditional business rules (Fast Formula), design a template for how it should look (BI Publisher), and specify how each 'letter' gets delivered (email, SFTP, etc.) — all without writing a bespoke program from scratch each time.

Key Concepts

It replaces the custom PL/SQL extract scripts that EBS HR implementations accumulated.

Three layers.

    Data Model          what to extract: the hierarchy, the fields,
                        the criteria
    BI Publisher template  how to format it
    Delivery            where it goes: UCM, SFTP, email

The separation is the useful part. The same data model can feed two templates producing different formats for two vendors, without extracting twice.

The hierarchy matters. An extract is not a flat query. It is nested — a payroll extract is employees, each with assignments, each with elements and balances.

    Employee
      Assignment
        Element Entry
        Balance

That structure is what the template then formats.

Fast Formula appears throughout, and it is the same formula language as EBS Payroll. It decides what to include and derives values:

    IF hire_date > extract_start_date THEN
        include = 'Y'
    ELSE
        include = 'N'

So a Fusion HCM technical consultant needs both the Extract framework and Fast Formula. Fast Formula knowledge from EBS Payroll transfers directly, which is worth saying.

Incremental extraction is the design question for a payroll interface.

    full extract        everyone, every cycle. Simple, and the vendor
                        reprocesses unchanged records every time.
    changes-only        the framework tracks what changed since the
                        last run and sends only that.

Changes-only is what a bi-weekly interface to an external provider normally needs. It requires the run to be tracked properly — a failed run that was not reset either resends everything or, worse, skips a period.

The realistic scenario to be ready for. A fortnightly payroll file: which employees, which elements, what happens to a mid-cycle joiner or leaver, how corrections to a previous period are sent, and what happens when the run fails halfway.

The framework handles the mechanics. Those questions are the design.

What the interviewer is probing.1. "What is HCM Extract for?" Probing: the purpose. Stalls: "Reports." Moves up: defining a dataset and delivery for outbound interfaces — benefits providers, third-party payroll, downstream systems.

2. "What are the main components?" Probing: the structure. Stalls: "A query." Moves up: the extract definition with blocks and records, fast formulas for derivation, and a delivery option for format and destination.

3. "How do you send only what changed?" Probing: the key capability. Stalls: "Full file each time." Moves up: changes-only mode, which compares against the previous run — though it needs care when the definition itself changes.

4. "What is the usual troubleshooting step?" Probing: practical skill. Stalls: "Rerun it." Moves up: run it for one person with the XML output retained, so you can see exactly which block or fast formula produced the wrong value.