Panel | |
---|---|
On This Page:
|
Include Page | ||||
---|---|---|---|---|
|
About this Release
This release represents a major improvement to the ESB and major and minor improvements to the mobile application.
Include Page | ||||
---|---|---|---|---|
|
Mobile Application Release Notes
Mobile Application Changes
Advance Ship Parts Status colour Green title ENHANCED
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:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
"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).
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
{ "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
ServiceMobility now provides a new rule to require estimate creation to require a consumer signature. Status colour Green title Enhanced
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.
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. Status colour Green title NEW
ServiceMobility will now strictly enforce the following rules when editing an asset: Status colour Yellow title changed
- 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
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. Status colour Yellow title 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. Status colour Yellow title CHANGED
ServiceMobility now provides the ability to configure Return Reason Codes via System Category 29. Status colour Green title NEW
Modified the Asset REST API and Work Order REST API for assets to include the following fields for ServicePower platform unity: Status colour Yellow title CHANGED
- RetailerID (string)
- RetailerName (string)
- Cost (decimal)
Introducing the following fields within the WorkOrder REST API ServiceContracts Collection for ServicePower platform unity: Status colour Yellow title CHANGED
- AssetNum (string)
- AuthorizationNum (string)
- AuthorizationLimit (number)
- CoverageEndDate (date)
- CoverageStartDate (date)
- RefNum (string)
Introducing a new collection within the Work Order REST API called PurchaseOrder with the following fields for platform unity: Status colour Yellow title CHANGED
- PONum (string)
- Amount (decimal)
ServiceMobility is deprecating the PONum field within the Work Order REST API Status colour Yellow title CHANGED
Introducing RepairLocation object into the WorkOrder REST API with the following data for platform unity: Status colour Yellow title CHANGED
- Type (string)
- Address object
Issues Resolved
Resolved an issue where a partial inventory count was replacing the technician's entire inventory rather than just those parts that were counted. Status colour Red title FIXED
Resolved an issue where system notifications weren't being translated into the technician's local time. Status colour Red title 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. Status colour Red title FIXED
Resolved an issue where the application is displaying a white screen when logging into the iOS version of ServiceMobility for clients utilizing SSO. Status colour Red title FIXED
Include Page | ||||
---|---|---|---|---|
|