Results for “iby_ext_fc_payer_1_0_v”

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

Overview

The view APPS.IBY_EXT_FC_PAYER_1_0_V is a Payments (IBY) module object delivered as part of the Oracle E-Business Suite 12.1.1 and 12.2.2 ETRM (E-Business Suite Technical Reference Manual) repository. It is classified as a VIEW owned by the APPS schema with VALID status. Its purpose is to expose payer (payee) information for funds capture transactions, consolidating party, customer account, account site, and operating unit attributes into a single denormalized presentation suitable for reporting and external integration extraction.

The _1_0_V naming convention indicates that this view represents version 1.0 of an extract-oriented interface, commonly consumed by Oracle Payments funds capture processing as well as by customer-built extracts and BI Publisher reports. Because it joins transactional summary data from IBY_TRXN_SUMMARIES_ALL to HZ (Trading Community Architecture) registry tables, it provides a transaction-to-party perspective that is otherwise distributed across multiple schemas.

Underlying Base Objects

The documented base objects referenced by this view are:

• HR_ALL_ORGANIZATION_UNITS_TL (SYNONYM) — supplies operating unit name and organization identifier.
• HZ_CUST_ACCOUNTS (SYNONYM) — provides the customer account identifier and account number for the payer.
• HZ_CUST_SITE_USES_ALL (SYNONYM) — supplies the customer account site, site use, and location context.
• HZ_PARTIES (SYNONYM) — supplies party identifier, party number, party name, party type, phonetic alternate name, and attribute category.
• IBY_FD_EXTRACT_GEN_PVT (PACKAGE) — invoked through the function GET_PAYEE_TAXREGISTRATION to derive the tax registration number for the payer.
• IBY_TRXN_SUMMARIES_ALL (SYNONYM) — the driving transaction summary table providing TRXNMID, PAYERID, CUST_ACCOUNT_ID, ACCT_SITE_USE_ID, BILL_TO_ADDRESS_ID, and ORG_ID.

All joins to the HZ and HR tables are declared as outer joins (using the legacy (+) operator), meaning the view returns a row for each transaction summary even when the corresponding party, customer account, site use, or operating unit record is absent. The join to HZ_PARTIES is driven by TO_CHAR(HZP.PARTY_ID(+)) = IBY_SUM.PAYERID, reflecting that PAYERID is stored as a character value in the transaction summary table.

Key Columns

• TRXNMID — the transaction summary identifier; the primary driver key.
• PARTY_ID, PARTY_NUMBER, PARTY_NAME, PARTY_TYPE — party identification attributes from HZ_PARTIES.
• ALTERNATE_NAME — a phonetic or alternate name derived conditionally: for organizations the phonetic organization name; for persons the concatenated phonetic first and last names.
• CUST_ACCOUNT_ID, ACCOUNT_NUMBER — customer account context.
• ORG_ID, OPERATING_UNIT — the operating unit owning the transaction.
• CUST_ACCT_SITE_ID, ACCOUNT_SITE_USE_ID, LOCATION — customer account site and site use details.
• BILL_TO_ADDRESS_ID — the bill-to address identifier from the transaction summary.
• TAX_REGISTRATION_NUMBER — computed via IBY_FD_EXTRACT_GEN_PVT.GET_PAYEE_TAXREGISTRATION(HZP.PARTY_ID, 'CUSTOMER'); this is the column most relevant to the search term and resolves the payer's tax registration identifier in the CUSTOMER registration context.
• LE_REGISTRATION_NUMBER — a NULL placeholder column reserved for legal entity registration number exposure.
• PARTY_ATTR_CAT — the party attribute category from HZ_PARTIES.

Common Use Cases and Queries

Typical uses include funds capture reconciliation, payer tax registration reporting, and third-party extract generation. A representative query retrieving the tax registration number for a given transaction is:

SELECT trxnm_id, party_name, tax_registration_number FROM iby_ext_fc_payer_1_0_v WHERE trxnm_id = :p_trxnm_id;

To report payers by operating unit with their tax registration numbers:

SELECT operating_unit, party_number, party_name, tax_registration_number FROM iby_ext_fc_payer_1_0_v ORDER BY operating_unit, party_name;

Because the tax registration value is computed per row through a PL/SQL function call, large extracts should be filtered meaningfully to avoid excessive function invocations. Note also that LE_REGISTRATION_NUMBER always returns NULL in this version, so legal entity registration must be sourced elsewhere.