APAR status
Closed as program error.
Error description
The following issue was tested against Maximo 7.1.1.5 with IBM Maximo for Utilities 7.1.0.0 Build 20081212-0732 DB Build V7110-172 and Transportation 7.1.0.0-20091118-0739 Build 20081211-1448 DB Build V7110-504. With Utilities 7.1.0.0 and hot fix build 003 installed the Requestnum is being updated when the Work Order Status is changed from APPR to INPRG. This issue happens from both the core Work Order tracking application and the Utilities Work Order tracking appliction. Here are steps to reproduce the issue from either one of the two applications, The core 1. Go to the work order tracking application and create a new work order, add an asset and save the work order. 2. Now on the plans tab add a stocked item and approve the work order. Run this query Select REQUESTNUM from WPMATERIAL where WONUM = 'ENTER WORK ORDER NUMBER' Note what the request number is. 3. Now changed the status of the Work Order to INPRG from APPR, now run the above query again. You now see that the REQUESTNUM has updated when it should not have. Tested this on an out of the box install of 7.1.1.5 with just core applications and this worked as needed. Seems to be only broken with T&D (Utilities) installed on it.
Local fix
n/a
Problem summary
**************************************************************** * USERS AFFECTED: All Transportation Clients * **************************************************************** * PROBLEM DESCRIPTION: WPMATERIAL REQUESTNUM IS CHANGING * * DURING STATUS CHANGE OF WORK ORDER * * FROM APPR TO INPRG. * * * **************************************************************** * RECOMMENDATION: * * * * * * * **************************************************************** WPMATERIAL REQUESTNUM IS CHANGING DURING STATUS CHANGE OF WORK ORDER FROM APPR TO INPRG.
Problem conclusion
When changing the status to INPRG, ActStart is modified and it's action method is called. This method resets all the warranty situations. The warranty process is always called in the save method of the app bean and before the change of the status. The old piece of code was intended to call again the warranty validation after the change of status but it caused an extra call of setValue in WPMATERIAL. Because of that, a new generation of REQUESTNUM field was done - the reason of the APAR. The fix for this APAR is contained in the following maintenance package: | release\fix pack | FIREBIRD_P2
Temporary fix
Comments
APAR Information
APAR number
IZ74630
Reported component name
MAXIMO UTILITIE
Reported component ID
5724R5600
Reported release
711
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2010-04-14
Closed date
2010-05-27
Last modified date
2010-05-27
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
MAXIMO
Fix information
Fixed component name
MAXIMO UTILITIE
Fixed component ID
5724R5600
Applicable component levels
R711 PSY
UP
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSLLAM","label":"Maximo for Utilities"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"711","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]
Document Information
Modified date:
29 September 2021