Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0033762Retail ModulesWeb POSpublic2016-08-22 13:502016-09-08 13:02
Reportermalsasua 
Assigned ToRetail 
PriorityhighSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned Tojorge-garcia
OBNetwork customer
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0033762: POS precision is not aligned with options available in backoffice: this can create "inconsistent" orders between channels
DescriptionSummary and implications:
1) On one side, is difficult to explain, from a functional or user perspective that exactly same order is represented in a different way
depending on the channel it has been captured. Omnichannel principle should guarantee consistency in our opinion.
2) Also, being possible that Q x unitPrice <> lineNetAmount for Web POS orders is somehow inconsistent, although lineNetAmount is
right.
3) Finally, unitPrice can't be used anymore in reporting or printed forms, as it is not accurate. Instead, lineNetAmount/Q, rounded to
desired precision needs to be done every time.
Steps To ReproduceSetup:
- Sales price list including taxes
- Price precision = 6 both at currency level and in format.xml
- POS precision = 2
- Tax rate 21% (Entregas IVA 21%)

1) Create a standard order in the backoffice (3 UN x 117 €):
- unitPrice: 96.694215 -> OK, rounded to price precision
- lineNetAmount: 290.08 -> OK
- Q x unitPrice = lineNetAmount rounded to standard precision -> OK
2) Create exactly same order this time through Web POS:
- unitPrice: 96.69 -> notice different representation than same order manually created in backoffice because it has been rounded to
POS precision (2) instead of price precision (6)
- lineNetAmount: 290.08 -> OK
- Q x unitPrice (3 x 96.69 = 290.07) <> lineNetAmount rounded to standard precision -> also notice different representation than
same order manually created in backoffice
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to design defect 0024601 new Retail Still we continue having problems with rounding in web POS 
related to design defect 0036694 closed jorge-garcia In Currency window, POS precision can be higher than the currency's real precision (commonly 2) 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-08-22 13:50malsasuaNew Issue
2016-08-22 13:50malsasuaAssigned To => Retail
2016-08-22 13:50malsasuaResolution time => 1472853600
2016-08-22 13:50malsasuaTriggers an Emergency Pack => No
2016-08-22 13:50malsasuaRelationship addedduplicate of 0033611
2016-08-22 14:36eugeniIssue Monitored: eugeni
2016-08-25 12:00jorge-garciaStatusnew => scheduled
2016-08-25 12:00jorge-garciaStatusscheduled => resolved
2016-08-25 12:00jorge-garciaResolutionopen => fixed
2016-08-25 12:01jorge-garciaReview Assigned To => jorge-garcia
2016-08-25 12:01jorge-garciaNote Added: 0089388
2016-08-25 12:01jorge-garciaStatusresolved => closed
2016-08-26 18:40eugeniNote Added: 0089473
2016-08-30 08:46migueldejuanaNote Added: 0089524
2016-08-30 10:33eugeniNote Added: 0089536
2016-08-30 11:34malsasuaNote Added: 0089542
2016-08-30 11:34malsasuaStatusclosed => new
2016-08-30 11:34malsasuaResolutionfixed => open
2016-08-31 13:54malsasuaRelationship deleted0033611
2016-08-31 13:55malsasuaTypedefect => design defect
2016-08-31 13:56malsasuaRelationship addedrelated to 0024601
2016-09-08 13:02marvintmResolution time1472853600 =>
2017-08-22 14:03ngarciaRelationship addedrelated to 0036694

Notes
(0089388)
jorge-garcia   
2016-08-25 12:01   
This issue will be manage and fixed in the issue 33611
(0089473)
eugeni   
2016-08-26 18:40   
In my opinion, this issue es is not a duplicate of 33611. In fact, it does not have nothing to do with it, but with the way unitPrice is showed and stored, depending of the channel where the SO comes in (application or POS)
(0089524)
migueldejuana   
2016-08-30 08:46   
Th ERP calculation is wrong (https://issues.openbravo.com/view.php?id=32265 [^]). This is the reason for this difference.
Calculating at document level in this case: quantity * netPrice != netLine. We only can ensure that quantity * grossPrice = grossLine.
At document level we need to follow above rule knowing that unit price is just and informative field, it must not be used to do tax calculation.
(0089536)
eugeni   
2016-08-30 10:33   
I Think this is neither the point. Let's assume we have a classic configuration where taxes are calculated at line level. Actually, it doesn't matter, as in this example there is just one line. Create the order through the application and through the POS. The point is that exactly same order is represented in a different way depending on the channel it has been captured.
(0089542)
malsasua   
2016-08-30 11:34   
Reopened: new comments have been added to the issue, and they should be analyzed by retail team