We have a requirement to force certain Items to be direct issue on Planned Materials. This plant has these parts in Inventory but they are not actually stocked. There is a field on the Inventory record we added to mark it as "DIRECT ISSUE". They want us to automatically mark these parts as direct issue if someone tries to add such an Item on a Planned Material line and fill out the Storeroom field. Here is where our script gets stuck:

Step 1) User enters the part number in the Item Field. Storeroom is empty but required.

Step 2) User enters the storeroom, tabs off and our script fires on the WPMATERIAL.LOCATION attribute. When this happens, there is an error that gets stuck in the storeroom attribute.

Maximo wouldn't show us this error nor would it get logged. So I figured out that if instead of manually typing in the storeroom, if I use the select value and choose it via the UI. I can see the error that is getting stuck:

Here is our script firing on the WPMATERIAL.LOCATION attribute (Run Action Event). Basically, get the inventory record for that Item, check if it is marked direct issue (our custom attribute) and that the storeroom is set. If that is all true, mark the WPMATERIAL line as direct issue and blank out the location.

inventorySet = mbo.getMboSet('INVENTORYSTATUS')
if not inventorySet.isEmpty():
  inventory = inventorySet.getMbo(0)
  if inventory.getString("REORDERTYPE")=="DIRECT ISSUE" and not mbo.isNull('LOCATION'):
     mbo.setValue("directreq", 1)
     mbo.setValueNull("location")

I think this error arises because we just manually typed a storeroom into the storeroom field but then our script fires and sets the planned material line to Direct Issue (directreq). At this point, Maximo is attempting to blank out the storeroom and storelocsite via it's normal logic tied to directreq but at the same time we also just set the storeroom via the UI. There has to be some conflict between those two situations causing that error?

My thought process of setting the location (storeroom) to null in that second line was that maybe blanking out the storeroom prior to setting directreq would help avoid this error but no luck. It also doesn't matter if I try setting the location to null before or after the directreq line.

When setting directreq, I have tried all the MboConstant variations of No Access Check, No Validation, No Action. The only one that gets us relatively close is MboConstants.NOVALIDATION_AND_NOACTION or using Delay Validation. But then we either lose all the Maximo logic of blanking out the storeroom field, storeroom site, setting the fields to read only etc or Delay Validation will delay it but then if the user changes items, the whole screen is out of whack.

Maybe I shouldn't run any logic on the LOCATION attribute because it has all this internal logic tied to it?

Anyway, I have tried so many variations on this thing, any input would maybe help me break into a new way of thinking about and solving this. Thanks!

------------------------------
Daniel Gruszka
------------------------------



#AssetandFacilitiesManagement
#Maximo
#MaximoIntegrationandScripting

I looked into this a bit in one of our demo environments and the error I saw was the storeroom site is read-only. Looking at the code, I believe what is happening is the storeroom (LOCATION) attribute is configured to bring over the storeroom site (think of it like a crossover domain, but done inside of the java code). Setting the attribute happens after your script fires but is evaluated if it needs to be done during validation of the attribute. During the validate of the attribute, a location existed so it thinks it needs to set the storeroom site. Even if you switched your launch point to validate, their logic would fire prior to your script so I don't see a way around it.

When they're setting attributes via this crossover logic, there is no suppressing of access control so you get the error (otherwise you'd have a storeroom site set on a record where it isn't allowed which would be incorrect). You'll have to come up with an alternate launch point (such as app validate/save of the WPMATERIAL record). This might be a better solution because other changes (such as the item) would impact your logic as well but obviously isn't the best from a user perspective. The other option is to extend the java class on the storeroom field. I don't really see another option.

------------------------------
Steven Shull
Director of Development
Projetech Inc
Cincinnati OH
------------------------------

Original Message:
Sent: Wed March 31, 2021 04:56 PM
From: Daniel Gruszka
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

