Results for “psa_acct_map_header_pk”

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

Overview

PSA_MF_ACCT_MAP_HEADER_ALL is a Public Sector Financials (PSA) table that stores the header records for Multi-Funds Account Mapping definitions in Oracle E-Business Suite 12.1.1 and 12.2.2. Multi-Funds processing is a public-sector-specific capability that allows a single transaction or document to be distributed across multiple funds, each with its own accounting derivation overrides. This table anchors that configuration by holding one header row per account mapping definition, which downstream detail lines and fund-level rules reference.

From a Data Vault modeling perspective, the mined relationship data classifies this object heuristically as a standalone entity — meaning no inbound or outbound foreign key dependencies were detected in the documented schema. As a modeling suggestion, this would typically be treated as a hub-like construct, since the table carries its own primary key (PSA_ACCT_MAPPING_ID) and no obvious parent reference. The absence of foreign keys does not imply isolation; it indicates that linkage to other PSA objects is likely enforced at the application layer or by convention rather than by declarative constraints.

Key Information Stored

The table has 9 documented columns. The most significant are:

• PSA_ACCT_MAPPING_ID — the single-column surrogate primary key, enforced through PSA_ACCT_MAP_HEADER_PK. It uniquely identifies each Multi-Funds account mapping header and is the value carried into detail and rule tables.
• DOCUMENT_CODE — identifies the transaction or document type to which the mapping applies. This is the principal business-key candidate, since mapping definitions are normally scoped by the document they govern.
• LOOKUP_CODE — a reference to a lookup value that further qualifies the mapping, for example the mapping category or derivation method. Together with DOCUMENT_CODE this forms the practical business identifier for a mapping header.
• ORG_ID — the operating unit (multi-org) partition, enabling the same mapping concept to be defined differently per operating unit.
• LAST_UPDATE_DATE, LAST_UPDATED_BY — WHO columns recording the most recent modification timestamp and the user who made it, essential for audit and incremental extraction.
• CREATION_DATE, CREATED_BY — WHO columns capturing the original insert timestamp and creating user.
• LAST_UPDATE_LOGIN — the login identifier associated with the last update, completing the standard EBS audit set.

Common Use Cases and Queries

Typical usage centers on auditing Multi-Funds configuration and reconciling mapping definitions across operating units. A frequent pattern is retrieving all headers for a given document type:

• SELECT psa_acct_mapping_id, document_code, lookup_code, org_id FROM psa.psa_mf_acct_map_header_all WHERE document_code = :p_doc_code AND org_id = :p_org_id;
• Point-in-time change tracking using the audit columns: SELECT * FROM psa.psa_mf_acct_map_header_all WHERE last_update_date >= :p_since;
• Supporting data-conversion and setup migration, where rows are loaded per operating unit and validated against lookup values.
• Feeding reporting extracts that explain why a given public-sector document was distributed across multiple funds.

Related Objects

Because the documented relationship data marks this object as standalone, no formal foreign keys are available to enumerate. The following are the most significant associated objects, joined on the columns indicated:

• PSA_MF_ACCT_MAP_LINES_ALL (or equivalent detail table) — joins on PSA_ACCT_MAPPING_ID to supply the fund-level mapping lines belonging to each header.
• PSA_MF_ACCT_MAP_RULES — joins on PSA_ACCT_MAPPING_ID to define derivation rules applied to the mapping.
• FND_LOOKUP_VALUES — joins on LOOKUP_CODE to resolve the meaning of the lookup reference.
• HR_OPERATING_UNITS / FND_ORG_ACCESS — joins on ORG_ID to resolve the operating unit and enforce security.
• FND_USER — joins on CREATED_BY and LAST_UPDATED_BY to resolve user names in audit reports.

Where an Oracle-provided API exists for maintaining Multi-Funds mapping setup, it should be preferred over direct DML to preserve integrity across the header and detail tables.