Search Results isdifferent_number




Overview

WIP_EAM_WORKREQUEST_PVT is the private implementation package for the Enterprise Asset Management (EAM) Work Request API in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It encapsulates the business logic used by maintenance organizations to create, validate, update, and approve work requests against maintained assets. The package forms the internal engine behind the public work request API, providing the procedural logic that governs how a maintenance work request is registered, how its descriptive flexfield and department references are resolved, and how automatic approval decisions are reached. The header comment block identifies the API name as WIP_EAM_WORKREQUEST_PVT, classifies it as a Public API type, and records a current version of 1.0, with the source controlled under the WIPVWRPB.pls file and modified during the Work Request Enhancement Project (Bug 2997297). All procedures follow the standard EBS API conventions, returning x_return_status, x_msg_count, and x_msg_data OUT parameters to communicate success, error, or unexpected exceptions to the calling layer.

Key Procedures and Functions

The documented interface exposes eleven procedures and functions:

  • CREATE_WORK_REQUEST — the primary entry point that inserts a new EAM work request, accepting API control flags, organization and asset identifiers, priority, request-by date, owning department, originator contact details, and ten descriptive flexfield attribute segments.
  • ISDIFFERENT — a comparison utility that determines whether two values differ, used to detect changed columns during update processing.
  • ISDIFFERENT_NUMBER — the numeric counterpart to ISDIFFERENT, applying the same difference-detection logic to NUMBER-typed attributes. This is the object of the user's search term.
  • DFF_PROMPT_NAME — resolves the prompt name for a descriptive flexfield segment, supporting user-facing DFF rendering.
  • UPDATE_WORK_REQUEST — applies modifications to an existing work request record, preserving unchanged columns through the ISDIFFERENT checks.
  • RETURN_DEPT_ID — derives and returns the owning department identifier for a given work request context.
  • VALIDATE_WORK_REQUEST — performs pre-write validation of required and referential data before creation or update.
  • AUTO_APPROVE_CHECK — evaluates whether a work request qualifies for automatic approval based on EAM organization maintenance defaults and parameter settings.
  • CREATE_AND_APPROVE — a convenience routine that combines creation with the approval check and approval execution in a single call.
  • CHECK_PRODUCT_INSTALL — verifies that required products or application components are installed before the API proceeds.
  • VALIDATE_DESC_FLEX_FIELD — validates the descriptive flexfield attribute segments against the defined flexfield structure.

Tables Accessed

The package reads and writes a set of EAM and shared EBS tables through APPS synonyms. WIP_EAM_WORK_REQUESTS and WIP_EAM_WORK_REQUESTS_S hold the work request header records and their primary key sequence, while WIP_EAM_WORK_REQ_NOTES and WIP_EAM_WORK_REQ_NOTES_S store attached note text. EAM_ORG_MAINT_DEFAULTS and WIP_EAM_PARAMETERS supply organization-level maintenance defaults and system parameters used by AUTO_APPROVE_CHECK. CSI_ITEM_INSTANCES and MTL_SYSTEM_ITEMS resolve the maintained asset and inventory item. BOM_DEPARTMENTS provides department validation for RETURN_DEPT_ID, and FND_USER supplies originator identity data. FND_DESCR_FLEX_CONTEXTS and FND_APPLICATION support flexfield validation and product installation checks. DUAL is used for lightweight singleton queries.

Usage Notes

WIP_EAM_WORKREQUEST_PVT is a private (PVT) package and is not intended to be called directly by external integrations; consumers should invoke the corresponding public work request API, which delegates to these private routines. It is referenced by two other packages within the EAM module. Typical invocation paths include the EAM work request entry forms, concurrent programs that batch-process or auto-approve work requests, and internal EAM flows such as CREATE_AND_APPROVE. Custom code that requires direct access should respect the FND_API initialization and message-handling conventions, checking x_return_status after every call.