We have a requirement to force certain Items to be direct issue on Planned Materials. This plant has these parts in Inventory but they are not actually stocked. There is a field on the Inventory record we added to mark it as "DIRECT ISSUE". They want us to automatically mark these parts as direct issue if someone tries to add such an Item on a Planned Material line and fill out the Storeroom field. Here is where our script gets stuck:

Step 1) User enters the part number in the Item Field. Storeroom is empty but required.

Step 2) User enters the storeroom, tabs off and our script fires on the WPMATERIAL.LOCATION attribute. When this happens, there is an error that gets stuck in the storeroom attribute.

Maximo wouldn't show us this error nor would it get logged. So I figured out that if instead of manually typing in the storeroom, if I use the select value and choose it via the UI. I can see the error that is getting stuck:

Here is our script firing on the WPMATERIAL.LOCATION attribute (Run Action Event). Basically, get the inventory record for that Item, check if it is marked direct issue (our custom attribute) and that the storeroom is set. If that is all true, mark the WPMATERIAL line as direct issue and blank out the location.

inventorySet = mbo.getMboSet('INVENTORYSTATUS')
if not inventorySet.isEmpty():
  inventory = inventorySet.getMbo(0)
  if inventory.getString("REORDERTYPE")=="DIRECT ISSUE" and not mbo.isNull('LOCATION'):
     mbo.setValue("directreq", 1)
     mbo.setValueNull("location")

I think this error arises because we just manually typed a storeroom into the storeroom field but then our script fires and sets the planned material line to Direct Issue (directreq). At this point, Maximo is attempting to blank out the storeroom and storelocsite via it's normal logic tied to directreq but at the same time we also just set the storeroom via the UI. There has to be some conflict between those two situations causing that error?

My thought process of setting the location (storeroom) to null in that second line was that maybe blanking out the storeroom prior to setting directreq would help avoid this error but no luck. It also doesn't matter if I try setting the location to null before or after the directreq line.

When setting directreq, I have tried all the MboConstant variations of No Access Check, No Validation, No Action. The only one that gets us relatively close is MboConstants.NOVALIDATION_AND_NOACTION or using Delay Validation. But then we either lose all the Maximo logic of blanking out the storeroom field, storeroom site, setting the fields to read only etc or Delay Validation will delay it but then if the user changes items, the whole screen is out of whack.

Maybe I shouldn't run any logic on the LOCATION attribute because it has all this internal logic tied to it?

Anyway, I have tried so many variations on this thing, any input would maybe help me break into a new way of thinking about and solving this. Thanks!

------------------------------
Daniel Gruszka
------------------------------



#AssetandFacilitiesManagement
#Maximo
#MaximoIntegrationandScripting

Ahh that makes sense. Thank you so much for clarifying that Steven! Really appreciate your help. I think we will attempt to move it to the Object Save on WPMATERIAL as you suggested.

------------------------------
Daniel Gruszka
------------------------------

Original Message:
Sent: Thu April 01, 2021 08:35 AM
From: Steven Shull
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

I looked into this a bit in one of our demo environments and the error I saw was the storeroom site is read-only. Looking at the code, I believe what is happening is the storeroom (LOCATION) attribute is configured to bring over the storeroom site (think of it like a crossover domain, but done inside of the java code). Setting the attribute happens after your script fires but is evaluated if it needs to be done during validation of the attribute. During the validate of the attribute, a location existed so it thinks it needs to set the storeroom site. Even if you switched your launch point to validate, their logic would fire prior to your script so I don't see a way around it.

When they're setting attributes via this crossover logic, there is no suppressing of access control so you get the error (otherwise you'd have a storeroom site set on a record where it isn't allowed which would be incorrect). You'll have to come up with an alternate launch point (such as app validate/save of the WPMATERIAL record). This might be a better solution because other changes (such as the item) would impact your logic as well but obviously isn't the best from a user perspective. The other option is to extend the java class on the storeroom field. I don't really see another option.

------------------------------
Steven Shull
Director of Development
Projetech Inc
Cincinnati OH

