Results for “settled_date”

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

Overview

OZF_CLAIM_LINES_HIST_ALL is a Trade Management (OZF) transactional history table in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It stores the historical or versioned state of claim line records — the individual earning, accrual, and settlement lines that make up a customer or supplier claim within the Trade Management claims lifecycle. Where OZF_CLAIM_LINES_ALL holds the current, active claim line rows, OZF_CLAIM_LINES_HIST_ALL preserves prior versions of those lines so that accruals, approvals, settlements, and payment activities can be audited after the fact. The table resides in the OZF schema and is documented as VALID, containing 92 columns in the ETRM 12.2.2 physical schema.

Applied Data Vault classification heuristics, mined from the foreign-key structure, indicate a satellite-leaning profile. The object has a single-column surrogate primary key and a rich set of descriptive and event-timestamp attributes, which is characteristic of a satellite table attached to a hub or link. This is a modeling suggestion only: functionally, the table behaves as a historical snapshot of claim lines, tracking state transitions rather than defining business entities themselves.

Key Information Stored

The surrogate primary key is CLAIM_LINE_HISTORY_ID, enforced by OZF_CLAIM_LINES_HIST_ALL_PK. A unique index, OZF_CLAIM_LINES_HIST_ALL_U1, also covers CLAIM_LINE_HISTORY_ID, making it the documented business-key candidate for the history row itself. The most operationally significant columns include:

• CLAIM_HISTORY_ID — foreign key to OZF_CLAIMS_HISTORY_ALL; ties the line history to the parent claim history event.
• CLAIM_ID and CLAIM_LINE_ID — foreign keys back to OZF_CLAIMS_ALL and OZF_CLAIM_LINES_ALL, linking history to the live claim and line.
• LINE_NUMBER and SPLIT_FROM_CLAIM_LINE_ID — identify the line and its split lineage.
• AMOUNT, ACCTD_AMOUNT, CLAIM_CURRENCY_AMOUNT — monetary values in entered, accounted, and claim currency.
• CURRENCY_CODE, EXCHANGE_RATE, SET_OF_BOOKS_ID — currency conversion context.
• PAYMENT_STATUS, PAYMENT_REFERENCE_ID, VOUCHER_ID, APPROVED_FLAG, APPROVED_DATE — approval and settlement state.
• VALID_FLAG — indicates whether the historical line is still considered valid.
• UTILIZATION_ID and SECURITY_GROUP_ID — fund utilization and multi-org security references.
• ORG_ID — operating unit context for multi-org access.

Standard EBS audit columns (OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, CREATED_BY, REQUEST_ID, PROGRAM_ID) and the ATTRIBUTE1 through ATTRIBUTE15 descriptive flexfield columns complete the structure.

Common Use Cases and Queries

The dominant use case is claim settlement audit and trend reporting. Analysts reconstruct the sequence of changes to a claim line over time, comparing current values in OZF_CLAIM_LINES_ALL against historical snapshots here.

SELECT h.claim_line_history_id, h.claim_line_id, h.line_number,
       h.amount, h.payment_status, h.valid_flag, h.last_update_date
FROM   ozf.ozf_claim_lines_hist_all h
WHERE  h.claim_id = :p_claim_id
ORDER  BY h.last_update_date;

A second pattern joins to the claim history header to produce a full audit trail:

SELECT ch.claim_history_id, h.line_number, h.amount, h.approved_date
FROM   ozf.ozf_claim_lines_hist_all h,
       ozf.ozf_claims_history_all  ch
WHERE  h.claim_history_id = ch.claim_history_id
AND    h.valid_flag = 'Y';

Reporting scenarios include tracking unsettled historical lines, reconciling payment_status transitions against voucher_id, and auditing fund utilization by joining on utilization_id.

Related Objects

• OZF_CLAIMS_HISTORY_ALL — parent claim history; join on CLAIM_HISTORY_ID.
• OZF_CLAIMS_ALL — current claim master; join on CLAIM_ID.
• OZF_CLAIM_LINES_ALL — current claim lines; join on CLAIM_LINE_ID.
• OZF_FUNDS_UTILIZED_ALL_B — fund utilization base table; join on UTILIZATION_ID.
• FND_SECURITY_GROUPS — security group definition; join on SECURITY_GROUP_ID.

These relationships confirm the table's role as a dependent historical satellite anchored to the current claim and line entities through surrogate keys.