Comment 17 for bug 452854

@Joël
well, now I see that there is at least reasonable idea of solving this :). Even though I do not see why this could not be fixed now, as this does not change any interfaces or API. System is completely ready for this, it could be done inside one function, without affecting external interfaces.

In other systems this is working behind the scenes fully automatic, there is no user interaction required at all. There is just another movement entry created to balance existing entries.

This even does not break existing movements, as we are changing neither object structure, nor introducing new objects (classes).

Actually this could be done by the user himself, he can create those records manually, right?

Anyway there should not be any change done for this, if we are not implementing correct functionality, as there should not be price_accuracy present in this function. To my opinion price_accuracy should be eliminated at some point as this is simplified approach to the the problem throughout the system, because calculation accuracy are not the same all over the functionality in system. In different parts it should be different, probably set as default property for each module (functionality).

P.S. I have not been reading your blueprint, I will read it and post comments on it a bit later.

best regards...