receipt reversal of stock order blocked because of extended cost

[dlsesler]

I am having trouble with repairing a problem to an order for an inventory. This is the scenario:

1. An item is entered in the item master. It is not assigned a cost.
2. An order is entered for one of the item. No cost is entered.
3. The order is revised. A unit cost is added to the original line. A second line is entered for negative one of an item (this is how we handle returns), with no unit cost added (this was an error on the user’s part).
4. Both lines are received.
5. When attempting to reverse line 2 (so that I can correct the second item by adding a unit cost at the PO level), I get the following error message – “The Extended Price is incorrect. The Extended Price should equal the number of units multiplied by the unit price.”

Here are the details about our system:
EnterpriseOne release – 8.93.S1
Platform/Server/Environment – AS400
Service Pack / Tools Release – release B9, service pack 3

I have posted this problem with Oracle, but all they could recommend was applying the latest ESU (PF5613). I would gladly do this, if they could tell me what the ESU would fix. Ideally, I would like to fix this one-time error without going through that process.

 

[janicej]

Can you SQL the F4311 and populate the unit cost (PDPRRC) and extended cost (PDAEXP) fields?

 

[dlsesler]

Thanks -- that is one of the options I am investigating. Since the OV line for the item in the PO receiver table also has costs of 0, I would have to SQL those fields in F43121 as well. Do you know if any other fields would be affected, such as item detail?

 

[janicej]

Oh, yeah...item detail. When I wrote that response, I was thinking that you could populate just enough fields to be able to reverse line 2 without an error. Then when it's recreated correctly, it would correct the associated files. Now that I'm thinking it through more, the system may not let you do the reverse if the F4311, F43121 and F4111 files aren't in sync. At the very least, you may get some integrity issues. Do you have a test environment where you can recreate this and test, test, test?

 

[zhusain90]

Not sure if you have resolved this issue.

This issue normally happens due to Unit of Measure conversion issues. When the Extended Price is being calculated -- the UOM conversion is being used and creates a rounding issue.

Take a look at the Conversion factors to resolve the issue permanently.