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

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Retail Modules] Web POSmajoralways2017-03-22 17:002017-04-26 17:57
ReportermalsasuaView Statuspublic 
Assigned Tomarvintm 
PriorityimmediateResolutionfixedFixed in VersionRR17Q1.1
StatusclosedFix in branchFixed in SCM revisionb5c22314d5f3
ProjectionnoneETAnoneTarget VersionRR17Q1.1
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 commit [^]
Triggers an Emergency PackNo

0035614: 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 ]
blocks defect 0035602 closedmarvintm It is not possible to process one receipt in Error While Importing, if the cashup has been completed 

-  Notes
hgbot (developer)
2017-04-26 14:05

Repository: retail/backports/3.0RR17Q1.1/org.openbravo.retail.posterminal
Changeset: b5c22314d5f39c839529b5218b5e57fdaa2fc0cd
Author: Antonio Moreno <antonio.moreno <at>>
Date: Wed Apr 26 14:05:19 2017 +0200
URL: [^]

Fixed issue 35614. 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/
M src/org/openbravo/retail/posterminal/

- Issue History
Date Modified Username Field Change
2017-03-24 13:56 marvintm Type defect => backport
2017-03-24 13:56 marvintm Target Version => RR17Q1.1
2017-03-24 14:57 marvintm Assigned To mario_castello => marvintm
2017-04-26 14:05 hgbot Checkin
2017-04-26 14:05 hgbot Note Added: 0096198
2017-04-26 14:05 hgbot Status scheduled => resolved
2017-04-26 14:05 hgbot Resolution open => fixed
2017-04-26 14:05 hgbot Fixed in SCM revision => [^]
2017-04-26 17:57 guilleaer Review Assigned To => guilleaer
2017-04-26 17:57 guilleaer Status resolved => closed
2017-04-26 17:57 guilleaer Fixed in Version => RR17Q1.1

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker