@blamejs/blamejs-shop 0.4.114 → 0.4.115

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.115 (2026-06-26) — **Adding a bundle with a multi-quantity member no longer charges above the advertised bundle price.** A bundle's discounted price is split across its members and stored as a single integer per-unit price on each cart line, so a member's realized cost is its quantity times that per-unit price. When a member's quantity is greater than one and its allocated share is not divisible by that quantity, the leftover cents could not be returned without raising the per-unit price by a whole quantity-step — and the allocator did exactly that, pushing the realized cart subtotal a few cents ABOVE the bundle price the customer saw on the product page. The allocation now returns leftover cents only in whole quantity-steps and leaves any final sub-step residual off, so the realized subtotal is at most the advertised bundle price, never above it (a residual of fewer than the member's quantity in cents is dropped in the customer's favour in the cases a single integer per-unit price cannot represent exactly). Bundles whose members are all single-unit, and bundles whose discounted allocation divides evenly, are unaffected. **Fixed:** *Bundle with a quantity-greater-than-one member never charges above the quoted price* — The bundle-to-cart allocation converts each member's share of the discounted bundle price into a single integer per-unit price (floor) and returns the cents lost to that floor. A single-unit member absorbs the shortfall exactly; otherwise the cents are returned in whole quantity-sized steps. The final sub-step residual — strictly fewer cents than any remaining member's quantity — was being recovered by bumping a multi-unit member's per-unit price up by one, which raised that line's total by a whole quantity-step and pushed the realized subtotal above the quoted bundle price. That residual is now left off instead: the realized subtotal is at most the advertised price (a sub-quantity-cent undercharge in the customer's favour when an integer per-unit price cannot land on the quote exactly), and never exceeds it.
+
 - v0.4.114 (2026-06-26) — **A mid-cycle subscription downgrade now issues the proration credit the customer is owed instead of dropping it.** When a subscription plan changed mid-billing-period to a cheaper plan, the credit for the outgoing plan's unused time exceeded the incoming plan's partial-period charge — and that net credit was silently discarded. The proration adjustment is recorded as a single invoice whose amount is the net of charge minus credit, and a negative net (the downgrade case) was clamped to zero with no mechanism to apply the remainder, so the customer lost the money they were owed. A mid-cycle downgrade now issues that owed credit to the customer's store-credit ledger. The plan-change component takes an optional storeCredit handle for this; when a downgrade owes a credit and no handle is wired, the change is refused (an immediate change throws before any state changes) or left pending (a scheduled change is skipped and retried on a later sweep) rather than applied with the credit lost. Upgrades and same-price changes are unchanged. **Fixed:** *Mid-cycle plan downgrade credit is issued to store credit, not dropped* — A subscription plan change splits the proration into a charge (billed through the invoice ledger) and a credit (the unused remainder of the outgoing plan). For a downgrade the credit exceeds the charge, and the invoice — which can only carry a charge — clamped the negative net to zero, so the owed remainder was silently lost. The plan-change component now issues that remainder (proration credit minus the partial-period charge) to the customer's hash-chained store-credit ledger, correlated to the change that produced it and gated on the same atomic transition claim that prevents double application. The credit is settled as part of winning that claim: if the store-credit write fails (a transient error), the plan transition is rolled back and the change is left reclaimable so a retry settles it cleanly — the credit is never finalized as lost. The proration invoice still records the (zero) charge, so a downgrade never overcharges. · *A downgrade with no credit vehicle is refused, not applied with the credit lost* — The plan-change component accepts an optional storeCredit handle. When a downgrade owes a credit but no handle is wired, an immediate change is refused before any row is written or plan transition is applied (the call throws), and a scheduled change is left pending and retried on a later sweep once a handle is available — never transitioned with the credit dropped. Operators composing the plan-change component should wire the store-credit handle to enable mid-cycle downgrades.
 
 - v0.4.113 (2026-06-26) — **VAT-ID validation and EU reverse-charge now handle Greece's EL prefix and Switzerland's CHE prefix correctly.** Two related correctness fixes in the tax module's VAT handling. The bare VAT number returned by validateVatId was corrupted for Greek and Swiss IDs: it dropped the leading digit of a Greek number when the caller passed the ISO code "GR", and it left a stray "E" on a Swiss number — because the prefix was guessed by length instead of taken from the registry's actual prefix (Greece files its EU VAT under "EL", Switzerland under "CHE"). Separately, the intra-EU B2B reverse charge was always denied to Greek parties: the country was derived from the VAT-ID prefix ("EL") and checked against the EU member list, which is keyed by the ISO code ("GR"), with no alias normalization — so a Greek buyer or seller was treated as non-EU and charged standard VAT where EU law requires 0% with reverse charge. Both paths now canonicalize the EL/GR alias and strip the exact registry prefix. Every other country, and a genuine VAT-ID/country mismatch, behaves exactly as before. **Fixed:** *EU reverse-charge is no longer wrongly denied to Greek (EL) VAT IDs* — applyReverseCharge derives a party's country from the first characters of its VAT ID. Greek EU VAT IDs carry the prefix "EL" while Greece's ISO 3166-1 code is "GR", and the EU-membership check is keyed by ISO code — so a Greek seller, or a Greek buyer (whether the country was supplied as "GR" or "EL"), was classified as non-EU and refused the reverse charge, causing standard VAT to be invoiced on a transaction where EU law requires 0% with the buyer self-assessing. The derived prefix and the declared country are now canonicalized (EL is treated as GR) before the EU-membership and prefix-match checks. A genuine mismatch — a non-Greek VAT ID declared against a GR country, or vice versa — is still refused. · *validateVatId returns the exact bare number for Greek (EL) and Swiss (CHE) IDs* — The bare VAT number was produced by guessing the prefix length (2 vs 3 characters) rather than using the registry's actual prefix. For a Greek ID queried under the ISO code "GR" this dropped the first digit of the number; for a Swiss "CHE…" ID it left the "E" attached. The prefix is now taken from the registry — "EL" for Greece (ISO "GR"), "CHE" for Switzerland (ISO "CH"), and the two-letter ISO code for every other registry — so the returned number that prints on a reverse-charge invoice is exact. IDs whose registered number itself begins with letters (Austria's U, France's two-character lead, Spain's alphanumeric) are unaffected.

