Hi,

is Anywhere built to handle multiple users working on the same workorder?

We seem to have issues with one person having no or little connection and working in offline mode and another with connection but they are both clicking on the timer icon to set the workorder into INPRG. This is the scenario

1.Person A in offline mode starts the workorder and puts into INPRG
2. Sometime later Person B who has connection sees workorder still in APPR and so hits timer icon to put in INPRG
3. Person A gets signal but sync issues because status date cannot be earlier than the current status date (they put into INPRG before Person B)
4. So Person's A actual labor and work logs don't sync and will lose changes if they discard

I assume on the device it has a queue of transaction to be sent but is it sequential in terms of if one errors does it stop everything?
And there is there visibility of these transactions to say discard the status change but sync the rest? Does it not sync child objects first before the main workorder?

Thanks
Chris

------------------------------
Christopher Kung
------------------------------



#Maximo
#MaximoAnywhere
#AssetandFacilitiesManagement

It's sort of sequential but tied to a WO. For example, your status change, addition of labor, adding materials, etc. for a WO will all be enforced in a sequential manner. But other WOs can still send updates if the first WO fails. So it's slightly different than say the sequential queues in Maximo where one failure blocks all updates. Editability rules in Maximo are pretty complicated which is why it has to stay sequential. You might approve the WO before entering the labor transaction for example. So that order has to be persisted for accuracy. 

You can see the queue on newer versions, though can't do anything to manipulate it like you requested. Open the settings, go into advanced settings, go into logging, and then from the menu choose "View Transaction Log". This will show you the transaction data on the device that hasn't been synchronized to Maximo.

------------------------------
Steven Shull
Director of Development
Projetech Inc
Cincinnati OH
------------------------------

Let's all go back to a paper mind set for a moment to better understand the design characteristics of the Anywhere transaction process.  In the paper world if you had two people working the same job, you could very easily give them duplicate printouts. Those folks are now working offline and are setting status by writing down the time they started the workorder. After all transactions are recorded on the hard copy, the technicians then would dump the paper in a clerk's in-box and it would be processed at a later time.  Now, The clerk could process the paper in a dozen different ways, right? The clerk could process each paper independent of one another paying no mind as to which piece of paper belongs to which workorder or, the clerk could sort through them all first and group them by Wo , or by tech or whatever, right? The human processor sort all of the transactional stuff out much as the computer does today.  

So, the process of sorting transactions on any given workorder spread over multiple devices is a bit trickier.  Status transactions are marked as a high priority transaction, First in wins. When you and I set the workorder to INPRG (let's say by using the WOTIMER) then if my transaction gets in first I set the ACTUALSTART time. your transaction is error out nd sent back to you.  You then have to undo the changes on your device, get the status update and recreate/edit your transactions.  Since there is no human involved to only set the status change once, the processing of transactions is by its very nature sequential (as Steven notes).  Since Status changes cannot happen twice the second status change MUST be rejected and sent back to user with an error message.

Therefore when the conflict arises there must be a human involved to help sort out what has always been a human problem. Having multiple users work on the Same workorder there will always be an inherent conflict on the transaction message processing.  A human must look at the transactions and determine which is what and when to determine how to go forward.

------------------------------
Bradley K. Downing , MBA
IBM Certified Adv. Deployment Prof. Maximo v7.6.1
IBM
Bakersfield CA
------------------------------

Thanks for all your input

I understand its a difficult one with data conflicts

Interestingly - i saw this APAR of it not syncing labour before COMP status which tells me there may be a way to alter the sync order somewhere

https://www.ibm.com/support/pages/apar/IJ26018

------------------------------
Christopher Kung
------------------------------

Original Message:
Sent: Tue March 16, 2021 08:52 AM
From: Bradley Downing
Subject: Work Execution Data Conflicts

Let's all go back to a paper mind set for a moment to better understand the design characteristics of the Anywhere transaction process.  In the paper world if you had two people working the same job, you could very easily give them duplicate printouts. Those folks are now working offline and are setting status by writing down the time they started the workorder. After all transactions are recorded on the hard copy, the technicians then would dump the paper in a clerk's in-box and it would be processed at a later time.  Now, The clerk could process the paper in a dozen different ways, right? The clerk could process each paper independent of one another paying no mind as to which piece of paper belongs to which workorder or, the clerk could sort through them all first and group them by Wo , or by tech or whatever, right? The human processor sort all of the transactional stuff out much as the computer does today.  

So, the process of sorting transactions on any given workorder spread over multiple devices is a bit trickier.  Status transactions are marked as a high priority transaction, First in wins. When you and I set the workorder to INPRG (let's say by using the WOTIMER) then if my transaction gets in first I set the ACTUALSTART time. your transaction is error out nd sent back to you.  You then have to undo the changes on your device, get the status update and recreate/edit your transactions.  Since there is no human involved to only set the status change once, the processing of transactions is by its very nature sequential (as Steven notes).  Since Status changes cannot happen twice the second status change MUST be rejected and sent back to user with an error message.

Therefore when the conflict arises there must be a human involved to help sort out what has always been a human problem. Having multiple users work on the Same workorder there will always be an inherent conflict on the transaction message processing.  A human must look at the transactions and determine which is what and when to determine how to go forward.

------------------------------
Bradley K. Downing , MBA
IBM Certified Adv. Deployment Prof. Maximo v7.6.1
IBM
Bakersfield CA
------------------------------