https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 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 -- 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=41819 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 192987 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192987&action=edit Bug 41819: POS refunds with 'AC' type incorrectly create PAYOUT accountlines When processing a refund through the POS register with refund type 'AC' (Account Credit), the system was incorrectly creating both a REFUND credit and a PAYOUT debit with payment_type = 'AC'. When 'AC' is selected, the refund should remain as a credit on the patron's account without creating a payout. This behavior was already correct in the member account refund workflow (members/boraccount.pl) but was missing from the POS refund workflow. This patch: 1. Adds the same check to pos/register.pl that exists in members/boraccount.pl to skip payout creation when refund_type is 'AC', making both workflows consistent. 2. Fixes the JavaScript in register.tt to properly hide the 'AC' option for anonymous transactions. The original check only tested for empty string, but borrowernumber can be undefined/null, which needs to be handled. Test plan: Part 1: Test patron transaction refund with Account Credit (AC) 1. Find or create a test patron 2. On the patron's Accounting tab, manually add a charge (e.g., Manual fee) 3. Pay the fee off from the patron's Accounting tab 4. Navigate to Point of Sale > Transaction History 5. Find the payment transaction you just created 6. Click "Issue refund" on the payment line item 7. Verify that "Account credit" appears as an option in the "Transaction type" dropdown 8. Select "Account credit" as the transaction type 9. Enter the refund amount and click "Confirm" 10. Navigate back to the patron's Accounting tab 11. Verify that a REFUND credit appears on their account 12. Verify that NO PAYOUT debit was created 13. Verify the credit remains on the patron's account (positive balance) Part 2: Test patron transaction refund with Cash payout 16. Using the same patron, create another manual fee and payment 17. Navigate to Point of Sale > Transaction History 18. Click "Issue refund" on the new payment 19. Select "Cash" (or another payment type) as the transaction type 20. Enter the refund amount and click "Confirm" 21. Navigate back to the patron's Accounting tab 22. Verify both a REFUND credit and a PAYOUT debit appear 23. Verify the PAYOUT has the correct payment_type (e.g., CASH) Part 3: Test anonymous transaction (no Account Credit option) 24. Navigate to Point of Sale 25. Add an item to sell and complete the payment 27. Navigate to Point of Sale > Transaction History 28. Find the anonymous payment you just created 29. Click "Issue refund" on the payment line item 30. Verify that "Account credit" does NOT appear in the "Transaction type" dropdown (only payment types like Cash, Check, etc. should appear) 31. This confirms anonymous transactions cannot have account credits since there's no patron account to credit Expected results: - Patron transactions show "Account credit" option in refund dropdown - Anonymous transactions do NOT show "Account credit" option - AC refunds create only REFUND credit (no PAYOUT debit) - Non-AC refunds create both REFUND credit and PAYOUT debit - Run: prove t/db_dependent/Koha/Cash/Register/Cashup.t -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 Laura Escamilla <Laura.escamilla@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 Laura Escamilla <Laura.escamilla@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Laura.escamilla@bywatersolu | |tions.com --- Comment #3 from Laura Escamilla <Laura.escamilla@bywatersolutions.com> --- Side note: The QA tool is complaining about tidiness. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 --- Comment #4 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197959 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197959&action=edit Bug 41819: POS refunds with 'AC' type incorrectly create PAYOUT accountlines When processing a refund through the POS register with refund type 'AC' (Account Credit), the system was incorrectly creating both a REFUND credit and a PAYOUT debit with payment_type = 'AC'. When 'AC' is selected, the refund should remain as a credit on the patron's account without creating a payout. This behavior was already correct in the member account refund workflow (members/boraccount.pl) but was missing from the POS refund workflow. This patch: 1. Adds the same check to pos/register.pl that exists in members/boraccount.pl to skip payout creation when refund_type is 'AC', making both workflows consistent. 2. Fixes the JavaScript in register.tt to properly hide the 'AC' option for anonymous transactions. The original check only tested for empty string, but borrowernumber can be undefined/null, which needs to be handled. Test plan: Part 1: Test patron transaction refund with Account Credit (AC) 1. Find or create a test patron 2. On the patron's Accounting tab, manually add a charge (e.g., Manual fee) 3. Pay the fee off from the patron's Accounting tab 4. Navigate to Point of Sale > Transaction History 5. Find the payment transaction you just created 6. Click "Issue refund" on the payment line item 7. Verify that "Account credit" appears as an option in the "Transaction type" dropdown 8. Select "Account credit" as the transaction type 9. Enter the refund amount and click "Confirm" 10. Navigate back to the patron's Accounting tab 11. Verify that a REFUND credit appears on their account 12. Verify that NO PAYOUT debit was created 13. Verify the credit remains on the patron's account (positive balance) Part 2: Test patron transaction refund with Cash payout 16. Using the same patron, create another manual fee and payment 17. Navigate to Point of Sale > Transaction History 18. Click "Issue refund" on the new payment 19. Select "Cash" (or another payment type) as the transaction type 20. Enter the refund amount and click "Confirm" 21. Navigate back to the patron's Accounting tab 22. Verify both a REFUND credit and a PAYOUT debit appear 23. Verify the PAYOUT has the correct payment_type (e.g., CASH) Part 3: Test anonymous transaction (no Account Credit option) 24. Navigate to Point of Sale 25. Add an item to sell and complete the payment 27. Navigate to Point of Sale > Transaction History 28. Find the anonymous payment you just created 29. Click "Issue refund" on the payment line item 30. Verify that "Account credit" does NOT appear in the "Transaction type" dropdown (only payment types like Cash, Check, etc. should appear) 31. This confirms anonymous transactions cannot have account credits since there's no patron account to credit Expected results: - Patron transactions show "Account credit" option in refund dropdown - Anonymous transactions do NOT show "Account credit" option - AC refunds create only REFUND credit (no PAYOUT debit) - Non-AC refunds create both REFUND credit and PAYOUT debit - Run: prove t/db_dependent/Koha/Cash/Register/Cashup.t Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 --- Comment #6 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197961 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197961&action=edit Bug 41819: (follow-up) Reject 'AC' refunds for anonymous transactions server-side The previous patch hides the 'Account credit' option in the refund modal when the accountline has no borrowernumber, but that is a UI convenience only. A crafted POST (or a stale page) could still submit refund_type=AC against an anonymous accountline, which would create a REFUND credit with no patron to attach it to and leave the register unbalanced because the payout branch is skipped. Add a server-side guard in pos/register.pl that refuses the operation and surfaces a new error_refund_anonymous_ac flag, rendered in pos/register.tt in the same style as the other refund errors. Test plan: 1. Apply the patch 2. Log in as a user with cash_management/anonymous_refund permission 3. Record an anonymous sale against a register 4. Using the browser devtools (or curl), POST to pos/register.pl with op=cud-refund, refund_type=AC and the accountline id of the sale 5. => Confirm the request is rejected and the "Account credit refunds are not available for anonymous transactions" message is shown 6. => Confirm no REFUND accountline was created and the register balance is unchanged 7. Repeat the POST with refund_type=CASH (or any non-AC type) and confirm the refund + payout are created normally -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198754 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198754&action=edit Bug 41819: POS refunds with 'AC' type incorrectly create PAYOUT accountlines When processing a refund through the POS register with refund type 'AC' (Account Credit), the system was incorrectly creating both a REFUND credit and a PAYOUT debit with payment_type = 'AC'. When 'AC' is selected, the refund should remain as a credit on the patron's account without creating a payout. This behavior was already correct in the member account refund workflow (members/boraccount.pl) but was missing from the POS refund workflow. This patch: 1. Adds the same check to pos/register.pl that exists in members/boraccount.pl to skip payout creation when refund_type is 'AC', making both workflows consistent. 2. Fixes the JavaScript in register.tt to properly hide the 'AC' option for anonymous transactions. The original check only tested for empty string, but borrowernumber can be undefined/null, which needs to be handled. Test plan: Part 1: Test patron transaction refund with Account Credit (AC) 1. Find or create a test patron 2. On the patron's Accounting tab, manually add a charge (e.g., Manual fee) 3. Pay the fee off from the patron's Accounting tab 4. Navigate to Point of Sale > Transaction History 5. Find the payment transaction you just created 6. Click "Issue refund" on the payment line item 7. Verify that "Account credit" appears as an option in the "Transaction type" dropdown 8. Select "Account credit" as the transaction type 9. Enter the refund amount and click "Confirm" 10. Navigate back to the patron's Accounting tab 11. Verify that a REFUND credit appears on their account 12. Verify that NO PAYOUT debit was created 13. Verify the credit remains on the patron's account (positive balance) Part 2: Test patron transaction refund with Cash payout 16. Using the same patron, create another manual fee and payment 17. Navigate to Point of Sale > Transaction History 18. Click "Issue refund" on the new payment 19. Select "Cash" (or another payment type) as the transaction type 20. Enter the refund amount and click "Confirm" 21. Navigate back to the patron's Accounting tab 22. Verify both a REFUND credit and a PAYOUT debit appear 23. Verify the PAYOUT has the correct payment_type (e.g., CASH) Part 3: Test anonymous transaction (no Account Credit option) 24. Navigate to Point of Sale 25. Add an item to sell and complete the payment 27. Navigate to Point of Sale > Transaction History 28. Find the anonymous payment you just created 29. Click "Issue refund" on the payment line item 30. Verify that "Account credit" does NOT appear in the "Transaction type" dropdown (only payment types like Cash, Check, etc. should appear) 31. This confirms anonymous transactions cannot have account credits since there's no patron account to credit Expected results: - Patron transactions show "Account credit" option in refund dropdown - Anonymous transactions do NOT show "Account credit" option - AC refunds create only REFUND credit (no PAYOUT debit) - Non-AC refunds create both REFUND credit and PAYOUT debit - Run: prove t/db_dependent/Koha/Cash/Register/Cashup.t Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 --- Comment #10 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Just another rebase -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41819 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.