Search Results person_type_code




Overview

The IGS_SS_PERTYP_RESP_GROUPS_ALL table is a core data object within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2, specifically for the IGS (Oracle's Student Management System) product family. Its primary function is to store configuration data that defines responsibility groups based on person types. This table enables the system to associate specific EBS responsibilities with defined person type codes, facilitating role-based access control and process workflows within the student system. The inclusion of the `ORG_ID` column and the `_ALL` suffix in the table name signifies it is a multi-org table, storing data partitioned by operating unit for instances operating in a multi-organization architecture.

Key Information Stored

The table's structure is designed to manage the mapping between responsibilities and person types. The most critical columns include the composite primary key and a control flag. The mandatory `PERSON_TYPE_CODE` (VARCHAR2(30)) is a key identifier for a category of person, such as a student, instructor, or applicant. The `RESPONSIBILITY_ID` (NUMBER) links to the EBS responsibility definition (FND_RESPONSIBILITY). The `ORG_ID` (NUMBER) identifies the operating unit, completing the unique key. The `REQUIRE_APPROVAL_FLAG` (VARCHAR2(1)) is a pivotal control column that dictates whether transactions or actions for this person type and responsibility combination mandate an approval step. Supplemental columns like `COMMENTS` allow for descriptive notes, while standard WHO columns (`CREATED_BY`, `CREATION_DATE`, etc.) provide audit trails.

Common Use Cases and Queries

This table is central to configuring security and process flows. A primary use case is determining if a user, based on their assigned responsibility and the person type they are interacting with, can perform an action without triggering an approval workflow. Administrators query this table to audit or modify responsibility-person type mappings. Common reporting queries involve joining to `FND_RESPONSIBILITY_TL` for the responsibility name and potentially to person type lookup values.

  • Sample Query to List All Mappings for an OU:
    SELECT r.responsibility_name, p.person_type_code, p.require_approval_flag
    FROM igs_ss_pertyp_resp_groups_all p,
    fnd_responsibility_vl r
    WHERE p.responsibility_id = r.responsibility_id
    AND p.org_id = 123
    ORDER BY 1,2;
  • Sample Query to Check Approval Requirement:
    SELECT require_approval_flag
    FROM igs_ss_pertyp_resp_groups_all
    WHERE org_id = :p_org_id
    AND responsibility_id = :p_resp_id
    AND person_type_code = :p_person_type;

Related Objects

Based on the provided metadata, the table's primary key relationship is self-contained. The unique index `IGS_SS_PERTYP_RESP_GROUPS_PK` enforces integrity on the combination of `ORG_ID`, `RESPONSIBILITY_ID`, and `PERSON_TYPE_CODE`. The dependency information indicates the table is referenced by an APPS synonym (`IGS_SS_PERTYP_RESP_GROUPS_ALL`), which is the standard access point for all application code. While not listed in the provided excerpt, logical relationships exist with the `FND_RESPONSIBILITY` table (via `RESPONSIBILITY_ID`) for responsibility details and with the relevant IGS person type lookup tables (via `PERSON_TYPE_CODE`). These joins are essential for meaningful reporting and application logic.