Maximo Open Forum

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!

Hi Raziela,

Did you try using 'MboConstants' to skip the validations? like below?

mbo.setValue("QUANTITY",<value>,MboConstants.NOVALIDATION_AND_NOACTION)

Thanks!

Sankar

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!

Hi Raziela

------ Initial thoughts ------------------------------------------------------

My instinct is to use the inventory system as it has been designed:

1. Create a work order
2. Add some WPMATERIALS using items
3. Approve the work order.  This generates the reservation to the storeroom.
   1. Reorder is run
   2. New items are purchased to restock, if needed
4. Issue the items using the procedure you use to issue items:
   1. Actual materials on the work order
   2. Inventory Usage
   3. Issues and Transfers
   4. Inventory
5. Complete the work order

---- Thoughts based on the article ---------------------------------------------------------

My instinct is to use SASIA in the reverse. i.e. have the user insert the requested qty into the SASIA and copy that into the QTY field in the WPMATERIAL.  Hide the QTY field in WPMATERIAL, so the user doesn't know about the other or maybe mask it.

Why?  This still allows the reservation to occur.  The warehouse can adjust the reserved QTY.  This maintains the reordering system to work.

We are missing a bit of info:

• At what status does the work order reach the warehouse?
• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder.

Having the warehouse do any confirmation...before actually generating the demand (reservation) is putting extra work on the warehouse that they really don't need.

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!

Hello Craig,

Thanks for your point of view. I haven't thought of using SASIA in the reverse, and I will try going with this approach. I will give feedback on how it goes.

Also to answer your questions:

• At what status does the work order reach the warehouse? 

Approved.

• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder. 

I understand your side, but this has been an important request from our client. They persisted on involving the warehouse user on that step, that's why we're adjusting with their procedures.

Thanks

Hi Raziela

------ Initial thoughts ------------------------------------------------------

My instinct is to use the inventory system as it has been designed:

1. Create a work order
2. Add some WPMATERIALS using items
3. Approve the work order.  This generates the reservation to the storeroom.
   1. Reorder is run
   2. New items are purchased to restock, if needed
4. Issue the items using the procedure you use to issue items:
   1. Actual materials on the work order
   2. Inventory Usage
   3. Issues and Transfers
   4. Inventory
5. Complete the work order

---- Thoughts based on the article ---------------------------------------------------------

My instinct is to use SASIA in the reverse. i.e. have the user insert the requested qty into the SASIA and copy that into the QTY field in the WPMATERIAL.  Hide the QTY field in WPMATERIAL, so the user doesn't know about the other or maybe mask it.

Why?  This still allows the reservation to occur.  The warehouse can adjust the reserved QTY.  This maintains the reordering system to work.

We are missing a bit of info:

• At what status does the work order reach the warehouse?
• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder.

Having the warehouse do any confirmation...before actually generating the demand (reservation) is putting extra work on the warehouse that they really don't need.

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!

Hi Raziela,

Just a thought, but when you use the Select Reserved Items button on the work order actuals, I believe it is copying from INVRESERVE and not the WPMATERIAL object. Perhaps you need to consider this in the logic? 

I tested this briefly by:
Adding a quantity to the PLAN,
APPROVING the WO (creates the reservation)
Modified (increased) the reservation qty
Selecting reserved Items the reserved quantity is what is pulled onto the actuals (matusetrans) line

100% agree with Craig though, use the system as designed, it is the responsibility of the storeroom to have inventory on hand to satisfy all demand.
The REORDER process does this well

Ken.

Hello Craig,

Thanks for your point of view. I haven't thought of using SASIA in the reverse, and I will try going with this approach. I will give feedback on how it goes.

Also to answer your questions:

• At what status does the work order reach the warehouse? 

Approved.

• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder. 

I understand your side, but this has been an important request from our client. They persisted on involving the warehouse user on that step, that's why we're adjusting with their procedures.

Thanks

Hi Raziela

------ Initial thoughts ------------------------------------------------------

My instinct is to use the inventory system as it has been designed:

