unit_price field in stock.move is limited by “price_digits”. This is not a problem for sale or purchase moves as the unit price comes from the corresponding sale or purchase which also uses “price_digits”.
However, on productions it is different because the unit_price comes from the operation:
unit_price = round_to_price_digits(total_production_cost / output_quantity)
When the account move for the output move is created, we compute unit_price * quantity which carries an error due to the rounding. This means that after the production is finished the value of our stock may be higher (or lower) than it was before the production when it should actually be the same (considering no operations are being added).
There is currently no way to avoid that. The only thing that can be done is minimize the problem by increasing price_digits, which results in more digits in sales, purchases and invoices (which in turn get printed in documents, etc).
But it seems to me that it should be possible to allow a different number of digits in stock.move unit_price without increasing the digits in other prices in the system and that it should cause no problems.
Or if we’re worried about the fact that the number of digits in sale and purchase moves is different from the ones in sale and purchase lines, we could make a PYSON expression + function field which limits the digits for those cases only.
Thoughts?