Search Results pay_au_module_types_u1

Overview

HR.PAY_AU_MODULE_TYPES is an Oracle E-Business Suite seed table that stores the set of module types consumed by the Australian payroll generic processor. The object is owned by the HR schema and registered under the FND Design Data application PAY, with a status of VALID in both EBS 12.1.1 and 12.2.2. Its DDL resides in the APPS_TS_SEED tablespace, reflecting its role as a low-volume, largely static reference table populated at installation and maintained through patching rather than day-to-day transactional activity. Because it defines allowable processor module types rather than transactional payroll events, it functions as a classification or domain table for Australian payroll processing.

Based on the mined foreign key structure and column composition, the heuristic Data Vault classification for this object is hub-leaning. The presence of a single-column surrogate primary key (MODULE_TYPE_ID), a small descriptive payload (NAME, ENABLED_FLAG, DESCRIPTION), and referencing child tables that carry the business keys of dependent records all support treating PAY_AU_MODULE_TYPES as a hub entity in a dimensional or Data Vault model. This is a modeling suggestion only; the physical table remains a standard EBS reference object with WHO audit columns and an editioning column.

Key Information Stored

The table contains eleven documented columns. The most significant are:

• MODULE_TYPE_ID — NUMBER(15), mandatory. System-generated primary key and the unique identifier for each module type.
• NAME — VARCHAR2(30). Business-facing module type name used by the generic processor.
• ENABLED_FLAG — VARCHAR2(30). Indicates whether the module type is currently active; typically Y/N.
• DESCRIPTION — VARCHAR2(80). Free-text explanation of the module type.
• OBJECT_VERSION_NUMBER — NUMBER. System-generated row version that increments on each update, supporting optimistic locking.
• ZD_EDITION_NAME — VARCHAR2(30). Editioning column introduced for EBS 12.2 online patching support, part of the unique index and used in cross-edition queries.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns foreign-keying to FND_USER and FND_LOGINS.

The surrogate primary key is MODULE_TYPE_ID. The documented business-key candidate is the unique index PAY_AU_MODULE_TYPES_U1, defined over (MODULE_TYPE_ID, ZD_EDITION_NAME). In practice the uniqueness is driven by MODULE_TYPE_ID, with ZD_EDITION_NAME ensuring edition-scoped uniqueness under 12.2 patching, which is why searches for "pay_au_module_types_u1" surface this index.

Common Use Cases and Queries

Typical scenarios centre on validating which module types the Australian generic processor may act upon, and on joining dependent records back to their descriptive name. A simple lookup query returns the enabled module types:

• Reference validation — SELECT MODULE_TYPE_ID, NAME FROM HR.PAY_AU_MODULE_TYPES WHERE ENABLED_FLAG = 'Y';
• Discovery of orphaned modules — joining PAY_AU_MODULES to confirm every module references a valid type.
• Reporting joins that resolve MODULE_TYPE_ID to a human-readable NAME for audit or interface extracts.

Because the table is small and seeded, queries are inexpensive; the principal caution is to filter on ZD_EDITION_NAME when interrogating 12.2 environments directly, since a given MODULE_TYPE_ID may appear once per edition during patching.

Related Objects

The following objects reference or depend on PAY_AU_MODULE_TYPES:

• PAY_AU_MODULES — references PAY_AU_MODULE_TYPES via MODULE_TYPE_ID; this is the primary child table carrying processor module configuration.
• WMS_API_HOOKED_ENTITIES — references PAY_AU_MODULE_TYPES via MODULE_TYPE_ID, linking warehouse-management API hooks to module type definitions.
• PAY_AU_MODULE_TYPES# — the editioning synonym/view generated by EBS 12.2 online patching, exposing the edition-specific row set.
• PAY_AU_MODULE_TYPES_PK — primary key constraint on MODULE_TYPE_ID.
• PAY_AU_MODULE_TYPES_U1 — unique index on (MODULE_TYPE_ID, ZD_EDITION_NAME).

No upstream foreign keys are documented, confirming the table's role as a foundational hub reference for Australian payroll module typing.