Search Results pabv_customers




Overview

PABV_CUSTOMERS is a read-only view owned by the APPS schema in Oracle E-Business Suite, catalogued under the PA (Projects) product family. It is documented as a retrofitted object, meaning it was reconstructed or aliased during an upgrade or patch cycle to preserve compatibility with prior releases, and it remains VALID in both EBS 12.1.1 and 12.2.2. The view exposes a consolidated, denormalized picture of the relationship between a project and the customer accounts associated with it. Functionally, it merges three sources of truth: the project-to-customer assignment stored in PA_PROJECT_CUSTOMERS, the master customer record in HZ_CUST_ACCOUNTS, and the underlying party identity in HZ_PARTIES. This makes it useful for reporting and integration flows that need customer billing attributes alongside the internal project identifier without writing the multi-table join manually. The view is defined WITH READ ONLY, so it is safe for ad-hoc querying and cannot be used as a DML target. Access to rows is effectively restricted through the '_SEC:PPA.ORG_ID' predicate against PA_PROJECTS_ALL, aligning the row set with the operating unit and security context of the querying user.

Underlying Base Objects

The documented ETRM metadata for release 12.2.2 identifies four referenced base objects, all presented in the owning schema as synonyms:

  • PA_PROJECT_CUSTOMERS — the primary source of project-to-customer linkage, bill split, and bill-to/ship-to address references.
  • PA_PROJECTS_ALL — provides the authoritative project record and carries the ORG_ID column used by the security predicate.
  • HZ_CUST_ACCOUNTS — supplies the customer account identifier and links that account to its party.
  • HZ_PARTIES — supplies the party-level identity behind the customer account.

The join path is: PA_PROJECT_CUSTOMERS.PROJECT_ID = PA_PROJECTS_ALL.PROJECT_ID; HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID = PA_PROJECT_CUSTOMERS.CUSTOMER_ID; and HZ_CUST_ACCOUNTS.PARTY_ID = HZ_PARTIES.PARTY_ID. The inclusion of HZ_CUST_ACCOUNTS and HZ_PARTIES ensures that only valid TCA-registered customers survive the join, filtering out orphaned or historical customer references in the projects data.

Key Columns

  • PROJECT_ID — the internal identifier of the project, joined from PA_PROJECT_CUSTOMERS and validated against PA_PROJECTS_ALL.
  • CUSTOMER_ID — the customer account identifier from PA_PROJECT_CUSTOMERS, matching HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID.
  • "_LA:PROJECT_CUST_RELATION" — the customer project relationship code. As documented, its value is derived from the PA_LOOKUPS lookup type "CUSTOMER PROJECT RELATIONSHIP" using the MEANING column, so consumers receive the descriptive meaning rather than the raw lookup code.
  • CUSTOMER_BILL_SPLIT — the billing split percentage or allocation applied to this customer for the project.
  • BILL_TO_ADDRESS_ID — reference to the bill-to address used for invoicing this customer on the project.
  • SHIP_TO_ADDRESS_ID — reference to the ship-to address associated with the customer relationship.
  • LAST_UPDATE_DATE / LAST_UPDATED_BY — audit trail for the last modification of the project-customer assignment row.
  • CREATION_DATE / CREATED_BY — audit trail for initial creation of the assignment row.

Common Use Cases and Queries

Typical scenarios include listing all customers on a project, validating bill split configuration before invoicing, and extracting billing addresses for downstream integration. A basic query by project is:

  • SELECT project_id, customer_id, customer_bill_split, bill_to_address_id FROM apps.pabv_customers WHERE project_id = :p_project_id;
  • SELECT c.project_id, c.customer_id, c.customer_bill_split FROM apps.pabv_customers c WHERE c.customer_id = :p_customer_id;
  • SELECT c.project_id, c.customer_id, p.party_name FROM apps.pabv_customers c, apps.hz_parties p, apps.hz_cust_accounts a WHERE c.customer_id = a.cust_account_id AND a.party_id = p.party_id;

Because the view is read-only and secured by the PPA.ORG_ID predicate through PA_PROJECTS_ALL, results are automatically limited to the operating units the querying responsibility is authorized to see, making it well suited to multi-org reporting without additional filtering logic.