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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0040868
TypeCategorySeverityReproducibilityDate SubmittedLast Update
design defect[Retail Modules] Web POSmajorhave not tried2019-05-13 18:282019-08-06 16:56
ReportermarvintmView Statuspublic 
Assigned Toranjith_qualiantech_com 
PrioritynormalResolutionfixedFixed in VersionRR19Q3
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toguilleaer
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0040868: When cashup is required, it is possible to reach a state in which the user cannot continue

DescriptionWhen a terminal goes offline, and in the meantime the store is closed and the business date changes, it is mandatory to do the cashup.

In this case, next time the user logs in the WebPOS, a popup explaining that the cashup is required is shown, and automated navigation to the cashup window occurs

However, it is possible that the cashup cannot be done. For example, it is possible that non-completed tickets with payments exist in the terminal, or that the user needs to do a cash management before executing the cashup. In this case, the user is stuck, because if he cancels the process he is moved to the login window again.
Steps To Reproduce- Log in a terminal, go offline, do some tickets.
- Create a ticket with a payment, but don't complete it.
- In the backoffice, close the store and open it in a different business date.
- Go online in the terminal, and do login. Cashup will be required, but it is not possible to complete it as there is a ticket which cannot be removed, due to it containing a payment.
- If the process is cancelled, the WebPOS moves again to the login window. If login is done again, cashup is required. It is not possible to get out of this loop, unless the cache is cleared.
Proposed SolutionThe popup explaining that the cashup is required should be shown. However, this popup should have a second button, which allows the user to go into the WebPOS main window with the previous business date se instead of the new one. The user would then be able to complete any necessary action before finally doing the cashup.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0041549 closedranjith_qualiantech_com Show Orders button always should be displayed to access to WEB POS with the previous Business Date 
related to defect 0041550 closedranjith_qualiantech_com Unable to do cash management if we access to Web POS using Show Order button. 

-  Notes
(0111647)
rafaroda (developer)
2019-05-13 18:41

As an extra comment, the user, once logged in this way, should have some actions restricted, for instance:
* Not allowed to click Done button
* Not allowed to click Pay On Credit button
This might come as a separate/custom blocking of features.
(0112080)
hgbot (developer)
2019-05-23 09:53

Repository: erp/pmods/org.openbravo.retail.sessions
Changeset: cc80d2b9e8914657c97e95310c0ee48c6c14a8b3
Author: Ranjith S R <ranjith <at> qualiantech.com>
Date: Thu May 23 13:23:29 2019 +0530
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.sessions/rev/cc80d2b9e8914657c97e95310c0ee48c6c14a8b3 [^]

Related to issue 40868 : Allow to Process Order With Payments when store is closed

* If cashup is pending and store is closed, while login, new button "Show Orders" is provided in the "Cashup needs to be done" popup.
  If "Show Orders" button is clicked it will be redirected with pointofsale window which shows the pending orders to complete.
  Once the pending orders are closed, it will ask user to do cashup by showing popup (It will not force do to cashup)

---
M src-db/database/sourcedata/AD_MESSAGE.xml
M web/org.openbravo.retail.sessions/js/components/loginhook.js
M web/org.openbravo.retail.sessions/js/countcash/countcash.js
---
(0112254)
hgbot (developer)
2019-05-30 07:59

Repository: tools/automation/pi-mobile
Changeset: f3db8e8bb6d1227b07a46e2618da01a272363eb2
Author: Ranjith S R <ranjith <at> qualiantech.com>
Date: Thu May 30 11:29:34 2019 +0530
URL: http://code.openbravo.com/tools/automation/pi-mobile/rev/f3db8e8bb6d1227b07a46e2618da01a272363eb2 [^]

Verifies issue 40868 : Added automated test 'I40868_VerifyCashupWithUnPaidOrder'

---
A src-test/org/openbravo/test/mobile/retail/extmodules/selenium/tests/sessions/openstoretill/I40868_VerifyCashupWithUnPaidOrder.java
---
(0112585)
samuel_nicuesa (developer)
2019-06-11 18:27

When you click on show orders button and if you do cash up the business date of this cash up is the new business date and not the old one.
(0112888)
hgbot (developer)
2019-06-19 12:52

Repository: erp/pmods/org.openbravo.retail.sessions
Changeset: 51cb9aa4170c912fc4ce67d35a565cfdd96d2cf4
Author: Ranjith S R <ranjith <at> qualiantech.com>
Date: Wed Jun 19 16:22:33 2019 +0530
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.sessions/rev/51cb9aa4170c912fc4ce67d35a565cfdd96d2cf4 [^]

Related to issue 40868 : Session cashup should be checked if store is closed in backoffice

* If Store is closed in backoffice, and orders are pending to close then pos should redirect to pointofsale window with old business date

---
M web/org.openbravo.retail.sessions/js/components/loginhook.js
---

- Issue History
Date Modified Username Field Change
2019-05-13 18:28 marvintm New Issue
2019-05-13 18:28 marvintm Assigned To => Retail
2019-05-13 18:28 marvintm Triggers an Emergency Pack => No
2019-05-13 18:42 rafaroda Note Added: 0111647
2019-05-13 18:42 rafaroda Issue Monitored: rafaroda
2019-05-22 08:34 ranjith_qualiantech_com Assigned To Retail => ranjith_qualiantech_com
2019-05-22 14:14 ranjith_qualiantech_com Status new => scheduled
2019-05-23 09:53 hgbot Checkin
2019-05-23 09:53 hgbot Note Added: 0112080
2019-05-30 07:59 hgbot Checkin
2019-05-30 07:59 hgbot Note Added: 0112254
2019-05-30 07:59 ranjith_qualiantech_com Status scheduled => resolved
2019-05-30 07:59 ranjith_qualiantech_com Resolution open => fixed
2019-06-06 20:39 marvintm Review Assigned To => marvintm
2019-06-06 20:39 marvintm Status resolved => closed
2019-06-06 20:39 marvintm Fixed in Version => RR19Q3
2019-06-11 18:27 samuel_nicuesa Note Added: 0112585
2019-06-11 18:27 samuel_nicuesa Status closed => new
2019-06-11 18:27 samuel_nicuesa Resolution fixed => open
2019-06-11 18:27 samuel_nicuesa Fixed in Version RR19Q3 =>
2019-06-12 09:06 ranjith_qualiantech_com Status new => scheduled
2019-06-19 12:52 hgbot Checkin
2019-06-19 12:52 hgbot Note Added: 0112888
2019-06-20 12:13 ranjith_qualiantech_com Status scheduled => resolved
2019-06-20 12:13 ranjith_qualiantech_com Resolution open => fixed
2019-06-24 17:07 guilleaer Review Assigned To marvintm => guilleaer
2019-06-24 17:07 guilleaer Status resolved => closed
2019-06-24 17:07 guilleaer Fixed in Version => RR19Q3
2019-08-06 14:55 ranjith_qualiantech_com Relationship added related to 0041432
2019-08-06 15:00 ranjith_qualiantech_com Relationship deleted related to 0041432
2019-08-06 16:56 rafaroda Relationship added related to 0041549
2019-08-06 16:56 rafaroda Relationship added related to 0041550


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker