Openbravo Issue Tracking System - Retail Modules
View Issue Details
0038466Retail ModulesWeb POSpublic2018-04-27 13:532018-06-14 12:36
maite 
gorka_gil 
immediatemajoralways
closedfixed 
5
 
RR18Q3 
marvintm
main
http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/f4fb9c07eb350e512bafe7547473d226da3b7efa [^]
No
0038466: getPaymentAmount() is not being rounded and causes ticket is identified as "hasReceiptChange"=true
When ticket is paid using higher amount but change is given in same currency, it should not be identified as "change"
0. 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.
No tags attached.
depends on backport 0038467RR18Q2 closed gorka_gil getPaymentAmount() is not being rounded and causes ticket is identified as "hasReceiptChange"=true 
depends on backport 0038468RR18Q1.3 closed gorka_gil getPaymentAmount() is not being rounded and causes ticket is identified as "hasReceiptChange"=true 
caused by defect 0038038 closed ranjith_qualiantech_com Wrong payment documents registered in backoffice when giving change in another currency from WebPOS 
Issue History
2018-04-27 13:53maiteNew Issue
2018-04-27 13:53maiteAssigned To => Retail
2018-04-27 13:53maiteResolution time => 1526594400
2018-04-27 13:53maiteTriggers an Emergency Pack => No
2018-04-27 13:54maiteRelationship addedcaused by 0038038
2018-04-27 13:54maiteIssue Monitored: networkb
2018-04-27 13:59maiteProposed Solution updated
2018-04-27 13:59marvintmRegression introduced in release => main
2018-04-27 13:59marvintmRegression introduced by commit => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/f4fb9c07eb350e512bafe7547473d226da3b7efa [^]
2018-04-27 13:59marvintmProposed Solution updated
2018-04-27 14:01marvintmStatusnew => scheduled
2018-04-30 15:35gorka_gilAssigned ToRetail => gorka_gil
2018-05-02 12:28hgbotCheckin
2018-05-02 12:28hgbotNote Added: 0104201
2018-05-02 12:28hgbotStatusscheduled => resolved
2018-05-02 12:28hgbotResolutionopen => fixed
2018-05-02 12:28hgbotFixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/2523a678697ae80e8f2557675a473eedee02c9cf [^]
2018-05-02 13:27marvintmReview Assigned To => marvintm
2018-05-02 13:27marvintmStatusresolved => closed
2018-05-02 13:27marvintmFixed in Version => RR18Q3
2018-06-13 09:07hgbotCheckin
2018-06-13 09:07hgbotNote Added: 0105108
2018-06-13 09:07hgbotStatusclosed => resolved
2018-06-13 09:07hgbotFixed in SCM revisionhttp://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/2523a678697ae80e8f2557675a473eedee02c9cf [^] => http://code.openbravo.com/erp/pmods/org.openbravo.client.analytics/rev/b5a9a67f729b4cdf06b52cf730c962415307a88a [^]
2018-06-14 12:36jarmendarizStatusresolved => closed
2018-06-14 12:36jarmendarizFixed in SCM revisionhttp://code.openbravo.com/erp/pmods/org.openbravo.client.analytics/rev/b5a9a67f729b4cdf06b52cf730c962415307a88a [^] => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/2523a678697ae80e8f2557675a473eedee02c9cf [^]
2018-06-14 12:36jarmendarizNote Deleted: 0105108

Notes
(0104201)
hgbot   
2018-05-02 12:28   
Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 2523a678697ae80e8f2557675a473eedee02c9cf
Author: Gorka Gil <gorka.gil <at> openbravo.com>
Date: Wed May 02 12:26:25 2018 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/2523a678697ae80e8f2557675a473eedee02c9cf [^]

Fixes issue 38466: 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/OrderLoader.java
---