@blamejs/blamejs-shop 0.4.119 → 0.4.121

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.121 (2026-06-26) — **Vendor-invoice reconciliation values each PO line at its own cost, and a vendor's invoices must share one currency.** Two fixes to vendor-invoice reconciliation and reporting. When the same SKU appeared on more than one purchase order at different unit costs, reconcileAgainstPOs summed the received quantity across the POs but valued all of it at the LAST PO's unit cost, inflating the PO received value and corrupting the over-billing variance the operator relies on to catch a vendor over-bill before paying. Each PO line is now valued at its own unit cost and accumulated, so the received value and the variance are exact, and the per-unit figure shown in the line variance is a true weighted mean. Separately, a vendor's invoices may now only be recorded in one currency: the accounts-payable aging report and the vendor scorecard sum amounts per vendor into a single figure, which is meaningless across currencies, so an invoice whose currency differs from the vendor's existing invoices is refused at write time rather than silently producing an incommensurable total. **Fixed:** *PO reconciliation values each purchase-order line at its own unit cost* — reconcileAgainstPOs aggregated purchase-order lines per SKU, accumulating the received quantity across POs but overwriting the unit cost with each successive PO's — so when the same SKU was received on two POs at different prices, the received value was computed as the combined quantity times the last PO's cost. That inflated po_received_value_minor and the variance the operator uses to spot a vendor over-bill before payment. Each PO line is now valued at its own unit cost and the values accumulated, so the received value and variance are exact; the line-variance's per-unit cost is reported as the true weighted mean of the received value. · *A vendor's invoices must all be recorded in the same currency* — The accounts-payable aging report and the vendor scorecard sum each vendor's invoice amounts into a single figure, which is only meaningful within one currency — mixing currencies produced an incommensurable total with no currency tag to unwind it. Recording an invoice whose currency differs from the vendor's existing invoices is now refused with a clear error, so those per-vendor totals stay within a single currency by construction.
+
+- v0.4.120 (2026-06-26) — **Splitting a discount across order lines no longer rounds a line's share negative.** When an order-level discount is allocated across the order's lines (proportionally, equally, or by quantity), each line's share was rounded independently with half-even rounding. Independently rounded shares can sum to MORE than the discount, which drove the leftover remainder negative and produced a negative discount on one line — and the checkout recorder, which rejects a negative share, then dropped the whole allocation breakdown, leaving nothing for a later per-line partial refund to draw on. Reversing an allocation for a refund had the same flaw and could persist a negative per-line refund (a charge-back on that line). The split now composes the framework's largest-remainder allocator: it floors each share and hands out the non-negative leftover one minor unit at a time, so every line's share is non-negative, the shares sum to the discount (or the refund) exactly, and no breakdown is dropped. The only visible change is which line absorbs a leftover cent — now the line with the largest fractional remainder rather than the highest subtotal. **Fixed:** *Per-line discount and refund shares are floored and distributed, never rounded negative* — The per-line discount split rounded each share half-even and independently, so the rounded shares could sum above the discount, send the remainder negative, and assign a negative discount to one line; the checkout path then dropped the breakdown (its recorder refuses a negative share), so a subsequent per-line refund had no recorded allocation to subtract. The reverse path likewise could persist a negative per-line refund. Both now compose the framework's largest-remainder allocator, which floors each share and distributes the non-negative leftover one minor unit at a time to the largest remainders — every share is non-negative, the shares sum exactly to the total, and the allocation is recorded. The leftover cent now lands on the largest-remainder line instead of the highest-subtotal line.
+
 - v0.4.119 (2026-06-26) — **Vendored framework refreshed to 0.15.32.** Updates the vendored blamejs framework to 0.15.32, taking in the 0.15.31 and 0.15.32 upstream releases. Both are internal test-suite tooling only: they extend the framework's guard suite with a re-verification gate that retires renamed suppression-marker tokens (so a re-verified suppression class can't inherit a stale approval) and update the matching in-source marker comments. No runtime code, public API, or wire format changed upstream, so there is no runtime or behavior change for this storefront and no operator action is required. **Changed:** *Vendored framework refreshed to 0.15.32* — Refreshes the vendored blamejs framework to 0.15.32 (taking in 0.15.31 and 0.15.32), upstream releases scoped to test-suite tooling — a re-verification gate for renamed suppression markers and the matching marker-comment updates. The shipped framework runtime, public API, and wire format are unchanged, so no operator action is required.
 
 - v0.4.118 (2026-06-26) — **Changing an affiliate's commission kind now revalidates the commission value against the new kind's cap.** An affiliate's commission value is validated against its kind's ceiling when it is set: a percentage commission is capped at 100% (10000 basis points), while a flat per-order amount may be far larger. Changing only the commission kind — without resupplying the value — skipped that revalidation. Switching a flat per-order amount to a percentage therefore left the large flat value in place as a percentage rate: a $500-per-order flat amount became a 5,000,000% rate that computes a runaway commission on the next recorded order and feeds it straight into the pending-payout total. Updating the commission kind now revalidates the effective commission value (the resupplied one, or the stored one) against the new kind, so a change that would push the value over the new kind's cap is rejected with the same error as setting it directly, instead of being silently persisted. **Fixed:** *An affiliate commission-kind change revalidates the stored value against the new kind's cap* — Updating an affiliate re-checked the commission value against the (possibly new) kind's cap only when the value itself was part of the same update. A kind-only change left the stored value untouched and unvalidated, so switching a flat per-order amount to a percentage kept a value that is legal as a flat amount (up to the large flat ceiling) but thousands of times over the 100%-basis-point percentage cap — producing a grossly inflated commission on the next order and an inflated pending payout. The update path now revalidates the effective commission value against the effective kind whenever either the kind or the value changes, rejecting an over-cap combination rather than persisting it.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.119",
