Search Results update_maint_attributes

Overview

The APPS.EAM_MAINT_ATTRIBUTES_PUB package is a public PL/SQL API within Oracle Enterprise Asset Management (eAM). It manages the maintenance attributes associated with asset instances, specifically the owning department, accounting class code, and maintenance area that drive work order accounting, cost collection, and organizational responsibility for maintainable assets. In Oracle EBS 12.1.1 and 12.2.2, this package provides the programmatic interface used to create and update these attribute assignments against eAM-enabled item instances without requiring direct table-level DML.

The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema rather than the package owner. This is a standard convention for EBS public APIs and requires that the calling user or application schema has appropriate grants on the underlying objects. The header identifies the source file as EAMPMATS.pls, with the most recent header revision dated 2005, indicating a stable interface carried forward across the 11i, 12.1.1, and 12.2.2 releases.

Key Procedures and Functions

The package exposes three documented procedures:

• CREATE_MAINT_ATTRIBUTES — Establishes maintenance attributes for an asset instance. It accepts an instance identifier along with optional owning department, accounting class code, area, and parent instance information, allowing the caller to define the full maintenance context for a newly configured instance.
• UPDATE_MAINT_ATTRIBUTES — Modifies existing maintenance attributes for an instance. This is the procedure retrieved by the search term update_maint_attributes. It shares the standard API parameter signature, including API version, initialization of the message list, commit control, validation level, the instance identifier, owning department, accounting class code, and area, and returns the standard x_return_status, x_msg_count, and x_msg_data outputs. Unlike the create procedure, the update procedure does not expose a parent instance parameter in the documented signature.
• VALIDATE_MAINT_DEFAULTS — Performs validation of the default maintenance attribute values, ensuring that department, accounting class, and area assignments are consistent with the eAM setup before they are committed.

All three procedures adhere to the Oracle Application Object Library API standard, returning status through x_return_status with message details retrievable via x_msg_count and x_msg_data. The p_commit and p_init_msg_list parameters follow the FND_API conventions, defaulting to G_FALSE, while p_validation_level defaults to G_VALID_LEVEL_FULL.

Tables Accessed

The package operates against the following tables through APPS synonyms:

• CSI_ITEM_INSTANCES — The primary eAM instance table storing the maintainable asset records whose attributes are created and updated.
• BOM_DEPARTMENTS — Supplies and validates owning department definitions referenced by the maintenance attributes.
• MTL_EAM_LOCATIONS — Provides eAM location context for area assignments associated with the instance.
• MTL_SYSTEM_ITEMS — Validates the item definition underlying the instance and enforces item-level eAM enablement.
• MTL_PARAMETERS — Resolves organization-level defaults and validation rules during attribute processing.
• WIP_ACCOUNTING_CLASSES — Validates the accounting class code that determines work order cost accounting behavior.

Usage Notes

EAM_MAINT_ATTRIBUTES_PUB is typically invoked from eAM setup and maintenance forms, from concurrent programs that mass-update instance attributes, and from custom extensions requiring attribute changes on asset instances. It is referenced by three other packages in the EBS codebase, confirming its role as a shared service interface rather than a form-only dependency. Because it is classified as a public API, direct DML against CSI_ITEM_INSTANCES for these attributes is discouraged. Callers should supply a valid API version, call the API within a properly initialized message list, and honor the returned x_return_status before committing. Custom code should always invoke UPDATE_MAINT_ATTRIBUTES rather than writing to the underlying columns directly, so that validation and accounting class consistency are preserved.