Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Retail Modules] Web POSmajorhave not tried2016-02-26 14:052017-01-17 13:01
ReportermarvintmView Statuspublic 
Assigned Tojorge-garcia 
PrioritynormalResolutionfixedFixed in VersionRR16Q4.1
StatusclosedFix in branchFixed in SCM revision145ec90bc7db
ProjectionnoneETAnoneTarget VersionRR16Q4.1
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tomarvintm
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0034896: Scanning with external barcode scanner performance can be improved

DescriptionCurrently, the performance of the external barcode scanner when scanning the same product a large amount of times in a row is quite poor, specially in low end machines.

This could be easily improved by "grouping" these requests to ensure that the Web POS has to do less rendering, which in this case takes a significant amount of time.

Another potential improvement consists in ensuring that the event which is generated when a scanning happens is only redirected to the specific component which handles the scanner, instead of the whole window.
Steps To Reproduce- Configure a fast external barcode scanner.
- Repeatedly scan the same product many times in short time.
- Verify that in low end machines, the Web POS gets stucked, and it takes a bit of time (sometimes even more than half a minute) to add the products, and compute the total amount.
Proposed SolutionB)
to continue fixing the issue:
- create a test that sends that reproduce the "Remark #1" in A). the goal is not to require a physical code scanner and have it in the automation
- fix the issue

create other tests to verify the uses cases specified in A)

There are two optimizations which should be made:
- First optimization consists in ensuring that the scan event only reaches the component which will actually use this event. This removes the significant overhead that Enyo introduces when receiving and handling events, particularly when there are many components rendered in the page.

- Second optimization consists in grouping products received very quickly. To do this, a small delay should be introduced whenever the first product is added. The idea is to group this requests, and initiate a single "add product" action whenever the user has stopped adding products.

These two optimizations are implemented in patches keyboard1_mobilecore.diff and keyboard1_posterminal.diff

Remark #1: Currently the implementation of the second optimization is not fully correct!! At this point, it only handles the case of the same product being added very quickly (right now it will add all units for the last product). A change to the implementation should be done so that it handles additions of different products very quickly.

Remark #2: It's very important to consider the case of modules which may have added hooks to the PreAddProduct hook, or any other hook that may take place during the process of adding products.

Remark #3: It's very important to test that non-grouped products work correctly after these changes. Optimization #2 most likely will not work for them, but at least the functionality should not be broken.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
blocks defect 0032365 closedjorge-garcia Scanning with external barcode scanner performance can be improved 

-  Notes
hgbot (developer)
2017-01-11 13:31

Repository: retail/backports/3.0RR16Q4.1/
Changeset: 145ec90bc7db1d373d5a60d99200a548352ff234
Author: Jorge Garcia <jorge.garcia <at>>
Date: Tue Jan 10 15:13:17 2017 +0100
URL: [^]

Fixed issue 34896: Scanning with external barcode scanner performance can
be improved

Several improvements have been made for this issue:
* Two findUsingCache are added to improve the search of products and product
* Added several returns to true to skip the execution of waterfall events.
* Accumulate the number of scanned products with the same UPC/EAN code.

Now, the normal flow of execution is:
The first unit of the new product is scanned, and a doAddProduct event is raised.
This is done to manage possible event during the adding of a product.
The rest of scanned products are accumulated. This search is launched in one of
these conditions are triggered:
* The barcode scan a new UPC/EAN code
* The user doesn’t scan anything else, and then a addProduct is added after
raised a timeout (500ms).
The following scan are treated the same way.

M web/
M web/
M web/
M web/
hgbot (developer)
2017-01-11 13:32

Repository: retail/backports/3.0RR16Q4.1/org.openbravo.retail.posterminal
Changeset: 05bab5d42d13087ec7cecbb34c645f920513e17d
Author: Jorge Garcia <jorge.garcia <at>>
Date: Wed Jan 11 12:29:16 2017 +0100
URL: [^]

Related to issue 34896: Scanning with external barcode scanner performance can
be improved

Several improvements have been made for this issue:
* If the product is a non grouped products, the POS creates as much new lines as
number of times the product have been scanned.
+ A new attribute has been added to addProductToReceipt function with the number
of products to add.

M web/org.openbravo.retail.posterminal/js/model/order.js
M web/org.openbravo.retail.posterminal/js/pointofsale/view/keyboardorder.js
M web/org.openbravo.retail.posterminal/js/utils/rfidWebsocket.js

- Issue History
Date Modified Username Field Change
2017-01-10 15:01 jorge-garcia Type defect => backport
2017-01-10 15:01 jorge-garcia Target Version => RR16Q4.1
2017-01-11 13:31 hgbot Checkin
2017-01-11 13:31 hgbot Note Added: 0093354
2017-01-11 13:31 hgbot Status scheduled => resolved
2017-01-11 13:31 hgbot Resolution open => fixed
2017-01-11 13:31 hgbot Fixed in SCM revision [^] => [^]
2017-01-11 13:32 hgbot Checkin
2017-01-11 13:32 hgbot Note Added: 0093356
2017-01-17 13:01 marvintm Status resolved => closed
2017-01-17 13:01 marvintm Fixed in Version => RR16Q4.1

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker