Search Results template_rec_type

Overview

ASO_SUP_TEMPLATE_DATA_PVT is a private PL/SQL package in the APPS schema belonging to the Oracle Order Management / Oracle Sales Offline (ASO) product family. It encapsulates the persistence and validation logic for supplemental template definitions. These templates are the configurable structures that drive the display and capture of supplemental (user-defined) attributes attached to sales documents such as quotes, orders, and returns. By concentrating template creation, modification, and semantic validation in a single private package, Oracle separates the template data model from the public APIs and the HTML/Forms front ends that consume it.

The package is declared with AUTHID CURRENT_USER and carries a header date stamp of 2005, indicating a mature, stable component in the 11i through 12.x code lines. Its private (PVT) classification means it is not a supported integration surface; it is invoked internally by sibling packages and product UI infrastructure rather than by customer extensions directly.

Key Procedures and Functions

ETRM documents three program units within this package:

• Validate_Template — A function returning a status string. It accepts a template context and template level and determines whether the supplied combination represents a valid template configuration. This check governs whether a template may be instantiated for a given business context and hierarchy level.
• CREATE_TEMPLATE — Inserts a new supplemental template record. It follows the standard EBS API contract: an API version number, an initialization flag for the message list, a commit flag, an input record typed as TEMPLATE_REC_TYPE, and output parameters returning the generated template identifier, return status, message count, and message data.
• UPDATE_TEMPLATE — Performs the corresponding modification of an existing template, observing the same API messaging and commit conventions as CREATE_TEMPLATE.

The package also declares the record type TEMPLATE_REC_TYPE, a row-shaped structure containing template_id and the standard WHO audit columns (created_by, creation_date, last_updated_by, last_update_date, last_update_login), followed by TEMPLATE_NAME, DESCRIPTION, TEMPLATE_LEVEL, TEMPLATE_CONTEXT, CONTEXT, and twenty descriptive flexfield attribute columns (ATTRIBUTE1 through ATTRIBUTE20, each VARCHAR2(240)). A global variable, G_Miss_Template_Rec, provides an empty instance of this record for defaulting and comparison purposes. The record definition establishes the canonical in-memory representation used by both the create and update program units.

Tables Accessed

The documented table reference for this package is FND_LOOKUP_VALUES, accessed through an APPS synonym. This table supplies the valid values against which template levels and contexts are validated, most likely through the common lookup types that define supplemental template levels (for example, header, line, or other document hierarchy levels) and the associated context codes. Validate_Template consults these lookup values so that template validation remains consistent with administrator-maintained reference data rather than hard-coded constants. No other base table is documented in the available metadata, although the create and update procedures logically persist into the supplemental template table itself.

Usage Notes

Because ASO_SUP_TEMPLATE_DATA_PVT is classified PVT and is referenced by zero other documented packages, it is best understood as an internal worker invoked from the Oracle Sales Offline setup and administration flows. Typical invocation paths include the Oracle Forms-based supplemental template setup screens and any concurrent or backend process that provisions templates programmatically. The procedures adhere to the FND_API messaging pattern, so callers retrieve outcomes through X_Return_Status, X_Msg_Count, and X_Msg_Data rather than through exceptions, and transaction control is deferred unless P_Commit is passed as FND_API.G_TRUE.

For EBS 12.1.1 and 12.2.2, the package remains unchanged in both releases and should be treated as an unsupported extension point. Customizations requiring template maintenance should invoke the public ASO supplemental APIs or the supported setup UI. Any direct call must honor the API version parameter, initialize message handling appropriately, and never assume that internal behavior is preserved across patch levels; the 120.1 header version confirms that Oracle considers this code frozen with respect to its original design intent.