Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0039793Retail ModulesWeb POSpublic2018-12-12 16:552018-12-19 10:42
Reportersamuel_nicuesa 
Assigned Toranjith_qualiantech_com 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS5OS Version
Product Versionpi 
Target VersionFixed in Version 
Merge Request Status
Review Assigned Tomarvintm
OBNetwork customerGold
Support ticket6415
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0039793: Remaining field is not working properly executing cash up with 3 decimals.
DescriptionRemaining field is not working properly executing cash up with 3 decimals.
Steps To Reproduce[BO]
Configure 3 decimals for product price and Web POS.
Change product price for one product setting amount 0.002

[POS]

Create a new ticket and add the product
Pay the ticket
Do cash up
You will see in Count Cash that Total = 0.002 and Remaining = -0.002
If you count 0.010 remaining changes to 0.010 but it is not correct because Total = 0.002 and Counted = 0.010

See attached images
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
caused by defect 0031962 closed ranjith_qualiantech_com reconciliations cashup not balanced with price precision 4 decimals 
Attached Filespng Cashup1.png (61,378) 2018-12-12 16:55
https://issues.openbravo.com/file_download.php?file_id=12429&type=bug
png

png Cashup2.png (62,526) 2018-12-12 16:56
https://issues.openbravo.com/file_download.php?file_id=12430&type=bug
png

png Cashup3.png (64,835) 2018-12-12 16:56
https://issues.openbravo.com/file_download.php?file_id=12431&type=bug
png
Issue History
Date ModifiedUsernameFieldChange
2018-12-12 16:55samuel_nicuesaNew Issue
2018-12-12 16:55samuel_nicuesaAssigned To => Retail
2018-12-12 16:55samuel_nicuesaOBNetwork customer => Gold
2018-12-12 16:55samuel_nicuesaSupport ticket => 6415
2018-12-12 16:55samuel_nicuesaResolution time => 1546383600
2018-12-12 16:55samuel_nicuesaTriggers an Emergency Pack => No
2018-12-12 16:55samuel_nicuesaFile Added: Cashup1.png
2018-12-12 16:56samuel_nicuesaFile Added: Cashup2.png
2018-12-12 16:56samuel_nicuesaFile Added: Cashup3.png
2018-12-12 17:11rafarodaIssue Monitored: rafaroda
2018-12-13 11:03ranjith_qualiantech_comAssigned ToRetail => ranjith_qualiantech_com
2018-12-13 11:04ranjith_qualiantech_comStatusnew => scheduled
2018-12-13 12:15ranjith_qualiantech_comRelationship addedcaused by 0031962
2018-12-19 10:42marvintmReview Assigned To => marvintm
2018-12-19 10:42marvintmNote Added: 0108669
2018-12-19 10:42marvintmStatusscheduled => closed
2018-12-19 10:42marvintmResolutionopen => no change required

Notes
(0108669)
marvintm   
2018-12-19 10:42   
After some further discussion, we have concluded that the current behaviour is correct.

The problem comes from the fact that the customer is using decimal precision 3 in the currency, but the created coins only have two decimals precision. Therefore, when paying tickets, it's not possible to pay the exact amount. The WebPOS assumes that the change will be returned to the customer, but it is kept in the till instead.

Therefore, in the end the amount Openbravo assumed that was kept in the till is different from reality. This explains why later on, in the cashup, the expected amount doesn't match with the counted amount.

There is a new functionality in 19Q1 version of Openbravo called "multichange" which was designed to cover this particular case, and could be used to avoid this problem.