Original Message:
Sent: Wed March 31, 2021 04:56 PM
From: Daniel Gruszka
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

We have a requirement to force certain Items to be direct issue on Planned Materials. This plant has these parts in Inventory but they are not actually stocked. There is a field on the Inventory record we added to mark it as "DIRECT ISSUE". They want us to automatically mark these parts as direct issue if someone tries to add such an Item on a Planned Material line and fill out the Storeroom field. Here is where our script gets stuck:

Step 1) User enters the part number in the Item Field. Storeroom is empty but required.

Step 2) User enters the storeroom, tabs off and our script fires on the WPMATERIAL.LOCATION attribute. When this happens, there is an error that gets stuck in the storeroom attribute.

Maximo wouldn't show us this error nor would it get logged. So I figured out that if instead of manually typing in the storeroom, if I use the select value and choose it via the UI. I can see the error that is getting stuck:

Here is our script firing on the WPMATERIAL.LOCATION attribute (Run Action Event). Basically, get the inventory record for that Item, check if it is marked direct issue (our custom attribute) and that the storeroom is set. If that is all true, mark the WPMATERIAL line as direct issue and blank out the location.

inventorySet = mbo.getMboSet('INVENTORYSTATUS')
if not inventorySet.isEmpty():
  inventory = inventorySet.getMbo(0)
  if inventory.getString("REORDERTYPE")=="DIRECT ISSUE" and not mbo.isNull('LOCATION'):
     mbo.setValue("directreq", 1)
     mbo.setValueNull("location")

I think this error arises because we just manually typed a storeroom into the storeroom field but then our script fires and sets the planned material line to Direct Issue (directreq). At this point, Maximo is attempting to blank out the storeroom and storelocsite via it's normal logic tied to directreq but at the same time we also just set the storeroom via the UI. There has to be some conflict between those two situations causing that error?

My thought process of setting the location (storeroom) to null in that second line was that maybe blanking out the storeroom prior to setting directreq would help avoid this error but no luck. It also doesn't matter if I try setting the location to null before or after the directreq line.

When setting directreq, I have tried all the MboConstant variations of No Access Check, No Validation, No Action. The only one that gets us relatively close is MboConstants.NOVALIDATION_AND_NOACTION or using Delay Validation. But then we either lose all the Maximo logic of blanking out the storeroom field, storeroom site, setting the fields to read only etc or Delay Validation will delay it but then if the user changes items, the whole screen is out of whack.

Maybe I shouldn't run any logic on the LOCATION attribute because it has all this internal logic tied to it?

Anyway, I have tried so many variations on this thing, any input would maybe help me break into a new way of thinking about and solving this. Thanks!

------------------------------
Daniel Gruszka
------------------------------



#Maximo
#AssetandFacilitiesManagement
#MaximoIntegrationandScripting

For what it may or may not be worth, you may want to consider your Direct Issue Only items as stock type NS (NonStock) for those items NOT in inventory.  To have an item listed in inventory simply means that:  you have inventory (i.e. CURBAL is normally greater than zero and you have schtuff on schelves. ;) ).    Use the system as designed and for those items for which you have no intention of carrying items in bins on shelves in your warehouse(s) then make them NS.  

Now for the ability to force user to set them as Direct Issue simply by choosing them, add your custom attribute on the Item master record.  When you add your itemnum to the wpmaterial object you can use the attribute point automation script to validate on the itemnum and set the directreq attribute based on the custom attribute on the Item master record.  Here is script:

from psdi.mbo import SqlFormat
from psdi.mbo import Mbo
from psdi.mbo import MboConstants

if (mbo != None ):

pItemSet = mbo.getMboSet("$ITEM","ITEM","itemnum = :itemnum ");

pItem = pItemSet.getMbo(0)
if (pItem != None):
p_dionly = pItem.getBoolean("{yourCustomAttribute}");

mbo.setValue("directreq", p_dionly , MboConstants.NOACCESSCHECK);

