Results for “friendly_name”

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

Overview

AR_BATCH_REMIT_V is a reporting view owned by the APPS schema in Oracle E-Business Suite Receivables (AR). It presents remittance batch information by combining automatic receipt batch attributes from AR_BATCHES with descriptive lookup values, receipt class and method names, remittance bank account details, and bank or branch party names. The view is registered in ETRM and is marked VALID in both Oracle EBS 12.1.1 and 12.2.2. Its principal role is to support inquiries, custom reports, and interface extracts that require a single, denormalized source of remittance batch data without the need to join the constituent base tables manually. The presence of the FRIENDLY_NAME column from AP_PAYMENT_PROGRAMS is particularly relevant to users who search for the program's friendly name rather than its numeric program identifier.

Underlying Base Objects

The view is defined over a fixed set of base objects in the Receivables, Payables, and Trading Community Architecture schemas. The documented references are:

• AR_BATCHES (SYNONYM) — the primary source, aliased BT, supplying batch identity, dates, currency, control totals, and remittance attributes.
• AR_RECEIPT_CLASSES (SYNONYM) and AR_RECEIPT_METHODS (SYNONYM) — supply receipt class and receipt method names.
• AR_RECEIPT_METHOD_ACCOUNTS_ALL (SYNONYM) — links receipt methods to remittance bank accounts.
• AP_PAYMENT_PROGRAMS (SYNONYM) — referenced twice as PP1 and PP2 to resolve the FRIENDLY_NAME of the automatic transmission and automatic print programs.
• AR_LOOKUPS (VIEW) — used multiple times (RT, LS, LRM) to decode type, status, and remittance method meanings.
• CE_BANK_ACCOUNTS (SYNONYM) and CE_BANK_ACCT_USES_ALL (SYNONYM) — provide bank account name, number, check digits, and bank currency.
• HZ_PARTIES (SYNONYM) and HZ_RELATIONSHIPS (SYNONYM) — provide bank and branch party names and the relationship between them.
• HZ_ORGANIZATION_PROFILES (SYNONYM) — supplies bank and branch numbers.

Each synonym resolves to its corresponding APPS-registered table, ensuring the view respects the standard EBS security and synonym model.

Key Columns

The view exposes batch identifiers and descriptive attributes. Important columns include BATCH_ID, NAME, and TYPE (from the RT lookup), which together identify the remittance batch. BATCH_DATE and GL_DATE establish the accounting and operational timing. CURRENCY_CODE and CONTROL_AMOUNT/CONTROL_COUNT convey the monetary and volume totals. RECEIPT_CLASS_NAME and RECEIPT_METHOD_NAME provide human-readable classification. AUTO_TRANS_PROGRAM_ID and AUTO_PRINT_PROGRAM_ID are the numeric program identifiers, while AUTO_TRANS_PROGRAM_NAME and AUTO_PRINT_PROGRAM_NAME expose the corresponding FRIENDLY_NAME values from AP_PAYMENT_PROGRAMS. Remittance banking data appears in BANK_ACCOUNT_NAME, BANK_ACCOUNT_NUMBER, BANK_BRANCH_NAME, BANK_NAME, BANK_NUMBER, and BANK_BRANCH_NUM. STATUS and BATCH_APPLIED_STATUS report processing state, and standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) plus ORG_ID support audit and multi-org filtering.

Common Use Cases and Queries

Typical uses include reconciling automatic receipt batches, reviewing remittance bank assignments, and reporting on transmission or print program configuration by friendly name. A representative query is:

• SELECT batch_id, name, type, currency_code, control_amount, auto_trans_program_name, auto_print_program_name, bank_account_number FROM ar_batch_remit_v WHERE org_id = :p_org_id AND batch_date BETWEEN :p_from AND :p_to;
• SELECT DISTINCT auto_trans_program_name, auto_print_program_name FROM ar_batch_remit_v WHERE auto_trans_program_name IS NOT NULL;
• SELECT name, receipt_class_name, receipt_method_name, bank_name, bank_branch_name FROM ar_batch_remit_v WHERE status = 'APPROVED';

Because the view relies on HZ_ and CE_ base objects, queries should be executed in the APPS schema or through a synonym granted to the reporting user, and should always filter by ORG_ID in multi-org environments to avoid cross-organization data leakage.