Search Results action_information27




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PAY_ACTION_INFORMATION is a payroll (PAY) module table owned by the HR schema in Oracle E-Business Suite 12.1.1 and 12.2.2. As documented in the ETRM repository, its purpose is to store archived data generated by legislation-specific payroll processes. The table acts as a repository for legislative "action information" — structured values that payroll/localization code needs to persist outside the transactional payroll run, typically for tax reporting, statutory declarations, and archived calculation context.

The table is a wide, generic container. Rather than defining a dedicated column for every legislative attribute, it exposes a category column (ACTION_INFORMATION_CATEGORY) plus thirty generic slots (ACTION_INFORMATION1 through ACTION_INFORMATION30). This design is commonly referred to as a descriptive flexfield–style or DDF-backed archive pattern: the meaning of each numbered slot is determined at runtime by the combination of jurisdiction, tax unit, and category. Because of this, the table is essentially an EAV-style satellite rather than a strictly normalized entity.

The supplied metadata classifies this object heuristically as a standalone data vault entity, meaning no foreign keys were mined into the FK structure. As a modeling suggestion, it would most naturally map to a satellite attached to a payroll action or tax context hub, with the category and jurisdiction columns acting as descriptive satellite attributes. The standalone classification should be treated as a caution: consumers cannot rely on declarative referential integrity when joining.

Key Information Stored

The only documented primary key is the surrogate ACTION_INFORMATION_ID (index PAY_ACTION_INFORMATION_PK). This is the row identifier and should never carry business meaning. The documented metadata also lists a business-key candidate, PAY_ACTION_INFORMATION_U1, composed of ACTION_CONTEXT_ID and ACTION_CONTEXT_TYPE; this combination identifies the specific payroll context (for example, a particular assignment, run, or action) to which the archive row belongs.

The most significant columns are:

  • ACTION_INFORMATION_ID — surrogate primary key, system-generated.
  • ACTION_CONTEXT_ID and ACTION_CONTEXT_TYPE — the business key identifying the payroll context the archive belongs to.
  • ACTION_INFORMATION_CATEGORY — discriminates the meaning of the numbered slots; the single most important column for interpreting the row.
  • ACTION_INFORMATION1 … ACTION_INFORMATION30 — up to thirty generic data slots, whose semantics derive from the category and legislation.
  • JURISDICTION_CODE and TAX_UNIT_ID — tie the archived information to a legislative jurisdiction and tax reporting unit.
  • SOURCE_ID and SOURCE_TEXT — identify and describe the originating record or process.
  • TAX_GROUP — groups the record for tax aggregation/reporting purposes.
  • ASSIGNMENT_ID — links the archive row to the assignment whose payroll triggered it.
  • EFFECTIVE_DATE and INSTANCE_ID — date-effectiveness and the source instance identifier (useful in multi-instance or ODS contexts).
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the Oracle framework (WHO columns LAST_UPDATED_BY, LAST_UPDATE_DATE, CREATED_BY, CREATION_DATE, LAST_UPDATE_LOGIN follow the standard pattern).

Common Use Cases and Queries

Typical consumption patterns are statutory reporting and reconciliation, audit reconstruction of what a payroll run archived, and data validation of generic slots.

  • Retrieve all archive rows for a context — join on the documented business key:
SELECT *
FROM   hr.pay_action_information
WHERE  action_context_id   = :p_context_id
AND    action_context_type = :p_context_type;
  • Filter by jurisdiction and category:
SELECT action_information_id, action_information1, action_information2, tax_group
FROM   hr.pay_action_information
WHERE  jurisdiction_code          = 'US'
AND    action_information_category = :p_category;
  • Assignment-level reporting — constrain by ASSIGNMENT_ID and EFFECTIVE_DATE for period-accurate extracts.
  • Generic-slot auditing — scan for rows where key numbered slots are null, a common defect when localization rules change.

Because the table is metadata-driven, always resolve the category before interpreting any ACTION_INFORMATIONn column; querying slots without the category will return misleading results.

Related Objects

With no mined foreign keys, relationships are logical rather than enforced. The most significant objects are:

  • PAY_ACTION_INFORMATION_PK / PAY_ACTION_INFORMATION_U1 — the documented primary key and unique (business-key) index.
  • PER_ASSIGNMENTS_F — joins logically on ASSIGNMENT_ID to resolve the employee assignment.
  • PAY_TAX_UNITS_F — joins on TAX_UNIT_ID to resolve the tax reporting unit.
  • PAY_ASSIGNMENT_ACTIONS — the payroll action context likely referenced by ACTION_CONTEXT_ID/ACTION_CONTEXT_TYPE.
  • FYI: legislative/localization tables (jurisdiction-specific) — resolve ACTION_INFORMATION_CATEGORY semantics.
  • PAY_PAYROLL_ACTIONS / PAY_RUN_RESULTS — often the process that caused archive rows to be written, joined indirectly via context and assignment.

Consumers should validate joins explicitly, since the standalone classification means no database-enforced referential integrity exists.