Bryce 95d0537c69 feat(sales-summaries): refresh on a schedule, skipping accepted days
sales-summaries-v2 recomputes every dirty summary, but nothing set the dirty
flag on a schedule: mark-all-dirty was only ever called by hand from the
comment block, and the job was registered in neither server.clj's
INTEGREAT_JOB dispatch nor terraform/deploy.tf, so -main was dead code that
could never run in production. Summaries were only recalculated when someone
remembered to do it in the REPL, and POS data keeps arriving after a business
day closes, so a summary computed once on the day was routinely wrong and
stayed wrong.

Add a daily job that marks the trailing 7 days dirty and recomputes them,
leaving finished work alone. "Finished" is the condition the app already calls
Balanced -- debits equal credits and every line is mapped to an account. Since
that is derived rather than stored, a summary that later falls out of balance
is picked up again on the next run.

Extract the Balanced predicate into auto-ap.datomic.sales-summaries so the
grid's pill and the job share one definition, rather than a background job
requiring an SSR namespace. total-debits/total-credits resolve the ledger side
from either a plain keyword or the {:db/ident ...} map a pull returns, and
accepted? requires every item to declare a side: un-normalized pulled items
otherwise sum to 0.0 on both sides, read as balanced, and get skipped
silently and permanently.

Also fix sales-summaries-v2 destroying user-entered line items. It filtered
for :sales-summary-item/manual? to preserve them, but dirty-sales-summaries'
index-pull selector never fetched :sales-summary/items, so manual-items was
always empty. Because items is a component attribute upserted via
[:reset-rels ...], every recompute deleted the hand-entered lines -- often the
very lines that make a summary balance. Harmless while nothing ran on a
schedule; destructive the moment this does.

Register the job in the admin Background Jobs dropdown too, with a days
field: schedules are prod-only, so the admin page is the only way to run it
on staging.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 15:17:54 -07:00
2024-02-08 11:41:03 -08:00
2019-01-26 09:02:28 -08:00
2026-05-18 15:38:07 -07:00
2026-06-04 22:59:51 -07:00
2026-06-04 22:59:51 -07:00
2024-05-02 20:37:13 -07:00
2024-11-17 22:32:43 -08:00
2026-05-19 09:21:28 -07:00
ok.
2026-02-08 08:43:53 -08:00
2022-09-26 16:12:39 -07:00
2026-04-25 19:41:40 -07:00
2023-10-12 21:55:37 -07:00
2023-07-27 09:50:22 -07:00
2018-09-03 13:12:20 -07:00
2019-01-26 09:02:28 -08:00
2022-12-08 08:51:34 -08:00
2019-01-26 09:02:28 -08:00
2019-04-24 21:29:38 -07:00
2024-10-18 23:21:49 -07:00
2023-01-07 23:01:20 -08:00
2023-03-24 10:57:53 -07:00
2023-08-31 23:43:19 -07:00
2026-05-19 09:21:28 -07:00
2024-02-08 20:36:04 -08:00
2021-10-08 16:18:31 -07:00
fix
2022-06-23 08:44:44 -07:00
2026-04-09 14:32:39 -07:00
2024-03-14 07:16:59 -07:00
Description
No description provided
22 MiB
Languages
Clojure 91%
CSS 4.2%
Sass 2.3%
HTML 1.2%
HCL 0.4%
Other 0.7%