Kyle M Hall
285f06e394
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> |
||
---|---|---|
.. | ||
prog |