Bug 18723 - Dot not recognized as decimal separator on receive
Summary: Dot not recognized as decimal separator on receive
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Victor Grousset/tuxayo
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on: 12310
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-03 19:30 UTC by Séverine Queune
Modified: 2018-09-14 21:22 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Séverine Queune 2017-06-03 19:30:48 UTC
Since we work on 16.11, we can't use dot when we receive orders but only comma (for example : a price 11.25€ will be changed in 1125,00€ after receiving the order).
It seems linked to syspref "Currencyformat" because the behaviour is different when we change it from FR to US format (a price 15,43€ will be changed in 15,430.00€).

When we worked on 3.20 until this april, we could use both dot and comma when receiving books.
This is quite disturbing for staff users because a dot is required when adding an order to a basket, whereas a comma must be used when receiving the book but there is no warning like it exist in the basket.

I don't know if it's a similar problem to the "Bug 18186 - Amounts with decimal comma instead of decimal dot breaking payments" about the circulation module.
We also work with plack, but even without it, we still have this bug.
Comment 1 Fridolin SOMERS 2017-10-24 12:36:36 UTC
Duplicate of Bug 18471 ?
Comment 2 Fridolin SOMERS 2017-11-17 15:18:47 UTC
You answered in Bug 19521 is it a mistake ?
Comment 3 Victor Grousset/tuxayo 2018-03-14 13:03:45 UTC
Linked but not a duplicate. Needs an independent patch due to the specificities of the two different pages.

The current plan is to make the order page take into account the CurrencyFormat syspref. Server side that means using Koha::Number::Price->unformat()
But it's likely to be done client-side.
Because currently, on the client-side there are calculations to convert the amount from one currency to another.

With that the behavior would be consistent between the order and reception.
Comment 4 Victor Grousset/tuxayo 2018-03-14 16:58:14 UTC
caused by Bug 18471
Comment 5 Victor Grousset/tuxayo 2018-03-26 09:53:43 UTC
The current plan is to make bug 12310 go in master and then in this bug do a follow up in cgi-bin/koha/acqui/orderreceive.pl
Comment 6 Katrin Fischer 2018-08-14 12:49:28 UTC
If we alreay know, that this was caused by 18471 - could we not bring the old behaviour back somehow to make things consistent again? A solution that could be backported.

And then bug 12310 as a new feature/enh for the next release?
Comment 7 Victor Grousset/tuxayo 2018-08-14 17:18:38 UTC
If Bug 18471 causes more harm than good, then that's a nice idea.

If so, then no one should feel blocked to submit such a patch because of the ongoing work on bug 12310 and this bug.

Unfortunately (or fortunately ;) ) all the issues that are reported to me are about fines, so I'll focus on fixing 12310 to not let it sink. Along with this bug, because it's a nice enhancement and it's won't be to much time.

@Séverine Queune, maybe you could rollback bug 18471 on your instance while bug 12310 and this bug are fixed?
Comment 8 Katrin Fischer 2018-09-14 21:22:47 UTC
To test:
- Set CurrencyFormat to FR
- Order something, verify you can use . on input there
- Receive it, verify that if you use . there, it turns into thousands