Maximo List Archive

This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.

Work orders closed accidentally

From: ggutierrez (2012-06-06 14:54)

I actually had the same incident a few months ago where hundreds of work
orders were closed to early.
We use Maximo 6.2.1, Weblogic and SQL Manager 2005.
After a few weeks of banging my head against the wall.
I figured out how to update in SQL.

select wonum,description,location,status,historyflag from workorder
WHERE wonum = '119754 '

update workorder set Status = 'COMP' where wonum = '119754'
update workorder set historyflag = '1' where wonum = '119754'

I created a excel sheet that helped me put together the statements so I
didn't have to enter each line in sql.

Putting it back in the 'COMP' status let them proceed with PO's.

Hope that helps.

Thank You,

George Gutierrez Jr.
Maximo Administration
Pasadena Refining Systems
713.920.3908 Direct
832.473.5330 Cell
U1O2 - Chave

From: "jhale1996" <jhale1996@yahoo.com>
To: MAXIMO@yahoogroups.com
Date: 06/06/2012 02:30 PM
Subject: [MAXIMO List] Work orders closed accidentally
Sent by: MAXIMO@yahoogroups.com

Occasionally our users will "accidentally" close work orders that are not
ready to be closed. With Maximo 4 a few power users had access to go into
the database and change the status back to open. With our upgrade to 7.x we
removed their ability to reopen work orders. Recently a couple hundred work
orders were closed (yes we do control who can close) that still had
outstanding work left to complete. We do use the edit historical feature,
but this does not allow additional costs to be added. The other painful
option that we do was to duplicate the work order and create a follow up. I
am looking for suggestions on both improvements to reduce the number or
work orders that need to be reopened and ideas how to handle work orders
that are closed too early.
Appreciate the input.

From: Will Hampton (2012-06-06 20:02)

Even better yet would be a Workflow to "CLOSE" all records after a certain time or to check records before they actually close... Remove the ability of the user to close records and have them start Workflow to deal with closing them for the user. IE - User submits the record to Workflow to close - Workflow checks all the appropriate information and if everything is ready, then it closes the record. Otherwise it puts the record in a loop and checks it once a day (or so) until it's ready to close and then closes it. (you can also send reminders about things like receipts, etc... while it's in the Workflow loop so that it doesn't stay there forever :) )
R/
Will
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Will Hampton
Sent: Wednesday, June 06, 2012 2:59 PM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Work orders closed accidentally
Just like in version 4 you can still go in and change the status back to 'COMP' if desired.
There is an additional row entry in an Assets table (I don't remember the exact table name you will have to delete the row from) you will have to delete to allow it to be "CLOSE'd" again, otherwise you will receive a "unique index has been violated" error when trying to 'CLOSE'. As always I'd recommend you make a backup of production and restore to test/dev to test the scripting in before attempting in production.
R/
Will
From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of jhale1996
Sent: Wednesday, June 06, 2012 2:28 PM
To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
Subject: [MAXIMO List] Work orders closed accidentally
Occasionally our users will "accidentally" close work orders that are not ready to be closed. With Maximo 4 a few power users had access to go into the database and change the status back to open. With our upgrade to 7.x we removed their ability to reopen work orders. Recently a couple hundred work orders were closed (yes we do control who can close) that still had outstanding work left to complete. We do use the edit historical feature, but this does not allow additional costs to be added. The other painful option that we do was to duplicate the work order and create a follow up. I am looking for suggestions on both improvements to reduce the number or work orders that need to be reopened and ideas how to handle work orders that are closed too early.
Appreciate the input.

From: Chris Brandon (2012-06-06 13:26)

I have had this happen multiple time ... usually closing thousands of workorders. (Had it happen in POs too) I know who closed them and when so came up with the SQL below to put them back into whatever statsu they were in prior to this event.   v6.2.4    (Hope this is resolved in v7.5)

createtable #wostatus(trwonum
varchar(10),
                        trstatus varchar(16),
                        trchangedate datetime,
                        trpreviousstatus varchar(16),
                        trpreviousdatetime datetime)
CREATETABLE #workorder(wowonum
varchar(10),wostatus varchar(10),wohistoryflag bit)

insertinto #wostatus(trwonum,trstatus,trchangedate)
      SELECT wonum, status, changedate
            FROM         wostatus
            WHERE     (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
            AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
insertinto #workorder(wowonum, wostatus)
selecttrwonum, trstatus
     from#wostatus

update#wostatus
      set trpreviousstatus = (SELECT top 1 status FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
      AND wonum = #wostatus.trwonum
      order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)

updateworkorder
setstatus = #wostatus.trpreviousstatus, historyflag = 0
      FROM workorder inner join #wostatus on #wostatus.trwonum =workorder.wonum
        WHERE (trpreviousstatus is not NULL)
      --and #wostatus.trwonum = '361402'
select#wostatus.*, workorder.wonum, workorder.status, workorder.historyflag
      from #wostatus
            inner join workorder on
            workorder.wonum = #wostatus.trwonum
            oRDERBY trpreviousstatus
droptable #wostatus
droptable #workorder

You also must delete asset hierarchy records for each wonum, but I didn't have that one written into this code. I just deleted any record in there for a workorder that wasn't in a "CLOSE" status.delete from asset hierarchy where wonum = 'xxxxxxxx'

________________________________
From: jhale1996 <jhale1996@yahoo.com>
To: MAXIMO@yahoogroups.com
Sent: Wednesday, June 6, 2012 2:27 PM
Subject: [MAXIMO List] Work orders closed accidentally

Occasionally our users will "accidentally" close work orders that are not ready to be closed. With Maximo 4 a few power users had access to go into the database and change the status back to open. With our upgrade to 7.x we removed their ability to reopen work orders. Recently a couple hundred work orders were closed (yes we do control who can close) that still had outstanding work left to complete. We do use the edit historical feature, but this does not allow additional costs to be added. The other painful option that we do was to duplicate the work order and create a follow up. I am looking for suggestions on both improvements to reduce the number or work orders that need to be reopened and ideas how to handle work orders that are closed too early.
Appreciate the input.

From: Kevin Egolf (2012-06-06 17:07)

We have removed the rights for any user to close a work order. We are using an escalation to close work orders 60 days after a status of complete. The escalation verifies there are no open purchasing documents associated with the work order or any children or tasks.

Kevin

From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Chris Brandon
Sent: Wednesday, June 06, 2012 4:26 PM
To: MAXIMO@yahoogroups.com
Subject: Re: [MAXIMO List] Work orders closed accidentally

I have had this happen multiple time ... usually closing thousands of workorders. (Had it happen in POs too) I know who closed them and when so came up with the SQL below to put them back into whatever statsu they were in prior to this event. v6.2.4 (Hope this is resolved in v7.5)

createtable #wostatus(trwonum
varchar(10),
trstatus varchar(16),
trchangedate datetime,
trpreviousstatus varchar(16),
trpreviousdatetime datetime)
CREATETABLE #workorder(wowonum
varchar(10),wostatus varchar(10),wohistoryflag bit)