1. Create a work order
2. Add some WPMATERIALS using items
3. Approve the work order.  This generates the reservation to the storeroom.
   1. Reorder is run
   2. New items are purchased to restock, if needed
4. Issue the items using the procedure you use to issue items:
   1. Actual materials on the work order
   2. Inventory Usage
   3. Issues and Transfers
   4. Inventory
5. Complete the work order

---- Thoughts based on the article ---------------------------------------------------------

My instinct is to use SASIA in the reverse. i.e. have the user insert the requested qty into the SASIA and copy that into the QTY field in the WPMATERIAL.  Hide the QTY field in WPMATERIAL, so the user doesn't know about the other or maybe mask it.

Why?  This still allows the reservation to occur.  The warehouse can adjust the reserved QTY.  This maintains the reordering system to work.

We are missing a bit of info:

• At what status does the work order reach the warehouse?
• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder.

Having the warehouse do any confirmation...before actually generating the demand (reservation) is putting extra work on the warehouse that they really don't need.

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!

Hi Ken,

Thanks a lot for your suggestion. I tested using INVRESERVE instead of WPMATERIAL and it seems to be working as desired. The only issue I'm facing now is that, since the moment the script was activated, the system has become noticeably slower, especially during work order approvals and when performing save actions for issuing materials to plans or actuals. It often stays in a loading state for a long time before completing the process.

I'm not entirely sure if this slowdown is directly related to the script or something else in the system, but I wanted to check if you've experienced similar behavior or if there might be something in the script that could affect performance.

Thanks again,

Raziela

Hi Raziela,

Just a thought, but when you use the Select Reserved Items button on the work order actuals, I believe it is copying from INVRESERVE and not the WPMATERIAL object. Perhaps you need to consider this in the logic? 

I tested this briefly by:
Adding a quantity to the PLAN,
APPROVING the WO (creates the reservation)
Modified (increased) the reservation qty
Selecting reserved Items the reserved quantity is what is pulled onto the actuals (matusetrans) line

100% agree with Craig though, use the system as designed, it is the responsibility of the storeroom to have inventory on hand to satisfy all demand.
The REORDER process does this well

Ken.

Hello Craig,

Thanks for your point of view. I haven't thought of using SASIA in the reverse, and I will try going with this approach. I will give feedback on how it goes.

Also to answer your questions:

• At what status does the work order reach the warehouse? 

Approved.

• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder. 

I understand your side, but this has been an important request from our client. They persisted on involving the warehouse user on that step, that's why we're adjusting with their procedures.

Thanks

Hi Raziela

------ Initial thoughts ------------------------------------------------------

My instinct is to use the inventory system as it has been designed:

1. Create a work order
2. Add some WPMATERIALS using items
3. Approve the work order.  This generates the reservation to the storeroom.
   1. Reorder is run
   2. New items are purchased to restock, if needed
4. Issue the items using the procedure you use to issue items:
   1. Actual materials on the work order
   2. Inventory Usage
   3. Issues and Transfers
   4. Inventory
5. Complete the work order

---- Thoughts based on the article ---------------------------------------------------------

My instinct is to use SASIA in the reverse. i.e. have the user insert the requested qty into the SASIA and copy that into the QTY field in the WPMATERIAL.  Hide the QTY field in WPMATERIAL, so the user doesn't know about the other or maybe mask it.

Why?  This still allows the reservation to occur.  The warehouse can adjust the reserved QTY.  This maintains the reordering system to work.

We are missing a bit of info:

• At what status does the work order reach the warehouse?
• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder.

Having the warehouse do any confirmation...before actually generating the demand (reservation) is putting extra work on the warehouse that they really don't need.

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!

Morning Raziela,

Unfortunately that is not my forte - probably the timing of the script firing. I would check the Object Launch point as a starting place.

You would need someone with deeper technical knowledge than I to help you find the correct launch point.

Ken.

Hi Ken,

Thanks a lot for your suggestion. I tested using INVRESERVE instead of WPMATERIAL and it seems to be working as desired. The only issue I'm facing now is that, since the moment the script was activated, the system has become noticeably slower, especially during work order approvals and when performing save actions for issuing materials to plans or actuals. It often stays in a loading state for a long time before completing the process.

