https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501
--- Comment #10 from Martin Renvoize (ashimema) <[email protected]> --- Created attachment 198840 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198840&action=edit Bug 33501: Per-payment-type Complete cashup modal Replaces the single expected/actual line in the Complete cashup modal with a table that has one row per payment type listed in CashupPaymentTypes. Each row shows the expected total for that type, an empty actual-amount input, a live discrepancy cell, and a per-row reconciliation note input. A totals row at the foot sums expected, actual, and net discrepancy. The reconciliation note input is disabled by default and is only enabled (and marked required when CashupReconciliationNoteRequired is on) once that row has a non-zero discrepancy. Visible '*' markers in the column headers indicate which columns are required. The modal no longer carries a single global reconciliation-note field — notes are strictly per-row. Each row's inputs are named per-payment-type (actual_amount_<TYPE>, reconciliation_note_<TYPE>) so disabling balanced rows does not break positional alignment with the rest of the form. The controller (pos/register.pl, pos/registers.pl) iterates the register's CashupPaymentTypes list and reads each value by suffix, building the 'reconciliations' array passed to add_cashup. The Quick cashup path (trigger modal) submits no actual amounts at all; the controller fills in expected per-type totals to build a balanced cashup — matching the previous Quick cashup semantics under the new per-type API. The register page Summary panel adds a "Bankable by payment type" table when more than one type is configured. The shared cashup modals (trigger, confirm, summary, confirm-selected) all use modal-lg for visual consistency. A small scoped CSS block in confirm_cashup.inc forces a white background on enabled inputs so the per-row inputs read as interactive against Koha's grey form backdrop. Submission validation is layered: - Native HTML5 'required' on every actual-amount input. - A custom submit handler walks every row and blocks the form if any actual_amount is empty, or any enabled+required note is empty, focusing the offender and surfacing reportValidity(). This compensates for jQuery Validate aggregating same-named inputs as a single field. - The backend re-validates via add_cashup and rejects submissions that slip through. Test plan: 1. Apply the previous patches in this series. 2. Configure CashupPaymentTypes to 'CASH,CHEQUE,CARD' via Administration > System preferences > Accounting. 3. Process some POS payments using each payment type. 4. Visit pos/register.pl for the till. Confirm the new "Bankable by payment type" table renders below the Summary list showing the expected total per type. 5. Click "Record cashup" then "Start cashup" (two-phase) to put a CASHUP_START on the register. Process more payments. 6. Click "Complete cashup". The modal should now show one row per configured payment type with its expected amount, an empty "Actual counted" input, and a disabled "Reconciliation note" input. 7. Enter actual amounts that match expected for some types and differ for others. Verify: - Each row shows its own discrepancy in real time. - The totals row sums expected, actual, and net discrepancy. - The note input on each discrepant row enables; balanced rows stay properly disabled (browser-grey, not interactive). 8. With CashupReconciliationNoteRequired set to "Require", try submitting a discrepant row without a note. The submit should be blocked and the empty note focused. 9. Submit a mixed cashup (some balanced, some discrepant, each with its own note). Verify in the resulting transaction history: - Only types with a non-zero discrepancy produce CASHUP_SURPLUS or CASHUP_DEFICIT lines. - Each line carries the relevant payment_type and the per-row note. 10. From the multi-register page, click "Complete cashup" on a specific register and confirm the same per-type modal renders with that register's data via the data-payment-types JSON attribute on the button. 11. Click the trigger modal's "Quick cashup" on a register with a multi-type configuration. The cashup should complete cleanly (balanced) using each type's expected total. 12. With CashupPaymentTypes set to a single type (e.g. 'CASH'), confirm the modal still renders correctly with one row only and the per-type totals table is hidden on the register page. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
