Results for “automatically_generated”

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

Overview

AR_ADJUSTMENTS_ALL_MRC_V is a multi-reporting-currency (MRC) view owned by the APPS schema in Oracle E-Business Suite Receivables. It presents adjustment records from the primary set of books alongside their corresponding reporting-currency equivalents, allowing concurrent access to both the operative and the converted accounting representations of each adjustment. The view is documented in ETRM 12.2.2 and carries the status VALID; in the ETRM metadata it is described as "Retrofitted," indicating it was recreated or repointed as part of an upgrade or patch cycle rather than derived from a fresh design. The view belongs to the AR - Receivables product family and is commonly referenced by inquiry screens, audit reports, and integration extracts that must reconcile functional-currency adjustments against their reporting-currency counterparts. Because it is a view rather than a table, it carries no independent storage, has no DML of its own, and inherits the security profile of its underlying synonyms.

Underlying Base Objects

The view is defined over two documented base objects, both referenced in ETRM as synonyms: AR_ADJUSTMENTS_ALL and AR_MC_ADJUSTMENTS. AR_ADJUSTMENTS_ALL holds the primary ledger adjustment records, and AR_MC_ADJUSTMENTS holds the reporting-currency conversion rows keyed by SET_OF_BOOKS_ID. The join is performed on ADJUSTMENT_ID, with the reporting-currency side further filtered by the current MRC context. That context is derived from USERENV('CLIENT_INFO'), from which characters 45 through 54 are extracted, trimmed, and converted to a number; if the resulting value is null, the predicate defaults to -99, a sentinel that matches no valid set of books. This mechanism ensures the view returns reporting-currency rows only for the set of books selected by the MRC responsibility, and returns nothing when no MRC context is established.

Key Columns

The projection blends primary-side and MRC-side columns. From the primary adjustment, the view exposes ADJUSTMENT_ID, AMOUNT, APPLY_DATE, GL_DATE, CODE_COMBINATION_ID, TYPE, ADJUSTMENT_TYPE, STATUS, CUSTOMER_TRX_ID, PAYMENT_SCHEDULE_ID, REASON_CODE, POSTABLE, APPROVED_BY, ADJUSTMENT_NUMBER, ORG_ID, and the standard audit columns LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, CREATED_BY, and CREATION_DATE, plus the WHO columns for last update. The APPROVED_BY column is the approval identifier for the adjustment and is frequently searched by users auditing who authorized a given write-off or debit memo. From AR_MC_ADJUSTMENTS the view supplies SET_OF_BOOKS_ID, GL_POSTED_DATE, POSTING_CONTROL_ID, ACCTD_AMOUNT, and the parallel MRC_GL_POSTED_DATE, MRC_POSTING_CONTROL_ID, and MRC_ACCTD_AMOUNT columns. Attribute and global attribute flexfields (ATTRIBUTE1 through ATTRIBUTE15, GLOBAL_ATTRIBUTE1 through GLOBAL_ATTRIBUTE20), USSGL transaction code fields, document sequence fields, and LINK_TO_TRX_HIST_ID complete the projection.

Common Use Cases and Queries

Typical uses include MRC reconciliation reports, approval audits, and extracts feeding downstream accounting or data-warehouse processes. Because the view depends on an MRC session context, queries must be executed from a responsibility configured for multiple reporting currencies; otherwise the default -99 predicate yields no rows.

• Audit by approval: SELECT ADJUSTMENT_ID, ADJUSTMENT_NUMBER, APPROVED_BY, AMOUNT, ACCTD_AMOUNT, SET_OF_BOOKS_ID FROM AR_ADJUSTMENTS_ALL_MRC_V WHERE APPROVED_BY IS NOT NULL AND TRUNC(APPLY_DATE) >= TRUNC(SYSDATE)-30;
• Unposted MRC adjustments: SELECT ADJUSTMENT_ID, STATUS, POSTABLE, GL_POSTED_DATE, MRC_GL_POSTED_DATE FROM AR_ADJUSTMENTS_ALL_MRC_V WHERE GL_POSTED_DATE IS NULL ORDER BY ADJUSTMENT_ID;
• Converted amount comparison by set of books: SELECT SET_OF_BOOKS_ID, SUM(AMOUNT) FUNCTIONAL, SUM(ACCTD_AMOUNT) CONVERTED FROM AR_ADJUSTMENTS_ALL_MRC_V GROUP BY SET_OF_BOOKS_ID;

Joins to AR_ADJUSTMENTS_ALL on ADJUSTMENT_ID or to RA_CUSTOMER_TRX_ALL on CUSTOMER_TRX_ID are common when transaction-level reporting is required.