Taking this approach will a) solve the technical problem, and b) solve the many other issues you have or will have in managing your storeroom (e.g. trying to receive items to bins that do not exist for stock type items which aren't there; running your physcount reports to filter on a possibly ever changing list of NS items which are listed as STK since you have them in your inventory; filtering out the items in inventory which are never supporsed to be order on the reorder report since they are NS instead of STK, and on, and on.

Hopefully you can implement this change easily by changing your Direct Issue Only items to NS, adding your custom YORN attribute to the item master record, and then implementing the automation script.

I trust this will help.

------------------------------
Bradley K. Downing , MBA
IBM Certified Adv. Deployment Prof. Maximo v7.6.1
IBM
Bakersfield CA
------------------------------

Original Message:
Sent: Wed March 31, 2021 04:56 PM
From: Daniel Gruszka
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

We have a requirement to force certain Items to be direct issue on Planned Materials. This plant has these parts in Inventory but they are not actually stocked. There is a field on the Inventory record we added to mark it as "DIRECT ISSUE". They want us to automatically mark these parts as direct issue if someone tries to add such an Item on a Planned Material line and fill out the Storeroom field. Here is where our script gets stuck:

Step 1) User enters the part number in the Item Field. Storeroom is empty but required.

Step 2) User enters the storeroom, tabs off and our script fires on the WPMATERIAL.LOCATION attribute. When this happens, there is an error that gets stuck in the storeroom attribute.

Maximo wouldn't show us this error nor would it get logged. So I figured out that if instead of manually typing in the storeroom, if I use the select value and choose it via the UI. I can see the error that is getting stuck:

Here is our script firing on the WPMATERIAL.LOCATION attribute (Run Action Event). Basically, get the inventory record for that Item, check if it is marked direct issue (our custom attribute) and that the storeroom is set. If that is all true, mark the WPMATERIAL line as direct issue and blank out the location.

inventorySet = mbo.getMboSet('INVENTORYSTATUS')
if not inventorySet.isEmpty():
  inventory = inventorySet.getMbo(0)
  if inventory.getString("REORDERTYPE")=="DIRECT ISSUE" and not mbo.isNull('LOCATION'):
     mbo.setValue("directreq", 1)
     mbo.setValueNull("location")

I think this error arises because we just manually typed a storeroom into the storeroom field but then our script fires and sets the planned material line to Direct Issue (directreq). At this point, Maximo is attempting to blank out the storeroom and storelocsite via it's normal logic tied to directreq but at the same time we also just set the storeroom via the UI. There has to be some conflict between those two situations causing that error?

My thought process of setting the location (storeroom) to null in that second line was that maybe blanking out the storeroom prior to setting directreq would help avoid this error but no luck. It also doesn't matter if I try setting the location to null before or after the directreq line.

When setting directreq, I have tried all the MboConstant variations of No Access Check, No Validation, No Action. The only one that gets us relatively close is MboConstants.NOVALIDATION_AND_NOACTION or using Delay Validation. But then we either lose all the Maximo logic of blanking out the storeroom field, storeroom site, setting the fields to read only etc or Delay Validation will delay it but then if the user changes items, the whole screen is out of whack.

Maybe I shouldn't run any logic on the LOCATION attribute because it has all this internal logic tied to it?

Anyway, I have tried so many variations on this thing, any input would maybe help me break into a new way of thinking about and solving this. Thanks!

------------------------------
Daniel Gruszka
------------------------------



#AssetandFacilitiesManagement
#Maximo
#MaximoIntegrationandScripting

Thanks for the detailed solution Bradley! I have a few questions based on that. To my knowledge, Stock / NS can only be set at the Item Master level in the Item Org Details. In our case, we have 13 sites under a single organization so we cannot make the part NS at that level because other plants may stock the part and track inventory.

As for this site in particular, they like to have everything in Inventory so it is easier for users to track down parts rather than search the entire Item Master enterprise wide. By using the custom attribute on Inventory, users can still search through Inventory and don't have to think about whether it is stocked or not stocked. They then select the Item from Inventory and the logic will automatically mark it direct issue based on our attribute.

