The process proposed doesn't work. This is because the person is already assigned. When you create the new labor and try to assign to the person, the system will say that the person has already been assigned in that ORG.
This is what must be done to correct the issue:
- Create a new person ID
- Find the existing Labor that has the issue
- Assign the new person ID
- ---------------- Do these after reversing the transactions (see comment if you need to wait else do it now) ------
- Find the old laborcode in the Laborcode application
- Make the old labor INACTIVE, this is important
- Find the new person in the People application
- Make the new person INACTIVE, this is important
That solves the current issue. Now, what about the past?
A question is do you need to "correct" the past and also we don't know if you are connected to a finance system. The expense has already been claimed, so do you really need to correct it? Using the above solution, you do lose the connection between the labor/person, not much can be done about that.
We also don't know the status of the work orders either as it's not always good to do a history edit of closed work orders with the main reason being that although you can backdate (if you remember to do this) that transaction date, it will most likely be changed to a different financial period. Let's ignore that and acknowledge that you want to correct everything through the front-end.
In Bradley's solution, you need to enter a reversing transaction to zero out the costs NB: The laborcode must be active to do this. Also on closed work orders, you will need to use the history edit function to add the reversing transaction. Then add the correcting transaction using the correct laborcode. Only after completing ALL the reversal, you can then inactivate the Labor and Person. This is the preferred solution from the front end.
If you are not worried and not connected to a financial system, then you could simply update the LABTRANS.LABORCODE with the correct laborcode using your preferred SQL tool. As advised by Bradley, this is not traceable...at least not normally, and you must know what you are doing.
Good luck and let us know what you did.
Regards, Craig
------------------------------
===============================
Craig Kokay,
Lead Senior Maximo/IoT Consultant
ISW
Sydney, NSW, Australia
Ph: 0411-682-040
=================================
#IBMChampion2021
------------------------------
Original Message:
Sent: Mon January 17, 2022 10:43 AM
From: Bradley Downing
Subject: Wrong LaborCode attached to PersonID
Hi Chelsea,
From the front end you and not able to "fix" this situation. Transactions are historical. so they live in the system. You could entertain the idea of creating a new labor record and assigning the person id to that if you wanted to do it this way. Then you could create reversal transactions against the old Labor record to zero out the costs. Afterward you can create new transactions to replace the old ones. This is the acceptable way of doing it through the front end. There are magical/ wizardy kinds of things that can (but should not) be done through the back-end with an SQL tool-of-choice. Two reasons for not doing it from back-end in the DB 1) you can REALLY screw up your database and wreck your MBOs by doing this unless you have years of practice; 2) you increase you audit risk; it is not usually a good practice to go in an change actual cost transactions, (some people might think fraud?)
I will say this; I created a report once (perhaps 2005 or so...) in Actuate for a client who insisted on changing transaction (labtrans, matusetrans, matrectrans, tooltrans and servrectrans) and with that report we created a hardcopy (i.e. PDF output) of what the prior transaction was and the modified transaction was. Kinda slick solution but a lot of work. The client regularly modified GL accounts for accounting purposes so this was an "approved" method of moving costs around the organization.
In your situation It occurs to me that you have a small "one-off" and you need to correct it. I would create a new labor record with the correct PERSONID value on the LABORCODE attribute and then go through the reversal and recreation process (long and laborious) but it will pass muster at audit time.
------------------------------
Bradley K. Downing , MBA
Solutions Engineer
IBM
Bakersfield CA
Original Message:
Sent: Fri January 14, 2022 07:37 AM
From: Chelsea McCabe
Subject: Wrong LaborCode attached to PersonID
Hi,
I have a user who's labor code was created as his craft code (30022226) and not his personid (WOFFK002) which is our company standard. He has 319 existing labor transactions with the 30022226 laborcode so it will not allow me to change it to his personid. How do I fix this? Thank you for any help that can be provided.
Maximo Inquiries, please submit a Service Request in Maximo: Click Here
"How-To" Submit a SR Document: How To Create SR in Maximo