Partner Capital Dashboard:
- Add get_styles() with proper CSS for sections (card with border/radius),
  summary grid (stat cards), and partner table — previously unstyled
- Extract filter styles from inline make_filters_html() into get_styles()
- Right-align all numeric columns in the partner table with tabular-nums
- Add hover and drilldown cursor states via CSS instead of inline styles
- Improve late-entry warning: structured DOM, partner breakdown on
  separate line as muted text joined by · instead of concatenated string

Project Dashboard:
- Add .time-title and .time-note CSS so activity/task line and
  description line render as distinct stacked rows instead of inline
- Rename "Work" section header to "Log Time" for clarity

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Partner Capital Dashboard:
- Remove redundant Refresh button (all filters already auto-refresh)
- Restore last selected partner from localStorage on page load
- Visual hierarchy: Partner Total, Bank Balance, Delta shown larger (key-metric)
- Delta color-coded green/positive vs red/negative
- Drilldown cells now show text underline on hover to signal clickability

Project Dashboard:
- Remove redundant Refresh button
- Restore last selected project from localStorage on page load
- Per-section loading spinner instead of global page freeze
- Quick-start timer button (▶ Start) directly on each active task row,
  appears on hover — eliminates the select-in-Work-section flow
- Completed/Cancelled tasks collapsed into expandable toggle at bottom
  of task list so active work stays prominent
- Persistent timer badge in My Time section header showing live elapsed
  time (pulsing dot + clock) — visible even when timer modal is minimized
- Timer badge cleared automatically when timer stops

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Each historical period's cutoff in _get_pl_allocation_periods_with_cutoff
was set to its own allocation's creation time, causing any late entry
captured by an intermediate run to be re-captured by every subsequent run.

