Fixed: Incorrect unit price calculation during PO receiving under non-US locales (OFBIZ-13449)#1396
Open
toaditi wants to merge 1 commit into
Open
Conversation
…-US locales (OFBIZ-13449) When receiving a purchase order under a locale whose decimal separator is a comma (e.g. pl_PL), the order item unit price was corrupted: 7,41 was stored as 741. The receiving form submits the order-currency unit price as a locale-formatted string. OFBiz's generic String->BigDecimal conversion (ObjectType / NumberConverters.fromString) ignores the caller locale and falls back to Locale.getDefault(), so "7,41" is parsed with comma-as-grouping and becomes 741. Declaring the service attribute as BigDecimal does not help, because the same converter is used. Parse the submitted order-currency unit price explicitly with the request locale (parameters.locale) in updateIssuanceShipmentAndPoOnReceiveInventory, so the value is interpreted correctly regardless of the server's default locale. Add an integration test (ReceivePoLocaleTest) that drives the service under pl_PL and asserts the stored unit price is 7.41; it fails before this change and passes after.
dixitdeepak
reviewed
Jul 1, 2026
| orderItem.unitPrice = new BigDecimal (parameters.orderCurrencyUnitPrice) | ||
| BigDecimal orderCurrencyUnitPrice = parseLocalizedAmount((String) parameters.orderCurrencyUnitPrice, (Locale) parameters.locale) | ||
| if (orderCurrencyUnitPrice != orderItem.unitPrice) { | ||
| orderItem.unitPrice = orderCurrencyUnitPrice | ||
| orderItem.store() |
Contributor
There was a problem hiding this comment.
@toaditi
ObjectType.simpleTypeOrObjectConvert also handles this conversion.
price = (BigDecimal) ObjectType.simpleTypeOrObjectConvert(parameters.orderCurrencyUnitPrice, "BigDecimal", null, locale);
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jira: https://issues.apache.org/jira/browse/OFBIZ-13449
Problem
Receiving a purchase order under a locale whose decimal separator is a comma (e.g.
pl_PL) corrupts the order item unit price:7,41is stored as741.Root cause
The receiving form submits the order-currency unit price as a locale-formatted string. OFBiz's generic String→BigDecimal conversion (
ObjectType.simpleTypeOrObjectConvert→NumberConverters.fromString) ignores the caller locale and falls back toLocale.getDefault()unless thetestBigDecimalsystem property is set:So
simpleTypeOrObjectConvert("7,41","BigDecimal",...,pl_PL,...)returns741(comma read as grouping), even though rawNumberFormat.getNumberInstance(pl_PL).parse("7,41")returns7.41. Declaring the service attribute asBigDecimaldoes not help, because the same converter runs — verified by integration test (it stored741.000).Fix
Parse the submitted order-currency unit price explicitly with the request locale (
parameters.locale) inupdateIssuanceShipmentAndPoOnReceiveInventory, bypassing the generic converter.Verification
Added
ReceivePoLocaleTest(registered inFacilityTest.xml) that drives the service in a real container underpl_PLwithorderCurrencyUnitPrice="7,41"and asserts the storedunitPrice == 7.41:741.000(fails).[JUNIT] Pass: true | # Tests: 1 | # Failed: 0.checkstyleMain/codenarcMain/codenarcTestpass.Note
The underlying
NumberConverters.fromStringbehaviour (discarding the caller locale) looks like a broader framework issue and is probably worth a separate ticket; this PR fixes the receiving flow without changing that shared converter.