79a4b457b0e5502181bae7190855966eb0a4fcc9
The headline and the new backfill step were current, but step 11 and "what this will not fix" still carried pre-backfill figures. The backfill did not just change the totals — it changed step 11's population. Before it, nine records held refunds dated before their own first order: 660 refunds worth $15,237.02. Seven of those were shared-location twins whose refunds only looked orphaned because their orders had never been imported; replaying the window gave them their orders and the refunds stopped predating them. Two are left, and they are a different case — neither shares a Square location, so there is no twin holding the other half: NG4S first order 2026-05-29 79 refunds $2,180.08 10 days NGPS first order 2026-05-26 81 refunds $2,167.60 7 days Step 11 now recommends trying backfill-history on them first, with a window reaching back before their first order, since that is exactly what resolved the other seven. "What this will not fix" re-measured: 122 days / $2,379.45, of which 106 are real trading days ($1,151.80) and 16 are refunds with no sales imported ($1,227.65). Only 3 of the trading days are on shared-location records, all already diagnosed. The other 103 days and $502.96 have been identical in every run of this analysis — deactivated, live, and backfilled — and are the floor this work reaches. Also adds the backfill's ~5.9 hour runtime to the up-front table, and notes that "two entities per Square object" holds automatically for new imports but needs step 5 for existing history. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
Languages
Clojure
91%
CSS
4.2%
Sass
2.3%
HTML
1.2%
HCL
0.4%
Other
0.7%