+  "version": "0.4.121",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

package/lib/discount-allocation.js

@@ -181,18 +181,18 @@ function _validateLines(lines) {
 
 // ---- allocation math (pure) --------------------------------------------
 
-// Compute the per-line share via b.money's half-even rounded multiply.
-// Given total `T`, weights `[w0, w1, ...]` summing to `W`, each share
-// is `floor_half_even(T * wi / W)`. The shares may sum to slightly
-// less than `T` (rounding gives back fractions); the remainder is
-// applied to the line with the highest subtotal so the audit row's
-// `allocated_minor` values sum exactly to `T`.
+// Compute the per-line share of `total` via b.money's largest-remainder
+// allocator. Each share is `floor(total * wi / W)`, and the non-negative
+// leftover is handed out one minor unit at a time to the lines with the
+// largest fractional remainders, so the `allocated_minor` values sum to
+// `total` EXACTLY and none is ever negative.
 //
-// "By quantity" weights use quantity; "equal" weights every line by
-// `1` (so the share is `T / N` rounded); "by_subtotal" /
-// "proportional" weight by subtotal. The remainder placement is
-// always by highest subtotal — the operator's "the biggest line
-// absorbs the cent" mental model holds for every kind.
+// "By quantity" weights use quantity; "equal" weights every line by `1`
+// (so each gets `total / N` floored, leftover spread); "by_subtotal" /
+// "proportional" weight by subtotal. Composing the framework allocator
+// instead of independently rounding each share is what keeps the split
+// conservation-safe — a per-line half-even round can sum above `total`
+// and force a negative share, which this avoids by construction.
 function _shares(total, lines, kind) {
   var weights = new Array(lines.length);
   var sumWeight = 0n;
@@ -220,32 +220,18 @@ function _shares(total, lines, kind) {
     }
   }
 
-  var money = b.money;
-  var totalMoney = money.fromMinorUnits(BigInt(total), ROUNDING_CURRENCY);
+  // Compose b.money's largest-remainder allocator: it floors each share and
+  // distributes the (always non-negative) leftover one minor unit at a time
+  // to the largest fractional remainders, so the shares sum to `total`
+  // EXACTLY and none is ever negative. The prior hand-rolled half-even
+  // multiply rounded each share independently and could push their sum ABOVE
+  // `total` — driving the remainder negative and a line's share below zero.
+  var allocated = b.money
+    .fromMinorUnits(BigInt(total), ROUNDING_CURRENCY)
+    .allocate(weights);
   var shares = new Array(lines.length);
-  var allocated = 0n;
   for (var j = 0; j < lines.length; j += 1) {
-    var share = totalMoney
-      .multiply([BigInt(weights[j]), sumWeight])
-      .toMinorUnits();
-    shares[j] = share;
-    allocated += share;
-  }
-
-  // Place the rounding remainder (positive or negative) on the line
-  // with the highest subtotal_minor. Ties broken by original index so
-  // the placement is deterministic across runtimes.
-  var remainder = BigInt(total) - allocated;
-  if (remainder !== 0n) {
-    var bestIdx = 0;
-    var bestSubtotal = lines[0].subtotal_minor;
-    for (var m = 1; m < lines.length; m += 1) {
-      if (lines[m].subtotal_minor > bestSubtotal) {
-        bestSubtotal = lines[m].subtotal_minor;
-        bestIdx = m;
-      }
-    }
-    shares[bestIdx] = shares[bestIdx] + remainder;
+    shares[j] = allocated[j].toMinorUnits();
   }
   return shares;
 }