Fix: after building the periods list (sorted descending), cascade
periods[0]["creation"] (the most recent prior run's timestamp) back
through all older periods. An entry is only treated as unallocated if
it was created after the last time any allocation ran.

Adds a Frappe migration patch that reconstructs the correct amounts for
each past allocation JE using the fixed logic and posts correcting
Journal Entries where the actual postings differ. Idempotent.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Two bugs introduced by the initial patch:

1. _get_last_allocation matched correction JEs via LIKE 'P&L Allocation%'.
   A correction JE has a remark that doesn't parse to a period, causing
   get_default_allocation_period to fall back to fiscal-year start and
   presenting the full year as allocatable.
   Fix: skip any row whose user_remark doesn't parse to a valid period.

2. Migration used CORRECTION_PREFIX = "P&L Allocation Correction" (same
   LIKE match problem) and called get_pl_totals_by_cost_centre without a
   creation bound, so GL entries posted into an already-allocated period
   after that allocation ran were included in the "correct" amount,
   producing spurious correction JEs (e.g. JV-00079 wrongly debited Feb).
   Fix: rename prefix to "Allocation Correction"; add _get_pl_totals_at_
   creation helper that bounds all GL entries by creation <= T_allocation,
   reconstructing exactly what the engine saw at runtime.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

The monthly P&L allocation and the partner dashboards inferred "already
allocated" from a GL.creation vs Allocation.creation timestamp heuristic,
reconstructed differently in the engine (cascaded cutoff) than in the
dashboard (no cascade). Combined with the P&L closing entry never running
(close_pnl_by_cost_centre was hard-wired to 0 in the UI), reconciling
back-dated bank items double-counted them and the dashboards drifted out
of sync.

Make "allocated" a real ledger fact instead:

- Every allocation now mandatorily posts the P&L closing entry, zeroing the
  P&L cost-centre balances into equity via the clearing account.
- The amount moved is the cumulative open P&L balance up to to_date
  (get_pl_totals_by_cost_centre(None, to_date, company)), which naturally
  includes prior closings and back-dated late entries.
- Delete all creation-timestamp, cascade, late-period and voucher-blacklist
  logic from the engine and the dashboard; the dashboard now reuses the exact
  same engine query, so the two can no longer disagree.

Add close_historical_pl_allocations migration to post the missing closing
entries for historical allocations (runs after fix_pl_allocation_double_counting,
which corrects historical Eigenkapital) so the clearing account nets to zero.

The retro-close migration crashed posting a P&L Closing entry into a period
already closed by a year-end Period Closing Voucher (books closed until
31.12.2025). Introduce a shared "books frozen upto" boundary (max of the newest
Period Closing Voucher posting date and Accounts Settings.acc_frozen_upto) and:

- clamp the open-P&L queries so P&L on or before the close is never counted
  (it was already swept to retained earnings), fixing the engine, the preview,
  and the dashboard cost_centre_balance for closed years;
- skip already-closed periods in the migration (and clamp a straddling period's
  window) so it never posts into frozen books.

Idempotent; safe to re-run after the partial migration.

The frozen-date skip alone was not enough on the test instance (the migration
still hit a Period Closing Voucher block). Harden it:

- detect the books-closed boundary from any submitted Period Closing Voucher
  (drop the company filter so it is found reliably) plus acc_frozen_upto;
- wrap each closing post in try/except: on any failure (e.g. a closed period the
  boundary detection missed) roll back that period and continue instead of
  aborting the whole `bench migrate`;
- print the detected boundary and every skip/failure so the actual state is
  visible in the migrate output.

get_books_frozen_upto queried a non-existent posting_date column on Period
Closing Voucher (this ERPNext keeps the close date in period_end_date), so the
frozen boundary silently resolved to nothing and the dashboard kept counting
already-closed prior-year P&L in cost_centre_balance. Use period_end_date (with
posting_date as a fallback) and ignore the unset acc_frozen_upto sentinel
(0001-01-01).

The dashboard showed a bare "Delta" between partner capital and the bank balance
that was impossible to interpret without knowing the open items, and it never
answered the actual question: how much can a partner take out right now.

- Add a reconciliation section that walks from partner capital down to the bank
  balance, one line per account causing the gap (open invoices, clearing,
  retained earnings, ...). It is exact by construction — derived from the trial
  balance identity — and shows an explicit "unexplained difference" line that
  stays at zero when the books are clean. Every line drills into the GL.
- Add "Payable now": the bank balance minus outstanding payables, split across
  partners in proportion to their claims and capped at each claim. Shown as a
  headline metric and per partner in the details table.
- Replace the misleading bare "Delta" metric with "Payable now"; the difference
  is now explained line by line instead of asserted as a number.

When the last allocation already ran up to today, the suggested next period
started the day after it ended while still ending today, so the form showed
from_date after to_date (e.g. 2026-07-23 to 2026-07-22). Clamp the end date to
at least the start date.

The letter read doc.outstanding_amount, but a Payment Request only carries
grand_total (the requested amount) — the open balance lives on the referenced
invoice. The "Offener Betrag" row therefore printed 0,00 EUR while the body text
silently fell back to grand_total, so the two contradicted each other.

- Resolve grand_total and outstanding_amount from the referenced document and use
  them consistently in the body text and the summary table.
- Show the breakdown (invoice total, already paid, open) and, when a partial
  amount is requested, the requested amount as a separate line.
- Handle the fully-settled case with an informational wording instead of asking
  for a payment of 0,00 EUR.
- Fix the same field mistake in the default e-mail message and format it as
  currency instead of a raw number.

Three defects surfaced while re-running the full reconcile on the test instance.

1. "Total Debit must be equal to Total Credit" when posting a period.
   The closing entry put every P&L line in at full float precision and offset
   them against the sum of the *unrounded* amounts. ERPNext rounds each line to
   currency precision on save, so the rounded lines no longer matched the
   rounded total and the entry was rejected. Round each line before summing, in
   the allocation entry, the closing entry and the retro-close migration.

2. A period whose income and expense cancelled out exactly was never closed at
   all (the zero net total short-circuited before any entry was written). Post
   the closing without a clearing line in that case — the P&L lines already
   balance each other.

3. fix_pl_allocation_double_counting recreated a spurious "Allocation
   Correction" on every fresh clone. It reconstructs amounts with the old
   creation-timestamp cascade, which the ledger-derived model replaced, and its
   corrections can outlive the allocation they correct (leaving equity and the
   clearing account off by that amount). The new model recomputes the open
   balance from the ledger on every run, so the patch is obsolete: remove it and
   inline the voucher-blacklist helper the retro-close migration still needs.

The clearing account could never reach zero because the two halves of an
allocation were computed from different data:

- the allocation summed open P&L per cost centre and silently skipped cost
  centres with no partner mapping, while the closing entry summed per
  (account, cost centre) and zeroed every cost centre including those; and
- each side rounded at a different aggregation level.

The live data shows the effect directly: allocation 119.00 vs. closing 78.33 for
2026-04-02..04-30, leaving 40.67 stranded on the clearing account (which the old
correction patch then papered over).

Derive both entries from one set of rounded (account, cost centre) lines, scoped
to the partner cost centres, and refuse to post while any P&L sits on an
unmapped cost centre instead of skipping it. Allocation total and closing total
are now equal by construction, so the clearing account nets to exactly zero.

Add a "Als Zahlungserinnerung drucken" checkbox to Dunning Type so a dunning can
be relabelled as a friendly reminder without a second document type.

When ticked, the print format:
- drops the fee and interest rows and prints a single "Offener Gesamtbetrag"
  line. The previous layout repeated the same figure as "Offen" and
  "Gesamtbetrag" whenever fee and interest were zero, which read like an error;
- uses the Dunning Type's Print Title instead of the word "Mahnung" in the
  "should your payment have crossed with this ..." sentence.

The reminder layout only takes effect when fee and interest really are zero;
otherwise the full breakdown is printed even with the box ticked, so the printed
total can never contradict the booked document.