Subversion Repositories SmartDukaan

Last modification

• Rev 37612 2026-09-13 02:37:36
• Author: amit

• Log message:

  Value an internal PO's cart the same way the transaction validates it
  
  Creating an internal PO failed with "Cart Value-Payment value mismatch" whenever a line
  carried paise and the quantity was more than a handful. Two places were computing the same
  cart total from the same stored float through two different decimal conversions, so they
  disagreed on the value of prices binary cannot hold exactly.
  
  createOrderInternally read WarehouseLineItem.unitPrice through String.valueOf, which
  resolves a float via Float.toString and yields 10499.99, while createTransactionForWarehouse
  re-values the persisted cart lines with BigDecimal.valueOf, which widens that same float to
  double and yields 10499.990234375. The per-unit gap is around two ten-thousandths of a rupee;
  quantity multiplies it, and it crosses the 0.001 tolerance the validator allows at a quantity
  of five. Round prices are exact in binary and passed, which is why this looked intermittent
  rather than total - across randomised carts the old arithmetic disagreed 98% of the time.
  
  The total is no longer computed in its own loop. It is derived from the cart items that are
  about to be written, using the conversion and the line-inclusion rule the validator applies,
  so both sides are the same function over the same rows and cannot drift apart. That also
  brings across two rules the PO side never had: quantities of zero or less, which
  addItemsToCart drops and which therefore never reach the validated total, and the one paisa
  carry bag, which the validator treats as a marker line rather than a billed one. Either of
  those reaching an internal PO would have failed it outright, and a carry bag is only a
  rounding error away from the paisa-per-unit pricing used for FOC stock.
  
  The wallet top-up still truncates the total to whole rupees, and now lands within a rupee of
  where it did before, well inside the twenty rupee buffer it already carried. Nothing outside
  internal PO creation is touched: the validator, bulk orders and the refurb split keep their
  existing numbers, and the wallet debit is driven by the order totals, not by this value.