Search Results sync_terr_group




Overview
Explore in AI Chat

Overview

JTF_TTY_POP_TERR_ADMIN_BIN_SUMM is a private (PVT) PL/SQL package in the APPS schema that supports the Oracle EBS Territory Management subsystem, part of the CRM Foundation / Trade Management foundation layer. Its declared purpose is to populate and maintain territory administration "bin" summary data and to synchronize territory groups used by the Territory Manager. The package establishes administrative bin information — the aggregate buckets that organize territories, accounts, and resources for administrative reporting and assignment processing — and is compiled with AUTHID CURRENT_USER, meaning that all unqualified SQL statements resolve against the privileges of the invoking session rather than the package owner.

The header comment (jtfvuabs.pls, version 120.0) records the package as created on 15-SEP-2002 and shipped in that form; no subsequent revision entries appear in the source control block, indicating the interface has been stable across the 12.1.1 and 12.2.2 releases. It is an internal helper rather than a public API, and is referenced by one other package in the territory administration stack.

Key Procedures and Functions

The package specification exposes three documented procedures, each of which returns status information through a standard return status and error message pair of OUT NOCOPY parameters. No IN parameters are declared in the published specification, so each procedure operates on the full administrative bin and territory group data set in scope.

  • POPULATE_CATCH_ALL_BIN_INFO — Populates the catch-all bin information. The catch-all bin is the default administrative bucket that receives accounts or resources not explicitly assigned to a named territory bin, ensuring no assignment is left unclassified in territory administration reporting. This is the procedure referenced by the search term "populate_catch_all_bin_info."
  • POPULATE_KPI_BIN_INFO — Populates KPI-oriented bin information, building the summary buckets used to surface territory key performance indicator data within the administrative bin summaries.
  • SYNC_TERR_GROUP — Synchronizes territory group definitions, aligning territory group header records with their associated account assignments so that group membership remains consistent with the underlying territory data.

Tables Accessed

The ETRM metadata documents the following tables as accessed through APPS synonyms:

  • JTF_TTY_ADMIN_BIN_SUMM — the administrative bin summary table that stores the aggregated bin information produced by the population procedures.
  • JTF_TTY_TERR_GROUPS — territory group header definitions, maintained by SYNC_TERR_GROUP.
  • JTF_TTY_TERR_GRP_ACCTS — the territory group-to-account association table, reconciled during synchronization.
  • JTF_TTY_NAMED_ACCT_RSC — named account resource assignments, used to determine which resources and accounts fall into named versus catch-all bins.
  • JTF_TERR_ALL — the consolidated territory definition table that supplies the territory hierarchy underlying bin construction.
  • AS_TERRITORY_ACCESSES — territory access permissions, consulted to respect access restrictions when bin information is generated.

Usage Notes

As a PVT package, JTF_TTY_POP_TERR_ADMIN_BIN_SUMM is not intended for direct invocation by customers or integrators. It is called from within the territory administration module — typically from the Territory Manager administrative forms or from the concurrent programs that refresh territory bin summaries after territory, account, or resource changes. Because the procedures commit administrative bin state and territory group synchronization, they should be invoked only through the supported territory administration flows rather than from ad hoc custom code. Customizations that must run these procedures should call the public territory administration APIs that wrap them, validate the returned status and error message values, and avoid concurrent execution against the same territory set, since the population and synchronization routines operate on shared summary tables. The stability of the specification since 2002 means any 12.1.1 custom code relying on these signatures remains valid on 12.2.2.