Results for “document_user”

6 results




Overview
Explore in AI Chat

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

Overview

APPS.AR_IDEP_COMMITMENT_USAGE is a reporting view in the Oracle E-Business Suite Receivables (AR) module. It exposes the party-level relationships that link Oracle Trading Community Architecture (TCA) party records to deposit-type transactions recorded in Receivables. Specifically, the view returns rows where a party is associated with a customer transaction through a relationship whose object type is DEPOSIT and whose relationship type is either DOCUMENT_OWNER or DOCUMENT_USER. This makes the view the canonical source for identifying which parties own or are authorized users of a given deposit commitment instrument.

The name "IDEP" refers to the intercompany deposit / commitment instrument processing used by Receivables, and "COMMITMENT_USAGE" reflects the view's purpose: revealing how parties consume or are bound to commitment documents. Because it joins TCA relationship data to transaction data, the view is most commonly consumed by reconciliation reports, customer statements, integration extracts, and commitment utilization reporting rather than by core transaction processing. The search term "document_user" corresponds directly to one of the two relationship types the view filters on, indicating the view is frequently queried to enumerate document users for a deposit.

Underlying Base Objects

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

  • HZ_PARTIES (SYNONYM) — the TCA party master, supplying party_id, party_name, email_address, and the rowid alias used as the view's first column.
  • HZ_RELATIONSHIPS (SYNONYM) — the TCA relationship model that connects a subject party to an object transaction, supplying relationship_type, start_date, and end_date.
  • RA_CUSTOMER_TRX_ALL (SYNONYM) — the Receivables transaction header, supplying customer_trx_id and linking the deposit object to the relationship.
  • ARPT_SQL_FUNC_UTIL (PACKAGE) — a Receivables SQL utility package whose GET_LOOKUP_MEANING function translates the relationship type code into its descriptive lookup meaning.

The joins are constrained by subject_type in ('PERSON','ORGANIZATION'), subject_table_name = 'HZ_PARTIES', object_type = 'DEPOSIT', object_table_name = 'RA_CUSTOMER_TRX_ALL', and relationship_type in ('DOCUMENT_OWNER','DOCUMENT_USER'). Note that the transaction join condition in the documented view text, trx.customer_trx_id = trx.customer_trx_id, is a self-referential tautology; this is a known artifact in the view definition and does not restrict rows. The effective linkage to the transaction is instead driven by rel.object_id = trx.customer_trx_id.

Key Columns

  • ROWID — the rowid of the HZ_PARTIES row, useful for direct party lookups.
  • CUSTOMER_TRX_ID — the Receivables transaction identifier for the deposit document.
  • PARTY_ID — the unique identifier of the party associated with the deposit.
  • EMAIL_ADDRESS — the party's email, common in notification and statement extracts.
  • PARTY_NAME — the display name of the party.
  • RELATIONSHIP_TYPE — the raw code, either DOCUMENT_OWNER or DOCUMENT_USER.
  • RELATIONSHIP_MEANING — the decoded lookup meaning returned by ARPT_SQL_FUNC_UTIL.GET_LOOKUP_MEANING for the PARTY_RELATIONS_TYPE lookup.
  • START_DATE / END_DATE — the validity window of the relationship, enabling effective-dated reporting.

Common Use Cases and Queries

Typical scenarios include identifying owners and users of a deposit commitment, extracting contact details for customer communications, and auditing active versus expired document relationships. A representative query filtering the document_user relationship type follows:

SELECT customer_trx_id,
       party_id,
       party_name,
       email_address,
       relationship_meaning,
       start_date,
       end_date
  FROM apps.ar_idep_commitment_usage
 WHERE relationship_type = 'DOCUMENT_USER'
   AND NVL(end_date, SYSDATE + 1) > SYSDATE
 ORDER BY customer_trx_id, party_name;

Because the view exposes both relationship types, an aggregate query can count owners and users per transaction or report parties who appear as users across multiple deposits. Analysts should treat the view as read-only, recognize its dependency on TCA relationship data quality, and be aware that columns such as email_address and party_name are sourced directly from HZ_PARTIES at query time.