Search Results check_aml_policy_allowed

Overview

EGO_ITEM_AML_PUB is a public PL/SQL package in the APPS schema that supports Approved Manufacturer List (AML) processing within Oracle E-Business Suite's Product Information Management (PIM) module. An AML defines the approved manufacturers and their manufacturer part numbers for a given item, and this package provides the programmatic interface for validating and applying AML changes against an item's definition. It forms part of the EGO (Engineering/Item) family of APIs, working alongside EGO_ITEM_PUB to enforce AML business rules during item creation and maintenance. The package is classified as PUB, indicating it is a published, callable API rather than a private implementation package.

In Oracle EBS 12.1.1 and 12.2.2, AML data is tightly coupled to item master records and manufacturer part number structures. EGO_ITEM_AML_PUB encapsulates the checks and persistence logic required when AML changes are staged as pending changes and subsequently implemented, ensuring that inventory and purchasing functions see only validated AML data.

Key Procedures and Functions

The ETRM metadata documents six procedures and functions:

• CHECK_CM_EXISTANCE — Verifies the existence of configuration management or change management context relevant to the AML change, ensuring the AML operates within a valid change control environment before processing proceeds.
• IMPLEMENT_AML_CHANGES — The primary action routine that applies staged AML changes to the item. This is the procedure that commits pending AML modifications, typically invoked after all validation checks have passed.
• DELETE_AML_PENDING_CHANGES — Removes AML modifications that were staged but not yet implemented, providing a rollback or cleanup capability for abandoned change sets.
• CHECK_AML_POLICY_ALLOWED — Validates whether the applicable AML policy permits the requested operation. AML policies govern whether manufacturers and part numbers may be freely added or are restricted by item or organization rules.
• CHECK_NO_AML_PRIV — Determines whether the calling context lacks the AML privilege required for the operation, used to enforce security and authorization on AML maintenance.
• CHECK_NO_MFG_ASSOCIATIONS — Confirms that no manufacturer associations exist that would prevent the requested change, guarding against orphaned or conflicting manufacturer part number links.

Tables Accessed

The package reads and writes several core tables via APPS synonyms:

• EGO_MFG_PART_NUM_CHGS — Stores staged (pending) manufacturer part number changes; central to the implement, delete, and existence checks.
• EGO_CAT_GRP_MFG_ASSOCS — Holds category-group-to-manufacturer associations used to validate manufacturer applicability.
• EGO_OBJ_TYPE_LIFECYCLES — Provides lifecycle definitions that govern which AML operations are permitted for an item type.
• MTL_MFG_PART_NUMBERS — The base manufacturer part number table where validated AML entries reside.
• MTL_MANUFACTURERS — Supplies manufacturer reference data.
• MTL_SYSTEM_ITEMS_KFV — The item key flexfield view, used to resolve and validate the target item.
• MTL_ITEM_CATALOG_GROUPS_B — Category group base table for catalog associations.
• FND_APPLICATION, FND_OBJECTS, FND_PRODUCT_INSTALLATIONS — Foundation tables used to check application context, object registration, and installation status.
• DUAL — Used for single-row evaluations.

Usage Notes

EGO_ITEM_AML_PUB is invoked through the standard EGO API stack, most notably by EGO_ITEM_PUB, which references it during item maintenance. It is not intended for direct end-user invocation; rather, it is called by forms and concurrent programs in PIM when users add, modify, or remove AML entries. Custom extensions integrating with the item master should call the published procedures in the documented order—validation checks first (CHECK_AML_POLICY_ALLOWED, CHECK_NO_AML_PRIV, CHECK_NO_MFG_ASSOCIATIONS, CHECK_CM_EXISTANCE), followed by IMPLEMENT_AML_CHANGES—using the standard FND_API error-handling conventions. Because dependencies include FND_API, callers should initialize the API context and interpret the returned success or error flags rather than relying on exceptions.