insertinto #wostatus(trwonum,trstatus,trchangedate)
SELECT wonum, status, changedate
FROM wostatus
WHERE (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
insertinto #workorder(wowonum, wostatus)
selecttrwonum, trstatus
from#wostatus

update#wostatus
set trpreviousstatus = (SELECT top 1 status FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
AND wonum = #wostatus.trwonum
order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)

updateworkorder
setstatus = #wostatus.trpreviousstatus, historyflag = 0
FROM workorder inner join #wostatus on #wostatus.trwonum =workorder.wonum
WHERE (trpreviousstatus is not NULL)
--and #wostatus.trwonum = '361402'
select#wostatus.*, workorder.wonum, workorder.status, workorder.historyflag
from #wostatus
inner join workorder on
workorder.wonum = #wostatus.trwonum
oRDERBY trpreviousstatus
droptable #wostatus
droptable #workorder

You also must delete asset hierarchy records for each wonum, but I didn't have that one written into this code. I just deleted any record in there for a workorder that wasn't in a "CLOSE" status.delete from asset hierarchy where wonum = 'xxxxxxxx'

________________________________
From: jhale1996 <jhale1996@yahoo.com <mailto:jhale1996%40yahoo.com> >
To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
Sent: Wednesday, June 6, 2012 2:27 PM
Subject: [MAXIMO List] Work orders closed accidentally

Occasionally our users will "accidentally" close work orders that are not ready to be closed. With Maximo 4 a few power users had access to go into the database and change the status back to open. With our upgrade to 7.x we removed their ability to reopen work orders. Recently a couple hundred work orders were closed (yes we do control who can close) that still had outstanding work left to complete. We do use the edit historical feature, but this does not allow additional costs to be added. The other painful option that we do was to duplicate the work order and create a follow up. I am looking for suggestions on both improvements to reduce the number or work orders that need to be reopened and ideas how to handle work orders that are closed too early.
Appreciate the input.

From: ron_bryant (2012-06-06 16:38)

This is how we do it as well. (v6 and v7.5)

Ron

From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of kegolf@techopsolutions.net
Sent: Wednesday, June 06, 2012 4:07 PM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Work orders closed accidentally

We have removed the rights for any user to close a work order. We are using an escalation to close work orders 60 days after a status of complete. The escalation verifies there are no open purchasing documents associated with the work order or any children or tasks.

Kevin

From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of Chris Brandon
Sent: Wednesday, June 06, 2012 4:26 PM
To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
Subject: Re: [MAXIMO List] Work orders closed accidentally

I have had this happen multiple time ... usually closing thousands of workorders. (Had it happen in POs too) I know who closed them and when so came up with the SQL below to put them back into whatever statsu they were in prior to this event. v6.2.4 (Hope this is resolved in v7.5)

createtable #wostatus(trwonum
varchar(10),
trstatus varchar(16),
trchangedate datetime,
trpreviousstatus varchar(16),
trpreviousdatetime datetime)
CREATETABLE #workorder(wowonum
varchar(10),wostatus varchar(10),wohistoryflag bit)