@@ -409,10 +395,9 @@ function create(opts) {
 
   // Reverse-walk an allocation: given a refund amount, distribute it
   // across the original breakdown proportional to each line's
-  // `allocated_minor`. Half-even rounding via b.money; the rounding
-  // remainder lands on the line with the largest original allocation
-  // (the same "biggest line absorbs the cent" rule applied to the
-  // reverse direction).
+  // `allocated_minor`, via the same b.money largest-remainder allocator
+  // as the forward split — so the per-line refund shares sum to `refund`
+  // exactly and none is negative.
   function _reverseShares(refund, breakdown) {
     var weights = new Array(breakdown.length);
     var sumWeight = 0n;
@@ -430,28 +415,17 @@ function create(opts) {
         sumWeight += 1n;
       }
     }
-    var money = b.money;
-    var refundMoney = money.fromMinorUnits(BigInt(refund), ROUNDING_CURRENCY);
+    // Same largest-remainder allocator as the forward split: floors each
+    // share and hands out the non-negative leftover unit-by-unit, so the
+    // per-line refund shares sum to `refund` exactly and none is negative
+    // (the prior half-even multiply could overshoot and persist a negative
+    // per-line refund — effectively a charge-back on that line).
+    var allocated = b.money
+      .fromMinorUnits(BigInt(refund), ROUNDING_CURRENCY)
+      .allocate(weights);
     var shares = new Array(breakdown.length);
-    var allocated = 0n;
     for (var j = 0; j < breakdown.length; j += 1) {
-      var share = refundMoney
-        .multiply([BigInt(weights[j]), sumWeight])
-        .toMinorUnits();
-      shares[j] = share;
-      allocated += share;
-    }
-    var remainder = BigInt(refund) - allocated;
-    if (remainder !== 0n) {
-      var bestIdx = 0;
-      var bestAlloc = breakdown[0].allocated_minor;
-      for (var m = 1; m < breakdown.length; m += 1) {
-        if (breakdown[m].allocated_minor > bestAlloc) {
-          bestAlloc = breakdown[m].allocated_minor;
-          bestIdx = m;
-        }
-      }
-      shares[bestIdx] = shares[bestIdx] + remainder;
+      shares[j] = allocated[j].toMinorUnits();
     }
     return shares;
   }

package/lib/vendor-invoices.js

@@ -435,6 +435,33 @@ function create(opts) {
       }
     }
 
