About this Release

This release represents a major improvement to the ESB and major and minor improvements to the mobile application. 

Mobile Application Release Notes

Mobile Application Changes

ENHANCED Advance Ship Parts

ServiceMobility now provides an enhanced process around around handling parts shipped directly to the consumer (advance ship parts).  Once a line item is designated as an advance ship part, the line item must always exist on the work order as an advance ship part, and may therefore only be designed under the following buckets:

• Advance Ship Used
• Advance Ship Unused
• Advance Ship Returned

Advance Ship Used 

An advance ship part is to be designated as used when the technician utilizes that part in the service call.  This is the default behavior of an advance ship part associated as a line item.  Advance ship used parts associated with a work order will be priced as a standard line item part and be subject to line item part pricing.

Setup: To setup the ability to receive advance ship parts with an auto-adjustment shipment, the WorkOrder.receiveAdvShipInventory must be set to true within the Mobile Configuration REST API.  When this is set equal to true, ServiceMobility will receive an auto-adjust shipment with the quantity of advance ship used parts on the work order and then immediately relieve the technician's inventory of all advance ship used parts.  If this field is set to false, ServiceMobility will simply ignore advance ship used parts and not include them as part of any inventory transaction.

Advance Ship Unused 

An advance ship unused part is designated as unused when the technician arrives onsite and does not yet utilize that part in the installation process, but does not yet wish to return that part.  This may be the case when a technician realizes that an additional part is required to complete the service, and an additional follow-up service call must be scheduled with additional parts ordered.  Advance ship unused parts associated with the work order will be priced the same as ordered parts.  This allows certain processes to take effect when a follow-up call must be scheduled such as no additional payment is required from the consumer since they've already put a parts deposit down on a previous call.  

Note: A work order may not be closed as closed-complete when an advance ship unused part is associated with the work order.  The technician must first take one of the following actions:

• Move the advance ship unused part to be an advance ship return part, thus taking that part back into inventory and not leaving it behind at the consumer service location.
• Move the advance ship unused part to be an advance ship used part, thus using that part in the service call and not leaving it behind at the consumer service location.
• Mark the work order as closed-incomplete, where a follow-up service call can be scheduled.

Setup: Within the Mobile Configuration REST API, WorkOrder.advShipUnusedPartsEnabled must be set to true to be able to set an advance ship part to unused via the Line Item Detail screen.  If this field is set equal to false, all advance ship parts will behave as advance ship used parts.

Advance Ship Return

An advance ship return part is a way for the technician to take custody of any part that is unused during a service call, allowing the technician to close the call out as closed-complete.  When designating a part as an advance ship return part, the technician may also choose to provide a reason for return.  This provides two functions:

• Provide reporting to the back-office as to why the part has been returned
• Automatically move that part into the proper inventory bucket based on the reason code

When a part is designated as advance ship return, the user may only perform the following actions:

• Change part designation from advance ship return to advance ship used
• Change part designation from advance ship return to advance ship unused
• Capture return reason code
• Close work order (closed-complete/closed-incomplete) based on validation rules and next course of action required

Setup: To setup the ability to receive advance ship return parts with an auto-adjustment shipment, the WorkOrder.receiveAdvShipInventory must be set to true within the Mobile Configuration REST API. If this field is set equal to false, then ServiceMobility will simply provide the inventory adjustment within the work order inventory usage transaction.

To setup the ability to automatically receive advance ship return parts into good inventory/dispositioned inventory automatically based on a system mapping, the WorkOrder.returnReasonToDispositionMap must be configured within the Mobile Configuration REST API.  The map is in the following format:

"returnReasonToDispositionMap": {
            "1001": "1001",
            "1002": "1002",
            "1003": "1001",
            "1004": "1002"
        },

The left value in the map is the return reason code (setup via system category 29) and the right side of the map is the inventory disposition bucket.

The return reason codes are setup via the System Category: Return Reason Code Types (System Category 29).

{
    "SysCatID": "29",
    "Desc": {
        "en": "Parts Return Reason Codes"
    },
    "SysActs": [
        {
            "SysActID": "1001",
            "IsActive": true,
            "Desc": {
                "en": "Not Suitable"
            }
        },
        ...
    ]
}

