Maximo Open Forum

 View Only

 Where do they keep the logic for status syncing from WO to SR?

Jump to Best Answer
  • End User
  • Everything Maximo
  • Work Management
Travis Herron's profile image
Travis Herron posted 04-01-2021 17:35
We're just starting to dabble in SR's.  I was on the Maximo preview site trying out some stuff, and I doubt the OOTB configuration is how we're going to want it.

I took an SR and used the Create Work Order action.  Then I hyperlinked to that Work Order and changed the status, then went back to the SR and refreshed it to see what happened.
--when WO went to INPRG, SR went to INPROG (and why didn't they use the same abbreviation?)
--then I changed the WO back to WAPPR, but the SR stayed INPROG.
--changed the WO to WSCH, SR stayed INPROG
--changed the WO to COMP, SR changed to RESOLVED.

We have lots of synonyms on WOSTATUS and I want to have better control over what status the user sees as the SR status, especially like in the example above where the WO was INPRG but I sent it backwards to WAPPR but the SR didn't change.

I'm assuming this is all in the Java coding, and the way to change it is to set SR.INHERITSTATUS to 0, and create an Escalation with lots of EscPoints and Actions to make it sync exactly how we want.  Is this correct or am I missing an easier way?
Steven Shull's profile image
Steven Shull Best Answer
We'd probably script it instead of using escalations but you're correct that you'll have to implement your own synchronization process. Simply when going to INPRG/COMP/CLOSE on WO they go and update the originator record status in the WO class. And it's only to INPROG/RESOLVED/CLOSED for tickets. In newer versions of Maximo (IE 7.6.1.2, potentially even an IFIX of 7.6.1.2) they added a new system property mxe.app.workorder.DoNotChangeTicketToINPROG which allows you to avoid the INPRG status change while still allowing the inherit for COMP/CLOSED. 

We might use this split differently than some, but for us it's typically two separate people working each record and we have situations where we have multiple WOs created against a single SR. We disable inheritstatus and let each team manage the status manually. The SR is the request from the client to do X, whatever that might be and is managed by our customer support team. If it's something we need to schedule (especially if it involves something we do in each of their environments) or requires other teams to do, the customer support team will create the necessary WOs and assign them out. The customer support team is always responsible for the customer request (providing updates, answering questions, etc.) and does that from the SR. The other teams execute the WO, documenting on the WO and informing the customer support team as they make progress. Then our customer support team communicates to the client the update and resolves the request when all outstanding requests are done. 

For both WOs and SRs, we don't let any user close work. We automatically close them once they're in a COMP/RESOLVED status after they haven't been modified in X days.