Search Results d_auto_or_manual

Overview

APPS.PER_LETTER_REQUESTS_V is a supplementary view in the Oracle E-Business Suite (EBS) APPS schema, registered under the FND Design Data name PER.PER_LETTER_REQUESTS_V and reported with a status of VALID. It belongs to the Oracle HRMS (PER) product family and exposes data related to letter requests generated by the Oracle HRMS Letter Generation feature. A letter request represents an instance of a letter type that has been generated or queued for generation on behalf of an employee, applicant, or other person, either automatically through a concurrent process or manually by a user.

The view is explicitly documented as a "supplementary view used to simplify forms coding," with Oracle cautioning that it should not be queried or altered directly and that its definition may change dramatically in subsequent minor or major releases. This positions the view as a forms-support construct rather than a supported public interface. Nevertheless, it is frequently encountered during reporting, integration, and troubleshooting work, particularly when users search for d_request_status — a descriptive distribution column that translates the coded REQUEST_STATUS into a user-readable value. The presence of D_-prefixed columns reflects the standard Oracle Forms pattern of pairing a base lookup code with its display value, which makes the view convenient for queries and reports that would otherwise require joining to HR_LOOKUPS.

Underlying Base Objects

The dependency list identifies the objects on which PER_LETTER_REQUESTS_V is defined. The primary transactional base is PER_LETTER_REQUESTS, referenced as a synonym, which stores one row per letter request. Descriptive details about the letter template are sourced from PER_LETTER_TYPES, also referenced as a synonym, giving the view its LETTER_TYPE_NAME attribute. Vacancy context is provided by PER_VACANCIES, a view, which supplies VACANCY_ID and VACANCY_NAME.

Event-related information comes from OTA_EVENTS, exposed as a synonym, contributing EVENT_ID and EVENT_NAME. Code-to-meaning translation is handled through HR_LOOKUPS, a view, which underpins the D_REQUEST_STATUS and D_AUTO_OR_MANUAL descriptive columns. Concurrent program details are resolved through FND_CONCURRENT_PROGRAMS_VL, providing CONCURRENT_PROGRAM_ID and CONCURRENT_PROGRAM_NAME for requests processed by a concurrent manager.

Security and business-group filtering are enforced through packaged PL/SQL logic. HR_SECURITY applies the security profile of the querying user, restricting results to the business groups and organizations they are authorized to see. HR_API and HR_GENERAL provide supporting API and utility calls used within the view's SQL. Consequently, the row set returned by the view is session-dependent and cannot be treated as a flat, unfiltered table query.

Key Columns

• LETTER_REQUEST_ID — Primary identifier for the letter request row; joins back to PER_LETTER_REQUESTS.
• BUSINESS_GROUP_ID — Business group owning the request; central to multi-organization security filtering.
• LETTER_TYPE_ID / LETTER_TYPE_NAME — Identifier and descriptive name of the letter template used.
• DATE_FROM — Effective start date associated with the letter request.
• REQUEST_STATUS — Coded status of the letter request. D_REQUEST_STATUS is the decoded, display-friendly equivalent.
• AUTO_OR_MANUAL — Coded indicator of whether the request was generated automatically or manually. D_AUTO_OR_MANUAL provides the decoded value.
• GENERATION_STATUS_TYPE — Further classification of the generation status.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, CONCURRENT_PROGRAM_ID, CONCURRENT_PROGRAM_NAME, PROGRAM_UPDATE_DATE — Concurrent request and program context, useful for tracing the submission that produced the letter.
• VACANCY_ID, VACANCY_NAME — Vacancy associated with the request, where applicable.
• EVENT_ID, EVENT_NAME — Recruitment or HR event context linked to the request.
• ROW_ID — ROWID pseudocolumn exposed for Forms row identification.
• Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) — Audit trail attributes.

Common Use Cases and Queries

Because the D_ columns supply decoded descriptions, the view is commonly used to report on letter requests without additional lookup joins. A typical query filters by business group and status:

• Status reporting: SELECT letter_request_id, letter_type_name, d_request_status, d_auto_or_manual, creation_date FROM apps.per_letter_requests_v WHERE business_group_id = :p_bg_id ORDER BY creation_date DESC;
• Concurrent request tracing: SELECT letter_request_id, letter_type_name, concurrent_program_name, request_id, d_request_status FROM apps.per_letter_requests_v WHERE request_id = :p_request_id;
• Vacancy-linked letters: SELECT vacancy_name, letter_type_name, event_name, d_request_status FROM apps.per_letter_requests_v WHERE vacancy_id IS NOT NULL;
• Automated versus manual analysis: SELECT d_auto_or_manual, d_request_status, COUNT(*) FROM apps.per_letter_requests_v GROUP BY d_auto_or_manual, d_request_status;

When such queries return no rows despite the data appearing to exist, the cause is usually the HR_SECURITY filter restricting access to a different business group than the one assumed. Because Oracle documents this object as a forms-support view that may change without notice, integrations should anchor on PER_LETTER_REQUESTS and perform their own lookup joins rather than depending on D_REQUEST_STATUS and the other distribution columns remaining stable across releases.