Openbravo Issue Tracking System - Retail Modules
View Issue Details
0035602Retail ModulesWeb POSpublic2017-03-22 17:002017-04-05 17:30
malsasua 
marvintm 
immediatemajoralways
closedfixed 
5
 
RR17Q2 
guilleaer
Production - Confirmed Stable
2016-07-15
RR16Q4
https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8ee815642094 [^]
No
0035602: It is not possible to process one receipt in Error While Importing, if the cashup has been completed
If 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"
in 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"
No tags attached.
depends on backport 0035614RR17Q1.1 closed marvintm It is not possible to process one receipt in Error While Importing, if the cashup has been completed 
depends on backport 0035615RR16Q4.3 closed guilleaer It is not possible to process one receipt in Error While Importing, if the cashup has been completed 
caused by defect 0033172 closed jorge-garcia [SER QA 1245] Till differences generated during the initial count are not linked to a cashup 
Issue History
2017-03-22 17:00malsasuaNew Issue
2017-03-22 17:00malsasuaAssigned To => Retail
2017-03-22 17:00malsasuaResolution time => 1490652000
2017-03-22 17:00malsasuaRegression level => Production - Confirmed Stable
2017-03-22 17:00malsasuaTriggers an Emergency Pack => No
2017-03-23 04:44pradeepvarmaIssue Monitored: pradeepvarma
2017-03-23 16:44mario_castelloAssigned ToRetail => mario_castello
2017-03-23 16:45mario_castelloStatusnew => acknowledged
2017-03-23 16:46mario_castelloStatusacknowledged => scheduled
2017-03-23 21:33mario_castelloRegression date => 2016-07-15
2017-03-23 21:33mario_castelloRegression introduced in release => RR16Q4
2017-03-23 21:33mario_castelloRegression introduced by commit => https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8ee815642094 [^]
2017-03-23 22:02mario_castelloFile Added: issue35602.diff
2017-03-24 13:56marvintmStatusscheduled => acknowledged
2017-03-24 13:56marvintmStatusacknowledged => scheduled
2017-03-24 14:57marvintmAssigned Tomario_castello => marvintm
2017-03-24 20:33mario_castelloFile Deleted: issue35602.diff
2017-03-27 12:30hgbotCheckin
2017-03-27 12:30hgbotNote Added: 0095585
2017-03-27 12:30hgbotStatusscheduled => resolved
2017-03-27 12:30hgbotResolutionopen => fixed
2017-03-27 12:30hgbotFixed in SCM revision => http://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/56572c1f0599ff652b1b2099eb9b4dbee358f8cb [^]
2017-03-29 11:37guilleaerReview Assigned To => guilleaer
2017-03-29 11:37guilleaerStatusresolved => closed
2017-03-29 11:37guilleaerFixed in Version => RR17Q2
2017-04-05 17:30dmitry_mezentsevRelationship addedcaused by 0033172

Notes
(0095585)
hgbot   
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
---