jolly
VIP Member
Hi All,
Have raised this issue with Oracle but need an answer in less than 2 months so will try asking here!
We have this issue at an 8.12 customer, and have replicated it on DemoJr in both 8.12 and 9.1.
Here is the scenario:
Set up a purchased, non stock item with primary UOM that is different to purchasing and component UOMs. Setup UOM conversions between primary and the purchasing and component UOMs. Setup an item cost (in primary UOM).
Add the item to a work order with a quantity in P13730.
It should default in the component UOM.
Press "Save Changes". The system brings back a unit cost that is the primary unit cost, not the expected component unit cost. The extended cost is correctly the component unit cost times the qty.
Now press the 'Create Purchase Order' button.
The system creates a purchase order for the given Qty and purchasing qty, but prices it at the primary rate!
It then updates the line on the WO parts list by scaling the requested qty with the UOM conversion to primary!
Example: Define an item for Oil, primary UOM is LT (litres), purchasing and component UOM is DR (drums).
Specify a cost (in LT) for this item of say $2/LT and a conversion factor of LT - DR of 1 - 200.
So we are stocking our oil in LT at $2/LT but purchasing it and putting it on workorders in DR at $400 a drum with 200 LT to 1 DR.
In our scenario, put 2 DR on a parts list in P13700 and save. The system calculates on the parts list an "Estimated (unit) Cost" of $2 but that makes no sense on a line with a UOM of DR ! It correctly puts the extended cost at $800.
Now for the worst part: Press the "Create Purchase Order" button.
It creates a purchase order for 2 DR at unit cost $4 and extended cost $8 !!!
And then it updates the Qty on the workorder parts list line down by the conversion factor to 0.005 DR !!!
This seems to be a bug. If I put it on a workorder for 2 drums I want it to stay there at 2 drums!
So, my good JDE friends... am I missing something? Is this a bug or not and has anyone else encountered this? Found a workaround or coded a fix?
My customer insists they want it to work the way they expected, and want me to modify the code to suit as they can't wait on Oracle to fix it. Have taken a look and the solution does not look all that easy.
Thanks in advance for any comments!
Cheers
JohnO
Have raised this issue with Oracle but need an answer in less than 2 months so will try asking here!
We have this issue at an 8.12 customer, and have replicated it on DemoJr in both 8.12 and 9.1.
Here is the scenario:
Set up a purchased, non stock item with primary UOM that is different to purchasing and component UOMs. Setup UOM conversions between primary and the purchasing and component UOMs. Setup an item cost (in primary UOM).
Add the item to a work order with a quantity in P13730.
It should default in the component UOM.
Press "Save Changes". The system brings back a unit cost that is the primary unit cost, not the expected component unit cost. The extended cost is correctly the component unit cost times the qty.
Now press the 'Create Purchase Order' button.
The system creates a purchase order for the given Qty and purchasing qty, but prices it at the primary rate!
It then updates the line on the WO parts list by scaling the requested qty with the UOM conversion to primary!
Example: Define an item for Oil, primary UOM is LT (litres), purchasing and component UOM is DR (drums).
Specify a cost (in LT) for this item of say $2/LT and a conversion factor of LT - DR of 1 - 200.
So we are stocking our oil in LT at $2/LT but purchasing it and putting it on workorders in DR at $400 a drum with 200 LT to 1 DR.
In our scenario, put 2 DR on a parts list in P13700 and save. The system calculates on the parts list an "Estimated (unit) Cost" of $2 but that makes no sense on a line with a UOM of DR ! It correctly puts the extended cost at $800.
Now for the worst part: Press the "Create Purchase Order" button.
It creates a purchase order for 2 DR at unit cost $4 and extended cost $8 !!!
And then it updates the Qty on the workorder parts list line down by the conversion factor to 0.005 DR !!!
This seems to be a bug. If I put it on a workorder for 2 drums I want it to stay there at 2 drums!
So, my good JDE friends... am I missing something? Is this a bug or not and has anyone else encountered this? Found a workaround or coded a fix?
My customer insists they want it to work the way they expected, and want me to modify the code to suit as they can't wait on Oracle to fix it. Have taken a look and the solution does not look all that easy.
Thanks in advance for any comments!
Cheers
JohnO
