Search Results autoreject_task

Overview

APPS.CSF_TASKS_PUB is the public task-management API for Oracle E-Business Suite Field Service. It is the single supported entry point through which the application and external integrations create, modify, advance, close, and validate service tasks. A task represents a unit of field work — a planned visit, a dependent assignment, or an escalation — and its lifecycle is governed by a status model that the package encapsulates.

The package body declares an explicit bit-code representation of task status, including constants such as g_working_bitcode, g_assigned_bitcode, g_planned_bitcode, g_completed_bitcode, g_closed_bitcode, g_onhold_bitcode, g_rejected_bitcode, g_cancelled_bitcode, and g_start_bitcode. Because each status maps to a distinct bit position, status propagation across parent and child tasks — and across dependency and escalation relationships — can be computed with bitwise arithmetic. Default starting statuses are seeded from profiles such as PLANSCOPE, CSF_DEFAULT_TASK_INPLANNING_STATUS, and CSF_DEFAULT_TASK_ASSIGNED_STATUS, so planning scope and initial status behaviour are configurable at the site level. The package also defines three task type identifiers: dependent tasks (20), array tasks (21), and escalation tasks (22).

The header comments identify the source file as CSFPTSKB.pls and indicate that the current form of the package body, including the accepted-status bitcode added for the bug identified in the header, dates from the 12.1.x code line and remained the delivered version for 12.2.2. The constant g_accepted_bitcode, annotated as added for bug 6646890, reflects the acceptance step introduced when dispatchers confirm assignment of a task to a resource.

Key Procedures and Functions

The package exposes 41 documented program units. They fall into three categories.

• Status and transition validation: VALIDATE_STATE_TRANSITION, VALIDATE_STATUS_CHANGE, and GET_VALID_STATUSES evaluate whether a requested movement between states is permitted by the configured state model.
• Status and type lookup: GET_TASK_STATUS_NAME returns the display name of a task's current status; this is the function most commonly referenced by custom reports and inquiry screens. GET_DEP_TASK_TYPE_ID and GET_ARR_TASK_TYPE_ID return the task type identifiers for dependent and array tasks respectively.
• Eligibility and relationship checks: IS_TASK_CLOSABLE, TASK_IS_CLOSABLE, IS_TASK_SCHEDULABLE, CHECK_SCHEDULABLE, IS_TASK_SCHEDULED, IS_TASK_ESCALATED, and HAS_FIELD_SERVICE_RULE answer specific business questions about a task's readiness for closure or scheduling and about its escalation or service-rule linkage.
• Maintenance and lifecycle operations: CREATE_TASK, UPDATE_TASK, DELETE_TASK, CLOSE_TASK, and UPDATE_TASK_STATUS perform the state-changing work, while AUTOREJECT_TASK handles the automatic rejection path and COMMIT_SCHEDULE persists scheduling outcomes.

Parameter lists are not reproduced here; callers should consult the package specification in the target instance, as signatures may vary slightly between 12.1.1 and 12.2.2.

Tables Accessed

The package operates on the task tables and their supporting reference and relationship data. JTF_TASKS_B is the primary base table holding task records. JTF_STATE_RULES_B and JTF_STATE_RESPONSIBILITIES supply the state-transition rules and the responsibility-based access control that drive VALIDATE_STATE_TRANSITION and GET_VALID_STATUSES; JTF_RS_ROLES_B provides resource roles. CSF_ACCESS_HOURS_B and CSF_ACCESS_HOURS_TL define the service calendar used when evaluating schedulability, while CAC_SR_OBJECT_CAPACITY and CSF_DC_QUERIES_B support capacity and debrief query processing. Customer-facing data — HZ_PARTIES, HZ_LOCATIONS, HZ_PARTY_SITES, HZ_CONTACT_POINTS, and CS_HZ_SR_CONTACT_POINTS — is read to resolve the contact and location context of a task, and CSI_ITEM_INSTANCES identifies the installed item in scope. CSF_DEBRIEF_HEADERS links task completion to debriefing. All access is through APPS synonyms.

Usage Notes

CSF_TASKS_PUB is invoked from Field Service forms such as the dispatcher and scheduler consoles, from concurrent programs that mass-update task status or run auto-rejection, and from custom PL/SQL that must honour the same validation and propagation logic used by the application. It is referenced by 18 other packages, so the delivered wrappers in the Oracle Field Service module depend on it directly. Practically, any integration that needs a task's readable status should call GET_TASK_STATUS_NAME rather than decoding JTF_TASKS_B status codes directly, and any custom state change should route through UPDATE_TASK_STATUS or VALIDATE_STATUS_CHANGE so that bit-code propagation to related tasks is preserved. Because the bitcode assignments and profile defaults are compiled constants, custom code must not hard-code the numeric values; it should use the documented functions to obtain status names and valid transitions.