Bug 36048 - Error actual cost format in receipt summary
Summary: Error actual cost format in receipt summary
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-08 13:43 UTC by Mirjam Vantieghem
Modified: 2024-04-14 21:12 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mirjam Vantieghem 2024-02-08 13:43:17 UTC
Since 23.11, when receiving an order, in the receipt summary pop-up screen, when clicking in the field 'Actual cost' and then in another field, it gives the error "Please add amount in valid format: 0.00". 

We have system preference CurrencyFormat set to "360 000,00 (FR)". 
In the previous Koha versions the "Retail price" and "Budgeted cost" were formatted that way, but the "Replacement price" and "Actual cost" had a dot for the decimals (US formatting). Now all amounts are formatted according to the system preference, which is a good improvement, but we get an error saying it should be formatted according to the US formatting system.

Regardless of which format we use, when confirming the receipt, the amount is saved in the correct format and there do not seem to be any issues.
Still, the error is confusing and should not appear.
Comment 1 Katrin Fischer 2024-04-14 21:12:03 UTC
Hi Mirjam, at the moment the CurrencyFormat system preference is only used for setting the display, not the input format.

I am to blame for adding the validation and will have to do some more testing, but in general Koha currently expects all amounts entered with a decimal dot. 

In some places a decimal comma led to wrong values or even errors on saving. It might be that the receive page was more flexible, which we might want to have a closer look at.

I was aiming to get some consistency in behavior as a first step. Ultimately we would like to have the input format configurable as well.