IBM Asset & Facilities Management Your destination for peer and expert insights to help unlock the power of data with AI and Asset & Facilities Management to advance your digital reinvention. Join / Log in
Hello everyone,We're facing an unusual issue. From time to time, we notice that the status in workorder do not match the last one in the table wostatus for the same workorder.The standard workorder workflow is : WAPPR > WAPPR1,2,3,4,5 > APPR > INPRG > COMP > CLOSEWe can also go to CAN from all of the previsous statuses (except COMP and CLOSE) or go back to WAPPR when in WAPPRx, APPR and INPRG.For instance, we have a workorder which went through the statuses: WAPPR > WAPPR1 > APPR > INPRG > COMP > CLOSEBut in wostatus, the last status recorded is COMP. No sign of CLOSE.In other time, you have a workorder.status = INPRG while the last wostatus.status = CLOSEor workorder.status = CAN while the last wostatus.status = INPRG.Please find attached another example.It seems like some changes in workorder.status/workorder.statusdate are not recorded in wostatus.status/wostatus.changedate and vice versa.This is happenning for any kind of worktype, woclass, child workorder, status, ...We're running on Maximo 184.108.40.206 with Transportation and we also custom the java code.Do you have any clue where this might come from or what we can check?Also if you need additional information, please let me know.Thanks for you time. Regards.
Or maybe somebody messed up relevant relationship? Maybe also check what is in DB.
Hello @Juris Flugins , Great. There is only a few custom relationships so I'll also check that and let you know. But for the DB, everything looks exactly the same as in the screen.
Hello Shannon, thanks for the feedback. Work orders are closed and cancelled using workflow buttons.I'll also check automation scripts, thanks.
Going to CLOSE via workflow is not very common, in my experience. Most places have an Escalation that CLOSEs work orders in COMP that don't have outstanding Purchase records and haven't had any financial transactions against them for 90 days.
Hello Ahmed.In general, if the status on the WO (or PO, or etc) is not shown in history, it is because WORKORDER.STATUS was set to that value instead of woMbo.changeStatus() being called to do that job. Scripts can call woMbo.setValue() on status. Integration can allow values for STATUS without requiring STATUSIFACE to be set. Workflow can use SETVALUE action on STATUS. This method for WOSTATUS getting out of sync with WORKORDER is the most common.However, in your screenshots, you point out WOSTATUS (also known as work order status history) suggesting a work order was close but the status being something else. I have never seen something write to WOSTATUS and forget to update WORKORDER, so I think what you are seeing is another instance of WORKORDER.STATUS being updated directly instead of by a call to changeStatus() (or invoking a CHANGESTATUS action from workflow / escalation or by setting STATUSIFACE during integration). I think the WO made it to CLOSE legitimately (e.g. via changeStatus()), but then was set to "INPRG" illegitimately.You said in response to other comments that you use workflow to change status. So, check for the places in workflow where status gets changed and make sure it gets changed by an Action of Type = Change Status and not Type = Set Value. And make sure status change is never attempted if :historyflag = 1. If you are trying status changes when historyflag is set, it means your work orders are going to CLOSE or CAN (i.e. history) too fast and need to stay in COMP for longer.
HI,Assuming there is no autoscript involved, Sometimes this occurs when a transaction on WO gets rolled back due to some interaction node properties in the workflow or due to some unexpected errors. Though the status changes got recorded in WOSTATUSCHANGE table correctly, the status didn't get reflected in the WO correctly. Please check for any interaction node(mostly the stay on the current app option) or check if there is any error.