What happened

Luminous lets you define a unit-of-measure conversion rule per product (a SKU-level rule) so that one product can be purchased in cases of 12 while another is purchased in cases of 48 — both using a unit named "case" but with different conversion factors to your base inventory unit.

Before this fix, when calculating the shipped or billed quantity for a PO line, Luminous resolved the conversion factor by looking up all rules for that unit pair and picking the one belonging to the product with the most recently created rule — regardless of which product was actually on the line. This meant:

  • A line whose product had no SKU-specific rule would inherit the conversion factor of whichever other product happened to have the highest-numbered rule on that unit pair.
  • A line whose product had a SKU-specific rule with a smaller case size than another product's rule on the same pair would have its shipment overstated.
  • The Remaining to Ship and Remaining to Receive columns, and the Line Status filter (Partially Shipped, Shipped, etc.), were derived from the same incorrect figure.
  • The quantity_shipped and quantity_billed values returned by the API were affected in the same way.

Example: A product with no case-size rule of its own, purchased in the same unit as another product whose case size is 68, would show 20 cases shipped as 1,360 base units — because the wrong product's factor (68) was applied instead of a factor of 1.

Who was affected

This issue only affected tenants who:

  1. Had SKU-level (per-product) conversion rules defined — not just the system-wide rule.
  2. Had more than one product carrying a SKU-level rule on the same unit pair (same base unit and ordered unit).
  3. Had PO lines belonging to a product with a lower-numbered product ID than another product's rule on that pair, or belonging to a product with no rule at all on that pair.

Tenants using only system-wide conversion rules were not affected.

What is fixed

Luminous now resolves the conversion factor for each PO line using the following precedence — matching exactly how the conversion was applied when the PO was originally created:

  1. The line's own product's SKU rule (if one exists)
  2. The variant parent product's SKU rule (if the product is a variant child and the parent has a rule)
  3. The system-wide rule for that unit pair
  4. A factor of 1 (no conversion) if none of the above applies

This applies to shipped quantities, billed quantities, and all derived figures (Remaining to Ship, Remaining to Receive, line-status classification). The API values quantity_shipped and quantity_billed are also corrected.

What to do now

No action is required. The corrected figures are calculated in real time from your existing shipment and bill data — nothing needs to be re-submitted or recalculated.

If a PO was previously showing a badly wrong Shipped or Remaining quantity, reload the PO and the corrected figure will appear immediately.

If you believe historical receiving reports or bills were processed based on the wrong quantity, contact support to review whether any downstream records need attention.