Search Results create_construction_unit




Overview
Explore in AI Chat

Overview

The APPS.EAM_CONSTRUCTION_UNIT_PUB package body is the public API layer for managing Construction Units within Oracle Enterprise Asset Management (eAM). A Construction Unit (CU) represents a logical grouping of assets or work orders that are managed together through a construction or capital project lifecycle, particularly in industries such as utilities, telecommunications, and heavy engineering where assets are built, commissioned, and then placed into service.

This package follows the Oracle Application Object Library (AOL) API design pattern: a thin public (PUB) wrapper that performs API version compatibility checking and delegates all business logic to a corresponding private package, EAM_CONSTRUCTION_UNIT_PVT. The header comment ($Header: EAMPCUB.pls 120.0.12010000.3 2008/11/20 ... dsingire noship $) indicates the file has been stable since the 12.1.x code line and remains unchanged in the 12.2.2 release, reflecting the maturity of the eAM data model across both releases.

The package is classified as PUB in ETRM (E-Business Suite Technical Reference Manual), signalling that it is a supported, externally callable interface rather than an internal implementation detail. It is referenced by two other packages, confirming its role as a foundational service within the eAM module.

Key Procedures and Functions

The documented public interface exposes three procedures:

  • CREATE_CONSTRUCTION_UNIT — Creates a new Construction Unit record together with its associated activity details. Accepts the API version, a commit flag, a Construction Unit record (p_cu_rec of type CU_rec), and a table of CU activities (p_cu_activity_tbl of type CU_Activity_tbl). Returns the generated Construction Unit identifier (x_cu_id) along with the standard AOL API output parameters x_return_status, x_msg_count, and x_msg_data. This is the procedure most commonly targeted when a user searches for create_construction_unit, as it is the supported entry point for programmatic CU creation.
  • UPDATE_CONSTRUCTION_UNIT — Modifies an existing Construction Unit and its activity rows. It mirrors the create signature, accepting the same CU_rec and CU_Activity_tbl structures plus the standard API control and feedback parameters.
  • COPY_CONSTRUCTION_UNIT — Duplicates an existing Construction Unit, typically used to replicate a template or a prior project structure to accelerate setup of similar construction efforts.

Each procedure follows the same defensive pattern: it validates the caller's API version using FND_API.Compatible_API_Call, raising FND_API.G_EXC_ERROR on mismatch; enables debugging via EAM_CONSTRUCTION_UNIT_PVT.set_debug; and delegates to the PVT package. The exception handler translates G_EXC_ERROR into FND_API.G_RET_STS_ERROR and, for unexpected errors, raises the message EAM_CU_UNEXP_SQL_ERRORR with the API name and SQLERRM as tokens.

Tables Accessed

The ETRM metadata for this PUB package does not enumerate specific base tables because all DML is performed by the private package EAM_CONSTRUCTION_UNIT_PVT. In the eAM schema, the underlying persistence for Construction Units resides in the EAM_CONSTRUCTION_UNITS and EAM_CU_ACTIVITIES tables (accessed through APPS synonyms), with supporting lookups for statuses and asset associations. The activity table parameter (CU_Activity_tbl) strongly implies that a single API call writes one header row plus one or more child activity rows in a single transaction, keeping the header and detail data consistent.

Usage Notes

Because this is a PUB package, it should be invoked directly rather than calling the PVT layer, so that API version checking and message stack handling are preserved. Typical invocation contexts include:

  • eAM forms — The Construction Unit setup and maintenance windows call into this API when users create, amend, or copy construction units.
  • Concurrent programs and interfaces — Batch loads of construction data from external project systems or legacy sources use these procedures to validate and insert records with controlled error reporting via the FND message stack.
  • Custom code and extensions — Developers integrating eAM with project accounting or Work Management should call CREATE_CONSTRUCTION_UNIT and pass 1.0 as p_api_version, interpreting x_return_status against FND_API.G_RET_STS_SUCCESS and iterating x_msg_count/x_msg_data (or FND_MSG_PUB) on failure.
  • Commit control — The p_commit flag allows the caller to defer commit, which is essential when the API is called inside a larger transaction orchestrated by the calling program.

The package behaves identically in 12.1.1 and 12.2.2; no 12.2-specific changes are documented, so existing 12.1.1 customisations remain valid after upgrade.