[Bug 33501] New: Cashup amount should be configurable
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Bug ID: 33501 Summary: Cashup amount should be configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs@lists.koha-community.org Reporter: cbrannon@cdalibrary.org QA Contact: testopia@bugs.koha-community.org It seems the Cashup summary only accounts for the cash payment type. We have a check payment type that should also be included. Am I missing a configuration somewhere, or do we need some way to define what should be included in the summary and intake balance? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Component|Tools |Fines and fees --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It's not configurable now. I think the feature was written with cash registers in mind. When you do a cash-up, it tells you how much money you need to take out in order to keep a certain amount of change in the register. I am not sure if adding non-cash payment types would complicate this in some way. Adding Martin. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #2 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- This is where 'credit type' and 'payment/transaction type' differ... credit types are configurable, but transaction types aren't at this time.. most places you select the payment/transaction type at transaction time.. is there's somewhere missing this and could you not select 'Cheque' for 'Credit type' with 'Cash' as transaction type? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #3 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to Katrin Fischer from comment #1)
It's not configurable now.
I think the feature was written with cash registers in mind. When you do a cash-up, it tells you how much money you need to take out in order to keep a certain amount of change in the register. I am not sure if adding non-cash payment types would complicate this in some way. Adding Martin.
Yes, and checks are typically taken out and tallied along with cash. They have to be accounted for, and not left in the register. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #4 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to Martin Renvoize from comment #2)
This is where 'credit type' and 'payment/transaction type' differ... credit types are configurable, but transaction types aren't at this time.. most places you select the payment/transaction type at transaction time.. is there's somewhere missing this and could you not select 'Cheque' for 'Credit type' with 'Cash' as transaction type?
I'm not sure I'm understanding you here. I am only aware of the PAYMENT_TYPE authorized value where we set types of Cash, Credit, or Check. That works just fine. It is in the cashup workflow where it shows the balance that we need to pull from the register where it does not reflect the check amounts. There is no place that I can see where we can define what payment types are included in the cashup balance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Christopher Brannon from comment #3)
(In reply to Katrin Fischer from comment #1)
It's not configurable now.
I think the feature was written with cash registers in mind. When you do a cash-up, it tells you how much money you need to take out in order to keep a certain amount of change in the register. I am not sure if adding non-cash payment types would complicate this in some way. Adding Martin.
Yes, and checks are typically taken out and tallied along with cash. They have to be accounted for, and not left in the register.
I was wondering how it could affect the value of change that should always remain in the register. If your cash in the register is low and there is mostly checks, you'll get into a situation where you need to replace some checks with change money again. I wonder if there is a better way to handle this somehow. At least it would be necessary to be able to 'flag' which payment type are 'physical' ones ending in the register. But maybe there should also be some clever calculation that tell you: take out all cheques and please fill up change money by X. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41299 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Fines and fees |Point of Sale -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |40445 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40445 [Bug 40445] Point of Sale reconciliation input during daily summaries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #6 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- I think, given the current restrictions we have around payment_types being an authorised value.. the best approach I can think of is one where we have an additional system preference to define a list of payment types that should be utilised in the cashup and reconciliation workflows. I think we'd want to display an input box per payment type for the reconciliation amounts to be entered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk Sponsorship status|--- |Seeking sponsor Crowdfunding goal|0 |2000 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |42553 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42553 [Bug 42553] preferences.pl: Allow 'multiple_sortable' to use 'authval' source for dynamic choices -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Comma delimited| |West Sussex County Council list of Sponsors| |<https://www.westsussex.gov | |.uk/> Patch complexity|--- |Medium patch Sponsorship status|Seeking sponsor |Sponsored Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #7 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198837 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198837&action=edit Bug 33501: Database update â Add CashupPaymentTypes system preference Adds a new system preference that lists, in order, which PAYMENT_TYPE authorised values participate in the cashup reconciliation workflow. The preference is rendered as a sortable multi-select picker in Administration > System preferences > Accounting using the 'multiple_sortable: authval' pattern (see Bug 42553). Order is significant: it drives the row order in the Complete cashup modal and the per-payment-type breakdown on the register page. Default value is 'CASH,SIP00' so that existing installations are unaffected — that matches the previously hardcoded list used for the expected-amount filter in the cashup workflow. Also backfills payment_type='CASH' on any historical CASHUP_SURPLUS / CASHUP_DEFICIT accountlines that pre-date this work and have no payment_type yet. Every cashup before this bug treated all takings as cash, so tagging those lines explicitly is safe and lets the cashup summary group them under 'CASH' without runtime fallback handling. Subsequent patches in this series consume the preference to drive the per-payment-type reconciliation flow. Depends on Bug 42553 for the dynamic 'authval' source on multiple_sortable. Test plan: 1. Apply this patch and run the database update. The output should confirm the syspref was added and report how many historical surplus/deficit lines (if any) were backfilled. 2. Visit Administration > System preferences > Accounting and find the new "CashupPaymentTypes" preference. Verify it renders as a sortable list of every value in the PAYMENT_TYPE authorised value category, with checkboxes and drag handles, defaulting to 'CASH,SIP00' selected. 3. Pick CASH and a couple of others (e.g. CHEQUE, SIP01), reorder by dragging, save. Reload and verify the order and selection are preserved as a comma-separated string in the systempreferences row. 4. Add a fresh PAYMENT_TYPE authorised value (e.g. VOUCHER) and confirm it appears in the picker without further configuration. 5. On a database with pre-existing CASHUP_SURPLUS / CASHUP_DEFICIT accountlines created before this patch, verify their payment_type column has been populated with 'CASH'. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198838 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198838&action=edit Bug 33501: Per-payment-type cashup reconciliation in add_cashup Reworks Koha::Cash::Register->add_cashup to take a 'reconciliations' arrayref. Each entry is reconciled against the expected total for that payment type alone. A non-zero discrepancy creates a CASHUP_SURPLUS or CASHUP_DEFICIT accountline tagged with the relevant payment_type. Balanced types create no reconciliation line. \$register->add_cashup({ manager_id => \$user_id, reconciliations => [ { payment_type => 'CASH', actual_amount => 102.00 }, { payment_type => 'CHEQUE', actual_amount => 20.00, note => 'Drawer short' }, ], }); Each entry must carry its own per-discrepancy 'note' on a discrepant row when CashupReconciliationNoteRequired is on; the note is stored on that surplus/deficit accountline. Balanced rows ignore any 'note' they carry. Adds two helpers: - cashup_payment_types reads CashupPaymentTypes, splits on commas, and falls back to ['CASH'] if empty. - cashup_payment_types_breakdown returns labelled per-type expected totals scoped to the in-progress session (when a CASHUP_START exists) or the outstanding accountlines (otherwise). The previous hardcoded ['CASH','SIP00'] filter in the expected-amount calculation now reads from the preference. cashup_in_progress is updated to return a Koha::Cash::Register::Cashup (rather than ::Action) so callers can use the richer interface (->accountlines, ->summary). Cashup ISA Action so existing attribute access remains valid. The previous single-amount form is removed: the method has only ever been used internally and every caller is updated in this patch series to pass a reconciliations array. The cashup-wide reconciliation_note fallback is also removed — notes are now strictly per-row, matching the modal UI which has no global note input. The 40445 test fixtures that called add_cashup with a single 'amount' or with a cashup-wide 'reconciliation_note' have been migrated mechanically to the equivalent reconciliations-array shape with the note moved onto the single CASH entry. Test plan: 1. Apply the previous patch in this series (the database update), then this patch, and run the database update. 2. Run prove t/db_dependent/Koha/Cash/Register.t — all subtests should pass, including the new ones: - cashup_payment_types - cashup_payment_types_breakdown - cashup_per_payment_type - cashup_per_payment_type_notes 3. Manually: configure CashupPaymentTypes to 'CASH,CHEQUE,CARD', process a transaction in each type, then call add_cashup with a reconciliations array. Verify per-type CASHUP_SURPLUS/DEFICIT lines are created with the correct payment_type, balanced types create no lines, and per-row notes land on the right line. 4. With CashupReconciliationNoteRequired set to "Require", verify that submitting a discrepant row without its own note throws Koha::Exceptions::MissingParameter. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198839 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198839&action=edit Bug 33501: Per-payment-type cashup summary modal Extends Koha::Cash::Register::Cashup->summary with a 'reconciliations_grouped' arrayref — one entry per payment type that has a CASHUP_SURPLUS and/or CASHUP_DEFICIT line for this cashup, with its surplus_total, deficit_total and note. Built directly from the reconciliation accountlines. The cashup summary modal (cashup_modal.js) renders one row per payment type with the relevant surplus or deficit amount and note. The legacy single-row fallback (using the older surplus_total / deficit_total fields without payment-type grouping) is dropped; the atomicupdate in the previous patch backfills payment_type on any historical surplus/deficit lines, so reconciliations_grouped is always populated when surplus or deficit lines exist. Adds a focused unit test 'reconciliations_grouped' covering a mixed cashup (cash deficit + cheque surplus). Existing summary fixtures that previously exercised the legacy single-amount add_cashup form have been mechanically migrated to the new reconciliations-array shape (all of them used CASH-only registers, so this is a syntactic change only). Test plan: 1. Apply the previous patches in this series. 2. Run prove t/db_dependent/Koha/Cash/Register/Cashup.t — all subtests should pass, including the new 'reconciliations_grouped'. 3. Configure CashupPaymentTypes to 'CASH,CHEQUE' and process some payments using each type. 4. Start a two-phase cashup, then complete it with a discrepant actual amount for both types, supplying a per-row note for each. 5. Click the Summary link on the completed cashup. Confirm the modal shows two reconciliation rows, one labelled "Cash deficit" and one labelled "Cheque surplus" (or similar), each with its own reconciliation note. 6. On a database that had CASHUP_SURPLUS / CASHUP_DEFICIT lines before this series, click Summary on one of those legacy cashups and confirm the modal still renders correctly — backfilled rows appear under the 'CASH' label. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #10 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- 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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Cashup amount should be |Add optional support for |configurable |different payment types | |during cashup | |reconciliation -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |13985 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13985 [Bug 13985] [Omnibus] Cash Management - Koha as 'Point of Sale' -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Initiative type|--- |Feature Target Milestone|--- |26.11 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198837|0 |1 is obsolete| | Attachment #198838|0 |1 is obsolete| | Attachment #198839|0 |1 is obsolete| | Attachment #198840|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201552 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201552&action=edit Bug 33501: Database update â Add CashupPaymentTypes system preference Adds a new system preference that lists, in order, which PAYMENT_TYPE authorised values participate in the cashup reconciliation workflow. The preference is rendered as a sortable multi-select picker in Administration > System preferences > Accounting using the 'multiple_sortable: authval' pattern (see Bug 42553). Order is significant: it drives the row order in the Complete cashup modal and the per-payment-type breakdown on the register page. Default value is 'CASH,SIP00' so that existing installations are unaffected — that matches the previously hardcoded list used for the expected-amount filter in the cashup workflow. Also backfills payment_type='CASH' on any historical CASHUP_SURPLUS / CASHUP_DEFICIT accountlines that pre-date this work and have no payment_type yet. Every cashup before this bug treated all takings as cash, so tagging those lines explicitly is safe and lets the cashup summary group them under 'CASH' without runtime fallback handling. Subsequent patches in this series consume the preference to drive the per-payment-type reconciliation flow. Depends on Bug 42553 for the dynamic 'authval' source on multiple_sortable. Test plan: 1. Apply this patch and run the database update. The output should confirm the syspref was added and report how many historical surplus/deficit lines (if any) were backfilled. 2. Visit Administration > System preferences > Accounting and find the new "CashupPaymentTypes" preference. Verify it renders as a sortable list of every value in the PAYMENT_TYPE authorised value category, with checkboxes and drag handles, defaulting to 'CASH,SIP00' selected. 3. Pick CASH and a couple of others (e.g. CHEQUE, SIP01), reorder by dragging, save. Reload and verify the order and selection are preserved as a comma-separated string in the systempreferences row. 4. Add a fresh PAYMENT_TYPE authorised value (e.g. VOUCHER) and confirm it appears in the picker without further configuration. 5. On a database with pre-existing CASHUP_SURPLUS / CASHUP_DEFICIT accountlines created before this patch, verify their payment_type column has been populated with 'CASH'. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #12 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201553 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201553&action=edit Bug 33501: Per-payment-type cashup reconciliation in add_cashup Reworks Koha::Cash::Register->add_cashup to take a 'reconciliations' arrayref. Each entry is reconciled against the expected total for that payment type alone. A non-zero discrepancy creates a CASHUP_SURPLUS or CASHUP_DEFICIT accountline tagged with the relevant payment_type. Balanced types create no reconciliation line. \$register->add_cashup({ manager_id => \$user_id, reconciliations => [ { payment_type => 'CASH', actual_amount => 102.00 }, { payment_type => 'CHEQUE', actual_amount => 20.00, note => 'Drawer short' }, ], }); Each entry must carry its own per-discrepancy 'note' on a discrepant row when CashupReconciliationNoteRequired is on; the note is stored on that surplus/deficit accountline. Balanced rows ignore any 'note' they carry. Adds two helpers: - cashup_payment_types reads CashupPaymentTypes, splits on commas, and falls back to ['CASH'] if empty. - cashup_payment_types_breakdown returns labelled per-type expected totals scoped to the in-progress session (when a CASHUP_START exists) or the outstanding accountlines (otherwise). The previous hardcoded ['CASH','SIP00'] filter in the expected-amount calculation now reads from the preference. cashup_in_progress is updated to return a Koha::Cash::Register::Cashup (rather than ::Action) so callers can use the richer interface (->accountlines, ->summary). Cashup ISA Action so existing attribute access remains valid. The previous single-amount form is removed: the method has only ever been used internally and every caller is updated in this patch series to pass a reconciliations array. The cashup-wide reconciliation_note fallback is also removed — notes are now strictly per-row, matching the modal UI which has no global note input. The 40445 test fixtures that called add_cashup with a single 'amount' or with a cashup-wide 'reconciliation_note' have been migrated mechanically to the equivalent reconciliations-array shape with the note moved onto the single CASH entry. Test plan: 1. Apply the previous patch in this series (the database update), then this patch, and run the database update. 2. Run prove t/db_dependent/Koha/Cash/Register.t — all subtests should pass, including the new ones: - cashup_payment_types - cashup_payment_types_breakdown - cashup_per_payment_type - cashup_per_payment_type_notes 3. Manually: configure CashupPaymentTypes to 'CASH,CHEQUE,CARD', process a transaction in each type, then call add_cashup with a reconciliations array. Verify per-type CASHUP_SURPLUS/DEFICIT lines are created with the correct payment_type, balanced types create no lines, and per-row notes land on the right line. 4. With CashupReconciliationNoteRequired set to "Require", verify that submitting a discrepant row without its own note throws Koha::Exceptions::MissingParameter. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #13 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201554 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201554&action=edit Bug 33501: Per-payment-type cashup summary modal Extends Koha::Cash::Register::Cashup->summary with a 'reconciliations_grouped' arrayref — one entry per payment type that has a CASHUP_SURPLUS and/or CASHUP_DEFICIT line for this cashup, with its surplus_total, deficit_total and note. Built directly from the reconciliation accountlines. The cashup summary modal (cashup_modal.js) renders one row per payment type with the relevant surplus or deficit amount and note. The legacy single-row fallback (using the older surplus_total / deficit_total fields without payment-type grouping) is dropped; the atomicupdate in the previous patch backfills payment_type on any historical surplus/deficit lines, so reconciliations_grouped is always populated when surplus or deficit lines exist. Adds a focused unit test 'reconciliations_grouped' covering a mixed cashup (cash deficit + cheque surplus). Existing summary fixtures that previously exercised the legacy single-amount add_cashup form have been mechanically migrated to the new reconciliations-array shape (all of them used CASH-only registers, so this is a syntactic change only). Test plan: 1. Apply the previous patches in this series. 2. Run prove t/db_dependent/Koha/Cash/Register/Cashup.t — all subtests should pass, including the new 'reconciliations_grouped'. 3. Configure CashupPaymentTypes to 'CASH,CHEQUE' and process some payments using each type. 4. Start a two-phase cashup, then complete it with a discrepant actual amount for both types, supplying a per-row note for each. 5. Click the Summary link on the completed cashup. Confirm the modal shows two reconciliation rows, one labelled "Cash deficit" and one labelled "Cheque surplus" (or similar), each with its own reconciliation note. 6. On a database that had CASHUP_SURPLUS / CASHUP_DEFICIT lines before this series, click Summary on one of those legacy cashups and confirm the modal still renders correctly — backfilled rows appear under the 'CASH' label. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #14 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201555 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201555&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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off QA Contact|testopia@bugs.koha-communit |andrew@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201552|0 |1 is obsolete| | Attachment #201553|0 |1 is obsolete| | Attachment #201554|0 |1 is obsolete| | Attachment #201555|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #15 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201794 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201794&action=edit Bug 33501: Database update â Add CashupPaymentTypes system preference Adds a new system preference that lists, in order, which PAYMENT_TYPE authorised values participate in the cashup reconciliation workflow. The preference is rendered as a sortable multi-select picker in Administration > System preferences > Accounting using the 'multiple_sortable: authval' pattern (see Bug 42553). Order is significant: it drives the row order in the Complete cashup modal and the per-payment-type breakdown on the register page. Default value is 'CASH,SIP00' so that existing installations are unaffected — that matches the previously hardcoded list used for the expected-amount filter in the cashup workflow. Also backfills payment_type='CASH' on any historical CASHUP_SURPLUS / CASHUP_DEFICIT accountlines that pre-date this work and have no payment_type yet. Every cashup before this bug treated all takings as cash, so tagging those lines explicitly is safe and lets the cashup summary group them under 'CASH' without runtime fallback handling. Subsequent patches in this series consume the preference to drive the per-payment-type reconciliation flow. Depends on Bug 42553 for the dynamic 'authval' source on multiple_sortable. Test plan: 1. Apply this patch and run the database update. The output should confirm the syspref was added and report how many historical surplus/deficit lines (if any) were backfilled. 2. Visit Administration > System preferences > Accounting and find the new "CashupPaymentTypes" preference. Verify it renders as a sortable list of every value in the PAYMENT_TYPE authorised value category, with checkboxes and drag handles, defaulting to 'CASH,SIP00' selected. 3. Pick CASH and a couple of others (e.g. CHEQUE, SIP01), reorder by dragging, save. Reload and verify the order and selection are preserved as a comma-separated string in the systempreferences row. 4. Add a fresh PAYMENT_TYPE authorised value (e.g. VOUCHER) and confirm it appears in the picker without further configuration. 5. On a database with pre-existing CASHUP_SURPLUS / CASHUP_DEFICIT accountlines created before this patch, verify their payment_type column has been populated with 'CASH'. Sponsored-by: West Sussex County Council <https://www.westsussex.gov.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Debbie McCarthy <debbie.mccarthy@westsussex.gov.uk> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #16 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201795 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201795&action=edit Bug 33501: Per-payment-type cashup reconciliation in add_cashup Reworks Koha::Cash::Register->add_cashup to take a 'reconciliations' arrayref. Each entry is reconciled against the expected total for that payment type alone. A non-zero discrepancy creates a CASHUP_SURPLUS or CASHUP_DEFICIT accountline tagged with the relevant payment_type. Balanced types create no reconciliation line. \$register->add_cashup({ manager_id => \$user_id, reconciliations => [ { payment_type => 'CASH', actual_amount => 102.00 }, { payment_type => 'CHEQUE', actual_amount => 20.00, note => 'Drawer short' }, ], }); Each entry must carry its own per-discrepancy 'note' on a discrepant row when CashupReconciliationNoteRequired is on; the note is stored on that surplus/deficit accountline. Balanced rows ignore any 'note' they carry. Adds two helpers: - cashup_payment_types reads CashupPaymentTypes, splits on commas, and falls back to ['CASH', 'SIP00'] (the previously hardcoded set) if empty. - cashup_payment_types_breakdown returns labelled per-type expected totals scoped to the in-progress session (when a CASHUP_START exists) or the outstanding accountlines (otherwise). The previous hardcoded ['CASH','SIP00'] filter in the expected-amount calculation now reads from the preference. cashup_in_progress is updated to return a Koha::Cash::Register::Cashup (rather than ::Action) so callers can use the richer interface (->accountlines, ->summary). Cashup ISA Action so existing attribute access remains valid. The previous single-amount form is removed: the method has only ever been used internally and every caller is updated in this patch series to pass a reconciliations array. The cashup-wide reconciliation_note fallback is also removed — notes are now strictly per-row, matching the modal UI which has no global note input. The 40445 test fixtures that called add_cashup with a single 'amount' or with a cashup-wide 'reconciliation_note' have been migrated mechanically to the equivalent reconciliations-array shape with the note moved onto the single CASH entry. Test plan: 1. Apply the previous patch in this series (the database update), then this patch, and run the database update. 2. Run prove t/db_dependent/Koha/Cash/Register.t — all subtests should pass, including the new ones: - cashup_payment_types - cashup_payment_types_breakdown - cashup_per_payment_type - cashup_per_payment_type_notes 3. Manually: configure CashupPaymentTypes to 'CASH,CHEQUE,CARD', process a transaction in each type, then call add_cashup with a reconciliations array. Verify per-type CASHUP_SURPLUS/DEFICIT lines are created with the correct payment_type, balanced types create no lines, and per-row notes land on the right line. 4. With CashupReconciliationNoteRequired set to "Require", verify that submitting a discrepant row without its own note throws Koha::Exceptions::MissingParameter. Sponsored-by: West Sussex County Council <https://www.westsussex.gov.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Debbie McCarthy <debbie.mccarthy@westsussex.gov.uk> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #17 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201796 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201796&action=edit Bug 33501: Per-payment-type cashup summary modal Extends Koha::Cash::Register::Cashup->summary with a 'reconciliations_grouped' arrayref — one entry per payment type that has a CASHUP_SURPLUS and/or CASHUP_DEFICIT line for this cashup, with its surplus_total, deficit_total and note. Built directly from the reconciliation accountlines. The cashup summary modal (cashup_modal.js) renders one row per payment type with the relevant surplus or deficit amount and note. The legacy single-row fallback (using the older surplus_total / deficit_total fields without payment-type grouping) is dropped; the atomicupdate in the previous patch backfills payment_type on any historical surplus/deficit lines, so reconciliations_grouped is always populated when surplus or deficit lines exist. Adds a focused unit test 'reconciliations_grouped' covering a mixed cashup (cash deficit + cheque surplus). Existing summary fixtures that previously exercised the legacy single-amount add_cashup form have been mechanically migrated to the new reconciliations-array shape (all of them used CASH-only registers, so this is a syntactic change only). Test plan: 1. Apply the previous patches in this series. 2. Run prove t/db_dependent/Koha/Cash/Register/Cashup.t — all subtests should pass, including the new 'reconciliations_grouped'. 3. Configure CashupPaymentTypes to 'CASH,CHEQUE' and process some payments using each type. 4. Start a two-phase cashup, then complete it with a discrepant actual amount for both types, supplying a per-row note for each. 5. Click the Summary link on the completed cashup. Confirm the modal shows two reconciliation rows, one labelled "Cash deficit" and one labelled "Cheque surplus" (or similar), each with its own reconciliation note. 6. On a database that had CASHUP_SURPLUS / CASHUP_DEFICIT lines before this series, click Summary on one of those legacy cashups and confirm the modal still renders correctly — backfilled rows appear under the 'CASH' label. Sponsored-by: West Sussex County Council <https://www.westsussex.gov.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Debbie McCarthy <debbie.mccarthy@westsussex.gov.uk> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #18 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201797 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201797&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. Sponsored-by: West Sussex County Council <https://www.westsussex.gov.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Debbie McCarthy <debbie.mccarthy@westsussex.gov.uk> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #19 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201798 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201798&action=edit Bug 33501: (follow-up) Replace hardcoded (cash) labels with accurate bankable wording The income/outgoing summary lines and table headers on the POS register pages were hardcoded to say "(cash)", a leftover from before CashupPaymentTypes made the bankable payment type list configurable. Since that preference can now include Cheque, Card, etc., "(cash)" no longer describes either the all-payment-types total or the type-filtered subset shown alongside it. Relabel both figures as "Total income/outgoing: X (bankable: Y)" and add a hover tooltip listing the actual payment types counted as bankable, sourced from the register's cashup_payment_types_breakdown. Sponsored-by: West Sussex County Council <https://www.westsussex.gov.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Debbie McCarthy <debbie.mccarthy@westsussex.gov.uk> Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 --- Comment #20 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 201799 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201799&action=edit Bug 33501: (follow-up) Share CashupPaymentTypes with HEA Adds the new CashupPaymentTypes system preference to the list of preferences reported to the Koha usage statistics service (HEA), per the process established by Bug 23849. The preference only stores an ordered list of PAYMENT_TYPE authorised value codes (e.g. CASH, CHEQUE, SIP00) chosen from a library's own configuration, and works the same way as the many other feature/config toggles already shared here. It carries no patron or library-identifying data, so it's safe to include and gives the community visibility into adoption of the per-payment-type cashup workflow. Test plan: 1. prove t/db_dependent/UsageStats.t 2. Confirm 'systempreferences' key in C4::UsageStats::BuildReport still builds without error and includes CashupPaymentTypes when set. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org