Line Item Multi-Edit Enhancements

The multi-edit capability has also been enhanced for the advance ship process. Under the Change Item Type action, the following to and from fields have been added:

• Advance Ship Used
• Advance Ship Unused
• Advance Ship Return

Advance Ship Used may only be designated as the following:

• Advance Ship Unused
• Advance Ship Returned

Advance Ship Unused may only be designated as the following:

• Advance Ship Used
• Advance Ship Returned

Advance Ship Returned may only be designated as the following:

• Advance Ship Used
• Advance Ship Unused

ENHANCED ServiceMobility now provides a new rule to require estimate creation to require a consumer signature.

Setup: WorkOrder.Rules.IsEstimateSigReq = true to require the estimate signature.  When WorkOrder.Rules.IsEstiateSigReq = false or is not present, the estimate signature is not required.

This will work in the following manner in the large form factor version:

• When WorkOrder.Rules.IsEstimateSigReq = true, the Accept button will only be enabled when a signature is captured in the signature panel. 
• When WorkOrder.Rules.IsEstimateSigReq = false or not present, the Accept button will always be enabled.

This will work in the following manner within the small form factor version of the application:

• An Accept button has been added to the bottom of the Estimate Screen.  When the WorkOrder.Rules.IsEstimateSigReq = true, the Accept button will only be enabled after the signature is captured.  When the WorkOrder.Rules.IsEstimateSigReq = false or missing, the Accept button will always be enabled.

NEW ServiceMobility will now force the user to close and relaunch ServiceMobility when the application is not able to connect to the database.  Previously, the application provided an error message but allowed to user to continue to navigate around the application.

CHANGED ServiceMobility will now strictly enforce the following rules when editing an asset:

• Always require a manufacture to be present.  This is consistent with the asset documentation.
• Asset Model Number is only required when Rules.IsAssetModelNumReq = true
• Asset Serial Number is only required when Rules.IsAssetSerialNumReq = true
• Asset install date is only required when Rules.IsAssetInstallDateReq = true
• ModelNumPattern and SerialNumPattern are only applied when Rules.IsAssetModelNumReq and IsAssetSerialNumReq are true, respectively
• IsAssetModelNumReq may be enforced even when ModelNumPattern is false
• IsAssetSerialNumReq may be enforced even when SerialNumPattern is false

ESB Release Notes

CHANGED ServiceMobility Work Order REST API  and Work Order Export REST API has been updated to support advance ship unused parts. This is designated by Items[].IsUnused = true.

CHANGED ServiceMobility work order order REST API and Work Order Export REST API has been updated to support return reason codes.  This is designated by Items[].ReturnReasonCode.  This will hold the values setup in system category 29.

NEW ServiceMobility now provides the ability to configure Return Reason Codes via System Category 29.

CHANGED Modified the Asset REST API and Work Order REST API for assets to include the following fields for ServicePower platform unity:

• RetailerID (string)
• RetailerName (string)
• Cost (decimal)

CHANGED Introducing the following fields within the WorkOrder REST API ServiceContracts Collection for ServicePower platform unity:

• AssetNum (string)
• AuthorizationNum (string)
• AuthorizationLimit (number)
• CoverageEndDate (date)
• CoverageStartDate (date)
• RefNum (string)

CHANGED Introducing a new collection within the Work Order REST API called PurchaseOrder with the following fields for platform unity:

• PONum (string)
• Amount (decimal)

CHANGED ServiceMobility is deprecating the PONum field within the Work Order REST API

CHANGED Introducing RepairLocation object into the WorkOrder REST API with the following data for platform unity:

• Type (string)
• Address object  

Issues Resolved

FIXED Resolved an issue where a partial inventory count was replacing the technician's entire inventory rather than just those parts that were counted.

FIXED Resolved an issue where system notifications weren't being translated into the technician's local time.

FIXED  Resolved an issue where, in some cases, messages coming down from the back-office weren't being applied to the local database.  This happened when ServiceMobility was closed during the processing of the message.

FIXED Resolved an issue where the application is displaying a white screen when logging into the iOS version ServiceMobility for clients utilizing SSO.