Search Results bon_alr

Overview

APPS.PAY_KR_SEP_RESULT_SLIP_YB_V is a supplementary Oracle E-Business Suite view owned by the APPS schema that supports the Korean localization of Oracle Payroll. The "_YB" suffix and the "SEP_RESULT_SLIP" naming indicate that the view supplies the data set used to render the separation (termination) result slip — the Korean statutory severance and settlement document produced for departing employees during a payroll run. Metadata status for both 12.1.1 and 12.2.2 records the object as VALID.

The view is classified as a "supplementary view used to simplify forms coding." This classification is significant: Oracle explicitly warns that the view is not intended for direct customer querying or data manipulation, and that its definition may change dramatically in subsequent minor or major releases. The view therefore exists primarily as an internal implementation artifact for the Korean payroll forms layer rather than as a supported public reporting interface. Nevertheless, it is commonly encountered when practitioners search on columns such as brun_type_name, which surfaces the run type description alongside the underlying assignment action and payroll run context.

Underlying Base Objects

The view resolves against the following documented base objects, all referenced through APPS synonyms except the report package:

• PAY_ASSIGNMENT_ACTIONS — the assignment-level action record driving the payroll processing event.
• PAY_PAYROLL_ACTIONS — the payroll action header.
• PAY_RUN_RESULTS — the per-assignment run result row.
• PAY_RUN_RESULT_VALUES — the individual balance and result values attached to each run result.
• PAY_BALANCE_FEEDS_F and PAY_BALANCE_TYPES — the balance feed and balance type definitions used to identify the severance-related balance.
• PAY_RUN_TYPES_F and PAY_RUN_TYPES_F_TL — the run type definition and its translated (language) description, which supply the run type name.
• PAY_KR_REPORT_PKG — the Korean localization PL/SQL package invoked to derive or format separation report data.

The view is referenced by a PUBLIC synonym of the same name, confirming that it is exposed schema-wide for the Korean payroll forms.

Key Columns

The view exposes a compact set of columns that join the assignment action context with the payroll run type. Notable columns include:

• ASSIGNMENT_ACTION_ID, ASSIGNMENT_ID, BASSIGNMENT_ACTION_ID — assignment action identifiers; the B-prefixed column appears to be the base or prior-period counterpart.
• EFFECTIVE_DATE, DATE_EARNED, BEFFECTIVE_DATE, BDATE_EARNED — date context for the action and the earned (B) values.
• RUN_TYPE_ID — the current run type identifier.
• BRUN_TYPE_ID, BRUN_TYPE_NAME, UBRUN_TYPE_NAME — the base run type identifier, its translated display name, and the untranslated (base language) name. BRUN_TYPE_NAME is the column most frequently referenced in searches; it provides the readable run type description associated with the separation result slip.
• BACTION_SEQUENCE — sequence number that orders actions within the processing run.
• BEARNINGS_SUBJ_AVG — an earnings-subject-to-averaging indicator or amount used in Korean severance average-wage computation.

Common Use Cases and Queries

Because the view is a forms-support artifact, its typical use is diagnostic or reconciliation rather than downstream reporting. Practitioners query it to confirm which run type produced a separation slip, to reconcile assignment actions against their translated run type names, or to verify the average-earnings basis used for Korean severance. A representative query follows:

SELECT assignment_action_id,
       assignment_id,
       effective_date,
       date_earned,
       run_type_id,
       brun_type_name,
       ub_run_type_name,
       bearnings_subj_avg
FROM   apps.pay_kr_sep_result_slip_yb_v
WHERE  assignment_id = :p_assignment_id
ORDER  BY beffective_date, baction_sequence;

Given the documented deprecation warning, any such query should be treated as read-only and inspected for change after each patch or upgrade. For supported equivalents, the underlying tables (PAY_RUN_RESULTS joined to PAY_RUN_TYPES_F_TL on RUN_TYPE_ID) should be preferred where an official interface is required.