Search Results fnd_log_level

Overview

WSM_WIP_LOT_TXN_PVT is a private PL/SQL package body in the Oracle EBS Work in Process (WIP) and Shop Floor Management (WSM) application, owned by the APPS schema. It provides the core transactional logic that supports lot-based manufacturing operations within the WSM module, specifically the split, merge, and update activities performed against discrete jobs and their associated material. The package encapsulates the business rules required to manipulate Work in Process entities at the job, operation, routing, and component level, and it is designed as a private (PVT) package, meaning it is intended to be invoked by the public WSM wrappers and internal WSM components rather than directly by external callers.

A distinguishing characteristic of this package is its extensive instrumentation for Oracle Application Framework diagnostic logging. The package declares module-level constants bound to FND_LOG levels (LEVEL_UNEXPECTED, LEVEL_ERROR, LEVEL_EXCEPTION, LEVEL_EVENT, LEVEL_PROCEDURE, and LEVEL_STATEMENT) along with FND_MSG_PUB message-level constants. This design allows runtime log filtering to be controlled through the standard FND logging framework, which is why the term fnd_log_level surfaces so prominently in this object's source.

Key Procedures and Functions

• INVOKE_TXN_API — The primary entry point that dispatches a lot transaction request to the appropriate handler based on the requested transaction type.
• SPLIT_TXN — Executes a job split transaction, dividing a source job and its associated material into a new resulting job.
• MERGE_TXN — Executes a job merge transaction, consolidating a starting job into a resulting job.
• UPDATE_ASSEMBLY_TXN — Updates the assembly information associated with a discrete job transaction.
• UPDATE_ROUTING_TXN — Updates routing details on the job being transacted.
• UPDATE_QUANTITY_TXN — Adjusts job quantities as part of the transaction.
• UPDATE_LOTNAME_TXN — Modifies or assigns lot name information for the job's material.
• BONUS_TXN — Processes bonus quantity transactions on a job.
• UPDATE_BOM — Handles updates to the bill of material structure tied to the job.
• UPDATE_STATUS — Changes the status of the job or its related entities.
• UPDATE_COMP_SUBINV_LOC — Updates the component subinventory and locator assignment for job material.
• LOG_TRANSACTION_DATA — Captures and writes transaction-related data to the logging framework, leaving out serial number data. It reads FND_LOG.G_CURRENT_RUNTIME_LEVEL to determine the active logging threshold.

Tables Accessed

The package reads and writes to a defined set of operational and transactional tables accessed through APPS synonyms. Job and entity information is drawn from WIP_DISCRETE_JOBS, WIP_ENTITIES, and WIP_OPERATIONS. Routing and operation metadata come from BOM_DEPARTMENTS, BOM_OPERATION_SEQUENCES, and BOM_STANDARD_OPERATIONS. Transactional state for split and merge operations is persisted in WSM_SPLIT_MERGE_TRANSACTIONS, with staging data in WSM_SM_STARTING_JOBS and WSM_SM_RESULTING_JOBS. Secondary quantity handling uses WSM_JOB_SECONDARY_QUANTITIES, and PLITBLM is referenced for temporary or indexed table access. These tables together support the full lifecycle of a lot transaction from request through persisted result.

Usage Notes

As a private package, WSM_WIP_LOT_TXN_PVT is not intended to be called directly from custom code or forms; instead it is invoked through the public WSM APIs. The ETRM metadata indicates the package is referenced by seven other packages, reflecting its role as an internal service layer consumed by higher-level WSM transaction orchestrators. Typical invocations originate from Shop Floor Management forms or concurrent processes that submit split, merge, and update transactions. The logging framework relies on the FND profile option controlling runtime log level, so diagnostic verbosity for this package is governed externally through standard Oracle diagnostics configuration. Because the object carries a noship directive in its source header and an older revision identifier, implementers working in 12.1.1 and 12.2.2 should treat it as a stable internal component and avoid direct dependency when building extensions.