I'm not entirely sure if this slowdown is directly related to the script or something else in the system, but I wanted to check if you've experienced similar behavior or if there might be something in the script that could affect performance.

Thanks again,

Raziela

Hi Raziela,

Just a thought, but when you use the Select Reserved Items button on the work order actuals, I believe it is copying from INVRESERVE and not the WPMATERIAL object. Perhaps you need to consider this in the logic? 

I tested this briefly by:
Adding a quantity to the PLAN,
APPROVING the WO (creates the reservation)
Modified (increased) the reservation qty
Selecting reserved Items the reserved quantity is what is pulled onto the actuals (matusetrans) line

100% agree with Craig though, use the system as designed, it is the responsibility of the storeroom to have inventory on hand to satisfy all demand.
The REORDER process does this well

Ken.

Hello Craig,

Thanks for your point of view. I haven't thought of using SASIA in the reverse, and I will try going with this approach. I will give feedback on how it goes.

Also to answer your questions:

• At what status does the work order reach the warehouse? 

Approved.

• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder. 

I understand your side, but this has been an important request from our client. They persisted on involving the warehouse user on that step, that's why we're adjusting with their procedures.

Thanks

Hi Raziela

------ Initial thoughts ------------------------------------------------------

My instinct is to use the inventory system as it has been designed:

1. Create a work order
2. Add some WPMATERIALS using items
3. Approve the work order.  This generates the reservation to the storeroom.
   1. Reorder is run
   2. New items are purchased to restock, if needed
4. Issue the items using the procedure you use to issue items:
   1. Actual materials on the work order
   2. Inventory Usage
   3. Issues and Transfers
   4. Inventory
5. Complete the work order

---- Thoughts based on the article ---------------------------------------------------------

My instinct is to use SASIA in the reverse. i.e. have the user insert the requested qty into the SASIA and copy that into the QTY field in the WPMATERIAL.  Hide the QTY field in WPMATERIAL, so the user doesn't know about the other or maybe mask it.

Why?  This still allows the reservation to occur.  The warehouse can adjust the reserved QTY.  This maintains the reordering system to work.

We are missing a bit of info:

• At what status does the work order reach the warehouse?
• Why is the warehouse having to confirm the quantity at all?  It's the volume that the user has requested, and that means the warehouse should be reviewing its stock balances to meet the demand.  If the user goes to do the pick-up and there is insufficient volume, then the user can only get what's present, and the rest is on backorder.

Having the warehouse do any confirmation...before actually generating the demand (reservation) is putting extra work on the warehouse that they really don't need.

Hello all,

I have a custom requirement related to Work Order Plans (WPMATERIAL) and Actuals (MATUSETRANS):

• In the Plans tab, the planner enters a quantity in the field ITEMQTY (standard field).
• The warehouse confirms the quantity in a custom field called SASIA (confirmed quantity). This value can be equal to ITEMQTY or smaller.
• In the Actuals tab, when adding a reserved item, Maximo automatically populates QUANTITY with the value of ITEMQTY. 

What I need to achieve

1. When adding reserved items to Actuals, the default value of QUANTITY should come from SASIA (confirmed quantity), not from ITEMQTY. 
2. If the user manually changes QUANTITY in Actuals, the system should allow it and not overwrite the manual value.

What I tried

• Created an Object Launch Point on MATUSETRANS and also Attribute Launch Point with automation scripts.
• Used the relationship MTRANS2WPITEM (MATUSETRANS → WPMATERIAL) to fetch SASIA.
• Logic: If QUANTITY is null or equal to ITEMQTY, then set QUANTITY = SASIA.

Problem

Even after implementing this:

• Manual entry works fine (user can change QUANTITY).
• But when adding reserved items, QUANTITY still takes ITEMQTY, not SASIA.
• Debug logs show that the script runs, but SASIA is either not picked up or overwritten by Maximo's default logic.

If you have any suggestions on what steps need to be taken regarding this scenario, I would really appreciate the help.

Thanks!