Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0033762
TypeCategorySeverityReproducibilityDate SubmittedLast Update
design defect[Retail Modules] Web POSmajoralways2016-08-22 13:502016-09-08 13:02
ReportermalsasuaView Statuspublic 
Assigned ToRetail 
PriorityhighResolutionopenFixed in Version
StatusnewFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tojorge-garcia
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0033762: 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
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to design defect 0024601 newRetail Still we continue having problems with rounding in web POS 
related to design defect 0036694 closedjorge-garcia In Currency window, POS precision can be higher than the currency's real precision (commonly 2) 

-  Notes
(0089388)
jorge-garcia (reporter)
2016-08-25 12:01

 This issue will be manage and fixed in the issue 33611
(0089473)
eugeni (reporter)
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 (developer)
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 (reporter)
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 (developer)
2016-08-30 11:34

 Reopened: new comments have been added to the issue, and they should be analyzed by retail team

- Issue History
Date Modified Username Field Change
2016-08-22 13:50 malsasua New Issue
2016-08-22 13:50 malsasua Assigned To => Retail
2016-08-22 13:50 malsasua Resolution time => 1472853600
2016-08-22 13:50 malsasua Triggers an Emergency Pack => No
2016-08-22 13:50 malsasua Relationship added duplicate of 0033611
2016-08-22 14:36 eugeni Issue Monitored: eugeni
2016-08-25 12:00 jorge-garcia Status new => scheduled
2016-08-25 12:00 jorge-garcia Status scheduled => resolved
2016-08-25 12:00 jorge-garcia Resolution open => fixed
2016-08-25 12:01 jorge-garcia Review Assigned To => jorge-garcia
2016-08-25 12:01 jorge-garcia Note Added: 0089388
2016-08-25 12:01 jorge-garcia Status resolved => closed
2016-08-26 18:40 eugeni Note Added: 0089473
2016-08-30 08:46 migueldejuana Note Added: 0089524
2016-08-30 10:33 eugeni Note Added: 0089536
2016-08-30 11:34 malsasua Note Added: 0089542
2016-08-30 11:34 malsasua Status closed => new
2016-08-30 11:34 malsasua Resolution fixed => open
2016-08-31 13:54 malsasua Relationship deleted 0033611
2016-08-31 13:55 malsasua Type defect => design defect
2016-08-31 13:56 malsasua Relationship added related to 0024601
2016-09-08 13:02 marvintm Resolution time 1472853600 =>
2017-08-22 14:03 ngarcia Relationship added related to 0036694

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker