This Slice adds a Batch Total (LCY) field to Payment Journal pages across localized layers, backed by GenJnlManagement.CalcBatchTotal, and adds tests for totals, empty batches, batch changes, and amount edits. The feature goal is valid: users need a batch-level payment total before posting. The sum itself uses the current page filters and Amount (LCY), which matches the stated batch-total behavior. The main correctness risk is that the page recalculates the total during amount field validation by reading persisted lines, but the edited line has not been explicitly saved first.

S1 - Save before recalculating edited amounts
The new amount-field UpdateBalance() calls recalculate Batch Total from persisted Gen. Journal Line records. Save the current line first, or adjust the total with the Rec/xRec amount delta, so the edited amount is included before the user leaves the line.

S2 - Avoid extra full-batch sums per edit
Each amount edit now runs the existing balance refresh and another full-batch CalcSums("Amount (LCY)") across every localized Payment Journal page. Large payment batches can pay several aggregate queries per edit. Consider updating Batch Total from the edited-line delta, or refresh it once after the record is saved.

S3 - Document new public extension points
CalcBatchTotal and the new Batch Total events expose new integration points, but they do not have the XML summary and param comments used by nearby public procedures and events. Add those comments in W1, ES, NL, and the page copies so subscribers understand the filters, amount sign, and visibility contract.

Risk: This is a financial UI surface, so a stale Batch Total can mislead users about the amount selected for payment before posting. The diff does not change posting or ledger-entry creation, but it adds a public helper and event publishers and it runs extra aggregate calculations on Payment Journal navigation and amount validation in all localized page copies.

Necessity: The change is justified by Slice 425446 and the Ideas-site request: Balance and Total Balance do not answer the batch-level payment-total question. The scope is mostly right because all Payment Journal page copies are covered and tests were added, but the edited-line refresh path should be fixed before merge.

This round updates the Payment Journal Batch Total implementation after round 1. Amount validation now saves the current line and refreshes only Batch Total, so the edited amount is included without forcing the full balance refresh path. The new Batch Total filter hook events were also removed. The feature still matches the Slice goal: show the total selected for payment at batch level, with tests for totals, empty batches, batch switching, and amount edits.

None - the new commit only addresses prior review feedback.

Risk: This is a financial UI surface, so a wrong or stale Batch Total can mislead users before posting. The round-2 change lowers the main correctness risk by saving the edited line before recalculating. It does not change posting or ledger entries. One non-blocking maintainability issue remains: the new public CalcBatchTotal procedure should document its filter and visibility contract.

Necessity: The Slice remains justified by the Ideas-site request. Balance and Total Balance do not show the batch-level amount selected for payment, and the scope covers the Payment Journal page copies plus relevant tests.