Search Results jtf_varchar2_table_400

Overview

JTF_TERR_LOOKUP_PUB_W is a public PL/SQL package in the APPS schema that forms part of the Oracle E-Business Suite Territory Management infrastructure, delivered within the CRM/Telesales foundation (the JTF product family). Its business purpose is to expose territory and organization lookup data to other EBS components, and to perform the array-based data marshalling that allows PL/SQL collections to cross the boundary between Java or OAF (Oracle Application Framework) presentation layers and the database. The "_W" suffix identifies the package as a generated wrapper: it is the public façade over the internal implementation package JTF_TERR_LOOKUP_PUB, providing a stable, callable interface for external consumers such as Oracle Forms, concurrent programs, and Java-based middle-tier code.

The package is classified in ETRM as API classification OTHER, meaning it is an internal supporting API rather than a documented, supported extension point for customer customization. In EBS 12.1.1 and 12.2.2 the package is compiled and present in every environment where Territory Management is licensed and installed.

Key Procedures and Functions

ETRM documents eight callable units. The rosetta family implements the standard "Rosetta" pattern used throughout EBS for collection-based integration, in which parallel indexed collections are copied into and out of a record-set type.

• ROSETTA_TABLE_COPY_IN_P3 — Copies inbound parallel collections into an org_name_tbl_type record set. This is the entry marshalling routine used by callers that supply territory/organization data in array form.
• ROSETTA_TABLE_COPY_OUT_P3 — Performs the inverse operation, unpacking an org_name_tbl_type record set into individual OUT collections. This is the exit marshalling routine used when results are returned to the caller.
• ROSETTA_TABLE_COPY_IN_P5 — A variant of the inbound marshalling routine handling a wider set of parallel collections (fifth profile variant).
• ROSETTA_TABLE_COPY_OUT_P5 — The corresponding outbound variant for the fifth profile.
• ROSETTA_TABLE_COPY_IN_P7 — A further inbound variant supporting an extended column profile.
• ROSETTA_TABLE_COPY_OUT_P7 — The corresponding outbound variant for the seventh profile.
• GET_ORG_CONTACTS — Returns the contacts associated with an organization, supporting territory lookup by contact resource.
• GET_WINNERS — Returns the winning territory or territories for a given input, i.e. the territory assignment result resolved by the Territory Manager engine.

The P3 profile signature, as documented, accepts the widest mix of collection types: several JTF_NUMBER_TABLE parameters alongside one JTF_VARCHAR2_TABLE_400, one JTF_VARCHAR2_TABLE_300, and numerous JTF_VARCHAR2_TABLE_100 parameters. This is why the object surfaces in searches for jtf_varchar2_table_400: the 400-character collection is the largest string column in the interface, typically carrying a description or name field.

Tables Accessed

The only table documented as referenced through APPS synonyms is PLITBLM, the standard EBS PL/SQL integer table used for name/value pair storage and generic list handling. No transactional territory base tables are documented as directly accessed by this wrapper; the substantive territory reads occur in the underlying JTF_TERR_LOOKUP_PUB implementation, while the wrapper's role is to pass collections in and out of that implementation.

Usage Notes

Because the package is a wrapper with API classification OTHER, it is not intended for direct customer invocation. It is called programmatically by the Territory Management engine, by Oracle Forms-based territory administration screens, and by middle-tier Java code that needs to pass array parameters into the database. The Rosetta copy procedures are invoked in matched pairs — an IN call before processing, an OUT call after — and collection indexes must be dense and 1-based, since the copy routines rely on positional correspondence between parallel collections. Custom code should call the supported JTF_TERR_LOOKUP_PUB interface rather than this wrapper, as wrapper signatures can change between patch levels and releases. No other packages reference this wrapper according to ETRM, confirming its status as a leaf-level integration aid rather than a shared utility.