Search Results delete_tasktemplate

Overview

OZF_TASK_TEMPLATE_PVT is a private PL/SQL package in the APPS schema that implements the core business logic for managing task templates within Oracle E-Business Suite. Task templates are reusable definitions that drive the automatic generation of tasks and deliverables in the Trade Management and Channel Revenue Management modules (the OZF product family). Rather than requiring users to re-enter task attributes for every new promotion, fund request, or trade activity, task templates allow a standardized set of tasks to be instantiated on demand. The package is classified as a PVT (private) API layer, meaning it is intended to be called from the public wrapper packages, forms, or concurrent programs rather than directly by external integrations.

The package was delivered with an older code lineage, as evidenced by its header stamp of version 115.3 dated 2003, but it remains documented in the ETRM 12.2.2 repository alongside its 12.1.1 equivalents. The compile-time directive AUTHID CURRENT_USER indicates the package executes with the privileges of the invoking user, which is typical for APPS-layer PL/SQL that relies on APPS synonyms and grants.

Key Procedures and Functions

The package exposes nine documented procedures and functions organized around a standard CRUD-plus-validation pattern consistent with Oracle's API design conventions.

• CREATE_TASKTEMPLATE — Inserts a new task template record. The specification accepts the standard FND_API parameters (p_api_version, p_init_msg_list, p_commit, p_validation_level) and returns x_return_status and x_msg_data. The object_version_number is initialized to 1 on insert.
• UPDATE_TASKTEMPLATE — Modifies an existing task template and typically increments the object_version_number for optimistic locking.
• DELETE_TASKTEMPLATE — Removes a task template definition, subject to referential checks.
• GET_TASKTEMPLATE — Retrieves a single task template record and populates the caller's record structure.
• VALIDATE_TASKTEMPLATE — Performs business-rule validation on the supplied template attributes before persistence.
• CHECK_TASKTEMPLATE_ITEMS — Verifies that dependent items associated with the template are consistent.
• CHECK_TASKTEMPLATE_RECORD — Confirms the existence and integrity of the template record itself.
• INIT_REASON_REC — Initializes the reason-code portion of the record structure.
• COMPLETE_TASKTEMPLATE_REC — Finalizes and completes the template record, likely populating derived or default values.

These procedures operate against the declared record type ozf_task_template_rec_type, which carries task name, description, reason code, task number, task type, status, priority, duration, duration UOM, object version, and fifteen DFF attribute columns.

Tables Accessed

The ETRM metadata references a single table through APPS synonyms: PLITBLM. In Oracle EBS, PLITBLM is the generic PL/SQL integer table used internally by the FND_API framework to manage message lists and index arrays. Its presence confirms that OZF_TASK_TEMPLATE_PVT leverages the standard FND message-stack mechanism for error handling and message propagation. The package and its callers therefore benefit from consistent error reporting through FND_MSG_PUB.

Usage Notes

Because OZF_TASK_TEMPLATE_PVT is a private API, it should not be invoked directly from custom code. Oracle's recommended pattern is to call the corresponding public OZF_TASK_TEMPLATE_PUB wrapper, which handles initialization, message-list setup, and transaction control before delegating to the private layer. In practice, the package is exercised when users define or maintain task templates through the Trade Management setup forms, when task templates are instantiated during promotion or offer creation, and when concurrent programs batch-generate tasks from templates. Users searching for "turbotel for desktop" are unlikely to find relevant documentation here; the term does not correspond to any documented object in this package. For EBS 12.1.1 and 12.2.2, functionality is equivalent, and any customization must respect the object_version_number locking scheme and the FND_API validation levels.