Search Results amw_evaluation_id_s

Overview

AMW_EVALUATIONS_PKG is an Oracle Application Object Library (EBS) PL/SQL package body owned by APPS that implements the evaluation engine for Oracle Enterprise Asset Management (formerly eAM) and related Maintenance Workbench components. Its central business purpose is to record and manage the outcome of evaluations performed against a defined evaluation set, capturing effectiveness codes for design objectives, operational objectives, and overall conclusions. In EBS 12.1.1 and 12.2.2 the package functions as a server-side API layer rather than a directly user-invoked component; it encapsulates validation, message handling, primary-key generation, and multilingual (TL) row maintenance behind a stable programmatic interface. The package header declares ten documented programs, and the body excerpt confirms that it derives the session context from FND_GLOBAL.USER_ID and FND_GLOBAL.CONC_LOGIN_ID at package initialization, which means the package is intended to run under a fully initialized EBS session (forms, OAF, or concurrent manager). The API classification is OTHER, indicating it is neither a pure public API nor an internal utility, and it is referenced by zero other packages, so it is consumed primarily by forms and custom extensions rather than by other server-side code.

Key Procedures and Functions

• INSERT_ROW — The primary write interface. It creates a new evaluation record, supporting a PGMODE-driven branch (the excerpt shows PGMODE = 'CR' for Create). It accepts the evaluation set identifier, object name, context, evaluation type, date evaluated, up to five generic primary-key values (PK1_VALUE through PK5_VALUE), the entered-by and executed-by identifiers, comments, effectiveness codes, and an evaluation set status code. It follows the standard EBS API contract with INIT_MSG_LIST, VALIDATION_LEVEL, COMMIT, and the X_RETURN_STATUS / X_MSG_COUNT / X_MSG_DATA out parameters. A defect-fix comment records that DATE_EVALUATED was changed from VARCHAR2 to DATE in the 115.8 version.
• GET_OP_EFFECTIVENESS, GET_DES_EFFECTIVENESS — Retrieve the operational and design effectiveness values for an evaluation.
• GET_OP_EFFECTIVENESS_CODE, GET_DES_EFFECTIVENESS_CODE — Return the corresponding coded (lookup) representation of operational and design effectiveness.
• GET_LINE_CONCLUSION, GET_LINE_CONCLUSION_CODE — Return the line-level conclusion text and its coded equivalent.
• ISEVALOWNEROREXECUTOR — Security predicate determining whether the current user is either the owner or the executor of an evaluation.
• ISEVALEXECUTOROFASSESSMENT — Security predicate determining whether the current user is the executor of a specific assessment.
• ADD_LANGUAGE — Inserts translated rows into the TL table for a target language.

Tables Accessed

• AMW_EVALUATIONS_B — Base table holding one row per evaluation; written by INSERT_ROW and queried by the GET_* functions.
• AMW_EVALUATIONS_DETAILS — Stores the detail/line-level conclusion data returned by GET_LINE_CONCLUSION.
• AMW_EVALUATIONS_TL — Translation table populated by ADD_LANGUAGE.
• AMW_EVALUATION_ID_S — Database sequence providing the primary key generated within INSERT_ROW.
• FND_LANGUAGES — Supplies the installed language set required by ADD_LANGUAGE.

Usage Notes

AMW_EVALUATIONS_PKG is normally invoked from the eAM evaluation and assessment forms, and from OAF pages that submit evaluation results, rather than being exposed as a concurrent program. The security functions ISEVALOWNEROREXECUTOR and ISEVALEXECUTOROFASSESSMENT are typically wired into form-level or query-level access control so that evaluations are visible only to their owner or executor. The presence of FND_GLOBAL.USER_ID initialization and the AMW_Utility_PVT.USER_PROFILE_MISSING error path means callers must ensure an EBS session context exists before calling any procedure; invoking from a standalone SQL session without FND_GLOBAL initialization raises G_EXC_ERROR. Custom code should honor the API conventions: pass P_INIT_MSG_LIST = FND_API.G_TRUE to reset the message stack, inspect X_RETURN_STATUS before reading X_MSG_DATA, and leave P_COMMIT as G_FALSE when participating in a larger transaction. Because the package is referenced by no other package, integrators should treat it as a stable but sparsely documented entry point and validate behavior on both 12.1.1 and 12.2.2, since the 12.2 file system and ADOP patching model do not change the PL/SQL signature but do affect how the owning product is patched.