You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "toaditi (via GitHub)" <gi...@apache.org> on 2026/06/30 13:25:13 UTC

[PR] Fixed: Incorrect unit price calculation during PO receiving under non-US locales (OFBIZ-13449) [ofbiz-framework]

toaditi opened a new pull request, #1394:
URL: https://github.com/apache/ofbiz-framework/pull/1394

   Jira: https://issues.apache.org/jira/browse/OFBIZ-13449
   
   ## Problem
   During PO receiving under a locale that uses a comma decimal separator (e.g. `pl_PL`), the received order item's unit price is corrupted (the value is mis-scaled, e.g. `7,41` becomes `741`).
   
   ## Root cause
   The receiving form (`ReceiveInventory.ftl`) submits the unit price as a locale-formatted string. The services that carry it — `receiveInventoryProduct` and `updateIssuanceShipmentAndPoOnReceiveInventory` — declared `orderCurrencyUnitPrice` and `unitCost` as `String`, so no locale-aware conversion happened at the service boundary. The Groovy implementation then parsed the raw string with the **locale-insensitive** `new BigDecimal(String)` constructor, corrupting the value.
   
   ## Fix
   - Declare `orderCurrencyUnitPrice` / `unitCost` as `BigDecimal` on both services, so the service engine performs locale-aware conversion of the incoming value.
   - Assign the already-converted parameter directly to `orderItem.unitPrice` instead of re-wrapping it in `new BigDecimal(...)`.
   
   The second part matters: the originally proposed fix (changing only the service-def types) leaves the `new BigDecimal(parameters.orderCurrencyUnitPrice)` call in place. Once the parameter is a `BigDecimal`, Groovy resolves `new BigDecimal(aBigDecimal)` to the `BigDecimal(double)` constructor, which reintroduces a precision error:
   
   ```
   new BigDecimal(7.41G) => 7.410000000000000142108547152020037174224853515625  (scale 48)
   ```
   
   so the wrap must be removed.
   
   ## Verification
   - `xmllint` confirms `services_shipment.xml` is well-formed.
   - The Groovy file parses cleanly (CompilationUnit CONVERSION phase).
   - `./gradlew compileJava` → BUILD SUCCESSFUL.
   
   Note: not yet exercised end-to-end in a live `pl_PL` instance; happy to add that if desired.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@ofbiz.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Fixed: Incorrect unit price calculation during PO receiving under non-US locales (OFBIZ-13449) [ofbiz-framework]

Posted by "toaditi (via GitHub)" <gi...@apache.org>.
toaditi closed pull request #1394: Fixed: Incorrect unit price calculation during PO receiving under non-US locales (OFBIZ-13449)
URL: https://github.com/apache/ofbiz-framework/pull/1394


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@ofbiz.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] Fixed: Incorrect unit price calculation during PO receiving under non-US locales (OFBIZ-13449) [ofbiz-framework]

Posted by "toaditi (via GitHub)" <gi...@apache.org>.
toaditi commented on PR #1394:
URL: https://github.com/apache/ofbiz-framework/pull/1394#issuecomment-4844745299

   Closing this PR: runtime testing showed this approach does not actually fix OFBIZ-13449.
   
   I drove updateIssuanceShipmentAndPoOnReceiveInventory in a real container under pl_PL with orderCurrencyUnitPrice="7,41"; OrderItem.unitPrice was still stored as 741.000 with this change applied.
   
   Root cause is deeper: org.apache.ofbiz.base.conversion.NumberConverters.fromString (framework/base) discards the caller locale and uses Locale.getDefault() unless the testBigDecimal system property is set, so ObjectType.simpleTypeOrObjectConvert("7,41","BigDecimal",...,pl_PL,...) returns 741. Declaring the attribute as BigDecimal therefore cannot fix it. A corrected fix that parses the submitted price with the request locale will follow in a new PR.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@ofbiz.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org