Search Results b_status




Overview
Explore in AI Chat

Overview

PV_PARTNER_VENDORS_V is a reporting and integration view owned by the APPS schema within the Partner Management (PV) product family of Oracle E-Business Suite, available in releases 12.1.1 and 12.2.2. It exposes a consolidated, denormalized projection of internal organizations (that is, operating units or inventory organizations registered as legal entities) and their associated party records. The view is designed to answer the recurring question of which "vendor-like" or partner-eligible organizations exist within the E-Business Suite instance: it filters HZ_ORGANIZATION_PROFILES to those flagged as internal (INTERNAL_FLAG = 'Y') and currently active (EFFECTIVE_END_DATE IS NULL), then joins them to HZ_PARTIES for identity and status information.

The user search term b_status corresponds directly to a column in this view. It is an aliased copy of HZ_PARTIES.STATUS, retained for code that expects the legacy "B_STATUS" naming convention (a convention inherited from earlier Oracle partner/vendor lookup structures). Practically, B_STATUS and STATUS carry identical values; the duplication exists solely for backward compatibility with forms, concurrent programs, and custom reports that reference the historical column name.

Underlying Base Objects

The ETRM metadata documents two referenced base objects, both accessed through synonyms in the APPS schema:

  • HZ_PARTIES (SYNONYM) — the Registry party master. Supplies PARTY_ID, PARTY_NUMBER, PARTY_NAME, PARTY_TYPE, and STATUS.
  • HZ_ORGANIZATION_PROFILES (SYNONYM) — the organization profile extension. Supplies the internal-organization flag and effective-dating attributes used by the view's filter and date columns.

The join predicate is PARTY.PARTY_ID = ORG_PROFILE.PARTY_ID, an inner join on the party primary key. Because the WHERE clause mandates INTERNAL_FLAG = 'Y' and a null effective end date, only internal organizations that are currently active appear in the result set.

Key Columns

  • ID1 — aliased from PARTY.PARTY_ID; the numeric primary key of the party record, used for foreign-key joins in downstream queries.
  • ID2 — a literal '#' placeholder, included to satisfy the two-column ID structure expected by certain Oracle EBS descriptive-flexfield and LOV frameworks.
  • DESCRIPTION — aliased from PARTY.PARTY_NUMBER; the human-readable party identifier.
  • PARTY_NUMBER — the registry party number; unique system-generated identifier.
  • NAME — aliased from PARTY.PARTY_NAME; the organization's display name.
  • PARTY_TYPE — the HZ party classification (for example, ORGANIZATION versus PERSON).
  • B_STATUS — the legacy-named alias of HZ_PARTIES.STATUS; valid values are typically A (active) and I (inactive). This is the column referenced by the user's search.
  • STATUS — the same underlying value as B_STATUS, exposed under the conventional name.
  • START_DATE_ACTIVE — populated with SYSDATE at query time; a dynamic, non-persistent value.
  • END_DATE_ACTIVE — drawn from ORG_PROFILE.EFFECTIVE_END_DATE; always NULL given the view's filter.

Common Use Cases and Queries

Typical scenarios include populating partner or vendor LOVs, validating that an operating unit has a corresponding internal party, and auditing party status for partner-management integrations. A representative query filtering on the search column follows:

  • SELECT party_number, name, b_status, status FROM apps.pv_partner_vendors_v WHERE b_status = 'A' ORDER BY name;
  • SELECT id1, party_number, party_type FROM apps.pv_partner_vendors_v WHERE party_type = 'ORGANIZATION';
  • SELECT COUNT(*) FROM apps.pv_partner_vendors_v WHERE b_status = 'I'; — identifying inactive internal parties requiring remediation.

Because the view targets internal organizations only, it should not be used to retrieve external suppliers or customers; those require querying HZ_PARTIES without the internal-organization restriction. For performance, join directly to HZ_PARTIES or HZ_ORGANIZATION_PROFILES where possible, as the view's SYSDATE column and derived aliases prevent some predicate pushdown optimizations.