From 74a070e545407cb2cf398b5855bb8249bc78c5aa Mon Sep 17 00:00:00 2001 From: Bryce Date: Sat, 15 Aug 2026 15:46:30 -0700 Subject: [PATCH] docs(sales-summaries): state how much of the re-key is actually finished MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The report implied the shared-payment problem was solved. Measuring the whole database shows it is solved for refunds, payouts and shifts, and 1.6% solved for card payments: refunds 51,986 scoped · 0 unscoped payouts 144,652 scoped · 0 unscoped · 36 with no owner cash-drawer shifts 69,291 scoped · 0 unscoped card payments 259,763 scoped · 14,241,890 unscoped · 2,122,161 no owner Sampling 2% of the orders belonging to every client that has ever contended found 12,954 payments still owned by two orders, extrapolating to roughly 650,000 across that population. So the balance figures are what the calculation fixes are worth on data where the sharing had been resolved for the clients and period measured — not a claim that the database is clean. The report now says so, and the headline stat that claimed zero shared payments has been replaced with the 1.6% actually renamed. Records what finishing requires: renaming is driven from orders, so it means walking all 19,040,296 of them rather than the clients that look shared today, since nine pairs contended in the past without sharing a location now. Measured at ~15,000 orders/hour once the 29 GB database stopped fitting in memory — the same code did 267,012 in 100 seconds with a warm cache — so it belongs in a maintenance window on sized hardware. It is resumable and a second pass is a no-op. Co-Authored-By: Claude Opus 5 --- .../2026-08-15-thirty-day-reconciliation.html | 62 ++++++++++++++++++- 1 file changed, 61 insertions(+), 1 deletion(-) diff --git a/docs/2026-08-15-thirty-day-reconciliation.html b/docs/2026-08-15-thirty-day-reconciliation.html index 03fd3cbb..952efcd7 100644 --- a/docs/2026-08-15-thirty-day-reconciliation.html +++ b/docs/2026-08-15-thirty-day-reconciliation.html @@ -120,7 +120,7 @@
1,172client-days brought into balance
0days knocked out of balance
97.3%of the variance removed
-
0shared payment records left
+
1.6%of card payments renamed so far
@@ -457,6 +457,66 @@
+
+

How complete is this, really

+
+

The importer deliberately understands both the old and new record names, so the change can + be deployed before the renaming finishes. That tolerance is a bridge, not a destination — + while any record still carries an unscoped name, two clients can still land on it, and the + guarantee rests on a convention rather than on the data.

+

Measuring the whole database rather than the part that was migrated gives an honest + picture, and it is not a flattering one.

+
+
+ + + + + + + + +
Record typeClient-scopedStill unscopedNo owner to scope by
Refunds51,98600
Payouts144,652036
Cash-drawer shifts69,29100
Card payments259,763 (1.6%)14,241,8902,122,161
+
+
+

Refunds, payouts and shifts are done. Card payments are not — the migration + described above covered the ten clients sharing a location today, within the reporting window, + which is 1.6% of them. And sampling 2% of the orders belonging to every client that has + ever contended found 12,954 payments still owned by two orders, which + extrapolates to roughly 650,000 across that population.

+

So the correct reading of the balance figures earlier in this report is: they are what the + calculation fixes are worth, measured on data where the sharing had been resolved for the + clients and period in question. They are not a claim that the whole database is clean.

+
+ +
+ What finishing it requires +

Renaming has to be driven from orders, because a payment's rightful owner is whichever order + refers to it — so completing it means walking all 19,040,296 orders, not just the clients that + look shared today. Nine client pairs contended in the past without sharing a location now, and + a migration scoped to the current configuration misses every one of them.

+

On the test machine this ran at roughly 15,000 orders an hour once the database no longer + fitted in memory, which puts a full pass in days rather than hours. That is a hardware + characteristic of a swapping 29 GB restore, not a property of the work: the same code + completed 267,012 orders in 100 seconds when the cache was warm. It belongs in a maintenance + window on properly sized hardware, and it is resumable and safe to re-run — a second pass over + already-renamed records does nothing at all.

+
+ +
+

The finish line is measurable, not a judgement call. + unscoped-report counts, for every record type, how many names are client-scoped, + how many are still unscoped, and how many have no owner. Two things follow from it:

+
    +
  • While the unscoped count is above zero, keep the importer's understanding of both name + forms. Removing it early would strand every record that had not yet been renamed.
    • +
  • Once it reaches zero and stays there across a full import cycle, delete the fallback. + At that point two clients sharing a location is structurally incapable of producing a shared + record, rather than merely unlikely to.
    • +
+
+
+

Decisions and risks still open