Search Results delete_assign_accts




Overview
Explore in AI Chat

Overview

JTF_TTY_NA_TERRGP is an Oracle EBS PL/SQL package owned by APPS and classified as an "OTHER" API within the ETRM documentation set. Its declared purpose is a Custom Assignment API, and the header explicitly states "ORACLE INTERNAL USE ONLY: NOT for customer use." The package supports the Territory Manager (JTF_TTY) subsystem by managing territory group definitions and the assignment of named accounts, resources, roles, interests, and access rights to those groups. It is declared AUTHID CURRENT_USER, so it executes with the privileges of the invoking schema rather than as definer rights.

The historical comments trace the package's evolution: created on 03/18/02, with procedures for qualifiers and winners added in 03/20/02, log_event added in 07/08/03, and create_acct_mappings added on 04/19/05 to fix bug 3981210. This lineage confirms the package is a long-standing internal component of the Named Account territory assignment framework.

Key Procedures and Functions

  • TERRGP_CREATE_ACCESS — Creates an access record linking a territory group role to a specific access type and access code, using the supplied user ID as the actor. This is the routine the user searched for and is central to granting access to territory groups.
  • TERRGP_DEFINE_ACCESS — Defines access attributes for a territory group, complementing terrgp_create_access in the access setup lifecycle.
  • TERRGP_DEFINE_ROLE — Defines a role for a territory group, associating a group role, user, and role code.
  • TERRGP_DEFINE_INTEREST — Defines an interest for a territory group role, referencing an interest type, category set, and category-enabled flag.
  • TERRGP_ASSIGN_OWNERS — Assigns owners to a territory group.
  • ENTER_TERRGP_DETAILS — Inserts or updates core territory group details such as name, description, rank, date range, territory ID, matching rule code, workflow item type, action type, catch-all user, number of winners, generate-NA flag, and group type.
  • ADD_ORGS_TO_TERRGP — Adds organizations (party, resource, role) to a territory group.
  • DELETE_TERRGP and DELETE_TERRGP_OWNERS_ROLES — Remove a territory group and its associated owner/role assignments.
  • GET_SITE_TYPE — Returns the site type for a party site, used in qualifying territories.
  • CREATE_TGP_NAMED_ACCOUNT and DELETE_TGP_NAMED_ACCOUNT — Create and delete named account records within a territory group.
  • ASSIGN_ACCTS, ASSIGN_ACCT, DELETE_ASSIGN_ACCTS, PROCESS_ASSIGN_ACCTS — Manage the assignment of accounts to territory groups, including bulk processing.
  • SUM_ACCTS, SUM_OWNER_ACCTS, SUM_RES_GP_ACCTS — Aggregate account counts for territory groups, owners, and resource-group combinations, used in winner determination and reporting.
  • GENERATENUMLIST — Generates a numeric list, a utility used by the set-based assignment logic.

Tables Accessed

The package reads and writes foundation data through APPS synonyms. Customer and party data comes from HZ_PARTIES, HZ_PARTY_SITES, HZ_LOCATIONS, and HZ_RELATIONSHIPS. Resource and role data is drawn from JTF_RS_GROUPS_DENORM, JTF_RS_GROUP_MEMBERS, JTF_RS_REP_MANAGERS, JTF_RS_RESOURCE_EXTNS, JTF_RS_ROLES_B, and JTF_RS_ROLE_RELATIONS. Territory-specific data resides in JTF_TTY_NAMED_ACCTS, JTF_TTY_GEO_TERR, JTF_TTY_GEO_TERR_RSC, JTF_TTY_ACCT_QUAL_MAPS, and JTF_TTY_ACCT_QUAL_MAPS_S. These tables supply the qualifiers, geographic territory mappings, and named-account records the API manipulates.

Usage Notes

Because the header states "ORACLE INTERNAL USE ONLY," the package should not be called directly by customer code; supported territory administration flows are expected to reach it through Oracle Forms or concurrent programs in the Territory Manager module. Typical invocations include Territory Manager setup forms and batch assignment or summarization concurrent requests, where assignment, sum_*, and process_assign_accts routines compute winners and account rollups. The package is referenced by three other packages, confirming it acts as a lower-level service layer. Customizations that depend on its behavior should be validated against patches, since the header shows it has been modified to resolve specific bugs.