Results for “adj_start_date”

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

Overview

PN_ADJUSTMENT_DETAILS is a transactional table in the Oracle EBS Property Manager (PN) module, owned by the PN schema. It stores the line-level detail records that make up an adjustment, where an adjustment represents a financial or contractual change applied to payment items, payment terms, or lease-related obligations. Each row captures a single adjustment component tied to a summary header, a payment item, and an associated payment terms history record, including the effective date range and monetary amount of the adjustment.

The table functions as a child of PN_ADJUSTMENT_SUMMARIES, providing the granular breakdown that the summary aggregates. It also serves as an intersection point linking payment items to payment terms history, which supports the interpretation that adjustment details connect multiple business entities rather than acting as a standalone descriptive record. From a Data Vault modeling perspective, the mined foreign key structure suggests classification as a link table: it resolves relationships among payment items, adjustment summaries, and payment terms history, carrying its own descriptive attributes (dates and amount). This classification is a modeling suggestion derived heuristically from the FK topology, not a declared Oracle design intent.

Key Information Stored

The documented physical schema contains 13 columns. The most significant include:

• ADJUSTMENT_DETAIL_ID — the surrogate primary key, enforced by PN_ADJUSTMENT_DETAILS_PK. It is also the sole column in the unique index PN_ADJUSTMENT_DETAILS_U1, making it the only documented business-key candidate.
• ADJUSTMENT_SUMMARY_ID — foreign key to PN_ADJUSTMENT_SUMMARIES, tying the detail line to its parent adjustment header.
• PAYMENT_ITEM_ID — foreign key to PN_PAYMENT_ITEMS_ALL, identifying the payment item being adjusted.
• TERM_HISTORY_ID — foreign key to PN_PAYMENT_TERMS_HISTORY, linking the adjustment to the applicable payment terms version.
• ADJ_START_DATE and ADJ_END_DATE — the effective date range over which the adjustment applies.
• ADJUSTMENT_AMOUNT — the monetary value of the adjustment detail line.
• GROUP_NUM — a grouping identifier used to cluster related detail lines.
• Audit columns CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN — standard WHO columns recording insert and update provenance.

Common Use Cases and Queries

Typical usage centers on reconstructing adjustment activity for a payment item or summarizing adjustment amounts by summary header. A common reporting pattern joins details to their parent summary:

• Listing all detail lines for a given adjustment summary: SELECT * FROM PN_ADJUSTMENT_DETAILS WHERE ADJUSTMENT_SUMMARY_ID = :id
• Aggregating adjustment amounts per summary: SELECT ADJUSTMENT_SUMMARY_ID, SUM(ADJUSTMENT_AMOUNT) FROM PN_ADJUSTMENT_DETAILS GROUP BY ADJUSTMENT_SUMMARY_ID
• Tracing adjustments applied to a payment item within a date range, filtering on ADJ_START_DATE and ADJ_END_DATE.
• Auditing changes using the WHO columns to identify who last modified a detail line and when.

Related Objects

• PN_ADJUSTMENT_SUMMARIES — parent header table; join on ADJUSTMENT_SUMMARY_ID.
• PN_PAYMENT_ITEMS_ALL — payment item master; join on PAYMENT_ITEM_ID.
• PN_PAYMENT_TERMS_HISTORY — payment terms version history; join on TERM_HISTORY_ID.
• PN_ADJUSTMENT_DETAILS_PK and PN_ADJUSTMENT_DETAILS_U1 — primary and unique indexes on ADJUSTMENT_DETAIL_ID.