+    // Single currency per vendor: the AP aging report and the vendor
+    // scorecard sum amount_minor / paid_minor per vendor into one scalar,
+    // which is only meaningful within a single currency — mixing currencies
+    // would yield an incommensurable total with no currency tag to unwind it.
+    // Refuse a mismatched currency at write time rather than silently record
+    // one that corrupts those reports.
+    // Reject if ANY existing invoice for this vendor is in a different
+    // currency — not just a sampled one. An upgraded store may already hold
+    // mixed-currency rows (earlier releases allowed them); sampling a single
+    // row could match the new currency and let the mix grow, so probe for any
+    // `currency <> this` row. A vendor already carrying a mix is locked until
+    // the operator resolves it, which is the fail-closed behaviour the
+    // single-currency report invariant requires.
+    var mismatchCur = await query(
+      "SELECT currency FROM vendor_invoices WHERE vendor_slug = ?1 AND currency <> ?2 LIMIT 1",
+      [vendorSlug, currency],
+    );
+    if (mismatchCur.rows.length) {
+      var curErr = new Error(
+        "vendor-invoices.recordInvoice: vendor " + JSON.stringify(vendorSlug) +
+        " has an existing invoice in " + mismatchCur.rows[0].currency + "; this invoice is " +
+        currency + " — a vendor's invoices must share one currency",
+      );
+      curErr.code = "VENDOR_INVOICE_CURRENCY_MISMATCH";
+      throw curErr;
+    }
+
     var id = b.uuid.v7();
     var ts = _now();
 
@@ -745,16 +772,34 @@ function create(opts) {
       for (var k = 0; k < po.lines.length; k += 1) {
         var pl = po.lines[k];
         if (!poBySku[pl.sku]) {
-          poBySku[pl.sku] = { received_qty: 0, unit_cost_minor: pl.unit_cost_minor, currency: pl.currency };
+          poBySku[pl.sku] = { received_qty: 0, received_value_minor: 0, unit_cost_minor: 0, currency: pl.currency };
         }
-        poBySku[pl.sku].received_qty += Number(pl.quantity_received);
-        // If multiple POs cost differently for the same SKU, keep the
-        // weighted mean (operator-visible signal that the vendor
-        // changed pricing across orders).
-        poBySku[pl.sku].unit_cost_minor = pl.unit_cost_minor;
+        var recvQty = Number(pl.quantity_received);
+        poBySku[pl.sku].received_qty += recvQty;
+        // Value each PO line at its OWN unit cost and ACCUMULATE. The same
+        // SKU can legitimately appear on multiple POs at different prices, so
+        // a single per-SKU unit cost cannot represent the received value —
+        // the prior code summed quantity across POs but overwrote unit_cost
+        // with the last PO's, inflating the received value and corrupting the
+        // over-billing variance. The operator-visible weighted-mean unit cost
+        // is derived from this accumulated value below.
+        poBySku[pl.sku].received_value_minor += recvQty * pl.unit_cost_minor;
       }
     }
 
+    // Derive each SKU's operator-visible unit cost as the true weighted mean
+    // of its received value across all matched POs (floored to a whole minor
+    // unit). The VALUE math downstream uses received_value_minor directly so
+    // it stays exact; this per-unit figure is only for the line-variance
+    // display.
+    var poBucketKeys = Object.keys(poBySku);
+    for (var wm = 0; wm < poBucketKeys.length; wm += 1) {
+      var wmBucket = poBySku[poBucketKeys[wm]];
+      wmBucket.unit_cost_minor = wmBucket.received_qty > 0
+        ? Math.floor(wmBucket.received_value_minor / wmBucket.received_qty)
+        : 0;
+    }
+
     // Map invoice lines onto PO buckets. A line item without an `sku`
     // (service-line, freight) lands in unmatched_invoice_lines so the
     // operator can decide whether that bill component is a separate
@@ -796,7 +841,7 @@ function create(opts) {
         po_unit_cost:       poBucket.unit_cost_minor,
         qty_variance:       il.quantity - poBucket.received_qty,
         unit_cost_variance: il.unit_cost_minor - poBucket.unit_cost_minor,
-        total_variance:     il.total_minor - (poBucket.received_qty * poBucket.unit_cost_minor),
+        total_variance:     il.total_minor - poBucket.received_value_minor,
       });
     }
 
@@ -817,8 +862,7 @@ function create(opts) {
 
     var poReceivedValueMinor = 0;
     for (var s = 0; s < poBySkuKeys.length; s += 1) {
-      var bucket = poBySku[poBySkuKeys[s]];
-      poReceivedValueMinor += bucket.received_qty * bucket.unit_cost_minor;
+      poReceivedValueMinor += poBySku[poBySkuKeys[s]].received_value_minor;
     }
 
     return {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.119",
+  "version": "0.4.121",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {