Maximo Open Forum

Hi Experts,

Lately we are encountering the below issue while integration is trying to create approve PO in Maximo. We verified the PO limit of MXINTADM (Integration User) and that has been set to "NO LIMIT". All other limit and tolerances are also set to NOLIMIT and UNLIMITED. Our integration uses APIKEY to create POs in Maximo with PO lines through lean OSLC calls. Header has been set to x-method-override as SYNC and data is in JSON format. Object structure has PO and POLINE object in it.

 ERROR: BMXAA3279E - Could not change PO EP362 status to APPR.\n\tBMXAA3289E - The order amount exceeds the purchasing limit.",

Our environment has been recently upgraded to 7613 recently and found that IBM has implemented an APAR IJ32670 as part of 7613. So We have requested IBM to let us know what changes they have added as part of this APAR and waiting for their response.  Our BASE currency is AUD and exchange rate is 1.0 while calculating the Total cost.

Meantime, I have gone through the logs and found that the error is coming from the POSTATUSHANDLER.APPROVE() method (refer attached screenshot for the class). After further investigation, I found that Maximo is calculating the Total cost in Base price (by multiplying with the exchange rate) and comparing with the POLIMIT retrieved from the Security Profile of the user (MXINTADM) and also checking whether the retrieved POLIMT value is not equal to  1.79769313486e+308 (guessing this has been used for NOLIMIT). 

So I tried to get the tolerance value from the security profile in an automation script (by using the same code and creating dummy launch Point on PO before Save to invoke it on integration call) and found that it returns 0.0 instead of 1.79769313486e+308 even if the PO limit has been set to "NO LIMIT" (null in UI) for MXINTADM. Then I have set the PO limit to some finite value (5000), still it returns 0.0. 

Now I am confused where is this 0.0 value is getting initialized. I checked in DB, app designer and found nothing. 

If anyone has any advise, please respond.

--> Used the below code to get and print the PO limit while calling the integration...

