@blamejs/blamejs-shop 0.4.117 → 0.4.118

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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.
+
 - v0.4.117 (2026-06-26) — **Weighted-average COGS reports reconstruct each sale's cost exactly, with no penny drift.** The weighted-average cost-of-goods-sold attribution stored a per-unit cost rounded to the nearest minor unit on each attribution row. The COGS reports (per-order and per-period) recover each line's cost as quantity times that per-unit price — there is no stored line total — so the residual attribution row, whose quantity does not always divide its cost evenly, reconstructed a total that differed from the cost the sale itself recorded, by up to one minor unit per multi-unit residual row. The drift could be a gain or a loss and accumulated across every weighted-average sale into the per-order profit figure and the period COGS report. Each attribution now splits a debit whose cost does not divide evenly into a floor-priced remainder and a ceil-priced sliver, so quantity times unit price summed over the rows reproduces the sale's cost exactly. FIFO and LIFO costing, and weighted-average debits that divide evenly, are unchanged. **Fixed:** *Weighted-average COGS attribution no longer drifts from the sale's recorded cost* — A weighted-average sale records the cost it consumes, then writes per-layer attribution rows the COGS reports sum back up. The attribution stored a single integer per-unit price, rounded — and because the reports reconstruct each row as quantity times that price (there is no stored line-total column), the residual-bearing row reconstructed quantity-times-rounded-unit, which differs from the attributed cost whenever the quantity does not divide it evenly (for example three units carrying a cost of 23 stored 8 per unit and reconstructed 24). A debit whose cost does not divide evenly across its units is now split into a floor-priced remainder and a ceil-priced sliver — (quantity minus r) units at the floor price and r units at the floor-plus-one price, where r is the leftover — so the rows reconstruct the attributed cost exactly. The per-order and per-period COGS reports now equal the cost each sale recorded; layer reversal restores the same quantity and value.
 
 - v0.4.116 (2026-06-26) — **Sales-tax filings net partial refunds and derive owed tax from the jurisdiction's default rate.** Two correctness fixes to the sales-tax filing computation. A partial refund leaves its order in a paid / fulfilling / shipped / delivered status (there is no partially-refunded state), so the order still counts toward the filing for the period it sold in — but the filing counted the order's FULL tax and subtotal, ignoring the refunded portion, which over-stated collected tax and the amount remitted to the authority. A partial refund recorded inside the filing window now reduces that order's contribution to net taxable sales and net collected tax, apportioned across tax and subtotal by the order's own grand-total structure. Separately, the owed re-derivation attributed every order to the first rate row covering its date regardless of category, so a reduced category rate (e.g. food) defined alongside the jurisdiction's default rate in the same window could be applied to all revenue — and which rate won depended on the database's row order, making the owed figure wrong and non-deterministic. The owed re-derivation now models the jurisdiction's default (category-less) rate only; the collected figure still reflects the actual per-order tax each order was charged at its own rate. **Fixed:** *Partial refunds are netted out of a sales-tax filing instead of counting full tax* — A partial refund is recorded as a same-status order transition that does not change the order's status, subtotal, or tax columns, so the order remained in the filing with its pre-refund tax and subtotal counted in full — over-stating collected tax and over-remitting. computeFiling now sums the partial refunds recorded inside the filing window per order and nets each order's taxable subtotal and collected tax by the refunded share, apportioned across tax and subtotal by the order's grand total (half-even, integer minor units). Refunds are attributed to the period they occur in; an order with no in-window refund is unaffected, and recomputing a filing is idempotent. · *Owed tax is re-derived from the jurisdiction's default rate, deterministically* — The owed re-derivation took the first tax-rate row covering an order's date with no regard for category. Because a category-specific rate (such as a reduced food rate) can legally coexist with the jurisdiction's default rate in the same window, whichever row the database returned first claimed all revenue — yielding a wrong owed figure that flipped with the database's row order. The re-derivation now selects only the jurisdiction's default (category-less) rate, so the owed figure is deterministic and modelled on the jurisdiction's primary rate. The collected figure is unchanged: it remains the sum of the actual tax each order was charged at its own category-aware rate at order time.

package/lib/affiliates.js

@@ -607,7 +607,20 @@ function create(opts) {
       if (patch.payout_method != null)     _set("payout_method",     _payoutMethod(patch.payout_method));
       if (patch.payout_address != null)    _set("payout_address",    _payoutAddress(patch.payout_address));
       if (patch.commission_kind != null)   _set("commission_kind",   effectiveKind);
-      if (patch.commission_value != null)  _set("commission_value",  _commissionValue(patch.commission_value, effectiveKind));
+      if (patch.commission_value != null) {
+        // Value supplied — validate against the effective kind and write it.
+        _set("commission_value", _commissionValue(patch.commission_value, effectiveKind));
+      } else if (patch.commission_kind != null) {
+        // Kind-only patch: re-validate the STORED value against the new kind
+        // so an over-cap combination is rejected (a flat amount, legal up to
+        // the 1e11 flat cap, switched to percent_bps where the cap is 10000 =
+        // 100%, throws here instead of silently persisting a runaway
+        // multiplier). Do NOT add commission_value to the SET list: writing
+        // the read-before value would clobber a concurrent value-only update,
+        // and when the (re)validation passes the stored value is already
+        // correct for the new kind, so it is left untouched.
+        _commissionValue(Number(current.commission_value), effectiveKind);
+      }
       if (patch.attribution_window_days != null) _set("attribution_window_days", _attributionWindow(patch.attribution_window_days));
 
       var ts = _now();

package/lib/asset-manifest.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.117",
+  "version": "0.4.118",
   "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": {