Search Results get_version_status_data




Overview
Explore in AI Chat

Overview

APPS.JTS_CONFIG_VER_STATUS_PVT is a private PL/SQL package body within the Oracle E-Business Suite CRM/TeleSales (JTS) schema that manages the lifecycle statuses associated with configuration version records. Its documented purpose is summarized in the package header comment as "Version's Replay Statuses, Dates, By, and Version Statuses." The package was created on 25-Feb-2002 by Sung Ha Huh and carries a header revision of 115.6. As a PVT (private) API classification, it is not intended for direct invocation by external consumers; it underpins the public version-management APIs that govern how Oracle Configurator or TeleSales configuration versions are submitted, replayed, failed, cancelled, or completed.

The package encodes the business rule that a configuration version can occupy exactly one of a defined set of statuses, and separates statuses into two families: replay statuses (transient execution states such as submit, running, success, failure, cancel, error, and no-submit) and version statuses (the persistent state of the version record itself). Every routine enforces the standard EBS API concurrency and version-compatibility contract through FND_API.COMPATIBLE_API_CALL and raises exceptions via APP_EXCEPTION.RAISE_EXCEPTION.

Key Procedures and Functions

  • IN_REPLAY_STATUS — Boolean function that returns TRUE when a supplied status belongs to the set of replay-related constants (submit, fail, cancel, success, error, no-submit, running); returns FALSE otherwise. It is the predicate used throughout the package to distinguish replay activity states from terminal version states.
  • IN_VERSION_STATUS — Boolean function that returns TRUE when a supplied status is a recognized version status, mirroring the validation logic of IN_REPLAY_STATUS for the version-status family.
  • CREATE_VERSION_STATUS — Inserts a new status row for a configuration version, recording status, date, and creating user. This is the primary write routine of the package.
  • DELETE_VERSION_STATUSES — Removes status records for a given version, typically invoked during version cleanup or reset.
  • DELETE_CONFIG_VER_STATUSES — Removes all status records associated with a configuration, cascading at the configuration level rather than the individual version level.
  • ANY_VERSION_REPLAYED — Boolean function indicating whether any version belonging to a configuration has undergone a replay, used to gate re-submission or to report progress.
  • GET_VERSION_STATUS_DATA — Returns the status, associated date, and user for a version, populating the display data required by calling forms or reports.
  • NOT_REPLAYED — Boolean function identifying versions that have not been replayed, supporting filtering and eligibility checks.

Tables Accessed

  • JTS_CONFIG_VERSION_STATUSES — The principal table; stores one row per version status event, including status, date, and user.
  • JTS_CONFIG_VERSIONS_B — Holds the configuration version base records against which statuses are keyed.
  • JTS_CONFIG_VERSION_FLOWS — Defines the permitted transitions or flow rules governing how a version moves between statuses.
  • FND_USER — Resolves the "By" identity (creating or updating user) recorded with each status row.
  • FND_LOOKUP_VALUES — Supplies or validates the lookup-coded status values used by the IN_REPLAY_STATUS and IN_VERSION_STATUS predicates.

Usage Notes

Because the package is classified PVT, it is invoked exclusively by sibling and parent packages — the ETRM metadata records two dependent packages — rather than by forms or concurrent programs directly. In practice, JTS_CONFIG_VER_STATUS_PVT is called from the public configuration-version management layer when a user submits a version for replay, when the replay engine reports completion or failure, and when a version is cancelled or reset. Customizations or extensions should never call this package directly; developers seeking create_version_status functionality should use the supported public API that wraps it. The package behaves identically on Oracle EBS 12.1.1 and 12.2.2, as it resides in the JTS product schema and was not materially changed by the 12.2 online-patcher architecture. Any direct modification should be avoided, since the package body is a shipped, non-customized Oracle object.