http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wizzyrea@gmail.com Severity|enhancement |normal -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - low |P3 Severity|normal |major -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 --- Comment #3 from Kyle M Hall <kyle.m.hall@gmail.com> 2012-02-08 17:28:57 UTC --- Created attachment 7512 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7512 Bug 7112 - Having two prices in 020$c causes basket creation to fail from staged marc import The root problem here is that the price is being pulled from the MARC record and is then run through Number::Format::unformat_number. This routine is really being misused, and should only be used to reverse the effects of Number::Format on a number string. We are apparently using it to strip out currency characters and the like. Number::Format::unformat_number will choke if there is more than one period (.) in the price field. MARC standards do not limit this field to a single period, so unless there is only one period, we should skip number unformatting. Examples of that break unformat_number include '18.95 (U.S.)', and '$5.99 ($7.75 CAN)', both of which are perfectly valid. This commit tests to see of $price contains more than one period, if it does have multiple periods, it will skip running the string though number_unformat. The variable $price may fail to have an actual price, in which case the price then defauls to '0.00', which would be rarely if ever the correct price. To combat this, I have added highlighting to any price in the Order Details table that begins with 0 ( i.e. '0.00' ). Also, fixed the incomplete table footer, adding a new td with a span of 3 to fill in the nonexistant cells. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 --- Comment #4 from Kyle M Hall <kyle.m.hall@gmail.com> 2012-02-08 17:45:44 UTC --- As an aside, perhaps GetMarcPrice should do some regex magic to pull the first valid looking number from the price field. For example, if the price field contains "$5.99 ($7.75 CAN)", it should return "5.99". If the field contained "18.95 (U.S.)", then it would "18.95". -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 --- Comment #6 from Kyle M Hall <kyle.m.hall@gmail.com> 2012-02-09 11:16:04 UTC --- That's a good question? I didn't even think of that! I suppose a first question would be do other currency fields in Koha handle decimal commas? If yes, then the question should be asked here as well. (In reply to comment #5)

I was wondering if it works for prices with decimal commas? I should test that :)

-- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=7516 --- Comment #8 from Kyle M Hall <kyle.m.hall@gmail.com> 2012-02-09 14:52:43 UTC --- (In reply to comment #7) I see what you mean. I feel that maybe we should have a custom subroutine that does its best to make sense of any give price field and attempt to get a single number out of it. Then GetMarcPrice would run the price through this before passing back returning the price value. I think I will make a separate bug report for it so we can close this one once it has been signed off and pushed to master.

Other fields do currently not handle commas. But I think this is a different problem - you can control what you enter in Koha and train staff accordingly. This bug is about making use of records from a vendor or third party, so it might be interesting to make it recognize other currency/number formatting as well and convert to a form that the acquisitions module can work with. Perhaps it's worth keeping this bug open with a note, if it's currently not working.

-- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 --- Comment #10 from Kyle M Hall <kyle.m.hall@gmail.com> 2012-02-09 19:16:39 UTC --- Created attachment 7539 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7539 Bug 7112 - Having two prices in 020$c causes basket creation to fail from staged marc import The root problem here is that the price is being pulled from the MARC record and is then run through Number::Format::unformat_number. This routine is really being misused, and should only be used to reverse the effects of Number::Format on a number string. We are apparently using it to strip out currency characters and the like. Number::Format::unformat_number will choke if there is more than one period (.) in the price field. MARC standards do not limit this field to a single period, so unless there is only one period, we should skip number unformatting. Examples of that break unformat_number include '18.95 (U.S.)', and '$5.99 ($7.75 CAN)', both of which are perfectly valid. This commit adds the function MungeMarcPrice that will better handle find a real price value in a given price field. It does a very good job at finding a price in any currency format, and attempts to find a price in whichever currency is active before falling back to the first valid price it can find. The variable $price may fail to have an actual price, in which case the price then defaults to '0.00', which would be rarely if ever the correct price. To combat this, I have added highlighting to any price in the Order Details table that begins with 0 ( i.e. '0.00' ). Also, fixed the incomplete table footer, adding a new td with a span of 3 to fill in the nonexistant cells. Bug 7516 - Create Subroutine For GetMarcPrice that will discern the actual price from a given price field value. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #7540|0 |1 is obsolete| | --- Comment #12 from Kyle M Hall <kyle.m.hall@gmail.com> 2012-02-09 19:24:57 UTC --- Created attachment 7541 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7541 Bug 7112 - Having two prices in 020$c causes basket creation to fail from staged marc import -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #7541|0 |1 is obsolete| | --- Comment #14 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- Created attachment 8250 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8250&action=edit Bug 7112 - Having two prices in 020$c causes basket creation to fail from staged marc import The root problem here is that the price is being pulled from the MARC record and is then run through Number::Format::unformat_number. This routine is really being misused, and should only be used to reverse the effects of Number::Format on a number string. We are apparently using it to strip out currency characters and the like. Number::Format::unformat_number will choke if there is more than one period (.) in the price field. MARC standards do not limit this field to a single period, so unless there is only one period, we should skip number unformatting. Examples of that break unformat_number include '18.95 (U.S.)', and '$5.99 ($7.75 CAN)', both of which are perfectly valid. This commit adds the function MungeMarcPrice that will better handle find a real price value in a given price field. It does a very good job at finding a price in any currency format, and attempts to find a price in whichever currency is active before falling back to the first valid price it can find. The variable $price may fail to have an actual price, in which case the price then defaults to '0.00', which would be rarely if ever the correct price. To combat this, I have added highlighting to any price in the Order Details table that begins with 0 ( i.e. '0.00' ). Also, fixed the incomplete table footer, adding a new td with a span of 3 to fill in the nonexistant cells. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Ian Walls <koha.sekjal@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA CC| |koha.sekjal@gmail.com --- Comment #15 from Ian Walls <koha.sekjal@gmail.com> --- Cleverly picks the best price based on active currency. Minimal changes to C4/Biblio, little chance of regression. Fixes template table issue. Marking as Passed QA. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |ASSIGNED Version|rel_3_6 |master --- Comment #17 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- This does not appear to have been pushed. Resetting to Passed QA. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master Version|master |rel_3_8 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7112 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathieu.saby@univ-rennes2.f | |r --- Comment #19 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Very cosmetic problem introduced by this patch : In a basket, if some prices are between 0 and 1, they are displayed in red, with class = "number error". For example, a VAT of 0.89 euros is displayed in red. In don't think it is normal. I have made a new bug : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9374 M. Saby -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.