Results for “igf_td_item_status”

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

Overview

APPS.IGF_AP_TD_ITEM_INST_V is a reporting and integration view in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environments, residing in the IGF (Oracle Student System / Financial Aid) application schema. It presents the instance-level state of "to-do" items associated with a financial aid applicant's base record, joining each item instance against its item master definition, its decoded status meaning, preferred lender information, and the underlying applicant base record. The view is the canonical surface through which the operational status of a to-do checklist item, such as "Submit Verification Worksheet" or "Complete Master Promissory Note," is exposed for inquiry, reporting, and downstream processing.

The view is particularly relevant when a user searches for igf_td_item_status, since it resolves that lookup type explicitly: status codes stored on the item instance are decoded through IGF_LOOKUPS_VIEW using LOOKUP_TYPE = 'IGF_TD_ITEM_STATUS', producing a human-readable STATUS_DESC. This makes the view suitable for both end-user reporting and programmatic consumption.

Underlying Base Objects

The view is defined over five objects through an inner-join structure with one outer join:

• IGF_AP_TD_ITEM_INST (TDII) — the driving table, holding one row per to-do item instance assigned to an applicant.
• IGF_AP_TD_ITEM_MST (TDM) — the item master, joined on TODO_NUMBER = ITEM_SEQUENCE_NUMBER, supplying item code, description, application code, career item, and system to-do type.
• IGF_LOOKUPS_VIEW (LV) — the lookup view, joined by LOOKUP_TYPE = 'IGF_TD_ITEM_STATUS' and LOOKUP_CODE = STATUS, supplying the decoded MEANING.
• IGF_AP_FA_BASE_REC_ALL (FA) — the applicant base record, joined on BASE_ID, supplying PERSON_ID.
• IGF_SL_CL_PREF_LENDERS_V (PREFLEND) — joined by CLPRL_ID as an outer join, supplying preferred-lender relationship code and description where applicable.

All joins except the preferred-lender join are inner joins, so a row is returned only where a matching master item, valid lookup, and applicant base record exist.

Key Columns

• ROW_ID — the ROWID of the underlying item instance row, enabling direct row addressing.
• BASE_ID — the applicant base record identifier; the principal key linking to the person.
• ITEM_SEQUENCE_NUMBER / ITEM_CODE / ITEM_DESCRIPTION — the to-do item definition identifier and its descriptive attributes from the master.
• STATUS / STATUS_DESC — the stored status code and its decoded IGF_TD_ITEM_STATUS meaning.
• STATUS_DATE, ADD_DATE, CORSP_DATE, CORSP_COUNT — lifecycle dates and correspondence count associated with the item instance.
• INACTIVE_FLAG, REQUIRED_FOR_APPLICATION, FREQ_ATTEMPT, MAX_ATTEMPT, LEGACY_RECORD_FLAG — control flags governing whether the item is active, mandatory, and how frequently it may be attempted.
• CLPRL_ID, RELATIONSHIP_CD, RELATIONSHIP_CD_DESC — preferred lender affiliation and its decoded relationship.
• PERSON_ID, APPLICATION_CODE, CAREER_ITEM, SYSTEM_TODO_TYPE_CODE — person identity and classification attributes for the item.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical scenarios include outstanding-item reporting per applicant, status trending, and lender-affiliation checks. A representative query lists outstanding items for a person:

SELECT base_id, person_id, item_code, item_description,
       status, status_desc, status_date
FROM   apps.igf_ap_td_item_inst_v
WHERE  person_id = :p_person_id
AND    inactive_flag = 'N'
ORDER BY status_date;

A second common pattern aggregates items by decoded status to produce workload summaries:

SELECT status_desc, COUNT(*) item_count
FROM   apps.igf_ap_td_item_inst_v
WHERE  required_for_application = 'Y'
GROUP BY status_desc;

Because STATUS_DESC is sourced from the IGF_TD_ITEM_STATUS lookup, the view is the recommended access path whenever item status interpretation is required, avoiding the need to re-implement lookup decoding in custom SQL.