Openbravo Issue Tracking System - Retail Modules
View Issue Details
0035615Retail ModulesWeb POSpublic2017-03-22 17:002017-04-20 10:22
malsasua 
guilleaer 
immediatemajoralways
closedfixed 
5
 
RR16Q4.3RR16Q4.3 
jorge-garcia
Production - Confirmed Stable
2016-07-15
RR16Q4
https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/8ee815642094 [^]
No
0035615: 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.
blocks defect 0035602 closed marvintm It is not possible to process one receipt in Error While Importing, if the cashup has been completed 
Issue History
2017-03-24 13:56marvintmTypedefect => backport
2017-03-24 13:56marvintmTarget Version => RR16Q4.3
2017-03-24 14:57marvintmAssigned Tomario_castello => marvintm
2017-04-18 18:09hgbotCheckin
2017-04-18 18:09hgbotNote Added: 0096055
2017-04-18 18:09hgbotStatusscheduled => resolved
2017-04-18 18:09hgbotResolutionopen => fixed
2017-04-18 18:09hgbotFixed in SCM revision => http://code.openbravo.com/retail/backports/3.0RR16Q4.3/org.openbravo.retail.posterminal/rev/e4464751717632432e9bce628e0c04653acd163d [^]
2017-04-18 20:20guilleaerAssigned Tomarvintm => guilleaer
2017-04-20 10:22jorge-garciaReview Assigned To => jorge-garcia
2017-04-20 10:22jorge-garciaNote Added: 0096083
2017-04-20 10:22jorge-garciaStatusresolved => closed
2017-04-20 10:22jorge-garciaFixed in Version => RR16Q4.3

Notes
(0096055)
hgbot   
2017-04-18 18:09   
Repository: retail/backports/3.0RR16Q4.3/org.openbravo.retail.posterminal
Changeset: e4464751717632432e9bce628e0c04653acd163d
Author: Guillermo Alvarez de Eulate <guillermo.alvarez <at> openbravo.com>
Date: Tue Apr 18 18:09:07 2017 +0200
URL: http://code.openbravo.com/retail/backports/3.0RR16Q4.3/org.openbravo.retail.posterminal/rev/e4464751717632432e9bce628e0c04653acd163d [^]

Fixed issue 35615, backport of 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
---
(0096083)
jorge-garcia   
2017-04-20 10:22   
Code reviewed and tested