Bug 18471 - Receiving order with unitprice greater than 1000 processing incorrectly
Summary: Receiving order with unitprice greater than 1000 processing incorrectly
Status: Pushed to Stable
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
: 18491 18500 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-04-21 13:15 UTC by Nick Clemens
Modified: 2017-06-06 11:02 UTC (History)
7 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
Bug 18471 - Receiving order with unitprice greater than 1000 processing incorrectly (2.54 KB, patch)
2017-04-21 14:23 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 18471 - Receiving order with unitprice greater than 1000 processing incorrectly (2.59 KB, patch)
2017-04-25 09:17 UTC, Nicolas Legrand
Details | Diff | Splinter Review
Bug 18471 - Receiving order with unitprice greater than 1000 processing incorrectly (2.66 KB, patch)
2017-04-25 13:29 UTC, Jonathan Druart
Details | Diff | Splinter Review
Patch rebased to use 16.11 Bookseller class (2.71 KB, patch)
2017-05-15 08:14 UTC, Colin Campbell
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2017-04-21 13:15:28 UTC
Two problems here really:
Receiving orders process the comma as a decimal point
Invoices are displaying incorrectly when formatting total

To recreate:
1 - Open a basket
2 - Place an order for an item with price > 1000, $4367.00 for example
3 - Close basket
4 - Receive order
5 - Note on orderreceive.pl the price is populate as "4,367.00"
6 - Receive/Save
7 - Note the 'Actual Cost' is now $4.00, verify db contains 4 as well
8 - Cancel receipt
9 - Receive again, this time enter price as "4367"
10 - Receive/save
11 - Note actual cost is correct
12 - Finish receiving
13 - Note invoice reads total as $4.00
14 - Check db - price in aqorders is correct but displaying incorrectly
Comment 1 Kyle M Hall 2017-04-21 14:23:49 UTC
Created attachment 62530 [details] [review]
Bug 18471 - Receiving order with unitprice greater than 1000 processing incorrectly

Receiving orders process the comma as a decimal point
Invoices are displaying incorrectly when formatting total