raise TypeError(mbo.getProfile().getTolerance("POLIMIT",mbo.getString("ORGID"))) ->  [mbo is PO --> ProfileRemote.getProfile() --> MboServerRemote.getMboServer().getTolerance(attrName, string orgsite)

I don't think APAR IJ32670 is relevant to your issue. Essentially, if the PO was INPRG status before, users could then change it to APPR status even if the PO exceeded their approval limits. This was initially implemented to fix IJ22724 where when a contract was INPRG status and someone tried to change it to APPR it could throw an error indicating that it exceeded the contract limits. Our fix for IJ32670 made it so we only ignored checking limits going from INPRG->APPR when it involved a contract. 

I assume in your case the PO is being approved for the first time so neither one of those APARs would be relevant. It seems like the bug is around null not being treated as unlimited approval. I have always seen it typed out as all 9s like 99,999,999 to be more obvious. 

Hi Experts,

Lately we are encountering the below issue while integration is trying to create approve PO in Maximo. We verified the PO limit of MXINTADM (Integration User) and that has been set to "NO LIMIT". All other limit and tolerances are also set to NOLIMIT and UNLIMITED. Our integration uses APIKEY to create POs in Maximo with PO lines through lean OSLC calls. Header has been set to x-method-override as SYNC and data is in JSON format. Object structure has PO and POLINE object in it.

 ERROR: BMXAA3279E - Could not change PO EP362 status to APPR.\n\tBMXAA3289E - The order amount exceeds the purchasing limit.",

Our environment has been recently upgraded to 7613 recently and found that IBM has implemented an APAR IJ32670 as part of 7613. So We have requested IBM to let us know what changes they have added as part of this APAR and waiting for their response.  Our BASE currency is AUD and exchange rate is 1.0 while calculating the Total cost.

Meantime, I have gone through the logs and found that the error is coming from the POSTATUSHANDLER.APPROVE() method (refer attached screenshot for the class). After further investigation, I found that Maximo is calculating the Total cost in Base price (by multiplying with the exchange rate) and comparing with the POLIMIT retrieved from the Security Profile of the user (MXINTADM) and also checking whether the retrieved POLIMT value is not equal to  1.79769313486e+308 (guessing this has been used for NOLIMIT). 

So I tried to get the tolerance value from the security profile in an automation script (by using the same code and creating dummy launch Point on PO before Save to invoke it on integration call) and found that it returns 0.0 instead of 1.79769313486e+308 even if the PO limit has been set to "NO LIMIT" (null in UI) for MXINTADM. Then I have set the PO limit to some finite value (5000), still it returns 0.0. 

Now I am confused where is this 0.0 value is getting initialized. I checked in DB, app designer and found nothing. 

If anyone has any advise, please respond.

--> Used the below code to get and print the PO limit while calling the integration...

raise TypeError(mbo.getProfile().getTolerance("POLIMIT",mbo.getString("ORGID"))) ->  [mbo is PO --> ProfileRemote.getProfile() --> MboServerRemote.getMboServer().getTolerance(attrName, string orgsite)

Hi @Steven Shull 

Thanks for confirming the APAR is not related to our issue. Currently the issue is resolved after we deleted the limit entries from MAXEVERYONE security group. The limit and tolerance was set to 0 for all the fields for maxeveryone.

Now I have two questions:
1. does maximo takes time to reflect the changes? becuase when I posted the same message from postman (after deleting the limits from MAXEVERYONE) before asking it in this forum, I used to get same error. 
2. As I know, the unlimited limits take precedence over other values including 0. 
   Then why it didn't work when MAXEVERYONE has POLIMIT set to 0 and MAXEVERYONE has POLIMIT set to NOLIMIT.

I don't think APAR IJ32670 is relevant to your issue. Essentially, if the PO was INPRG status before, users could then change it to APPR status even if the PO exceeded their approval limits. This was initially implemented to fix IJ22724 where when a contract was INPRG status and someone tried to change it to APPR it could throw an error indicating that it exceeded the contract limits. Our fix for IJ32670 made it so we only ignored checking limits going from INPRG->APPR when it involved a contract. 

I assume in your case the PO is being approved for the first time so neither one of those APARs would be relevant. It seems like the bug is around null not being treated as unlimited approval. I have always seen it typed out as all 9s like 99,999,999 to be more obvious. 

Hi Experts,

Lately we are encountering the below issue while integration is trying to create approve PO in Maximo. We verified the PO limit of MXINTADM (Integration User) and that has been set to "NO LIMIT". All other limit and tolerances are also set to NOLIMIT and UNLIMITED. Our integration uses APIKEY to create POs in Maximo with PO lines through lean OSLC calls. Header has been set to x-method-override as SYNC and data is in JSON format. Object structure has PO and POLINE object in it.

 ERROR: BMXAA3279E - Could not change PO EP362 status to APPR.\n\tBMXAA3289E - The order amount exceeds the purchasing limit.",

Our environment has been recently upgraded to 7613 recently and found that IBM has implemented an APAR IJ32670 as part of 7613. So We have requested IBM to let us know what changes they have added as part of this APAR and waiting for their response.  Our BASE currency is AUD and exchange rate is 1.0 while calculating the Total cost.

Meantime, I have gone through the logs and found that the error is coming from the POSTATUSHANDLER.APPROVE() method (refer attached screenshot for the class). After further investigation, I found that Maximo is calculating the Total cost in Base price (by multiplying with the exchange rate) and comparing with the POLIMIT retrieved from the Security Profile of the user (MXINTADM) and also checking whether the retrieved POLIMT value is not equal to  1.79769313486e+308 (guessing this has been used for NOLIMIT). 

So I tried to get the tolerance value from the security profile in an automation script (by using the same code and creating dummy launch Point on PO before Save to invoke it on integration call) and found that it returns 0.0 instead of 1.79769313486e+308 even if the PO limit has been set to "NO LIMIT" (null in UI) for MXINTADM. Then I have set the PO limit to some finite value (5000), still it returns 0.0. 

Now I am confused where is this 0.0 value is getting initialized. I checked in DB, app designer and found nothing. 

If anyone has any advise, please respond.

--> Used the below code to get and print the PO limit while calling the integration...

raise TypeError(mbo.getProfile().getTolerance("POLIMIT",mbo.getString("ORGID"))) ->  [mbo is PO --> ProfileRemote.getProfile() --> MboServerRemote.getMboServer().getTolerance(attrName, string orgsite)