I think if we were 1 to 1 with Org / Site then it would be easy to use NS at the Item Org Level like you suggested. The other problem we noticed with the NS designation is it doesn't seem to drive any logic? We attempted to expose the category field on the Inventory level and set it to NS but Maximo still seemed to treat it like a stocked item in Inventory.

------------------------------
Daniel Gruszka
------------------------------

Original Message:
Sent: Thu April 01, 2021 08:34 PM
From: Bradley Downing
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

For what it may or may not be worth, you may want to consider your Direct Issue Only items as stock type NS (NonStock) for those items NOT in inventory.  To have an item listed in inventory simply means that:  you have inventory (i.e. CURBAL is normally greater than zero and you have schtuff on schelves. ;) ).    Use the system as designed and for those items for which you have no intention of carrying items in bins on shelves in your warehouse(s) then make them NS.  

Now for the ability to force user to set them as Direct Issue simply by choosing them, add your custom attribute on the Item master record.  When you add your itemnum to the wpmaterial object you can use the attribute point automation script to validate on the itemnum and set the directreq attribute based on the custom attribute on the Item master record.  Here is script:

from psdi.mbo import SqlFormat
from psdi.mbo import Mbo
from psdi.mbo import MboConstants

if (mbo != None ):

pItemSet = mbo.getMboSet("$ITEM","ITEM","itemnum = :itemnum ");

pItem = pItemSet.getMbo(0)
if (pItem != None):
p_dionly = pItem.getBoolean("{yourCustomAttribute}");

mbo.setValue("directreq", p_dionly , MboConstants.NOACCESSCHECK);

Taking this approach will a) solve the technical problem, and b) solve the many other issues you have or will have in managing your storeroom (e.g. trying to receive items to bins that do not exist for stock type items which aren't there; running your physcount reports to filter on a possibly ever changing list of NS items which are listed as STK since you have them in your inventory; filtering out the items in inventory which are never supporsed to be order on the reorder report since they are NS instead of STK, and on, and on.

Hopefully you can implement this change easily by changing your Direct Issue Only items to NS, adding your custom YORN attribute to the item master record, and then implementing the automation script.

I trust this will help.

------------------------------
Bradley K. Downing , MBA
IBM Certified Adv. Deployment Prof. Maximo v7.6.1
IBM
Bakersfield CA

Original Message:
Sent: Wed March 31, 2021 04:56 PM
From: Daniel Gruszka
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

We have a requirement to force certain Items to be direct issue on Planned Materials. This plant has these parts in Inventory but they are not actually stocked. There is a field on the Inventory record we added to mark it as "DIRECT ISSUE". They want us to automatically mark these parts as direct issue if someone tries to add such an Item on a Planned Material line and fill out the Storeroom field. Here is where our script gets stuck:

Step 1) User enters the part number in the Item Field. Storeroom is empty but required.

Step 2) User enters the storeroom, tabs off and our script fires on the WPMATERIAL.LOCATION attribute. When this happens, there is an error that gets stuck in the storeroom attribute.

Maximo wouldn't show us this error nor would it get logged. So I figured out that if instead of manually typing in the storeroom, if I use the select value and choose it via the UI. I can see the error that is getting stuck:

Here is our script firing on the WPMATERIAL.LOCATION attribute (Run Action Event). Basically, get the inventory record for that Item, check if it is marked direct issue (our custom attribute) and that the storeroom is set. If that is all true, mark the WPMATERIAL line as direct issue and blank out the location.

inventorySet = mbo.getMboSet('INVENTORYSTATUS')
if not inventorySet.isEmpty():
  inventory = inventorySet.getMbo(0)
  if inventory.getString("REORDERTYPE")=="DIRECT ISSUE" and not mbo.isNull('LOCATION'):
     mbo.setValue("directreq", 1)
     mbo.setValueNull("location")