Test Plan:
1. Open a basket
2. Place an order for an item with price > 1000, $4367.00 for example
3. Close basket
4. Receive order
5. Note on orderreceive.pl the price is populate as "4,367.00"
6. Receive/Save
7. Note the 'Actual Cost' is now $4.00, verify db contains 4 as well
8. Cancel receipt
9. Receive again, this time enter price as "4367"
10. Receive/save
11. Note actual cost is correct
12. Finish receiving
13. Note invoice reads total as $4.00
14. Check db. price in aqorders is correct but displaying incorrectly
15. Apply this patch
16. Repeat step2 1. 14, note errors are fixed
Comment 2 Alex Buckley 2017-04-23 22:34:44 UTC
I tried to replicate this bug on a clean up to date branch and was unable to, the price of 4367.00 was shown throughout the whole of the purchasing process and was also correct in the db
Comment 3 Nick Clemens 2017-04-24 12:09:38 UTC
(In reply to Alex Buckley from comment #2)
> I tried to replicate this bug on a clean up to date branch and was unable
> to, the price of 4367.00 was shown throughout the whole of the purchasing
> process and was also correct in the db

This may be specific to USD and/or browser settings. If the comma is not displaying at any point in the ordering that seems likely
Comment 4 Nicolas Legrand 2017-04-25 09:17:14 UTC
Created attachment 62653 [details] [review]
Bug 18471 - Receiving order with unitprice greater than 1000 processing incorrectly

Receiving orders process the comma as a decimal point
Invoices are displaying incorrectly when formatting total

Test Plan:
1. Open a basket
2. Place an order for an item with price > 1000, $4367.00 for example
3. Close basket
4. Receive order
5. Note on orderreceive.pl the price is populate as "4,367.00"
6. Receive/Save
7. Note the 'Actual Cost' is now $4.00, verify db contains 4 as well
8. Cancel receipt
9. Receive again, this time enter price as "4367"
10. Receive/save
11. Note actual cost is correct
12. Finish receiving
13. Note invoice reads total as $4.00
14. Check db. price in aqorders is correct but displaying incorrectly
15. Apply this patch
16. Repeat step2 1. 14, note errors are fixed

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Comment 5 Nick Clemens 2017-04-25 11:47:46 UTC
*** Bug 18491 has been marked as a duplicate of this bug. ***
Comment 6 Jonathan Druart 2017-04-25 13:24:31 UTC
Why do you unformat on finishreceive.pl?
Comment 7 Jonathan Druart 2017-04-25 13:27:07 UTC
(In reply to Jonathan Druart from comment #6)
> Why do you unformat on finishreceive.pl?

Because we have, in the template:
353             <input type="text" size="20" name="unitprice" id="unitprice" value="[% unitprice | $Price %]" />
Comment 8 Jonathan Druart 2017-04-25 13:29:07 UTC
Created attachment 62677 [details] [review]
Bug 18471 - Receiving order with unitprice greater than 1000 processing incorrectly

Receiving orders process the comma as a decimal point
Invoices are displaying incorrectly when formatting total

Test Plan:
1. Open a basket
2. Place an order for an item with price > 1000, $4367.00 for example
3. Close basket
4. Receive order
5. Note on orderreceive.pl the price is populate as "4,367.00"
6. Receive/Save
7. Note the 'Actual Cost' is now $4.00, verify db contains 4 as well
8. Cancel receipt
9. Receive again, this time enter price as "4367"
10. Receive/save
11. Note actual cost is correct
12. Finish receiving
13. Note invoice reads total as $4.00
14. Check db. price in aqorders is correct but displaying incorrectly
15. Apply this patch
16. Repeat step2 1. 14, note errors are fixed

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 9 Kyle M Hall 2017-04-28 10:28:59 UTC
Pushed to master for 17.05!
Comment 10 Colin Campbell 2017-04-28 14:59:27 UTC
*** Bug 18500 has been marked as a duplicate of this bug. ***
Comment 11 Katrin Fischer 2017-05-13 11:59:58 UTC
Patch doesn't apply to 16.11.x - please rebase/comment if it's needed there.
Comment 12 Colin Campbell 2017-05-15 08:12:37 UTC
(In reply to Katrin Fischer from comment #11)
> Patch doesn't apply to 16.11.x - please rebase/comment if it's needed there.

Yes it is required for 16.11 - I'll rebase the patch
Comment 13 Colin Campbell 2017-05-15 08:14:34 UTC
Created attachment 63461 [details] [review]
Patch rebased to use 16.11 Bookseller class
Comment 14 Katrin Fischer 2017-05-16 06:07:58 UTC
Thx for the rebase patch, Colin!
This patch has been pushed to 16.11.x and will be in 16.11.08.
Comment 15 Mason James 2017-05-24 00:15:44 UTC
> Yes it is required for 16.11 - I'll rebase the patch

hi Folks, does this problem exist in 16.05.x?
Comment 16 Colin Campbell 2017-05-24 10:28:16 UTC
(In reply to Mason James from comment #15)
> > Yes it is required for 16.11 - I'll rebase the patch
> 
> hi Folks, does this problem exist in 16.05.x?

I think not. 16.11 introduced some price formatting changes that caused a problem when amounts wth a comma were passed. I think 16.5 does the right thing
Comment 17 Katrin Fischer 2017-06-05 13:37:08 UTC
(In reply to Colin Campbell from comment #16)
> (In reply to Mason James from comment #15)
> > > Yes it is required for 16.11 - I'll rebase the patch
> > 
> > hi Folks, does this problem exist in 16.05.x?
> 
> I think not. 16.11 introduced some price formatting changes that caused a
> problem when amounts wth a comma were passed. I think 16.5 does the right
> thing

Hi Colin,
can you file a bug for any existing problems please? I'd like to get 16.11.x as bug free as possible!
Comment 18 Colin Campbell 2017-06-06 11:02:25 UTC
(In reply to Katrin Fischer from comment #17)
> (In reply to Colin Campbell from comment #16)
> > (In reply to Mason James from comment #15)
> > > > Yes it is required for 16.11 - I'll rebase the patch
> > > 
> > > hi Folks, does this problem exist in 16.05.x?
> > 
> > I think not. 16.11 introduced some price formatting changes that caused a
> > problem when amounts wth a comma were passed. I think 16.5 does the right
> > thing
> 
> Hi Colin,
> can you file a bug for any existing problems please? I'd like to get 16.11.x
> as bug free as possible!

I think the problems are resolved by the applied patch. Problem was the new formatting was being applied twice - patch resolves the effects