IBM Asset & Facilities Management Your destination for peer and expert insights to help unlock the power of data with AI and Asset & Facilities Management to advance your digital reinvention. Join / Log in
Hi guys: we have three Maximo databases that are all integrated with an external financial system. Approved PRs are being sent to the Financial system, and approved Pos are being sent back.
This is working, except for one problem: in one of the databases, when a PO is revised in the financial system and sent back to Maximo, Maximo throws an error if it has to re-open the PR, and won't save the PO revision. Specifically the error is "the purchase requisition is closed or canceled". We haven't been able to figure out why this one is throwing an error when another database, which is on the same fixpack, doesn't.
To get around this, we have tweaked the Organization settings to not close PRs, but this is causing a huge amount of user confusion, and attempts to hide fully-satisfied PRs are resulting in problems searching.
The biggest difference between the two databases is: the database that's not working is much older (upgraded from 4.1.1 to 7.5 to 220.127.116.11), whereas the one that works started in 2011, so presumably as 7.1. Otherwise, we can't think of any differences, but it could be an obscure setting somewhere that's causing the problem.
We've turned up the logs on:
So far, no luck – we can see the error, but we can't see anything that's useful (see below)
Caused by: psdi.util.MXApplicationException: BMXAA3433E - The purchase requisition is closed or canceled. The purchase order or contract cannot be created
... 47 more
Can anyone give me any pointers on where to look here? I'd be grateful.
Maximo Certified Deployment Professional
Maximo Certified Solution Advisor
President, InComm Solutions Inc.
(604) 562-8515 (cell)
It occurs to me, there might need to be a validation check in your integration to see if the PONUM attribute on the PRLINE is already populated. If not null then bypass the MBO processing on the PR, if all you are processing is a revision. The only thing I can see in my demo data is that you would be trying to update the PRLINE.PONUM attribute with a PONUM value. But if that is already populated..... errr... who cares? Maybe I am over simplifying the issue? At this point the PRLINE is the PRLINE, the fulfilment of that PR (e.g. the POLINE will differ and the RECEIPT and INVOICE will too,) but the only thing you really need is the PONUM correct? If that is already on the line, then I would think you would be good to go and could bypass this in your integration processing.
Hope this helps and is not a distraction to your problem solving.
Hey Bradley: thanks for replying. Unfortunately, we WANT the processing to happen, ideally the same thing that would happen if the PO is revised in Maximo. It's fine in the other two environments, and yet this one won't do it. Weird.
Hi Shannon I'd put an eye on Enterprise Services related to PO MIF. Do you mean that POs are sent to the financial system Approved and are returned back Revised? Which is PO status returned from the financial system?
The flow is: PR created in Maximo and approved --> PR sent to Oracle Fusion --> PO created in Fusion and approved --> PO sent back to Maximo and connected to PR --> PR closes as usual --> PO revised in Fusion and approved --> PO revision sent back to Maximo --> ERROR.
Enterprise Services seems about right. We've done some looking already, but I'll look again.
Anything you can think of would be useful at this point ...
Might also be worth comparing the mxcollab switches to confirm they are set the same. I'm the message content is identical, so anything around statusiface and revision number is in place on all database. Also check the inbound setting restrictions on the object structure.