Mobility : Status service order never move from "SA in ROUTE"

Do you see any errors in the Alliance application Event Viewer logs when the Start Work transaction is processed?  Look in there to see if any error details are captured, that may help to pinpoint the problem...

Were any new builds applied just prior to when the issue started happening?  Alliance or Mobile?
Thanks,
Reid

Hi Philippe,

I can’t say why you have such cases as there could be several things that may result in this scenario.  This is why Reid suggested looking at the event logs.

One thing also, if you enable the Employees Security - Audit API for one of the users having this issue with a specific work order, this will capture inbound API’s from the user which can be reviewed via the Inbound Data Audit (Integration Module) to view any API’s or results captured by Alliance.

If an API is captured, it might give you a clue what is happening.  If an API is not captured, then something seems to be going wrong within Mobile itself I would monitor connectivity, etc.  After finished capturing, please do not forget to turn off the Audit API’s for this user from the configuration as it should only be used during troubleshooting.

In the case you reference from Bjørn, we found it was data corruption that was sent down to the mobile client but not determined how it occurred.  What I found was that instead of starting work from the Activity card using the Start Work button, if I went to the Completion card, click on the orange circled ? to the right of the Activity label (upper left of the Completion card usually), it would open the activity module for maintenance.  What I saw was that even if I clicked Start Work on the Activity card and time was visible in the activity from that route, when entering the Activity from Completion card the start time was NOT populated.  I do this and the backend Mobile/Alliance was properly populated with the status SA On Site instead of the SA In Route.  Again, i don’t know why this happened but after using this work around the remaining work orders were able to start work normally for that user.

I don’t know what version of Alliance you are using but after 15.4 SU8, we found issues with processing date/time with some databases which were configured as non-English databases (e.g. Norwegian, French, etc.) on the database servers.  This has been fixed since SU10 with a new \bin\Framework\Astea.AO.DBadapter.dll file.  This file is also backward compatible to SU8 and SU9.

If this had been a problem, you would normally see errors returned to the mobile client but seeing as you did not mention any errors, this is likely not the problem but still should be checked.

Once you have more information, it is recommended you log a case to IFS Support to take this up further.

Hi, thanks for your answerS.

We have some others informations. 

For a technician who was audit API, for a service order with “SA in route” status although the report has been sent (and signature collected and joinned in the service order) we have found those messages API : 

• one API message for the start travel, successfull,
• one API message that sends all the results of the checklist, successfull,
• one API message that sends the report, successfull 

but no message with start work and no message with stop work.

And some minutes after the API message “send report”, we have found an error message : “there is at least one activity not fullfilled. So you cannot delete this order from your device” (perhaps not exactly this message because I have translated it from french...)

Our customer Alliance version :  15.4.5.0

Do you see any entries (error or otherwise) in the Alliance Event Viewer log files?  Try running another test where you clear those out right before you send up the Start Work API from the mobile application...(then there should be only one transaction for this particular SV# captured in the log if you hit refresh right afterwards).  See if there are any additional details captured in there…

If you still don’t see any evidence of the SV# in the Alliance application logs then take a look in the mobile log files for the day (start at the bottom of the file and search upwards to see the last few entries for that particular SV#), see if that yields any additional information.
Thanks,
Reid

We have asked the customer to ask the technician, how he can do that… Because we are not able to reproduce this. It happens sometimes for some technicians, not always the same…

The analysed case above has happened on february the 6, some logs have been cleared

Hi Philippe,

In the earlier case you mentioned, it was happening for all orders involving two newly created field engineers.

They reviewed the settings and found something which perhaps has an influence on this in the Employees Security settings.

The configuration level of the two new field engineers encountering this issue was not properly set up and showing Setup.  This should have been Employee.

After fixing this by using the lookup for Mobile Configuration and selecting Default Configuration again in the lookup, it updated to Employee.

They are monitoring this but so far have not had reports from the previously affected field engineers for the same issue not updating from SA In Route to SA On Site.

Hi Phil, 

thanks for this information, I have informed the customer about this

Have a good day

Philippe

Hi Phil,
Were those employees created via an Import or Integration initially?  Or were they created manually through the Employees module in Alliance?
Thanks,
Reid

Hi Reid,

I suspect it was through imports as they normally do this but do not have confirmation from them.  All I know is that they did not have Configuration level = Employee.

Hi Phil and Reid, do you think thas this IL is linked ? 

In our customer case, the technician never clicks on start or stop work but can finish the job, and the activity report is generated. 

BEst regards

Philippe

Hi Philippe,
Are there any errors captured in the logs?  See if there’s an error related to the duration on the activity (if that’s a NEGATIVE value calculated there then it’s probably the same issue...upgrade them to SU8 or greater which has the fix):
“Cannot read properties of null (reading ‘_millis’) (caused by “Possibly unhandled rejection: {}”)

Thanks,
Reid

Hi Reid, Hi Phil

The users has been creted by import, but for a same user, only for few SV the status stay at “SA in route”, for the majority of his SV it’s ok with the status. It happens for several users but just sometimes.

For a SV in “error”, we don’t find any error in “Inbound Data Audit (Integration)” module for it on february 14. We only found the API below for start travel, no API for Start Work / Stop work

The service order : 

For the SV attached documents we can see the Signatures : 

The report has been attached manually bu a back-office user (frederci Chanu). 

The 5 jpg attached, I think for photos in checklist, and with the same name,  are “blanks” if we click on it ,

The checklist : 

Thanks

Philippe

Hi Philippe,
Take a look in the Mobile Application log files, see if you see any errors captured in those.  I suspect it’s erroring out there when it’s trying to create the Start Work API so see if you see anything in those log files like the following:

“Cannot read properties of null (reading ‘_millis’) (caused by “Possibly unhandled rejection: {}”)

If you know the day that the start work API SHOULD have been generated (probably Feb 14th), then go to the mobile server and grab the .txt file for that day (AsteaLogYYYYMMDD.txt syntax) from the following folder:

Program Files\Alliance Mobile Edge\AsteaMobileEdgeServices\Logs

Then search for that SV# and see if there are any error entries captured in there for this user...
Thanks,
Reid