Search Results get_current_task




Overview
Explore in AI Chat

Overview

JTF_AGENDA_CALCULATIONS is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM API classification OTHER. It forms part of the Oracle Field Service / TeleService scheduling infrastructure delivered through the JTF (Java Technology Foundation) product family, which underpins the CRM service request and task-management modules. The package supplies date and status computation utilities used by the service scheduling engine to derive shift boundaries, assignment progress and status information, task escalation behaviour, and sequence flags for scheduled tasks. The declared AUTHID CURRENT_USER clause indicates the package executes with the privileges of the invoking user, and the header comment (JTFAGCAS.pls 115.5) confirms it is a long-standing, stable component of the codebase present in both 12.1.1 and 12.2.2 releases. The ETRM metadata documents nine callable functions and no standalone procedures, and notes that the package is referenced by two other packages within the application, confirming its role as a shared utility layer rather than a top-level business API.

Key Procedures and Functions

  • PREDICT_TIME_DIFFERENCE — Returns a numeric value representing a predicted elapsed-time difference for a given task assignment, used by scheduling logic to estimate durations between task events.
  • SET_SEQUENCE_FLAG — Returns a varchar2 value that establishes or evaluates the sequencing flag for a task assignment, supporting ordered processing of tasks in an agenda.
  • GET_PROGRESS_STATUS — Returns a numeric progress-status indicator for a resource of a specified resource type at a given date, allowing the scheduling engine to report advancement through an assigned workload.
  • GET_SHIFT_START — Returns a date representing the beginning of a shift, resolved from a shift construct, resource, resource type, and reference date. All four inputs carry defaults, permitting flexible invocation.
  • GET_SHIFT_END — Returns the corresponding date marking the end of the applicable shift, using the same optional input pattern as GET_SHIFT_START.
  • GET_ASSIGNMENT_STATUS — Returns a numeric status identifier for the assignment associated with a given resource and resource type code.
  • GET_STATUS_NAME — Returns the varchar2 display name corresponding to a numeric status identifier, providing a decoded, user-facing label.
  • GET_CURRENT_TASK — Returns the numeric identifier of the task currently active for a resource and resource type, enabling the calendar and agenda views to highlight in-progress work.
  • SET_ESCALATION_FLAG — Returns a varchar2 value that sets or evaluates the escalation indicator for a given task identifier, driving escalation handling within service task processing.

Tables Accessed

ETRM documents two base tables referenced through APPS synonyms. JTF_CAL_SHIFT_CONSTRUCTS supplies the shift definitions consumed by GET_SHIFT_START and GET_SHIFT_END, providing the construct records from which calendar shift boundaries are resolved. JTF_TASKS_B is the base table for JTF tasks and provides the task-level data used by the functions that operate on task assignments and task identifiers, including SET_ESCALATION_FLAG, SET_SEQUENCE_FLAG, and GET_CURRENT_TASK. The package is read-oriented in practice, surfacing calculated values to callers rather than owning transactional data, though the flag-setting functions may influence task state.

Usage Notes

JTF_AGENDA_CALCULATIONS is an internal utility package rather than a user-facing API. It is typically invoked from Oracle Forms and OAF pages in the Field Service and TeleService modules, from concurrent programs that build resource schedules, and from custom PL/SQL that extends the standard scheduling logic. The presence of SET_ESCALATION_FLAG in the documented interface explains why a search on that term resolves here: developers extending escalation behaviour should call the packaged function rather than replicating the logic. Because the package is referenced by two further packages, customisations should treat it as a shared dependency and avoid direct modification; the correct extension approach in 12.1.1 and 12.2.2 is to call the documented functions or wrap them in a custom package.