Debrief Transaction Processing and Part Scanning

Starting with Oracle Fusion Field Service 26D, Debrief changes how labor, expense, added part, and returned part details are stored and submitted for processing. Debrief no longer creates or updates Oracle Fusion Field Service Inventory entity records to store these transaction details. Instead, the Debrief plug-in retains the details in the local browser storage and submits them to the applicable Oracle Fusion application based on the activity context and configuration.

Mobile workers can continue to enter labor, expenses, added parts, and returned parts in Debrief. Debrief evaluates whether the activity is associated with a Service Work Order, Maintenance Work Order, Project, or Project Task and routes the supported transactions accordingly.

Update 26D also introduces barcode scanning for added and returned parts. Mobile workers can scan a supported item or serial-number barcodes to identify inventory items and serial numbers during Debrief.

Before applying the update 26D Debrief plug-in, review these processing changes and assess their impact on integrations, extensions, reports, operational procedures, and other solutions that depend on Debrief or Field Service Inventory records. Validate the updated behavior in a test environment before deploying the update to production.

How Debrief Works Based on Activity Context

An Oracle Fusion Field Service activity can originate from an upstream Oracle Fusion application. The activity can be associated with a Service Work Order, Maintenance Work Order, Project, or Project Task.

Debrief evaluates the activity context and the configured processing parameters to determine where each supported transaction must be submitted.

Distinguish the activity context from the downstream labor destination:

A Project or Project Task provides the project context for the activity.
Oracle Time and Labor receives the applicable time card or time-entry information.
Oracle Time and Labor isn't another name for Oracle Project Management.
Added and returned parts require a supported work order context so that Debrief can determine the applicable material-processing application.

Process Service Work Order transactions

When an activity is linked to a Service Work Order, Debrief uses the Service Logistics processing flow for applicable transactions.

When Oracle Time and Labor processing isn't configured, Debrief submits supported labor, expense, added part, and returned part details through Service Logistics according to the Service Logistics configuration.

When Oracle Time and Labor processing is configured:

Labor hours are submitted to Oracle Time and Labor.
Added and returned parts continue through the Service Logistics processing flow.
Other supported transactions follow the configuration associated with the Service Work Order.

Service Logistics configuration determines how the reported activity is represented for downstream service processing and billing.

Process Maintenance Work Order transactions

When an activity is linked to a Maintenance Work Order, Debrief uses the Maintenance processing flow for applicable transactions.

When Oracle Time and Labor processing isn't configured:

Labor is represented through the applicable resource transaction.
An added part results in a material issue transaction.
A returned part results in a material return transaction.
Expenses are processed according to the supported Maintenance Debrief configuration.

When Oracle Time and Labor processing is configured:

Labor hours are submitted to Oracle Time and Labor.
Added and returned parts continue through the Maintenance material transaction flow.
Other supported transactions follow the configuration associated with the Maintenance Work Order.

Process Labor for a Project or Project Task

When an activity is associated with a Project or Project Task, Debrief can create time information for Oracle Time and Labor.

Processing depends on the Debrief plug-in configuration:

When pjcExpenditureTypeConfig is configured, Debrief provides the information required to process labor as a Project expenditure. A Project identifier is required.
When payrollTypeConfig is configured, Debrief provides the information required to process labor for Payroll.
When both the parameters are configured, the labor time information can be used for both Payroll and Project expenditure processing. A Project identifier is required for Project expenditure processing.

These parameters control the classification and destination of labor time. They don't configure added part or returned part processing.

When the activity also has a Service Work Order or Maintenance Work Order context, part transactions follow that work order context:

Parts associated with a Service Work Order are processed through Service Logistics.
Parts associated with a Maintenance Work Order are processed through Maintenance.

A Project or Project Task by itself doesn't provide a destination for added part or returned part transactions.

Handle Activities Without a Supported Context

The Debrief page can be displayed for an activity that isn't linked to a supported Service Work Order, Maintenance Work Order, Project, or Project Task.

In this situation, the mobile worker can review the available Debrief information, but the transaction can't be submitted until the activity contains a supported context.

Store and submit Debrief transactions

Starting with Update 26D, the Debrief plug-in no longer posts Debrief transaction details by updating the Oracle Fusion Field Service Inventory entity.

The processing flow is:

The mobile worker enters labor, expenses, added parts, and returned parts in Debrief.
The Debrief plug-in retains the transaction details in the local browser storage.
Debrief evaluates the activity context and applicable configuration.
Debrief submits the transaction to Service Logistics, Maintenance, or Oracle Time and Labor, as applicable.
The downstream Oracle Fusion application processes the corresponding labor, expense, material, return, service, or time transaction.

Scan added and returned parts

Mobile workers can scan the supported item or serial-number barcodes to identify parts and reduce manual entry.

Scan added parts

When adding a part, the mobile worker can scan a supported barcode to identify the applicable item or serial number.

Debrief uses the activity context to determine whether the transaction is processed through Service Logistics or Maintenance.

Scan returned parts

When adding a returned part, the mobile worker can scan a supported barcode to identify the returned item or serial number. Debrief uses the activity context to determine the appropriate return-processing flow.

Business Benefits

Reduces dependency on Field Service Inventory records. Debrief no longer uses these records to store and submit Debrief transaction details.
Simplifies part identification. Mobile workers can scan the supported barcodes to identify the added and returned items and reduce manual entry of item and serial numbers.
Aligns processing with activity context. Labor and material processing follows the originating Service Work Order, Maintenance Work Order, Project, or Project Task context, as applicable.

Steps to enable and configure

This capability requires update 26D of the standard Debrief plug-in.

Tips and considerations

Before applying the update:

Review the Debrief processing changes introduced in Update 26D.
Identify the integrations, extensions, reports, or automation that read or update Oracle Fusion Field Service Inventory records created by Debrief.
Review the custom properties previously used to store the added part, returned part, labor, or expense information.
Confirm that the required Service Logistics, Maintenance, Project, and Oracle Time and Labor configuration is available for the activity contexts used by your organization.
Validate the updated behavior in a test environment before deploying the update to production.