Search Results sex_code

Overview

RA_HCONTACTS is a Receivables (AR) compatibility view in Oracle E-Business Suite 12.1.1 and 12.2.2. It presents customer contact information — historically stored in the legacy RA_CONTACTS table — by projecting data from the Oracle Trading Community Architecture (TCA) model, principally the HZ_CUST_ACCOUNT_ROLES, HZ_ORG_CONTACTS, HZ_PARTIES, and HZ_CONTACT_POINTS tables. It exists to preserve backward compatibility for pre-11.5.10 forms, reports, and custom code that referenced RA_CONTACTS directly, while the underlying data is maintained by TCA.

A notable characteristic is that the view object itself is frequently not instantiated in customer databases. The ETRM documentation explicitly records "Not implemented in this database" for the implementation/DBA data, meaning the view definition may exist in the patch metadata but is only created in environments where the compatibility script has been run. The view is also read-only in practice; DML against customer contacts is performed through TCA public APIs and the Customers / Contacts forms, not through this view.

Underlying Base Objects

The view text references the following objects, using correlation aliases:

• HZ_CUST_ACCOUNT_ROLES (alias ACCT_ROLE) — the primary driver, supplying the contact's surrogate and foreign keys, who columns, status, primary flag, and the ATTRIBUTE1 through ATTRIBUTE25 flex columns.
• HZ_ORG_CONTACTS (alias ORG_CONT) — role-level contact attributes such as job title, mail stop, decision-maker flag, rank, contact number, and reference-use flag.
• HZ_PARTIES (alias PARTY) — person name components (last, first, pre-name adjunct, suffix), the customer key, language, and the do-not-mail flag. A comment in the view text notes the key is taken from HZ_PARTIES because the person key is stored there (Bugs 1199439 and 1354647).
• HZ_CONTACT_POINTS (alias REL_PARTY) — supplies the contact e-mail address.

RA_HCONTACTS is therefore a denormalized join across the TCA contact sub-model rather than a view over a single legacy table.

Key Columns

• CUST_ACCOUNT_ROLE_ID — exposed as CONTACT_ID; the primary identifier for the contact role.
• CUST_ACCOUNT_ID — exposed as CUSTOMER_ID; links the contact to the customer account.
• CUST_ACCT_SITE_ID — exposed as ADDRESS_ID; the site with which the contact is associated.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard who columns. LAST_UPDATE_DATE is the column most frequently searched for, used in incremental-extract and audit queries. Note it originates from HZ_CUST_ACCOUNT_ROLES, while LAST_UPDATE_LOGIN is taken from HZ_ORG_CONTACTS, so the two are not guaranteed to be updated in lockstep.
• STATUS, PRIMARY_FLAG — exposed as PRIMARY_ROLE; active/inactive state and primary-contact designation.
• ORIG_SYSTEM_REFERENCE, CUSTOMER_KEY — integration keys for legacy and TCA-originated records.
• PERSON_FIRST_NAME, PERSON_LAST_NAME, PERSON_PRE_NAME_ADJUNCT, SUFFIX — name components, with SUBSTRB truncation applied to first and last names.
• EMAIL_ADDRESS, JOB_TITLE, JOB_TITLE_CODE, MAIL_STOP, RANK, DECISION_MAKER_FLAG, CONTACT_NUMBER, REFERENCE_USE_FLAG — descriptive contact attributes.
• ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE25 — descriptive flexfield columns from HZ_CUST_ACCOUNT_ROLES.
• CONTACT_PERSONAL_INFORMATION, OTHER_LANGUAGE_1, OTHER_LANGUAGE_2 — always NULL, retained only for column-position compatibility.

Common Use Cases and Queries

Typical scenarios include legacy report migration, reconciliation between legacy RA_CONTACTS-based extracts and TCA, and incremental synchronization of contact changes. A standard query returns active contacts for a customer, filtered by update date:

• SELECT contact_id, customer_id, address_id, person_first_name, person_last_name, email_address, last_update_date FROM ra_hcontacts WHERE customer_id = :customer_id AND status = 'A' ORDER BY person_last_name, person_first_name;
• SELECT contact_id, customer_id, last_update_date FROM ra_hcontacts WHERE last_update_date >= :last_run_date;

Because the view is not implemented in every database, code should verify existence in ALL_VIEWS before use. For new development, query the TCA tables directly or use the TCA APIs, since RA_HCONTACTS is a compatibility artifact with no documented base objects and no DML support.