I think this error arises because we just manually typed a storeroom into the storeroom field but then our script fires and sets the planned material line to Direct Issue (directreq). At this point, Maximo is attempting to blank out the storeroom and storelocsite via it's normal logic tied to directreq but at the same time we also just set the storeroom via the UI. There has to be some conflict between those two situations causing that error?

My thought process of setting the location (storeroom) to null in that second line was that maybe blanking out the storeroom prior to setting directreq would help avoid this error but no luck. It also doesn't matter if I try setting the location to null before or after the directreq line.

When setting directreq, I have tried all the MboConstant variations of No Access Check, No Validation, No Action. The only one that gets us relatively close is MboConstants.NOVALIDATION_AND_NOACTION or using Delay Validation. But then we either lose all the Maximo logic of blanking out the storeroom field, storeroom site, setting the fields to read only etc or Delay Validation will delay it but then if the user changes items, the whole screen is out of whack.

Maybe I shouldn't run any logic on the LOCATION attribute because it has all this internal logic tied to it?

Anyway, I have tried so many variations on this thing, any input would maybe help me break into a new way of thinking about and solving this. Thanks!

------------------------------
Daniel Gruszka
------------------------------



#MaximoIntegrationandScripting
#AssetandFacilitiesManagement
#Maximo

Daniel,

OK critical piece of info there.  You are correct, the stock category is an attribute of the ITEMORGINFO object and as such is in direct relationship to the item and not inventory.  So if you are using the item as STK at plant 'A' and NS at plant 'B' then you will need to proceed as you have done working at the INVENTORY object level.   So to your main point if plant A is stocking and plant B chooses not to, then yes it is a STK item and your custom attribute is likely in the best place (i.e. on the INVENTORY object).  So back to the question at hand: try the attribute launch point using your custom attribute from inventory instead of item and see how that behaves.

------------------------------
Bradley K. Downing , MBA
IBM Certified Adv. Deployment Prof. Maximo v7.6.1
IBM
Bakersfield CA
------------------------------

Original Message:
Sent: Mon April 05, 2021 11:05 AM
From: Daniel Gruszka
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

Thanks for the detailed solution Bradley! I have a few questions based on that. To my knowledge, Stock / NS can only be set at the Item Master level in the Item Org Details. In our case, we have 13 sites under a single organization so we cannot make the part NS at that level because other plants may stock the part and track inventory.

As for this site in particular, they like to have everything in Inventory so it is easier for users to track down parts rather than search the entire Item Master enterprise wide. By using the custom attribute on Inventory, users can still search through Inventory and don't have to think about whether it is stocked or not stocked. They then select the Item from Inventory and the logic will automatically mark it direct issue based on our attribute.

I think if we were 1 to 1 with Org / Site then it would be easy to use NS at the Item Org Level like you suggested. The other problem we noticed with the NS designation is it doesn't seem to drive any logic? We attempted to expose the category field on the Inventory level and set it to NS but Maximo still seemed to treat it like a stocked item in Inventory.

------------------------------
Daniel Gruszka

Original Message:
Sent: Thu April 01, 2021 08:34 PM
From: Bradley Downing
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

For what it may or may not be worth, you may want to consider your Direct Issue Only items as stock type NS (NonStock) for those items NOT in inventory.  To have an item listed in inventory simply means that:  you have inventory (i.e. CURBAL is normally greater than zero and you have schtuff on schelves. ;) ).    Use the system as designed and for those items for which you have no intention of carrying items in bins on shelves in your warehouse(s) then make them NS.  

Now for the ability to force user to set them as Direct Issue simply by choosing them, add your custom attribute on the Item master record.  When you add your itemnum to the wpmaterial object you can use the attribute point automation script to validate on the itemnum and set the directreq attribute based on the custom attribute on the Item master record.  Here is script:

from psdi.mbo import SqlFormat
from psdi.mbo import Mbo
from psdi.mbo import MboConstants

if (mbo != None ):

