0039793: Remaining field is not working properly executing cash up with 3 decimals.

Issue History
Date Modified	Username	Field	Change
2018-12-12 16:55	samuel_nicuesa	New Issue
2018-12-12 16:55	samuel_nicuesa	Assigned To	=> Retail
2018-12-12 16:55	samuel_nicuesa	OBNetwork customer	=> Gold
2018-12-12 16:55	samuel_nicuesa	Support ticket	=> 6415
2018-12-12 16:55	samuel_nicuesa	Resolution time	=> 1546383600
2018-12-12 16:55	samuel_nicuesa	Triggers an Emergency Pack	=> No
2018-12-12 16:55	samuel_nicuesa	File Added: Cashup1.png
2018-12-12 16:56	samuel_nicuesa	File Added: Cashup2.png
2018-12-12 16:56	samuel_nicuesa	File Added: Cashup3.png
2018-12-12 17:11	rafaroda	Issue Monitored: rafaroda
2018-12-13 11:03	ranjith_qualiantech_com	Assigned To	Retail => ranjith_qualiantech_com
2018-12-13 11:04	ranjith_qualiantech_com	Status	new => scheduled
2018-12-13 12:15	ranjith_qualiantech_com	Relationship added	caused by 0031962
2018-12-19 10:42	marvintm	Review Assigned To	=> marvintm
2018-12-19 10:42	marvintm	Note Added: 0108669
2018-12-19 10:42	marvintm	Status	scheduled => closed
2018-12-19 10:42	marvintm	Resolution	open => no change required

Notes
(0108669) marvintm (viewer) 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.