PO Receipt Error - Unit of Measure does not exist. Unable to compute tax.

[johnhugh]

Hi, I'm using Accpac 6.
I've been struggling to capture a PO receipt. The receipt fails with error:
"Unit of Measure does not exist. Unable to compute tax."

I don't think the UOM is the issue.
I get the same error when I delete all the line items and just try to post an empty receipt for that PO.
The error could be triggered from the tax settings of the supplier.

The receipt is a partial receipt. In between the first receipt and the second receipt I've added an additional tax class to the tax authority the vendor is associated with.
I believe this is what is causing the error. I've tried removing the tax class again, but can still not do a receipt.
I'm out of ideas on how to fix it. I cannot cancel the PO either but need to remove the items from the outstanding order list.
Would really appreciate any help.

I have attached a link for the RVSPY of the error.
RVSPY

 

[johnhugh]

Anybody?

 

[Jay Converse]

Jeez, you come up with some of the screwiest problems.

Forget about that PO, it's f@#$@# up. Make a new one and move on.

 

[johnhugh]

Mate, appreciate any help you provide in this forum to myself and anyone else - really do.
However sometimes I wonder whether you have any customers that have more than 5 users and have procedures in place they try to follow?
I'm trying to get rid of this PO, because it shows up on our outstanding PO reports. We also have min/max and re-order quantities set up which we use for our replenishment.
If the items on this PO are still on back-order it won't be considered for replenishment messing up the supply chain for us.

You see I'm pedantic for a reason.

 

[Jay Converse]

I have very large (> 50 user) publicly traded and government customers who have been using Accpac for up to 15 years. For problems like this, use a database editor and set POPORL.COMPLETION = 2, OQORDERED=0, and SQORDERED=0. Once a PO goes bad, reposting it will only muck up day-end processing.

 

[DjangMan]

PO is even more pedantic. It's tables are the backwoods/hillbilly family of the database. They are all so interrelated that if one bit of information goes the PO, and it's relatives, all suffer.

 

[johnhugh]

Thanks. Will have to use a DB editor. Can't figure out how to fix it.