package/lib/asset-manifest.json

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

package/lib/storefront.js

@@ -21208,10 +21208,17 @@ function mount(router, deps) {
       // Convert each member's line allocation to a uniform integer per-unit
       // price (floor) and tally the cents lost to that floor across all
       // lines. A single-unit line (the usual bundle shape) absorbs the whole
-      // shortfall exactly; failing that, the cents are returned in qty-sized
-      // steps to the smallest-quantity lines, with any final sub-step residual
-      // rounded up onto the smallest line — so the realized subtotal is never
-      // below the quoted bundle price.
+      // shortfall exactly. Otherwise the cents are returned only in whole
+      // qty-sized steps (each step is a per-unit +1 on a line, i.e. exactly
+      // that line's quantity in cents), smallest-quantity lines first. A
+      // final sub-step residual — strictly less than every remaining line's
+      // quantity — CANNOT be returned without bumping a multi-unit line's
+      // per-unit price, which would raise that line's realized total by a
+      // whole quantity-step and push the realized subtotal ABOVE the quoted
+      // bundle price the customer saw on the PDP. That residual is left off:
+      // the realized subtotal is at most the quote, never above it (a
+      // ≤ (min member qty − 1)-cent undercharge in the cases the integer
+      // per-unit price cannot represent exactly — favouring the customer).
       var lostCents = 0;
       for (var u = 0; u < members.length; u += 1) {
         var me = members[u];
@@ -21225,10 +21232,34 @@ function mount(router, deps) {
         if (single) {
           single.unit += lostCents;
         } else {
-          for (var g = 0; g < byQty.length && lostCents > 0; g += 1) {
-            while (lostCents >= byQty[g].qty) { byQty[g].unit += 1; lostCents -= byQty[g].qty; }
+          // Each whole step (a +1 on a member's per-unit price) returns
+          // exactly that member's quantity in cents. Recover the MOST cents
+          // possible WITHOUT exceeding lostCents — a greedy pass can strand
+          // cents a different member would recover exactly (quantities 5 and
+          // 7, residual 7: bumping the qty-7 line is exact, but spending 5 on
+          // the qty-5 line first leaves an unrecoverable 2). This is bounded
+          // coin-change over the member quantities: reach[v] holds a per-line
+          // bump-count vector summing to exactly v cents, or null if v is not
+          // reachable. The largest reachable v ≤ lostCents is applied; any
+          // remainder below the smallest reachable step is genuinely
+          // unrepresentable with one integer per-unit price and is dropped in
+          // the customer's favour — never bumped up past the quoted price.
+          var reach = new Array(lostCents + 1);
+          reach[0] = byQty.map(function () { return 0; });
+          for (var v = 1; v <= lostCents; v += 1) {
+            reach[v] = null;
+            for (var c = 0; c < byQty.length; c += 1) {
+              if (byQty[c].qty <= v && reach[v - byQty[c].qty]) {
+                reach[v] = reach[v - byQty[c].qty].slice();
+                reach[v][c] += 1;
+                break;
+              }
+            }
           }
-          if (lostCents > 0) { byQty[0].unit += 1; lostCents = 0; }
+          var bestSum = lostCents;
+          while (bestSum > 0 && !reach[bestSum]) bestSum -= 1;
+          var bumps = reach[bestSum] || byQty.map(function () { return 0; });
+          for (var g = 0; g < byQty.length; g += 1) byQty[g].unit += bumps[g];
         }
       }
 

package/package.json

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