Search Results jtf_terr_date_list




Overview

JTY_ASSIGN_REALTIME_PUB is a public PL/SQL API within the Oracle E-Business Suite Territory Management (ETRM) module. Its documented purpose is to return winning territories or the territory resources associated with those territories in real time. Unlike batch territory assignment, which processes transactions after the fact, this package evaluates assignment logic at the point of transaction entry where the caller must be given the current winner immediately.

The package was created on 05/04/05 by achanda and carries the header identifier jtftraes.pls 120.2.12010000.2, last updated 2008/12/11. It is classified as a PUB (public) API, meaning Oracle explicitly exposes it for use by external product teams and custom code rather than restricting it to internal ETRM processing. The package is referenced by twelve other packages, which is consistent with its role as a shared real-time assignment engine for modules such as Order Management, Advanced Pricing, and TeleSales.

Key Procedures and Functions

The documented public interface consists of three routines:

  • GET_WINNERS — Returns the winning territory or territories for a given transaction, using real-time evaluation rather than the staged qualifier processing employed by batch assignment. It is the primary entry point when a caller requires the identity of the winning territory only, without materializing the associated territory resources.
  • PROCESS_MATCH — Performs the match evaluation against transaction usage program definitions and qualifiers. It embodies the core qualification logic that determines whether a transaction satisfies the criteria of a territory.
  • PROCESS_WINNERS — Combines matching and winner determination to produce the final assignment result, and is the routine invoked when both the matching evaluation and the winning outcome must be produced in a single call.

The package also declares the record type bulk_trans_id_type, intended for product teams that use pass-by-reference parameter passing. This record holds up to five collections of transaction object primary keys (trans_object_id1 through trans_object_id5, each of type jtf_terr_number_list) together with a transaction date collection, txn_date, of type jtf_terr_date_list. A global default instance, G_MISS_BULK_TRANS_ID, is declared for this type. The presence of jtf_terr_date_list in this structure is central to date-effective assignment, where territory eligibility is resolved as of a specific transaction date rather than the system date.

Tables Accessed

The package reads from the principal territory definition and resource tables through APPS synonyms. JTF_TERR_ALL supplies the territory definitions being evaluated, while JTF_TERR_RSC_ALL and JTF_TERR_RSC_ACCESS_ALL provide territory-resource mappings and access restrictions used to resolve the resources returned for a winning territory. Qualifier metadata is sourced from JTF_QUAL_TYPES_ALL. Resource attributes are drawn from JTF_RS_RESOURCE_EXTNS and its translation table JTF_RS_RESOURCE_EXTNS_TL, with group, role, and team assignments read from JTF_RS_GROUPS_TL, JTF_RS_ROLES_B, and JTF_RS_TEAMS_TL. The transaction usage program definitions and their generated SQL are read from JTY_TRANS_USG_PGM_DETAILS and JTY_TRANS_USG_PGM_SQL, which drive the qualification criteria for the calling transaction type. PLITBLM is the standard EBS PL/SQL table-handling package used for collection manipulation.

Usage Notes

JTY_ASSIGN_REALTIME_PUB is typically invoked from Forms-based transaction entry, from concurrent programs that require immediate rather than scheduled assignment, and from custom PL/SQL code that must determine territory ownership inline. Callers pass transaction identifiers using the bulk_trans_id_type record, supplying the transaction date through the jtf_terr_date_list collection so that date-effective territories resolve correctly. Because the package is a public API and is referenced by twelve other packages, it should be treated as a stable integration point; callers should not depend on internal implementation details beyond the three documented routines and the declared record type.