Search Results original_assignee_type_code

Overview

APPS.ENG_CHANGE_ROUTE_PEOPLE_VL is a multilingual (language-resolved) view registered under the APPS schema and identified by the FND Design Data reference ENG.ENG_CHANGE_ROUTE_PEOPLE_VL. It exposes the people assigned to an Engineering Change Management (ECM) change order routing step, together with their workflow response data. The view is classified as a "MultiLingual view," meaning it resolves translatable descriptive columns against the user's session language by joining a base table to its corresponding translation table.

The view carries a status of VALID and serves as the API-facing, report-friendly surface for change route personnel. Because it presents a flattened, denormalized projection of routing assignment records, it is the recommended object for reports, form LOVs, and integration extracts that need to read route assignees without navigating the underlying normalized tables directly.

Underlying Base Objects

The view is defined over two documented synonyms: ENG_CHANGE_ROUTE_PEOPLE and ENG_CHANGE_ROUTE_PEOPLE_TL. The former is the base (non-translatable) table that stores the operational attributes of each route person record — identifiers, assignee information, notification linkage, response codes, and standard WHO audit columns. The latter, the "_TL" table, stores the language-dependent descriptive text, most notably RESPONSE_DESCRIPTION.

The "_VL" suffix convention indicates that the view performs the required join between the base table and its translation table, filtering the translation rows by the current language (or by the language defined for the session/terminology). Consumers therefore do not need to write the language join themselves; the view delivers the appropriate resolved description automatically. This design pattern is standard across Oracle EBS 12.1.1 and 12.2.2 for objects with translatable descriptive attributes.

Key Columns

The view exposes a broad set of columns supporting identification, assignment, and workflow response analysis:

• ROW_ID — Row identifier; the physical ROWID of the underlying row.
• ROUTE_PEOPLE_ID — Primary identifier for the route people record.
• STEP_ID — Identifies the routing step to which the assignee belongs.
• ASSIGNEE_ID / ASSIGNEE_TYPE_CODE — The assignee and the code denoting the assignee category (for example, a person or a role).
• ADHOC_PEOPLE_FLAG — Indicates whether the assignee was added to the workflow as an ad hoc participant rather than as a planned assignee.
• RESPONSE_DESCRIPTION — The translatable description of the response; this is the column resolved through the _TL translation table.
• WF_NOTIFICATION_ID — Links the route person to the workflow notification created for the assignment.
• RESPONSE_CODE / RESPONSE_DATE — The response the assignee returned and when it was recorded.
• RESPONSE_CONDITION_CODE — The condition code associated with the response; this is the column most relevant to the search term "response_condition_code" and is used to drive conditional routing logic based on the assignee's answer.
• ORIGINAL_SYSTEM_REFERENCE, ORIGINAL_ASSIGNEE_ID, ORIGINAL_ASSIGNEE_TYPE_CODE — Preserve the original assignment context, supporting reassignment and audit traceability.
• PARENT_ROUTE_PEOPLE_ID — Supports hierarchical or nested route people relationships.
• Standard WHO and concurrent columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, and PROGRAM_UPDATE_DATE provide standard audit and concurrent program context.

Common Use Cases and Queries

Typical uses include reporting assignee responses per change order, detecting ad hoc participants, and driving conditional approval logic through RESPONSE_CONDITION_CODE. The following query retrieves route people for a given routing step and lists their response status:

• SELECT route_people_id, step_id, assignee_id, assignee_type_code, response_code, response_condition_code, response_date FROM apps.eng_change_route_people_vl WHERE step_id = :step_id;
• SELECT route_people_id, assignee_id, adhoc_people_flag, response_description FROM apps.eng_change_route_people_vl WHERE adhoc_people_flag = 'Y';
• SELECT r.route_people_id, r.assignee_id, r.response_code, r.wf_notification_id FROM apps.eng_change_route_people_vl r WHERE r.response_code IS NULL;

Because RESPONSE_DESCRIPTION is resolved through the translation table, all queries automatically return the description in the session language, making the view suitable for both localized reporting and language-neutral integration extracts.