Results for “adjusted_amount”

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

Overview

The OE_ACCRUALS_V view is a reporting and integration object in the Oracle E-Business Suite Order Management (ONT) module, owned by the APPS schema and marked VALID in both 12.1.1 and 12.2.2. Its stated purpose is to expose accrued price adjustments within Order Management, presenting a consolidated, query-ready projection of the price adjustment lines that have been accrued and applied against sales orders. Because the accrual logic is otherwise fragmented across several transactional tables, this view assembles those records into a single denormalized structure suitable for accrual reconciliation, rebate and promotion analysis, and downstream integration into financial and settlement processes.

Underlying Base Objects

Per the documented ETRM metadata, the view is defined over the following base objects:

• OE_PRICE_ADJUSTMENTS — the driving table that stores individual price adjustment (modifier) records, including the accrual and applied flags, list references, arithmetic operators, operands, and benefit amounts.
• OE_ORDER_HEADERS — the order header, supplying ORG_ID and joining on HEADER_ID. This is the object referenced by the user's search term "oe_order_headers".
• OE_ORDER_LINES_ALL — order line detail, joined on LINE_ID via an outer join (+) and used for ordered quantity, line category (e.g., RETURN), and return sign reversal logic.
• OE_SOLD_TO_ORGS_V — a supporting view providing customer identifiers and names, joined on ORGANIZATION_ID = SOLD_TO_ORG_ID.
• OE_PRICE_ADJ_ASSOCS — price adjustment associations, used in the UNION branch to capture associated or dependent adjustments.

The view text is a UNION of two similar queries. Both restrict records with ACCRUAL_FLAG = 'Y' and APPLIED_FLAG = 'Y' and exclude list line types 'CIE' and 'PBH'. The second branch adds OE_PRICE_ADJ_ASSOCS and a self-reference to OE_PRICE_ADJUSTMENTS to resolve linked adjustment relationships, ensuring the union captures both directly accrued and associated accrued adjustments without duplication.

Key Columns

• PRICE_ADJUSTMENT_ID, HEADER_ID, LINE_ID — keys linking the accrual back to the adjustment, order header, and order line.
• CUSTOMER_ID, CUSTOMER_NUMBER, NAME — sold-to customer identity sourced through OE_SOLD_TO_ORGS_V.
• LIST_HEADER_ID, LIST_LINE_ID, LIST_LINE_NO — the price list and line against which the adjustment was derived.
• SOURCE_SYSTEM_CODE, ARITHMETIC_OPERATOR, OPERAND — the modifier mechanics that produced the adjustment.
• BENEFIT_QTY, BENEFIT_UOM_CODE — the accrued benefit quantity, with sign reversal (multiplied by -1) when the line category is 'RETURN'.
• ADJUSTED_AMOUNT — extended as ADJUSTED_AMOUNT * NVL(ORDERED_QUANTITY,1), again negated for returns, giving the accrued extended value.
• PRINT_ON_INVOICE_FLAG, EXPIRATION_DATE — presentation and validity attributes.
• REBATE_TRANSACTION_TYPE_CODE, REBATE_TRANSACTION_REFERENCE, REBATE_PAYMENT_SYSTEM_CODE — rebate and settlement references.
• REDEEMED_DATE, REDEEMED_FLAG — indicates whether the accrual has been redeemed.
• ORG_ID — the operating unit, from OE_ORDER_HEADERS, enabling multi-org (MOAC) filtering.

Common Use Cases and Queries

Typical scenarios include reconciling accrued versus redeemed adjustments, feeding accrual balances into financial systems, and auditing rebate/promotion accruals by customer or operating unit.

Accrued adjustments by customer for an operating unit:

• SELECT header_id, line_id, customer_number, name, adjusted_amount, redeemed_flag FROM oe_accruals_v WHERE org_id = :p_org_id;

Outstanding (unredeemed) accruals joining to order headers for order context:

• SELECT a.header_id, oh.order_number, a.name, a.adjusted_amount FROM oe_accruals_v a, oe_order_headers_all oh WHERE a.header_id = oh.header_id AND a.redeemed_flag = 'N';

Rebate accrual detail by transaction reference:

• SELECT header_id, line_id, rebate_transaction_reference, benefit_qty, benefit_uom_code FROM oe_accruals_v WHERE rebate_transaction_type_code IS NOT NULL;

Because the view already applies the ACCRUAL_FLAG and APPLIED_FLAG filters and handles return sign reversal, reporting and integration logic can consume it directly rather than reimplementing the underlying join and sign conventions.