insertinto #wostatus(trwonum,trstatus,trchangedate)
SELECT wonum, status, changedate
FROM wostatus
WHERE (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
insertinto #workorder(wowonum, wostatus)
selecttrwonum, trstatus
from#wostatus

update#wostatus
set trpreviousstatus = (SELECT top 1 status FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
AND wonum = #wostatus.trwonum
order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)

updateworkorder
setstatus = #wostatus.trpreviousstatus, historyflag = 0
FROM workorder inner join #wostatus on #wostatus.trwonum =workorder.wonum
WHERE (trpreviousstatus is not NULL)
--and #wostatus.trwonum = '361402'
select#wostatus.*, workorder.wonum, workorder.status, workorder.historyflag
from #wostatus
inner join workorder on
workorder.wonum = #wostatus.trwonum
oRDERBY trpreviousstatus
droptable #wostatus
droptable #workorder

You also must delete asset hierarchy records for each wonum, but I didn't have that one written into this code. I just deleted any record in there for a workorder that wasn't in a "CLOSE" status.delete from asset hierarchy where wonum = 'xxxxxxxx'

________________________________
From: jhale1996 <jhale1996@yahoo.com<mailto:jhale1996%40yahoo.com> <mailto:jhale1996%40yahoo.com> >
To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
Sent: Wednesday, June 6, 2012 2:27 PM
Subject: [MAXIMO List] Work orders closed accidentally

Occasionally our users will "accidentally" close work orders that are not ready to be closed. With Maximo 4 a few power users had access to go into the database and change the status back to open. With our upgrade to 7.x we removed their ability to reopen work orders. Recently a couple hundred work orders were closed (yes we do control who can close) that still had outstanding work left to complete. We do use the edit historical feature, but this does not allow additional costs to be added. The other painful option that we do was to duplicate the work order and create a follow up. I am looking for suggestions on both improvements to reduce the number or work orders that need to be reopened and ideas how to handle work orders that are closed too early.
Appreciate the input.

From: in2data (2012-06-06 23:09)

Hi,
Same here. No one can close and we wait until 180 days after the complete to have the escalation close.
Dave Bone
--- In MAXIMO@yahoogroups.com, Kevin Egolf <kegolf@...> wrote:
>
> We have removed the rights for any user to close a work order. We are using an escalation to close work orders 60 days after a status of complete. The escalation verifies there are no open purchasing documents associated with the work order or any children or tasks.
>
>
>
> Kevin
>
>
>
>
>
> From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Chris Brandon
> Sent: Wednesday, June 06, 2012 4:26 PM
> To: MAXIMO@yahoogroups.com
> Subject: Re: [MAXIMO List] Work orders closed accidentally
>
>
>
>
>
>
>
> I have had this happen multiple time ... usually closing thousands of workorders. (Had it happen in POs too) I know who closed them and when so came up with the SQL below to put them back into whatever statsu they were in prior to this event. v6.2.4 (Hope this is resolved in v7.5)
>
> createtable #wostatus(trwonum
> varchar(10),
> trstatus varchar(16),
> trchangedate datetime,
> trpreviousstatus varchar(16),
> trpreviousdatetime datetime)
> CREATETABLE #workorder(wowonum
> varchar(10),wostatus varchar(10),wohistoryflag bit)
>
> insertinto #wostatus(trwonum,trstatus,trchangedate)
> SELECT wonum, status, changedate
> FROM wostatus
> WHERE (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
> AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
> insertinto #workorder(wowonum, wostatus)
> selecttrwonum, trstatus
> from#wostatus
>
> update#wostatus
> set trpreviousstatus = (SELECT top 1 status FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
> AND wonum = #wostatus.trwonum
> order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)
>
> updateworkorder
> setstatus = #wostatus.trpreviousstatus, historyflag = 0
> FROM workorder inner join #wostatus on #wostatus.trwonum =workorder.wonum
> WHERE (trpreviousstatus is not NULL)
> --and #wostatus.trwonum = '361402'
> select#wostatus.*, workorder.wonum, workorder.status, workorder.historyflag
> from #wostatus
> inner join workorder on
> workorder.wonum = #wostatus.trwonum
> oRDERBY trpreviousstatus
> droptable #wostatus
> droptable #workorder
>
>
> You also must delete asset hierarchy records for each wonum, but I didn't have that one written into this code. I just deleted any record in there for a workorder that wasn't in a "CLOSE" status.delete from asset hierarchy where wonum = 'xxxxxxxx'
>
>
>
> ________________________________
> From: jhale1996 <jhale1996@... <mailto:jhale1996%40yahoo.com> >
> To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> Sent: Wednesday, June 6, 2012 2:27 PM
> Subject: [MAXIMO List] Work orders closed accidentally
>
>
>
>
> Occasionally our users will "accidentally" close work orders that are not ready to be closed. With Maximo 4 a few power users had access to go into the database and change the status back to open. With our upgrade to 7.x we removed their ability to reopen work orders. Recently a couple hundred work orders were closed (yes we do control who can close) that still had outstanding work left to complete. We do use the edit historical feature, but this does not allow additional costs to be added. The other painful option that we do was to duplicate the work order and create a follow up. I am looking for suggestions on both improvements to reduce the number or work orders that need to be reopened and ideas how to handle work orders that are closed too early.
> Appreciate the input.
>
>
>
>
>
>
>
>
>

From: Jason Verly (2012-06-07 13:26)

Dave/Kevin,
I'm looking at doing the same ting and I've got a couple of people more worried about accidental charges than the benefits of automating the WO closure process. Looking for ideas to bring these last two users over before making the change. Have either of you done any conditional restrictions, or monitoting, on the WO to prevent accidental labor or material charges due to a fat finger during data entry?
--- In MAXIMO@yahoogroups.com, "in2data" <in2data@...> wrote:
>
> Hi,
>
> Same here. No one can close and we wait until 180 days after the complete to have the escalation close.
>
> Dave Bone
>
> --- In MAXIMO@yahoogroups.com, Kevin Egolf <kegolf@> wrote:
> >
> > We have removed the rights for any user to close a work order. We are using an escalation to close work orders 60 days after a status of complete. The escalation verifies there are no open purchasing documents associated with the work order or any children or tasks.
> >
> >
> >
> > Kevin
> >
> >
> >
> >
> >
> > From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Chris Brandon
> > Sent: Wednesday, June 06, 2012 4:26 PM
> > To: MAXIMO@yahoogroups.com
> > Subject: Re: [MAXIMO List] Work orders closed accidentally
> >
> >
> >
> >
> >
> >
> >
> > I have had this happen multiple time ... usually closing thousands of workorders. (Had it happen in POs too) I know who closed them and when so came up with the SQL below to put them back into whatever statsu they were in prior to this event. v6.2.4 (Hope this is resolved in v7.5)
> >
> > createtable #wostatus(trwonum
> > varchar(10),
> > trstatus varchar(16),
> > trchangedate datetime,
> > trpreviousstatus varchar(16),
> > trpreviousdatetime datetime)
> > CREATETABLE #workorder(wowonum
> > varchar(10),wostatus varchar(10),wohistoryflag bit)
> >
> > insertinto #wostatus(trwonum,trstatus,trchangedate)
> > SELECT wonum, status, changedate
> > FROM wostatus
> > WHERE (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
> > AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
> > insertinto #workorder(wowonum, wostatus)
> > selecttrwonum, trstatus
> > from#wostatus
> >
> > update#wostatus
> > set trpreviousstatus = (SELECT top 1 status FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
> > AND wonum = #wostatus.trwonum
> > order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)
> >
> > updateworkorder
> > setstatus = #wostatus.trpreviousstatus, historyflag = 0
> > FROM workorder inner join #wostatus on #wostatus.trwonum =workorder.wonum
> > WHERE (trpreviousstatus is not NULL)
> > --and #wostatus.trwonum = '361402'
> > select#wostatus.*, workorder.wonum, workorder.status, workorder.historyflag
> > from #wostatus
> > inner join workorder on
> > workorder.wonum = #wostatus.trwonum
> > oRDERBY trpreviousstatus
> > droptable #wostatus
> > droptable #workorder
> >
> >
> > You also must delete asset hierarchy records for each wonum, but I didn't have that one written into this code. I just deleted any record in there for a workorder that wasn't in a "CLOSE" status.delete from asset hierarchy where wonum = 'xxxxxxxx'
> >
> >
> >
> > ________________________________
> > From: jhale1996 <jhale1996@ <mailto:jhale1996%40yahoo.com> >
> > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> > Sent: Wednesday, June 6, 2012 2:27 PM
> > Subject: [MAXIMO List] Work orders closed accidentally
> >
> >
> >
> >
> > Occasionally our users will "accidentally" close work orders that are not ready to be closed. With Maximo 4 a few power users had access to go into the database and change the status back to open. With our upgrade to 7.x we removed their ability to reopen work orders. Recently a couple hundred work orders were closed (yes we do control who can close) that still had outstanding work left to complete. We do use the edit historical feature, but this does not allow additional costs to be added. The other painful option that we do was to duplicate the work order and create a follow up. I am looking for suggestions on both improvements to reduce the number or work orders that need to be reopened and ideas how to handle work orders that are closed too early.
> > Appreciate the input.
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

From: Kevin Egolf (2012-06-07 11:14)

Jason

I'm not sure exactly what you are looking for related to verifying charges.
We do have restrictions in place to prevent a user from entering labor more
than 5 days in advance to prevent fat fingered dates. Several of our sites
require the supervisors to review and approve labor entries rather than
using the automatic approval. I don't know what you would measure against to
validate material charges.

What process do they use now to validate the charges? Does someone review
the work orders before closing each one? If the work orders are being batch
closed there is probably no validation process in place. You could make
that part of the process prior to completion. Or you could have a synonym
status to indicate a work order has been validated and close based on that
status.

I expect you are getting resistance to automated closing because of a loss
of control rather than a real problem with incorrect charges

Kevin

From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
Jason Verly
Sent: Thursday, June 07, 2012 9:26 AM
To: MAXIMO@yahoogroups.com
Subject: Re: [MAXIMO List] Work orders closed accidentally

Dave/Kevin,
I'm looking at doing the same ting and I've got a couple of people more
worried about accidental charges than the benefits of automating the WO
closure process. Looking for ideas to bring these last two users over before
making the change. Have either of you done any conditional restrictions, or
monitoting, on the WO to prevent accidental labor or material charges due to
a fat finger during data entry?
--- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , "in2data"
<in2data@...> wrote:
>
> Hi,
>
> Same here. No one can close and we wait until 180 days after the complete
to have the escalation close.
>
> Dave Bone
>
> --- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , Kevin
Egolf <kegolf@> wrote:
> >
> > We have removed the rights for any user to close a work order. We are
using an escalation to close work orders 60 days after a status of complete.
The escalation verifies there are no open purchasing documents associated
with the work order or any children or tasks.
> >
> >
> >
> > Kevin
> >
> >
> >
> >
> >
> > From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
[mailto:MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> ] On Behalf
Of Chris Brandon
> > Sent: Wednesday, June 06, 2012 4:26 PM
> > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> > Subject: Re: [MAXIMO List] Work orders closed accidentally
> >
> >
> >
> >
> >
> >
> >
> > I have had this happen multiple time ... usually closing thousands of
workorders. (Had it happen in POs too) I know who closed them and when so
came up with the SQL below to put them back into whatever statsu they were
in prior to this event. v6.2.4 (Hope this is resolved in v7.5)
> >
> > createtable #wostatus(trwonum
> > varchar(10),
> > trstatus varchar(16),
> > trchangedate datetime,
> > trpreviousstatus varchar(16),
> > trpreviousdatetime datetime)
> > CREATETABLE #workorder(wowonum
> > varchar(10),wostatus varchar(10),wohistoryflag bit)
> >
> > insertinto #wostatus(trwonum,trstatus,trchangedate)
> > SELECT wonum, status, changedate
> > FROM wostatus
> > WHERE (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
> > AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
> > insertinto #workorder(wowonum, wostatus)
> > selecttrwonum, trstatus
> > from#wostatus
> >
> > update#wostatus
> > set trpreviousstatus = (SELECT top 1 status FROMwostatus
WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
> > AND wonum = #wostatus.trwonum
> > order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate
FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17
13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)
> >
> > updateworkorder
> > setstatus = #wostatus.trpreviousstatus, historyflag = 0
> > FROM workorder inner join #wostatus on #wostatus.trwonum
=workorder.wonum
> > WHERE (trpreviousstatus is not NULL)
> > --and #wostatus.trwonum = '361402'
> > select#wostatus.*, workorder.wonum, workorder.status,
workorder.historyflag
> > from #wostatus
> > inner join workorder on
> > workorder.wonum = #wostatus.trwonum
> > oRDERBY trpreviousstatus
> > droptable #wostatus
> > droptable #workorder
> >
> >
> > You also must delete asset hierarchy records for each wonum, but I
didn't have that one written into this code. I just deleted any record in
there for a workorder that wasn't in a "CLOSE" status.delete from asset
hierarchy where wonum = 'xxxxxxxx'
> >
> >
> >
> > ________________________________
> > From: jhale1996 <jhale1996@ <mailto:jhale1996%40yahoo.com> >
> > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com>
> > Sent: Wednesday, June 6, 2012 2:27 PM
> > Subject: [MAXIMO List] Work orders closed accidentally
> >
> >
> >
> >
> > Occasionally our users will "accidentally" close work orders that are
not ready to be closed. With Maximo 4 a few power users had access to go
into the database and change the status back to open. With our upgrade to
7.x we removed their ability to reopen work orders. Recently a couple
hundred work orders were closed (yes we do control who can close) that still
had outstanding work left to complete. We do use the edit historical
feature, but this does not allow additional costs to be added. The other
painful option that we do was to duplicate the work order and create a
follow up. I am looking for suggestions on both improvements to reduce the
number or work orders that need to be reopened and ideas how to handle work
orders that are closed too early.
> > Appreciate the input.
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

From: Jason Verly (2012-06-07 16:19)

I'm sure part of the reluctance is a control issue, so I'm trying to address what's been publicly stated and their true intent... which is always tricky. ;-)
My thought was to use an escalation/notification to notify planners when a material or labor charge were made against a WO that has been in COMP for more than xx days. The two users that have been vocal have asked for some security to restrict the possible fat fingering. I challenged them to tell me how to differentiate between a fat fingered entry and one of a trailing cost that comes in 10d, 20d, etc after setting WO to COMP status that should be charged to the WO.
The other choice is to keep the window a WO in COMP status stays open to be ~7d and then only keep it open in the event the WO, or WO task, is on an active PO.
Switching from automatic labor charge approval to reviewed approval is another step.

--- In MAXIMO@yahoogroups.com, Kevin Egolf <kegolf@...> wrote:
>
> Jason
>
>
>
> I'm not sure exactly what you are looking for related to verifying charges.
> We do have restrictions in place to prevent a user from entering labor more
> than 5 days in advance to prevent fat fingered dates. Several of our sites
> require the supervisors to review and approve labor entries rather than
> using the automatic approval. I don't know what you would measure against to
> validate material charges.
>
>
>
> What process do they use now to validate the charges? Does someone review
> the work orders before closing each one? If the work orders are being batch
> closed there is probably no validation process in place. You could make
> that part of the process prior to completion. Or you could have a synonym
> status to indicate a work order has been validated and close based on that
> status.
>
>
>
> I expect you are getting resistance to automated closing because of a loss
> of control rather than a real problem with incorrect charges
>
>
>
> Kevin
>
>
>
>
>
> From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
> Jason Verly
> Sent: Thursday, June 07, 2012 9:26 AM
> To: MAXIMO@yahoogroups.com
> Subject: Re: [MAXIMO List] Work orders closed accidentally
>
>
>
>
>
> Dave/Kevin,
>
> I'm looking at doing the same ting and I've got a couple of people more
> worried about accidental charges than the benefits of automating the WO
> closure process. Looking for ideas to bring these last two users over before
> making the change. Have either of you done any conditional restrictions, or
> monitoting, on the WO to prevent accidental labor or material charges due to
> a fat finger during data entry?
>
> --- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , "in2data"
> <in2data@> wrote:
> >
> > Hi,
> >
> > Same here. No one can close and we wait until 180 days after the complete
> to have the escalation close.
> >
> > Dave Bone
> >
> > --- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , Kevin
> Egolf <kegolf@> wrote:
> > >
> > > We have removed the rights for any user to close a work order. We are
> using an escalation to close work orders 60 days after a status of complete.
> The escalation verifies there are no open purchasing documents associated
> with the work order or any children or tasks.
> > >
> > >
> > >
> > > Kevin
> > >
> > >
> > >
> > >
> > >
> > > From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> [mailto:MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> ] On Behalf
> Of Chris Brandon
> > > Sent: Wednesday, June 06, 2012 4:26 PM
> > > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> > > Subject: Re: [MAXIMO List] Work orders closed accidentally
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I have had this happen multiple time ... usually closing thousands of
> workorders. (Had it happen in POs too) I know who closed them and when so
> came up with the SQL below to put them back into whatever statsu they were
> in prior to this event. v6.2.4 (Hope this is resolved in v7.5)
> > >
> > > createtable #wostatus(trwonum
> > > varchar(10),
> > > trstatus varchar(16),
> > > trchangedate datetime,
> > > trpreviousstatus varchar(16),
> > > trpreviousdatetime datetime)
> > > CREATETABLE #workorder(wowonum
> > > varchar(10),wostatus varchar(10),wohistoryflag bit)
> > >
> > > insertinto #wostatus(trwonum,trstatus,trchangedate)
> > > SELECT wonum, status, changedate
> > > FROM wostatus
> > > WHERE (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
> > > AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
> > > insertinto #workorder(wowonum, wostatus)
> > > selecttrwonum, trstatus
> > > from#wostatus
> > >
> > > update#wostatus
> > > set trpreviousstatus = (SELECT top 1 status FROMwostatus
> WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
> > > AND wonum = #wostatus.trwonum
> > > order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate
> FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17
> 13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)
> > >
> > > updateworkorder
> > > setstatus = #wostatus.trpreviousstatus, historyflag = 0
> > > FROM workorder inner join #wostatus on #wostatus.trwonum
> =workorder.wonum
> > > WHERE (trpreviousstatus is not NULL)
> > > --and #wostatus.trwonum = '361402'
> > > select#wostatus.*, workorder.wonum, workorder.status,
> workorder.historyflag
> > > from #wostatus
> > > inner join workorder on
> > > workorder.wonum = #wostatus.trwonum
> > > oRDERBY trpreviousstatus
> > > droptable #wostatus
> > > droptable #workorder
> > >
> > >
> > > You also must delete asset hierarchy records for each wonum, but I
> didn't have that one written into this code. I just deleted any record in
> there for a workorder that wasn't in a "CLOSE" status.delete from asset
> hierarchy where wonum = 'xxxxxxxx'
> > >
> > >
> > >
> > > ________________________________
> > > From: jhale1996 <jhale1996@ <mailto:jhale1996%40yahoo.com> >
> > > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> <mailto:MAXIMO%40yahoogroups.com>
> > > Sent: Wednesday, June 6, 2012 2:27 PM
> > > Subject: [MAXIMO List] Work orders closed accidentally
> > >
> > >
> > >
> > >
> > > Occasionally our users will "accidentally" close work orders that are
> not ready to be closed. With Maximo 4 a few power users had access to go
> into the database and change the status back to open. With our upgrade to
> 7.x we removed their ability to reopen work orders. Recently a couple
> hundred work orders were closed (yes we do control who can close) that still
> had outstanding work left to complete. We do use the edit historical
> feature, but this does not allow additional costs to be added. The other
> painful option that we do was to duplicate the work order and create a
> follow up. I am looking for suggestions on both improvements to reduce the
> number or work orders that need to be reopened and ideas how to handle work
> orders that are closed too early.
> > > Appreciate the input.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
>
>

From: Thomas (2012-06-07 20:38)

We are also on an automated close process. Every Friday evening the work orders in a completed status are closed if they have been completed for 7 days. Every Sunday evening a custom exception report runs and emails all the Planners. It is there waiting for them on Monday morning and they have until Friday evening to make adjustments.
It's not perfect but it is much easier than dealing with a bunch of work orders closed accidently.
--- In MAXIMO@yahoogroups.com, "Bill" <bill.e.murphy@...> wrote:
>
> We do it the same way as Dave does, waiting 180 days before an escalation moves them to CLOSE. In addition, we use workflows for each status change to control the choices they have for each status change step. We also prevent users from moving Standing Work Orders (SWOs) to COMP because those were being accidentally completed too early.
>
> Bill Murphy
> v7.1.1.6 / Life Sciences v7.1
>
> --- In MAXIMO@yahoogroups.com, "jhale1996" <jhale1996@> wrote:
> >
> > Occasionally our users will "accidentally" close work orders that are not ready to be closed. With Maximo 4 a few power users had access to go into the database and change the status back to open. With our upgrade to 7.x we removed their ability to reopen work orders. Recently a couple hundred work orders were closed (yes we do control who can close) that still had outstanding work left to complete. We do use the edit historical feature, but this does not allow additional costs to be added. The other painful option that we do was to duplicate the work order and create a follow up. I am looking for suggestions on both improvements to reduce the number or work orders that need to be reopened and ideas how to handle work orders that are closed too early.
> > Appreciate the input.
> >
>

From: max.joercne (2012-06-10 12:54)

Here is the SQL I use. there are many changes you need to do to have maximo work if you need to change the status of a workorder.
---------
--update changes in each update script to include.
--insert the siteid wonum needing change
--insert the wonum's
--insert the old status
--insert the new status
--insert the hystoryflag 1 or 0
--insert the default values as needed
-- if wo was closed look in assethistory object and remove entry
Declare
v1 char(20);
cursor c1wo is
select     wonum,
    PARENT,
    status,
    GLACCOUNT,
        ORGID,
        SITEID
   from workorder
   where
           status not in('WAPPR')
        and wonum in
(select wonum from workorder where parent in
('U255302920'
)
)
;
begin
v1:=1;
for rec in c1wo
loop
Insert into WOSTATUS
    (
    WONUM,
    STATUS,
    CHANGEDATE,
    CHANGEBY,
    MEMO,
    GLACCOUNT,
    ORGID,
    SITEID,
    WOSTATUSID,
    PARENT
    )
Values
       (
   rec.wonum,
    'WAPPR',
    sysdate,
    'MAXIMO',
    'Changed as per INC305899',
     rec.GLACCOUNT,
    rec.ORGID,
    rec.SITEID,
    WOSTATUSSEQ.NEXTVAL,
    rec.PARENT
    )
    ;
v1:=(v1+1);
if v1 = 1000 then
commit;
v1:=0;
end if;
end loop ;
commit ;
end;

Declare
v1 char(20);
cursor c2wo is
select     wonum,
    PARENT,
    status,
    GLACCOUNT,
        ORGID,
        SITEID
   from workorder
   where
           status not in('WAPPR')
        and wonum in
('U255302920');
begin
v1:=1;
for rec in c2wo
loop
Insert into WOSTATUS
       (
    WONUM,
    STATUS,
    CHANGEDATE,
    CHANGEBY,
    MEMO,
    GLACCOUNT,
    ORGID,
    SITEID,
    WOSTATUSID,
    PARENT)
Values
       (
   rec.wonum,
    'WAPPR',
    sysdate,
    'MAXIMO',
    'Changed as per INC305899',
     rec.GLACCOUNT,
    rec.ORGID,
    rec.SITEID,
    WOSTATUSSEQ.NEXTVAL,
    rec.PARENT
    )
    ;
v1:=(v1+1);
if v1 = 1000 then
commit;
v1:=0;
end if;
end loop ;
commit ;
end;

Declare
v1 char(20);
cursor c3wo is
select * from workorder where status not in ('WAPPR') and wonum in
('U255302920') ;
begin
v1:=1;
for rec in c3wo
loop
update workorder set
    status='WAPPR',
    historyflag = 0
where wonum=rec.wonum
;
v1:=(v1+1);
if v1 = 1000 then
commit;
v1:=0;
end if;
end loop ;
commit ;
end;
Declare
v1 char(20);
cursor c4wo is
select * from workorder where status not in ('WAPPR') and parent in
('U255302920') ;
begin
v1:=1;
for rec in c4wo
loop
update workorder set
    status='WAPPR',
    historyflag = 0
where wonum=rec.wonum
;
v1:=(v1+1);
if v1 = 1000 then
commit;
v1:=0;
end if;
end loop ;
commit ;
end;
Declare
v1 char(20);
cursor c5wo is
select * from workview where recordkey in
(
select wonum from workorder where
status not in ('WAPPR') and parent in
('U255302920')
)
;
begin
v1:=1;
for rec in c5wo
loop
update workview set
status='WAPPR',
historyflag = 0
where recordkey=rec.recordkey
;
v1:=(v1+1);
if v1 = 1000 then
commit;
v1:=0;
end if;
end loop ;
commit ;
end;
Declare
v1 char(20);
cursor c6wo is
select * from workview where status not in ('WAPPR') and recordkey in

('U255302920');
begin
v1:=1;
for rec in c6wo
loop
update workview set
    status='WAPPR',
    historyflag = 0
where recordkey=rec.recordkey
----- Original Message -----
From: ggutierrez@pasadenarefining.com
To: MAXIMO@yahoogroups.com
Sent: Wednesday, June 6, 2012 3:54:49 PM
Subject: Re: [MAXIMO List] Work orders closed accidentally

I actually had the same incident a few months ago where hundreds of work
orders were closed to early.
We use Maximo 6.2.1, Weblogic and SQL Manager 2005.
After a few weeks of banging my head against the wall.
I figured out how to update in SQL.
select wonum,description,location,status,historyflag from workorder
WHERE wonum = '119754 '
update workorder set Status = 'COMP' where wonum = '119754'
update workorder set historyflag = '1' where wonum = '119754'
I created a excel sheet that helped me put together the statements so I
didn't have to enter each line in sql.
Putting it back in the 'COMP' status let them proceed with PO's.
Hope that helps.
Thank You,
George Gutierrez Jr.
Maximo Administration
Pasadena Refining Systems
713.920.3908 Direct
832.473.5330 Cell
U1O2 - Chave
From: "jhale1996" < jhale1996@yahoo.com >
To: MAXIMO@yahoogroups.com
Date: 06/06/2012 02:30 PM
Subject: [MAXIMO List] Work orders closed accidentally
Sent by: MAXIMO@yahoogroups.com
Occasionally our users will "accidentally" close work orders that are not
ready to be closed. With Maximo 4 a few power users had access to go into
the database and change the status back to open. With our upgrade to 7.x we
removed their ability to reopen work orders. Recently a couple hundred work
orders were closed (yes we do control who can close) that still had
outstanding work left to complete. We do use the edit historical feature,
but this does not allow additional costs to be added. The other painful
option that we do was to duplicate the work order and create a follow up. I
am looking for suggestions on both improvements to reduce the number or
work orders that need to be reopened and ideas how to handle work orders
that are closed too early.
Appreciate the input.

From: in2data (2012-06-11 16:24)

Hi,
By fat finger I take it youmean charging labor to the wrong work order?
We still have the maintenance planner review all completed work orders for errors. They also check to make certain that a work order where the description and long description indicate that labor and parts were used actually have those issued.
Your users would still have "control" over that. The only actual change is that they cannot change a work order to close.
If you really are forced to do so you could set them up in a security group that has access to the close status.
Dave Bone
--- In MAXIMO@yahoogroups.com, "Jason Verly" <jason.verly@...> wrote:
>
>
> I'm sure part of the reluctance is a control issue, so I'm trying to address what's been publicly stated and their true intent... which is always tricky. ;-)
>
> My thought was to use an escalation/notification to notify planners when a material or labor charge were made against a WO that has been in COMP for more than xx days. The two users that have been vocal have asked for some security to restrict the possible fat fingering. I challenged them to tell me how to differentiate between a fat fingered entry and one of a trailing cost that comes in 10d, 20d, etc after setting WO to COMP status that should be charged to the WO.
>
> The other choice is to keep the window a WO in COMP status stays open to be ~7d and then only keep it open in the event the WO, or WO task, is on an active PO.
>
> Switching from automatic labor charge approval to reviewed approval is another step.
>
>
> --- In MAXIMO@yahoogroups.com, Kevin Egolf <kegolf@> wrote:
> >
> > Jason
> >
> >
> >
> > I'm not sure exactly what you are looking for related to verifying charges.
> > We do have restrictions in place to prevent a user from entering labor more
> > than 5 days in advance to prevent fat fingered dates. Several of our sites
> > require the supervisors to review and approve labor entries rather than
> > using the automatic approval. I don't know what you would measure against to
> > validate material charges.
> >
> >
> >
> > What process do they use now to validate the charges? Does someone review
> > the work orders before closing each one? If the work orders are being batch
> > closed there is probably no validation process in place. You could make
> > that part of the process prior to completion. Or you could have a synonym
> > status to indicate a work order has been validated and close based on that
> > status.
> >
> >
> >
> > I expect you are getting resistance to automated closing because of a loss
> > of control rather than a real problem with incorrect charges
> >
> >
> >
> > Kevin
> >
> >
> >
> >
> >
> > From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
> > Jason Verly
> > Sent: Thursday, June 07, 2012 9:26 AM
> > To: MAXIMO@yahoogroups.com
> > Subject: Re: [MAXIMO List] Work orders closed accidentally
> >
> >
> >
> >
> >
> > Dave/Kevin,
> >
> > I'm looking at doing the same ting and I've got a couple of people more
> > worried about accidental charges than the benefits of automating the WO
> > closure process. Looking for ideas to bring these last two users over before
> > making the change. Have either of you done any conditional restrictions, or
> > monitoting, on the WO to prevent accidental labor or material charges due to
> > a fat finger during data entry?
> >
> > --- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , "in2data"
> > <in2data@> wrote:
> > >
> > > Hi,
> > >
> > > Same here. No one can close and we wait until 180 days after the complete
> > to have the escalation close.
> > >
> > > Dave Bone
> > >
> > > --- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , Kevin
> > Egolf <kegolf@> wrote:
> > > >
> > > > We have removed the rights for any user to close a work order. We are
> > using an escalation to close work orders 60 days after a status of complete.
> > The escalation verifies there are no open purchasing documents associated
> > with the work order or any children or tasks.
> > > >
> > > >
> > > >
> > > > Kevin
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> > [mailto:MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> ] On Behalf
> > Of Chris Brandon
> > > > Sent: Wednesday, June 06, 2012 4:26 PM
> > > > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> > > > Subject: Re: [MAXIMO List] Work orders closed accidentally
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I have had this happen multiple time ... usually closing thousands of
> > workorders. (Had it happen in POs too) I know who closed them and when so
> > came up with the SQL below to put them back into whatever statsu they were
> > in prior to this event. v6.2.4 (Hope this is resolved in v7.5)
> > > >
> > > > createtable #wostatus(trwonum
> > > > varchar(10),
> > > > trstatus varchar(16),
> > > > trchangedate datetime,
> > > > trpreviousstatus varchar(16),
> > > > trpreviousdatetime datetime)
> > > > CREATETABLE #workorder(wowonum
> > > > varchar(10),wostatus varchar(10),wohistoryflag bit)
> > > >
> > > > insertinto #wostatus(trwonum,trstatus,trchangedate)
> > > > SELECT wonum, status, changedate
> > > > FROM wostatus
> > > > WHERE (changedate > CONVERT(DATETIME, '2012-02-17 13:49:46', 102))
> > > > AND (changeby = 'XXXXXXX') AND (status = 'CLOSE')
> > > > insertinto #workorder(wowonum, wostatus)
> > > > selecttrwonum, trstatus
> > > > from#wostatus
> > > >
> > > > update#wostatus
> > > > set trpreviousstatus = (SELECT top 1 status FROMwostatus
> > WHERE(changedate < CONVERT(DATETIME, '2012-02-17 13:30:00',102))
> > > > AND wonum = #wostatus.trwonum
> > > > order by changedate desc),trpreviousdatetime =(SELECTtop1 changedate
> > FROMwostatus WHERE(changedate < CONVERT(DATETIME, '2012-02-17
> > 13:30:00',102)) AND wonum = #wostatus.trwonum order by changedate desc)
> > > >
> > > > updateworkorder
> > > > setstatus = #wostatus.trpreviousstatus, historyflag = 0
> > > > FROM workorder inner join #wostatus on #wostatus.trwonum
> > =workorder.wonum
> > > > WHERE (trpreviousstatus is not NULL)
> > > > --and #wostatus.trwonum = '361402'
> > > > select#wostatus.*, workorder.wonum, workorder.status,
> > workorder.historyflag
> > > > from #wostatus
> > > > inner join workorder on
> > > > workorder.wonum = #wostatus.trwonum
> > > > oRDERBY trpreviousstatus
> > > > droptable #wostatus
> > > > droptable #workorder
> > > >
> > > >
> > > > You also must delete asset hierarchy records for each wonum, but I
> > didn't have that one written into this code. I just deleted any record in
> > there for a workorder that wasn't in a "CLOSE" status.delete from asset
> > hierarchy where wonum = 'xxxxxxxx'
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: jhale1996 <jhale1996@ <mailto:jhale1996%40yahoo.com> >
> > > > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> > <mailto:MAXIMO%40yahoogroups.com>
> > > > Sent: Wednesday, June 6, 2012 2:27 PM
> > > > Subject: [MAXIMO List] Work orders closed accidentally
> > > >
> > > >
> > > >
> > > >
> > > > Occasionally our users will "accidentally" close work orders that are
> > not ready to be closed. With Maximo 4 a few power users had access to go
> > into the database and change the status back to open. With our upgrade to
> > 7.x we removed their ability to reopen work orders. Recently a couple
> > hundred work orders were closed (yes we do control who can close) that still
> > had outstanding work left to complete. We do use the edit historical
> > feature, but this does not allow additional costs to be added. The other
> > painful option that we do was to duplicate the work order and create a
> > follow up. I am looking for suggestions on both improvements to reduce the
> > number or work orders that need to be reopened and ideas how to handle work
> > orders that are closed too early.
> > > > Appreciate the input.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
>