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
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
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
(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
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>
*** Bug 18491 has been marked as a duplicate of this bug. ***
Why do you unformat on finishreceive.pl?
(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 %]" />
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>
Pushed to master for 17.05!
*** Bug 18500 has been marked as a duplicate of this bug. ***
Patch doesn't apply to 16.11.x - please rebase/comment if it's needed there.
(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
Created attachment 63461 [details] [review] Patch rebased to use 16.11 Bookseller class
Thx for the rebase patch, Colin! This patch has been pushed to 16.11.x and will be in 16.11.08.
> Yes it is required for 16.11 - I'll rebase the patch hi Folks, does this problem exist in 16.05.x?
(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
(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!
(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
Thx!
Could you, please, reconsider this patch? After the patch of Bug 20881 extended price filtering with "on_editing" in koha-tmpl/intranet-tmpl/prog/en/modules/acqui/orderreceive.tt, now (18.05.06), with European (= FR) CurrencyFormat, the 'unformat' makes troubles: the unitprice (which now is passed without formatting) gets multiplied by 100 while receiving orders. Thank you for verifying and reconsidering this.
Hi Janusz, this patch was pushed to all versions - I think we need an new patch on a new bug. There is also a bug report for the problem you describe, that I'd love to see fixed: bug 18723 Dot not recognized as decimal separator on receive