pItemSet = mbo.getMboSet("$ITEM","ITEM","itemnum = :itemnum ");

pItem = pItemSet.getMbo(0)
if (pItem != None):
p_dionly = pItem.getBoolean("{yourCustomAttribute}");

mbo.setValue("directreq", p_dionly , MboConstants.NOACCESSCHECK);

Taking this approach will a) solve the technical problem, and b) solve the many other issues you have or will have in managing your storeroom (e.g. trying to receive items to bins that do not exist for stock type items which aren't there; running your physcount reports to filter on a possibly ever changing list of NS items which are listed as STK since you have them in your inventory; filtering out the items in inventory which are never supporsed to be order on the reorder report since they are NS instead of STK, and on, and on.

Hopefully you can implement this change easily by changing your Direct Issue Only items to NS, adding your custom YORN attribute to the item master record, and then implementing the automation script.

I trust this will help.

------------------------------
Bradley K. Downing , MBA
IBM Certified Adv. Deployment Prof. Maximo v7.6.1
IBM
Bakersfield CA

Original Message:
Sent: Wed March 31, 2021 04:56 PM
From: Daniel Gruszka
Subject: Script to remove Storeroom / Set Direct Issue on Planned Material Line (WPMATERIAL)

We have a requirement to force certain Items to be direct issue on Planned Materials. This plant has these parts in Inventory but they are not actually stocked. There is a field on the Inventory record we added to mark it as "DIRECT ISSUE". They want us to automatically mark these parts as direct issue if someone tries to add such an Item on a Planned Material line and fill out the Storeroom field. Here is where our script gets stuck:

Step 1) User enters the part number in the Item Field. Storeroom is empty but required.

Step 2) User enters the storeroom, tabs off and our script fires on the WPMATERIAL.LOCATION attribute. When this happens, there is an error that gets stuck in the storeroom attribute.

Maximo wouldn't show us this error nor would it get logged. So I figured out that if instead of manually typing in the storeroom, if I use the select value and choose it via the UI. I can see the error that is getting stuck:

Here is our script firing on the WPMATERIAL.LOCATION attribute (Run Action Event). Basically, get the inventory record for that Item, check if it is marked direct issue (our custom attribute) and that the storeroom is set. If that is all true, mark the WPMATERIAL line as direct issue and blank out the location.

inventorySet = mbo.getMboSet('INVENTORYSTATUS')
if not inventorySet.isEmpty():
  inventory = inventorySet.getMbo(0)
  if inventory.getString("REORDERTYPE")=="DIRECT ISSUE" and not mbo.isNull('LOCATION'):
     mbo.setValue("directreq", 1)
     mbo.setValueNull("location")

I think this error arises because we just manually typed a storeroom into the storeroom field but then our script fires and sets the planned material line to Direct Issue (directreq). At this point, Maximo is attempting to blank out the storeroom and storelocsite via it's normal logic tied to directreq but at the same time we also just set the storeroom via the UI. There has to be some conflict between those two situations causing that error?

My thought process of setting the location (storeroom) to null in that second line was that maybe blanking out the storeroom prior to setting directreq would help avoid this error but no luck. It also doesn't matter if I try setting the location to null before or after the directreq line.

When setting directreq, I have tried all the MboConstant variations of No Access Check, No Validation, No Action. The only one that gets us relatively close is MboConstants.NOVALIDATION_AND_NOACTION or using Delay Validation. But then we either lose all the Maximo logic of blanking out the storeroom field, storeroom site, setting the fields to read only etc or Delay Validation will delay it but then if the user changes items, the whole screen is out of whack.

Maybe I shouldn't run any logic on the LOCATION attribute because it has all this internal logic tied to it?

Anyway, I have tried so many variations on this thing, any input would maybe help me break into a new way of thinking about and solving this. Thanks!

------------------------------
Daniel Gruszka
------------------------------



#Maximo
#AssetandFacilitiesManagement
#MaximoIntegrationandScripting