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

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajorhave not tried2016-02-26 14:052017-01-10 15:02
ReportermarvintmView Statuspublic 
Assigned Tojorge-garcia 
PrioritynormalResolutionfixedFixed in VersionRR17Q1
StatusclosedFix in branchFixed in SCM revision07206a5f7be7
ProjectionnoneETAnoneTarget Version
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

0032365: 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 Filesdiff file icon keyboard1_mobilecore.diff [^] (3,626 bytes) 2016-02-26 14:18 [Show Content]
diff file icon keyboard1_posterminal.diff [^] (662 bytes) 2016-02-26 14:18 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0034732 closedranjith_qualiantech_com Deactivate test I32798_ReceiptGiftVoucherDiscount 
depends on backport 0034896RR16Q4.1 closedjorge-garcia Scanning with external barcode scanner performance can be improved 
causes defect 0034846pi closedjorge-garcia Scanning could not work if the model has change but cache is not deleted 

-  Notes
hgbot (developer)
2016-12-14 16:33

Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 8435373ee62da7f6c0d667ba227e1e37c10f87e9
Author: Jorge Garcia <jorge.garcia <at>>
Date: Wed Dec 14 15:46:38 2016 +0100
URL: [^]

Related to issue 32365: 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
hgbot (developer)
2016-12-14 16:33

Repository: erp/pmods/
Changeset: 07206a5f7be742a7ff5a55565950494b93b77fc3
Author: Jorge Garcia <jorge.garcia <at>>
Date: Wed Dec 14 15:47:42 2016 +0100
URL: [^]

Fixed issue 32365: 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)
2016-12-16 12:57

Repository: erp/pmods/
Changeset: a086fe03a0de133d73f82954a2dc2900a037a63d
Author: Jorge Garcia <jorge.garcia <at>>
Date: Fri Dec 16 12:56:20 2016 +0100
URL: [^]

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

Remove some useless comments of the fix.

M web/
jorge-garcia (reporter)
2017-01-10 15:01

Create backport for RR16Q4.1

- Issue History
Date Modified Username Field Change
2016-02-26 14:05 marvintm New Issue
2016-02-26 14:05 marvintm Assigned To => Retail
2016-02-26 14:05 marvintm Triggers an Emergency Pack => No
2016-02-26 14:17 marvintm Proposed Solution updated
2016-02-26 14:18 marvintm File Added: keyboard1_mobilecore.diff
2016-02-26 14:18 marvintm File Added: keyboard1_posterminal.diff
2016-02-26 14:43 Orekaria Proposed Solution updated
2016-02-26 14:43 Orekaria Status new => acknowledged
2016-10-25 13:10 malsasua Resolution time => 1479250800
2016-10-25 17:45 jorge-garcia Status acknowledged => scheduled
2016-10-25 17:45 jorge-garcia Assigned To Retail => jorge-garcia
2016-12-14 16:32 jorge-garcia Relationship added related to 0034732
2016-12-14 16:33 hgbot Checkin
2016-12-14 16:33 hgbot Note Added: 0092366
2016-12-14 16:33 hgbot Checkin
2016-12-14 16:33 hgbot Note Added: 0092367
2016-12-14 16:33 hgbot Status scheduled => resolved
2016-12-14 16:33 hgbot Resolution open => fixed
2016-12-14 16:33 hgbot Fixed in SCM revision => [^]
2016-12-16 12:57 hgbot Checkin
2016-12-16 12:57 hgbot Note Added: 0092484
2016-12-16 12:58 marvintm Review Assigned To => marvintm
2016-12-16 12:58 marvintm Status resolved => closed
2016-12-16 12:58 marvintm Fixed in Version => RR17Q1
2017-01-03 17:07 jorge-garcia Relationship added causes 0034846
2017-01-10 15:01 jorge-garcia Note Added: 0093311
2017-01-10 15:01 jorge-garcia Status closed => new
2017-01-10 15:01 jorge-garcia Resolution fixed => open
2017-01-10 15:01 jorge-garcia Fixed in Version RR17Q1 =>
2017-01-10 15:01 jorge-garcia Status new => scheduled
2017-01-10 15:02 jorge-garcia Status scheduled => resolved
2017-01-10 15:02 jorge-garcia Resolution open => fixed
2017-01-10 15:02 jorge-garcia Status resolved => closed
2017-01-10 15:02 jorge-garcia Fixed in Version => RR17Q1

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker