I’m running into an issue with unit conversion on BOM pricing. There’s two issues, really.
I have a component product (CompA) which is priced per ton (Unit = Ton, Cost Price = 200).
I have a finished goods product (ProdA), and have created a BOM for it. This BOM contains 500 Pounds of CompA.
Additionally, I have two unit conversions set up: Tons = 2000 X Pounds, and Pounds = 0.0005 X Tons
When I calculate price, the code is taking my Price Per Ton ($200 / 1 Ton) and multiplying it by the quantity of my component (500 Pound). This returns a value of $100,000. Then, it applies the Ton to Pounds conversion, multiplying that value by a further 2,000, resulting in a final computed price of $200,000,000, when it should be a mere $50. This is easy enough to fix. Instead of doing:
BigDecimal costPrice = unitConversionService.convert(product.getUnit(), unit, product.getCostPrice().multiply(consumptionQty));
we should be doing this:
BigDecimal costPrice = product.getCostPrice().multiply(unitConversionService.convert( unit, product.getUnit(), consumptionQty, appProductionService.getNbDecimalDigitForBomQty()));
In effect, we should be converting the quantity first into the unit that the product defines its price in (alternatively, we should be dividing by the coefficient, not multiplying, but that’s nested down in the
unitConversionService, which we don’t want to handle this). However, this leads to a second problem. The coefficient to convert Pounds to Tons (0.0005) is returned in a
BigDecimal with a scale of
3, so we are truncating the coefficient to be
0.000. The model correctly defines the scale as being
12, and the database stores the coefficient correctly with a scale of
12. Further, the
Unit Conversions page correctly displays the coefficient as
0.000500000000. I’ve tried removing my Pound to Ton conversion (so the unit converter will invert the Ton to Pound conversion), but I run into the same issue.
The problem I need help with is determining where the coefficient is being truncated to a scale of only 3. The
UnitConversionRepo already has the coefficient stored with a scale of 3 (which incorrectly truncates my coefficient), and the
UnitConversionService#getInverseCoefficientScale is also not returning a large enough value.