When changing the UOM in an orderline will not change the price field. While that's no problem if the price leaves unchanged it will usually lead into a problem if the price is changed. As example selling a sixpack instead of 'each'. The user will see the price for a single item and therefore enter the reduced price for a single item. But the calculation takes this as price for the sixpack. It's correctly mentioned in the help window that the price is based on the currently selected UOM but nobody reads this.
In my tests this is behaving inconsistently.
Tested adding one line to a Sales Order already created and prepared, the price didn't change.
Tested adding one line to a totally new Sales Order, and the price changed correctly when I changed the UOM.
Tested using Sales Order - business partner C&W - product Elm - UOM 6-Pack
Strangely, I repeated the tests today and I was not able to reproduce the issue.
Elm - changing from each to 6-pack
Tested with a new order, worked
Tested with an old order new line, worked
Tested with an old order reactivated, worked
If you find a way to reproduce the issue, please add it here.
I had several tests with the elm tree using a already defined ‘unidad’ which was set to 6 times of each. Even after adding the reverse conversion, which was missing first, I got unchanged price field when changing the uom. Then, to write my posting more clearly I created a uom ‘sixpack’ and created the necessary conversions. Now when creating a new order with an elm line I first had to refresh the list of the uom field to see the sixpack and indeed the price changed when changing the uom. Than I took an old order with a new elm line and the price kept untouched when changing the uom. Even after requering the list.
The difference I observed: when creating a new line in the old order the uom field was set to each before entering elm while in the new order the field was empty an red surrounded.
Ok, it has nothing to do with old or new order, but with C&W or Seed Farm Inc. Seed Farm has a discount schema entered, which does not exists, removing this helps, entering an existing discount scheme let the error reappear. So AFAICS the set discount scheme triggers the unchanged price.