Search Results ame_itl_del




Overview
Explore in AI Chat

Overview

AME_ITL_DEL is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the Approvals Management Engine (AME) product family. Its naming convention—combining the AME prefix with the "ITL" (item translation) and "DEL" (delete) suffixes—indicates that it is a utility package dedicated to the deletion of translated (multi-language) item data maintained by the AME framework. AME relies on item classes to drive approval rule evaluation and routing logic; those item classes carry translatable attributes stored in the corresponding _TL table, and AME_ITL_DEL provides the controlled cleanup mechanism for those translation rows.

The package is documented as VALID with API classification OTHER, meaning it is an internal support utility rather than a public, supported application programming interface. It has no dependencies on other APPS packages, referencing only the SYS.STANDARD package that is implicitly available to every PL/SQL unit. The ETRM record confirms it is referenced by no other packages, which reinforces its role as a leaf-level worker routine invoked directly by AME processing logic or administrative maintenance.

Key Procedures and Functions

The package exposes a single documented procedure:

  • DEL_TL — Removes translated row data associated with AME item classes. In the AME data model, translated entities maintain a base table plus a "_TL" companion table that holds the language-specific description or display text. DEL_TL performs the deletion of the translation records, typically when an item class is being removed, when obsolete languages must be cleaned up, or when the base entity is being purged and the corresponding translation rows must not remain orphaned.

No parameter signatures, function overloads, or additional helper programs are documented in the metadata. The full package body is available through the "show dependent code" reference, and its exact parameter list should be confirmed from that source prior to any direct invocation.

The single delivered routine, DEL_TL, belongs to a pattern common across EBS: a small, purpose-built procedure that encapsulates the delete operation against one translation table so that callers do not need to embed the DELETE statement in business logic.

Tables Accessed

The ETRM documentation identifies one table accessed through APPS synonyms:

  • AME_ITEM_CLASSES_TL — The translation table for AME item classes. It stores the language-dependent display text, including the ML row identifier and the description of each item class. DEL_TL issues delete operations against this table to remove translation rows.

Because the procedure is a delete routine, access is write-oriented (DELETE, and possibly SELECT for identifying the rows to be removed). No inserts or updates to the base AME_ITEM_CLASSES table are documented as part of this package, so integrity of the base item-class definition is left to the calling process or to cascading logic elsewhere.

Usage Notes

AME_ITL_DEL is an internal maintenance package and is not intended as a public extension point. Typical invocation scenarios include:

  • AME configuration maintenance: invoked during the deletion or redefinition of AME item classes when translated content must be purged in step with the base entity.
  • Multi-language cleanup: called when obsolete translations or languages are retired from the AME configuration.
  • Custom migration or data-fix scripts: occasionally referenced in support and upgrade scripts where translated AME item-class rows must be removed as part of a larger data correction.

Because the package is classified as OTHER with no referencing packages, direct calls from custom code should be undertaken only with the exact signature verified from the package body, and only within a transaction that also manages the related base-table rows to avoid orphaning AME_ITEM_CLASSES records. In Oracle EBS 12.1.1 and 12.2.2 the object resides in the APPS schema and is shipped as VALID; it should be treated as an internal utility rather than a supported integration interface, and any use in custom code carries the usual caution applied to undocumented APIs.