Search Results csm_task_assignments_pkg




Overview

The APPS.CSM_TASK_ASSIGNMENTS_PKG package is a PL/SQL synchronization component within the Oracle E-Business Suite Field Service (CSM) module. Its principal business function is to propagate Task Assignment changes captured on a handheld or disconnected client device back to the enterprise database. This process, referred to in the source header as "upward sync," allows field technicians working in a mobile environment to create and modify task assignments offline and then transmit those changes to the central system once connectivity is restored.

The package is declared with AUTHID CURRENT_USER, meaning that it executes with the privileges of the invoking user rather than the definer, which is typical of packages invoked within the Mobile Field Service synchronizer framework. The package spec was originally created by DBhagat on 11 September 2002 and carries a version header dated 2013, indicating on-going maintenance through the 12.1.1 and 12.2.2 release lines. It is classified in the ETRM repository under API classification OTHER, reflecting that it is a synchronization utility rather than a transactional business API.

Key Procedures and Functions

The package exposes two documented program units:

  • APPLY_CLIENT_CHANGES — A procedure that performs the actual upload of Task Assignment changes from the handheld to the enterprise database. It is described in the source as the entry point called by CSM_SERVICEP_WRAPPER_PKG for upward synchronization of the CSM_TASK_ASSIGNMENTS publication item. It accepts a user name, a transaction identifier, and a debug level, and returns a status indicator to the caller.
  • CONFLICT_RESOLUTION_METHOD — A function that determines how conflicts are resolved when a change arriving from the client collides with a change already made on the server. It takes a user name, a transaction identifier, and a sequence number, and returns a string identifying the resolution method to apply. This supports the Mobile Field Service conflict-resolution framework, which allows different strategies to be selected per publication item.

Both units are designed to be invoked only through the CSM synchronization wrapper, never directly by end users.

Tables Accessed

The package operates against a broad set of Mobile Field Service and Service Request tables, accessed through APPS synonyms. Its transactional targets include the accounting and inquiry views for the debrief process — CSM_DEBRIEF_HEADERS_ACC and CSM_DEBRIEF_HEADERS_INQ, together with CSM_DEBRIEF_LINES_ACC and the mobile inquiry views CSF_M_DEBRIEF_LABOR_INQ, CSF_M_DEBRIEF_PARTS_INQ, and CSF_M_DEBRIEF_EXPENSES_INQ. Service request and incident data are read and updated through CSM_REQ_HEADERS_ACC, CSM_REQ_HEADERS_INQ, CSM_INCIDENTS_ALL_ACC, and CSM_INCIDENTS_ALL_INQ. Supporting data is drawn from ASG_USER for assignment ownership, CSF_DEBRIEF_HEADERS and CSM_NOTES_ACC / CSF_M_NOTES_INQ for debrief and note records, and CSM_CLIENT_UNDO_REQUEST_INQ to process client-initiated undo requests. Together these tables supply the assignment, debrief, and service-request context needed to reconcile client changes.

Usage Notes

This package is not intended for direct invocation by forms, concurrent programs, or custom code. It is called exclusively by CSM_SERVICEP_WRAPPER_PKG during the Mobile Field Service synchronization cycle, triggered when a handheld client uploads changes to the CSM_TASK_ASSIGNMENTS publication item. The wrapper supplies the user name, transaction identifier, and debug level, and interprets the returned status to report success or failure of the sync.

Administrators troubleshooting Mobile Field Service synchronization issues may enable the debug level to obtain diagnostic output. Because the package is referenced by one other package and carries no standalone menu or concurrent program entry, any custom extension should preserve the wrapper-driven call model rather than invoking APPLY_CLIENT_CHANGES independently, as the conflict-resolution and transaction bookkeeping logic depends on the synchronizer context.