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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0035602
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2017-03-22 17:002017-04-05 17:30
ReportermalsasuaView Statuspublic 
Assigned Tomarvintm 
PriorityimmediateResolutionfixedFixed in VersionRR17Q2
StatusclosedFix in branchFixed in SCM revision56572c1f0599
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toguilleaer
Regression levelProduction - Confirmed Stable
Regression date2016-07-15
Regression introduced in releaseRR16Q4
Regression introduced by commithttps://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8ee815642094 [^]
Triggers an Emergency PackNo
Summary

0035602: It is not possible to process one receipt in Error While Importing, if the cashup has been completed

DescriptionIf a receipt is stuck in error while importing (for example, error1), the cashup related to this receipt is completed in Terminal (it is stuck in Error While Importing). Then, the original problem with receipt is fixed (error1 is fixed) and you try to save again the receipt, then the next error is returned:
 "The cashup is processed, and it can not be set as unprocessed"
Steps To Reproducein backend:
. close current period (in Open/Close period control window)
in POS:
. do a receipt: R1
in backend:
. in Open/Close period control: open current period
in terminal:
. complete the cashup: C1

in backend:
. in errors while importing there are two records:
R1 error -> "The Period does not exist or it is not opened"
C1 error -> "There are errors related to non-created customers..."
save again R1-> error is returned:
"The cashup is processed, and it can not be set as unprocessed"
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
depends on backport 0035614RR17Q1.1 closedmarvintm It is not possible to process one receipt in Error While Importing, if the cashup has been completed 
depends on backport 0035615RR16Q4.3 closedguilleaer It is not possible to process one receipt in Error While Importing, if the cashup has been completed 
caused by defect 0033172 closedjorge-garcia [SER QA 1245] Till differences generated during the initial count are not linked to a cashup 

-  Notes
(0095585)
hgbot (developer)
2017-03-27 12:30

 Repository: erp/pmods/org.openbravo.retail.posterminal
Changeset: 56572c1f0599ff652b1b2099eb9b4dbee358f8cb
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Fri Mar 24 14:53:13 2017 +0100
URL: http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/56572c1f0599ff652b1b2099eb9b4dbee358f8cb [^]

Fixed issue 35602. It's now possible to save again orders in the Errors window, if cashup was also sent.
From 16Q4 onwards, the cashup is automatically updated every time an order, cash management, ... is sent to the backend, as part of the process which also updates the record. This makes sense in general , so that the cashup information is always updated, and even if the user clears the cache, it's possible to recover it again.
However, when the cashup has already been sent to the backend, this update is not really needed, and it was causing trouble because at that point, the cashup is marked as processed, which triggered the check that ensures that a processed cashup is not changed back to being not processed.
The solution we have decided is to ensure that lastCashupReportDate is updated when the cashup is sent to the backend, even it if fails. This in turn means that any record which was created previously will not update the cashup information whenever it is saved again, and therefore it will not trigger the check which fails whenever isProcessed is changed from Y to N. This is not a problem, because the cashup processing will update the cashup information with the final values.

---
M src/org/openbravo/retail/posterminal/ProcessCashClose.java
M src/org/openbravo/retail/posterminal/UpdateCashup.java
---

- Issue History
Date Modified Username Field Change
2017-03-22 17:00 malsasua New Issue
2017-03-22 17:00 malsasua Assigned To => Retail
2017-03-22 17:00 malsasua Resolution time => 1490652000
2017-03-22 17:00 malsasua Regression level => Production - Confirmed Stable
2017-03-22 17:00 malsasua Triggers an Emergency Pack => No
2017-03-23 04:44 pradeepvarma Issue Monitored: pradeepvarma
2017-03-23 16:44 mario_castello Assigned To Retail => mario_castello
2017-03-23 16:45 mario_castello Status new => acknowledged
2017-03-23 16:46 mario_castello Status acknowledged => scheduled
2017-03-23 21:33 mario_castello Regression date => 2016-07-15
2017-03-23 21:33 mario_castello Regression introduced in release => RR16Q4
2017-03-23 21:33 mario_castello Regression introduced by commit => https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8ee815642094 [^]
2017-03-23 22:02 mario_castello File Added: issue35602.diff
2017-03-24 13:56 marvintm Status scheduled => acknowledged
2017-03-24 13:56 marvintm Status acknowledged => scheduled
2017-03-24 14:57 marvintm Assigned To mario_castello => marvintm
2017-03-24 20:33 mario_castello File Deleted: issue35602.diff
2017-03-27 12:30 hgbot Checkin
2017-03-27 12:30 hgbot Note Added: 0095585
2017-03-27 12:30 hgbot Status scheduled => resolved
2017-03-27 12:30 hgbot Resolution open => fixed
2017-03-27 12:30 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/56572c1f0599ff652b1b2099eb9b4dbee358f8cb [^]
2017-03-29 11:37 guilleaer Review Assigned To => guilleaer
2017-03-29 11:37 guilleaer Status resolved => closed
2017-03-29 11:37 guilleaer Fixed in Version => RR17Q2
2017-04-05 17:30 dmitry_mezentsev Relationship added caused by 0033172

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker