Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Retail Modules] Web POSmajoralways2018-04-27 13:532018-05-10 12:03
ReportermaiteView Statuspublic 
Assigned Togorka_gil 
PriorityimmediateResolutionfixedFixed in VersionRR18Q1.3
StatusclosedFix in branchFixed in SCM revision239e16d6cc55
ProjectionnoneETAnoneTarget VersionRR18Q1.3
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tomarvintm
Regression level
Regression date
Regression introduced in releasemain
Regression introduced by commit [^]
Triggers an Emergency PackNo

0038468: getPaymentAmount() is not being rounded and causes ticket is identified as "hasReceiptChange"=true

DescriptionWhen ticket is paid using higher amount but change is given in same currency, it should not be identified as "change"
Steps To Reproduce0. Access Terminal, select any product and set price=1500.40
1. Pay ticket setting amount=1550 (so change of 49.6 is calculated) and press done
2. Access backoffice to review the sales order and realize that payment plan information is incorrect as change amount has been identified as outstanding amount. Also, navigate to Payment document and realize that details are incorrect as gl item has been used when it should not.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
blocks defect 0038466 closedgorka_gil getPaymentAmount() is not being rounded and causes ticket is identified as "hasReceiptChange"=true 

-  Notes
hgbot (developer)
2018-05-02 14:12

Repository: retail/backports/3.0RR18Q1.3/org.openbravo.retail.posterminal
Changeset: 239e16d6cc55bd44814cf9a1147c04c2a749abca
Author: Gorka Gil <gorka.gil <at>>
Date: Wed May 02 12:26:25 2018 +0200
URL: [^]

Fixes issue 38468: Fix precision of payment amount read from json in the order loader.

Payment amount when read from json was passed to Double and then to BigDecimal which produce precision problems.
The precision problems makes that the check if there is change to be true, when in really there isn't change,
which produce the behaviour reported in the issue.

Now readed as string from json and passed directly to BigDecimal.

M src/org/openbravo/retail/posterminal/

- Issue History
Date Modified Username Field Change
2018-04-27 14:01 marvintm Type defect => backport
2018-04-27 14:01 marvintm Target Version => RR18Q1.4
2018-05-02 14:12 hgbot Checkin
2018-05-02 14:12 hgbot Note Added: 0104202
2018-05-02 14:12 hgbot Status scheduled => resolved
2018-05-02 14:12 hgbot Resolution open => fixed
2018-05-02 14:12 hgbot Fixed in SCM revision => [^]
2018-05-02 14:13 gorka_gil Target Version RR18Q1.4 => RR18Q1.3
2018-05-04 14:45 marvintm Review Assigned To => marvintm
2018-05-04 14:45 marvintm Status resolved => closed
2018-05-04 14:45 marvintm Fixed in Version => RR18Q1.3
2018-05-10 12:03 gorka_gil Assigned To Retail => gorka_gil

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker