Results for “source_job_title”

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

Overview

JTF_RS_DEFRESOURCES_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite. It is registered under the FND – Application Object Library product and carries a VALID status in both release 12.1.1 and 12.2.2. The view exposes resource definitions maintained within the JTF Resource Manager (part of the CRM Foundation / Territory and Resource Management stack) and joins each resource to its category description, producing a denormalized, reporting-friendly projection of resource master data.

Its role is primarily reporting and integration. Rather than requiring consumers to join the resource extension entity to the object lookup themselves, JTF_RS_DEFRESOURCES_V already performs that join and flattens both descriptive attributes (name, address, contact points, status) and administrative attributes (cost per hour, currency, commissionability, hold flags, flexfield segments) into a single row per resource. This makes it a convenient source for customer-facing reports, OTBI/BIP data models, interfaces, and concurrent programs that need a stable, denormalized resource picture.

Underlying Base Objects

The view text is defined over exactly two documented objects:

• JTF_RS_RESOURCE_EXTNS_VL (VIEW) — aliased RSC. This is the primary driver; it is the resource extension view that supplies resource identity, source/contact details, and the majority of the projected columns.
• JTF_OBJECTS_VL (VIEW) — aliased OBJ. This is joined solely to translate the resource category code into a meaningful description via OBJ.NAME, aliased as CATG_MEANING.

The join predicate is RSC.CATEGORY = OBJ.OBJECT_CODE. Because both operands are themselves views (_VL suffixed, indicating they resolve to language-dependent or extension layer definitions), JTF_RS_DEFRESOURCES_V sits at the top of a small view chain rather than directly on base tables. All columns, including the ROWID exposed as ROW_ID, are inherited from the resource extension view.

Key Columns

The view projects a broad column list. Notable groupings include:

• Identity and audit — ROW_ID, RESOURCE_ID, RESOURCE_NUMBER, RESOURCE_NAME, USER_ID, USER_NAME, plus the standard CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and OBJECT_VERSION_NUMBER.
• Classification — CATEGORY (the code) and CATG_MEANING (the description obtained from JTF_OBJECTS_VL.NAME).
• Source/contact detail — SOURCE_NAME, SOURCE_EMAIL, SOURCE_PHONE, SOURCE_MOBILE_PHONE, SOURCE_PAGER, and the structured address fields (SOURCE_ADDRESS1–4, SOURCE_CITY, SOURCE_STATE, SOURCE_POSTAL_CODE, SOURCE_COUNTRY, and related fields).
• Organizational context — SOURCE_ORG_ID, SOURCE_ORG_NAME, SOURCE_MGR_ID, SOURCE_MGR_NAME, SOURCE_BUSINESS_GRP_ID, SOURCE_BUSINESS_GRP_NAME, SERVER_GROUP_ID, ASSIGNED_TO_GROUP_ID, COMP_SERVICE_TEAM_ID.
• Financial and status attributes — COST_PER_HR, COST_CENTER, CHARGE_TO_COST_CENTER, COMPENSATION_CURRENCY_CODE, COMMISSIONABLE_FLAG, HOLD_REASON_CODE, HOLD_PAYMENT, SOURCE_STATUS, and the active date range START_DATE_ACTIVE/END_DATE_ACTIVE.
• Flexfield support — ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15.

Common Use Cases and Queries

Typical scenarios include building resource directories, validating active resources for assignment, and feeding downstream integration extracts. A simple listing of active resources with their category description and contact details follows:

• Filter on END_DATE_ACTIVE to isolate currently valid resources.
• Join to FND_USER or HR tables on USER_ID or MANAGING_EMPLOYEE_ID for extended attributes.
• Group by CATG_MEANING for resource headcount by category.

Sample SQL:

SELECT resource_id, resource_number, resource_name, catg_meaning,
       source_email, source_phone, source_org_name, cost_per_hr
  FROM apps.jtf_rs_defresources_v
 WHERE TRUNC(SYSDATE) BETWEEN NVL(start_date_active, SYSDATE)
         AND NVL(end_date_active, SYSDATE)
  ORDER BY catg_meaning, resource_name;

Because the view is a non-updatable projection over other views, it must be treated strictly as a query/reporting interface; DML against resource definitions is performed through the underlying Resource Manager APIs, not this object.