Results for “hz_relationship_val_gt”

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

Overview

HZ_RELATIONSHIP_VAL_GT is a table owned by the AR (Receivables) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its name follows the EBS/ETRM convention for a global temporary (GT) staging structure, and the presence of a TEMP_ID column reinforces that this is a transient workspace holding relationship rows that are loaded, validated, and processed during a batch run before being committed to permanent relationship storage. The name associates it with the Trading Community Architecture (TCA) HZ_RELATIONSHIP family, which manages party-to-party and party-to-object associations such as customer contacts, account contacts, and cross-party links used throughout Receivables, Order Management, and CRM flows.

The documented catalog lists 38 columns under owner AR, and the ETRM Data Vault classification (mined heuristically from the foreign-key footprint) is standalone. In Data Vault terms this suggests the object is best modeled as an independent staging structure rather than a hub, link, or satellite, because it does not carry a natural business key with dependent descriptive history of its own; it is a working set defined by its relationship payload.

Key Information Stored

Because this is a staging table, its columns mirror the attributes required to construct a relationship record. Three identifier columns anchor each row:

• TEMP_ID — the batch/run identifier; foreign key to FV_LOCKBOX_IPA_TEMP, allowing rows to be grouped and purged per processing run.
• TEMP_PARTY_ID — the transient party identifier generated or carried through the staging process.
• SUBJECT_ID and SUBJECT_TYPE/SUBJECT_TABLE_NAME — the source subject of the relationship; SUBJECT_ID carries a foreign key to IGS_UC_COM_EBL_SUBJ. The subject side is qualified by a type plus table-name pair, supporting the polymorphic subject reference used in TCA.
• OBJECT_ID, OBJECT_TYPE, OBJECT_TABLE_NAME — the object/target side of the relationship, likewise expressed through a type and table-name pairing.
• RELATIONSHIP_CODE and RELATIONSHIP_TYPE — the business key of the association; these encode which relationship is being staged (for example, a reciprocal or directional party link).
• START_DATE and END_DATE — the validity window applied to the resulting relationship.
• STATUS — the processing state of each staged row.
• CONTENT_SOURCE_TYPE — the origin of the content, distinguishing externally loaded versus internally generated relationship data.
• COMMENTS — free-text annotation for the staged relationship.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE20 — the standard EBS descriptive flexfield (DFF) block used to carry context-specific relationship attributes.
• CREATED_BY_MODULE and APPLICATION_ID — audit columns recording the originating module and application, supporting multi-module provenance and cleanup logic.

The surrogate key for staging purposes is TEMP_ID combined with the row’s own identifiers; the business-key candidates are RELATIONSHIP_CODE plus the subject/object pairing.

Common Use Cases and Queries

The primary use case is inbound relationship creation: rows are inserted into the GT table, validated, then promoted into the permanent TCA relationship structures. Typical inspection patterns include transactional reporting per run and pre-promotion validation:

-- Review all staged rows for one run
SELECT temp_id, subject_id, subject_type,
       object_id, object_type, relationship_code,
       status, start_date, end_date
FROM   ar.hz_relationship_val_gt
WHERE  temp_id = :p_temp_id;

-- Validate rows missing a business key before promotion
SELECT *
FROM   ar.hz_relationship_val_gt
WHERE  relationship_code IS NULL
   OR  subject_id IS NULL;

-- DFF reporting on relationship attributes
SELECT relationship_code,
       attribute_category,
       attribute1, attribute2, attribute3
FROM   ar.hz_relationship_val_gt
WHERE  temp_id = :p_temp_id;

Because the table is transient, queries are best issued while the batch is active; any periodic purge or truncation applied by concurrent programs should be accounted for before joining to historical reporting.

Related Objects

• FV_LOCKBOX_IPA_TEMP — referenced through TEMP_ID; links the staged row to the lockbox/IPA batch context that produced it.
• IGS_UC_COM_EBL_SUBJ — referenced through SUBJECT_ID; the source subject table from which the relationship subject is derived.
• HZ_RELATIONSHIPS — the permanent TCA relationship table into which qualified rows are ultimately promoted.
• HZ_RELATIONSHIP_TYPES — supplies the meaning behind RELATIONSHIP_CODE and RELATIONSHIP_TYPE values.
• HZ_PARTIES — the party master underlying SUBJECT_ID and OBJECT_ID in normal TCA relationship processing.
• HZ_ORG_CONTACTS and HZ_ORG_CONTACT_ROLES — the common consumer of party relationship rows for contact assignments.
• AR_INTERFACE_CONTS_ALL — the Receivables customer/contact interface frequently used in the same load path that populates this staging table.

Direct DML against HZ_RELATIONSHIP_VAL_GT is unsupported; integrations should use the standard TCA relationship APIs and concurrent programs so that validation, DFF handling, and promotion into HZ_RELATIONSHIPS remain consistent with the application logic.