Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0035614Retail ModulesWeb POSpublic2017-03-22 17:002017-04-26 17:57
Reportermalsasua 
Assigned Tomarvintm 
PriorityimmediateSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionRR17Q1.1Fixed in VersionRR17Q1.1 
Merge Request Status
Review Assigned Toguilleaer
OBNetwork customer
Support ticket
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
Summary0035614: 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"
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
blocks defect 0035602 closed marvintm It is not possible to process one receipt in Error While Importing, if the cashup has been completed 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2017-03-24 13:56marvintmTypedefect => backport
2017-03-24 13:56marvintmTarget Version => RR17Q1.1
2017-03-24 14:57marvintmAssigned Tomario_castello => marvintm
2017-04-26 14:05hgbotCheckin
2017-04-26 14:05hgbotNote Added: 0096198
2017-04-26 14:05hgbotStatusscheduled => resolved
2017-04-26 14:05hgbotResolutionopen => fixed
2017-04-26 14:05hgbotFixed in SCM revision => http://code.openbravo.com/retail/backports/3.0RR17Q1.1/org.openbravo.retail.posterminal/rev/b5c22314d5f39c839529b5218b5e57fdaa2fc0cd [^]
2017-04-26 17:57guilleaerReview Assigned To => guilleaer
2017-04-26 17:57guilleaerStatusresolved => closed
2017-04-26 17:57guilleaerFixed in Version => RR17Q1.1

Notes
(0096198)
hgbot   
2017-04-26 14:05   
Repository: retail/backports/3.0RR17Q1.1/org.openbravo.retail.posterminal
Changeset: b5c22314d5f39c839529b5218b5e57fdaa2fc0cd
Author: Antonio Moreno <antonio.moreno <at> openbravo.com>
Date: Wed Apr 26 14:05:19 2017 +0200
URL: http://code.openbravo.com/retail/backports/3.0RR17Q1.1/org.openbravo.retail.posterminal/rev/b5c22314d5f39c839529b5218b5e57fdaa2fc0cd [^]

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/ProcessCashClose.java
M src/org/openbravo/retail/posterminal/UpdateCashup.java
---