Openbravo Issue Tracking System - Retail Modules
View Issue Details
0040101Retail ModulesOmnichannelpublic2019-02-01 11:352019-02-25 11:10
plujan 
ranjith_qualiantech_com 
normalmajorhave not tried
closedno change required 
5
main 
 
marvintm
No
0040101: [RR19Q1] [OMNI] Trying to pay a ticket that has been already paid in other terminal causes a silent error
I opened a partially paid ticket, while I had it displayed, a user in a different terminal opened and fully paid it.
Not realizing about this other user, I tried to paid the same ticket. I did not receive any error message, and the ticket seem to been synchronized properly.
However, in the "Errors while importing" window, an exception is shown "The data of this order has been changed on the server. Please reload the ticket through the menu and apply your changes again."
1. In the terminal A, create a ticket with one line and partially paid it. Seek for the ticket and open it.
2. In the terminal B, seek for the same ticket and open it.
3. In B, fully paid the ticket. Note the process is successful
4. In A, fully paid the ticket. Note the process is successful
5. Open the backend and check the "Errors while Importing" window. Note the step 4 has generated an error.


The full error is:
org.openbravo.mobile.core.process.OutDatedDataChangeException: The data of this order has been changed on the server. Please reload the ticket through the menu and apply your changes again.
    at org.openbravo.retail.posterminal.OrderLoader.saveRecord(OrderLoader.java:254)
    at org.openbravo.mobile.core.process.DataSynchronizationProcess.saveRecord(DataSynchronizationProcess.java:201)
    at org.openbravo.mobile.core.process.DataSynchronizationProcess.exec(DataSynchronizationProcess.java:155)
    at org.openbravo.mobile.core.process.DataSynchronizationProcess.exec(DataSynchronizationProcess.java:87)
    at org.openbravo.mobile.core.process.MobileImportEntryProcessorRunnable.processEntry(MobileImportEntryProcessorRunnable.java:53)
    at org.openbravo.retail.posterminal.importprocess.OrderImportEntryProcessor$OrderLoaderRunnable.processEntry(OrderImportEntryProcessor.java:59)
    at org.openbravo.service.importprocess.ImportEntryProcessor$ImportEntryProcessRunnable.doRunCycle(ImportEntryProcessor.java:376)
    at org.openbravo.service.importprocess.ImportEntryProcessor$ImportEntryProcessRunnable.run(ImportEntryProcessor.java:297)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:844)
No tags attached.
Issue History
2019-02-01 11:35plujanNew Issue
2019-02-01 11:35plujanAssigned To => Retail
2019-02-01 11:35plujanTriggers an Emergency Pack => No
2019-02-01 11:36plujanSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=18261#r18261
2019-02-25 10:50ranjith_qualiantech_comAssigned ToRetail => ranjith_qualiantech_com
2019-02-25 10:50ranjith_qualiantech_comStatusnew => scheduled
2019-02-25 11:10marvintmReview Assigned To => marvintm
2019-02-25 11:10marvintmNote Added: 0110048
2019-02-25 11:10marvintmStatusscheduled => closed
2019-02-25 11:10marvintmResolutionopen => no change required

Notes
(0110048)
marvintm   
2019-02-25 11:10   
This is the expected behaviour as of now. This is an intrinsic limitation in how the WebPOS synchronises the data. Changing this would involve making the synchronisation not work asynchronously, and this is something we have decided not to do at this point.