You can't suppress validation of the POs for receiving without causing more problems.
And you probably don't want to use inventory adjustments for an integration. When you do something like a current balance adjustment, you need to tell Maximo what the new balance should be. You can't tell Maximo to add 3 to the current balance for example. You need to tell Maximo the new balance is 8. That makes it point in time dependent where any other receipts, issues, transfers, etc. will impact what the new balance should be. Integrations should ideally be routed through queues which makes that more problematic.
Depending on your comfort level, you could try to write your own logic where you provide a value in the message of what you want the behavior to be (-2 for example) and then pull the current balance to trigger the balance.
But I'd probably want to understand the integration errors for PO and how to avoid those. The integration method (SOAP vs REST for example) won't fundamentally change the behavior so I don't think rewriting it to REST would solve anything unless you took time to redesign the integration. If Maximo isn't the system of record, the PO can be kept extremely simple. You need a vendor, but you could use a generic vendor for all the POs to avoid situations where the company doesn't exist in Maximo. You need details about the item, storeroom, etc. but that data should already exist in the Maximo system.
Unless you have users using POs interactively, the idea of replicating PO data from another system via integration would not require licensing. This is one of the scenarios IBM is explicit about because the system of record is the purchasing system. You're merely replicating the data to Maximo to take advantage of other functionality like inventory.