Hello @ll The problem here is on the refund modal, when retrieving the default value before being modified it is NaN because in some cases for decimal separators with comma, the recovery fails due to formatting a value already formatted in js. After a quick search I think it's a return of bug 31513 fix
Created attachment 191871 [details] [review] Bug 41688: Fix NaN display in POS refund modal Test plan: Prerequisites: CurrencyFormat as 'FR' activated, have already produced a payment (with a comma separator) 1. Go to POS > register > transaction history 2. Click "Issue refund" on any paid transaction 3. Verify "Amount paid" shows correct amount (not NaN) 4. Enter refund amount with comma decimal (e.g. 5,50) 5. Verify no validation error occurs 6. Process refund successfully
Created attachment 191872 [details] [review] Bug 41688: Fix NaN display in POS refund modal Test plan: Prerequisites: CurrencyFormat as 'FR' activated, have already produced a payment (with a comma separator) 1. Go to POS > register > transaction history 2. Click "Issue refund" on any paid transaction 3. Verify "Amount paid" shows correct amount (not NaN but get the value with comma separator) 4. Enter refund amount (point separator is mandatory to valid input) 5. Verify no validation error occurs 6. Process refund successfully