Amarsir wrote:

OK I have the code open here so I can see the logic clearly. The simple answer is that changing the price is the easiest way to fix rounding errors. It shouldn't be a big change though.

Suppose you're selling 1000 units, price 250, qa100. We calculate and find that you need to sell 1100 units like that.

So we find a line in the warehouse with a bunch of units but qa 90. We take out 100. Then we mix that in to get 1100 units of qa 99.1.

The problem is that the first recalculation assumed qa100. Had it been done at qa99.1 the quantity would have been different. If we recalculated again at qa99.1 it would be a different number, which means a different merge, which means a different qa, and so on iteratively.

So to get around that we just shift the price instead. As I say it shouldn't be a big move. But if that's really bothering people we could probably find another way.

I must be missing something here....

Why would the first recalculation "assume" qa100 when the product was posted at qa45.75?

If I started the qa45.75 product at 60,000.00 for 24 hours, the units started should be enough at that point in time.

When you come back and "adjust" the mix, the product is still qa45.75 in the store AND the warehouse. If the quantity needs to be adjusted, there will be no merge required and no "rounding error" of 9%.

Why would the price need to be adjusted?