Search Results person_profile_sub

Overview

APPS.CSC_CUSTOMER_RESPONSE_V is a customer-facing reporting view in Oracle E-Business Suite that presents party, relationship, and profile information for both organizations and persons within the Trading Community Architecture (TCA) data model. Its name suggests it was originally constructed to expose the "customer" side of a party relationship—that is, the object party—alongside attributes of the subject party, enabling downstream consumers to report on who a given party is, what organization they belong to, and what role they play.

The view is documented in ETRM for both 12.1.1 and 12.2.2 and is defined in the APPS schema. It joins party, relationship, organization profile, person profile, and organization contact records into a single flattened row, presenting denormalized party attributes (names, addresses, profile attributes) alongside relationship metadata. This makes it suitable for reporting, extract, and integration scenarios where a single query must return both the responding party and its associated counterpart without requiring callers to navigate the underlying TCA tables individually.

Underlying Base Objects

According to the documented view metadata, APPS.CSC_CUSTOMER_RESPONSE_V is defined over the following base objects, all accessed through APPS synonyms:

• HZ_PARTIES (SYNONYM) — provides the primary party record, aliased as PARTY.
• HZ_RELATIONSHIPS (SYNONYM) — provides the relationship between subject and object parties, aliased as PARTY_REL.
• HZ_ORGANIZATION_PROFILES (SYNONYM) — supplies organization-level profile attributes, aliased as ORG_PROFILE.
• HZ_PERSON_PROFILES (SYNONYM) — supplies person-level profile attributes, aliased as PERSON_PROFILE_SUB.
• HZ_ORG_CONTACTS (SYNONYM) — supplies organization contact role and department details, aliased as ORG_CONT.

The view also references party records under multiple aliases (PARTY, OBJ_PARTY, SUB_PARTY), indicating that HZ_PARTIES is accessed more than once within the defining query to resolve both ends of each relationship.

Key Columns

The view exposes a broad set of columns drawn from each base object:

• Party identity: PARTY_ID, PARTY_NUMBER, PARTY_TYPE, PARTY_NAME, and ROWID from HZ_PARTIES, identifying the governing party record.
• Relationship metadata: SUBJECT_ID, OBJECT_ID, and RELATIONSHIP_CODE from HZ_RELATIONSHIPS, defining the directional link between parties.
• Person name elements: PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, PERSON_NAME_SUFFIX, PERSON_PRE_NAME_ADJUNCT, PERSON_TITLE, KNOWN_AS, and PERSON_NAME_PHONETIC.
• Organization profile attributes: ANALYSIS_FY, FISCAL_YEAREND_MONTH, EMPLOYEES_TOTAL, CURR_FY_POTENTIAL_REVENUE, NEXT_FY_POTENTIAL_REVENUE, TAX_REFERENCE, YEAR_ESTABLISHED, INTERNAL_FLAG, PUBLIC_PRIVATE_OWNERSHIP_FLAG, DUNS_NUMBER, JGZZ_FISCAL_CODE, and SIC_CODE.
• Contact role details: JOB_TITLE, JOB_TITLE_CODE, DECISION_MAKER_FLAG, MANAGED_BY, DEPARTMENT_CODE, DEPARTMENT, RANK, NATIVE_LANGUAGE, OTHER_LANGUAGE_1/2, and REFERENCE_USE_FLAG.
• Address and audit columns: composed ADDRESS1–ADDRESS4 output, CITY, STATE, PROVINCE, POSTAL_CODE, COUNTRY, ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE8, plus CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The view is commonly used to report on customer or contact relationships, particularly where both the responding party and its associated organization must appear on one row. A representative query joins the view to return party, person, and organization context:

SELECT party_id, party_number, party_name, party_type, relationship_code, person_first_name, person_last_name, job_title, department FROM apps.csc_customer_response_v WHERE party_type = 'PERSON';

For organization-centric reporting, filtering on PARTY_TYPE = 'ORGANIZATION' and selecting DUNS_NUMBER, EMPLOYEES_TOTAL, and SIC_CODE supports account profiling and segmentation. Because the view already performs the joins across HZ_PARTIES, HZ_RELATIONSHIPS, HZ_ORGANIZATION_PROFILES, HZ_PERSON_PROFILES, and HZ_ORG_CONTACTS, callers avoid duplicating that logic. As with any TCA-derived view, queries should filter on indexed identifiers (PARTY_ID, PARTY_NUMBER, or SUBJECT_ID) to limit full-table scans across the underlying party tables.