Search Results pay_report_magnetic_procedures




Overview
Explore in AI Chat

Overview

PAY_REPORT_MAGNETIC_PROCEDURES is a Payroll (PAY) module table owned by the HR schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It defines the PL/SQL procedure associated with each magnetic block within a report group, providing the executable logic that drives magnetic media (tape/disk) report generation for statutory payroll reporting such as tax filings, bank transfers, and government submissions. Each row effectively maps a magnetic block to a procedure name within a legislative context, allowing Oracle Payroll to invoke the correct formatting routine when a magnetic report is produced.

In Data Vault modeling terms, the ETRM metadata classifies this object heuristically as a standalone entity. This suggests it may be modeled as a hub-like reference structure with no incoming satellite dependencies, holding descriptive and procedural attributes that qualify the relationship between magnetic blocks and report groups. The classification should be treated as a modeling suggestion rather than a definitive Data Vault design.

Key Information Stored

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

  • REPORT_MAGNETIC_PROCEDURE_ID — the surrogate primary key, uniquely identifying each procedure definition row.
  • MAGNETIC_BLOCK_ID — foreign key to PAY_MAGNETIC_BLOCKS, identifying the magnetic block to which the procedure applies.
  • REPORT_GROUP_ID — foreign key to PAY_REPORT_GROUPS, linking the procedure to its parent report group.
  • PROCEDURE_NAME — the PL/SQL procedure invoked to generate or format the magnetic output for the associated block.
  • SEQUENCE — controls the ordering in which procedures execute when multiple blocks are processed.
  • LEGISLATION_CODE — identifies the legislation (country) under which the procedure is valid, ensuring jurisdiction-specific rules are applied.
  • ZD_EDITION_NAME — the editioning column supporting Oracle EBS online patching (Edition-Based Redefinition) in 12.2.x.

The unique business-key candidate is defined by the composite index PAY_REPORT_MAGNETIC_PROC_PK on (REPORT_MAGNETIC_PROCEDURE_ID, ZD_EDITION_NAME), which combines the surrogate key with the edition name to guarantee uniqueness across editions during online patching. The PK constraint is named PAY_REPORT_MAGNETIC_PROC_PK.

Common Use Cases and Queries

Typical scenarios include troubleshooting magnetic report output, verifying which procedure executes for a given block, and auditing legislation-specific procedural mappings. A representative query joining the table to its parent and referenced objects is:

  • SELECT pmp.procedure_name, pmp.sequence, pmp.legislation_code, pmb.block_name, prg.report_group_name FROM pay_report_magnetic_procedures pmp, pay_magnetic_blocks pmb, pay_report_groups prg WHERE pmp.magnetic_block_id = pmb.magnetic_block_id AND pmp.report_group_id = prg.report_group_id AND pmp.legislation_code = :leg_code ORDER BY pmp.report_group_id, pmp.sequence;
  • Reporting use cases include listing all procedures for a legislation to confirm configuration completeness before running statutory submissions, and identifying sequence gaps or duplicate procedures that could cause magnetic output to be generated incorrectly.
  • Support and implementation teams query this table when diagnosing magnetic report failures, since an incorrect or missing PROCEDURE_NAME is a common cause of runtime errors during magnetic media generation.

Related Objects

The following objects are most significant to PAY_REPORT_MAGNETIC_PROCEDURES, derived from documented foreign key relationships:

  • PAY_MAGNETIC_BLOCKS — referenced via MAGNETIC_BLOCK_ID; defines the magnetic blocks that procedures format.
  • PAY_REPORT_GROUPS — referenced via REPORT_GROUP_ID; the parent grouping of magnetic report definitions.
  • PAY_REPORT_MAGNETIC_PROCED_PK — the primary key constraint/index enforcing uniqueness on (REPORT_MAGNETIC_PROCEDURE_ID, ZD_EDITION_NAME).

These relationships confirm the table's role as a procedural bridge between report groups and magnetic blocks, and should be considered when building retrieval or migration logic involving magnetic payroll reporting configurations.